Re: Bug in clearing history

Hi, On Sun, Jan 31, 2016 at 2:53 PM, Yegappan Lakshmanan <yegapp...@gmail.com> wrote: > Hi all, > > There is a bug in the clr_history() function when deleting entries > from the command history. > > When walking through the elements in the history array, the

Re: [bug] regex with \%l in front of ^ does not match

same, however I find it kind of unexpected, that the second search > > term does not match. > > It looks like the zero-width match clears the flag that the current > position is at the start of the line. I would call that a bug. Yes you are right and I wouldn't

Re: [bug] regex with \%l in front of ^ does not match

ine) > > > #v- > > > > > > The 'regexpengine' setting does not matter, both engines seem to behave > > > the same, however I find it kind of unexpected, that the second search > > > term does not match. > > > > It looks like the zero-width mat

Re: [bug] Error number "Exxx" should be replaced by proper error number in src/if_mzsch.c

Dominique Pellé wrote: > File src/if_mzsch.c contains this error message > introduced by recent patch 7.4.1104: > > 1291 if (load_base_module_failed || startup_mzscheme()) > 1292 { > 1293 EMSG(_("Exxx: Sorry, this command is disabled, the MzScheme's > racket/base module could not be

[bug] Error number "Exxx" should be replaced by proper error number in src/if_mzsch.c

Hi File src/if_mzsch.c contains this error message introduced by recent patch 7.4.1104: 1291 if (load_base_module_failed || startup_mzscheme()) 1292 { 1293 EMSG(_("Exxx: Sorry, this command is disabled, the MzScheme's racket/base module could not be loaded.")); The "Exxx" part should be

Re: [bug] vim does not parse function names correctly in turkish locale

Hi Bram! On Di, 19 Jan 2016, Bram Moolenaar wrote: > > Christian Brabandt wrote: > > > take this file: > > > > #v+ > > ~$ cat /tmp/foobar.vim > > set nocp > > func! _dummy_function() > > echo 1 > > endfunc > > au VimEnter * call _dummy_function() > > ~$ LC_ALL=tr_TR.UTF-8 vim

Re: [bug] vim does not parse function names correctly in turkish locale

Christian Brabandt wrote: > take this file: > > #v+ > ~$ cat /tmp/foobar.vim > set nocp > func! _dummy_function() > echo 1 > endfunc > au VimEnter * call _dummy_function() > ~$ LC_ALL=tr_TR.UTF-8 vim --noplugins -u /tmp/foobar.vim -N > Error detected while processing /tmp/foobar.vim: >

[bug] regex with \%l in front of ^ does not match

Hi, consider this file: #v+ ~$ cat file # first comment line # second comment line ~$ vim -u NONE -N file :set hls /^\%1l#.* (this matches the first line) /\%1l^#.* (this does not match the first line) /^#.*\%1l (this matches the first line) #v- The 'regexpengine' setting does not matter, both

Re: [bug] regex with \%l in front of ^ does not match

t the current position is at the start of the line. I would call that a bug. -- Often you're less important than your furniture. If you think about it, you can get fired but your furniture stays behind, gainfully employed at the company that didn't need _you_ anymore.

Bug in the argidx() function?

Hi all, I think there is a bug in the argidx() function when all the files in the argument list are deleted. $ vim -u NONE -N :echo argidx() 0 :args a b c :last :echo argidx() 2 :%argdelete :echo argidx() 1 The last invocation of argidx() should return 0 instead of 1 (as the argument list

Re: Bug in the argidx() function?

Yegappan Lakshmanan wrote: > I think there is a bug in the argidx() function when all the files in the > argument list are deleted. > > $ vim -u NONE -N > :echo argidx() > 0 > :args a b c > :last > :echo argidx() > 2 > :%argdelete > :echo argidx() > 1 >

[vim bug] cursorline resets spell foreground color

on a line, the foreground color of the misspelled word, "tset", changes away from yellow to whatever the syntax color is. Note that the italic highlighting still stays in effect, though, so the word is still in the SpellBad group. Also note that the TODO foreground color does not chang

Re: [patch] fix possible bug in searchpair

Hi Bram! On Mi, 13 Jan 2016, Bram Moolenaar wrote: > > Christian Brabandt wrote: > > > > > Bram, > > > > this patch fies an issue reported by David Fishburn about a misbehaving > > > > searchpairpos(). I traced it back to syntax.c and I think what happens > > > > is, that Vim gets confused

Re: [patch] fix possible bug in searchpair

Christian Brabandt wrote: > > > Bram, > > > this patch fies an issue reported by David Fishburn about a misbehaving > > > searchpairpos(). I traced it back to syntax.c and I think what happens > > > is, that Vim gets confused about the current syntax stack. I added a > > > newstyle test, that

Re: [patch] fix gn bug

Hi Bram! On Di, 12 Jan 2016, Bram Moolenaar wrote: > > Christian Brabandt wrote: > > > Bram, > > this patch fixes the gn bug reported by John Becket in > > https://groups.google.com/d/msg/vim_dev/UHFPleYDxWA/4dcOL1OkBgAJ > > > > Additionally, sin

Re: [patch] fix possible bug in searchpair

Hi Bram! On Di, 12 Jan 2016, Bram Moolenaar wrote: > > Christian Brabandt wrote: > > > Bram, > > this patch fies an issue reported by David Fishburn about a misbehaving > > searchpairpos(). I traced it back to syntax.c and I think what happens > > is, that Vim gets confused about the current

Re: [patch] fix possible bug in searchpair

Christian Brabandt wrote: > Bram, > this patch fies an issue reported by David Fishburn about a misbehaving > searchpairpos(). I traced it back to syntax.c and I think what happens > is, that Vim gets confused about the current syntax stack. I added a > newstyle test, that lets the problem

Re: [patch] fix gn bug

Christian Brabandt wrote: > Bram, > this patch fixes the gn bug reported by John Becket in > https://groups.google.com/d/msg/vim_dev/UHFPleYDxWA/4dcOL1OkBgAJ > > Additionally, since I was already at the gn behaviour, I converted the > old-style test to a newstyle test. F

Re: [patch] fix possible bug in searchpair

On Mon, Jan 11, 2016 at 3:06 PM, Christian Brabandt wrote: > Bram, > this patch fies an issue reported by David Fishburn about a misbehaving > searchpairpos(). I traced it back to syntax.c and I think what happens > is, that Vim gets confused about the current syntax stack. I

[patch] fix gn bug

Bram, this patch fixes the gn bug reported by John Becket in https://groups.google.com/d/msg/vim_dev/UHFPleYDxWA/4dcOL1OkBgAJ Additionally, since I was already at the gn behaviour, I converted the old-style test to a newstyle test. Fix should be ready to be included for Vim 7.5 Thanks

[patch] fix possible bug in searchpair

Bram, this patch fies an issue reported by David Fishburn about a misbehaving searchpairpos(). I traced it back to syntax.c and I think what happens is, that Vim gets confused about the current syntax stack. I added a newstyle test, that lets the problem reproduce, given the plugin from David.

Re: [bug] error E201 when opening 3 large files with -o option when using LargeFile plugin

On Sat, Jan 9, 2016 at 8:58 AM, Bram Moolenaar wrote: > > Justin Keyes wrote: > >> On Fri, Jan 8, 2016 at 12:15 PM, Charles E Campbell >> wrote: >> > Ben Fritz wrote: >> >> On Friday, January 8, 2016 at 2:33:04 AM UTC-6, Christian Brabandt wrote: >>

Re: [bug] error E201 when opening 3 large files with -o option when using LargeFile plugin

On Sun, Jan 10, 2016 at 1:21 PM, Bram Moolenaar wrote: > > Justin Keyes wrote: > >> >> On Fri, Jan 8, 2016 at 12:15 PM, Charles E Campbell >> >> wrote: >> >> > Ben Fritz wrote: >> >> >> On Friday, January 8, 2016 at 2:33:04 AM UTC-6, Christian

Re: [bug] error E201 when opening 3 large files with -o option when using LargeFile plugin

Justin Keyes wrote: > >> On Fri, Jan 8, 2016 at 12:15 PM, Charles E Campbell > >> wrote: > >> > Ben Fritz wrote: > >> >> On Friday, January 8, 2016 at 2:33:04 AM UTC-6, Christian Brabandt > >> >> wrote: > >> >>> Having said that, I personally don't like the argument

Re: [bug] error E201 when opening 3 large files with -o option when using LargeFile plugin

Christian Brabandt wrote: > On Fr, 08 Jan 2016, Charles E Campbell wrote: > > > Ben Fritz wrote: > > > On Friday, January 8, 2016 at 2:33:04 AM UTC-6, Christian Brabandt wrote: > > >> Having said that, I personally don't like the argument as > > >> well. Perhaps we could use a new command

Re: [bug] error E201 when opening 3 large files with -o option when using LargeFile plugin

Justin Keyes wrote: > On Fri, Jan 8, 2016 at 12:15 PM, Charles E Campbell > wrote: > > Ben Fritz wrote: > >> On Friday, January 8, 2016 at 2:33:04 AM UTC-6, Christian Brabandt wrote: > >>> Having said that, I personally don't like the argument as > >>> well. Perhaps

Re: [bug] error E201 when opening 3 large files with -o option when using LargeFile plugin

On 09-Jan-16, Bram Moolenaar wrote: > > Christian Brabandt wrote: > > > On Fr, 08 Jan 2016, Charles E Campbell wrote: > > > > > Ben Fritz wrote: > > > > On Friday, January 8, 2016 at 2:33:04 AM UTC-6, Christian Brabandt > > > > wrote: > > > >> Having said that, I personally don't like the

Re: [bug] error E201 when opening 3 large files with -o option when using LargeFile plugin

Hi Justin! On Fr, 08 Jan 2016, Justin M. Keyes wrote: > Instead of requiring , the default behavior could be changed. > Can anyone give a single reason why the old behavior is desirable or > useful, or necessary for backwards compatibility? > > Ben mentioned that the existing behavior gives the

Re: [bug] error E201 when opening 3 large files with -o option when using LargeFile plugin

On Fri, Jan 8, 2016 at 12:15 PM, Charles E Campbell wrote: > Ben Fritz wrote: >> On Friday, January 8, 2016 at 2:33:04 AM UTC-6, Christian Brabandt wrote: >>> Having said that, I personally don't like the argument as >>> well. Perhaps we could use a new command

Re: [bug] error E201 when opening 3 large files with -o option when using LargeFile plugin

Hi Charles! On Fr, 08 Jan 2016, Charles E Campbell wrote: > Ben Fritz wrote: > > On Friday, January 8, 2016 at 2:33:04 AM UTC-6, Christian Brabandt wrote: > >> Having said that, I personally don't like the argument as > >> well. Perhaps we could use a new command modifier like > >> :keeppos

Re: [bug] error E201 when opening 3 large files with -o option when using LargeFile plugin

On Friday, January 8, 2016 at 2:33:04 AM UTC-6, Christian Brabandt wrote: > > Having said that, I personally don't like the argument as > well. Perhaps we could use a new command modifier like > :keeppos windo ... > > That could be useful for other commands as well. > I like that idea better

Re: [bug] error E201 when opening 3 large files with -o option when using LargeFile plugin

Ben Fritz wrote: > On Friday, January 8, 2016 at 2:33:04 AM UTC-6, Christian Brabandt wrote: >> Having said that, I personally don't like the argument as >> well. Perhaps we could use a new command modifier like >> :keeppos windo ... >> >> That could be useful for other commands as well. >> > I

Re: [bug] error E201 when opening 3 large files with -o option when using LargeFile plugin

Instead of requiring , the default behavior could be changed. Can anyone give a single reason why the old behavior is desirable or useful, or necessary for backwards compatibility? Ben mentioned that the existing behavior gives the user an indication that "something was done". But this could be

Re: [bug] error E201 when opening 3 large files with -o option when using LargeFile plugin

On Sa, 26 Dez 2015, Christian Brabandt wrote: > Okay, I'll go with and check it out within the next 2 weeks. I > am on vacation currently, so don't expect anything very soon. Here is a patch series, that adds the argument to the :windo/bufdo/argdo/cdo commands that should correctly restore

Re: [bug] error E201 when opening 3 large files with -o option when using LargeFile plugin

On Mi, 06 Jan 2016, Christian Brabandt wrote: > Here is a patch series, that adds the argument to the > :windo/bufdo/argdo/cdo commands that should correctly restore the cursor > position after those commands. The patch includes updates to the > documentation, a newstyle test and an update to

Re: [bug] access beyond end of string in syntax.c in Vim-7.4.1051

Dominique Pellé wrote: > afl-fuzz found another case which accesses > invalid memory (beyond end of string) in > Vim-7.4.1051 and older. > > Steps to reproduce: > > $ valgrind vim -u NONE -N -S vg-error.vim 2> vg.log > > ... where vg-error.vim is the nonsensical attached 2-lines file: > >

[bug] access beyond end of string in syntax.c in Vim-7.4.1051

Hi afl-fuzz found another case which accesses invalid memory (beyond end of string) in Vim-7.4.1051 and older. Steps to reproduce: $ valgrind vim -u NONE -N -S vg-error.vim 2> vg.log ... where vg-error.vim is the nonsensical attached 2-lines file: $ cat vg-error.vim syn cluster a add=t

Re: Bug: Unable to set textwidth via vimrc

vimrc and in the meantime will keep this in my ~/.vimrc: let g:leave_my_textwidth_alone=1 Thank you for your help! Regards -Original Message- Date: Sun, 3 Jan 2016 15:04:34 +0100 From: Tony Mechelynck <antoine.mechely...@gmail.com> To: vim_dev <vim_dev@googlegroups.com> C

Re: Bug: Unable to set textwidth via vimrc

On Mon, Jan 4, 2016 at 12:37 AM, tot-to wrote: […] > :scriptnames gives the following list if started with no options: > > 1: /etc/vim/vimrc > 2: /usr/share/vim/vim74/syntax/syntax.vim > 3: /usr/share/vim/vim74/syntax/synload.vim > 4:

Re: Bug: Unable to set textwidth via vimrc

On Sat, Jan 2, 2016 at 7:06 AM, tot-to wrote: > Hi Ken, > > Thanks, it says "Last set from /etc/vim/vimrc" > > I've found the place in that file, where it sets the variable. This is > apparently distribution (Gentoo) specific settings: Many Linux distributions, when they

Re: Bug: Unable to set textwidth via vimrc

On Sa, 02 Jan 2016, tot-to wrote: > https://bugs.gentoo.org/show_bug.cgi?id=559800 > > Previously, I haven't set textwidth in .vimrc and it was no > autowrapping by default in all files. > > At some point (probably after an upgrade) it stared to do autowrap, but > only for *.txt files, i.e. if

Re: Bug: Unable to set textwidth via vimrc

Hi tot-to, Unfortunately, your mail was filtered to the spam folder by Gmail... 2016-01-02 15:06 GMT+09:00 tot-to : > Hi Ken, > > Thanks, it says "Last set from /etc/vim/vimrc" > > I've found the place in that file, where it sets the variable. This is > apparently

Re: Bug: Unable to set textwidth via vimrc

"normal g'\"" | 171 \ endif | 172 \ endif 173 174 " When editing a crontab file, set backupcopy to yes rather than auto. See 175 " :help crontab and bug #53437. 176 autocmd FileType crontab set backupcopy=yes 177 178 " If we previously detect

Re: Bug: Unable to set textwidth via vimrc

On Sat, Jan 2, 2016 at 7:51 AM, Ken Takata wrote: > Hi tot-to, > > Unfortunately, your mail was filtered to the spam folder by Gmail... > > 2016-01-02 15:06 GMT+09:00 tot-to : >> >> Hi Ken, >> >> Thanks, it says "Last set from /etc/vim/vimrc" >> >>

Re: Bug: Unable to set textwidth via vimrc

Hi tot-to, 2016/1/2 Sat 13:19:05 UTC+9 tot-to wrote: > https://bugs.gentoo.org/show_bug.cgi?id=559800 > > Previously, I haven't set textwidth in .vimrc and it was no > autowrapping by default in all files. > > At some point (probably after an upgrade) it stared to do autowrap, but > only for

Bug: Unable to set textwidth via vimrc

https://bugs.gentoo.org/show_bug.cgi?id=559800 Previously, I haven't set textwidth in .vimrc and it was no autowrapping by default in all files. At some point (probably after an upgrade) it stared to do autowrap, but only for *.txt files, i.e. if I open such file and enter the command :set tw I

Re: [bug] Can't remove letters from comma-separated options after a backslash

Jacob Niehus wrote: > After a single backslash is added as an item in a comma-separation > option, the items after the backslash can't be removed without removing > the backslash first. > > For example: > > set iskeyword+=\\,! > --> iskeyword=@,48-57,_,192-255,\,! > set iskeyword-=! > -->

[bug] Can't remove letters from comma-separated options after a backslash

After a single backslash is added as an item in a comma-separation option, the items after the backslash can't be removed without removing the backslash first. For example: set iskeyword+=\\,! --> iskeyword=@,48-57,_,192-255,\,! set iskeyword-=! --> iskeyword=@,48-57,_,192-255,\,! set

Re: [bug] error E201 when opening 3 large files with -o option when using LargeFile plugin

On Sa, 26 Dez 2015, Bram Moolenaar wrote: > Christian Brabandt wrote: > > > On Di, 22 Dez 2015, Bram Moolenaar wrote: > > > > > Hmm, I think it's confusing that adding ! means something different for > > > :windo and :bufdo. A separate argument would be better. > > > That's more work, but I'm

Re: [bug] error E201 when opening 3 large files with -o option when using LargeFile plugin

Hi Bram! On Di, 22 Dez 2015, Bram Moolenaar wrote: > Hmm, I think it's confusing that adding ! means something different for > :windo and :bufdo. A separate argument would be better. > That's more work, but I'm sure you can handle it :-). You mean like windo restoreview command? Best,

Re: [bug] error E201 when opening 3 large files with -o option when using LargeFile plugin

Christian Brabandt wrote: > On Di, 22 Dez 2015, Bram Moolenaar wrote: > > > Hmm, I think it's confusing that adding ! means something different for > > :windo and :bufdo. A separate argument would be better. > > That's more work, but I'm sure you can handle it :-). > > You mean like windo

Re: [bug][patch] Inconsistent handling of path names in Cygwin

On Thursday, December 24, 2015 at 9:11:15 AM UTC-7, Bram Moolenaar wrote: > > I thought that request was from Wily Wampa... Whoops, the thought of confused identification hadn't occurred to me. I just added my name and made my email address public on GitHub: https://github.com/wilywampa -Jake

Re: [bug][patch] Inconsistent handling of path names in Cygwin

Jacob Niehus wrote: > I opened up a pull request for this issue a few weeks ago: > https://github.com/vim/vim/pull/505 > > The short version is that relative paths are handled differently in Cygwin > compared to other platforms. The most obvious manifestation of the bug is that

[bug][patch] Inconsistent handling of path names in Cygwin

I opened up a pull request for this issue a few weeks ago: https://github.com/vim/vim/pull/505 The short version is that relative paths are handled differently in Cygwin compared to other platforms. The most obvious manifestation of the bug is that `fnamemodify('.', ':.')` returns an empty string

Re: [bug] error E201 when opening 3 large files with -o option when using LargeFile plugin

lows: > > > > $ vim -o foo1 foo2 foo3 > > > > 3) notice the error message: > > > > E201: *ReadPre autocommands must not change current buffer > > Press ENTER or type command to continue > > > > After pressing ENTER, notice that file foo1 is load

Re: [bug] error E201 when opening 3 large files with -o option when using LargeFile plugin

Christian Brabandt wrote: > On Di, 22 Dez 2015, Ben Fritz wrote: > > > Already discussed here: > > https://groups.google.com/d/topic/vim_dev/P8EyOpmNj5A/discussion > > Thanks for pointing that out. > > > Supposedly the latest unreleased version of LargeFile fixes it for > > LargeFile. I don't

Re: [bug] error E201 when opening 3 large files with -o option when using LargeFile plugin

On Di, 22 Dez 2015, Ben Fritz wrote: > Already discussed here: > https://groups.google.com/d/topic/vim_dev/P8EyOpmNj5A/discussion Thanks for pointing that out. > Supposedly the latest unreleased version of LargeFile fixes it for > LargeFile. I don't remember if I ever tried it. Regardless I'd

[bug] error E201 when opening 3 large files with -o option when using LargeFile plugin

foo3 in bottom window. I noticed the bug using vim-7.4.979 (huge) on Linux x86_64. Bug does not happen with Vim that comes with xubuntu-14.04 (7.4.52). Doing a bisection in git: 7.4.072 --> OK (no error) 7.4.073 --> Error E201 So the regression is introduced by

Re: [bug] error E201 when opening 3 large files with -o option when using LargeFile plugin

> > After pressing ENTER, notice that file foo1 is loaded in top > and bottom window, and middle window is empty. I would > expect instead to see foo1 in top window, foo2 in middle > window and foo3 in bottom window. > > I noticed the bug using vim-7.4.979 (huge) on Linux x86_6

Re: [bug] sh.vim 134 bash syntax: ${var/#from/to} not recognized anymore

On Tuesday, June 3, 2014 at 8:43:41 AM UTC-7, Charles Campbell wrote: > G.raud wrote: > > This bug is found in sh.vim Version 134 ASTRO-ONLY but _not_ in Version > > 132 ASTRO-ONLY (and _not_ in VIM 7.4.273 either): > > > > $ cat >test.sh <<"EOF" >

Re: bug: if an autogroup has the name of an autocommand event, the autocommand does not trigger

Christian Brabandt wrote: > On Sa, 05 Dez 2015, Bram Moolenaar wrote: > > > That exe command has an error, the quoting is wrong. > > Yes, posting a bad example > > > The second command doesn't work as you expect: > > filetypegroup > > * event > > :echom

Re: bug: if an autogroup has the name of an autocommand event, the autocommand does not trigger

Christian Brabandt wrote: > I think I have found a bug: > > vim -u NONE -N > :exe "augroup filetype | au BufNewFile * echo "foobar"|augroup end" > :au filetype * :echom "filetype command fired" > > Now set the filetype and notice that the auto

Re: bug: if an autogroup has the name of an autocommand event, the autocommand does not trigger

On Sa, 05 Dez 2015, Bram Moolenaar wrote: > That exe command has an error, the quoting is wrong. Yes, posting a bad example > The second command doesn't work as you expect: > filetypegroup > * event > :echom pattern Yes, I just found out. How

Re: $TMPDIR bug

I can > > > unsubscribe again. > > > [...] ... > Cannot say I enjoy this policy or that it encourages bug reports. You can also report bugs at https://github.com/vim/vim/issues > But then again, this is the first bug I have encountered in 17 years > of using vim, s

Re: $TMPDIR bug

Jörn Engel wrote: > On Thu, Dec 03, 2015 at 02:12:08AM +, Random832 wrote: > > On 2015-12-02, Jörn Engel <jo...@purestorage.com> wrote: > > > The vim bug is to try "$TMPDIR" even though the environment variable > > > isn't set. Arguably that co

Re: $TMPDIR bug

On Thu, Dec 03, 2015 at 05:43:33PM +0100, Bram Moolenaar wrote: > > Does this patch fix your problem: > > > --- a/fileio.c2015-12-03 13:52:48.451584080 +0100 > +++ b/fileio.c2015-12-03 17:31:53.457770134 +0100 > @@ -7390,8 +7390,9 @@ > > /* expand $TMP, leave room

Re: $TMPDIR bug

Jörn Engel wrote: > > Does this patch fix your problem: > > > > > > --- a/fileio.c 2015-12-03 13:52:48.451584080 +0100 > > +++ b/fileio.c 2015-12-03 17:31:53.457770134 +0100 > > @@ -7390,8 +7390,9 @@ > > > > /* expand $TMP, leave room for "/v110/9" */ > >

Re: $TMPDIR bug

On Thu, Dec 03, 2015 at 09:02:47PM +0100, Bram Moolenaar wrote: > Jörn Engel wrote: > > > But fundamentally this patch is still wrong. If I run > > export TMPDIR='$TMPDIR' vim > > then vim should very much try '$TMPDIR' because I explicitly asked it > > to do so. Might be a silly choice,

Re: $TMPDIR bug

On Thu, Dec 03, 2015 at 11:03:19AM -0800, Jörn Engel wrote: > On Thu, Dec 03, 2015 at 05:43:33PM +0100, Bram Moolenaar wrote: > > > > Does this patch fix your problem: > > > > > > --- a/fileio.c 2015-12-03 13:52:48.451584080 +0100 > > +++ b/fileio.c 2015-12-03 17:31:53.457770134 +0100

Re: $TMPDIR bug

On Thu, Dec 3, 2015 at 12:39 AM, Jörn Engel wrote: > Retry after subscribing to the list. I hope this works and I can > unsubscribe again. > [...] Indeed, messages can only make it to the list if they are from subscribed authors, but in addition, the first time a given

Re: $TMPDIR bug

On Thu, Dec 03, 2015 at 02:12:08AM +, Random832 wrote: > [...] > > Vim isn't opening a file that exists, it is trying to find a file that > doesn't exist. Which means it can't be tricked into opening a file that > exists. So let's try to steal the file content instead. If a normal user can

Re: $TMPDIR bug

4, 707649}, NULL) = 0 > mkdir("$TMPDIR/v4sgqHU", 0700) = -1 EEXIST (File exists) > mkdir("$TMPDIR/vvuiqHU", 0700) = -1 EEXIST (File exists) > mkdir("$TMPDIR/vWvkqHU", 0700) = -1 EEXIST (File exists) > ... > > After about 30s and 250k attempts

$TMPDIR bug

|0555, st_size=4096, ...}) = 0 gettimeofday({1430937134, 707649}, NULL) = 0 mkdir("$TMPDIR/v4sgqHU", 0700) = -1 EEXIST (File exists) mkdir("$TMPDIR/vvuiqHU", 0700) = -1 EEXIST (File exists) mkdir("$TMPDIR/vWvkqHU", 0700) = -1 EEXIST (File exists) ... After about 30s a

Re: $TMPDIR bug

On 2015-12-02, Jörn Engel <jo...@purestorage.com> wrote: > The vim bug is to try "$TMPDIR" even though the environment variable > isn't set. Arguably that could become a security-issue if I can create > a "$TMPDIR" in a directory I control and trick

Re: $TMPDIR bug

On Thu, Dec 03, 2015 at 02:12:08AM +, Random832 wrote: > On 2015-12-02, Jörn Engel <jo...@purestorage.com> wrote: > > The vim bug is to try "$TMPDIR" even though the environment variable > > isn't set. Arguably that could become a security-issue if I can create

Re: $TMPDIR bug

fore you decide to get rid of the email account, or just > after you decide never to use Vim again. Cannot say I enjoy this policy or that it encourages bug reports. But then again, this is the first bug I have encountered in 17 years of using vim, so you must be doing something right. Tha

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

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

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

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

[DOC? BUG] Documentation regarding viminfo-% is incorrect

Consider the following script: vim -u NONE -i /tmp/foo.viminfo -c 'help :command' -c 'setlocal buflisted' -c 'set viminfo='\''0,%' -c 'qa' This will result in the following contents in foo.viminfo: # This viminfo file was generated by Vim 7.4. # You may edit it if you're careful!

Re: [DOC? BUG] Documentation regarding viminfo-% is incorrect

Nikolay Pavlov wrote: > Consider the following script: > > vim -u NONE -i /tmp/foo.viminfo -c 'help :command' -c 'setlocal > buflisted' -c 'set viminfo='\''0,%' -c 'qa' > > This will result in the following contents in foo.viminfo: > > # This viminfo file was generated by Vim 7.4. >

Re: [DOC? BUG] Documentation regarding viminfo-% is incorrect

On Mon, Nov 23, 2015 at 1:12 PM, Nikolay Pavlov wrote: > Consider the following script: > > vim -u NONE -i /tmp/foo.viminfo -c 'help :command' -c 'setlocal > buflisted' -c 'set viminfo='\''0,%' -c 'qa' > > This will result in the following contents in foo.viminfo: > > #

Re: [DOC? BUG] Documentation regarding viminfo-% is incorrect

2015-11-24 8:23 GMT+03:00 Tony Mechelynck : > On Mon, Nov 23, 2015 at 1:12 PM, Nikolay Pavlov wrote: > > Consider the following script: > > > > vim -u NONE -i /tmp/foo.viminfo -c 'help :command' -c 'setlocal > > buflisted' -c 'set

Re: [vim] htmlcomplete bug: vim goes into an endless loop of errors prompting you to press enter

Hello, It's been ~17 days since I posted here and I still haven't recieved a reply from the maintainer. Where do we go from here? Thanks, Dylan -- -- 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

Re: [vim] htmlcomplete bug: vim goes into an endless loop of errors prompting you to press enter

Hi Dyl! On Di, 17 Nov 2015, Dyl A wrote: > Hello, > > It's been ~17 days since I posted here and I still haven't recieved a reply > from the maintainer. > > Where do we go from here? Does this patch fix it for you? idiff --git a/runtime/autoload/htmlcomplete.vim

[BUG/DOC PATCH] Variable actual_curbuf is unset without notice and any documentation

Consider the following script: vim -u NONE -i NONE -N --cmd 'let g:actual_curbuf="foo"' --cmd 'set statusline=%{bufnr('\'\'')} laststatus=2' --cmd 'redrawstatus' --cmd 'echo g:actual_curbuf' you will see E121: Undefined variable: g:actual_curbuf. But trying to use help to understand what

Re: [BUG/DOC PATCH] Variable actual_curbuf is unset without notice and any documentation

Nikolay Pavlov wrote: > Consider the following script: > > vim -u NONE -i NONE -N --cmd 'let g:actual_curbuf="foo"' --cmd 'set > statusline=%{bufnr('\'\'')} laststatus=2' --cmd 'redrawstatus' --cmd 'echo > g:actual_curbuf' > > you will see E121: Undefined variable: g:actual_curbuf. But

Re: Bug: screen clearing doesn't work in xterm

Random832 wrote: > John Little writes: > > > On Sunday, November 8, 2015 at 4:52:26 PM UTC+13, Random832 wrote: > > > >> "U+25BD WHITE DOWN-POINTING TRIANGLE" > > > > Well done, is all I can say. > > > > How do you start an xterm in non-utf8 mode? > > As far as I

Re: [bug] parsing :command

On 7 November 2015, thinca wrote: > command! -bar F call F() > > See :help :command-bar Ah, I missed that. Sorry for the noise then. /lcd -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying

Re: [bug] parsing :command

command! -bar F call F() See :help :command-bar Regards, -- thinca -- -- 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

Bug: screen clearing doesn't work in xterm

When running in xterm (a real xterm, not any other terminal reporting itself as "xterm") with TERM set to xterm, Vim puts the terminal in a state where the screen clearing commands \e[K and \e[J do not work (resulting in many artifacts where text that Vim attempted to clear remains on the

Re: Bug: screen clearing doesn't work in xterm

On 2015-11-07, Random832 wrote: > When running in xterm (a real xterm, not any other terminal reporting > itself as "xterm") with TERM set to xterm, Vim puts the terminal in a > state where the screen clearing commands \e[K and \e[J do not work > (resulting in many artifacts where text that Vim

Re: Bug: screen clearing doesn't work in xterm

Hi, 2015-11-8(Sun) 8:03:49 UTC+9 Random832: > When running in xterm (a real xterm, not any other terminal reporting > itself as "xterm") with TERM set to xterm, Vim puts the terminal in a > state where the screen clearing commands \e[K and \e[J do not work > (resulting in many artifacts where

Re: Bug: screen clearing doesn't work in xterm

On Sunday, November 8, 2015 at 12:03:49 PM UTC+13, Random832 wrote: > When running in xterm (a real xterm, not any other terminal reporting > itself as "xterm") with TERM set to xterm, Vim puts the terminal in a > state where the screen clearing commands \e[K and \e[J do not work Are you sure

Re: Bug: screen clearing doesn't work in xterm

ntioned it is dependent on the vim version. I also figured out after sending my initial bug report, that this only happens on a non-UTF8 xterm. It makes me wonder if Vim is sending a UTF-8 character that contains 0x96, but I can't think of why that would be happening. > in case your shell'

Re: Bug: screen clearing doesn't work in xterm

Note also that you can add a full reset when vim starts by putting the following in your .vimrc: let _ti = "\ec" . _ti I haven't tested that much though. It messes with the "alternate screen" handling. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your

Re: Bug: screen clearing doesn't work in xterm

On Sunday, November 8, 2015 at 4:52:26 PM UTC+13, Random832 wrote: > "U+25BD WHITE DOWN-POINTING TRIANGLE" Well done, is all I can say. How do you start an xterm in non-utf8 mode? If I reset my locale to C and start an xterm then vim, vim uses latin1 and only the bd byte is output. IMO,

Re: Bug: screen clearing doesn't work in xterm

John Little writes: > On Sunday, November 8, 2015 at 4:52:26 PM UTC+13, Random832 wrote: > >> "U+25BD WHITE DOWN-POINTING TRIANGLE" > > Well done, is all I can say. > > How do you start an xterm in non-utf8 mode? As far as I can tell, it's non-utf8 by default when

Re: [BUG] It looks like OOM handling code is harmful

2015-11-06 0:48 GMT+03:00 Bram Moolenaar : > > Nikolay Pavlov wrote: > >> >> Consider the following scenario: while processing function dict_copy >> >> >> >> static dict_T * >> >> dict_copy(orig, deep, copyID) >> >> dict_T *orig; >> >> int

[bug] parsing :command

definition helps, running "FG" after that works as expected: command! FG call F()|G This seems like a parsing bug. /lcd -- -- 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 informatio

Re: [bug] use of uninitialized memory in silent mode

Dominique Pellé wrote: > valgrind detects a use of uninitialized memory when doing > the following weird command. It happens in Vim-7.4.909 and > earlier. This a simplified case which was detected by afl-fuzz > (http://lcamtuf.coredump.cx/afl/): > > $ echo q | valgrind --track-origins=yes ./vim

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