debugging vim
Hi all, I'd like to debug vim with cgdb to understand how it works. My problem is this: when I run cgdb vim I get the output in the cgdb console as binary.. I can't debug mouse actions or editing. Is there a way to point vim to another terminal instance other than the cgdb? or how would you suggest to go about this one? 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: 100% CPU for a long time when editing .yml file
armin walland wrote:
> hi!
>
> i think i have encountered a bug in vim's syntax plugin.
>
> the behaviour seems to have something to do with matching of curly braces or
> quotes.
>
> $ cat a.yml
>
> - name: make sure authorized_keys are correct
> authorized_key: user=root key="{{ a-ssh }}"
> authorized_key: user=root key="{{ b-ssh }}"
> authorized_key: user=root state=absent
> key="f"
>
>
> if i open this file with vim, change to edit mode, place the cursor at the
> closing double quote in the b-ssh line and press backspace, vim freezes for
> some time (maybe 30 seconds) using 100% cpu and returns to life eventually.
> the duration of the freeze seems to be related to how long the
> "ff..." line is. :syntax off removes the problem.
>
> not sure how my thunderbird will format this message, but just to make sure,
> there should not be a newline before the key="f..." line.
>
> thank you :)
I can't reproduce it using vim-7.4.2232 (huge) on Linux.
Which version of Vim are you using? Make sure you're using
a recent version, as the bug may have been fixed already.
Can you also try with: vim -u NONE a.yaml?
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: Setting quickfix/location list context
2016-08-21 3:43 GMT+03:00 Yegappan Lakshmanan :
> Hi,
>
> On Fri, Aug 19, 2016 at 7:56 AM, Ken Takata wrote:
>> Hi Yegappan,
>>
>> 2016/8/19 Fri 23:08:16 UTC+9 yega...@gmail.com wrote:
>>> Hi all,
>>>
>>> On Thu, Aug 18, 2016 at 5:47 AM, Yegappan Lakshmanan
>>> wrote:
>>> > Hi all,
>>> >
>>> > The attached patch adds support for setting and getting a context to/from
>>> > a quickfix/location list. There is a refcount problem with this diff
>>> > (which I am
>>> > not able to solve).
>>> >
>>> > If the context is a number or a string, then the patch works without any
>>> > issues. If the context is a List or a Dict, then Vim crashes if garbage
>>> > collection runs. For example, the following works:
>>> >
>>> > :call setqflist([], 'a', {'context':[1,2,3]})
>>> > :echo getqflist({'context':1})
>>> >
>>> > But the following doesn't work:
>>> >
>>> > :call setqflist([], 'a', {'context':[1,2,3]})
>>> > :call garbagecollect()
>>> > :echo getqflist({'context':1})
>>> >
>>> > Any suggestions on how to copy the context with proper update to the
>>> > reference count so that garbage collection doesn't free the List/Dict?
>>>
>>> Any suggestions on how to fix the reference count issue?
>>
>> I struggled with reference counting and garbage collection when I implemented
>> lambda and closure.
>>
>> Vim uses mark-and-sweep garbage collection. If an object is not marked, it
>> will be collected even if the refcount is not zero. This is needed because
>> reference counting cannot handle circular reference. To mark an object, you
>> need to update the copyID member in the object (dict or list).
>> Please check the garbage_collect() function in eval.c and also
>> set_ref_in_XXX() functions.
>>
>
> Thanks for the suggestion. This seems to work. I have added a
> set_ref_in_quickfixlist() function to mark the quickfix context
> objects.
>
> But this seems inefficient. Every time garbage collection runs,
> the context of the location list for all the windows (across all
> the tabs) needs to be marked. If there are too many tabs/windows,
> this may take some time.
It is efficient enough, garbage collecting normally runs when Vim is
idle waiting for input. Also number of tabs and windows is completely
incomparable with number of lists and dictionaries: garbage_collect()
is recursing into each list and dictionary that happened to be marked
referenced. So you do not need to care, traversing all tabs and
windows is nothing compared to what garbage_collect() is already
doing.
>
> Also, how do I verify that the context is eventually garbage collected
> when it is no longer referenced? I can run Vim under valgrind and look
> for memory leaks. But is there a simpler way?
No, you can’t. Valgrind will never report memory leaks for lists and
dictionaries because all of them are referenced in a linked list used
for garbage collecting, you may check it yourself by omitting
*_unref() call somewhere. I actually know no way to check that context
is garbage collected, except for performing an operation that is
suspected for causing memory leaks a number of times, running garbage
collector and checking memory usage before and after the test.
>
> 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.
--
--
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.
100% CPU for a long time when editing .yml file
hi!
i think i have encountered a bug in vim's syntax plugin.
the behaviour seems to have something to do with matching of curly
braces or quotes.
$ cat a.yml
- name: make sure authorized_keys are correct
authorized_key: user=root key="{{ a-ssh }}"
authorized_key: user=root key="{{ b-ssh }}"
authorized_key: user=root state=absent
key="f"
if i open this file with vim, change to edit mode, place the cursor at
the closing double quote in the b-ssh line and press backspace, vim
freezes for some time (maybe 30 seconds) using 100% cpu and returns to
life eventually. the duration of the freeze seems to be related to how
long the "ff..." line is. :syntax off removes the problem.
not sure how my thunderbird will format this message, but just to make
sure, there should not be a newline before the key="f..." line.
thank you :)
--
Armin Walland, CEO
Sourcy Software & Services GmbH
Feldgasse 97, 3400 Kierling, Austria
W: https://sourcy.io
E: a.wall...@sourcy.io
--
--
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 is compiled without python support
i compile vim from source on a daily basis, lately i encounter an issue, when
vim is not compiled with python support.
$ vim --version
...
+python/dyn
+python3/dyn
...
The build process i follow, is this one
https://github.com/Valloric/YouCompleteMe/wiki/Building-Vim-from-source
i do set python configuration directory for both (python2.7 and python) like so:
$ ./configure --with-features=huge \
--enable-multibyte \
--enable-rubyinterp \
--enable-pythoninterp\
--with-python-config-dir=/usr/lib/python2.7/config-i386-linux-gnu
\
--enable-python3interp \
--with-python3-config-dir=/usr/lib/python3.5/config-3.5m-i386-linux-gnu
\
--enable-perlinterp \
--enable-luainterp \
--enable-gui=gtk2 \
--enable-cscope \
--prefix=/usr
i'am using linux, python-dev and python3-dev are installed,
:echo has('python') return 0
--
--
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: Setting quickfix/location list context
Hi,
On Fri, Aug 19, 2016 at 7:56 AM, Ken Takata wrote:
> Hi Yegappan,
>
> 2016/8/19 Fri 23:08:16 UTC+9 yega...@gmail.com wrote:
>> Hi all,
>>
>> On Thu, Aug 18, 2016 at 5:47 AM, Yegappan Lakshmanan
>> wrote:
>> > Hi all,
>> >
>> > The attached patch adds support for setting and getting a context to/from
>> > a quickfix/location list. There is a refcount problem with this diff
>> > (which I am
>> > not able to solve).
>> >
>> > If the context is a number or a string, then the patch works without any
>> > issues. If the context is a List or a Dict, then Vim crashes if garbage
>> > collection runs. For example, the following works:
>> >
>> > :call setqflist([], 'a', {'context':[1,2,3]})
>> > :echo getqflist({'context':1})
>> >
>> > But the following doesn't work:
>> >
>> > :call setqflist([], 'a', {'context':[1,2,3]})
>> > :call garbagecollect()
>> > :echo getqflist({'context':1})
>> >
>> > Any suggestions on how to copy the context with proper update to the
>> > reference count so that garbage collection doesn't free the List/Dict?
>>
>> Any suggestions on how to fix the reference count issue?
>
> I struggled with reference counting and garbage collection when I implemented
> lambda and closure.
>
> Vim uses mark-and-sweep garbage collection. If an object is not marked, it
> will be collected even if the refcount is not zero. This is needed because
> reference counting cannot handle circular reference. To mark an object, you
> need to update the copyID member in the object (dict or list).
> Please check the garbage_collect() function in eval.c and also
> set_ref_in_XXX() functions.
>
Thanks for the suggestion. This seems to work. I have added a
set_ref_in_quickfixlist() function to mark the quickfix context
objects.
But this seems inefficient. Every time garbage collection runs,
the context of the location list for all the windows (across all
the tabs) needs to be marked. If there are too many tabs/windows,
this may take some time.
Also, how do I verify that the context is eventually garbage collected
when it is no longer referenced? I can run Vim under valgrind and look
for memory leaks. But is there a simpler way?
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.
[bug] crash with funcref in vim-7.4.2232
Hi
afl-fuzz found this command which crashes vim-7.4.2232:
$ vim -u NONE -c "echo funcref('{')"
Vim: Caught deadly signal SEGV
Vim: Finished.
Segmentation fault (core dumped)
In gdb:
Program received signal SIGSEGV, Segmentation fault.
0x004c1e26 in hash_hash (key=0x0) at hashtab.c:470
(gdb) bt
#0 0x004c1e26 in hash_hash (key=0x0) at hashtab.c:470
#1 0x004c164f in hash_find (ht=0x8ca240 ,
key=0x0) at hashtab.c:120
#2 0x005e284e in find_func (name=0x0) at userfunc.c:549
#3 0x0044ee36 in common_function (argvars=0x7fffcea0,
rettv=0x7fffd4b0, is_funcref=1) at evalfunc.c:3
735
#4 0x0044ef0f in f_funcref (argvars=0x7fffcea0,
rettv=0x7fffd4b0) at evalfunc.c:3766
#5 0x00449fb2 in call_internal_func (name=0x929620 "funcref",
argcount=1, argvars=0x7fffcea0, rettv=0x7ff
fd4b0) at evalfunc.c:997
#6 0x005e4702 in call_func (funcname=0x8e89b5
"funcref('{')vim", len=7, rettv=0x7fffd4b0, argcount_in=1,
argvars_in=0x7fffcea0, argv_func=0x0, firstline=1, lastline=1,
doesrange=0x7fffd04c, evaluate=1, partial=0x0,
selfdict_in=0x0) at userfunc.c:1372
#7 0x005e2582 in get_func_tv (name=0x8e89b5
"funcref('{')vim", len=7, rettv=0x7fffd4b0, arg=0x7fffd49
8, firstline=1, lastline=1, doesrange=0x7fffd04c, evaluate=1,
partial=0x0, selfdict=0x0) at userfunc.c:455
#8 0x0043f7d6 in eval7 (arg=0x7fffd498,
rettv=0x7fffd4b0, evaluate=1, want_string=0) at eval.c:4343
#9 0x0043f011 in eval6 (arg=0x7fffd498,
rettv=0x7fffd4b0, evaluate=1, want_string=0) at eval.c:3977
#10 0x0043eaf4 in eval5 (arg=0x7fffd498,
rettv=0x7fffd4b0, evaluate=1) at eval.c:3793
#11 0x0043ddb8 in eval4 (arg=0x7fffd498,
rettv=0x7fffd4b0, evaluate=1) at eval.c:3492
#12 0x0043dbf6 in eval3 (arg=0x7fffd498,
rettv=0x7fffd4b0, evaluate=1) at eval.c:3409
#13 0x0043da6f in eval2 (arg=0x7fffd498,
rettv=0x7fffd4b0, evaluate=1) at eval.c:3341
#14 0x0043d8a6 in eval1 (arg=0x7fffd498,
rettv=0x7fffd4b0, evaluate=1) at eval.c:3269
#15 0x00446086 in ex_echo (eap=0x7fffd5f0) at eval.c:8178
#16 0x0047aa70 in do_one_cmd (cmdlinep=0x7fffd710,
sourcing=1, cstack=0x7fffd800, fgetline=0x0, cookie
=0x0) at ex_docmd.c:2925
#17 0x0047775c in do_cmdline (cmdline=0x7fffe252 "echo
funcref('{')vim", fgetline=0x0, cookie=0x0, flags=1
1) at ex_docmd.c:1110
#18 0x00476d98 in do_cmdline_cmd (cmd=0x7fffe252 "echo
funcref('{')vim") at ex_docmd.c:715
#19 0x006236e1 in exe_commands (parmp=0x8cae40 ) at main.c:2896
#20 0x0062080e in vim_main2 () at main.c:781
#21 0x0062010f in main (argc=9, argv=0x7fffde58) at main.c:415
(gdb) up
#1 0x004c164f in hash_find (ht=0x8ca240 ,
key=0x0) at hashtab.c:120
(gdb) up
#2 0x005e284e in find_func (name=0x0) at userfunc.c:549
(gdb) up
#3 0x0044ee36 in common_function (argvars=0x7fffcea0,
rettv=0x7fffd4b0, is_funcref=1) at evalfunc.c:3735
evalfunc.c:
3733│else if (is_funcref)
3734│{
3735├> pt->pt_func = find_func(trans_name);
3736│func_ptr_ref(pt->pt_func);
3737│vim_free(name);
3738│}
(gdb) p trans_name
$1 = (char_u *) 0x0
So we have a funcref with trans_name being NULL
at evalfunc.c:3735. The current error checking looks
complex in this function, so I'm 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: [patch] fixed stack buffer overflow with invalid submatch() argument
Dominique Pellé wrote:
> Hi
>
> afl-fuzz found the following command which causes a stack
> buffer overflow in vim-7.4.2232 and older:
>
> $ vim -c 'echo substitute("x", ".", {-> submatch(10)}, "")'
>
> This one as well:
>
> $ vim -u NONE -c 'norm ix' -c 's/./\=submatch(10)/'
>
> The address sanitizer reports:
>
> =
> ==8302==ERROR: AddressSanitizer: stack-buffer-overflow on address
> 0x7f65148036b0 at pc 0x77ec07 bp 0x7ffce56f5f00 sp 0x7ffce56f5ef8
> READ of size 4 at 0x7f65148036b0 thread T0
> #0 0x77ec06 in reg_submatch /home/pel/sb/vim/src/regexp.c:7878
> #1 0x4e0043 in f_submatch /home/pel/sb/vim/src/evalfunc.c:11503
> #2 0x4afe03 in call_internal_func /home/pel/sb/vim/src/evalfunc.c:997
> #3 0x8e6e56 in call_func /home/pel/sb/vim/src/userfunc.c:1372
> #4 0x8e1948 in get_func_tv /home/pel/sb/vim/src/userfunc.c:455
> #5 0x493c4f in eval7 /home/pel/sb/vim/src/eval.c:4343
> #6 0x492837 in eval6 /home/pel/sb/vim/src/eval.c:3977
> #7 0x491dc7 in eval5 /home/pel/sb/vim/src/eval.c:3793
> #8 0x490623 in eval4 /home/pel/sb/vim/src/eval.c:3492
> #9 0x4901dc in eval3 /home/pel/sb/vim/src/eval.c:3409
> #10 0x48fdcd in eval2 /home/pel/sb/vim/src/eval.c:3341
> #11 0x48f945 in eval1 /home/pel/sb/vim/src/eval.c:3269
> #12 0x48f73c in eval0 /home/pel/sb/vim/src/eval.c:3229
> #13 0x482889 in eval_to_string /home/pel/sb/vim/src/eval.c:733
> #14 0x77cdce in vim_regsub_both /home/pel/sb/vim/src/regexp.c:7517
> #15 0x77c685 in vim_regsub_multi /home/pel/sb/vim/src/regexp.c:7390
> #16 0x4ff687 in do_sub /home/pel/sb/vim/src/ex_cmds.c:5496
> #17 0x5301e4 in do_one_cmd /home/pel/sb/vim/src/ex_docmd.c:2925
> #18 0x528514 in do_cmdline /home/pel/sb/vim/src/ex_docmd.c:1110
> #19 0x5270f8 in do_cmdline_cmd /home/pel/sb/vim/src/ex_docmd.c:715
> #20 0x985dc9 in exe_commands /home/pel/sb/vim/src/main.c:2896
> #21 0x97f1eb in vim_main2 /home/pel/sb/vim/src/main.c:781
> #22 0x97e7e6 in main /home/pel/sb/vim/src/main.c:415
> #23 0x7f65228ebf44 in __libc_start_main
> (/lib/x86_64-linux-gnu/libc.so.6+0x21f44)
> #24 0x40eb28 (/home/pel/sb/vim/src/vim+0x40eb28)
>
> Address 0x7f65148036b0 is located in stack of thread T0 at offset 688 in frame
> #0 0x4fbf21 in do_sub /home/pel/sb/vim/src/ex_cmds.c:4775
>
> This frame has 6 object(s):
> [32, 36) 'sc'
> [96, 100) 'ec'
> [160, 168) 'cmd'
> [224, 240) 'old_cursor'
> [288, 320) 'subflags_save'
> [352, 688) 'regmatch' <== Memory access at offset 688 overflows
> this variable
> HINT: this may be a false positive if your program uses some custom
> stack unwind mechanism or swapcontext
> (longjmp and C++ exceptions *are* supported)
> SUMMARY: AddressSanitizer: stack-buffer-overflow
> /home/pel/sb/vim/src/regexp.c:7878 reg_submatch
> Shadow bytes around the buggy address:
> 0x0fed228f8680: f1 f1 f1 f1 04 f4 f4 f4 f2 f2 f2 f2 04 f4 f4 f4
> 0x0fed228f8690: f2 f2 f2 f2 00 f4 f4 f4 f2 f2 f2 f2 00 00 f4 f4
> 0x0fed228f86a0: f2 f2 f2 f2 00 00 00 00 f2 f2 f2 f2 00 00 00 00
> 0x0fed228f86b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fed228f86c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> =>0x0fed228f86d0: 00 00 00 00 00 00[f4]f4 f3 f3 f3 f3 00 00 00 00
> 0x0fed228f86e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fed228f86f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fed228f8700: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
> 0x0fed228f8710: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
> 0x0fed228f8720: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
> 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
> Heap right redzone: fb
> Freed heap region: fd
> Stack left redzone: f1
> Stack mid redzone: f2
> Stack right redzone: f3
> Stack partial redzone: f4
> Stack after return: f5
> Stack use after scope: f8
> Global redzone: f9
> Global init order: f6
> Poisoned by user:f7
> Contiguous container OOB:fc
> ASan internal: fe
> ==8302==ABORTING
>
> Valgrind detects the bug as well but indirectly as use
> of uninitialized memory, since valgrind does not check
> for buffer overflows in stack.
>
> Attached patch fixes it and adds a test.
>
> Regards
> Dominique
Attached is a small update to the patch: comment in test
indicated "Vim-7.3.2232" instead of "Vim-7.4.2232".
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 e
[patch] fixed stack buffer overflow with invalid submatch() argument
Hi
afl-fuzz found the following command which causes a stack
buffer overflow in vim-7.4.2232 and older:
$ vim -c 'echo substitute("x", ".", {-> submatch(10)}, "")'
This one as well:
$ vim -u NONE -c 'norm ix' -c 's/./\=submatch(10)/'
The address sanitizer reports:
=
==8302==ERROR: AddressSanitizer: stack-buffer-overflow on address
0x7f65148036b0 at pc 0x77ec07 bp 0x7ffce56f5f00 sp 0x7ffce56f5ef8
READ of size 4 at 0x7f65148036b0 thread T0
#0 0x77ec06 in reg_submatch /home/pel/sb/vim/src/regexp.c:7878
#1 0x4e0043 in f_submatch /home/pel/sb/vim/src/evalfunc.c:11503
#2 0x4afe03 in call_internal_func /home/pel/sb/vim/src/evalfunc.c:997
#3 0x8e6e56 in call_func /home/pel/sb/vim/src/userfunc.c:1372
#4 0x8e1948 in get_func_tv /home/pel/sb/vim/src/userfunc.c:455
#5 0x493c4f in eval7 /home/pel/sb/vim/src/eval.c:4343
#6 0x492837 in eval6 /home/pel/sb/vim/src/eval.c:3977
#7 0x491dc7 in eval5 /home/pel/sb/vim/src/eval.c:3793
#8 0x490623 in eval4 /home/pel/sb/vim/src/eval.c:3492
#9 0x4901dc in eval3 /home/pel/sb/vim/src/eval.c:3409
#10 0x48fdcd in eval2 /home/pel/sb/vim/src/eval.c:3341
#11 0x48f945 in eval1 /home/pel/sb/vim/src/eval.c:3269
#12 0x48f73c in eval0 /home/pel/sb/vim/src/eval.c:3229
#13 0x482889 in eval_to_string /home/pel/sb/vim/src/eval.c:733
#14 0x77cdce in vim_regsub_both /home/pel/sb/vim/src/regexp.c:7517
#15 0x77c685 in vim_regsub_multi /home/pel/sb/vim/src/regexp.c:7390
#16 0x4ff687 in do_sub /home/pel/sb/vim/src/ex_cmds.c:5496
#17 0x5301e4 in do_one_cmd /home/pel/sb/vim/src/ex_docmd.c:2925
#18 0x528514 in do_cmdline /home/pel/sb/vim/src/ex_docmd.c:1110
#19 0x5270f8 in do_cmdline_cmd /home/pel/sb/vim/src/ex_docmd.c:715
#20 0x985dc9 in exe_commands /home/pel/sb/vim/src/main.c:2896
#21 0x97f1eb in vim_main2 /home/pel/sb/vim/src/main.c:781
#22 0x97e7e6 in main /home/pel/sb/vim/src/main.c:415
#23 0x7f65228ebf44 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x21f44)
#24 0x40eb28 (/home/pel/sb/vim/src/vim+0x40eb28)
Address 0x7f65148036b0 is located in stack of thread T0 at offset 688 in frame
#0 0x4fbf21 in do_sub /home/pel/sb/vim/src/ex_cmds.c:4775
This frame has 6 object(s):
[32, 36) 'sc'
[96, 100) 'ec'
[160, 168) 'cmd'
[224, 240) 'old_cursor'
[288, 320) 'subflags_save'
[352, 688) 'regmatch' <== Memory access at offset 688 overflows
this variable
HINT: this may be a false positive if your program uses some custom
stack unwind mechanism or swapcontext
(longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow
/home/pel/sb/vim/src/regexp.c:7878 reg_submatch
Shadow bytes around the buggy address:
0x0fed228f8680: f1 f1 f1 f1 04 f4 f4 f4 f2 f2 f2 f2 04 f4 f4 f4
0x0fed228f8690: f2 f2 f2 f2 00 f4 f4 f4 f2 f2 f2 f2 00 00 f4 f4
0x0fed228f86a0: f2 f2 f2 f2 00 00 00 00 f2 f2 f2 f2 00 00 00 00
0x0fed228f86b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fed228f86c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0fed228f86d0: 00 00 00 00 00 00[f4]f4 f3 f3 f3 f3 00 00 00 00
0x0fed228f86e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fed228f86f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fed228f8700: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
0x0fed228f8710: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
0x0fed228f8720: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
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
Heap right redzone: fb
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack partial redzone: f4
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user:f7
Contiguous container OOB:fc
ASan internal: fe
==8302==ABORTING
Valgrind detects the bug as well but indirectly as use
of uninitialized memory, since valgrind does not check
for buffer overflows in stack.
Attached patch fixes it and adds a test.
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/src/evalfunc.c b/src/evalfunc.c
index 16e2365..504f344 100644
--- a/src/evalfunc.c
+++ b/src/evalfunc.c
@@ -11491,7 +11491,11 @@ f_submatch(typval_T *argvars, typval_T *rettv)
no = (int)get_tv_number_chk(&arg
Re: Patch 7.4.2231
On 21-Aug-2016 02:37, Bram Moolenaar wrote: Patch 7.4.2231 Problem:":oldfiles" output is a very long list. Solution: Add a pattern argument. (Coot, closes #575) Files: runtime/doc/starting.txt, src/ex_cmds.h, src/eval.c, src/ex_cmds.c, src/proto/eval.pro, src/proto/ex_cmds.pro, src/testdir/test_viminfo.vim After this patch I get the following warning (on mingw64) if FEAT_QUICKFIX is not defined: gcc -c -Iproto -DWIN32 -DWINVER=0x0603 -D_WIN32_WINNT=0x0603 -DHAVE_PATHDEF -DFEAT_NORMAL -DHAVE_STDINT_H -DFEAT_GUI_W32 -DFEAT_CLIPBOARD -pipe -march=native -Wall -O3 -fomit-frame-pointer -freg-struct-return -s ex_cmds.c -o gobjnative/ex_cmds.o ex_cmds.c: In function 'ex_oldfiles': ex_cmds.c:8415:10: warning: implicit declaration of function 'skip_vimgrep_pat' [-Wimplicit-function-declaration] if (skip_vimgrep_pat(eap->arg, ®_pat, NULL) == NULL) ^~~~ ex_cmds.c:8415:53: warning: comparison between pointer and integer if (skip_vimgrep_pat(eap->arg, ®_pat, NULL) == NULL) ^~ Followed by this linker error: gcc -Iproto -DWIN32 -DWINVER=0x0603 -D_WIN32_WINNT=0x0603 -DHAVE_PATHDEF -DFEAT_NORMAL -DHAVE_STDINT_H -DFEAT_GUI_W32 -D FEAT_CLIPBOARD -pipe -march=native -Wall -O3 -fomit-frame-pointer -freg-struct-return -s -Wl,-nxcompat,-dynamicbase -mwindows -o gvim.exe gobjnative/arabic.o gobjnative/blowfish.o gobjnative/buffer.o gobjnative/charset.o gobjnative/crypt.o gobjnative/crypt_zip.o gobjnative/dict.o gobjnative/diff.o gobjnative/digraph.o gobjnative/edit.o gobjnative/eval.o gobjnative/evalfunc.o gobjnative/ex_cmds.o gobjnative/ex_cmds2.o gobjnative/ex_docmd.o gobjnative/ex_eval.o gobjnative/ex_getln.o gobjnative/farsi.o gobjnative/fileio.o gobjnative/fold.o gobjnative/getchar.o gobjnative/hardcopy.o gobjnative/hashtab.o gobjnative/json.o gobjnative/list.o gobjnative/main.o gobjnative/mark.o gobjnative/memfile.o gobjnative/memline.o gobjnative/menu.o gobjnative/message.o gobjnative/misc1.o gobjnative/misc2.o gobjnative/move.o gobjnative/mbyte.o gobjnative/normal.o gobjnative/ops.o gobjnative/option.o gobjnative/os_win32.o gobjnative/os_mswin.o gobjnative/winclip.o gobjnative/pathdef.o gobjnative/popupmnu.o gobjnative/quickfix.o gobjnative/regexp.o gobjnative/screen.o gobjnative/search.o gobjnative/sha256.o gobjnative/spell.o gobjnative/spellfile.o gobjnative/syntax.o gobjnative/tag.o gobjnative/term.o gobjnative/ui.o gobjnative/undo.o gobjnative/userfunc.o gobjnative/version.o gobjnative/vimrc.o gobjnative/window.o gobjnative/gui.o gobjnative/gui_w32.o gobjnative/gui_beval.o gobjnative/os_w32exe.o -lkernel32 -luser32 -lgdi32 -ladvapi32 -lcomdlg32 -lcomctl32 -lversion -lole32 -luuid gobjnative/ex_cmds.o:ex_cmds.c:(.text+0xb229): undefined reference to `skip_vimgrep_pat' collect2.exe: error: ld returned 1 exit status Make_cyg_ming.mak:829: recipe for target 'gvim.exe' failed make: *** [gvim.exe] Error 1 skip_vimgrep_pat() is defined in quickfix.c, but the contents are only included if FEAT_QUICKFIX or PROTO is defined. Cheers John -- -- 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: Changing the defaults with Vim 8
Hirohito Higashi wrote: > Sorry for late reply :-) > > I want to add the following setting: > > " If Vim cause malfunctioning cursor keys on slow terminals or very busy > systems, adjust the value or comment out this. > set ttimeoutlen=0 > > 'ttimeoutlen' default value is -1. > This means that use the 'timeoutlen' to the key code time-out value. > That one second. > I think most user feels "Vim is slow" in the following operation. This is > disadvantage. > - When the transition to the normal-mode by pressing the XXX in insert-mode. > i > - Similarly, in visual-mode. > V > - Similarly, in cmdline-mode. > : > > Yes, I know that lag does not occur if the input without waiting for > the display is switched. > But, most people would wait until the display is switched. And they > feels "Vim is slow...". > > `set ttimeoutlen=0` will solve the above. > > I have invested in above setting more than a year, but the trouble > does not happen even once. Zero only works when you are directly using a terminal. When using a remote shell it might not work properly. But one second is indeed too much. I have it set to 200, this still has some lag. I think 100 would work for just about everyone. -- Latest survey shows that 3 out of 4 people make up 75% of the world's population. /// 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 7.4.22
Patch 7.4.2232
Problem:The default ttimeoutlen is very long.
Solution: Use "100". (Hirohito Higashi)
Files: runtime/defaults.vim
*** ../vim-7.4.2231/runtime/defaults.vim2016-07-29 18:13:29.132175672
+0200
--- runtime/defaults.vim2016-08-20 19:13:10.629675986 +0200
***
*** 1,7
" The default vimrc file.
"
" Maintainer: Bram Moolenaar
! " Last change:2016 Jul 29
"
" This is loaded if no vimrc file was found.
" Except when Vim is run with "-u NONE" or "-C".
--- 1,7
" The default vimrc file.
"
" Maintainer: Bram Moolenaar
! " Last change:2016 Aug 20
"
" This is loaded if no vimrc file was found.
" Except when Vim is run with "-u NONE" or "-C".
***
*** 25,30
--- 25,33
set showcmd " display incomplete commands
set wildmenu " display completion matches in a status line
+ set ttimeout " time out for key codes
+ set ttimeoutlen=100 " wait up to 100ms after Esc for special key
+
" Show @@@ in the last line if it is truncated.
set display=truncate
*** ../vim-7.4.2231/src/version.c 2016-08-20 18:36:48.308969048 +0200
--- src/version.c 2016-08-20 19:10:06.155296933 +0200
***
*** 765,766
--- 765,768
{ /* Add new patch number below this line */
+ /**/
+ 2232,
/**/
--
A fine is a tax for doing wrong. A tax is a fine for doing well.
/// 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 7.4.2231
Patch 7.4.2231
Problem:":oldfiles" output is a very long list.
Solution: Add a pattern argument. (Coot, closes #575)
Files: runtime/doc/starting.txt, src/ex_cmds.h, src/eval.c,
src/ex_cmds.c, src/proto/eval.pro, src/proto/ex_cmds.pro,
src/testdir/test_viminfo.vim
*** ../vim-7.4.2230/runtime/doc/starting.txt2016-08-06 19:01:33.984856713
+0200
--- runtime/doc/starting.txt2016-08-20 18:08:24.744295631 +0200
***
*** 1561,1571
*:ol* *:oldfiles*
:ol[dfiles] List the files that have marks stored in the viminfo
file. This list is read on startup and only changes
! afterwards with ":rviminfo!". Also see |v:oldfiles|.
The number can be used with |c_#<|.
{not in Vi, only when compiled with the |+eval|
feature}
:bro[wse] ol[dfiles][!]
List file names as with |:oldfiles|, and then prompt
for a number. When the number is valid that file from
--- 1611,1630
*:ol* *:oldfiles*
:ol[dfiles] List the files that have marks stored in the viminfo
file. This list is read on startup and only changes
! afterwards with `:rviminfo!`. Also see |v:oldfiles|.
The number can be used with |c_#<|.
{not in Vi, only when compiled with the |+eval|
feature}
+ :ol[dfiles] {pat}
+ :ol[dfiles] /{pat}/
+ Like `:oldfiles` but only files matching {pat} will
+ be included. {pat} is a Vim search pattern. Instead
+ of enclosing it in / any non-ID character (see
+ |'isident'|) can be used, so long as it does not
+ appear in {pat}. Without the enclosing character the
+ pattern cannot include the bar character.
+
:bro[wse] ol[dfiles][!]
List file names as with |:oldfiles|, and then prompt
for a number. When the number is valid that file from
*** ../vim-7.4.2230/src/ex_cmds.h 2016-07-16 16:54:18.330699629 +0200
--- src/ex_cmds.h 2016-08-20 18:09:40.947603814 +0200
***
*** 992,998
RANGE|BANG|EXTRA,
ADDR_LINES),
EX(CMD_oldfiles, "oldfiles", ex_oldfiles,
! BANG|TRLBAR|SBOXOK|CMDWIN,
ADDR_LINES),
EX(CMD_omap, "omap", ex_map,
EXTRA|TRLBAR|NOTRLCOM|USECTRLV|CMDWIN,
--- 992,998
RANGE|BANG|EXTRA,
ADDR_LINES),
EX(CMD_oldfiles, "oldfiles", ex_oldfiles,
! BANG|TRLBAR|NOTADR|EXTRA|SBOXOK|CMDWIN,
ADDR_LINES),
EX(CMD_omap, "omap", ex_map,
EXTRA|TRLBAR|NOTRLCOM|USECTRLV|CMDWIN,
*** ../vim-7.4.2230/src/eval.c 2016-08-17 21:51:52.251045689 +0200
--- src/eval.c 2016-08-20 18:11:43.594490724 +0200
***
*** 8929,8988
}
}
- /*
- * List v:oldfiles in a nice way.
- */
- void
- ex_oldfiles(exarg_T *eap UNUSED)
- {
- list_T*l = vimvars[VV_OLDFILES].vv_list;
- listitem_T*li;
- int nr = 0;
-
- if (l == NULL)
- msg((char_u *)_("No old files"));
- else
- {
- msg_start();
- msg_scroll = TRUE;
- for (li = l->lv_first; li != NULL && !got_int; li = li->li_next)
- {
- msg_outnum((long)++nr);
- MSG_PUTS(": ");
- msg_outtrans(get_tv_string(&li->li_tv));
- msg_putchar('\n');
- out_flush();/* output one line at a time */
- ui_breakcheck();
- }
- /* Assume "got_int" was set to truncate the listing. */
- got_int = FALSE;
-
- #ifdef FEAT_BROWSE_CMD
- if (cmdmod.browse)
- {
- quit_more = FALSE;
- nr = prompt_for_number(FALSE);
- msg_starthere();
- if (nr > 0)
- {
- char_u *p = list_find_str(get_vim_var_list(VV_OLDFILES),
- (long)nr);
-
- if (p != NULL)
- {
- p = expand_env_save(p);
- eap->arg = p;
- eap->cmdidx = CMD_edit;
- cmdmod.browse = FALSE;
- do_exedit(eap, NULL);
- vim_free(p);
- }
- }
- }
- #endif
- }
- }
-
/* reset v:option_new, v:option_old and v:option_type */
void
reset_v_option_vars(void)
--- 8929,8934
*** ../vim-7.4.2230/src/ex_cmds.c 2016-08-17 22:29:06.158531366 +02
Re: Changing the defaults with Vim 8
Hi Bram and list,
2016-7-24(Sun) 22:03:06 UTC+9 Bram Moolenaar:
> Vim has always been conservative about the default option values.
> Without any .vimrc the default is 'compatible'. That's nice for people
> who rely on the old Vi. But how many of these still exist? I expect
> nearly all Vim users to want 'nocompatible', thus create a .vimrc ASAP.
>
> What has stopped me from changing this is the unexpected change. Many
> users will notice that Vim suddenly behaves differently. Some may be
> upset. The release of Vim 8.0 might be the best point in time to do
> this. If we do this.
>
> Besides making 'nocompatible' the default, there are a few options that
> should probably be on by default. Currently these are in
> $VIMRUNTIME/vimrc_example.vim. Most of these only have a visual effect
> or slightly change how editing works. You will notice this right away.
> The ones that have unexpected effects should be avoided.
>
> If someone wants to start in the old way, the -C flag should be used:
> vim -C
>
> If someone wants to start with 'nocompatible', but not all of the new
> option values, a .vimrc would be needed to change the settings. This is
> the most common and also most tricky part. Assuming that the user will
> want most of the new option values, but not all, he should be able to
> revert to the old value. For options that is easy. But including the
> matchit plugin is not easy to revert.
>
> What we can probably always do:
>
> set backspace=indent,eol,start
> set history=50 " keep 50 lines of command line history
> set ruler " show the cursor position all the time
> set showcmd " display incomplete commands
> set incsearch " do incremental searching
>
> " Don't use Ex mode, use Q for formatting
> map Q gq
>
> " In many terminal emulators the mouse works just fine, thus enable it.
> if has('mouse')
> set mouse=a
> endif
> if &t_Co > 2 || has("gui_running")
> syntax on
> set hlsearch
> let c_comment_strings=1
> endif
>
> if has("autocmd")
> " Enable file type detection.
> filetype plugin indent on
>
> augroup vimrcEx
> au!
>
> " For all text files set 'textwidth' to 78 characters.
> autocmd FileType text setlocal textwidth=78
>
> " When editing a file, always jump to the last known cursor position.
> " Don't do it when the position is invalid or when inside an event handler
> " (happens when dropping a file on gvim).
> autocmd BufReadPost *
> \ if line("'\"") >= 1 && line("'\"") <= line("$") |
> \ exe "normal! g`\"" |
> \ endif
>
> augroup END
> else
> set autoindent" always set autoindenting on
> endif
>
> if has('langmap') && exists('+langnoremap')
> set langnoremap
> endif
>
>
> Probably not:
>
> " these two leave files behind
> set backup
> set undofile
>
> " may conflict with a user mapping
> inoremap u
>
> " hard to revert
> if has('syntax') && has('eval')
> packadd matchit
> endif
>
> Comments?
Sorry for late reply :-)
I want to add the following setting:
" If Vim cause malfunctioning cursor keys on slow terminals or very busy
systems, adjust the value or comment out this.
set ttimeoutlen=0
'ttimeoutlen' default value is -1.
This means that use the 'timeoutlen' to the key code time-out value.
That one second.
I think most user feels "Vim is slow" in the following operation. This is
disadvantage.
- When the transition to the normal-mode by pressing the XXX in insert-mode.
i
- Similarly, in visual-mode.
V
- Similarly, in cmdline-mode.
:
Yes, I know that lag does not occur if the input without waiting for the
display is switched.
But, most people would wait until the display is switched. And they feels "Vim
is slow...".
`set ttimeoutlen=0` will solve the above.
I have invested in above setting more than a year, but the trouble does not
happen even once.
thanks.
--
Best regards,
Hirohito Higashi (a.k.a. h_east)
--
--
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 7.4.2230
Patch 7.4.2230
Problem:There is no equivalent of 'smartcase' for a tag search.
Solution: Add value "followscs" and "smart" to 'tagcase'. (Christian
Brabandt, closes #712) Turn tagcase test into new style.
Files: runtime/doc/options.txt, runtime/doc/tagsrch.txt, src/option.h,
src/tag.c, src/search.c, src/proto/search.pro,
src/testdir/test_tagcase.in, src/testdir/test_tagcase.ok,
src/testdir/test_tagcase.vim, src/Makefile,
src/testdir/Make_all.mak, src/testdir/test_alot.vim
*** ../vim-7.4.2229/runtime/doc/options.txt 2016-08-14 19:54:16.324930218
+0200
--- runtime/doc/options.txt 2016-08-20 16:17:45.435665366 +0200
***
*** 7375,7380
--- 7417,7425
By default, tag searches are case-sensitive. Case is ignored when
'ignorecase' is set and 'tagcase' is "followic", or when 'tagcase' is
"ignore".
+ Also when 'tagcase' is "followscs" and 'smartcase' is set, or
+ 'tagcase' is "smart", and the pattern contains only lowercase
+ characters.
When 'tagbsearch' is off, tags searching is slower when a full match
exists, but faster when no full match exists. Tags in unsorted tags
***
*** 7393,7400
--- 7438,7447
This option specifies how case is handled when searching the tags
file:
followic Follow the 'ignorecase' option
+ followscsFollow the 'smartcase' and 'ignorecase' options
ignore Ignore case
matchMatch case
+ smartIgnore case unless an upper case letter is used
*'taglength'* *'tl'*
'taglength' 'tl' number (default 0)
*** ../vim-7.4.2229/runtime/doc/tagsrch.txt 2015-11-24 18:45:52.633647066
+0100
--- runtime/doc/tagsrch.txt 2016-08-20 16:24:45.035950333 +0200
***
*** 84,97
changed, to avoid confusion when using ":tnext". It is changed when using
":tag {ident}".
! The ignore-case matches are not found for a ":tag" command when the
! 'ignorecase' option is off and 'tagcase' is "followic" or when 'tagcase' is
! "match". They are found when a pattern is used (starting with a "/") and for
! ":tselect", also when 'ignorecase' is off and 'tagcase' is "followic" or when
! 'tagcase' is "match". Note that using ignore-case tag searching disables
! binary searching in the tags file, which causes a slowdown. This can be
! avoided by fold-case sorting the tag file. See the 'tagbsearch' option for an
! explanation.
==
2. Tag stack *tag-stack* *tagstack* *E425*
--- 84,106
changed, to avoid confusion when using ":tnext". It is changed when using
":tag {ident}".
! The ignore-case matches are not found for a ":tag" command when:
! - the 'ignorecase' option is off and 'tagcase' is "followic"
! - 'tagcase' is "match"
! - 'tagcase' is "smart" and the pattern contains an upper case character.
! - 'tagcase' is "followscs" and 'smartcase' option is on and the pattern
! contains an upper case character.
!
! The gnore-case matches are found when:
! - a pattern is used (starting with a "/")
! - for ":tselect"
! - when 'tagcase' is "followic" and 'ignorecase' is off
! - when 'tagcase' is "match"
! - when 'tagcase' is "followscs" and the 'smartcase' option is off
!
! Note that using ignore-case tag searching disables binary searching in the
! tags file, which causes a slowdown. This can be avoided by fold-case sorting
! the tag file. See the 'tagbsearch' option for an explanation.
==
2. Tag stack *tag-stack* *tagstack* *E425*
***
*** 442,454
The next file in the list is not used when:
- A matching static tag for the current buffer has been found.
- A matching global tag has been found.
! This also depends on whether case is ignored. Case is ignored when
! 'ignorecase' is set and 'tagcase' is "followic", or when 'tagcase' is
! "ignore". If case is not ignored, and the tags file only has a match without
! matching case, the next tags file is searched for a match with matching case.
! If no tag with matching case is found, the first match without matching case
! is used. If case is ignored, and a matching global tag with or without
! matching case is found, this one is used, no further tags files are searched.
When a tag file name starts with "./", the '.' is replaced with the path of
the current file. This makes it possible to use a tags file in the directory
--- 451,468
The next file in the list is not used when:
- A matching static tag for the current buffer has been found.
- A matching global tag has been found.
! This also depends on whether case is ignored. Case is ignored when:
! - 'tagcase' i
Patch 7.4.2229
Patch 7.4.2229
Problem:Startup test fails on Solaris.
Solution: Recognize a character device. (Danek Duvall)
Files: src/buffer.c, src/fileio.c, src/proto/fileio.pro, src/vim.h
*** ../vim-7.4.2228/src/buffer.c2016-08-14 19:08:41.838022274 +0200
--- src/buffer.c2016-08-20 14:58:16.826642753 +0200
***
*** 220,225
--- 220,228
# ifdef S_ISSOCK
|| S_ISSOCK(perm)
# endif
+ # ifdef OPEN_CHR_FILES
+ || (S_ISCHR(perm) && is_dev_fd_file(curbuf->b_ffname))
+ # endif
))
read_fifo = TRUE;
if (read_fifo)
*** ../vim-7.4.2228/src/fileio.c2016-08-09 22:13:51.858043815 +0200
--- src/fileio.c2016-08-20 15:00:50.941254004 +0200
***
*** 27,36
/* Is there any system that doesn't have access()? */
#define USE_MCH_ACCESS
- #if (defined(sun) || defined(__FreeBSD__)) && defined(S_ISCHR)
- # define OPEN_CHR_FILES
- static int is_dev_fd_file(char_u *fname);
- #endif
#ifdef FEAT_MBYTE
static char_u *next_fenc(char_u **pp);
# ifdef FEAT_EVAL
--- 27,32
***
*** 2718,2731
return OK;
}
! #ifdef OPEN_CHR_FILES
/*
* Returns TRUE if the file name argument is of the form "/dev/fd/\d\+",
* which is the name of files used for process substitution output by
* some shells on some operating systems, e.g., bash on SunOS.
* Do not accept "/dev/fd/[012]", opening these may hang Vim.
*/
! static int
is_dev_fd_file(char_u *fname)
{
return (STRNCMP(fname, "/dev/fd/", 8) == 0
--- 2714,2727
return OK;
}
! #if defined(OPEN_CHR_FILES) || defined(PROTO)
/*
* Returns TRUE if the file name argument is of the form "/dev/fd/\d\+",
* which is the name of files used for process substitution output by
* some shells on some operating systems, e.g., bash on SunOS.
* Do not accept "/dev/fd/[012]", opening these may hang Vim.
*/
! int
is_dev_fd_file(char_u *fname)
{
return (STRNCMP(fname, "/dev/fd/", 8) == 0
*** ../vim-7.4.2228/src/proto/fileio.pro2016-08-10 20:53:01.679116172
+0200
--- src/proto/fileio.pro2016-08-20 15:01:50.784721772 +0200
***
*** 1,6
--- 1,7
/* fileio.c */
void filemess(buf_T *buf, char_u *name, char_u *s, int attr);
int readfile(char_u *fname, char_u *sfname, linenr_T from, linenr_T
lines_to_skip, linenr_T lines_to_read, exarg_T *eap, int flags);
+ int is_dev_fd_file(char_u *fname);
int prep_exarg(exarg_T *eap, buf_T *buf);
void set_file_options(int set_options, exarg_T *eap);
void set_forced_fenc(exarg_T *eap);
*** ../vim-7.4.2228/src/vim.h 2016-08-14 19:54:16.332930147 +0200
--- src/vim.h 2016-08-20 15:01:36.068852496 +0200
***
*** 2485,2488
--- 2485,2492
#define FNE_INCL_BR 1 /* include [] in name */
#define FNE_CHECK_START 2 /* check name starts with valid
character */
+ #if (defined(sun) || defined(__FreeBSD__)) && defined(S_ISCHR)
+ # define OPEN_CHR_FILES
+ #endif
+
#endif /* VIM__H */
*** ../vim-7.4.2228/src/version.c 2016-08-18 23:04:44.666592772 +0200
--- src/version.c 2016-08-20 14:57:41.510961033 +0200
***
*** 765,766
--- 765,768
{ /* Add new patch number below this line */
+ /**/
+ 2229,
/**/
--
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.
Re: error in test_startup_utf8
Danek Duvall wrote: > On Fri, Aug 19, 2016 at 09:45:32PM +0200, Bram Moolenaar wrote: > > > There is a similar check already in fileio.c: > > > > # ifdef OPEN_CHR_FILES > > && !(S_ISCHR(perm) && is_dev_fd_file(fname)) > > /* ... or a character special file named /dev/fd/ */ > > # endif > > Oh, well, that's useful. Updated patch attached. Thanks, I'll include it now. -- Bumper sticker: Honk if you love peace and quiet. /// 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.
