Re: [bug] vim on windows does not seem to expand environment variables

[Bram Moolenaar]

Christian wrote:

> having read :h expand-env, I suspected that this also works on Windows, 
> however it does not seem to be the case:
> 
> :echo $PATH
> " This correctly shows the path, but neither of the following work:
> :echo expand("$PATH")
> :echo expand("%PATH%")
> 
> My use case is to have cmd.exe return a pseudo random number by using 
> %random%. However it looks like vim on windows cannot expand environment 
> variables.

expand() wasn't made for expanding environment variables.  Why not use
$PATH directly?

Not sure if $random works, might be something built into cmd.exe.  You
could try using system('echo %random%'), but it's likely slower.

-- 
"Microsoft is like Coke.  It's a secret formula, all the money is from
distribution, and their goal is to get Coke everywhere.  Open source is like
selling water.  There are water companies like Perrier and Poland Spring, but
you're competing with something that's free."   -- Carl Howe


 /// 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_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 received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [bug] vim on windows does not seem to expand environment variables

[Gary Johnson]

On 2019-03-26, Charles Cooper wrote:
> > ... neither of the following work:
> > :echo expand("$PATH")
>   This works for me now as it has in the past, using a gvim compiled with 
> MSVC.  Could there be a difference if compiled with gcc?

This works for me, too, using the latest Windows gvim that I had on
hand, 8.1.1006, installed from
https://github.com/vim/vim-win32-installer/releases and run as

gvim -N -u NONE -i NONE

on a Windows 10 system.

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

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

Re: [bug] vim on windows does not seem to expand environment variables

[Charles Cooper]

> ... neither of the following work:
> :echo expand("$PATH")
  This works for me now as it has in the past, using a gvim compiled with MSVC. 
 Could there be a difference if compiled with gcc?

> :echo expand("%PATH%")
  Agree this does not work.

Charlie

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

[bug] vim on windows does not seem to expand environment variables

[Christian Brabandt]

Hi,
having read :h expand-env, I suspected that this also works on Windows, 
however it does not seem to be the case:

:echo $PATH
" This correctly shows the path, but neither of the following work:
:echo expand("$PATH")
:echo expand("%PATH%")

My use case is to have cmd.exe return a pseudo random number by using 
%random%. However it looks like vim on windows cannot expand environment 
variables.

Best,
Christian
-- 
Antike Tempel konzentrieren den Gott im Menschen; des
Mittelalters Kirchen streben nach dem Gott in der Höhe.
-- Goethe, Maximen und Reflektionen, Nr. 1208

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

Re: Linux clipboard corruption bug?

[Sihera Andre]

On 15/03/19 05:37, Bram Moolenaar wrote:
> Andre Sihera wrote:
>
>> I'm using a fairly old version of ViM (7.3) on Ubuntu so I wondered if
>> this problem
>> isalready known about and maybe fixed in a newer version.
>>
>> The problem is that the clipboard contents appear to be getting
>> corrupted during a
>> cut/paste using the '*' register.
>>
>> Way to reproduce:
>>
>> 1) Open two terminal windows (or two tabs in a single terminal). I can
>> reproduce
>>  with both gnome terminal and mate terminal.
>>
>> 2) run VIM in both with no file in either window.
>>
>> 3) Go to one terminal ("terminal #1") and enter the following text from
>> line one:
>>
>> This is a test
>> This is another test
>> This is yet another test
>> This is a fourth test
>>
>> 5) Go to the other terminal ("terminal #2") and enter this text from
>> line one:
>>
>> This is a new test
>> This is a newer test
>>
>> 6) In terminal #1, go to line two, SHIFT+V, select the two middle lines,
>> then "*y
>>  toyankto the clipboard. The lines yanked will be:
>>
>> This is another test
>> This is yet another test
>>
>> 7) In terminal #1, :q! to exit ViM.
>>
>> 8) Go to terminal #2 position on line two ("This is a newer test") then "*p
>> The text does not paste from line three onwards, it gets merged into
>> line two:
>>
>> This is a new test
>> TThis is another test
>> This is yet another test
>> his is a newer test
>>
>>
>> If terminal #1 is left open during the operation it works as expected.
>> If anyone
>> can confirm this I'd be grateful.
> This is normal.  So long as Vim is running it can support requests for
> the current selection, which it owns.  Vim then adds info about the kind
> of selection (linewise, blockwise).  When Vim exits the selection is
> moved to the clipboard.  There it is not possible to add info about the
> kind of selection, thus it is always characterwise.
>
Understood.

Thanks for explaining.

Andre.

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

Re: Linux clipboard corruption bug?

[Bram Moolenaar]

Andre Sihera wrote:

> I'm using a fairly old version of ViM (7.3) on Ubuntu so I wondered if 
> this problem
> isalready known about and maybe fixed in a newer version.
> 
> The problem is that the clipboard contents appear to be getting 
> corrupted during a
> cut/paste using the '*' register.
> 
> Way to reproduce:
> 
> 1) Open two terminal windows (or two tabs in a single terminal). I can 
> reproduce
> with both gnome terminal and mate terminal.
> 
> 2) run VIM in both with no file in either window.
> 
> 3) Go to one terminal ("terminal #1") and enter the following text from 
> line one:
> 
> This is a test
> This is another test
> This is yet another test
> This is a fourth test
> 
> 5) Go to the other terminal ("terminal #2") and enter this text from 
> line one:
> 
> This is a new test
> This is a newer test
> 
> 6) In terminal #1, go to line two, SHIFT+V, select the two middle lines, 
> then "*y
> toyankto the clipboard. The lines yanked will be:
> 
> This is another test
> This is yet another test
> 
> 7) In terminal #1, :q! to exit ViM.
> 
> 8) Go to terminal #2 position on line two ("This is a newer test") then "*p
> The text does not paste from line three onwards, it gets merged into 
> line two:
> 
> This is a new test
> TThis is another test
> This is yet another test
> his is a newer test
> 
> 
> If terminal #1 is left open during the operation it works as expected. 
> If anyone
> can confirm this I'd be grateful.

This is normal.  So long as Vim is running it can support requests for
the current selection, which it owns.  Vim then adds info about the kind
of selection (linewise, blockwise).  When Vim exits the selection is
moved to the clipboard.  There it is not possible to add info about the
kind of selection, thus it is always characterwise.

-- 
Over the years, I've developed my sense of deja vu so acutely that now
I can remember things that *have* happened before ...

 /// 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_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 received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Linux clipboard corruption bug?

[Sihera Andre]

Hi all,

I'm using a fairly old version of ViM (7.3) on Ubuntu so I wondered if 
this problem
isalready known about and maybe fixed in a newer version.

The problem is that the clipboard contents appear to be getting 
corrupted during a
cut/paste using the '*' register.

Way to reproduce:

1) Open two terminal windows (or two tabs in a single terminal). I can 
reproduce
with both gnome terminal and mate terminal.

2) run VIM in both with no file in either window.

3) Go to one terminal ("terminal #1") and enter the following text from 
line one:

This is a test
This is another test
This is yet another test
This is a fourth test

5) Go to the other terminal ("terminal #2") and enter this text from 
line one:

This is a new test
This is a newer test

6) In terminal #1, go to line two, SHIFT+V, select the two middle lines, 
then "*y
toyankto the clipboard. The lines yanked will be:

This is another test
This is yet another test

7) In terminal #1, :q! to exit ViM.

8) Go to terminal #2 position on line two ("This is a newer test") then "*p
The text does not paste from line three onwards, it gets merged into 
line two:

This is a new test
TThis is another test
This is yet another test
his is a newer test


If terminal #1 is left open during the operation it works as expected. 
If anyone
can confirm this I'd be grateful.

Thanks in advance,

Andre.

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

[BUG] Bug with "gw" and cursor position

[Jason Franklin]

Greetings,

Found another small bug:

1. vim --clean
2. :set autoindent
3. i 
4. :exe 'norm 25atest '
5. gww0
6. vipgw

Note that the cursor moved to the end of the previous line.

Also note, each time we increase the indentation by one space,
we will move back into the previous line by the amount of the
indent.

It looks like the "saved_cursor" variable is being adjusted
incorrectly at the bottom of the "set_indent()" function.  I
am unable to discern precisely how this works, but it's where
I think the problem is, anyway.

Best,
Jason Franklin


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

Re: [vim/vim] Bug: on Windows, hang when opening files from network. (#3923)

[Kevin Gao]

https://docs.microsoft.com/en-us/windows/desktop/api/fileapi/nf-fileapi-findfirstfilea
 has a sample code. I just gave a try. I passed "\\dir1\*". The API call just 
hangs. So I'm 100% sure it hangs. I doubt if this is a Win API bug.

In my production environment, \\dir1 is a network share folder. I don't have 
access to \\dir1\dir_noaccess. When I double click the folder in Windows File 
Explorer, after about 10 seconds, the file explore prompts that 
"\\dir1\dir_noaccess is not accessible. You might not have permission to use 
this network resource. Contact the administrator of this server to find out if 
you have access permissions. The device is not ready".

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

Re: [vim/vim] Bug: on Windows, hang when opening files from network. (#3923)

[Bram Moolenaar]

> Repro:
> 
> Eg, the file is \\dir1\dir2\dir3\file. I've r/w access to this file.
> Under, \\dir1, there is folder, eg \\dir1\dir22, which I don't have access 
> right. Then when opening \\dir1\dir2\dir3\file, vim hangs.
> 
> As a comparison, notepad++ does not hang when opening this file.
> 
> I built windows vim tiny to take a look. The issue is here:
> 
> In fname_case of os_win32.c
> 
>   if (ptrue > ptruePrev
>   && (ptruePrev[0] != '.'
>   || (ptruePrev[1] != NUL
>   && (ptruePrev[1] != '.' || ptruePrev[2] != NUL)))
>   && (hFind = ### **FindFirstFile**(szTrueNameTemp, ))
> != INVALID_HANDLE_VALUE)
> 
> **FindFirstFile** tries to access files from root dir to current dir, level 
> by level. Because I don't have access right to \\dir1\dir22, when accessing 
> \\dir1\*, the API call just hang.

Does it really hang?  It's supposed to return an error.

-- 
No children may attend school with their breath smelling of "wild onions."
[real standing law in West Virginia, United States of America]

 /// 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_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 received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: BUG: Recent commit breaks shell script indention

[Christian Brabandt]

Can you please create an issue at my repository?
https://github.com/chrisbra/vim-sh-indent/

I'll have a look then.

Best,
Christian

On Do, 07 Feb 2019, Michael Jarvis wrote:

> It seems that a recent commit (314dd79ca) has broken shell-script indention. 
> This is using Vim 8.1.877.
> 
> To reproduce, try creating a simple shell script with several if-then-else 
> statements. Then edit the script with Vim, and try re-indenting the file with 
> gg=G, and you will see that the indention is not what is expected. 
> 
> At first I suspected it might be something in my configuration, but I get the 
> same problem when running without a vimrc ("vim -u NONE") and manually 
> entering ":filetype plugin indent on" and "set filetype=sh". 
> 
> For instance, consider this script. Note that the "if" and "then" are 
> represented with both styles, where if and then are on the same line, and 
> also where they are on separate lines. Both styles are valid, and a matter of 
> preference. 
> 
> #!/bin/bash
> # Use gg=G to re-indent whole file
> if [[ /bin/true ]]; then
> echo "hello true"
> else
> if [[ /bin/false ]]; then
> echo "hello false"
> else
> echo "true"
> fi
> fi
> if [[ /bin/true ]]
> then
> echo "hello true"
> else
> if [[ /bin/false ]]
> then
> echo "hello false"
> else
> echo "true"
> fi
> fi
> 
> This gets reformatted by Vim 8.1.877 to be:
> 
> #!/bin/bash
> # Use gg=G to re-indent whole file
> 
> if [[ /bin/true ]]; then
> echo "hello true"
> else
> if [[ /bin/false ]]; then
> echo "hello false"
> else
> echo "true"
> fi
> fi
> 
> if [[ /bin/true ]]
> then
> echo "hello true"
> else
> if [[ /bin/false ]]
> then
> echo "hello false"
> else
> echo "true"
> fi
> fi
> 
> It appears that the author was trying to improve the indention for shell 
> scripts, but it seems to have made things worse. :-/ 
> 
> Here's a patch that I made locally that seems to fix it. I am sure there is a 
> better way to do this, but I was in a rush. 
> 
> diff --git a/runtime/indent/sh.vim b/runtime/indent/sh.vim
> index c93be3195..028dcf275 100644
> --- a/runtime/indent/sh.vim
> +++ b/runtime/indent/sh.vim
> @@ -114,12 +114,13 @@ function! GetShIndent()
>let line = curline
>" Current line is a endif line, so get indent from start of "if condition" 
> line
>" TODO: should we do the same for other "end" lines?
> -  if curline =~ '^\s*\%(fi\)\s*\%(#.*\)\=$'
> -let previous_line = search('if.\{-\};\s*then\s*\%(#.*\)\=$', 'bnW')
> -if previous_line > 0
> -  let ind = indent(previous_line)
> -endif
> -  elseif line =~ '^\s*\%(then\|do\|else\|elif\|done\|end\)\>' || 
> s:end_block(line)
> +" if curline =~ '^\s*\%(fi\)\s*\%(#.*\)\=$'
> +"   let previous_line = search('if.\{-\};\s*then\s*\%(#.*\)\=$', 'bnW')
> +"   if previous_line > 0
> +" let ind = indent(previous_line)
> +"   endif
> +" elseif line =~ '^\s*\%(then\|do\|else\|elif\|done\|end\)\>' || 
> s:end_block(line)
> +  if line =~ '^\s*\%(then\|do\|else\|elif\|fi\|done\|end\)\>' || 
> s:end_block(line)
>  let ind -= s:indent_value('default')
>elseif line =~ '^\s*esac\>' && s:is_case_empty(getline(v:lnum - 1))
>  let ind -= s:indent_value('default')
> 


Mit freundlichen Grüßen
Christian
-- 
Dem Storch gegenüber haben die Frösche eine beschränkte Souveränität.
-- David Frost

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

BUG: Recent commit breaks shell script indention

[Michael Jarvis]

It seems that a recent commit (314dd79ca) has broken shell-script indention. 
This is using Vim 8.1.877.

To reproduce, try creating a simple shell script with several if-then-else 
statements. Then edit the script with Vim, and try re-indenting the file with 
gg=G, and you will see that the indention is not what is expected. 

At first I suspected it might be something in my configuration, but I get the 
same problem when running without a vimrc ("vim -u NONE") and manually entering 
":filetype plugin indent on" and "set filetype=sh". 

For instance, consider this script. Note that the "if" and "then" are 
represented with both styles, where if and then are on the same line, and also 
where they are on separate lines. Both styles are valid, and a matter of 
preference. 

#!/bin/bash
# Use gg=G to re-indent whole file
if [[ /bin/true ]]; then
echo "hello true"
else
if [[ /bin/false ]]; then
echo "hello false"
else
echo "true"
fi
fi
if [[ /bin/true ]]
then
echo "hello true"
else
if [[ /bin/false ]]
then
echo "hello false"
else
echo "true"
fi
fi

This gets reformatted by Vim 8.1.877 to be:

#!/bin/bash
# Use gg=G to re-indent whole file

if [[ /bin/true ]]; then
echo "hello true"
else
if [[ /bin/false ]]; then
echo "hello false"
else
echo "true"
fi
fi

if [[ /bin/true ]]
then
echo "hello true"
else
if [[ /bin/false ]]
then
echo "hello false"
else
echo "true"
fi
fi

It appears that the author was trying to improve the indention for shell 
scripts, but it seems to have made things worse. :-/ 

Here's a patch that I made locally that seems to fix it. I am sure there is a 
better way to do this, but I was in a rush. 

diff --git a/runtime/indent/sh.vim b/runtime/indent/sh.vim
index c93be3195..028dcf275 100644
--- a/runtime/indent/sh.vim
+++ b/runtime/indent/sh.vim
@@ -114,12 +114,13 @@ function! GetShIndent()
   let line = curline
   " Current line is a endif line, so get indent from start of "if condition" 
line
   " TODO: should we do the same for other "end" lines?
-  if curline =~ '^\s*\%(fi\)\s*\%(#.*\)\=$'
-let previous_line = search('if.\{-\};\s*then\s*\%(#.*\)\=$', 'bnW')
-if previous_line > 0
-  let ind = indent(previous_line)
-endif
-  elseif line =~ '^\s*\%(then\|do\|else\|elif\|done\|end\)\>' || 
s:end_block(line)
+" if curline =~ '^\s*\%(fi\)\s*\%(#.*\)\=$'
+"   let previous_line = search('if.\{-\};\s*then\s*\%(#.*\)\=$', 'bnW')
+"   if previous_line > 0
+" let ind = indent(previous_line)
+"   endif
+" elseif line =~ '^\s*\%(then\|do\|else\|elif\|done\|end\)\>' || 
s:end_block(line)
+  if line =~ '^\s*\%(then\|do\|else\|elif\|fi\|done\|end\)\>' || 
s:end_block(line)
 let ind -= s:indent_value('default')
   elseif line =~ '^\s*esac\>' && s:is_case_empty(getline(v:lnum - 1))
 let ind -= s:indent_value('default')

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

Re: [bug] Completion candidate doesn't show up immediately since 8.1.0768

[Bram Moolenaar]

Ken Takata wrote:

> Typing Ctrl-N/P once in insert mode doesn't show up the first completion
> candidate immediately since 8.1.0768.
> Before that patch, the first candidate is shown immediately after typing
> Ctrl-N/P, then the popup menu is shown after a few seconds (if there are many
> candidates).  After that patch, the first candidate is shown at the same time
> as the popup menu is shown.  So, it takes a few seconds to show the first
> candidate.
> 
> It seems that update_screen(0) is required for showing the first candidate.
> How about this patch?
> 
> --- a/src/edit.c
> +++ b/src/edit.c
> @@ -5023,7 +5023,10 @@ ins_compl_next(
>  
>   // Redraw before showing the popup menu to show the user what was
>   // inserted.
> - pum_call_update_screen();
> + if (pum_enough_matches())
> + pum_call_update_screen();
> + else
> + update_screen(0);
>  
>   /* display the updated popup menu */
>   ins_compl_show_pum();
> 
> 
> Thanks to h-east and mattn for helping debugging.

Ah, thus when there is one match the popup menu isn't displayed, but the
match also isn't displayed.  Your solution looks good.

There is still another problem that the popup menu isn't displayed after
searching the current file, making it slow when there are many buffers.
That's an older problem though.

-- 
"When I die, I want a tombstone that says "GAME OVER" - Ton Richters

 /// 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_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 received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[bug] Completion candidate doesn't show up immediately since 8.1.0768

[ktakata65536]

Hi Bram,

Typing Ctrl-N/P once in insert mode doesn't show up the first completion
candidate immediately since 8.1.0768.
Before that patch, the first candidate is shown immediately after typing
Ctrl-N/P, then the popup menu is shown after a few seconds (if there are many
candidates).  After that patch, the first candidate is shown at the same time
as the popup menu is shown.  So, it takes a few seconds to show the first
candidate.

It seems that update_screen(0) is required for showing the first candidate.
How about this patch?

--- a/src/edit.c
+++ b/src/edit.c
@@ -5023,7 +5023,10 @@ ins_compl_next(
 
// Redraw before showing the popup menu to show the user what was
// inserted.
-   pum_call_update_screen();
+   if (pum_enough_matches())
+   pum_call_update_screen();
+   else
+   update_screen(0);
 
/* display the updated popup menu */
ins_compl_show_pum();


Thanks to h-east and mattn for helping debugging.

Regards,
Ken Takata

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

Re: [bug] quickfix commands don't relibably redraw the displayed buffer

[Jason Franklin]

> If you really do want to move the cursorline highlighting, do:
>:.cc | redraw | wincmd p

This command works when it's in a mapping or when it's typed manually.
However, it did not work when invoked within a function (i.e., the
:redraw seemed to have no effect).

It appears, however, that Patch 8.1.0849 fixed this problem as a
side-effect!

Thanks,
Jason Franklin

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

Re: [bug] quickfix commands don't relibably redraw the displayed buffer

[Bram Moolenaar]

Jason Franklin wrote:

> I discovered another issue with updating the cursorline, this time
> when opening a result from the quickfix window.
> 
> 1. vim --clean
> 2. Source the attached script (it's short, review first)
> 3. :.cc | wincmd p
> 
> Notice that the cursorline highlighting is not updated.
> 
> The following patch fixes the problem by forcing quickfix navigation
> functions to call redraw_later(SOME_VALID).

Hmm, it's not really a bug, since the cursor is never displayed in that
window.  I'm sure there will be other sequences of commands that move
the cursor around and, so long as they are not typed, will not update
the cursor line in a window that isn't the current one.

If you really do want to move the cursorline highlighting, do:
   :.cc | redraw | wincmd p

-- 
BLACK KNIGHT:  I move for no man.
ARTHUR:So be it!
[hah] [parry thrust]
[ARTHUR chops the BLACK KNIGHT's left arm off]
ARTHUR:Now stand aside, worthy adversary.
BLACK KNIGHT:  'Tis but a scratch.
  The Quest for the Holy Grail (Monty Python)

 /// 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_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 received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[bug] quickfix commands don't relibably redraw the displayed buffer

[Jason Franklin]

I discovered another issue with updating the cursorline, this time
when opening a result from the quickfix window.

1. vim --clean
2. Source the attached script (it's short, review first)
3. :.cc | wincmd p

Notice that the cursorline highlighting is not updated.

The following patch fixes the problem by forcing quickfix navigation
functions to call redraw_later(SOME_VALID).


diff --git a/src/quickfix.c b/src/quickfix.c
index e292819f2..660152b40 100644
--- a/src/quickfix.c
+++ b/src/quickfix.c
@@ -3354,6 +3354,7 @@ theend:
else
free_string_option(old_swb);
 }
+redraw_later(SOME_VALID);
 }
 
 // Highlight attributes used for displaying entries from the quickfix list.


As usual, there may be a much better solution, and review would be greatly
appreciated!

Thanks,
Jason Franklin

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


test.vim
Description: Binary data

Re: [vim/vim] bufexists file name bug in session file

[Jon Crowe]

On Thursday, 24 January 2019 12:35:10 UTC, Bram Moolenaar  wrote:
> Jon Crowe wrote:
> 
> > Under certain circumstances (see below for steps to reproduce) a
> > session created by the :mksession command creates errors when
> > attempting to load the session.
> > 
> > The circumstances are:
> > 
> > There is a window with a split.
> > At least one of the buffers has a filename containing an apostrophe.
> > 
> > The steps to reproduce are as follows:
> > 
> > vim -N -u NONE
> > :w x'x
> > :split
> > :w xx
> > :mksession
> > :qa
> > vim -N -u NONE -S
> > 
> > The errors are:
> > 
> > "x'x" 0L, 0C
> > Error detected while processing /tmp/Session.vim:
> > line  159:
> > E116: Invalid arguments for function bufexists('x\'x') | buffer x\'x | else 
> > | edit x\'x | endif
> > E15: Invalid expression: bufexists('x\'x') | buffer x\'x | else | edit x\'x 
> > | endif
> > line  300:
> > E171: Missing :endif
> > 
> > The offending line in the Session.vim file is:
> > 
> > if bufexists('x\'x') | buffer x\'x | else | edit x\'x | endif
> > 
> > If I manually edit this line as follows:
> > 
> > if bufexists('x''x') | buffer x\'x | else | edit x\'x | endif
> > 
> > the error disappears and the session loads without error and as expected.
> > 
> > I realise this is an obscure and minor bug, but I hope it is of some use to 
> > report it. Thank you if you have the time or inclination to look into it. 
> > Also thank you if you don't, as I love Vim anyway.
> > 
> > Other info that may be of use:
> > 
> > VIM - Vi IMproved 8.1 (2018 May 18, compiled Jan 05 2019 20:53:12)
> > Included patches: 1-693
> > 
> > Running on Debian testing.
> > 
> > If there is any further information I have naively omitted that you
> > need, please let me know.
> 
> I can reproduce it.  The session escaping code only works for a double
> quoted string.  I'll make a fix.
> 

Thanks, much appreciated.

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

Re: [vim/vim] bufexists file name bug in session file

[Bram Moolenaar]

Jon Crowe wrote:

> Under certain circumstances (see below for steps to reproduce) a
> session created by the :mksession command creates errors when
> attempting to load the session.
> 
> The circumstances are:
> 
> There is a window with a split.
> At least one of the buffers has a filename containing an apostrophe.
> 
> The steps to reproduce are as follows:
> 
> vim -N -u NONE
> :w x'x
> :split
> :w xx
> :mksession
> :qa
> vim -N -u NONE -S
> 
> The errors are:
> 
> "x'x" 0L, 0C
> Error detected while processing /tmp/Session.vim:
> line  159:
> E116: Invalid arguments for function bufexists('x\'x') | buffer x\'x | else | 
> edit x\'x | endif
> E15: Invalid expression: bufexists('x\'x') | buffer x\'x | else | edit x\'x | 
> endif
> line  300:
> E171: Missing :endif
> 
> The offending line in the Session.vim file is:
> 
> if bufexists('x\'x') | buffer x\'x | else | edit x\'x | endif
> 
> If I manually edit this line as follows:
> 
> if bufexists('x''x') | buffer x\'x | else | edit x\'x | endif
> 
> the error disappears and the session loads without error and as expected.
> 
> I realise this is an obscure and minor bug, but I hope it is of some use to 
> report it. Thank you if you have the time or inclination to look into it. 
> Also thank you if you don't, as I love Vim anyway.
> 
> Other info that may be of use:
> 
> VIM - Vi IMproved 8.1 (2018 May 18, compiled Jan 05 2019 20:53:12)
> Included patches: 1-693
> 
> Running on Debian testing.
> 
> If there is any further information I have naively omitted that you
> need, please let me know.

I can reproduce it.  The session escaping code only works for a double
quoted string.  I'll make a fix.

-- 
TALL KNIGHT OF NI: Ni!
 "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

 /// 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_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 received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[vim/vim] bufexists file name bug in session file

[Jon Crowe]

Under certain circumstances (see below for steps to reproduce) a session 
created by the :mksession command creates errors when attempting to load the 
session.

The circumstances are:

There is a window with a split.
At least one of the buffers has a filename containing an apostrophe.

The steps to reproduce are as follows:

vim -N -u NONE
:w x'x
:split
:w xx
:mksession
:qa
vim -N -u NONE -S

The errors are:

"x'x" 0L, 0C
Error detected while processing /tmp/Session.vim:
line  159:
E116: Invalid arguments for function bufexists('x\'x') | buffer x\'x | else | 
edit x\'x | endif
E15: Invalid expression: bufexists('x\'x') | buffer x\'x | else | edit x\'x | 
endif
line  300:
E171: Missing :endif

The offending line in the Session.vim file is:

if bufexists('x\'x') | buffer x\'x | else | edit x\'x | endif

If I manually edit this line as follows:

if bufexists('x''x') | buffer x\'x | else | edit x\'x | endif

the error disappears and the session loads without error and as expected.

I realise this is an obscure and minor bug, but I hope it is of some use to 
report it. Thank you if you have the time or inclination to look into it. Also 
thank you if you don't, as I love Vim anyway.

Other info that may be of use:

VIM - Vi IMproved 8.1 (2018 May 18, compiled Jan 05 2019 20:53:12)
Included patches: 1-693

Running on Debian testing.

If there is any further information I have naively omitted that you need, 
please let me know.

Thanks,

Jon Crowe.

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

Re: [bug][patch] Vim can segfault when setting v:errmsg

[Bram Moolenaar]

Jason Franklin wrote:

> My environment is Ubuntu 18.04, GNOME Terminal.
> 
> While tinkering around, I discovered that the following snippet of
> Vimscript will result in a segfault:
> 
> " This produces a segfault.
> while 1
>   silent! let v:errmsg = []
>   let v:errmsg = ''
> endwhile
> 
> The loop is there because you may have to execute the sequence
> a couple of times before a segfault happens.
> 
> Also notice that running:
> 
> :let v:errmsg = []
> :echo v:errmsg
> 
> does not show the last generated error message as one would expect,
> it shows the empty string.
> 
> I wrote a test to prove that my patch sets the error message in
> this case:
> 
> func Test_let_errmsg()
> silent! let v:errmsg = []
> call assert_false(empty(v:errmsg))
> endfunc
> 
> I'm not exactly sure where to put the test...  there were several
> test scripts that seemed relevant here.
> 
> I dug into the code and came up with this:
> 
> diff --git a/src/eval.c b/src/eval.c
> index d1a7fd37d..c485ecabd 100644
> --- a/src/eval.c
> +++ b/src/eval.c
> @@ -7883,20 +7883,23 @@ set_var(
>  || tv_check_lock(v->di_tv.v_lock, name, FALSE))
>   return;
>  
> - /*
> -  * Handle setting internal v: variables separately where needed to
> -  * prevent changing the type.
> -  */
> + // Handle setting internal v: variables separately where needed to
> + // prevent changing the type.
>   if (ht == )
>   {
>   if (v->di_tv.v_type == VAR_STRING)
>   {
> - vim_free(v->di_tv.vval.v_string);
> + VIM_CLEAR(v->di_tv.vval.v_string);
>   if (copy || tv->v_type != VAR_STRING)
> - v->di_tv.vval.v_string = vim_strsave(tv_get_string(tv));
> + {
> + if (STRCMP("v:errmsg", name) == 0)
> + tv_get_string(tv); // calls emsg(), which sets v:errmsg
> + else
> + v->di_tv.vval.v_string = vim_strsave(tv_get_string(tv));
> + }
>   else
>   {
> - /* Take over the string to avoid an extra alloc/free. */
> + // Take over the string to avoid an extra alloc/free.
>   v->di_tv.vval.v_string = tv->vval.v_string;
>   tv->vval.v_string = NULL;
>   }
> 
> This patch stops the segfault from happening and lets the check of the "tv"
> variable set v:errmsg (see comment).
> 
> I would appreciate some careful review here.  I don't precisely understand
> why VIM_CLEAR works instead of vim_free(). I suspect it is due to some check
> for NULL later.  Any feedback to help my understanding is always appreciated.
> It may be that a much better solution exists, but I'm not really familiar
> enough with the code to arrive at the perfect fix... though I try.

Good catch!  I don't have time to debug right now, but I suspect
tv_get_string() produces an error message and when v_string was not set
to NULL, it gets freed twice.

Solution would be to call vim_strsave() and storing the result in a
local variable, instead of assigning it to v_string.  And probably use
tv_get_string_chk() to skip storing the value when there is an error.

-- 
There is a fine line between courage and foolishness.
Unfortunately, it's not a fence.

 /// 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_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 received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[bug][patch] Vim can segfault when setting v:errmsg

[Jason Franklin]

Greetings,

My environment is Ubuntu 18.04, GNOME Terminal.

While tinkering around, I discovered that the following snippet of
Vimscript will result in a segfault:

" This produces a segfault.
while 1
  silent! let v:errmsg = []
  let v:errmsg = ''
endwhile

The loop is there because you may have to execute the sequence
a couple of times before a segfault happens.

Also notice that running:

:let v:errmsg = []
:echo v:errmsg

does not show the last generated error message as one would expect,
it shows the empty string.

I wrote a test to prove that my patch sets the error message in
this case:

func Test_let_errmsg()
silent! let v:errmsg = []
call assert_false(empty(v:errmsg))
endfunc

I'm not exactly sure where to put the test...  there were several
test scripts that seemed relevant here.

I dug into the code and came up with this:

diff --git a/src/eval.c b/src/eval.c
index d1a7fd37d..c485ecabd 100644
--- a/src/eval.c
+++ b/src/eval.c
@@ -7883,20 +7883,23 @@ set_var(
   || tv_check_lock(v->di_tv.v_lock, name, FALSE))
return;
 
-   /*
-* Handle setting internal v: variables separately where needed to
-* prevent changing the type.
-*/
+   // Handle setting internal v: variables separately where needed to
+   // prevent changing the type.
if (ht == )
{
if (v->di_tv.v_type == VAR_STRING)
{
-   vim_free(v->di_tv.vval.v_string);
+   VIM_CLEAR(v->di_tv.vval.v_string);
if (copy || tv->v_type != VAR_STRING)
-   v->di_tv.vval.v_string = vim_strsave(tv_get_string(tv));
+   {
+   if (STRCMP("v:errmsg", name) == 0)
+   tv_get_string(tv); // calls emsg(), which sets v:errmsg
+   else
+   v->di_tv.vval.v_string = vim_strsave(tv_get_string(tv));
+   }
else
{
-   /* Take over the string to avoid an extra alloc/free. */
+   // Take over the string to avoid an extra alloc/free.
v->di_tv.vval.v_string = tv->vval.v_string;
tv->vval.v_string = NULL;
}

This patch stops the segfault from happening and lets the check of the "tv"
variable set v:errmsg (see comment).

I would appreciate some careful review here.  I don't precisely understand
why VIM_CLEAR works instead of vim_free(). I suspect it is due to some check
for NULL later.  Any feedback to help my understanding is always appreciated.
It may be that a much better solution exists, but I'm not really familiar
enough with the code to arrive at the perfect fix... though I try.

Best,
Jason Franklin

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

[bug/patch] Stop session scripts from creating additional empty buffers

[Jason Franklin]

Currently, sourcing a session script that creates multiple tabs will
create multiple empty buffers as an unintended side effect (these buffers
did not exist when the session was written).  This only seems to happen
when 'hidden' is set.

Reproduce:

1. vim --clean +'set hidden'
2. :edit foo | tabedit bar | tabedit baz
3. :tabdo write
3. :mks!
4. :qa!
5. vim --clean +'set hidden' -S
6. :ls

Now you can see that additional buffers were created.  The buffer list also,
surprisingly, starts at 2 instead of 1 (this will be fixed as a side-effect
of this patch).

We can test our fix with:


diff --git a/src/testdir/test_mksession.vim b/src/testdir/test_mksession.vim
index 4d524da0d..db631f395 100644
--- a/src/testdir/test_mksession.vim
+++ b/src/testdir/test_mksession.vim
@@ -198,6 +198,27 @@ func Test_mksession_blank_tabs()
   call delete('Xtest_mks.out')
 endfunc
 
+func Test_mksession_buffer_count()
+  set hidden
+
+  " Edit exactly three files in the current session.
+  %bwipe!
+  e Xfoo | tabe Xbar | tabe Xbaz
+  tabdo write
+  mksession! Xtest_mks.out
+
+  " Verify that loading the session does not create additional buffers.
+  %bwipe!
+  source Xtest_mks.out
+  call assert_equal(3, len(getbufinfo()))
+
+  " Clean up.
+  call delete('Xfoo') | call delete('Xbar') | call delete('Xbaz')
+  call delete('Xtest_mks.out')
+  %bwipe!
+  set hidden&
+endfunc
+
 if has('extra_search')
 
 func Test_mksession_hlsearch()


The patch that I found that will fix the problem is here:


diff --git a/src/ex_docmd.c b/src/ex_docmd.c
index 8a9b2f4bf..dd8647ac3 100644
--- a/src/ex_docmd.c
+++ b/src/ex_docmd.c
@@ -11331,26 +11331,6 @@ makeopens(
 if (put_line(fd, "set shortmess=aoO") == FAIL)
return FAIL;
 
-/* Now put the other buffers into the buffer list */
-FOR_ALL_BUFFERS(buf)
-{
-   if (!(only_save_windows && buf->b_nwindows == 0)
-   && !(buf->b_help && !(ssop_flags & SSOP_HELP))
-#ifdef FEAT_TERMINAL
-   /* skip terminal buffers: finished ones are not useful, others
-* will be resurrected and result in a new buffer */
-   && !bt_terminal(buf)
-#endif
-   && buf->b_fname != NULL
-   && buf->b_p_bl)
-   {
-   if (fprintf(fd, "badd +%ld ", buf->b_wininfo == NULL ? 1L
-  : buf->b_wininfo->wi_fpos.lnum) < 0
-   || ses_fname(fd, buf, _flags, TRUE) == FAIL)
-   return FAIL;
-   }
-}
-
 /* the global argument list */
 if (ses_arglist(fd, "argglobal", _alist.al_ga,
!(ssop_flags & SSOP_CURDIR), _flags) == FAIL)
@@ -11578,6 +11558,28 @@ makeopens(
 if (restore_stal && put_line(fd, "set stal=1") == FAIL)
return FAIL;
 
+// Add all buffers to the buffer list.  If a buffer was already set to be
+// added above (with ":edit", for example), the command written here will
+// have no effect.
+FOR_ALL_BUFFERS(buf)
+{
+   if (!(only_save_windows && buf->b_nwindows == 0)
+   && !(buf->b_help && !(ssop_flags & SSOP_HELP))
+#ifdef FEAT_TERMINAL
+   /* skip terminal buffers: finished ones are not useful, others
+* will be resurrected and result in a new buffer */
+   && !bt_terminal(buf)
+#endif
+   && buf->b_fname != NULL
+   && buf->b_p_bl)
+   {
+   if (fprintf(fd, "badd +%ld ", buf->b_wininfo == NULL ? 1L
+  : buf->b_wininfo->wi_fpos.lnum) < 0
+   || ses_fname(fd, buf, _flags, TRUE) == FAIL)
+   return FAIL;
+   }
+}
+
 /*
  * Wipe out an empty unnamed buffer we started in.
  */


This places all of the ":badd" invocations at the bottom of the session.
The effect is that visible buffers are added first (which means they replace
the empty buffers in the windows they occupy). Adding all of the buffers
at the end then adds buffers that do not occupy a window.  Running :badd on
a buffer that is already in the list has no effect, so it doesn't hurt to
leave it.

I hope I didn't miss anything here.  I think my reasoning is sound.

Best wishes,
Jason Franklin

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

Re: [bug?] for loop on blob

[Bram Moolenaar]

Dominique wrote:

> I noticed that it's possible to use a :for loop
> on a blob and it's currently not documented:
> 
> :for v in 0z0102003 | echo v | endfor
> 1
> 2
> 3
> 
> So it apparently behaves like:
> :for v in [0x01,0x02,0x03] | echo v | endfor
> 1
> 2
> 3
> 
> I wanted to document it, but then I then realized
> that it does not behaves as I'd expect in this
> example:
> 
> echo "For loop with list"
> let l = [1, 2, 3]
> for x in l
>   echo l
>   call remove(l, 0)
> endfor
> echo l
> 
> echo "For loop with blob"
> let b = 0z010203
> for x in b
>   echo b
>   call remove(b, 0)
> endfor
> echo b
> 
> It outputs:
> 
> For loop with list
> [1, 2, 3]
> [2, 3]
> [3]
> []
> For loop with blob
> 0z010203
> 0z0203
> 0z03
> 
> Notice that:
> - the loop with list iterated 3 times, as expected, whereas
>   the loop with blob iterated only 2 times which seems wrong.
> - at the end, list l is empty as expected, whereas blob b has
>   1 byte left which seems wrong.
> 
> It looks like a bug to me. But since looping on a blob
> is not documented,  I don't know what to expect.

The loop over blob does not handle the blob changing inside the loop.
Like you did, most users will expect it to behave like a list of bytes.
Thus I think we should fix that.  Patch is welcome!

> Unrelated question: how do we convert a blob 0z010203
> into a list of integers [0x01,0x02,0x03]?  Perhaps we
> should be able to do:
> 
> :echo items(0z010203)
> [1,2,3]
> 
> But that does not work. Any other way?

Why would you want to do that?  Since the information in the Blob is
binary, when would you want to turn it into a list?

-- 
hundred-and-one symptoms of being an internet addict:
269. You receive an e-mail from the wife of a deceased president, offering
 to send you twenty million dollar, and you are not even surprised.

 /// 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_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 received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[bug?] for loop on blob

[Dominique Pellé]

Hi

I noticed that it's possible to use a :for loop
on a blob and it's currently not documented:

:for v in 0z0102003 | echo v | endfor
1
2
3

So it apparently behaves like:
:for v in [0x01,0x02,0x03] | echo v | endfor
1
2
3

I wanted to document it, but then I then realized
that it does not behaves as I'd expect in this
example:

echo "For loop with list"
let l = [1, 2, 3]
for x in l
  echo l
  call remove(l, 0)
endfor
echo l

echo "For loop with blob"
let b = 0z010203
for x in b
  echo b
  call remove(b, 0)
endfor
echo b

It outputs:

For loop with list
[1, 2, 3]
[2, 3]
[3]
[]
For loop with blob
0z010203
0z0203
0z03

Notice that:
- the loop with list iterated 3 times, as expected, whereas
  the loop with blob iterated only 2 times which seems wrong.
- at the end, list l is empty as expected, whereas blob b has
  1 byte left which seems wrong.

It looks like a bug to me. But since looping on a blob
is not documented,  I don't know what to expect.

Unrelated question: how do we convert a blob 0z010203
into a list of integers [0x01,0x02,0x03]?  Perhaps we
should be able to do:

:echo items(0z010203)
[1,2,3]

But that does not work. Any other way?

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

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

Re: [BUG] Peculiar bug with session restoration, please repro

[Jason Franklin]

John,

Please also see this discussion.  I also ran git bisect and arrived
at the same patch.

https://groups.google.com/forum/#!topic/vim_dev/oxi_dTY02as

Thanks,
Jason

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

Re: [BUG] Peculiar bug with session restoration, please repro

[John Little]

On Sunday, January 13, 2019 at 11:53:04 AM UTC+13, Jason Franklin wrote:
> Again, while working with sessions, I found a peculiar bug.
> Now... move the cursor up and down with j/k, and you'll see that
> cursorline highlighting doesn't follow the cursor as expected.

I reproduced this in Kubuntu 18.10 in a konsole, and also gvim with GTK2, but 
only after getting the latest source, so I thought, I can bisect this.

The first bad commit is

patch 8.1.0726: redrawing specifically for conceal feature

Problem:Redrawing specifically for conceal feature.
Solution:   Use generic redrawing methods.

Regards, John Little

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

Re: [BUG] Peculiar bug with session restoration, please repro

[Bram Moolenaar]

Jason Franklin wrote:

> Again, while working with sessions, I found a peculiar bug.
> 
> Environment is Ubuntu 18.04 with GNOME Terminal.  Latest Vim build.
> 
> vim --clean test.txt
> itesting...
> :w
> :set cul
> :h
> M
> :mks!
> :qall
> vim --clean -S
> j
> 
> 
> Now... move the cursor up and down with j/k, and you'll see that
> cursorline highlighting doesn't follow the cursor as expected.
> 
> Just wondering if anyone else can reproduce this issue before I
> try to dig deeper.

I can reproduce it.  Good luck with finding out what causes it.

-- 
hundred-and-one symptoms of being an internet addict:
183. You move your coffeemaker next to your computer.

 /// 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_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 received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[BUG] Peculiar bug with session restoration, please repro

[Jason Franklin]

Again, while working with sessions, I found a peculiar bug.

Environment is Ubuntu 18.04 with GNOME Terminal.  Latest Vim build.

vim --clean test.txt
itesting...
:w
:set cul
:h
M
:mks!
:qall
vim --clean -S
j


Now... move the cursor up and down with j/k, and you'll see that
cursorline highlighting doesn't follow the cursor as expected.

Just wondering if anyone else can reproduce this issue before I
try to dig deeper.

Thanks,
Jason Franklin

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

Re: [bug] term_gettitle() always returns an empty string

[Bram Moolenaar]

Dominique wrote:

> Function term_gettitle() is currently not tested according to
> codecov:
> 
>   https://codecov.io/gh/vim/vim/src/master/src/terminal.c#L4971
> 
> I thought of adding a test, but term_gettitle() seems to always
> return an empty string. For example, this command...
> 
>   :echo 'term title=[' . term_gettitle(term_start("bash")) . ']'
> 
> ... prints:
> 
>   term title=[]
> 
> It looks like a bug or am I missing something?

The shell doesn't set the title, you need to run something that does.
Running Vim it shows "[No name] - VIM".
You may also need to wait a moment before the running job updates the
title.

-- 
hundred-and-one symptoms of being an internet addict:
120. You ask a friend, "What's that big shiny thing?" He says, "It's the sun."

 /// 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_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 received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[bug] term_gettitle() always returns an empty string

[Dominique Pellé]

Hi

Function term_gettitle() is currently not tested according to
codecov:

  https://codecov.io/gh/vim/vim/src/master/src/terminal.c#L4971

I thought of adding a test, but term_gettitle() seems to always
return an empty string. For example, this command...

  :echo 'term title=[' . term_gettitle(term_start("bash")) . ']'

... prints:

  term title=[]

It looks like a bug or am I missing something?

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

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

Re: [PATCH] Fix bug in diffopt_changed() function

[Christian Brabandt]

On Di, 04 Dez 2018, Jason Franklin wrote:

> Oh! I see... it fails and then it tries again.
> 
> If that's the expected behavior, then this all seems good to me.

Yes, Test_diff_screen() is marked as flaky. So it tries again. Not sure 
why it fails the first time.

Best,
Christian
-- 
Das Menschenleben ist seltsam eingerichtet: Nach den Jahren der Last hat
man die Last der Jahre.
-- Alfred Polgar

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

Re: [PATCH] Fix bug in diffopt_changed() function

[Jason Franklin]

Oh! I see... it fails and then it tries again.

If that's the expected behavior, then this all seems good to me.

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

Re: [PATCH] Fix bug in diffopt_changed() function

[Jason Franklin]

I was able to verify the following:

1. The test fails with out the change to diff.c
2. The test passes with the patch.

The change to the test suite seems okay.  However, when I run the 
test without the patch, I see the message:

"Executed 31 tests"

And, when I run with the patch...

"Executed 30 tests"

Why is there a difference in the number of tests?

Thanks,
Jason

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

Re: [PATCH] Fix bug in diffopt_changed() function

[Christian Brabandt]

On Di, 04 Dez 2018, Christian Brabandt wrote:

> 
> On Di, 04 Dez 2018, Jason Franklin wrote:
> 
> > > Does the test fail if the change to diff.c is not applied?
> > 
> > Good catch.  It looks like the test doesn't fail for me when
> > the change to "diff.c" is not applied.
> 
> Yeah, I see. In fact, it should actually fail in both cases, because the 
> commandline differs from the recorded screen dump. Let me have a look, 
> if I can make it work.

There were actually quite a few more minor bugs in the test suite, that 
prevented correctly testing and it was tedious to find the root cause. 

One problem was, that the VerifyScreenDump() function did a term_dump()
too early, before the nested Vim had a chance to redraw, so that it 
returned both dumps being equal, while they were in fact different.

It almost drove me crazy until I finally found that cause.

Once I fixed that, the dump/Test_diff_09.dump started to fail. And this 
was in fact expected, as the dump was made with algorithm:patience on 
the commandline, while the test used algorithm:histogram.
So that dump had to be fixed.

Also the Test_diff_11.dump was changed, so that the commandline remained 
empty as well.

Once all that was fixed, the test started to behave as expected. Uff. 

So attached is the complete patch.

Best,
Christian
-- 
Es gab Zeiten, da man die Sklaven legal kaufen mußte.
-- Stanislaw Jerzy Lec (eig. S. J. de Tusch-Letz)

-- 
-- 
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 received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
diff --git a/src/diff.c b/src/diff.c
index 0399e7967..7f7e15df6 100644
--- a/src/diff.c
+++ b/src/diff.c
@@ -2173,6 +2173,7 @@ diffopt_changed(void)
 int		diff_flags_new = 0;
 int		diff_foldcolumn_new = 2;
 long	diff_algorithm_new = 0;
+long	diff_indent_heuristic = 0;
 tabpage_T	*tp;
 
 p = p_dip;
@@ -2236,7 +2237,7 @@ diffopt_changed(void)
 	else if (STRNCMP(p, "indent-heuristic", 16) == 0)
 	{
 	p += 16;
-	diff_algorithm_new |= XDF_INDENT_HEURISTIC;
+	diff_indent_heuristic = XDF_INDENT_HEURISTIC;
 	}
 	else if (STRNCMP(p, "internal", 8) == 0)
 	{
@@ -2276,6 +2277,8 @@ diffopt_changed(void)
 	++p;
 }
 
+diff_algorithm_new |= diff_indent_heuristic;
+
 /* Can't have both "horizontal" and "vertical". */
 if ((diff_flags_new & DIFF_HORIZONTAL) && (diff_flags_new & DIFF_VERTICAL))
 	return FAIL;
diff --git a/src/testdir/dumps/Test_diff_09.dump b/src/testdir/dumps/Test_diff_09.dump
index 6445a5776..95692b62a 100644
--- a/src/testdir/dumps/Test_diff_09.dump
+++ b/src/testdir/dumps/Test_diff_09.dump
@@ -17,4 +17,4 @@
 | +0#e05#a8a8a8255@1| +0#000#ff0@3|{| @29||+1&&| +0#e05#a8a8a8255@1| +0#000#ff0@3|{| @29
 | +0#e05#a8a8a8255@1| +0#000#5fd7ff255@7|p|r|i|n|t|f|(|"|Y|o|u|r| |a|n|s|w|e|r| |i|s|:| 

Re: [PATCH] Fix bug in diffopt_changed() function

[Christian Brabandt]

On Di, 04 Dez 2018, Jason Franklin wrote:

> > Does the test fail if the change to diff.c is not applied?
> 
> Good catch.  It looks like the test doesn't fail for me when
> the change to "diff.c" is not applied.

Yeah, I see. In fact, it should actually fail in both cases, because the 
commandline differs from the recorded screen dump. Let me have a look, 
if I can make it work.

Best,
Christian
-- 
Die Kunst zu gefallen, ist die Kunst zu täuschen.
-- Luc de Clapiers Vauvenargues

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

Re: [PATCH] Fix bug in diffopt_changed() function

[Jason Franklin]

> Does the test fail if the change to diff.c is not applied?

Good catch.  It looks like the test doesn't fail for me when
the change to "diff.c" is not applied.

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

Re: [PATCH] Fix bug in diffopt_changed() function

[Christian Brabandt]

On Di, 04 Dez 2018, Jason Franklin wrote:

> > How about the following...
> 
> This seems perfectly reasonable to me.
> 
> The tests run and everything checks out on visual inspection.  I'm content!

Thanks for confirming. Does the test fail if the change to diff.c is not 
applied? For reference, can you share the complete patch then?


Thanks,
Christian
-- 
Ratten und Mäuse bekömmt man selten zu sehen, fast niemals in einer Mausefalle.
-- Johann Georg August Galletti

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

Re: [PATCH] Fix bug in diffopt_changed() function

[Jason Franklin]

> How about the following...

This seems perfectly reasonable to me.

The tests run and everything checks out on visual inspection.  I'm content!

Best,
Jason Franklin

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

Re: [PATCH] Fix bug in diffopt_changed() function

[Christian Brabandt]

On Di, 04 Dez 2018, Jason Franklin wrote:

> Greetings,
> 
> While reading this article...
> 
>   https://vimways.org/2018/the-power-of-diff/
> 
> ... yesterday, I discovered a subtle bug in the behavior when
> the 'diffopt' setting is changed.
> 
> To observe, use the two attached files and run...
> 
>   vim --clean
>   :e f2.rb
>   :vsp f1.rb
>   :windo diffthis
> 
> Now, you can source the following two snippets of VimL:
> 
>   :set diffopt&
>   :set diffopt+=algorithm:patience,indent-heuristic
> 
> Observe the correct behavior after the above.
> 
>   :set diffopt&
>   :set diffopt+=indent-heuristic,algorithm:patience
> 
> Observe the incorrect behavior.  This is because order matters
> in the "diffopt_changed()" function.
> 
> I believe the patch, also attached, fixes this problem.  It'd be
> great if Christian could take a look and verify my change.

Thanks, the patch looks reasonable.

> I didn't include a test because I thought I'd be more testing the
> output of the diff operation than the setting of the option.  That is,
> there's no way to get direct access to the internal data managed by
> the option when set.  Let me know if this is not acceptable.

How about the following (Note, I suppose the patience diff alogrithm 
does not actually change the diff produced, so enhancing the existings 
tests and using the existing dumps should work):

diff --git a/src/testdir/test_diffmode.vim b/src/testdir/test_diffmode.vim
index 4f20395ab..7681b5ce1 100644
--- a/src/testdir/test_diffmode.vim
+++ b/src/testdir/test_diffmode.vim
@@ -815,6 +815,13 @@ func Test_diff_screen()

   call term_sendkeys(buf, ":set diffopt+=indent-heuristic\")
   call VerifyScreenDump(buf, 'Test_diff_11', {})
+  " shouldn't matter, if indent-algorithm comes before or after the algorithm
+  call term_sendkeys(buf, ":set diffopt&\")
+  call term_sendkeys(buf, ":set 
diffopt+=indent-heuristic,algorithm:patience\")
+  call VerifyScreenDump(buf, 'Test_diff_11', {})
+  call term_sendkeys(buf, ":set diffopt&\")
+  call term_sendkeys(buf, ":set 
diffopt+=algorithm:patience,indent-heuristic\")
+  call VerifyScreenDump(buf, 'Test_diff_11', {})

   " Test 12: diff the same file
   call WriteDiffFiles(buf, [1, 2, 3, 4, 5, 6, 7, 8, 9, 10], [1, 2, 3, 4, 5, 6, 
7, 8, 9, 10])






Best,
Christian
-- 
UNIX-Airlines
Jedermann bringt ein Stück des Flugzeuges zum Flughafen mit. Alle
gehen auf die Startbahn und setzen das Flugzeug Stück für Stück
zusammen.  Dabei diskutieren sie fortwährend, welche Art von Flugzeug
sie gerade zusammenbauen.

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

[PATCH] Fix bug in diffopt_changed() function

[Jason Franklin]

Greetings,

While reading this article...

  https://vimways.org/2018/the-power-of-diff/

... yesterday, I discovered a subtle bug in the behavior when
the 'diffopt' setting is changed.

To observe, use the two attached files and run...

  vim --clean
  :e f2.rb
  :vsp f1.rb
  :windo diffthis

Now, you can source the following two snippets of VimL:

  :set diffopt&
  :set diffopt+=algorithm:patience,indent-heuristic

Observe the correct behavior after the above.

  :set diffopt&
  :set diffopt+=indent-heuristic,algorithm:patience

Observe the incorrect behavior.  This is because order matters
in the "diffopt_changed()" function.

I believe the patch, also attached, fixes this problem.  It'd be
great if Christian could take a look and verify my change.

I didn't include a test because I thought I'd be more testing the
output of the diff operation than the setting of the option.  That is,
there's no way to get direct access to the internal data managed by
the option when set.  Let me know if this is not acceptable.

Best,
Jason Franklin

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


f1.rb
Description: Binary data


f2.rb
Description: Binary data
diff --git a/src/diff.c b/src/diff.c
index 0399e7967..7f7e15df6 100644
--- a/src/diff.c
+++ b/src/diff.c
@@ -2173,6 +2173,7 @@ diffopt_changed(void)
 int		diff_flags_new = 0;
 int		diff_foldcolumn_new = 2;
 long	diff_algorithm_new = 0;
+long	diff_indent_heuristic = 0;
 tabpage_T	*tp;
 
 p = p_dip;
@@ -2236,7 +2237,7 @@ diffopt_changed(void)
 	else if (STRNCMP(p, "indent-heuristic", 16) == 0)
 	{
 	p += 16;
-	diff_algorithm_new |= XDF_INDENT_HEURISTIC;
+	diff_indent_heuristic = XDF_INDENT_HEURISTIC;
 	}
 	else if (STRNCMP(p, "internal", 8) == 0)
 	{
@@ -2276,6 +2277,8 @@ diffopt_changed(void)
 	++p;
 }
 
+diff_algorithm_new |= diff_indent_heuristic;
+
 /* Can't have both "horizontal" and "vertical". */
 if ((diff_flags_new & DIFF_HORIZONTAL) && (diff_flags_new & DIFF_VERTICAL))
 	return FAIL;

Re: Documentation bug report - "j" format option

[Bram Moolenaar]

Edward McGuire wrote:

> On Monday, November 5, 2018 at 9:57:25 AM UTC-6, Christian Brabandt wrote:
> > Note, vimdoc.sf.net is no longer maintained.
> 
> That clears things up for me. Thank you!
> 
> There are two apparently credible sources that link to
> vimdoc.sourceforge.net, which is how I ended up in the weeds.
> 
> On the left sidebar of www.vim.org/docs.php, the links are to
> vimdoc.sourceforge.net. If someone is still maintaining vim.org maybe
> those links can be updated.
> 
> Google search still returns vimdoc.sourceforge.net as the first result
> for ?q=vimdoc. So vimdoc.sourceforge.net itself could benefit from a
> banner with a forwarding address.
> 
> I'd be happy to do the work if someone can loan me the keys.

Thanks for the hint, I removed the links from the documentation menu.
And replaced the FAQ link with the one that is maintained.

I'll keep the link in the body, but make it "nofollow" so that Google
search won't value the link.

-- 
ARTHUR:Well, it doesn't matter.  Will you go and tell your master that
   Arthur from the Court of Camelot is here.
GUARD #1:  Listen, in order to maintain air-speed velocity, a swallow
   needs to beat its wings 43 times every second, right?
ARTHUR:Please!
  The Quest for the Holy Grail (Monty Python)

 /// 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_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 received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Documentation bug report - "j" format option

[Edward McGuire]

On Monday, November 5, 2018 at 9:57:25 AM UTC-6, Christian Brabandt wrote:
> Note, vimdoc.sf.net is no longer maintained.

That clears things up for me. Thank you!

There are two apparently credible sources that link to vimdoc.sourceforge.net, 
which is how I ended up in the weeds.

On the left sidebar of www.vim.org/docs.php, the links are to 
vimdoc.sourceforge.net. If someone is still maintaining vim.org maybe those 
links can be updated.

Google search still returns vimdoc.sourceforge.net as the first result for 
?q=vimdoc. So vimdoc.sourceforge.net itself could benefit from a banner with a 
forwarding address.

I'd be happy to do the work if someone can loan me the keys.

Cheers!

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

Re: Documentation bug report - "j" format option

[Tony Mechelynck]

On Mon, Nov 5, 2018 at 4:50 PM Edward McGuire  wrote:
>
> This is a documentation bug report. The "j" format option is missing from the 
> table *fo-table* of the current HTML documentation, retrieved 5 November 2018.
>
> URL:
>
> http://vimdoc.sourceforge.net/htmldoc/change.html#fo-table
>
> Cheers
> Edward

Thanks. I suppose a new version of the HTML help should be uploaded
(by whoever maintains it).

That HTML documentation is "for Vim 7.3". Since then, 7.4 and 8.0 have
come and gone, and the latest version asof this writing is 8.1.511. In
case of doubt, the authoritative documentation is the online help
distributed together with Vim.

Best regards,
Tony.

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

Re: Documentation bug report - "j" format option

[Christian Brabandt]

On Mo, 05 Nov 2018, Edward McGuire wrote:

> This is a documentation bug report. The "j" format option is missing
> from the table *fo-table* of the current HTML documentation, retrieved
> 5 November 2018.
> 
> URL:
> 
> http://vimdoc.sourceforge.net/htmldoc/change.html#fo-table

Note, vimdoc.sf.net is no longer maintained. It's documentation is for 
Vim version 7.3 or something (as can be seen on the front page).

If you need an online version of the vim documentation, you can either 
use http://vimhelp.appspot.com/ or browse the vim github repository
https://github.com/vim/vim/blob/master/runtime/doc/change.txt


Best,
Christian
-- 
Wer das Unheil voraussieht, leidet zweimal.
-- B. Porteus

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

Documentation bug report - "j" format option

[Edward McGuire]

This is a documentation bug report. The "j" format option is missing from the 
table *fo-table* of the current HTML documentation, retrieved 5 November 2018.

URL:

http://vimdoc.sourceforge.net/htmldoc/change.html#fo-table

Cheers
Edward

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

Re: [patch] Fix bug with "CTRL-W " quickfix window command

[Jason Franklin]

> Using :clearjumps also deletes older jumps.  That's not what I expect.
> Could we just remove the jumps to the quickfix window buffer?

I defer to you on this one.  Your take sounds reasonable.  My choice here
was
little naive.  I haven't looked at how to go about deleting only certain
jump list
entries.

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

Re: [patch] Fix bug with "CTRL-W " quickfix window command

[Bram Moolenaar]

Jason Franklin wrote:

> I fixed the patch per your request.  I followed points 1 & 2, but I must say
> that I disagree with point 3.  I think making this change would make the
> function less readable.  Thus, I didn't include that change.
> 
> Let me know if this is acceptable.

Looks OK to me.  I'll include it, thanks.

Using :clearjumps also deletes older jumps.  That's not what I expect.
Could we just remove the jumps to the quickfix window buffer?


-- 
You were lucky. We lived for three months in a brown paper bag in a 
septic tank. We used to have to get up at six o'clock in the morning, 
clean the bag, eat a crust of stale bread, go to work down mill for 
fourteen hours a day week in-week out. When we got home, our Dad
would thrash us to sleep with his belt!

 /// 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_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 received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [bug] termdebug button does not work with "set cpoptions=ces$" in vimrc

[Christian Brabandt]

On Di, 17 Jul 2018, Bram Moolenaar wrote:

> 
> Dominique wrote:
> 
> > In my ~/.vimrc, I have this line:
> > 
> >   set cpoptions=ces$
> > 
> > I noticed that it breaks the buttons in the termdebug plugin.
> > 
> > Steps  to reproduce:
> > 
> > 1) run:
> >   $ cd vim/src
> >   $ ./vim --clean \
> >-c 'set cpoptions=ces$' \
> >-c 'packadd termdebug' \
> >-c 'Termdebug vim'
> > 
> > 2) Press the "Cont" button in the bottom window
> > 
> > 3) observe that the "continuer" command is sent to
> > the gdb terminal window (top window).  It should
> > instead send "continue\r".
> > 
> > Now, I don't remember why I have "set cpoptions=ces$"
> > in my ~/.vimrc.  But probably, it should not break the
> > "Cont" button of the termdebug plugin.
> 
> Have you tried  finding which missing flag matters?

Missing 'B'. How about this doc patch:

diff --git a/runtime/doc/options.txt b/runtime/doc/options.txt
index c895bf0db..b7b17da93 100644
--- a/runtime/doc/options.txt
+++ b/runtime/doc/options.txt
@@ -2107,10 +2107,11 @@ A jump table for the options with a short description 
can be found at |Q_op|.
See also |map_bar|.
*cpo-B*
B   A backslash has no special meaning in mappings,
-   abbreviations and the "to" part of the menu commands.
-   Remove this flag to be able to use a backslash like a
-   CTRL-V.  For example, the command ":map X \"
-   results in X being mapped to:
+   abbreviations, commands and the "to" part of the
+   |:menu| commands.  Remove this flag to be able to use
+   a backslash like a CTRL-V. For example, the command >
+   :map X \
+<   results in X being mapped to:
'B' included:   "\^["(^[ is a real )
'B' excluded:   ""  (5 characters)
('<' excluded in both cases)


Best,
Christian
-- 
So wie das Ohr Verhältnisse mißt, so berechnet vielleicht die Zunge
Flächen von Körpern.
-- Georg Christoph Lichtenberg

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

Re: [bug] termdebug button does not work with "set cpoptions=ces$" in vimrc

[Bram Moolenaar]

Dominique wrote:

> In my ~/.vimrc, I have this line:
> 
>   set cpoptions=ces$
> 
> I noticed that it breaks the buttons in the termdebug plugin.
> 
> Steps  to reproduce:
> 
> 1) run:
>   $ cd vim/src
>   $ ./vim --clean \
>-c 'set cpoptions=ces$' \
>-c 'packadd termdebug' \
>-c 'Termdebug vim'
> 
> 2) Press the "Cont" button in the bottom window
> 
> 3) observe that the "continuer" command is sent to
> the gdb terminal window (top window).  It should
> instead send "continue\r".
> 
> Now, I don't remember why I have "set cpoptions=ces$"
> in my ~/.vimrc.  But probably, it should not break the
> "Cont" button of the termdebug plugin.

Have you tried  finding which missing flag matters?

-- 
hundred-and-one symptoms of being an internet addict:
257. Your "hundred-and-one" lists include well over 101 items, since you
 automatically interpret all numbers in hexadecimal notation.
 (hex 101 = decimal 257)

 /// 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_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 received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[bug] termdebug button does not work with "set cpoptions=ces$" in vimrc

[Dominique Pellé]

Hi

In my ~/.vimrc, I have this line:

  set cpoptions=ces$

I noticed that it breaks the buttons in the termdebug plugin.

Steps  to reproduce:

1) run:
  $ cd vim/src
  $ ./vim --clean \
   -c 'set cpoptions=ces$' \
   -c 'packadd termdebug' \
   -c 'Termdebug vim'

2) Press the "Cont" button in the bottom window

3) observe that the "continuer" command is sent to
the gdb terminal window (top window).  It should
instead send "continue\r".

Now, I don't remember why I have "set cpoptions=ces$"
in my ~/.vimrc.  But probably, it should not break the
"Cont" button of the termdebug plugin.

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

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

Re: [bug] access to uninitialized memory in match_backref() regexp_nda.c:4882

[Bram Moolenaar]

Dominique wrote:

> Marius Gedminas  wrote:
> 
> > On Tue, Nov 24, 2015 at 05:11:02PM +0100, Bram Moolenaar wrote:
> > > Dominique wrote:
> > >
> > > > afl-fuzz fuzzer came up with the following command,
> > > > which causes access to uninitialized memory in
> > > > Vim-7-4-909:
> > > >
> > > > $ valgrind --track-origins=yes 2> valgrind.log \
> > > >   vim -u NONE -c 'syn keyword x nextgroup=\(\1\)'
> > > >
> > > > In valgrind.log:
> > > >
> > > > ==4366== Memcheck, a memory error detector
> > > > ==4366== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
> > > > ==4366== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for 
> > > > copyright info
> > > > ==4366== Command: ./vim -u NONE -c syn\ keyword\ x\ nextgroup=\\(\\1\\)
> > > > ==4366==
> > > > ==4366== Conditional jump or move depends on uninitialised value(s)
> [...]
> > >
> > > Is this fixed by patch 7.4.937, or is this another problem?
> >
> > I can reproduce this with vim 7.4.941, so it must be a different
> > problem.
> >
> > (Unsurprisingly, since \z(\) doesn't make an appearance.)
> 
> Replying to this old thread.
> I just tried to reproduce this with the latest Vim-8.1.177
> and I cannot reproduce it anymore.
> 
> Doing a git bissection, the issue was resolved in this
> commit more than a year ago:
> 
> ===
> commit 1ef9bbe215e13a273e74fccaddd8fc5a42c76b6e
> Author: Bram Moolenaar 
> Date:   Sat Jun 17 20:08:20 2017 +0200
> 
> patch 8.0.0645: no error for illegal back reference in NFA engine
> 
> Problem:The new regexp engine does not give an error for using a back
> reference where it is not allowed. (Dominique Pelle)
> Solution:   Check the back reference like the old engine. (closes #1774)
> ===
> 
> So we can remove this item still in runtime/doc/todo.txt as
> in attached patch:
> 
> ===
> Access to uninitialized memory in match_backref() regexp_nda.c:4882
> (Dominique Pelle, 2015 Nov 6)
> ===

Thanks.  Also took care of the other one.
Perhaps some day the todo list will actually get shorter :-).

-- 
hundred-and-one symptoms of being an internet addict:
231. You sprinkle Carpet Fresh on the rugs and put your vacuum cleaner
 in the front doorway permanently so it always looks like you are
 actually attempting to do something about that mess that has amassed
 since you discovered the Internet.

 /// 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_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 received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [bug] more info about global memory overflow (old bug in todo.txt reported on Jul 2015)

[Dominique Pellé]

Dominique Pellé  wrote:

> Hi
>
> I looked at this old item in todo.txt:
>
> ===
> Illegal memory access, requires ASAN to see. (Dominique Pelle, 2015 Jul 28)
> ===
>
> I can still reproduce it with the latest vim-8.0.703
> built with asan. I found this simpler way to reproduce it:
>
> $ vim -u NONE -c'set re=1' -c"call setline(1,'x')" -c"/\n\@<=" 2>log
> Vim: Caught deadly signal ABRT
> Vim: preserving files...
> Vim: Finished.
> Aborted (core dumped)
>
> And log contains:
>
> =
> ==8289==ERROR: AddressSanitizer: global-buffer-overflow on address
> 0x00a8cce4 at pc 0x0069a57b bp 0x7ffe999d3480 sp
> 0x7ffe999d3470
> READ of size 1 at 0x00a8cce4 thread T0
> #0 0x69a57a in utf_head_off /home/pel/sb/vim/src/mbyte.c:3809
> #1 0x78817b in regmatch /home/pel/sb/vim/src/regexp.c:5592
> #2 0x78026b in regtry /home/pel/sb/vim/src/regexp.c:4076
> #3 0x77fe00 in bt_regexec_both /home/pel/sb/vim/src/regexp.c:3961
> #4 0x77f2d5 in bt_regexec_multi /home/pel/sb/vim/src/regexp.c:3771
> #5 0x7c0141 in vim_regexec_multi /home/pel/sb/vim/src/regexp.c:8360
> #6 0x801112 in searchit /home/pel/sb/vim/src/search.c:716
> #7 0x80410f in do_search /home/pel/sb/vim/src/search.c:1443
> #8 0x53e068 in get_address /home/pel/sb/vim/src/ex_docmd.c:4562
> #9 0x52ed12 in do_one_cmd /home/pel/sb/vim/src/ex_docmd.c:2158
> #10 0x528f6f in do_cmdline /home/pel/sb/vim/src/ex_docmd.c:1089
> #11 0x527694 in do_cmdline_cmd /home/pel/sb/vim/src/ex_docmd.c:689
> #12 0x9f65e4 in exe_commands /home/pel/sb/vim/src/main.c:2945
> #13 0x9ef5e0 in vim_main2 /home/pel/sb/vim/src/main.c:803
> #14 0x9eeb68 in main /home/pel/sb/vim/src/main.c:419
> #15 0x7fe5bb73d82f in __libc_start_main
> (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
> #16 0x411ce8 in _start (/home/pel/sb/vim/src/vim+0x411ce8)
>
> 0x00a8cce4 is located 60 bytes to the left of global variable
> '*.LC1' defined in 'regexp.c' (0xa8cd20) of size 7
>   '*.LC1' is ascii string 'latin1'
> 0x00a8cce4 is located 3 bytes to the right of global variable
> '*.LC0' defined in 'regexp.c' (0xa8cce0) of size 1
>   '*.LC0' is ascii string ''
> SUMMARY: AddressSanitizer: global-buffer-overflow
> /home/pel/sb/vim/src/mbyte.c:3809 in utf_head_off
> Shadow bytes around the buggy address:
>   0x80149940: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x80149950: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x80149960: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x80149970: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x80149980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> =>0x80149990: 00 00 00 00 00 00 00 00 00 00 00 00[01]f9 f9 f9
>   0x801499a0: f9 f9 f9 f9 07 f9 f9 f9 f9 f9 f9 f9 00 04 f9 f9
>   0x801499b0: f9 f9 f9 f9 00 00 00 04 f9 f9 f9 f9 00 00 00 00
>   0x801499c0: 00 00 07 f9 f9 f9 f9 f9 00 00 02 f9 f9 f9 f9 f9
>   0x801499d0: 02 f9 f9 f9 f9 f9 f9 f9 00 00 02 f9 f9 f9 f9 f9
>   0x801499e0: 00 00 03 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00
> Shadow byte legend (one shadow byte represents 8 application bytes):
>   Addressable:   00
>   Partially addressable: 01 02 03 04 05 06 07
>   Heap left redzone:   fa
>   Freed heap region:   fd
>   Stack left redzone:  f1
>   Stack mid redzone:   f2
>   Stack right redzone: f3
>   Stack after return:  f5
>   Stack use after scope:   f8
>   Global redzone:  f9
>   Global init order:   f6
>   Poisoned by user:f7
>   Container overflow:  fc
>   Array cookie:ac
>   Intra object redzone:bb
>   ASan internal:   fe
>   Left alloca redzone: ca
>   Right alloca redzone:cb
> ==8289==ABORTING
>
> It crashes at regexp.c:5592:
>
>   5590 if (has_mbyte)
>   5591 rp->rs_un.regsave.rs_u.pos.col -=
> !!5592 (*mb_head_off)(regline, regline
>   5593 + rp->rs_un.regsave.rs_u.pos.col - 1) + 1;
>
> I see that at line 5592:
> - rp->rs_un.regsave.rs_u.pos.col is equal to 5 (i.e. number
>  of x in the line)
> - regline is equal to an empty string "" which was set
>   by reg_getline() at line 3694 to a constant string "".
>
>   3685 static char_u *
>   3686 reg_getline(linenr_T lnum)
>   3687 {
>   3688 /* when looking behind for a match/no-match lnum is negative.  But 
> we
>   3689  * can't go before line 1 */
>   3690 if (rex.reg_firstlnum + lnum < 1)
>   3691 return NULL;
>   3692 if (lnum > rex.reg_maxline)
>   3693 /* Must have matched the

Re: [bug] access to uninitialized memory in match_backref() regexp_nda.c:4882

[Dominique Pellé]

Marius Gedminas  wrote:

> On Tue, Nov 24, 2015 at 05:11:02PM +0100, Bram Moolenaar wrote:
> > Dominique wrote:
> >
> > > afl-fuzz fuzzer came up with the following command,
> > > which causes access to uninitialized memory in
> > > Vim-7-4-909:
> > >
> > > $ valgrind --track-origins=yes 2> valgrind.log \
> > >   vim -u NONE -c 'syn keyword x nextgroup=\(\1\)'
> > >
> > > In valgrind.log:
> > >
> > > ==4366== Memcheck, a memory error detector
> > > ==4366== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
> > > ==4366== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for 
> > > copyright info
> > > ==4366== Command: ./vim -u NONE -c syn\ keyword\ x\ nextgroup=\\(\\1\\)
> > > ==4366==
> > > ==4366== Conditional jump or move depends on uninitialised value(s)
> > > ==4366==at 0x55246B: match_backref (regexp_nfa.c:4882)
> > > ==4366==by 0x555276: nfa_regmatch (regexp_nfa.c:6398)
> > > ==4366==by 0x556214: nfa_regtry (regexp_nfa.c:6894)
> > > ==4366==by 0x5569DF: nfa_regexec_both (regexp_nfa.c:7085)
> > > ==4366==by 0x556D6A: nfa_regexec_nl (regexp_nfa.c:7247)
> > > ==4366==by 0x55702D: vim_regexec_both (regexp.c:8179)
> > > ==4366==by 0x5571BD: vim_regexec (regexp.c:8238)
> > > ==4366==by 0x5A90B8: get_id_list (syntax.c:6027)
> > > ==4366==by 0x5A5C2F: get_syn_options (syntax.c:4602)
> > > ==4366==by 0x5A63C4: syn_cmd_keyword (syntax.c:4840)
> > > ==4366==by 0x5A97B3: ex_syntax (syntax.c:6296)
> > > ==4366==by 0x46E052: do_one_cmd (ex_docmd.c:2961)
> > > ==4366==  Uninitialised value was created by a heap allocation
> > > ==4366==at 0x4C2AB80: malloc (in
> > > /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> > > ==4366==by 0x4E27E3: lalloc (misc2.c:921)
> > > ==4366==by 0x5530D0: nfa_regmatch (regexp_nfa.c:5474)
> > > ==4366==by 0x556214: nfa_regtry (regexp_nfa.c:6894)
> > > ==4366==by 0x5569DF: nfa_regexec_both (regexp_nfa.c:7085)
> > > ==4366==by 0x556D6A: nfa_regexec_nl (regexp_nfa.c:7247)
> > > ==4366==by 0x55702D: vim_regexec_both (regexp.c:8179)
> > > ==4366==by 0x5571BD: vim_regexec (regexp.c:8238)
> > > ==4366==by 0x5A90B8: get_id_list (syntax.c:6027)
> > > ==4366==by 0x5A5C2F: get_syn_options (syntax.c:4602)
> > > ==4366==by 0x5A63C4: syn_cmd_keyword (syntax.c:4840)
> > > ==4366==by 0x5A97B3: ex_syntax (syntax.c:6296)
> >
> > Is this fixed by patch 7.4.937, or is this another problem?
>
> I can reproduce this with vim 7.4.941, so it must be a different
> problem.
>
> (Unsurprisingly, since \z(\) doesn't make an appearance.)

Replying to this old thread.
I just tried to reproduce this with the latest Vim-8.1.177
and I cannot reproduce it anymore.

Doing a git bissection, the issue was resolved in this
commit more than a year ago:

===
commit 1ef9bbe215e13a273e74fccaddd8fc5a42c76b6e
Author: Bram Moolenaar 
Date:   Sat Jun 17 20:08:20 2017 +0200

patch 8.0.0645: no error for illegal back reference in NFA engine

Problem:The new regexp engine does not give an error for using a back
reference where it is not allowed. (Dominique Pelle)
Solution:   Check the back reference like the old engine. (closes #1774)
===

So we can remove this item still in runtime/doc/todo.txt as
in attached patch:

===
Access to uninitialized memory in match_backref() regexp_nda.c:4882
(Dominique Pelle, 2015 Nov 6)
===

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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
diff --git a/runtime/doc/todo.txt b/runtime/doc/todo.txt
index a39715799..8b82d555f 100644
--- a/runtime/doc/todo.txt
+++ b/runtime/doc/todo.txt
@@ -1018,9 +1018,6 @@ Added tests (James McCoy, 2016 Aug 3).  Still needs more work.
 Feature request: add the "al" text object, to manipulate a screen line.
 Especially useful when using 'linebreak'
 
-Access to uninitialized memory in match_backref() regexp_nda.c:4882
-(Dominique Pelle, 2015 Nov 6)
-
 ":cd C:\Windows\System32\drivers\etc*" does not work, even though the
 directory exists. (Sergio Gallelli, 2013 Dec 29)
 

Possible bug: inconsistent behavior with 'confirm' set

[Jason Franklin]

Platform: Ubuntu 18.04 (gnome-terminal)
Vim Version: 8.1.0121

To reproduce:

  vim --clean
  :set hidden
  :set confirm
  oword
  :e [some existing file]
  odd
  ZZ


Now the prompt comes up for the other buffer. Note that pressing responding
now doesn't immediately dismiss the prompt (you have to press enter).

This is inconsistent with all other confirm dialogs I've seen from Vim.

Just wondering if this is intentional.  I've tried tracking down the problem
to no avail.

Thanks,
Jason Franklin

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

Re: Vim bug when inserting foo}

[Petr Vorel]

Hi John,

> I have reproduced this with konsole and xterm, with vim 8.0.1453, 8.1.26, and 
> 8.1.72.  It happens for any character that showmatch would respond with, }, 
> ), or ], if there isn't a matching left character, and so vim would do the 
> visual bell if one was typing.

> Vim get very confused and echoes all characters typed, even escape if typed 
> twice.  Except that, if one presses ctrl-c, the display freezes and vim goes 
> CPU bound, with its memory usage bouncing up and down by a few MB, very 
> slowly increasing.  The only action I've found that will affect vim is a 
> window resize, or a WINCH signal; sometimes that fills most of the screen 
> with the two characters ^C.

> It's a bracketed paste problem, 

> :set t_BE=

> to turn that off stops it happening.  It's like the showmatch action is 
> turned back on slightly too soon, and the sequences for the visual bell 
> interfere with the end of the paste and the result is a mess.

Thank you for a quick explanation.

I consider it as a bug, even if it's not reproducible with 'vim -N -u NONE'
according to [1].

I guess we should report it.


> Regards, John Little


Kind regards,
Petr

[1] https://github.com/vim/vim/blob/master/CONTRIBUTING.md

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

Re: [patch] Fix bug with "CTRL-W " quickfix window command

[Bram Moolenaar]

Jason Franklin wrote:

> Just a friendly ping.  Checking to see if you've had a chance to peek
> at this change.

I have added it to the todo list.

-- 
>From "know your smileys":
 :-HIs missing teeth

 /// 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_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 received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [patch] Fix bug with "CTRL-W " quickfix window command

[Jason Franklin]

Hey Bram,

Just a friendly ping.  Checking to see if you've had a chance to peek at this
change.

Thanks,
Jason

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

Re: Vim bug when inserting foo}

[John Little]

I have reproduced this with konsole and xterm, with vim 8.0.1453, 8.1.26, and 
8.1.72.  It happens for any character that showmatch would respond with, }, ), 
or ], if there isn't a matching left character, and so vim would do the visual 
bell if one was typing.

Vim get very confused and echoes all characters typed, even escape if typed 
twice.  Except that, if one presses ctrl-c, the display freezes and vim goes 
CPU bound, with its memory usage bouncing up and down by a few MB, very slowly 
increasing.  The only action I've found that will affect vim is a window 
resize, or a WINCH signal; sometimes that fills most of the screen with the two 
characters ^C.

It's a bracketed paste problem, 

:set t_BE=

to turn that off stops it happening.  It's like the showmatch action is turned 
back on slightly too soon, and the sequences for the visual bell interfere with 
the end of the paste and the result is a mess.

Regards, John Little

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

[bug] syntax/sh.vim: shell command option inside if statement should have syntax shOption

[Jin-Jie Huang]

Hi,

I've sent this email to the maintainer of sh.vim but got an error so I came 
here for help.

Here is my test code snippet:

#!/bin/sh

if true; then
ls -l # inside if
fi
ls -l # outside if

The two '-l' are in different syntax group, the one inside if is shTestOpr, and 
the other one is shOption. I think they should all be in shOption group. I have 
a screenshot as an attachment, which clearly we can see that they have 
different syntax highlighting.

I use the following function to detect the syntax group to which the text under 
the cursor belongs.

function DetectSyntaxGroup()
for id in synstack(line('.'), col('.'))
echo synIDattr(id, 'name')
endfor
endfunction
noremap  :call DetectSyntaxGroup()

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

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

Re: [bug] use of free memory in qf_jump()

[Bram Moolenaar]

Dominique wrote:

> afl-fuzz found this case which causes vim-8.1.59
> and older to sometimes crash:
> 
> $ vim --clean -c new -c new -c 'au * * bw' -c lbuffer -cq
> Vim: Caught deadly signal SEGV
> Vim: Finished.
> Segmentation fault (core dumped)
> 
> Valgrind says:
> 
> ==7895== Memcheck, a memory error detector
> ==7895== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
> ==7895== Using Valgrind-3.14.0.GIT and LibVEX; rerun with -h for copyright 
> info
> ==7895== Command: ./vim --clean -c new -c new -c au\ *\ *\ bw -c lbuffer -cq
> ==7895==
> ==7895== Invalid read of size 4
> ==7895==at 0x246C1F: qf_jump (quickfix.c:2909)
> ==7895==by 0x1A0D01: do_one_cmd (ex_docmd.c:2886)
> ==7895==by 0x1A0D01: do_cmdline (ex_docmd.c:1040)
> ==7895==by 0x31AE2F: exe_commands (main.c:2937)
> ==7895==by 0x31AE2F: vim_main2 (main.c:812)
> ==7895==by 0x139B0C: main (main.c:443)
> ==7895==  Address 0x92cb898 is 8 bytes inside a block of size 1,216 free'd
> ==7895==at 0x4C30CF0: free (vg_replace_malloc.c:530)
> ==7895==by 0x24690B: qf_free_all (quickfix.c:1702)
> ==7895==by 0x2E1BDE: win_free (window.c:4717)
> ==7895==by 0x2E3633: win_free_mem (window.c:2596)
> ==7895==by 0x2E3633: win_close (window.c:2441)
> ==7895==by 0x145097: do_buffer (buffer.c:1432)
> ==7895==by 0x1458D5: do_bufdel (buffer.c:1112)
> ==7895==by 0x197A54: ex_bunload (ex_docmd.c:5532)
> ==7895==by 0x1A0D01: do_one_cmd (ex_docmd.c:2886)
> ==7895==by 0x1A0D01: do_cmdline (ex_docmd.c:1040)
> ==7895==by 0x1BBDB0: apply_autocmds_group (fileio.c:9690)
> ==7895==by 0x1BC6F3: apply_autocmds (fileio.c:9203)
> ==7895==by 0x24BDA3: ex_cbuffer (quickfix.c:6275)
> ==7895==by 0x1A0D01: do_one_cmd (ex_docmd.c:2886)
> ==7895==by 0x1A0D01: do_cmdline (ex_docmd.c:1040)
> ==7895==by 0x31AE2F: exe_commands (main.c:2937)
> ==7895==by 0x31AE2F: vim_main2 (main.c:812)
> ==7895==by 0x139B0C: main (main.c:443)
> ==7895==  Block was alloc'd at
> ==7895==at 0x4C2FBF6: malloc (vg_replace_malloc.c:299)
> ==7895==by 0x1FFD30: lalloc (misc2.c:976)
> ==7895==by 0x2430BD: ll_new_list (quickfix.c:1816)
> ==7895==by 0x243D9C: ll_get_or_alloc_list (quickfix.c:1844)
> ==7895==by 0x24BAE6: ex_cbuffer (quickfix.c:6233)
> ==7895==by 0x1A0D01: do_one_cmd (ex_docmd.c:2886)
> ==7895==by 0x1A0D01: do_cmdline (ex_docmd.c:1040)
> ==7895==by 0x31AE2F: exe_commands (main.c:2937)
> ==7895==by 0x31AE2F: vim_main2 (main.c:812)
> ==7895==by 0x139B0C: main (main.c:443)
> 
> Doing bwipe inside an autocommand is asking for
> trouble, but perhaps avoid the crash anyway.

Yes, that's a nasty autocommand, but Vim should not crash.
I'll make a fix.

-- 
ERROR 047: Keyboard not found.  Press RETURN to continue.

 /// 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_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 received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[bug] use of free memory in qf_jump()

[Dominique Pellé]

Hi

afl-fuzz found this case which causes vim-8.1.59
and older to sometimes crash:

$ vim --clean -c new -c new -c 'au * * bw' -c lbuffer -cq
Vim: Caught deadly signal SEGV
Vim: Finished.
Segmentation fault (core dumped)

Valgrind says:

==7895== Memcheck, a memory error detector
==7895== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==7895== Using Valgrind-3.14.0.GIT and LibVEX; rerun with -h for copyright info
==7895== Command: ./vim --clean -c new -c new -c au\ *\ *\ bw -c lbuffer -cq
==7895==
==7895== Invalid read of size 4
==7895==at 0x246C1F: qf_jump (quickfix.c:2909)
==7895==by 0x1A0D01: do_one_cmd (ex_docmd.c:2886)
==7895==by 0x1A0D01: do_cmdline (ex_docmd.c:1040)
==7895==by 0x31AE2F: exe_commands (main.c:2937)
==7895==by 0x31AE2F: vim_main2 (main.c:812)
==7895==by 0x139B0C: main (main.c:443)
==7895==  Address 0x92cb898 is 8 bytes inside a block of size 1,216 free'd
==7895==at 0x4C30CF0: free (vg_replace_malloc.c:530)
==7895==by 0x24690B: qf_free_all (quickfix.c:1702)
==7895==by 0x2E1BDE: win_free (window.c:4717)
==7895==by 0x2E3633: win_free_mem (window.c:2596)
==7895==by 0x2E3633: win_close (window.c:2441)
==7895==by 0x145097: do_buffer (buffer.c:1432)
==7895==by 0x1458D5: do_bufdel (buffer.c:1112)
==7895==by 0x197A54: ex_bunload (ex_docmd.c:5532)
==7895==by 0x1A0D01: do_one_cmd (ex_docmd.c:2886)
==7895==by 0x1A0D01: do_cmdline (ex_docmd.c:1040)
==7895==by 0x1BBDB0: apply_autocmds_group (fileio.c:9690)
==7895==by 0x1BC6F3: apply_autocmds (fileio.c:9203)
==7895==by 0x24BDA3: ex_cbuffer (quickfix.c:6275)
==7895==by 0x1A0D01: do_one_cmd (ex_docmd.c:2886)
==7895==by 0x1A0D01: do_cmdline (ex_docmd.c:1040)
==7895==by 0x31AE2F: exe_commands (main.c:2937)
==7895==by 0x31AE2F: vim_main2 (main.c:812)
==7895==by 0x139B0C: main (main.c:443)
==7895==  Block was alloc'd at
==7895==at 0x4C2FBF6: malloc (vg_replace_malloc.c:299)
==7895==by 0x1FFD30: lalloc (misc2.c:976)
==7895==by 0x2430BD: ll_new_list (quickfix.c:1816)
==7895==by 0x243D9C: ll_get_or_alloc_list (quickfix.c:1844)
==7895==by 0x24BAE6: ex_cbuffer (quickfix.c:6233)
==7895==by 0x1A0D01: do_one_cmd (ex_docmd.c:2886)
==7895==by 0x1A0D01: do_cmdline (ex_docmd.c:1040)
==7895==by 0x31AE2F: exe_commands (main.c:2937)
==7895==by 0x31AE2F: vim_main2 (main.c:812)
==7895==by 0x139B0C: main (main.c:443)

Doing bwipe inside an autocommand is asking for
trouble, but perhaps avoid the crash anyway.

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

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

Vim bug when inserting foo}

[petr . vorel]

Hi,

I'm having problems with Vim, when pasting with mouse
foo}

I mean any string ended by '}'.
When I post that,  doesn't allow me to end insert mode, instead of it 
prints ascii escape sequence ^[
And that Vim needs to be killed with sigkill.

This is not reproducible with 
vim -N -u NONE

I've found this works with my ~/.vimrc containing:  


  
set showmatch
set vb

Below is complete :version output

:version
VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Apr 27 2018 02:08:08)
Included patches: 1-1766
Modified by pkg-vim-maintain...@lists.alioth.debian.org
Compiled by pkg-vim-maintain...@lists.alioth.debian.org
Huge version with GTK2 GUI.  Features included (+) or not (-):
+acl   +clientserver  +dialog_con_gui+find_in_path  
+keymap+modify_fname  +multi_byte+profile   
+statusline+textobjects   +wildignore
+arabic+clipboard +diff  +float 
+lambda+mouse +multi_lang-python
-sun_workshop  +timers+wildmenu
+autocmd   +cmdline_compl +digraphs  +folding   
+langmap   +mouseshape-mzscheme  +python3   
+syntax+title +windows
-autoservername+cmdline_hist  +dnd   -footer
+libcall   +mouse_dec +netbeans_intg +quickfix  
+tag_binary+toolbar   +writebackup
+balloon_eval  +cmdline_info  -ebcdic+fork()
+linebreak +mouse_gpm +num64 +reltime   
+tag_old_static+user_commands +X11
+balloon_eval_term +comments  +emacs_tags+gettext   
+lispindent-mouse_jsbterm +packages  +rightleft 
-tag_any_white +vertsplit -xfontset
+browse+conceal   +eval  -hangul_input  
+listcmds  +mouse_netterm +path_extra+ruby  
+tcl   +virtualedit   +xim
++builtin_terms+cryptv+ex_extra  +iconv 
+localmap  +mouse_sgr +perl  +scrollbind
+termguicolors +visual+xpm
+byte_offset   +cscope+extra_search  +insert_expand 
+lua   -mouse_sysmouse+persistent_undo   +signs 
+terminal  +visualextra   +xsmp_interact
+channel   +cursorbind+farsi +job   
+menu  +mouse_urxvt   +postscript+smartindent   
+terminfo  +viminfo   +xterm_clipboard
+cindent   +cursorshape   +file_in_path  +jumplist  
+mksession +mouse_xterm   +printer   +startuptime   
+termresponse  +vreplace  -xterm_save
   system vimrc file: "$VIM/vimrc"
 user vimrc file: "$HOME/.vimrc"
 2nd user vimrc file: "~/.vim/vimrc"
  user exrc file: "$HOME/.exrc"
  system gvimrc file: "$VIM/gvimrc"
user gvimrc file: "$HOME/.gvimrc"
2nd user gvimrc file: "~/.vim/gvimrc"
   defaults file: "$VIMRUNTIME/defaults.vim"
system menu file: "$VIMRUNTIME/menu.vim"
  fall-back for $VIM: "/usr/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK  -pthread 
-I/usr/include/gtk-2.0 -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include 
-I/usr/include/gio-unix-2.0/ -I/usr/include/cairo -I/usr/include/pango-1.0 
-I/usr/include/atk-1.0 -
I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/gdk-pixbuf-2.0 
-I/usr/include/libpng16 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz 
-I/usr/include/pango-1.0 -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/includ
e -I/usr/include/fribidi -I/usr/include/uuid -I/usr/include/freetype2 
-I/usr/include/libpng16 -Wdate-time  -g -O2 
-fdebug-prefix-map=/build/vim-0PaOCf/vim-8.0.1766=. -fstack-protector-strong 
-Wformat -Werror=format-security -U_FORTIFY_SOUR
CE -D_FORTIFY_SOURCE=1
Linking: gcc   -L. -Wl,-z,relro -Wl,-z,now -fstack-protector -rdynamic 
-Wl,-export-dynamic -Wl,-E  -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -o vim   
-lgtk-x11-2.0 -lgdk-x11-2.0 -lpangocairo-1.0 -latk-1.0 -lcairo -lgdk_pixbuf-2.0 
-lgio-2.0 -
lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lfribidi -lfontconfig 
-lfreetype -lSM -lICE -lXpm -lXt -lX11 -lXdmcp -lSM -lICE  -lm -ltinfo -lnsl  
-lselinux  -lacl -lattr -lgpm -ldl  -L/usr/lib -llua5.2 -Wl,-E  
-fstack-protector-stron
g -L/usr/local/lib  -L/usr/lib/x86_64-linux-gnu/perl/5.26/CORE -lperl -ldl -lm 
-lpthread -lcrypt  -L/usr/lib/python3.6/config-3.6m-x86_64-linux-gnu 
-lpython3.6m -lpthread -ldl -lutil -lm -L/usr/lib/x86_64-linux-gnu -ltcl8.6 

Re: Bug Report: fnamemodify() fails on Windows

[Bram Moolenaar]

Jason Franklin wrote:

> I wanted to fix this myself, but I'm not having any fun fighting with the
> Microsoft build tools.  Hopefully, someone else has time to look into this
> issue.
> 
> System:   Windows 10
> Vim Version:  8.1.0001
> 
> To reproduce:
> 
> :echo fnamemodify('C:\__nodir__\__nofile__', ':.')
> 
> You'll see that the "C:" is removed from the given path.  If
> "C:\__nodir__\__nofile__" doesn't exist, the path should not be modified 
> (because
> it's not relative to the working directory).
> 
> See ":help filename-modifiers" for the description of how ":." should cause
> fnamemodify() to behave.

On MS-Windows the drive is sticky, thus \dir\path will use the current
drive.  Thus the resulting path will work.  We can adjust the help to
explain this.

-- 
Despite the cost of living, have you noticed how it remains so popular?

 /// 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_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 received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Bug Report: fnamemodify() fails on Windows

[Jason Franklin]

I wanted to fix this myself, but I'm not having any fun fighting with the
Microsoft build tools.  Hopefully, someone else has time to look into this
issue.

System:   Windows 10
Vim Version:  8.1.0001

To reproduce:

:echo fnamemodify('C:\__nodir__\__nofile__', ':.')

You'll see that the "C:" is removed from the given path.  If
"C:\__nodir__\__nofile__" doesn't exist, the path should not be modified 
(because
it's not relative to the working directory).

See ":help filename-modifiers" for the description of how ":." should cause
fnamemodify() to behave.

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

Re: [patch] Fix bug with "CTRL-W " quickfix window command

[Yegappan Lakshmanan]

Hi,

On Wed, May 30, 2018 at 5:26 AM, Jason Franklin
 wrote:
> Yegappan,
>
> I fixed the patch per your request.  I followed points 1 & 2, but I must say
> that I disagree with point 3.  I think making this change would make the
> function less readable.  Thus, I didn't include that change.
>
> Let me know if this is acceptable.
>

The patch looks good to me. Thanks for incorporating the changes.

Regards,
Yegappan

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

Re: [patch] Fix bug with "CTRL-W " quickfix window command

[Jason Franklin]

Yegappan,

I fixed the patch per your request.  I followed points 1 & 2, but I must say
that I disagree with point 3.  I think making this change would make the
function less readable.  Thus, I didn't include that change.

Let me know if this is acceptable.

Thanks,
Jason

-- 
-- 
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 received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
>From 8ddb5e6b03fe59c9e9d819ee0856e9d91e881e3a Mon Sep 17 00:00:00 2001
From: Jason Franklin 
Date: Wed, 30 May 2018 08:22:08 -0400
Subject: [PATCH] Fix bug with "CTRL-W " quickfix window command

---
 src/normal.c  | 14 --
 src/proto/quickfix.pro|  1 +
 src/quickfix.c| 40 
 src/testdir/test_quickfix.vim | 18 ++
 src/window.c  | 17 -
 5 files changed, 67 insertions(+), 23 deletions(-)

diff --git a/src/normal.c b/src/normal.c
index 58f7a7a..4196108 100644
--- a/src/normal.c
+++ b/src/normal.c
@@ -6195,18 +6195,12 @@ nv_down(cmdarg_T *cap)
 	cap->arg = FORWARD;
 	nv_page(cap);
 }
-else
 #if defined(FEAT_QUICKFIX)
-/* In a quickfix window a  jumps to the error under the cursor. */
-if (bt_quickfix(curbuf) && cap->cmdchar == CAR)
-{
-	if (curwin->w_llist_ref == NULL)
-	do_cmdline_cmd((char_u *)".cc");	/* quickfix window */
-	else
-	do_cmdline_cmd((char_u *)".ll");	/* location list window */
-}
-else
+/* Quickfix window only: view the result under the cursor. */
+else if (bt_quickfix(curbuf) && cap->cmdchar == CAR)
+	qf_view_result(FALSE);
 #endif
+else
 {
 #ifdef FEAT_CMDWIN
 	/* In the cmdline window a  executes the command. */
diff --git a/src/proto/quickfix.pro b/src/proto/quickfix.pro
index d32655f..26a5de0 100644
--- a/src/proto/quickfix.pro
+++ b/src/proto/quickfix.pro
@@ -7,6 +7,7 @@ void qf_list(exarg_T *eap);
 void qf_age(exarg_T *eap);
 void qf_history(exarg_T *eap);
 void qf_mark_adjust(win_T *wp, linenr_T line1, linenr_T line2, long amount, long amount_after);
+void qf_view_result(int split);
 void ex_cwindow(exarg_T *eap);
 void ex_cclose(exarg_T *eap);
 void ex_copen(exarg_T *eap);
diff --git a/src/quickfix.c b/src/quickfix.c
index 1b281ce..1d33045 100644
--- a/src/quickfix.c
+++ b/src/quickfix.c
@@ -3470,6 +3470,46 @@ qf_types(int c, int nr)
 }
 
 /*
+ * "": Open the entry/result under the cursor.
+ * "CTRL-W ": Open the entry/result under the cursor in a new split.
+ */
+void
+qf_view_result(int split)
+{
+char_u  cmd[32];
+qf_info_T   *qi = _info;
+
+if (!bt_quickfix(curbuf))
+	return;
+
+if (IS_LL_WINDOW(curwin))
+	qi = GET_LOC_LIST(curwin);
+
+if (qi == NULL || qi->qf_lists[qi->qf_curlist].qf_count == 0)
+{
+	EMSG(_(e_quickfix));
+	return;
+}
+
+if (split)
+{
+	vim_snprintf((char *) cmd, sizeof(cmd), "split +%ld%s",
+		(long) curwin->w_cursor.lnum,
+		IS_LL_WINDOW(curwin) ? "ll" : "cc");
+
+	if (do_cmdline_cmd(cmd) == OK)
+	do_cmdline_cmd((char_u *) "clearjumps");
+
+	return;
+}
+
+vim_snprintf((char *) cmd, sizeof(cmd), ".%s",
+	IS_LL_WINDOW(curwin) ? "ll" : "cc");
+
+do_cmdline_cmd(cmd);
+}
+
+/*
  * ":cwindow": open the quickfix window if we have errors to display,
  *	   close it if not.
  * ":lwindow": open the location list window if we have locations to display,
diff --git a/src/testdir/test_quickfix.vim b/src/testdir/test_quickfix.vim
index c3850ce..6f084ad 100644
--- a/src/testdir/test_quickfix.vim
+++ b/src/testdir/test_quickfix.vim
@@ -3350,3 +3350,21 @@ func Test_qftitle()
   call assert_equal('Errors', w:quickfix_title)
   cclose
 endfunc
+
+" Tests for the "CTRL-W " command.
+func Xview_result_split_tests(cchar)
+  call s:setup_commands(a:cchar)
+
+  " Test that "CTRL-W " in a qf/ll window fails with empty list.
+  call g:Xsetlist([])
+  Xopen
+  let l:win_count = winnr('$')
+  call assert_fails('execute "normal! \\"', 'E42')
+  call assert_equal(l:win_count, winnr('$'))
+  Xclose
+endfunc
+
+func Test_view_result_split()
+  call Xview_result_split_tests('c')
+  call Xview_result_split_tests('l')
+endfunc
diff --git a/src/window.c b/src/window.c
index d3ec4cd..190a6dd 100644
--- a/src/window.c
+++ b/src/window.c
@@ -520,23 +520,14 @@ wingotofile:
 		break;
 #endif
 
+/* Quickfix window only: view the result under the cursor in a new split. */
+#

Re: [patch] Fix bug with "CTRL-W " quickfix window command

[Yegappan Lakshmanan]

Hi,

On Tue, May 29, 2018 at 1:05 PM, Jason Franklin
 wrote:
> Yegappan,
>
> Attached is the updated patch.  To confirm, I...
>
> * merged qf_view_result() and qf_view_result_split()
> * used vim_snprintf(); I believe I used it properly
> * I used the X... functions to merge the test code
>
> Let me know what you think!
>

Thanks for incorporating the feedback. Few more suggestions on the new patch:

1. The location list may not be present always. So the return value of
GET_LOC_LIST()
should be checked against NULL.
2. The Vim source code convention is not to check against TRUE for functions
 returning a boolean. Can you change
 if (bt_quickfix(curbuf) == TRUE)
 to
 if (bt_quickfix(curbuf))
Same comment applies for the "if (split == TRUE)" statement.
3. Is it possible to combine the two vim_snprintf() calls into one with a check
for "split"?

Regards,
Yegappan

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

Re: [patch] Fix bug with "CTRL-W " quickfix window command

[Jason Franklin]

Yegappan,

Attached is the updated patch.  To confirm, I...

* merged qf_view_result() and qf_view_result_split()
* used vim_snprintf(); I believe I used it properly
* I used the X... functions to merge the test code

Let me know what you think!

-- Jason Franklin

-- 
-- 
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 received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
>From 97516709ae8f44627c72d9662f23257261431dfe Mon Sep 17 00:00:00 2001
From: Jason Franklin 
Date: Tue, 29 May 2018 16:02:15 -0400
Subject: [PATCH] Fix bug with "CTRL-W " quickfix window command

---
 src/normal.c  | 14 --
 src/proto/quickfix.pro|  1 +
 src/quickfix.c| 40 
 src/testdir/test_quickfix.vim | 18 ++
 src/window.c  | 19 +--
 5 files changed, 68 insertions(+), 24 deletions(-)

diff --git a/src/normal.c b/src/normal.c
index 58f7a7a..4196108 100644
--- a/src/normal.c
+++ b/src/normal.c
@@ -6195,18 +6195,12 @@ nv_down(cmdarg_T *cap)
 	cap->arg = FORWARD;
 	nv_page(cap);
 }
-else
 #if defined(FEAT_QUICKFIX)
-/* In a quickfix window a  jumps to the error under the cursor. */
-if (bt_quickfix(curbuf) && cap->cmdchar == CAR)
-{
-	if (curwin->w_llist_ref == NULL)
-	do_cmdline_cmd((char_u *)".cc");	/* quickfix window */
-	else
-	do_cmdline_cmd((char_u *)".ll");	/* location list window */
-}
-else
+/* Quickfix window only: view the result under the cursor. */
+else if (bt_quickfix(curbuf) && cap->cmdchar == CAR)
+	qf_view_result(FALSE);
 #endif
+else
 {
 #ifdef FEAT_CMDWIN
 	/* In the cmdline window a  executes the command. */
diff --git a/src/proto/quickfix.pro b/src/proto/quickfix.pro
index d32655f..26a5de0 100644
--- a/src/proto/quickfix.pro
+++ b/src/proto/quickfix.pro
@@ -7,6 +7,7 @@ void qf_list(exarg_T *eap);
 void qf_age(exarg_T *eap);
 void qf_history(exarg_T *eap);
 void qf_mark_adjust(win_T *wp, linenr_T line1, linenr_T line2, long amount, long amount_after);
+void qf_view_result(int split);
 void ex_cwindow(exarg_T *eap);
 void ex_cclose(exarg_T *eap);
 void ex_copen(exarg_T *eap);
diff --git a/src/quickfix.c b/src/quickfix.c
index 1b281ce..4129dc5 100644
--- a/src/quickfix.c
+++ b/src/quickfix.c
@@ -3470,6 +3470,46 @@ qf_types(int c, int nr)
 }
 
 /*
+ * "": Open the entry/result under the cursor.
+ * "CTRL-W ": Open the entry/result under the cursor in a new split.
+ */
+void
+qf_view_result(int split)
+{
+char_u  cmd[32];
+qf_info_T   *qi = _info;
+
+if (!bt_quickfix(curbuf))
+	return;
+
+if (IS_LL_WINDOW(curwin))
+	qi = GET_LOC_LIST(curwin);
+
+if (qi->qf_lists[qi->qf_curlist].qf_count == 0)
+{
+	EMSG(_(e_quickfix));
+	return;
+}
+
+if (split == TRUE)
+{
+	vim_snprintf((char *) cmd, sizeof(cmd), "split +%ld%s",
+		(long) curwin->w_cursor.lnum,
+		IS_LL_WINDOW(curwin) ? "ll" : "cc");
+
+	if (do_cmdline_cmd(cmd) == OK)
+	do_cmdline_cmd((char_u *) "clearjumps");
+
+	return;
+}
+
+vim_snprintf((char *) cmd, sizeof(cmd), ".%s",
+	IS_LL_WINDOW(curwin) ? "ll" : "cc");
+
+do_cmdline_cmd(cmd);
+}
+
+/*
  * ":cwindow": open the quickfix window if we have errors to display,
  *	   close it if not.
  * ":lwindow": open the location list window if we have locations to display,
diff --git a/src/testdir/test_quickfix.vim b/src/testdir/test_quickfix.vim
index c3850ce..6f084ad 100644
--- a/src/testdir/test_quickfix.vim
+++ b/src/testdir/test_quickfix.vim
@@ -3350,3 +3350,21 @@ func Test_qftitle()
   call assert_equal('Errors', w:quickfix_title)
   cclose
 endfunc
+
+" Tests for the "CTRL-W " command.
+func Xview_result_split_tests(cchar)
+  call s:setup_commands(a:cchar)
+
+  " Test that "CTRL-W " in a qf/ll window fails with empty list.
+  call g:Xsetlist([])
+  Xopen
+  let l:win_count = winnr('$')
+  call assert_fails('execute "normal! \\"', 'E42')
+  call assert_equal(l:win_count, winnr('$'))
+  Xclose
+endfunc
+
+func Test_view_result_split()
+  call Xview_result_split_tests('c')
+  call Xview_result_split_tests('l')
+endfunc
diff --git a/src/window.c b/src/window.c
index d3ec4cd..b79824b 100644
--- a/src/window.c
+++ b/src/window.c
@@ -520,23 +520,14 @@ wingotofile:
 		break;
 #endif
 
+/* Quickfix window only: view the result under the cursor in a new split. */
+#if defined(FEAT_QUI

Re: [patch] Fix bug with "CTRL-W " quickfix window command

[Jason Franklin]

Hey Yegappan,

I can certainly make these changes.  It shouldn't be too difficult... I'm
still learning best practices in the context of the Vim project.  Just
a moment.

-- Jason

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

Re: [patch] Fix bug with "CTRL-W " quickfix window command

[Yegappan Lakshmanan]

Hi,

On Tue, May 29, 2018 at 7:54 AM, Jason Franklin
 wrote:
> This patch fixes a minor bug with the quickfix window.  It also makes a small
> improvement and does some refactoring.
>
> To reproduce the bug:
>
>   vim -u NONE
>   :copen
>   
>
> ... note that you get an error message and a window still opens.  A window
> should not open.
>
> The refactoring is farily obvious.  Callbacks for "" and "CTRL-W " in
> the quickfix window are moved into "quickfix.c".  This seems like the natural
> place for these functions.
>
> The improvement is somewhat nice.  If the split succeeds, we clear the 
> jumplist
> in the new window with the ":clearjumps" command.  This means that we can't
> jump back to the quickfix list in the new window (we don't want two quickfix
> lists).
>
> As usual, a test is included to make sure that the bug remains fixed.
>

Some comments/suggestions about the patch:

Is it possible to merge the qf_view_result() and qf_view_result_split()
functions into a single function with a "split" argument?
Instead of using sprintf(), can you use vim_snprintf()?
In the test, can you use the g:Xsetlist, Xopen and Xclose command/function
and merge the test for quickfix and location list into a single test?

- Yegappan

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

Re: [patch] Fix bug with "CTRL-W " quickfix window command

[Jason Franklin]

Note that more can be done to fix up this command, but I didn't want to do too
much in one patch. 

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

[patch] Fix bug with "CTRL-W " quickfix window command

[Jason Franklin]

This patch fixes a minor bug with the quickfix window.  It also makes a small
improvement and does some refactoring.

To reproduce the bug:

  vim -u NONE
  :copen
  

... note that you get an error message and a window still opens.  A window
should not open.

The refactoring is farily obvious.  Callbacks for "" and "CTRL-W " in
the quickfix window are moved into "quickfix.c".  This seems like the natural
place for these functions.

The improvement is somewhat nice.  If the split succeeds, we clear the jumplist
in the new window with the ":clearjumps" command.  This means that we can't
jump back to the quickfix list in the new window (we don't want two quickfix
lists).

As usual, a test is included to make sure that the bug remains fixed.

-- 
-- 
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 received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
>From 1591f6a25c962ed58adad2211304a53da7170dbe Mon Sep 17 00:00:00 2001
From: Jason Franklin 
Date: Tue, 29 May 2018 10:40:45 -0400
Subject: [PATCH] Fix bug with "CTRL-W " quickfix window command

---
 src/normal.c  | 14 --
 src/proto/quickfix.pro|  2 ++
 src/quickfix.c| 44 +++
 src/testdir/test_quickfix.vim | 20 
 src/window.c  | 19 +--
 5 files changed, 75 insertions(+), 24 deletions(-)

diff --git a/src/normal.c b/src/normal.c
index 58f7a7a..9bd668f 100644
--- a/src/normal.c
+++ b/src/normal.c
@@ -6195,18 +6195,12 @@ nv_down(cmdarg_T *cap)
 	cap->arg = FORWARD;
 	nv_page(cap);
 }
-else
 #if defined(FEAT_QUICKFIX)
-/* In a quickfix window a  jumps to the error under the cursor. */
-if (bt_quickfix(curbuf) && cap->cmdchar == CAR)
-{
-	if (curwin->w_llist_ref == NULL)
-	do_cmdline_cmd((char_u *)".cc");	/* quickfix window */
-	else
-	do_cmdline_cmd((char_u *)".ll");	/* location list window */
-}
-else
+/* Quickfix window only: view the result under the cursor. */
+else if (bt_quickfix(curbuf) && cap->cmdchar == CAR)
+	qf_view_result();
 #endif
+else
 {
 #ifdef FEAT_CMDWIN
 	/* In the cmdline window a  executes the command. */
diff --git a/src/proto/quickfix.pro b/src/proto/quickfix.pro
index d32655f..6d41e57 100644
--- a/src/proto/quickfix.pro
+++ b/src/proto/quickfix.pro
@@ -7,6 +7,8 @@ void qf_list(exarg_T *eap);
 void qf_age(exarg_T *eap);
 void qf_history(exarg_T *eap);
 void qf_mark_adjust(win_T *wp, linenr_T line1, linenr_T line2, long amount, long amount_after);
+void qf_view_result();
+void qf_view_result_split();
 void ex_cwindow(exarg_T *eap);
 void ex_cclose(exarg_T *eap);
 void ex_copen(exarg_T *eap);
diff --git a/src/quickfix.c b/src/quickfix.c
index 1b281ce..3d52b11 100644
--- a/src/quickfix.c
+++ b/src/quickfix.c
@@ -3470,6 +3470,50 @@ qf_types(int c, int nr)
 }
 
 /*
+ * "": Open the entry/result under the cursor.
+ */
+void
+qf_view_result()
+{
+char_u  cmd[32];
+
+if (!bt_quickfix(curbuf))
+	return;
+
+sprintf((char *) cmd, ".%s", IS_LL_WINDOW(curwin) ? "ll" : "cc");
+
+do_cmdline_cmd(cmd);
+}
+
+/*
+ * "CTRL-W ": Open the entry/result under the cursor in a new split.
+ */
+void
+qf_view_result_split()
+{
+char_u  cmd[32];
+qf_info_T   *qi = _info;
+
+if (!bt_quickfix(curbuf))
+	return;
+
+if (IS_LL_WINDOW(curwin))
+	qi = GET_LOC_LIST(curwin);
+
+if (qi->qf_lists[qi->qf_curlist].qf_count == 0)
+{
+	EMSG(_(e_quickfix));
+	return;
+}
+
+sprintf((char *) cmd, "split +%ld%s", (long) curwin->w_cursor.lnum,
+	IS_LL_WINDOW(curwin) ? "ll" : "cc");
+
+if (do_cmdline_cmd(cmd) == OK)
+	do_cmdline_cmd((char_u *) "clearjumps");
+}
+
+/*
  * ":cwindow": open the quickfix window if we have errors to display,
  *	   close it if not.
  * ":lwindow": open the location list window if we have locations to display,
diff --git a/src/testdir/test_quickfix.vim b/src/testdir/test_quickfix.vim
index c3850ce..e131e8b 100644
--- a/src/testdir/test_quickfix.vim
+++ b/src/testdir/test_quickfix.vim
@@ -3350,3 +3350,23 @@ func Test_qftitle()
   call assert_equal('Errors', w:quickfix_title)
   cclose
 endfunc
+
+" Test for the "CTRL-W " command.
+func Test_qf_view_result_split()
+
+  " Test that "CTRL-W " in a quickfix window fails with empty list.
+  call setqflist([])
+  copen
+  let 

Re: Bug report: 'scrollbind' breaks when using mouse in xterm window

[Jason Franklin]

Thanks Marius!

> Both places should probably be updated to also mention the mouse wheel.

I see now that my initial idea was mistaken.  However, I noted in an email
directly to Bram that gvim on Microsoft Windows does not obey this behavior.
That is, both windows are scrolled regardless of which window has cursor focus.
Apparently this cannot be changed.

I agree that both places in the documentation should be updated to mention the
mousewheel, but I'm not sure about how to explain the MS Windows issue in the
docs.

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

Re: Bug report: 'scrollbind' breaks when using mouse in xterm window

[Bram Moolenaar]

Jason Franklin wrote:

> Reproduce as follows (I used Gnome Terminal):
> 
> vim -u NONE
> :set mouse=a
> :e [name of long file]
> :vsp
> :windo set scrollbind
> 
> Now, use the mouse wheel to try and scroll in both windows.  The window with
> cursor focus will scroll both windows properly, but not the other window,
> thus breaking the 'scrollbind' setting.
> 
> Unlike with my other patches, I don't see an obvious way to fix this issue
> and test it properly, so I figured I'd just report it and hope someone else
> picked it up.

This is intentional.  Previously it only worked this way in the GUI, bit
since most users like it the terminal was also made to work like this.

> Thanks for 8.1, by the way.  It's a treat!

Enjoy!



-- 
Mynd you, m00se bites Kan be pretty nasti ...
 "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

 /// 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_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 received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Bug report: 'scrollbind' breaks when using mouse in xterm window

[Jason Franklin]

Reproduce as follows (I used Gnome Terminal):

vim -u NONE
:set mouse=a
:e [name of long file]
:vsp
:windo set scrollbind

Now, use the mouse wheel to try and scroll in both windows.  The window with
cursor focus will scroll both windows properly, but not the other window,
thus breaking the 'scrollbind' setting.

Unlike with my other patches, I don't see an obvious way to fix this issue
and test it properly, so I figured I'd just report it and hope someone else
picked it up.

Thanks for 8.1, by the way.  It's a treat!

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

Re: Patch to have ":close" attempt to respect 'wfw' and 'wfh' settings (bug fix)

[Jason Franklin]

Hey Bram,

> Ah, this requires "set nosplitbelow nosplitright".

That's true for my example, but not true in general.  If you simply
reverse the orientation of my example, you can observe that the same
problem occurs while using the 'splitbelow' and 'splitright' settings.
I didn't want to include this because I didn't want to be redundant.
The patch will fix either case!

I'm one of the maintainers of the NERDTree, and this was originally
discovered by one of our users:

https://github.com/scrooloose/nerdtree/issues/644

He'll be happy to know that it's fixed!

Best,
Jason Franklin

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

Re: Patch to have ":close" attempt to respect 'wfw' and 'wfh' settings (bug fix)

[Bram Moolenaar]

Jason Franklin wrote:

> This patch improves upon the ":close" command by attempting to have it
> respect the 'winfixheight' and 'winfixwidth' settings whenever possible.
> 
> Two files are attached:
>   * example.vim - gives a summary of the bug
>   * fix_wf_close.patch - fixes both cases of the bug ('wfw' for 'wfh')
> 
> Tests are included to ensure that both versions of the problem remain
> fixed.  The example shows the problem using 'wfw', and the similar case
> for 'wfh' is then easy to deduce.

I like your work on this.  However, I cannot reproduce the problem you
describe.  I started with "vim --clean".  Perhaps you have some option
set or unset?

Ah, this requires "set nosplitbelow nosplitright".


Looks OK then, I'll fix the code style.


-- 
A mathematician is a device for turning coffee into theorems.
Paul Erdos
A computer programmer is a device for turning coffee into bugs.
Bram Moolenaar

 /// 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_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 received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Patch to have ":close" attempt to respect 'wfw' and 'wfh' settings (bug fix)

[Jason Franklin]

This patch improves upon the ":close" command by attempting to have it
respect the 'winfixheight' and 'winfixwidth' settings whenever possible.

Two files are attached:
  * example.vim - gives a summary of the bug
  * fix_wf_close.patch - fixes both cases of the bug ('wfw' for 'wfh')

Tests are included to ensure that both versions of the problem remain
fixed.  The example shows the problem using 'wfw', and the similar case
for 'wfh' is then easy to deduce.

Best,
Jason

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


example.vim
Description: Binary data
>From 9002f09dc8f89ba67d8b45e8ec3c5cb7b78dcecb Mon Sep 17 00:00:00 2001
From: Jason Franklin <j_...@fastmail.us>
Date: Fri, 4 May 2018 09:07:46 -0400
Subject: [PATCH] Make win_altframe() obey 'wfw' and 'wfh'

---
 src/testdir/test_winbuf_close.vim | 38 +++
 src/window.c  | 48 +++
 2 files changed, 71 insertions(+), 15 deletions(-)

diff --git a/src/testdir/test_winbuf_close.vim b/src/testdir/test_winbuf_close.vim
index ed64dd7..408b049 100644
--- a/src/testdir/test_winbuf_close.vim
+++ b/src/testdir/test_winbuf_close.vim
@@ -122,3 +122,41 @@ func Test_winbuf_close()
   call delete('Xtest2')
   call delete('Xtest3')
 endfunc
+
+" Test that ":close" will respect 'winfixheight' when possible.
+func Test_winfixheight_on_close()
+%bwipeout!
+set nosplitbelow nosplitright
+
+split | split | vsplit
+
+$wincmd w
+setlocal winfixheight
+let l:height = winheight(0)
+
+3close
+
+call assert_equal(l:height, winheight(0))
+
+%bwipeout!
+setlocal nowinfixheight
+endfunc
+
+" Test that ":close" will respect 'winfixwidth' when possible.
+func Test_winfixwidth_on_close()
+%bwipeout!
+set nosplitbelow nosplitright
+
+vsplit | vsplit | split
+
+$wincmd w
+setlocal winfixwidth
+let l:width = winwidth(0)
+
+3close
+
+call assert_equal(l:width, winwidth(0))
+
+%bwipeout!
+setlocal nowinfixwidth
+endfunction
diff --git a/src/window.c b/src/window.c
index 333663b..1d93586 100644
--- a/src/window.c
+++ b/src/window.c
@@ -2740,12 +2740,14 @@ winframe_remove(
 }
 
 /*
- * Find out which frame is going to get the freed up space when "win" is
- * closed.
- * if 'splitbelow'/'splitleft' the space goes to the window above/left.
- * if 'nosplitbelow'/'nosplitleft' the space goes to the window below/right.
- * This makes opening a window and closing it immediately keep the same window
- * layout.
+ * Return a pointer to the frame that will receive the empty screen space that
+ * is left over after "win" is closed.
+ *
+ * If 'splitbelow' or 'splitright' is set, the space goes above or to the left
+ * by default.  Otherwise, the free space goes below or to the right.  The
+ * result is that opening a window and then immediately closing it will
+ * preserve the initial window layout.  The 'wfh' and 'wfw' settings are
+ * respected when possible.
  */
 static frame_T *
 win_altframe(
@@ -2753,20 +2755,36 @@ win_altframe(
 tabpage_T	*tp)		/* tab page "win" is in, NULL for current */
 {
 frame_T	*frp;
-int		b;
+frame_T	*other_fr, *target_fr;
 
 if (tp == NULL ? ONE_WINDOW : tp->tp_firstwin == tp->tp_lastwin)
-	/* Last window in this tab page, will go to next tab page. */
 	return alt_tabpage()->tp_curwin->w_frame;
 
 frp = win->w_frame;
-if (frp->fr_parent != NULL && frp->fr_parent->fr_layout == FR_ROW)
-	b = p_spr;
-else
-	b = p_sb;
-if ((!b && frp->fr_next != NULL) || frp->fr_prev == NULL)
-	return frp->fr_next;
-return frp->fr_prev;
+
+if (frp->fr_next == NULL || frp->fr_prev == NULL)
+	return frp->fr_next ? frp->fr_next : frp->fr_prev;
+
+other_fr  = frp->fr_prev;
+target_fr = frp->fr_next;
+
+if (p_spr || p_sb) {
+	other_fr  = frp->fr_next;
+	target_fr = frp->fr_prev;
+}
+
+/* If 'wfh' or 'wfw' is set for the target and not for the alternate
+ * window, reverse the selection. */
+if (frp->fr_parent != NULL && frp->fr_parent->fr_layout == FR_ROW) {
+	if (frame_fixed_width(target_fr) && !frame_fixed_width(other_fr))
+	target_fr = other_fr;
+}
+else {
+	if (frame_fixed_height(target_fr) && !frame_fixed_height(other_fr))
+	target_fr = other_fr;
+}
+
+return target_fr;
 }
 
 /*
-- 
2.7.4

Re: [bug] heap-use-after-free with asan when running test_terminal.vim

[Dominique Pellé]

;   0x0c488005af60: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
>>   0x0c488005af70: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
>>   0x0c488005af80: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
>>   0x0c488005af90: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
>> =>0x0c488005afa0: fd fd fd fd fd fd fd[fd]fa fa fa fa fa fa fa fa
>>   0x0c488005afb0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>>   0x0c488005afc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>>   0x0c488005afd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>>   0x0c488005afe0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>>   0x0c488005aff0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>> Shadow byte legend (one shadow byte represents 8 application bytes):
>>   Addressable:   00
>>   Partially addressable: 01 02 03 04 05 06 07
>>   Heap left redzone:   fa
>>   Freed heap region:   fd
>>   Stack left redzone:  f1
>>   Stack mid redzone:   f2
>>   Stack right redzone: f3
>>   Stack after return:  f5
>>   Stack use after scope:   f8
>>   Global redzone:  f9
>>   Global init order:   f6
>>   Poisoned by user:f7
>>   Container overflow:  fc
>>   Array cookie:ac
>>   Intra object redzone:bb
>>   ASan internal:   fe
>>   Left alloca redzone: ca
>>   Right alloca redzone:cb
>> ==6221==ABORTING
>> Vim: Caught deadly signal ABRT
>> Vim: Finished.
>> Aborted (core dumped)
>>
>> Code where error is detected (terminal.c:3226)
>>
>> !!3226 while (buf->b_term != NULL && !buf->b_term->tl_channel_closed)
>>   3227 {
>>   3228 mch_check_messages();
>> !!3229 parse_queued_messages();
>>   3230 ui_delay(10L, FALSE);
>>   3231 }
>>
>> Memory was freed when calling parse_queued_message()
>> at line 3229 and then free memory is used at line 3226
>> in terminal.c.
>>
>> I ran "make test" 3 times and bug happened 3 times
>> i a row so it looks reproducible for me.
>>
>> I suspect that it's the same bug that happened
>> in travis there (but the stack did not have symbols):
>>
>> https://travis-ci.org/vim/vim/jobs/302986849
>
> I cannot reproduce the problem with valgrind, there probably is a race
> condition and valgrind is a lot slower.
>
> I'll add a check that the buffer still exists.  There are other ways,
> such as postponing wiping out the buffer, but then there can still be an
> autocommand doing something similar.


Thank. Vim-8.0.1317 appears to fix it.  I ran the test several
times without error.

Going back to Vim-8.0.1316 I could reproduce it with gcc-7 + asan
but I could not reproduce it with clang-5.0 + asan or with valgrind.
It was perhaps a race condition indeed.

Thanks
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

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

Re: [bug] heap-use-after-free with asan when running test_terminal.vim

[Bram Moolenaar]

fa fa fa fa fa fa fa fa fa
> Shadow byte legend (one shadow byte represents 8 application bytes):
>   Addressable:   00
>   Partially addressable: 01 02 03 04 05 06 07
>   Heap left redzone:   fa
>   Freed heap region:   fd
>   Stack left redzone:  f1
>   Stack mid redzone:   f2
>   Stack right redzone: f3
>   Stack after return:  f5
>   Stack use after scope:   f8
>   Global redzone:  f9
>   Global init order:   f6
>   Poisoned by user:f7
>   Container overflow:  fc
>   Array cookie:ac
>   Intra object redzone:bb
>   ASan internal:   fe
>   Left alloca redzone: ca
>   Right alloca redzone:cb
> ==6221==ABORTING
> Vim: Caught deadly signal ABRT
> Vim: Finished.
> Aborted (core dumped)
> 
> Code where error is detected (terminal.c:3226)
> 
> !!3226 while (buf->b_term != NULL && !buf->b_term->tl_channel_closed)
>   3227 {
>   3228 mch_check_messages();
> !!3229 parse_queued_messages();
>   3230 ui_delay(10L, FALSE);
>   3231 }
> 
> Memory was freed when calling parse_queued_message()
> at line 3229 and then free memory is used at line 3226
> in terminal.c.
> 
> I ran "make test" 3 times and bug happened 3 times
> i a row so it looks reproducible for me.
> 
> I suspect that it's the same bug that happened
> in travis there (but the stack did not have symbols):
> 
> https://travis-ci.org/vim/vim/jobs/302986849

I cannot reproduce the problem with valgrind, there probably is a race
condition and valgrind is a lot slower.

I'll add a check that the buffer still exists.  There are other ways,
such as postponing wiping out the buffer, but then there can still be an
autocommand doing something similar.

-- 
The goal of science is to build better mousetraps.
The goal of nature is to build better mice.

 /// 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_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 received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[bug] heap-use-after-free with asan when running test_terminal.vim

[Dominique Pellé]

; !buf->b_term->tl_channel_closed)
  3227 {
  3228 mch_check_messages();
!!3229 parse_queued_messages();
  3230 ui_delay(10L, FALSE);
  3231 }

Memory was freed when calling parse_queued_message()
at line 3229 and then free memory is used at line 3226
in terminal.c.

I ran "make test" 3 times and bug happened 3 times
i a row so it looks reproducible for me.

I suspect that it's the same bug that happened
in travis there (but the stack did not have symbols):

https://travis-ci.org/vim/vim/jobs/302986849

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

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

[bug] heap-use-after-free when running tests from test_matchadd_conceal

[Dominique Pellé]

Hi

Running Vim tests with (vim-8.0.1216, latest in git) built
with asan aborts with this error:

Vim: Caught deadly signal ABRT_conceal_with_syntax_off()
Vim: preserving files...
Vim: Finished.

=
==9549==ERROR: AddressSanitizer: heap-use-after-free on address
0x62400027db70 at pc 0x00a442fb bp 0x7fffb66e4700 sp
0x7fffb66e46f0
READ of size 8 at 0x62400027db70 thread T0
#0 0xa442fa in syn_stack_find_entry /home/dope/sb/vim/src/syntax.c:1454
#1 0xa46cb8 in syntax_end_parsing /home/dope/sb/vim/src/syntax.c:1715
#2 0x93d0b2 in win_update /home/dope/sb/vim/src/screen.c:2178
#3 0x930fa6 in update_screen /home/dope/sb/vim/src/screen.c:756
#4 0x5cdca3 in ex_redraw /home/dope/sb/vim/src/ex_docmd.c:9721
#5 0x599fce in do_one_cmd /home/dope/sb/vim/src/ex_docmd.c:2908
#6 0x58c5fc in do_cmdline /home/dope/sb/vim/src/ex_docmd.c:1071
#7 0xb0abd8 in call_user_func /home/dope/sb/vim/src/userfunc.c:942
#8 0xb0e3c3 in call_func /home/dope/sb/vim/src/userfunc.c:1427
#9 0xb07086 in get_func_tv /home/dope/sb/vim/src/userfunc.c:455
#10 0xb1c74d in ex_call /home/dope/sb/vim/src/userfunc.c:3082
#11 0x599fce in do_one_cmd /home/dope/sb/vim/src/ex_docmd.c:2908
#12 0x58c5fc in do_cmdline /home/dope/sb/vim/src/ex_docmd.c:1071
#13 0x4d8e8a in ex_execute /home/dope/sb/vim/src/eval.c:8344
#14 0x599fce in do_one_cmd /home/dope/sb/vim/src/ex_docmd.c:2908
#15 0x58c5fc in do_cmdline /home/dope/sb/vim/src/ex_docmd.c:1071
#16 0xb0abd8 in call_user_func /home/dope/sb/vim/src/userfunc.c:942
#17 0xb0e3c3 in call_func /home/dope/sb/vim/src/userfunc.c:1427
#18 0xb07086 in get_func_tv /home/dope/sb/vim/src/userfunc.c:455
#19 0xb1c74d in ex_call /home/dope/sb/vim/src/userfunc.c:3082
#20 0x599fce in do_one_cmd /home/dope/sb/vim/src/ex_docmd.c:2908
#21 0x58c5fc in do_cmdline /home/dope/sb/vim/src/ex_docmd.c:1071
#22 0x584a8e in do_source /home/dope/sb/vim/src/ex_cmds2.c:4355
#23 0x582f0d in cmd_source /home/dope/sb/vim/src/ex_cmds2.c:3968
#24 0x582c35 in ex_source /home/dope/sb/vim/src/ex_cmds2.c:3943
#25 0x599fce in do_one_cmd /home/dope/sb/vim/src/ex_docmd.c:2908
#26 0x58c5fc in do_cmdline /home/dope/sb/vim/src/ex_docmd.c:1071
#27 0x58aa8a in do_cmdline_cmd /home/dope/sb/vim/src/ex_docmd.c:671
#28 0xc7d3bb in exe_commands /home/dope/sb/vim/src/main.c:2955
#29 0xc72bf6 in vim_main2 /home/dope/sb/vim/src/main.c:800
#30 0xc720d1 in main /home/dope/sb/vim/src/main.c:429
#31 0x7f6da1b8882f in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
#32 0x412458 in _start (/home/dope/sb/vim/src/vim+0x412458)

0x62400027db70 is located 6768 bytes inside of 7224-byte region
[0x62400027c100,0x62400027dd38)
freed by thread T0 here:
#0 0x7f6da6b84588 in free (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xde588)
#1 0x75549a in vim_free /home/dope/sb/vim/src/misc2.c:1801
#2 0x418585 in free_buffer /home/dope/sb/vim/src/buffer.c:883
#3 0x4171e5 in close_buffer /home/dope/sb/vim/src/buffer.c:678
#4 0x41b12e in do_buffer /home/dope/sb/vim/src/buffer.c:1462
#5 0x419795 in do_bufdel /home/dope/sb/vim/src/buffer.c:1128
#6 0x5afa23 in ex_bunload /home/dope/sb/vim/src/ex_docmd.c:5535
#7 0x599fce in do_one_cmd /home/dope/sb/vim/src/ex_docmd.c:2908
#8 0x58c5fc in do_cmdline /home/dope/sb/vim/src/ex_docmd.c:1071
#9 0xb0abd8 in call_user_func /home/dope/sb/vim/src/userfunc.c:942
#10 0xb0e3c3 in call_func /home/dope/sb/vim/src/userfunc.c:1427
#11 0xb07086 in get_func_tv /home/dope/sb/vim/src/userfunc.c:455
#12 0xb1c74d in ex_call /home/dope/sb/vim/src/userfunc.c:3082
#13 0x599fce in do_one_cmd /home/dope/sb/vim/src/ex_docmd.c:2908
#14 0x58c5fc in do_cmdline /home/dope/sb/vim/src/ex_docmd.c:1071
#15 0x584a8e in do_source /home/dope/sb/vim/src/ex_cmds2.c:4355
#16 0x582f0d in cmd_source /home/dope/sb/vim/src/ex_cmds2.c:3968
#17 0x582c35 in ex_source /home/dope/sb/vim/src/ex_cmds2.c:3943
#18 0x599fce in do_one_cmd /home/dope/sb/vim/src/ex_docmd.c:2908
#19 0x58c5fc in do_cmdline /home/dope/sb/vim/src/ex_docmd.c:1071
#20 0x58aa8a in do_cmdline_cmd /home/dope/sb/vim/src/ex_docmd.c:671
#21 0xc7d3bb in exe_commands /home/dope/sb/vim/src/main.c:2955
#22 0xc72bf6 in vim_main2 /home/dope/sb/vim/src/main.c:800
#23 0xc720d1 in main /home/dope/sb/vim/src/main.c:429
#24 0x7f6da1b8882f in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x2082f)

previously allocated by thread T0 here:
#0 0x7f6da6b84920 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xde920)
#1 0x752079 in lalloc /home/dope/sb/vim/src/misc2.c:954
#2 0x751f42 in alloc_clear /home/dope/sb/vim/src/misc2.c:876
#3 0x41e506 in buflist_new /home/dope/sb/vim/src/buffer.c:2001
#4 0x548758 in do_ecmd /home/dope/sb/vim/src/ex_cmds.c:3846
#5 0x5c581e in do_exedit /home/dope/sb/vim/src/ex_docmd.c:8637
#6 

Re: [bug] access to free memory with -DEXITFREE

[Bram Moolenaar]

Dominique wrote:

> The following script found by afl-fuzz causes
> vim-8.0.1213 (huge) and older to access free
> memory when built with -DEXITFREE:
> 
> $ cat bug.vim
> tabedit
> sp X
> sp
> au WinLeave X tabnext
> close
> qa
> 
> $ valgrind --num-callers=30 vim -u NONE -S bug.vim 2> vg.log
> 
> And vg.log contains:
> 
> ==14381== Memcheck, a memory error detector
> ==14381== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
> ==14381== Using Valgrind-3.14.0.GIT and LibVEX; rerun with -h for copyright 
> info
> ==14381== Command: vim -u NONE -S bug.vim
> ==14381==
> ==14381== Invalid read of size 1
> ==14381==at 0x4C30A12: strlen (vg_replace_strmem.c:458)
> ==14381==by 0x4D581D: vim_strsave (misc2.c:1290)
> ==14381==by 0x50AEE6: buf_copy_options (option.c:11083)
> ==14381==by 0x5B09A9: win_enter_ext (window.c:4392)
> ==14381==by 0x5B0C58: enter_tabpage (window.c:3912)
> ==14381==by 0x5B4266: close_last_window_tabpage.part.20 (window.c:2239)
> ==14381==by 0x5B4729: close_last_window_tabpage (window.c:2364)
> ==14381==by 0x5B4729: win_close (window.c:2311)
> ==14381==by 0x46E2E8: ex_win_close (ex_docmd.c:7418)
> ==14381==by 0x473D3F: tabpage_close (ex_docmd.c:7622)
> ==14381==by 0x5B6221: win_free_all (window.c:2599)
> ==14381==by 0x4D8F3B: free_all_mem (misc2.c:1197)
> ==14381==by 0x512F08: mch_exit (os_unix.c:3371)
> ==14381==by 0x5F27EA: getout (main.c:1544)
> ==14381==by 0x470A61: ex_quit_all (ex_docmd.c:7320)
> ==14381==by 0x477723: do_one_cmd (ex_docmd.c:2908)
> ==14381==by 0x477723: do_cmdline (ex_docmd.c:1071)
> ==14381==by 0x46AFEB: do_source (ex_cmds2.c:4355)
> ==14381==by 0x46BB2B: cmd_source (ex_cmds2.c:3968)
> ==14381==by 0x477723: do_one_cmd (ex_docmd.c:2908)
> ==14381==by 0x477723: do_cmdline (ex_docmd.c:1071)
> ==14381==by 0x5F44F0: exe_commands (main.c:2955)
> ==14381==by 0x5F44F0: vim_main2 (main.c:800)
> ==14381==by 0x413E41: main (main.c:429)
> ==14381==  Address 0x10db57d0 is 0 bytes inside a block of size 12 free'd
> ==14381==at 0x4C2ECF0: free (vg_replace_malloc.c:530)
> ==14381==by 0x5030A9: free_string_option (option.c:5715)
> ==14381==by 0x5030A9: free_all_options (option.c:3892)
> ==14381==by 0x4D8E11: free_all_mem (misc2.c:1138)
> ==14381==by 0x512F08: mch_exit (os_unix.c:3371)
> ==14381==by 0x5F27EA: getout (main.c:1544)
> ==14381==by 0x470A61: ex_quit_all (ex_docmd.c:7320)
> ==14381==by 0x477723: do_one_cmd (ex_docmd.c:2908)
> ==14381==by 0x477723: do_cmdline (ex_docmd.c:1071)
> ==14381==by 0x46AFEB: do_source (ex_cmds2.c:4355)
> ==14381==by 0x46BB2B: cmd_source (ex_cmds2.c:3968)
> ==14381==by 0x477723: do_one_cmd (ex_docmd.c:2908)
> ==14381==by 0x477723: do_cmdline (ex_docmd.c:1071)
> ==14381==by 0x5F44F0: exe_commands (main.c:2955)
> ==14381==by 0x5F44F0: vim_main2 (main.c:800)
> ==14381==by 0x413E41: main (main.c:429)
> ==14381==  Block was alloc'd at
> ==14381==at 0x4C2DBF6: malloc (vg_replace_malloc.c:299)
> ==14381==by 0x4D4DE0: lalloc (misc2.c:954)
> ==14381==by 0x4D582D: alloc (misc2.c:852)
> ==14381==by 0x4D582D: vim_strsave (misc2.c:1291)
> ==14381==by 0x50037D: set_string_option_global (option.c:5901)
> ==14381==by 0x5045F1: set_string_option_direct (option.c:5865)
> ==14381==by 0x5048B3: set_option_default (option.c:3746)
> ==14381==by 0x50496B: set_options_default (option.c:3822)
> ==14381==by 0x50FA2C: set_init_1 (option.c:3520)
> ==14381==by 0x5F2F65: common_init (main.c:1027)
> ==14381==by 0x41374B: main (main.c:173)
> ...snip many other errors after that...
> 
> Sorry, no patch, not sure how to fix it.

Thanks.  Quite a tricky script.

Freeing options later helps.  But uncovers another problem.
Skipping redraw when exiting appears to fix that one.
I'll make a patch.

-- 
ARTHUR:  You fight with the strength of many men, Sir knight.
 I am Arthur, King of the Britons.  [pause]
 I seek the finest and the bravest knights in the land to join me
 in my Court of Camelot.  [pause]
 You have proved yourself worthy; will you join me?  [pause]
 You make me sad.  So be it.  Come, Patsy.
BLACK KNIGHT:  None shall pass.
  The Quest for the Holy Grail (Monty Python)

 /// 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_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 received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and 

[bug] access to free memory with -DEXITFREE

[Dominique Pellé]

Hi

The following script found by afl-fuzz causes
vim-8.0.1213 (huge) and older to access free
memory when built with -DEXITFREE:

$ cat bug.vim
tabedit
sp X
sp
au WinLeave X tabnext
close
qa

$ valgrind --num-callers=30 vim -u NONE -S bug.vim 2> vg.log

And vg.log contains:

==14381== Memcheck, a memory error detector
==14381== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==14381== Using Valgrind-3.14.0.GIT and LibVEX; rerun with -h for copyright info
==14381== Command: vim -u NONE -S bug.vim
==14381==
==14381== Invalid read of size 1
==14381==at 0x4C30A12: strlen (vg_replace_strmem.c:458)
==14381==by 0x4D581D: vim_strsave (misc2.c:1290)
==14381==by 0x50AEE6: buf_copy_options (option.c:11083)
==14381==by 0x5B09A9: win_enter_ext (window.c:4392)
==14381==by 0x5B0C58: enter_tabpage (window.c:3912)
==14381==by 0x5B4266: close_last_window_tabpage.part.20 (window.c:2239)
==14381==by 0x5B4729: close_last_window_tabpage (window.c:2364)
==14381==by 0x5B4729: win_close (window.c:2311)
==14381==by 0x46E2E8: ex_win_close (ex_docmd.c:7418)
==14381==by 0x473D3F: tabpage_close (ex_docmd.c:7622)
==14381==by 0x5B6221: win_free_all (window.c:2599)
==14381==by 0x4D8F3B: free_all_mem (misc2.c:1197)
==14381==by 0x512F08: mch_exit (os_unix.c:3371)
==14381==by 0x5F27EA: getout (main.c:1544)
==14381==by 0x470A61: ex_quit_all (ex_docmd.c:7320)
==14381==by 0x477723: do_one_cmd (ex_docmd.c:2908)
==14381==by 0x477723: do_cmdline (ex_docmd.c:1071)
==14381==by 0x46AFEB: do_source (ex_cmds2.c:4355)
==14381==by 0x46BB2B: cmd_source (ex_cmds2.c:3968)
==14381==by 0x477723: do_one_cmd (ex_docmd.c:2908)
==14381==by 0x477723: do_cmdline (ex_docmd.c:1071)
==14381==by 0x5F44F0: exe_commands (main.c:2955)
==14381==by 0x5F44F0: vim_main2 (main.c:800)
==14381==by 0x413E41: main (main.c:429)
==14381==  Address 0x10db57d0 is 0 bytes inside a block of size 12 free'd
==14381==at 0x4C2ECF0: free (vg_replace_malloc.c:530)
==14381==by 0x5030A9: free_string_option (option.c:5715)
==14381==by 0x5030A9: free_all_options (option.c:3892)
==14381==by 0x4D8E11: free_all_mem (misc2.c:1138)
==14381==by 0x512F08: mch_exit (os_unix.c:3371)
==14381==by 0x5F27EA: getout (main.c:1544)
==14381==by 0x470A61: ex_quit_all (ex_docmd.c:7320)
==14381==by 0x477723: do_one_cmd (ex_docmd.c:2908)
==14381==by 0x477723: do_cmdline (ex_docmd.c:1071)
==14381==by 0x46AFEB: do_source (ex_cmds2.c:4355)
==14381==by 0x46BB2B: cmd_source (ex_cmds2.c:3968)
==14381==by 0x477723: do_one_cmd (ex_docmd.c:2908)
==14381==by 0x477723: do_cmdline (ex_docmd.c:1071)
==14381==by 0x5F44F0: exe_commands (main.c:2955)
==14381==by 0x5F44F0: vim_main2 (main.c:800)
==14381==by 0x413E41: main (main.c:429)
==14381==  Block was alloc'd at
==14381==at 0x4C2DBF6: malloc (vg_replace_malloc.c:299)
==14381==by 0x4D4DE0: lalloc (misc2.c:954)
==14381==by 0x4D582D: alloc (misc2.c:852)
==14381==by 0x4D582D: vim_strsave (misc2.c:1291)
==14381==by 0x50037D: set_string_option_global (option.c:5901)
==14381==by 0x5045F1: set_string_option_direct (option.c:5865)
==14381==by 0x5048B3: set_option_default (option.c:3746)
==14381==by 0x50496B: set_options_default (option.c:3822)
==14381==by 0x50FA2C: set_init_1 (option.c:3520)
==14381==by 0x5F2F65: common_init (main.c:1027)
==14381==by 0x41374B: main (main.c:173)
...snip many other errors after that...

Sorry, no patch, not sure how to fix it.

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

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

Re: apparent bug or oddity in fortran indent

[fulvio ciriaco]

Il giorno venerdì 13 ottobre 2017 08:43:12 UTC+2, Christian Brabandt ha scritto:
> On Do, 12 Okt 2017, fulvio ciriaco wrote:
> 
> > Dear Vim developers,
> > fortran vim indentation indents "class" in a very strage manner:
> > 
> >   function antecedente_costante(self)
> >   class(t_costante) :: self
> > real(dp):: antecedente_costante
> >   end function antecedente_costante
> > 
> > instead of
> > 
> >   function antecedente_costante(self)
> > class(t_costante) :: self
> > real(dp):: antecedente_costante
> >   end function antecedente_costante
> > 
> > Indeed all lines beginning with "class" are back indented.
> > Best regards and thanks for vim
> 
> Are you using the custom indent plugin (e.g. :filetype plugin indent 
> on)?
> 
> If so, please contact the maintainer of the file 
> $VIMRUNTIME/indent/fortran.vim who is mentioned at the top of the file.
> 
> But first please test with the latest version available.
> 
> 
> Christian
> -- 
> Frauen sind wie Milch, wenn Man(n) sie stehen läßt, werden sie sauer.

Yes, indent plugin is on and all other indentation works fine.
Vim version is 8.0 with patchsets 1-1144, from debian distribution.
I will follow your advice and contact Ajit.

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

Re: apparent bug or oddity in fortran indent

[Christian Brabandt]

On Do, 12 Okt 2017, fulvio ciriaco wrote:

> Dear Vim developers,
> fortran vim indentation indents "class" in a very strage manner:
> 
>   function antecedente_costante(self)
>   class(t_costante) :: self
> real(dp):: antecedente_costante
>   end function antecedente_costante
> 
> instead of
> 
>   function antecedente_costante(self)
> class(t_costante) :: self
> real(dp):: antecedente_costante
>   end function antecedente_costante
> 
> Indeed all lines beginning with "class" are back indented.
> Best regards and thanks for vim

Are you using the custom indent plugin (e.g. :filetype plugin indent 
on)?

If so, please contact the maintainer of the file 
$VIMRUNTIME/indent/fortran.vim who is mentioned at the top of the file.

But first please test with the latest version available.


Christian
-- 
Frauen sind wie Milch, wenn Man(n) sie stehen läßt, werden sie sauer.

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

apparent bug or oddity in fortran indent

[fulvio ciriaco]

Dear Vim developers,
fortran vim indentation indents "class" in a very strage manner:

  function antecedente_costante(self)
  class(t_costante) :: self
real(dp):: antecedente_costante
  end function antecedente_costante

instead of

  function antecedente_costante(self)
class(t_costante) :: self
real(dp):: antecedente_costante
  end function antecedente_costante

Indeed all lines beginning with "class" are back indented.
Best regards and thanks for vim

Fulvio Ciriaco

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

Re: fix matchit bug

[Christian Brabandt]

On Sa, 16 Sep 2017, Ken Takata wrote:

> Seeing Benji's repository, the latest commit was 6 months ago:
> https://github.com/benjifisher/matchit.zip
> 
> I'm not sure he actually abandoned it.
> Isn't it better to ask him before taking over?

Oh it looks still maintained, I did not know. I asked for clarification:
https://github.com/benjifisher/matchit.zip/issues/10


Best,
Christian
-- 
Beim Beginnen eine Unternehmung und unweit des Zieles ist die Gefahr
des Mißlingens am größten. - Wenn Schiffe scheitern, so geschieht es
nahe am Ufer.
-- Ludwig Börne

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

Re: fix matchit bug

[Ken Takata]

Hi,

2017/9/17 Sun 3:32:14 UTC+9 Christian Brabandt wrote:
> On Sa, 16 Sep 2017, Bram Moolenaar wrote:
> 
> > It looks like Benji abandoned this.  Perhaps someone can take over
> > maintenance?
> 
> I can do it.

Seeing Benji's repository, the latest commit was 6 months ago:
https://github.com/benjifisher/matchit.zip

I'm not sure he actually abandoned it.
Isn't it better to ask him before taking over?

Regards,
Ken Takata

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

Re: fix matchit bug

[Christian Brabandt]

On Sa, 16 Sep 2017, Bram Moolenaar wrote:

> It looks like Benji abandoned this.  Perhaps someone can take over
> maintenance?

I can do it.

Best,
Christian
-- 
Im Leben kommt es darauf an zu lernen, ohne die anderen merken zu lassen,
daß man lernt.

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

Re: fix matchit bug

[Bram Moolenaar]

Christian Brabandt wrote:

> On Fr, 15 Sep 2017, Bram Moolenaar wrote:
> 
> > Thanks.  I'll include it.
> > 
> > Hmm, there is quite a bit of half finished and commented-out code.
> > I'll remove a few lines, but some more cleanup should be done.
> 
> Well, there is still #955 laying around, that cleans up quite some of 
> those normal mode command and instead uses winsaveview() which is a lot 
> clearer.
> 
> There have been some patches sent in the past to vim-dev from various 
> people (me included) that have not been included so matchit has been 
> started to bit rot a little.

It looks like Benji abandoned this.  Perhaps someone can take over
maintenance?

-- 
All true wisdom is found on T-shirts.

 /// 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_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 received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: fix matchit bug

[Christian Brabandt]

On Fr, 15 Sep 2017, Bram Moolenaar wrote:

> Thanks.  I'll include it.
> 
> Hmm, there is quite a bit of half finished and commented-out code.
> I'll remove a few lines, but some more cleanup should be done.

Well, there is still #955 laying around, that cleans up quite some of 
those normal mode command and instead uses winsaveview() which is a lot 
clearer.

There have been some patches sent in the past to vim-dev from various 
people (me included) that have not been included so matchit has been 
started to bit rot a little.

Best,
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

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

Re: fix matchit bug

[Bram Moolenaar]

Christian Brabandt wrote:

> Bram,
> there is a bug in the matchit plugin. It makes use of the v:count1 
> variable in the function s:MultiMatch(). However when it accesses the 
> variable, it might be reset from the previous normal mode commands for 
> restoring the cursor position. So save it a little bit earlier:
> 
> 
> diff --git a/runtime/pack/dist/opt/matchit/plugin/matchit.vim 
> b/runtime/pack/dist/opt/matchit/plugin/matchit.vim
> index 4c9b845..7165067 100644
> --- a/runtime/pack/dist/opt/matchit/plugin/matchit.vim
> +++ b/runtime/pack/dist/opt/matchit/plugin/matchit.vim
> @@ -704,6 +704,8 @@ fun! s:MultiMatch(spflag, mode)
>  let skip = 's:comment\|string'
>endif
>let skip = s:ParseSkip(skip)
> +  " save v:count1 variable, might be reset from the restore_cursor command
> +  let level = v:count1
>" let restore_cursor = line(".") . "G" . virtcol(".") . "|"
>" normal! H
>" let restore_cursor = "normal!" . line(".") . "Gzt" . restore_cursor
> @@ -726,7 +728,6 @@ fun! s:MultiMatch(spflag, mode)
>  execute "if " . skip . "| let skip = '0' | endif"
>endif
>mark '
> -  let level = v:count1
>while level
>  if searchpair(openpat, '', closepat, a:spflag, skip) < 1
>call s:CleanUp(restore_options, a:mode, startline, startcol)
> 
> 
> CC'ing Benji, not sure if he reads his mail, I haven't heard from him in 
> a long while.

Thanks.  I'll include it.

Hmm, there is quite a bit of half finished and commented-out code.
I'll remove a few lines, but some more cleanup should be done.

-- 
You cannot have a baby in one month by getting nine women pregnant.

 /// 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_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 received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

fix matchit bug

[Christian Brabandt]

Bram,
there is a bug in the matchit plugin. It makes use of the v:count1 
variable in the function s:MultiMatch(). However when it accesses the 
variable, it might be reset from the previous normal mode commands for 
restoring the cursor position. So save it a little bit earlier:


diff --git a/runtime/pack/dist/opt/matchit/plugin/matchit.vim 
b/runtime/pack/dist/opt/matchit/plugin/matchit.vim
index 4c9b845..7165067 100644
--- a/runtime/pack/dist/opt/matchit/plugin/matchit.vim
+++ b/runtime/pack/dist/opt/matchit/plugin/matchit.vim
@@ -704,6 +704,8 @@ fun! s:MultiMatch(spflag, mode)
 let skip = 's:comment\|string'
   endif
   let skip = s:ParseSkip(skip)
+  " save v:count1 variable, might be reset from the restore_cursor command
+  let level = v:count1
   " let restore_cursor = line(".") . "G" . virtcol(".") . "|"
   " normal! H
   " let restore_cursor = "normal!" . line(".") . "Gzt" . restore_cursor
@@ -726,7 +728,6 @@ fun! s:MultiMatch(spflag, mode)
 execute "if " . skip . "| let skip = '0' | endif"
   endif
   mark '
-  let level = v:count1
   while level
 if searchpair(openpat, '', closepat, a:spflag, skip) < 1
   call s:CleanUp(restore_options, a:mode, startline, startcol)



CC'ing Benji, not sure if he reads his mail, I haven't heard from him in 
a long while.

Best,
Christian
-- 
Besser heimlich schlau als unheimlich blöd.

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

Re: Possible bug C++ string literal and cindent feature

[Bart Louwers]

I filed this as a bug https://github.com/vim/vim/issues/2019

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

Re: Possible bug C++ string literal and cindent feature

[Bart Louwers]

I was intended to to refer to the *raw* string literal specifically. So (6) on 
this list. http://en.cppreference.com/w/cpp/language/string_literal E.g. 
R"(test)"

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

Re: Bug: read from free'd memory when jumping from a quickfix list

[Yegappan Lakshmanan]

Hi,

On Sun, Aug 20, 2017 at 3:54 AM, Wuh Orp  wrote:
> Having read this thread and encountered the same issues myself in ALE,
> I can confidently say that LCD had a lot of really valid points here,
> and this should be examined again.
>
> The problem is that plugins like Syntastic and ALE want to be able to
> check buffers for errors when you open them. This is implemented
> through autocmd events of course. The problem with the current set of
> patches is that you will see an annoying error message when you switch
> from one buffer to another by selecting an item in the location list
> or the quickfix list, because changing the lists through the autocmd
> events that Syntastic or ALE uses will trigger the error.
>
> The solution seems to be to delay execution of autocmd events until
> after quickfix has finished jumping from one buffer to another, and
> then execute autocmd events only after quickfix has finished moving
> from one buffer to another. Theoretically, this should fix the
> original segfault issue, and remove the need for the error saying the
> list was changed.
>

The recent set of changes to the quickfix functionality allows a plugin
to create or modify a quickfix/location list without changing the current
quickfix list. So when a buffer is opened, the above plugins can create a
new location list and populate the entries into the list without changing
the current list. Will this approach solve this problem?

- Yegappan

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

Re: Bug: read from free'd memory when jumping from a quickfix list

[Dominique Pellé]

Christian Brabandt <cbli...@256bit.org> wrote:

> On So, 20 Aug 2017, Wuh Orp wrote:
>
>> Having read this thread and encountered the same issues myself in ALE, I can 
>> confidently say that LCD had a lot of really valid points here, and this 
>> should be examined again.
>>
>> The problem is that plugins like Syntastic and ALE want to be able to check 
>> buffers for errors when you open them. This is implemented through autocmd 
>> events of course. The problem with the current set of patches is that you 
>> will see an annoying error message when you switch from one buffer to 
>> another by selecting an item in the location list or the quickfix list, 
>> because changing the lists through the autocmd events that Syntastic or ALE 
>> uses will trigger the error.
>>
>> The solution seems to be to delay execution of autocmd events until after 
>> quickfix has finished jumping from one buffer to another, and then execute 
>> autocmd events only after quickfix has finished moving from one buffer to 
>> another. Theoretically, this should fix the original segfault issue, and 
>> remove the need for the error saying the list was changed.
>
> What exact problem are you facing? How do you reproduce it? (Sorry,
> don't see the context to which you replied).

Also, which version of Vim do you use?
There were several recent fixes in quickfix:

patch 8.0.0782: using freed memory in quickfix code
patch 8.0.0676: crash when closing quickfix window in autocmd

The best to get something fixed is to send a
a reproducable bug report with the latest vim from
github. Consider running vim with valgrind or build
vim with the address sanitizer (asan) if you can,
to get stacks where invalid memory is accessed.
Building with asan should only be a matter of
rebuilding after uncommenting this line in
vim/src/Makefile:

SANITIZER_CFLAGS = -g -O0 -fsanitize=address -fno-omit-frame-pointer

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

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

Re: Bug: read from free'd memory when jumping from a quickfix list

[Christian Brabandt]

On So, 20 Aug 2017, Wuh Orp wrote:

> Having read this thread and encountered the same issues myself in ALE, I can 
> confidently say that LCD had a lot of really valid points here, and this 
> should be examined again.
> 
> The problem is that plugins like Syntastic and ALE want to be able to check 
> buffers for errors when you open them. This is implemented through autocmd 
> events of course. The problem with the current set of patches is that you 
> will see an annoying error message when you switch from one buffer to another 
> by selecting an item in the location list or the quickfix list, because 
> changing the lists through the autocmd events that Syntastic or ALE uses will 
> trigger the error.
> 
> The solution seems to be to delay execution of autocmd events until after 
> quickfix has finished jumping from one buffer to another, and then execute 
> autocmd events only after quickfix has finished moving from one buffer to 
> another. Theoretically, this should fix the original segfault issue, and 
> remove the need for the error saying the list was changed.

What exact problem are you facing? How do you reproduce it? (Sorry, 
don't see the context to which you replied).

Best,
Christian
-- 
Der Liebende ist so strenge-fordernd gegen die Liebende nicht
seinetwegen, sondern (ihretwegen) damit die rechte Liebe und (oder)
ihr Gegenstand sei.
-- Jean Paul

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