ZyX wrote:

> Added undo_indent and cpo saving/setting

Thanks.  For me it's a bit easier if you send the whole file instead of
a patch.

--
hundred-and-one symptoms of being an internet addict:
105. When someone asks you for your address, you tell them your URL.

  /// Bram Moolenaar -- Bram@... -- 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_dev" 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

Sergey -

I have build Vim with MzScheme on Ubuntu 12.10.  Every time a shell
command is executed I get this warning message:

    SIGCHLD handler called (some thread has SIGCHLD unblocked)

Can this be avoided?

- Bram

--
hundred-and-one symptoms of being an internet addict:
104. When people ask about the Presidential Election you ask "Which country?"

  /// Bram Moolenaar -- Bram@... -- 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_dev" 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

Patch 7.3.752
Problem:    Test 49 script file doesn't fold properly.
Solution:   Add a colon.
Files:     src/testdir/test49.vim


*** ../vim-7.3.751/src/testdir/test49.vim 2012-11-14 22:38:04.000000000 +0100
--- src/testdir/test49.vim 2012-11-23 22:08:37.000000000 +0100
***************
*** 1,6 ****
   " Vim script language tests
   " Author: Servatius Brandt <Servatius.Brandt@...>
! " Last Change: 2010 Sep 29

  
"-------------------------------------------------------------------------------
   " Test environment 						    {{{1
--- 1,6 ----
   " Vim script language tests
   " Author: Servatius Brandt <Servatius.Brandt@...>
! " Last Change: 2012 Nov 23

  
"-------------------------------------------------------------------------------
   " Test environment 						    {{{1
***************
*** 9604,9610 ****
   Xcheck 198689

  
"-------------------------------------------------------------------------------
! " Test 86   setloclist crash 					    {{{1
   "
   "     Executing a setloclist() on BufUnload shouldn't crash Vim
  
"-------------------------------------------------------------------------------
--- 9604,9610 ----
   Xcheck 198689

  
"-------------------------------------------------------------------------------
! " Test 86:  setloclist crash 					    {{{1
   "
   "     Executing a setloclist() on BufUnload shouldn't crash Vim
  
"-------------------------------------------------------------------------------
*** ../vim-7.3.751/src/version.c 2012-12-05 18:21:28.000000000 +0100
--- src/version.c 2012-12-05 18:59:50.000000000 +0100
***************
*** 727,728 ****
--- 727,730 ----
   {   /* Add new patch number below this line */
+ /**/
+     752,
   /**/

--
hundred-and-one symptoms of being an internet addict:
106. When told to "go to your room" you inform your parents that you
      can't...because you were kicked out and banned.

  /// Bram Moolenaar -- Bram@... -- 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_dev" 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

I'm a bit stuck on how synID* should work in this context.

The problem is that synID() returns the id of the *highlight group*, not the
syntax match. In the following example:

     syntax match Foo 'foo' combine
     syntax match Bar 'bar'
     highlight link Foo Comment
     highlight link Bar Comment

if you have the highlight id for 'Comment', I can't reliably tell you whether or
not it's going to combine with attributes further up the stack.

The best I can think to do is one of:

     1. Add synmatchID() and synmatchIDattr()
     2. Add syncombines(line, col) which tells you if you also need to consult
the rest of the synstack() for attributes.

Honestly I think that these functions are a bit misnamed and would prefer them
to be 'hlID', 'hlIDattr', hlIDtrans', 'synID', 'synIDattr', and 'synIDtrans'
(the *trans functions always returning lists), but that's backwards
compatibility breaking.

Does anyone have preference where we go? I don't have the experience with synID*
to choose the 'right' decision.

--
You received this message from the "vim_dev" 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

> Thanks.  For me it's a bit easier if you send the whole file instead of
a patch.

https://bitbucket.org/ZyX_I/vim/raw/262f483812f8f7c5a0e6c9a43cd1967782b7b9ed/run\
time/indent/yaml.vim

Google groups interface for some reason does not like �.vim� extension.

--
You received this message from the "vim_dev" 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

Patch 7.3.753
Problem:    When there is a QuitPre autocommand using ":q" twice does not work
	     for exiting when there are more files to edit.
Solution:   Do not decrement quitmore in an autocommand. (Techlive Zheng)
Files:     src/ex_docmd.c, src/fileio.c, src/proto/fileio.pro


*** ../vim-7.3.752/src/ex_docmd.c 2012-11-28 23:03:02.000000000 +0100
--- src/ex_docmd.c 2012-12-05 19:07:01.000000000 +0100
***************
*** 1729,1739 ****
       ++ex_nesting_level;
   #endif

!  /* when not editing the last file :q has to be typed twice */
       if (quitmore
   #ifdef FEAT_EVAL
  	     /* avoid that a function call in 'statusline' does this */
  	     && !getline_equal(fgetline, cookie, get_func_line)
   #endif
  	     )
  	 --quitmore;
--- 1729,1741 ----
       ++ex_nesting_level;
   #endif

!     /* When the last file has not been edited :q has to be typed twice. */
       if (quitmore
   #ifdef FEAT_EVAL
  	     /* avoid that a function call in 'statusline' does this */
  	     && !getline_equal(fgetline, cookie, get_func_line)
+ 	    /* avoid that an autocommand, e.g. QuitPre, does this */
+ 	    && !getline_equal(fgetline, cookie, getnextac)
   #endif
  	     )
  	 --quitmore;
*** ../vim-7.3.752/src/fileio.c 2012-08-29 18:50:50.000000000 +0200
--- src/fileio.c 2012-12-05 19:08:17.000000000 +0100
***************
*** 7774,7780 ****
   static int event_ignored __ARGS((event_T event));
   static int au_get_grouparg __ARGS((char_u **argp));
   static int do_autocmd_event __ARGS((event_T event, char_u *pat, int nested,
char_u *cmd, int forceit, int group));
- static char_u *getnextac __ARGS((int c, void *cookie, int indent));
   static int apply_autocmds_group __ARGS((event_T event, char_u *fname, char_u
*fname_io, int force, int group, buf_T *buf, exarg_T *eap));
   static void auto_next_pat __ARGS((AutoPatCmd *apc, int stop_at_last));

--- 7774,7779 ----
***************
*** 9613,9619 ****
    * Called by do_cmdline() to get the next line for ":if".
    * Returns allocated string, or NULL for end of autocommands.
    */
!     static char_u *
   getnextac(c, cookie, indent)
       int     c UNUSED;
       void    *cookie;
--- 9612,9618 ----
    * Called by do_cmdline() to get the next line for ":if".
    * Returns allocated string, or NULL for end of autocommands.
    */
!     char_u *
   getnextac(c, cookie, indent)
       int     c UNUSED;
       void    *cookie;
*** ../vim-7.3.752/src/proto/fileio.pro 2012-02-29 18:22:03.000000000 +0100
--- src/proto/fileio.pro 2012-12-05 19:08:24.000000000 +0100
***************
*** 47,52 ****
--- 47,53 ----
   int has_insertcharpre __ARGS((void));
   void block_autocmds __ARGS((void));
   void unblock_autocmds __ARGS((void));
+ char_u *getnextac __ARGS((int c, void *cookie, int indent));
   int has_autocmd __ARGS((event_T event, char_u *sfname, buf_T *buf));
   char_u *get_augroup_name __ARGS((expand_T *xp, int idx));
   char_u *set_context_in_autocmd __ARGS((expand_T *xp, char_u *arg, int
doautocmd));
*** ../vim-7.3.752/src/version.c 2012-12-05 19:00:03.000000000 +0100
--- src/version.c 2012-12-05 19:08:34.000000000 +0100
***************
*** 727,728 ****
--- 727,730 ----
   {   /* Add new patch number below this line */
+ /**/
+     753,
   /**/

--
Laughing helps. It's like jogging on the inside.

  /// Bram Moolenaar -- Bram@... -- 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_dev" 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

Ken Takata wrote:

> Hi,
>
> 2012/06/03 Sun 22:38:35 UTC+9 Ken Takata:
>> Hi Bram and  Dominique,
>>
>> > So please hold this patch until the Tab behavior is changed.  Then we at
>> > least know what to change.
>>
>> OK, I will wait the change of the Tab behavior.
>> If I found misalignments after the change, I will send a new patch.
>>
>> E.g. +feature-list (various.txt) isn't aligned when either cole=0 nor cole=2.
>
> I think it's ready to update my patch because the Tab behavior is
> changed in 7.3.748.
> Here is an updated patch.
>
> Best regards,
> Ken Takata

Thanks.  There might still be a few places in help files where
things are misaligned even after patch 7.3.748. But the problem
is not in conceal code any more and it's also rare. It now only
happens because a few help files mix spaces and tabs
inconsistently causing misalignments with conceallevel=3
vs conceallevel=0.

Attached patch fixes such a misalignment in ":help help".

Regards
-- Dominique

--
You received this message from the "vim_dev" 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

Hello all,

Attached is a small change to support the newest NMAKE introduced by Visual
Studio 2012 Update 1. I have tested it and VIM seems to compile fine.

--
You received this message from the "vim_dev" 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

On Wednesday, December 5, 2012 12:03:31 PM UTC-6, So8res wrote:
> I'm a bit stuck on how synID* should work in this context.
>
> The problem is that synID() returns the id of the *highlight group*, not the
syntax match. In the following example:
>
>     syntax match Foo 'foo' combine
>     syntax match Bar 'bar'
>     highlight link Foo Comment
>     highlight link Bar Comment
>
> if you have the highlight id for 'Comment', I can't reliably tell you whether
or not it's going to combine with attributes further up the stack.
>

I don't understand. synIDattr(synID(...),"name") on foo returns "Foo".
synIDattr(synIDtrans(synID(...)),"name") on foo returns "Comment". Can't we just
add something like synIDattr(synID(...),"combine") which returns true/false?
Determining the highlight would then be a matter of going up the syntax stack
until a non-combining item is found, then walking back up the stack getting the
attributes for the translated syntax ID of each item.

That said, doing all that in vimscript would probably be quite inefficient. The
TOHtml implementation even has a comment on the loop that finds all characters
in a particular highlight group, that the loop needs to be kept small. A
traversal up and down the syntax stack for every character in the document would
be a very bad thing. Doing the same thing for every entire highlighted item
found would also probably not be very good. So I think we want a new set of
functions to help out.

> The best I can think to do is one of:
>
>     1. Add synmatchID() and synmatchIDattr()

What would these do?

>     2. Add syncombines(line, col) which tells you if you also need to consult
the rest of the synstack() for attributes.
>

This could work but would likewise affect the performance of a tight inner loop
requiring "if" logic and a vimscript stack traversal on each character.

Syntax highlighting internally uses a unique number for each individually
highlighted item. What if we add a function to return this number
(synconcealed() already returns it as one item in a list for different reasons),
and another function to get a list of syntax IDs which apply to an item's
highlighting (in order of application), given this item number?

--
You received this message from the "vim_dev" 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

I use vim-gtk 7.3.429-2ubuntu2.1 on ubuntu 12.04. The docs for shellslash state
that it's only defined only for MSDOS, MS-Windows and OS/2. In vim-gtk,

     echo exists('&shellslash')

prints 1. And the value of &shellslash is 0.

I'd expect the option to be either undefined (that's my understanding of the
doc) or maybe that the value is 1 since bash uses slashes and not backslashes
(but I guess I'm missing something here).

Regards

--
You received this message from the "vim_dev" 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

On 05/12/12 22:13, lith wrote:
> I use vim-gtk 7.3.429-2ubuntu2.1 on ubuntu 12.04. The docs for shellslash
state that it's only defined only for MSDOS, MS-Windows and OS/2. In vim-gtk,
>
>      echo exists('&shellslash')
>
> prints 1. And the value of &shellslash is 0.
>
> I'd expect the option to be either undefined (that's my understanding of the
doc) or maybe that the value is 1 since bash uses slashes and not backslashes
(but I guess I'm missing something here).
>
> Regards
>

exists('&shellslash') tests only if that option has been defined in the
source no later than the code you're currently using. To test if the
option is supported (i.e. working) in the current Vim build, you should use

	 :echo exists('+shellslash')

instead. This will return 0 on Linux. Similarly,

	 :echo &ssl

returns 0, but

	 :set ssl?

returns

	 E519: Option not supported: ssl?

The difference between exists('&option') and exists('+option') is
mentioned (albeit rather summarily) under

	 :help exists()


To test, in a script, whether 'shellslash' is both supported and set,
you should use

	 :if exists('+ssl') && &ssl

Short-circuit evaluation will in this case make sure that the value of
'shellslash' is only tested if the option is supported.


Best regards,
Tony.
--
Join the march to save individuality!

--
You received this message from the "vim_dev" 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

Hi!

On Tue, Dec 04, 2012 at 08:29:39AM -0800, Ben Fritz wrote:
> Maybe just match the \\\n sequences as a separate syntax item and use
> nextgroup to enforce ordering. It should work (probably even a little
> bit faster) and also simplify your pattern.

As far as I understood, nextgroup is just a recommendation, while I've
tried to implement more strict syntax checking "after that item can be
only this one, and after this there can be only one of these items, etc.".
Maybe I'm wrong in trying to go this way, because it's syntax highlighter,
not real parser/compiler, it may be a little relaxed�

--
			 WBR, Alex.

--
You received this message from the "vim_dev" 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

On Wednesday, December 5, 2012 9:37:26 PM UTC-6, Alex Efros wrote:
> Hi!
>
>
>
> On Tue, Dec 04, 2012 at 08:29:39AM -0800, Ben Fritz wrote:
>
> > Maybe just match the \\\n sequences as a separate syntax item and use
>
> > nextgroup to enforce ordering. It should work (probably even a little
>
> > bit faster) and also simplify your pattern.
>
>
>
> As far as I understood, nextgroup is just a recommendation, while I've
>
> tried to implement more strict syntax checking "after that item can be
>
> only this one, and after this there can be only one of these items, etc.".
>
> Maybe I'm wrong in trying to go this way, because it's syntax highlighter,
>
> not real parser/compiler, it may be a little relaxed�
>

You already know from the mkfileVarAttr match that the pattern you are looking
for matches strictly. Now you just need to match the components of it which can
be done more lazily since you know it's there.

--
You received this message from the "vim_dev" 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

Oops, sorry, I was misunderstanding how synID* worked.

I've updated the patch to add the "combine" {what} to synIDattr, which is the
bare minimum we need here.

synID should definitely return only one ID in this case, both because we don't
want to duplicate synstack and because it's the only way to get interoperability
with the extended links patch.

I'm still not sure how best to deal with synIDattr. How would you feel about
adding a [, {flatten}] argument to it that flattens out the stack before
checking the attr (analagous to [, {trans}] in synID)?

--
You received this message from the "vim_dev" 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 should use
>
>  :echo exists('+shellslash')

Ah, I see. Thanks a lot.

Regards,
Tom

--
You received this message from the "vim_dev" 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

On Wednesday, December 5, 2012 10:47:42 PM UTC-6, So8res wrote:
> Oops, sorry, I was misunderstanding how synID* worked.
>
> I've updated the patch to add the "combine" {what} to synIDattr, which is the
bare minimum we need here.
>
> synID should definitely return only one ID in this case, both because we don't
want to duplicate synstack and because it's the only way to get interoperability
with the extended links patch.
>
> I'm still not sure how best to deal with synIDattr. How would you feel about
adding a [, {flatten}] argument to it that flattens out the stack before
checking the attr (analagous to [, {trans}] in synID)?

I like that idea, but in order for it to work it would need a row+col because
the attributes for combined items depend on what they are combined with which
depends on where in the document you are.

So I guess I could get the attrs flattened always at a particular row and
column, then if the "combine" item shows that at least one item in the flattened
view is a combining syntax item, look at the syntax stack for the names used.

The problem I see is in detecting two regions side-by-side with the same
top-level (combining) syntax item but different underlying syntax stacks which
therefore need different highlighting. I'd like to do this without checking the
entire stack for every character in the document which I believe will be much
slower than otherwise. I suppose I could keep a list of synIDs which combine and
only check the stack for those but I'd still like a faster method.

--
You received this message from the "vim_dev" 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

Ben Fritz wrote:
> On Wednesday, December 5, 2012 10:47:42 PM UTC-6, So8res wrote:
>> Oops, sorry, I was misunderstanding how synID* worked.
>>
>> I've updated the patch to add the "combine" {what} to synIDattr, which is the
bare minimum we need here.
>>
>> synID should definitely return only one ID in this case, both because we
don't want to duplicate synstack and because it's the only way to get
interoperability with the extended links patch.
>>
>> I'm still not sure how best to deal with synIDattr. How would you feel about
adding a [, {flatten}] argument to it that flattens out the stack before
checking the attr (analagous to [, {trans}] in synID)?
> I like that idea, but in order for it to work it would need a row+col because
the attributes for combined items depend on what they are combined with which
depends on where in the document you are.
>
> So I guess I could get the attrs flattened always at a particular row and
column, then if the "combine" item shows that at least one item in the flattened
view is a combining syntax item, look at the syntax stack for the names used.
>
> The problem I see is in detecting two regions side-by-side with the same
top-level (combining) syntax item but different underlying syntax stacks which
therefore need different highlighting. I'd like to do this without checking the
entire stack for every character in the document which I believe will be much
slower than otherwise. I suppose I could keep a list of synIDs which combine and
only check the stack for those but I'd still like a faster method.
>
I just am letting you know that I'm interested in this modification, too.

I have two plugins (hilinks.vim, which allows one to see which syntax
and highlighting group(s) are active under the cursor; and synchk.vim,
which is a personal plugin which compares syntax highlighting
correctness (converts syntax highlighting IDs for various test files
into line-by-line hashed codes using
synIDattr(synID(line("."),col("."),1),"name"); I can compare proposed
changes to syntax highlighting plugins with the previous highlighting of
the test files, thereby permitting some automated syntax highlight
checking)).  Obviously, if synID* will be returning lists, I may need to
change these plugins to accommodate that.

I see other users of synID* : SrchRplcHiGrp.vim (David Fishburn),
foldutil.vim (Hari Krishna Dara), 2tex.vim (Francois Rigault), in my own
files.  I'm certain that there are many more plugins on vim.sf.net that
may be affected.

I think that perhaps [,{flatten}] should be the default, and
[,{expanded}] give out the list.

Regards,
Chip Campbell

--
You received this message from the "vim_dev" 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

Hi Raymond,

On Wednesday, December 5, 2012 2:01:26 PM UTC-5, Raymond Ko wrote:
> Hello all,
>
> Attached is a small change to support the newest NMAKE introduced by Visual
Studio 2012 Update 1. I have tested it and VIM seems to compile fine.


I updated visual studio yesterday and temporarily added MSVCVER=11.0 in the
command line in order to be able to compile, would have worked with this patch.

How about Win32.Mak? Does compiling vim work without copying this file to the
vim source dir? In my case I had to go to the old visual studio 2010 folder and
copy that file, because somehow it wasn't present when I installed visual studio
2012 (ultimate).

Thanks!

--
You received this message from the "vim_dev" 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

On Thursday, December 6, 2012 10:35:34 AM UTC-5, skeept wrote:
> Hi Raymond,
>
> On Wednesday, December 5, 2012 2:01:26 PM UTC-5, Raymond Ko wrote:
> > Hello all,
> >
> > Attached is a small change to support the newest NMAKE introduced by Visual
Studio 2012 Update 1. I have tested it and VIM seems to compile fine.
>
>
> I updated visual studio yesterday and temporarily added MSVCVER=11.0 in the
command line in order to be able to compile, would have worked with this patch.
>
> How about Win32.Mak? Does compiling vim work without copying this file to the
vim source dir? In my case I had to go to the old visual studio 2010 folder and
copy that file, because somehow it wasn't present when I installed visual studio
2012 (ultimate).
>
> Thanks!

I had encountered the same problem before, and the solution adopted in 7.3.666
is mentioned (which is somewhat hidden I must admit) in Make_mvc.mak line 18,
which is to set an SDK_INCLUDE_DIR variable, such as:

SDK_INCLUDE_DIR="C:\Program Files\Microsoft SDKs\Windows\v7.1\Include"

for 64 bit. So I don't forget, I use a batch file to compile:
https://bitbucket.org/rko/vim/src/5e5285bfe982bfc5dbf5dce3a3541b0d3b8f22e7/src/_\
msvc.bat?at=default

I wonder why Microsoft didn't do this somewhere by default. Maybe to push Metro
;-) ?

--
You received this message from the "vim_dev" 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

Raymond Ko wrote:

> Attached is a small change to support the newest NMAKE introduced by
> Visual Studio 2012 Update 1. I have tested it and VIM seems to compile
> fine.

I'll include it, thanks.

--
Amnesia is one of my favorite words, but I forgot what it means.

  /// Bram Moolenaar -- Bram@... -- 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_dev" 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

Patch 7.3.754
Problem:    Latest nmake is not recognized.
Solution:   Add nmake version 11.00.51106.1. (Raymond Ko)
Files:     src/Make_mvc.mak


*** ../vim-7.3.753/src/Make_mvc.mak 2012-10-23 05:35:30.000000000 +0200
--- src/Make_mvc.mak 2012-12-06 21:27:56.000000000 +0100
***************
*** 413,418 ****
--- 413,421 ----
   !if "$(_NMAKE_VER)" == "11.00.50727.1"
   MSVCVER = 11.0
   !endif
+ !if "$(_NMAKE_VER)" == "11.00.51106.1"
+ MSVCVER = 11.0
+ !endif
   !endif

   # Abort bulding VIM if version of VC is unrecognised.
*** ../vim-7.3.753/src/version.c 2012-12-05 19:13:11.000000000 +0100
--- src/version.c 2012-12-06 21:29:12.000000000 +0100
***************
*** 727,728 ****
--- 727,730 ----
   {   /* Add new patch number below this line */
+ /**/
+     754,
   /**/

--
hundred-and-one symptoms of being an internet addict:
116. You are living with your boyfriend who networks your respective
      computers so you can sit in separate rooms and email each other

  /// Bram Moolenaar -- Bram@... -- 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_dev" 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

Dominique Pelle wrote:

> Ken Takata wrote:
>
> > Hi,
> >
> > 2012/06/03 Sun 22:38:35 UTC+9 Ken Takata:
> >> Hi Bram and  Dominique,
> >>
> >> > So please hold this patch until the Tab behavior is changed.  Then we at
> >> > least know what to change.
> >>
> >> OK, I will wait the change of the Tab behavior.
> >> If I found misalignments after the change, I will send a new patch.
> >>
> >> E.g. +feature-list (various.txt) isn't aligned when either cole=0 nor
cole=2.
> >
> > I think it's ready to update my patch because the Tab behavior is
> > changed in 7.3.748.
> > Here is an updated patch.
> >
> > Best regards,
> > Ken Takata
>
> Thanks.  There might still be a few places in help files where
> things are misaligned even after patch 7.3.748. But the problem
> is not in conceal code any more and it's also rare. It now only
> happens because a few help files mix spaces and tabs
> inconsistently causing misalignments with conceallevel=3
> vs conceallevel=0.
>
> Attached patch fixes such a misalignment in ":help help".

Thanks, I'll include it

--
FIXME and XXX are two common keywords used to mark broken or incomplete code
not only since XXX as a sex reference would grab everybody's attention but
simply due to the fact that Vim would highlight these words.
					 -- Hendrik Scholz

  /// Bram Moolenaar -- Bram@... -- 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_dev" 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

Sorry to bother the list with this: I have a couple of people for who I
no longer have a valid address or email, and I need to get in touch with
them.  I assume they are Vim users, that's why I am trying the Vim
maillist.

	 Daniel Hofmann (was in Bielefeld)
	 Daniel Geh (was in Aalen)

I would like these persons to contact me.

- Bram

--
Support your right to bare arms!  Wear short sleeves!

  /// Bram Moolenaar -- Bram@... -- 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_dev" 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

synID now returns a list.
synIDattr now takes a list.

They both still handle the single-id case, but the code's a bit messy and the
name is stale. I think we should add synActive and synActiveAttr, which
take/return lists instead of single numbers, and then deprecate synID*.

--
You received this message from the "vim_dev" 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

On Wed, December 5, 2012 15:17, Bram Moolenaar wrote:
> Patch 7.3.746
[�]
> + 	 /* Somehow qf_count may have an incorrect value, set it to 1
> + 		 * to avoid crashing when it's wrong.
> + 		 * TODO: Avoid qf_count being incorrect. */
> + 	 qi->qf_lists[idx].qf_count = 1;

I finally found the root cause of having qf_count being wrong.

The vimgrep doesn't expect, that the quickfix list changes between
loading files and uses qf_add_entry() to add entries, which happily
increments qf_count of the wrong curlist, while the actual entries
will always be attached at the correct position to which prevp points
to.

I think, this patch prevents it, by checking that qi->curlist is
always the one, vimgrep expects. But please check. I am not entirely
sure this works correctly in all situations, but at least my tests
have all been successful so far (valgrind did not report errors, the
test suite runs as expected and the crashes are avoided)

regards,
Christian

--
You received this message from the "vim_dev" 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

在 2012年12月6日星期四UTC+8上午2时13分35秒，Bram Moolenaar写道：
> Patch 7.3.753
>
> Problem:    When there is a QuitPre autocommand using ":q" twice does not work
>
> 	    for exiting when there are more files to edit.
>
> Solution:   Do not decrement quitmore in an autocommand. (Techlive Zheng)
>
> Files:     src/ex_docmd.c, src/fileio.c, src/proto/fileio.pro
>
>
>
>
>
> *** ../vim-7.3.752/src/ex_docmd.c 2012-11-28 23:03:02.000000000 +0100
>
> --- src/ex_docmd.c 2012-12-05 19:07:01.000000000 +0100
>
> ***************
>
> *** 1729,1739 ****
>
>       ++ex_nesting_level;
>
>   #endif
>
>
>
> !  /* when not editing the last file :q has to be typed twice */
>
>       if (quitmore
>
>   #ifdef FEAT_EVAL
>
>   	    /* avoid that a function call in 'statusline' does this */
>
>   	    && !getline_equal(fgetline, cookie, get_func_line)
>
>   #endif
>
>   	    )
>
>    --quitmore;
>
> --- 1729,1741 ----
>
>       ++ex_nesting_level;
>
>   #endif
>
>
>
> !     /* When the last file has not been edited :q has to be typed twice. */
>
>       if (quitmore
>
>   #ifdef FEAT_EVAL
>
>   	    /* avoid that a function call in 'statusline' does this */
>
>   	    && !getline_equal(fgetline, cookie, get_func_line)
>
> + 	    /* avoid that an autocommand, e.g. QuitPre, does this */
>
> + 	    && !getline_equal(fgetline, cookie, getnextac)
>
>   #endif
>
>   	    )
>
>    --quitmore;
>
> *** ../vim-7.3.752/src/fileio.c 2012-08-29 18:50:50.000000000 +0200
>
> --- src/fileio.c 2012-12-05 19:08:17.000000000 +0100
>
> ***************
>
> *** 7774,7780 ****
>
>   static int event_ignored __ARGS((event_T event));
>
>   static int au_get_grouparg __ARGS((char_u **argp));
>
>   static int do_autocmd_event __ARGS((event_T event, char_u *pat, int nested,
char_u *cmd, int forceit, int group));
>
> - static char_u *getnextac __ARGS((int c, void *cookie, int indent));
>
>   static int apply_autocmds_group __ARGS((event_T event, char_u *fname, char_u
*fname_io, int force, int group, buf_T *buf, exarg_T *eap));
>
>   static void auto_next_pat __ARGS((AutoPatCmd *apc, int stop_at_last));
>
>
>
> --- 7774,7779 ----
>
> ***************
>
> *** 9613,9619 ****
>
>    * Called by do_cmdline() to get the next line for ":if".
>
>    * Returns allocated string, or NULL for end of autocommands.
>
>    */
>
> !     static char_u *
>
>   getnextac(c, cookie, indent)
>
>       int     c UNUSED;
>
>       void    *cookie;
>
> --- 9612,9618 ----
>
>    * Called by do_cmdline() to get the next line for ":if".
>
>    * Returns allocated string, or NULL for end of autocommands.
>
>    */
>
> !     char_u *
>
>   getnextac(c, cookie, indent)
>
>       int     c UNUSED;
>
>       void    *cookie;
>
> *** ../vim-7.3.752/src/proto/fileio.pro 2012-02-29 18:22:03.000000000 +0100
>
> --- src/proto/fileio.pro 2012-12-05 19:08:24.000000000 +0100
>
> ***************
>
> *** 47,52 ****
>
> --- 47,53 ----
>
>   int has_insertcharpre __ARGS((void));
>
>   void block_autocmds __ARGS((void));
>
>   void unblock_autocmds __ARGS((void));
>
> + char_u *getnextac __ARGS((int c, void *cookie, int indent));
>
>   int has_autocmd __ARGS((event_T event, char_u *sfname, buf_T *buf));
>
>   char_u *get_augroup_name __ARGS((expand_T *xp, int idx));
>
>   char_u *set_context_in_autocmd __ARGS((expand_T *xp, char_u *arg, int
doautocmd));
>
> *** ../vim-7.3.752/src/version.c 2012-12-05 19:00:03.000000000 +0100
>
> --- src/version.c 2012-12-05 19:08:34.000000000 +0100
>
> ***************
>
> *** 727,728 ****
>
> --- 727,730 ----
>
>   {   /* Add new patch number below this line */
>
> + /**/
>
> +     753,
>
>   /**/
>
>
>
> --
>
> Laughing helps. It's like jogging on the inside.
>
>
>
>  /// Bram Moolenaar -- Bram@... -- 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    ///

This is great.

--
You received this message from the "vim_dev" 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

On 2012-12-07, Techlive Zheng wrote:
> 在 2012年12月6日星期四UTC+8上午2时13分35秒，Bram
Moolenaar写道：
> > Patch 7.3.753
> > Problem:    When there is a QuitPre autocommand using ":q" twice does not
work
> > 	    for exiting when there are more files to edit.
> > Solution:   Do not decrement quitmore in an autocommand. (Techlive Zheng)
> > Files:     src/ex_docmd.c, src/fileio.c, src/proto/fileio.pro

[179 lines of patch deleted]

> This is great.

I'm glad the patch helps you and I'm sure Bram appreciates the
acknowledgement.  But, would you and others please not include the
entire text of a patch in such replies unless you are commenting on
specific parts of the patch?

Regards,
Gary

--
You received this message from the "vim_dev" 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

2012/12/8 Gary Johnson <garyjohn@...>:
> On 2012-12-07, Techlive Zheng wrote:
>> 在 2012年12月6日星期四UTC+8上午2时13分35秒，Bram
Moolenaar写道：
>> > Patch 7.3.753
>> > Problem:    When there is a QuitPre autocommand using ":q" twice does not
work
>> >         for exiting when there are more files to edit.
>> > Solution:   Do not decrement quitmore in an autocommand. (Techlive Zheng)
>> > Files:          src/ex_docmd.c, src/fileio.c, src/proto/fileio.pro
>
> [179 lines of patch deleted]
>
>> This is great.
>
> I'm glad the patch helps you and I'm sure Bram appreciates the
> acknowledgement.  But, would you and others please not include the
> entire text of a patch in such replies unless you are commenting on
> specific parts of the patch?
>
> Regards,
> Gary
>

Sorry for that, I thought the google groups will automatically fold
that, but it does not. I will notice next time.

--
You received this message from the "vim_dev" 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

> Sorry for that, I thought the google groups will automatically fold
> that, but it does not. I will notice next time.

It does. But not all mail clients do the same.

--
You received this message from the "vim_dev" 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