Re: help for a git newbie -- no merge candidate found
_sc_, 11.02.2009: On Tuesday 10 February 2009 5:54 pm, Markus Heidelberg wrote: _sc_, 07.02.2009: On Friday 06 February 2009 4:09 pm, Matt Wozniski wrote: and my .git/config contains: Somehow, you're missing this: [branch custom] remote = origin merge = refs/heads/vim-with-runtime and adding that in should make things work just fine... indeed it does 06 Feb 2009 16:52 Fri Already up-to-date. thank you a lot Matt, that made all the difference markus: i don't know what i did different than matt -- Maybe you have an old git version installed, where the automatic setup of .git/config for the remote tracking branches (during the command git checkout -b custom origin/vim-with-runtime) was not yet the default. my git reports it is version 1.5.2.4 -- is that old? i It's 1,5 years old, the default mentioned above has changed in 1.5.3 Close aside :) If this is the case, either set branch.autosetupmerge to true or update git, which is of course recommended. please tell me if i need to take steps to get a newer git following is my entire .git/config: [..] is somewhere in here where i should add something about branch.autosetupmerge? somewhere else? (this config is on my ~/.build/vim/vim72/vim_extended/.git path) You can do git config --global branch.autosetupmerge true to globally enable it in you ~/.gitconfig instead of only for this repository. Or you can simply add it by hand: [branch] autosetupmerge = true Of course this is for future creation of custom branches only, it doesn't affect or improve your current setup. Maybe I'll add something like this to the README, but I didn't think such old git versions are still around. and i should again mention, before we go too far in assuming there's a problem in my setup, i think i may well have bolixed the setup myself: i don't remember exactly when in the process it was, but it may well have been during the checkout of vim-with-runtime, i remember being surprised with the fact that i wasn't in a totally normal shell -- i had been using midnight commander and had shelled out of it with Ctrl-O and was working in that shell -- i suspect it has differences much as has been discussed in a different thread concerning shelling out from vim -- i noticed it i think because something wasn't working like it was supposed to -- i think my 'inst' script was executing from my ~/bin path (long irrelevant story) Don't worry, that didn't hurt. Markus --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Patch 7.2.103
Patch 7.2.103
Problem:When 'bomb' is changed the window title is updated to show/hide a
+, but the tab page label isn't. (Patrick Texier)
Solution: Set redraw_tabline in most places where need_maketitle is set.
(partly by Lech Lorens)
Files: src/option.c
*** ../vim-7.2.102/src/option.c Wed Feb 4 17:27:50 2009
--- src/option.cWed Feb 4 17:40:02 2009
***
*** 5268,5273
--- 5268,5288
}
#endif
+ #ifdef FEAT_TITLE
+ static void redraw_titles __ARGS((void));
+
+ /*
+ * Redraw the window title and/or tab page text later.
+ */
+ static void redraw_titles()
+ {
+ need_maketitle = TRUE;
+ # ifdef FEAT_WINDOWS
+ redraw_tabline = TRUE;
+ # endif
+ }
+ #endif
+
/*
* Set a string option to a new value (without checking the effect).
* The string is copied into allocated memory.
***
*** 5672,5678
{
# ifdef FEAT_TITLE
/* May show a + in the title now. */
! need_maketitle = TRUE;
# endif
/* Add 'fileencoding' to the swap file. */
ml_setflags(curbuf);
--- 5687,5693
{
# ifdef FEAT_TITLE
/* May show a + in the title now. */
! redraw_titles();
# endif
/* Add 'fileencoding' to the swap file. */
ml_setflags(curbuf);
***
*** 5691,5697
{
errmsg = mb_init();
# ifdef FEAT_TITLE
! need_maketitle = TRUE;
# endif
}
}
--- 5706,5712
{
errmsg = mb_init();
# ifdef FEAT_TITLE
! redraw_titles();
# endif
}
}
***
*** 5800,5806
else
curbuf-b_p_tx = FALSE;
#ifdef FEAT_TITLE
! need_maketitle = TRUE;
#endif
/* update flag in swap file */
ml_setflags(curbuf);
--- 5815,5821
else
curbuf-b_p_tx = FALSE;
#ifdef FEAT_TITLE
! redraw_titles();
#endif
/* update flag in swap file */
ml_setflags(curbuf);
***
*** 7127,7148
curbuf-b_did_warn = FALSE;
#ifdef FEAT_TITLE
! need_maketitle = TRUE;
#endif
}
#ifdef FEAT_TITLE
/* when 'modifiable' is changed, redraw the window title */
else if ((int *)varp == curbuf-b_p_ma)
! need_maketitle = TRUE;
/* when 'endofline' is changed, redraw the window title */
else if ((int *)varp == curbuf-b_p_eol)
! need_maketitle = TRUE;
! #ifdef FEAT_MBYTE
! /* when 'bomb' is changed, redraw the window title */
else if ((int *)varp == curbuf-b_p_bomb)
! need_maketitle = TRUE;
! #endif
#endif
/* when 'bin' is set also set some other options */
--- 7142,7169
curbuf-b_did_warn = FALSE;
#ifdef FEAT_TITLE
! redraw_titles();
#endif
}
#ifdef FEAT_TITLE
/* when 'modifiable' is changed, redraw the window title */
else if ((int *)varp == curbuf-b_p_ma)
! {
! redraw_titles();
! }
/* when 'endofline' is changed, redraw the window title */
else if ((int *)varp == curbuf-b_p_eol)
! {
! redraw_titles();
! }
! # ifdef FEAT_MBYTE
! /* when 'bomb' is changed, redraw the window title and tab page text */
else if ((int *)varp == curbuf-b_p_bomb)
! {
! redraw_titles();
! }
! # endif
#endif
/* when 'bin' is set also set some other options */
***
*** 7150,7156
{
set_options_bin(old_value, curbuf-b_p_bin, opt_flags);
#ifdef FEAT_TITLE
! need_maketitle = TRUE;
#endif
}
--- 7171,7177
{
set_options_bin(old_value, curbuf-b_p_bin, opt_flags);
#ifdef FEAT_TITLE
! redraw_titles();
#endif
}
***
*** 7301,7307
if (!value)
save_file_ff(curbuf); /* Buffer is unchanged */
#ifdef FEAT_TITLE
! need_maketitle = TRUE;
#endif
#ifdef FEAT_AUTOCMD
modified_was_set = value;
--- 7322,7328
if (!value)
save_file_ff(curbuf); /* Buffer is unchanged */
#ifdef FEAT_TITLE
! redraw_titles();
#endif
#ifdef FEAT_AUTOCMD
modified_was_set = value;
***
*** 7736,7742
newFoldLevel();
}
! /* 'foldminlevel' */
else if (pp == curwin-w_p_fml)
{
foldUpdateAll(curwin);
--- 7757,7763
newFoldLevel();
}
! /* 'foldminlines' */
else if (pp == curwin-w_p_fml)
{
foldUpdateAll(curwin);
*** ../vim-7.2.102/src/version.cThu Feb 5 20:47:14 2009
--- src/version.c Wed Feb 11 11:32:20 2009
***
*** 678,679
--- 678,681
{ /* Add new patch number below this line */
+ /**/
+ 103,
/**/
--
hundred-and-one symptoms of being an internet addict:
73. You give your
Re: vim_extended/vim_mainline git repos independent of svn repo
Markus Heidelberg, 11.02.2009: Christian MICHON, 06.02.2009: you're facing the same problem I faced in July. I noticed (example 7.2.102) the commit message is truncated. so we're even here: I've the same issue and this requires somehow manual intervention. :( James does manual intervention in his Debian repo Oh, crap. He uses the README file from the same directory as the patches. Hmm, good idea. Markus --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Create vimballs from the command-line
On Tue, Feb 10, 2009 at 9:48 PM, Charles E. Campbell, Jr. wrote: Matt Wozniski wrote: But let's not forget that they have significant disadvantages, too... Vimballs made with new versions of the plugin don't work on older vims. There's been one problem with that -- 7.0 vimball doesn't handle the later vimball versions. 7.1 and has been compatible; newer vimballs have largely fixed small problems, not introduced incompatibilities. I could swear an incompatibility was introduced when fnameescape() came along... but that might have just been for using newer versions of the plugin with older vims, not with extracting vimballs made with the newer version on older vims. If so, scratch that point off my list. Vimball was done by request, consequently it didn't have much feedback before it went into 7.0. Considering that those writing and distributing scripts are much more likely to be at the bleeding edge than the users who download those scripts, they're quite likely to wind up distributing something that many of their users can't use. It's also not possible to include binary files in a vimball, or fines with different encodings, or even files with different line endings. I think that I could get vimball to handle binary files, which would mean that zip files could be embedded. However, most plugins don't need binary files (those with icons for signs would be an exception). Or even those that would like to include screenshots, or compiled data files... I don't doubt that vimball could be made to support things like this, I just think it would be more effort than trying to come up with a wrapper around zips that adds the features we need. IMHO, this makes them significantly less useful than zip files, since we could add those 3 nice features (automatic :helptags, extracted to first writable directory, uninstallable) to zip files without having to tolerate the disadvantages that vimball doesn't seem to be able to overcome... Really, it seems that depending on an unzip program being on the computer is far better than implementing our own barely-featured interface-unstable self-extracting-archive-that-wants-to-be-a-zipfile. I think that an effort to nicely encapsulate the platform differences and such of handling zipfiles, or possibly even one day writing a vimscript unzipper, would be a better use of our resources than continuing to maintain vimball. And putting these vim-specific features into zip files would be real popular with the rest of the zip community, I'm sure. At the very least, it'd be bloat for most such users. Then some other applications would want to chime in with their own application specific features. Well, of course I didn't mean that we should add the features to the zip format. Rather, I meant we should do something more like XPI - create a zip file, rename it to .vba, and let vim handle it specially. The change would be transparent to users, and give more useful features to developers, without having to reinvent the wheel. It'd be better to have a plugin that acted as a wrapper around zip to support the additional features that vimball provides. Probably could be a modification to the current zip handling plugin. The same sort of mods could be done with tar and the tar handling plugin, too. I'll consider doing it (after taxes and fafsas). Right. For the near term, supporting unzipping using a pure-vimscript solution isn't terribly likely, but it's definitely possible OOTB in vims built with +python, for example. ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Create vimballs from the command-line
Right. For the near term, supporting unzipping using a pure-vimscript
solution isn't terribly likely, but it's definitely possible OOTB in
vims built with +python, for example.
installing zip-based plugins basically is a matter of
exec '!unzip '. shellescape(expand('%')) .' -d ~/vimfiles'
:helptags ~/vimfiles/doc
IMHO reliance on compiled-in +python support would make things even
more complicate that relying on unzip being installed -- which maybe
could be even shipped with vim? BTW the zip plugin work quite well,
even when using bash under windows.
BTW maybe a vba (zip-based or not) could include some sort of manifest
file that includes not only a file list but also dependencies on other
plugins? These manifests could be saved in, eg, ~/vimfiles/vimballs/
manifests/ and be used for downloading the dependencies and for
removing vimfiles (AFAIK the uninstall info is currently saved in a
single file, which could cause minor conflicts when syncing vimfiles
directories between several computers). Just a thought.
Regards,
Thomas.
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: Create vimballs from the command-line
On Wed, Feb 11, 2009 at 11:06 AM, Tom Link micat...@gmail.com wrote: Right. For the near term, supporting unzipping using a pure-vimscript solution isn't terribly likely, but it's definitely possible OOTB in vims built with +python, for example. IMHO reliance on compiled-in +python support would make things even more complicate that relying on unzip being installed -- which maybe could be even shipped with vim? BTW the zip plugin work quite well, even when using bash under windows. I was suggesting just the opposite - that we shouldn't *rely* on +python, but that if python were available we wouldn't have to rely on an external unzip. Which may or may not be worthwhile - I guess it depends on which supported platforms don't include an 'unzip' (win 9x? Amiga?) and whether most binaries on those platforms have +python (probably not, so the entire exercise might well be pointless). I was just pointing out a possibility that might be worth considering. :-) BTW maybe a vba (zip-based or not) could include some sort of manifest file that includes not only a file list but also dependencies on other plugins? These manifests could be saved in, eg, ~/vimfiles/vimballs/ manifests/ and be used for downloading the dependencies and for removing vimfiles (AFAIK the uninstall info is currently saved in a single file, which could cause minor conflicts when syncing vimfiles directories between several computers). Just a thought. Sounds like a reasonable suggestion to me. ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: help for a git newbie -- no merge candidate found
On Wednesday 11 February 2009 4:00 am, Markus Heidelberg wrote: [...] Maybe you have an old git version installed, where the automatic setup of .git/config for the remote tracking branches (during the command git checkout -b custom origin/vim-with-runtime) was not yet the default. my git reports it is version 1.5.2.4 -- is that old? i It's 1,5 years old, the default mentioned above has changed in 1.5.3 Close aside :) my bad -- i'm behind the curve on linux distros -- my suse 10.2 is several iterations behind current, but it works -- i tried upgrading to 10.3 not long after it came out, and suddenly found myself in conflict hell -- the upgrade timed out and gave up before resolving them all -- i decided to wait til there was a compelling reason to upgrade -- i don't think this is it, although it does sound a death knell for 10.2... my plan is to buy a new harddrive when the time comes, install 11.1 or so as dual boot to skip the conflicts, then copy stuff from one to the other [..] You can do git config --global branch.autosetupmerge true to globally enable it in you ~/.gitconfig instead of only for this repository. ahhh -- an easy solution -- thank you thank you thank you Or you can simply add it by hand: [branch] autosetupmerge = true Of course this is for future creation of custom branches only, it doesn't affect or improve your current setup. is there any reason to believe my current setup isn't wholly fixed? i've now got both [branch custom] remote = origin merge = refs/heads/vim-with-runtime in my .git/config for the vim project, and [branch] autosetupmerge = true in my ~/.gitconfig -- my 'git pull's are politely claiming Already up-to-date., my builds are building, the relnum patch is working gorgeously, birds are singing, and my country finally elected the same guy i voted for Maybe I'll add something like this to the README, but I didn't think such old git versions are still around. if there's a way to mess things up you can generally count on me to find it anyway i'm definitely +1 for the README addition sc --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Patch 7.2.108
Patch 7.2.108 (after 7.2.105)
Problem:Can't build without the diff feature.
Solution: Add #ifdef.
Files: src/option.c
*** ../vim-7.2.107/src/option.c Wed Feb 11 16:45:56 2009
--- src/option.cWed Feb 11 22:21:16 2009
***
*** 4127,4132
--- 4127,4133
errmsg = (char_u *)_(E520: Not allowed in a modeline);
goto skip;
}
+ #ifdef FEAT_DIFF
/* In diff mode some options are overruled. This avoids that
* 'foldmethod' becomes marker instead of diff and that
* wrap gets set. */
***
*** 4134,4139
--- 4135,4141
(options[opt_idx].indir == PV_FDM
|| options[opt_idx].indir == PV_WRAP))
goto skip;
+ #endif
}
#ifdef HAVE_SANDBOX
*** ../vim-7.2.107/src/version.cWed Feb 11 18:46:48 2009
--- src/version.c Wed Feb 11 22:46:40 2009
***
*** 678,679
--- 678,681
{ /* Add new patch number below this line */
+ /**/
+ 108,
/**/
--
hundred-and-one symptoms of being an internet addict:
80. At parties, you introduce your spouse as your service provider.
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
[patch] fixed access to free memory when using some autocommands
Testing autocommands, I see that Vim-7.2.107 (and older) is using memory already freed when doing silly autocommands such as: $ touch foobar $ valgrind ./vim -u NONE -c 'au! BufReadPre * cd /tmp' \ -c 'e foobar' 2 vg.log In vg.log, I then see the following error: ==15058== Syscall param open(filename) points to unaddressable byte(s) ==15058==at 0x40007D2: (within /lib/ld-2.8.90.so) ==15058==by 0x805365E: open_buffer (buffer.c:130) ==15058==by 0x8098548: do_ecmd (ex_cmds.c:3655) ==15058==by 0x80AE8E9: do_exedit (ex_docmd.c:7557) ==15058==by 0x80AE560: ex_edit (ex_docmd.c:7452) ==15058==by 0x80A6FE7: do_one_cmd (ex_docmd.c:2622) ==15058==by 0x80A4867: do_cmdline (ex_docmd.c:1096) ==15058==by 0x80A3F00: do_cmdline_cmd (ex_docmd.c:702) ==15058==by 0x80E8A07: exe_commands (main.c:2693) ==15058==by 0x80E63A7: main (main.c:874) ==15058== Address 0x54312d4 is 4 bytes inside a block of size 11 free'd ==15058==at 0x4024E5A: free (vg_replace_malloc.c:323) ==15058==by 0x8114D5D: vim_free (misc2.c:1631) ==15058==by 0x80C97DF: shorten_fnames (fileio.c:5715) ==15058==by 0x80AF1A9: ex_cd (ex_docmd.c:7942) ==15058==by 0x80A6FE7: do_one_cmd (ex_docmd.c:2622) ==15058==by 0x80A4867: do_cmdline (ex_docmd.c:1096) ==15058==by 0x80CD35A: apply_autocmds_group (fileio.c:8853) ==15058==by 0x80CCD9B: apply_autocmds_exarg (fileio.c:8481) ==15058==by 0x80C2246: readfile (fileio.c:723) ==15058==by 0x805365E: open_buffer (buffer.c:130) ==15058==by 0x8098548: do_ecmd (ex_cmds.c:3655) ==15058==by 0x80AE8E9: do_exedit (ex_docmd.c:7557) The error is actually deeper inside readfile(...) (not sure why valgrind stops the stack trace at open_buffer (buffer.c:130). In readfile(), parameter fname may point to curbuf-b_ffname or curbuf-b_fname before running autocommands (near fileio.c:715). Some autocommands may change curbuf-b_ffname and curbuf-b_fname (freeing and reallocating them) so after executing autommand fname may then point to some invalid memory, and readfile() then uses freed memory when accessing fname. Attached patch fixes the bug by making readfile() fail when that happens. Probably an error should also be reported (see TODO comment in patch). Please review the patch. The same patch also fixes at least another error when doing another silly autocommand: $ touch foobar $ vim -u NONE :set autochdir :au! BufReadPre * e! :e foobar ==12943== Syscall param open(filename) points to unaddressable byte(s) ==12943==at 0x40007D2: (within /lib/ld-2.8.90.so) ==12943==by 0x805368E: open_buffer (buffer.c:130) ==12943==by 0x809856E: do_ecmd (ex_cmds.c:3650) ==12943==by 0x80AE90D: do_exedit (ex_docmd.c:7557) ==12943==by 0x80AE584: ex_edit (ex_docmd.c:7452) ==12943==by 0x80A700B: do_one_cmd (ex_docmd.c:2622) ==12943==by 0x80A488B: do_cmdline (ex_docmd.c:1096) ==12943==by 0x812A4F0: nv_colon (normal.c:5233) ==12943==by 0x8123B74: normal_cmd (normal.c:1200) ==12943==by 0x80E69B9: main_loop (main.c:1180) ==12943==by 0x80E6506: main (main.c:939) ==12943== Address 0x5d69824 is 4 bytes inside a block of size 11 free'd ==12943==at 0x4024E5A: free (vg_replace_malloc.c:323) ==12943==by 0x8114D91: vim_free (misc2.c:1631) ==12943==by 0x80C9803: shorten_fnames (fileio.c:5715) ==12943==by 0x805538B: do_autochdir (buffer.c:1476) ==12943==by 0x8098521: do_ecmd (ex_cmds.c:3631) ==12943==by 0x80AE90D: do_exedit (ex_docmd.c:7557) ==12943==by 0x80AE584: ex_edit (ex_docmd.c:7452) ==12943==by 0x80A700B: do_one_cmd (ex_docmd.c:2622) ==12943==by 0x80A488B: do_cmdline (ex_docmd.c:1096) ==12943==by 0x80CD3A9: apply_autocmds_group (fileio.c:8861) ==12943==by 0x80CCDEA: apply_autocmds_exarg (fileio.c:8489) ==12943==by 0x80C226A: readfile (fileio.c:723) ==12943==by 0x805368E: open_buffer (buffer.c:130) ==12943==by 0x809856E: do_ecmd (ex_cmds.c:3650) ==12943==by 0x80AE90D: do_exedit (ex_docmd.c:7557) ==12943==by 0x80AE584: ex_edit (ex_docmd.c:7452) ==12943==by 0x80A700B: do_one_cmd (ex_docmd.c:2622) ==12943==by 0x80A488B: do_cmdline (ex_docmd.c:1096) ==12943==by 0x812A4F0: nv_colon (normal.c:5233) ==12943==by 0x8123B74: normal_cmd (normal.c:1200) ==12943==by 0x80E69B9: main_loop (main.c:1180) ==12943==by 0x80E6506: main (main.c:939) (and many other errors follow) Regards -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~--- Index: fileio.c === RCS file: /cvsroot/vim/vim7/src/fileio.c,v retrieving revision 1.129 diff -c -r1.129 fileio.c *** fileio.c 31 Dec 2008 15:21:17 - 1.129 --- fileio.c 11 Feb 2009 21:46:59 - *** *** 69,75 static int au_find_group
Bram, you're the best! (Was: Patch 7.2.105)
On 11/02/09 22:54, Tony Mechelynck wrote: On 11/02/09 16:46, Bram Moolenaar wrote: Patch 7.2.105 Problem:Modeline setting for 'foldmethod' overrules diff options. (Ingo Karkat) Solution: Don't set 'foldmethod' and 'wrap' from a modeline when 'diff' is on. Files: src/option.c Error when compiling with tiny features: [...] Wow! The fix (7.2.108) got ready while I was typing the bug report. Bram, you're the best! Best regards, Tony. -- An artist should be fit for the best society and keep out of it. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
'switchbuf' usetab misbehaviour, incorrect title for the location list window
The attached patch fixes the misbehaviour of vim when 'switchbuf' is set
to usetab. Also the location list window is not incorrectly described
as quickfix window any more.
To reproduce the problems perform the following steps:
Create a file file.txt containing the string foo.
Open Vim: vim -p file.txt file.txt file.txt. Execute:
:autocmd TabEnter * call PrintTabNr()
:function! PrintTabNr()
:echomsg Entering tab number . tabpagenr()
:endfunction
:set switchbuf=usetab
:lgrep foo file.txt
:lopen
At this moment observe that the location list window incorrectly has the
title [Quickfix list] instead of [Location list]. Execute:
:wincmd k
:q
Press Enter. Observe that tab 3 becomes the current tab instead of
tab 2. Execute:
:messages
You see:
Entering tab number 2
Entering tab number 3
which means that both tabs were entered.
The reason for this behaviour: macro FOR_ALL_TAB_WINDOWS, which consists
of two nested loops, is used for iterating over each window. When the
correct window is found, a break is performed, which only breaks the
inner loop. Solution: break out of both loops.
--
Cheers,
Lech
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Index: src/buffer.c
===
--- src/buffer.c (revision 1356)
+++ src/buffer.c (working copy)
@@ -5098,7 +5098,8 @@
*/
FOR_ALL_TAB_WINDOWS(tp, win)
if (win-w_buffer == buf)
- break;
+ goto window_found;
+window_found:
if (win != NULL win-w_llist_ref != NULL)
return _([Location List]);
else
Index: src/quickfix.c
===
--- src/quickfix.c (revision 1356)
+++ src/quickfix.c (working copy)
@@ -1610,11 +1610,12 @@
{
goto_tabpage_win(tp, wp);
usable_win = 1;
- break;
+ goto window_found;
}
}
}
+window_found:
/*
* If there is only one window and it is the quickfix window, create a
* new one above the quickfix window.
Index: src/screen.c
===
--- src/screen.c (revision 1356)
+++ src/screen.c (working copy)
@@ -7448,11 +7448,12 @@
{
outofmem = TRUE;
#ifdef FEAT_WINDOWS
- break;
+ goto try_no_more;
#endif
}
}
+try_no_more:
#ifdef FEAT_MBYTE
for (i = 0; i p_mco; ++i)
if (new_ScreenLinesC[i] == NULL)
Re: Create vimballs from the command-line
On 11/02/09 03:48, Charles E. Campbell, Jr. wrote: Matt Wozniski wrote: But let's not forget that they have significant disadvantages, too... Vimballs made with new versions of the plugin don't work on older vims. There's been one problem with that -- 7.0 vimball doesn't handle the later vimball versions. 7.1 and has been compatible; newer vimballs have largely fixed small problems, not introduced incompatibilities. Vimball was done by request, consequently it didn't have much feedback before it went into 7.0. Considering that those writing and distributing scripts are much more likely to be at the bleeding edge than the users who download those scripts, they're quite likely to wind up distributing something that many of their users can't use. It's also not possible to include binary files in a vimball, or fines with different encodings, or even files with different line endings. I think that I could get vimball to handle binary files, which would mean that zip files could be embedded. However, most plugins don't need binary files (those with icons for signs would be an exception). IMHO, this makes them significantly less useful than zip files, since we could add those 3 nice features (automatic :helptags, extracted to first writable directory, uninstallable) to zip files without having to tolerate the disadvantages that vimball doesn't seem to be able to overcome... Really, it seems that depending on an unzip program being on the computer is far better than implementing our own barely-featured interface-unstable self-extracting-archive-that-wants-to-be-a-zipfile. I think that an effort to nicely encapsulate the platform differences and such of handling zipfiles, or possibly even one day writing a vimscript unzipper, would be a better use of our resources than continuing to maintain vimball. And putting these vim-specific features into zip files would be real popular with the rest of the zip community, I'm sure. At the very least, it'd be bloat for most such users. Then some other applications would want to chime in with their own application specific features. It'd be better to have a plugin that acted as a wrapper around zip to support the additional features that vimball provides. Probably could be a modification to the current zip handling plugin. The same sort of mods could be done with tar and the tar handling plugin, too. I'll consider doing it (after taxes and fafsas). Chip And then there are people like me who can un- .zip files if they have to, but prefer to gunzip them (un- .gz), which is the Unix standard (as opposed to the Microsoft Megabucks LoseDough standard). And note that if the right tools are present (gunzip in the $PATH), a compressed vimball (*.vba.gz) will (if I'm not mistaken) be handled by Vim just as easily as an ordinary one. For you poor serfs of Bill Gates, WinZip (for instance) can uncompress .gz files as an easy preliminary step. (Last I checked, it couldn't do .bz2 though.) OTOH I have had encoding compatibility problems in the past but I solved them manually and I don't remember exactly what they were. I think they were related to the fact that my vimrc includes :setglobal fenc=utf-8 bomb for new files and that it sometimes created problems if there already were differently-encoded files in the same directories. As for line-ending format differences, portable scripts can be distributed in only the Unix version (LF-without-CR) since Vim-for-Windows and Vim-for-Mac can edit and source them with no problem unless a nondefault 'fileformats' setting explicitly makes it incompatible with them. People who (like me) don't always want to unpack the vimball into the first tree in 'runtimepath' can always use the :UseVimball command with an explicit path at the command-line rather than by sourcing the vimball. (It often makes sense to unpack a vimball globally into $VIM/vimfiles rather than user-privately into ~/.vim or ~/vimfiles even if one of the latter exists. This is a feature which Dr. Chip added at my suggestion two and a half years ago.) Yes, vimballs, like many Vim features, do take some getting used to (and it took me some time to get used to them); but I believe they are a worthwhile component. Best regards, Tony. -- There was a young whore from Kaloo Who filled her vagina with glue. She said with a grin, If they pay to get in, They can pay to get out again too! --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Create vimballs from the command-line
On 11/02/09 16:23, Matt Wozniski wrote: [...] Well, of course I didn't mean that we should add the features to the zip format. Rather, I meant we should do something more like XPI - create a zip file, rename it to .vba, and let vim handle it specially. The change would be transparent to users, and give more useful features to developers, without having to reinvent the wheel. [...] For backward compatibility, *.vba shouldn't be a zipfile under another name (which .xpi and .jar are, but these extensions were never used for something else before). *.vba.gz (keeping the .vba as-is and compressing them for transport, the way .tar.gz relates to plain .tar) would be easy to implement; if you want something more complicated than this, I believe a new extension would be necessary. Best regards, Tony. -- The correct way to punctuate a sentence that starts: Of course it is none of my business, but -- is to place a period after the word but. Don't use excessive force in supplying such a moron with a period. Cutting his throat is only a momentary pleasure and is bound to get you talked about. -- Lazarus Long, Time Enough for Love --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Create vimballs from the command-line
On 11/02/09 06:42, Tom Link wrote: You can specify the base path with the final arg to MkVimball. If you wanted to create vimballs from cygwin bash by calling Windows gvim (you could of course use cygwin's vim but ...), you'd have to convert the path which works most of the time but can be cumbersome. But thanks for reminding me of that extra argument. Regards, Thomas. IMHO it makes sense to have a non-GUI version of Vim-for-Cygwin and use that under Cygwin bash in preference to native-Windows versions. Or, if your Cygwin Vim is too outdated, you can run native-Windows Vim at the cmd.exe command line. In both cases, I believe (but didn't check) that you could use (for instance, and with the extra argument) vim -u NORC -N -es -c 'MkVimball filelist $VIM/vimfiles' -cq if you didn't want to bother with an interactive Vim session. Best regards, Tony. -- BRIDGEKEEPER: What is your favorite colour? GAWAIN: Blue ... No yelloww! Monty Python and the Holy Grail PYTHON (MONTY) PICTURES LTD --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Create vimballs from the command-line
On 2009-02-12, Tony Mechelynck antoine.mechely...@gmail.com wrote: And then there are people like me who can un- .zip files if they have to, but prefer to gunzip them (un- .gz), which is the Unix standard (as opposed to the Microsoft Megabucks LoseDough standard). And note that if the right tools are present (gunzip in the $PATH), a compressed vimball (*.vba.gz) will (if I'm not mistaken) be handled by Vim just as easily as an ordinary one. Yes, it will, except that when you open the gzipped file with vim someplugin.vba.gz the original file is automatically gunzipped and replaced by the gunzipped version, e.g., somefile.vba. I wish the vimball plugin wouldn't do that. If I'm going to keep the archive around for a while, I'd rather keep it in its gzipped form. Besides, I should be able to use vim to just look at a file without modifying it. Regards, Gary --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Create vimballs from the command-line
On Wed, Feb 11, 2009 at 7:29 PM, Tony Mechelynck wrote: On 11/02/09 16:23, Matt Wozniski wrote: [...] Well, of course I didn't mean that we should add the features to the zip format. Rather, I meant we should do something more like XPI - create a zip file, rename it to .vba, and let vim handle it specially. The change would be transparent to users, and give more useful features to developers, without having to reinvent the wheel. [...] For backward compatibility, *.vba shouldn't be a zipfile under another name (which .xpi and .jar are, but these extensions were never used for something else before). *.vba.gz (keeping the .vba as-is and compressing them for transport, the way .tar.gz relates to plain .tar) would be easy to implement; if you want something more complicated than this, I believe a new extension would be necessary. Yes, I realized that after sending that email off - I was thinking about it providing backwards compatibility in the sense that the install process for a zip-based vimball and a vimscript-based vimball could be made largely the same, but at the time of writing it didn't even occur to me that the old vimball install scripts would mangle it. Oops. ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Create vimballs from the command-line
Gary Johnson wrote: On 2009-02-12, Tony Mechelynck antoine.mechely...@gmail.com wrote: And then there are people like me who can un- .zip files if they have to, but prefer to gunzip them (un- .gz), which is the Unix standard (as opposed to the Microsoft Megabucks LoseDough standard). And note that if the right tools are present (gunzip in the $PATH), a compressed vimball (*.vba.gz) will (if I'm not mistaken) be handled by Vim just as easily as an ordinary one. Yes, it will, except that when you open the gzipped file with vim someplugin.vba.gz the original file is automatically gunzipped and replaced by the gunzipped version, e.g., somefile.vba. I wish the vimball plugin wouldn't do that. If I'm going to keep the archive around for a while, I'd rather keep it in its gzipped form. Besides, I should be able to use vim to just look at a file without modifying it. The reason why it does that: one can't source a buffer, and one can't source a compressed file. Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Create vimballs from the command-line
On 12/02/09 02:07, Gary Johnson wrote: On 2009-02-12, Tony Mechelynckantoine.mechely...@gmail.com wrote: And then there are people like me who can un- .zip files if they have to, but prefer to gunzip them (un- .gz), which is the Unix standard (as opposed to the Microsoft Megabucks LoseDough standard). And note that if the right tools are present (gunzip in the $PATH), a compressed vimball (*.vba.gz) will (if I'm not mistaken) be handled by Vim just as easily as an ordinary one. Yes, it will, except that when you open the gzipped file with vim someplugin.vba.gz the original file is automatically gunzipped and replaced by the gunzipped version, e.g., somefile.vba. I wish the vimball plugin wouldn't do that. If I'm going to keep the archive around for a while, I'd rather keep it in its gzipped form. Besides, I should be able to use vim to just look at a file without modifying it. Regards, Gary That's how gunzip normally works. You can keep the compressed file by doing gunzip -c somefile.vba.gz somefile.vba or gunzip -c somefile.vba.gz | view - which uncompresses to stdout (hence the redirection) and keeps the *.gz. (You may have a script or softlink named zcat or gzcat which is equivalent to gunzip -c). Best regards, Tony. -- The Right Honorable Gentleman is indebted to his memory for his jests and to his imagination for his facts. -- Sheridan --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: vim_extended/vim_mainline git repos independent of svn repo
On 11/02/09 03:35, Markus Heidelberg wrote: James Vega, 06.02.2009: On Thu, Feb 05, 2009 at 10:23:33PM +0100, Markus Heidelberg wrote: What do you think about the commit message format, is it ok? I searched for a git-like message, without losing information. The duplicated first line of the problem description is unavoidable I think, because it should be fully automated and the first line shouldn't merely contain the patch number. Using 7.2.093 as an example, here's what I use for the upstream branch of the Debian repo: [7.2.093] (extra) dialogs can't always handle multi-byte text I decided to discard the (extra) or (after 7.2.xxx) comments in the summary. But to not lose information, I put this Patch 7.2.093 (extra) at the last line. This isn't very nice, but the summary line will stay below 80 chars with the automated extraction of the complete first Problem line. But why this extra and the distinction between Unix and non-Unix at all? Markus Because if you are on a Unix-like OS, you can get a functional Vim by omitting everything that's not for Unix, including downloading the extra.tar.gz archive. Currently the source is divided among 3 archives: ftp://ftp.vim.org/pub/vim/unix/vim-7.2.tar.bz2 ftp://ftp.vim.org/pub/vim/extra/vim-7.2.extra.tar.gz ftp://ftp.vim.org/pub/vim/extra/vim-7.2.lang.tar.gz All three together contain exactly one copy of every 7.2.0 source file, and that's what I recommend downloading regardless of platform, if you want to download Vim and keep it up via ftp (as I do). But IIUC you can omit the extra archive on Unix (if, maybe, you don't use out-of-the-way rarely-used features) (and the lang archive if you want only a strictly en-US version). In that case, extra patches would be for files you haven't downloaded. IIUC that's what the RedHat developers do, and that's why the Vim builds they distribute show a number of missing numbers in the Included patches line of their :version output. Best regards, Tony. -- I think every good Christian ought to kick Falwell right in the ass. -- Barry Goldwater --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
