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

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

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

> ... 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

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

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

Re: Linux clipboard corruption bug?

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

Re: Linux clipboard corruption bug?

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.

Linux clipboard corruption bug?

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

[BUG] Bug with "gw" and cursor position

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

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

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 sh

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

> 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. > >

Re: BUG: Recent commit breaks shell script indention

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

BUG: Recent commit breaks shell script indention

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

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

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 >

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

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

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

> 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

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

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 mo

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

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

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

ion.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

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

t; 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

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

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 int

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

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

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

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

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

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 |

Re: [bug?] for loop on blob

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 sin

[bug?] for loop on blob

, 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

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

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

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

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 i

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

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 -

[BUG] Peculiar bug with session restoration, please repro

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

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

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 show

[bug] term_gettitle() always returns an empty string

(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, visi

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

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

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

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

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

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

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

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

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

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

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

> 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

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

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

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

> 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

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

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

[PATCH] Fix bug in diffopt_changed() function

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

Re: Documentation bug report - "j" format option

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

Re: Documentation bug report - "j" format option

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

Re: Documentation bug report - "j" format option

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.n

Re: Documentation bug report - "j" format option

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/htm

Documentation bug report - "j" format option

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 th

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

> 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

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

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.

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

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 \

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

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' \ >

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

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

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

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: > > > > > > > >

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

9 * 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 "\n" in the last line. */ > !!3694 return (char_u *)""; > 3695

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

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>

Possible bug: inconsistent behavior with 'confirm' set

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

Re: Vim bug when inserting foo}

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

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

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 \\\ ///

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

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

Re: Vim bug when inserting foo}

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

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

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

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

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

[bug] use of free memory in qf_jump()

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==

Vim bug when inserting foo}

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

Re: Bug Report: fnamemodify() fails on Windows

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

Bug Report: fnamemodify() fails on Windows

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

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

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. > >

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

-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

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

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

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

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 S

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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_cl

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

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 'wf

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

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 red

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

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 AB

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

emory 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

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

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:

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

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 >

[bug] access to free memory with -DEXITFREE

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

Re: apparent bug or oddity in fortran indent

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) ::

Re: apparent bug or oddity in fortran indent

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

apparent bug or oddity in fortran indent

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)

Re: fix matchit bug

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

Re: fix matchit bug

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:

Re: fix matchit bug

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

Re: fix matchit bug

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

Re: fix matchit bug

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

Re: fix matchit bug

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 po

fix matchit bug

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

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

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 b

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

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.

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

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

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

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

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

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

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

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.

<    1   2   3   4   5   6   7   8   9   10   >