Re: MacVim maintenance

2015-03-26 Thread Andrew Stewart
On 26 Mar 2015, at 00:30, "Charles"  wrote:
> I don't know any C, or anything about Vim's code, but if there's a way I
> can help keep on top of things, please let me know.  Perhaps if there's a
> section on the wiki that explains which sections of the code are free of
> Vim/MacVim conflict, I and others could make github PRs for most Vim
> patches.  Or perhaps @douglasdrumond can post the workflow involved in
> doing this.


I also don't know anything about C or Vim's code but a few months ago I figured 
out how to update MacVim's patchlevel.  Here are the raw notes I made at the 
time:

8<

[1] b4winckler/macvim - 7.4.383
[2] b4winckler/vim- 7.4.430
[3] vim   - 7.4.542

we want to bring [1] up to date with [3].

ideally we'd merge [3] directly into [1] but i can't see how to do that without 
losing macvim-specific stuff.
instead:
A: diff [2] and [1] and apply to [1]
B: diff [3] and [2] and apply to [1']


## Clone vim's repo [3] as a git repo

we don't do this the way recommended on b4winckler/vim/wiki (using mercurial 
and the hg-git mercurial extension).
instead we use git with the "semi-official" git-remote-hg remote helper.

Install git-remote-hg as per instructions 
(https://github.com/felipec/git-remote-hg)
$ git clone hg::https://code.google.com/p/vim/
$ git gc --aggressive
$ git remote add github https://github.com/airblade/vim.git (new, empty repo)
$ git push github master

## Clone macvim's repo [1] and add [2] and [3] as remotes

$ git clone https://github.com/b4winckler/macvim.git
$ cd macvim
$ git remote add b4winckler-vim https://github.com/b4winckler/vim.git
$ git remote add airblade-vim https://github.com/airblade/vim.git
$ git fetch


## A

method 1 (this method squashes all the individual commits together)

$ git diff HEAD...b4winckler-vim/master > a.diff
$ git apply --reject a.diff

mostly applies but a few rejects (mostly perl stuff - see 7.4.409)

$ find . -name '*.rej' -print
./runtime/doc/tags.rej
./src/auto/configure.rej
./src/config.mk.in.rej
./src/configure.in.rej
./src/Makefile.rej
./src/option.c.rej
./src/structs.h.rej

fix up by hand, remove the *.rej files, then generate a new clean diff

$ git add -A
$ git diff --staged > a-clean.diff
$ git commit -m "Patchlevel 430"

method 2 (probably better)

$ git merge b4winckler-vim/master

a few merge conflicts (mostly perl stuff)
for each conflicted file:
fix conflict
git add the fixed file
when all conflicts fixed, finish merge with

$ git commit

generate patch with

$ git diff HEAD^ > a-clean.diff


## B

method 1 (this method squashes all the individual commits together)

$ git diff b4winckler-vim/master...airblade-vim/master > b.diff
$ git apply --reject b.diff

mostly applies but a few rejects

$ find . -name '*.rej' -print 
./runtime/doc/tags.rej
./src/ex_cmds.h.rej
./src/if_ruby.c.rej
./src/misc2.c.rej
./src/vim.h.rej

fix up by hand, remove the *.rej files, then generate a new clean diff

$ git add -A
$ git diff --staged > b-clean.diff
$ git commit -m "Patchlevel 542"

method 2 (probably better)

[i can't figure out how to make this work without losing all the 
macvim-specific stuff]

$ git co -b foo b4winckler-vim/master
$ git merge airblade-vim/master

leads to 150 add-add merge conflicts...i don't understand why


## Upload {a,b}-clean.diff somewhere and `brew edit macvim` adding

head do
patch do
  url 'file:///Users/andy/code/buildingvim/a-clean.diff'
  sha1 '2086b634bb7a2d3c5a079830e66d50184a1c7eb3'
end
patch do
  url 'file:///Users/andy/code/buildingvim/b-clean.diff'
  sha1 '8c696f81903ed910db637fd30a25dea00b95438f'
end
end

i also had to remove `--enable-perlinterp` from compile args around line 55
presumably i messed up the perl stuff when cleaning the rejected patches


## voila

$ brew uninstall macvim
$ brew intall macvim --custom-icons --HEAD
$ brew linkapps


## When vim is updated

we could do B all over again but it takes a while to fix the rejected patches
(either automate this or) better to diff B and let's call it C

$ cd /path/to/vim-clone
$ git pull
$ git push github master
[erm]
$ git diff e62677eac > c.diff
$ cd /path/to/macvim-clone
$ git apply --reject /path/to/c.diff
etc

8<

I'd like to hear of better ways to do this!  Or even see MacVim merged into 
main Vim as someone else suggested.

Yours,
Andy Stewart

-- 
-- 
You received this message from the "vim_mac" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_mac" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_mac+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Is it time to merge MacVim into mainline Vim?

2015-03-26 Thread Bram Moolenaar

Charles wrote:

> Is there any reason still existing why MacVim is a separate project from
> the offical Vim repo?  MacVim is stable and mature, and is probably fairly
> easily mergeable into Vim.
> 
> One benefit of pulling MacVim into regular Vim is: MacVim will never be
> behind Vim in patch level.
> 
> Also, in mainline Vim, the Carbon GUI is effectively dead.  If mainline
> Vim wants an OSX GUI, it should pull in MacVim.  It works all the way back
> to 10.4, and if support of even older machines is desired, the Carbon
> option can be kept.

The main reason it's a separate project is because there are different
people working on MacVim.  This way the project can progress
independently.

I have already offered in the past to include relevant changes into core
Vim.  It's just a matter of providing me with the patch.  Preferably
tested :-).

-- 
Lose weight, NEVER Diet again with
  The "Invisible Weight Loss Patch"
(spam e-mail)

 /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

-- 
-- 
You received this message from the "vim_mac" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_mac" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_mac+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Is it time to merge MacVim into mainline Vim?

2015-03-26 Thread Charles
Bram Moolenaar wrote:
> Charles wrote:
>> Is there any reason still existing why MacVim is a separate project 
from the offical Vim repo?  MacVim is stable and mature, and is 
probably fairly easily mergeable into Vim. One benefit of pulling 
MacVim into regular Vim is: MacVim will never be behind Vim in patch 
level. Also, in mainline Vim, the Carbon GUI is effectively dead.  If 
mainline Vim wants an OSX GUI, it should pull in MacVim.  It works all 
the way back to 10.4, and if support of even older machines is desired,
>>  the  Carbon option can be kept.
> The main reason it's a separate project is because there are different 
people working on MacVim.  This way the project can progress
> independently.

It seems to me that it no longer needs to progress independently (though
at the beginning, this was the wise choice).  There are hardly ever any
changes anymore, apart from pulling in mainline Vim patches.

> I have already offered in the past to include relevant changes into core

> Vim.  It's just a matter of providing me with the patch.  Preferably 
tested :-).

I'm no expert, but I think Bram would have to pull in the entire
src/MacVim directory, minus things that only make sense for a separate
MacVim (like custom icons and Sparkle updating).  Also, several files in
$VIMRUNTIME are modified, especially $VIMRUNTIME/doc.  The big configure
file has tons of differences.  And there are #IFDEF FEAT_GUI_MACVIM blocks
all over the place in /src.

This would require a heroic effort on the part of people who know what the
heck they're doing, but it sure seems better to do this once than to have
to keep doing it every N months to catch up on patchlevel.

> Preferably tested :-).

FWIW, I logged into the only remote Linux box I have access to, and cloned
the MacVim repo as-is (it's currently at 7.4.622). Configuration and
building succeeded without having to do anything preparatory, and I can
successfully use the Vim binary.  "make clean" failed because it wanted to
call `xcodebuild`, but I think it's to be expected that "configure" and
"makefile" will need some tweaking.

Lastly, IMHO this is only a good idea if certain specific MacVim-only
things are pulled in.  I'm thinking especially of MacVim's true fullscreen
mode, and the fact that one can choose whether one wants it to behave in
the old fast way or the modern slow way.  Fullscreen mode (fast version)
in MacVim is, for me, 75% of the reason to use MacVim instead of just good
old Vim in a terminal (or the X11 GUI).  The other 25% is the ability to
use the Cmd key as a modifer in the LHS of mappings.  These two things are
workflow-impacting.  There is precedent in Vim for there to be a few
special things limited to certain GUIs (such as tear-off menus, IIRC), so
I hope that this sort of thing would be accepted into Vim proper.

-Charles





-- 
-- 
You received this message from the "vim_mac" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_mac" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_mac+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.