E94 generated by bufwinnr()
Hi,
With the following in my vimrc
set debug=msg,throw
the function bufwinnr() generates E94 if the buffer does not
exist. Example:
:echo bufwinnr("nothing")
Is it correct to raise an error in this case? I think that there
should be no error because when the buffer does not exist the
function returns a predefined value (-1) that can be checked in
scripts.
Thanks!
--
Jakson Alves de Aquino
www.lepem.ufc.br/aquino.php?lang=en
--
--
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: SIGSEGV at syntax.c:2101
On Sat, Jan 31, 2015 at 12:57 AM, Jakson Alves de Aquino wrote: > On Sat, Jan 31, 2015 at 06:30:05AM +0100, Dominique Pellé wrote: >> No, I don't think it's your fault. It should be OK I think >> to enable FEAT_CONCEAL the way you did but it's better >> to build with --with-features=huge anyway. >> >> So it would still be interesting to see why it crashed it you >> can. Unfortunately, you copied only the last lines of >> the address sanitizer, we're missing the most important >> piece of information from asan. Can you try it again with... >> >> $ cd vim/src >> $ ./vim 2> asan.log >> >> ... and send the full output in asan.log > > I configured the build as before: > >CFLAGS=-g ./configure --enable-pythoninterp=yes --enable-multibyte > > And the asan.log is (I removed the first directories from file > paths to make them shorter): > > = > ==6353==ERROR: AddressSanitizer: heap-use-after-free on address > 0x616fa790 at pc 0x79a090 bp 0x7fff2c094bd0 sp 0x7fff2c094bc0 > READ of size 8 at 0x616fa790 thread T0 > #0 0x79a08f in nfa_regmatch src/regexp_nfa.c:5505 > #1 0x7a0c6c in nfa_regtry src/regexp_nfa.c:6860 > #2 0x7a20a9 in nfa_regexec_both src/regexp_nfa.c:7050 > #3 0x7a296a in nfa_regexec_multi src/regexp_nfa.c:7263 > #4 0x7a32a3 in vim_regexec_multi src/regexp.c:8273 > #5 0x866236 in syn_regexec src/syntax.c:3284 > #6 0x8601d4 in syn_current_attr src/syntax.c:2097 > #7 0x85ee2c in get_syntax_attr src/syntax.c:1854 > #8 0x7b9d36 in win_line src/screen.c:4354 > #9 0x7ad9c5 in win_update src/screen.c:2011 > #10 0x7a6e0b in update_screen src/screen.c:678 > #11 0x89a9d7 in set_shellsize src/term.c:3174 > #12 0x89a451 in shell_resized src/term.c:3036 > #13 0x72cf4d in handle_resize src/os_unix.c:487 > #14 0x72cd55 in mch_inchar src/os_unix.c:399 > #15 0x8a5748 in ui_inchar src/ui.c:199 > #16 0x5dbfb7 in inchar src/getchar.c:3098 > #17 0x5db251 in vgetorpeek src/getchar.c:2873 > #18 0x5d5de6 in vpeekc src/getchar.c:1875 > #19 0x5d5fd1 in char_avail src/getchar.c:1925 > #20 0x7da67a in redrawing src/screen.c:10421 > #21 0x7a5963 in update_screen src/screen.c:500 > #22 0x95691b in main_loop src/main.c:1237 > #23 0x95616e in main src/main.c:1034 > #24 0x7f9370260ec4 in __libc_start_main > (/lib/x86_64-linux-gnu/libc.so.6+0x21ec4) > #25 0x431558 (/usr/local/bin/vim+0x431558) > > 0x616fa790 is located 528 bytes inside of 640-byte region > [0x616fa580,0x616fa800) > freed by thread T0 here: > #0 0x7f93731c553f in __interceptor_free > (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x5753f) > #1 0x6728d3 in vim_free src/misc2.c:1741 > #2 0x7a2730 in nfa_regfree src/regexp_nfa.c:7182 > #3 0x7a2c4b in vim_regfree src/regexp.c:8138 > #4 0x868120 in syn_clear_pattern src/syntax.c:3598 > #5 0x867404 in syntax_clear src/syntax.c:3495 > #6 0x86866e in syn_cmd_clear src/syntax.c:3655 > #7 0x87790b in ex_syntax src/syntax.c:6285 > #8 0x544222 in do_one_cmd src/ex_docmd.c:2940 > #9 0x53c708 in do_cmdline src/ex_docmd.c:1133 > #10 0x4ff928 in call_user_func src/eval.c:23618 > #11 0x4ba42f in call_func src/eval.c:8598 > #12 0x4b97a7 in get_func_tv src/eval.c:8434 > #13 0x4a682d in ex_call src/eval.c:3505 > #14 0x544222 in do_one_cmd src/ex_docmd.c:2940 > #15 0x53c708 in do_cmdline src/ex_docmd.c:1133 > #16 0x5ba897 in apply_autocmds_group src/fileio.c:9487 > #17 0x5b95ce in apply_autocmds src/fileio.c:9045 > #18 0x71490a in did_set_string_option src/option.c:7145 > #19 0x70abcc in do_set src/option.c:4892 > #20 0x570bc2 in ex_set src/ex_docmd.c:11972 > #21 0x544222 in do_one_cmd src/ex_docmd.c:2940 > #22 0x53c708 in do_cmdline src/ex_docmd.c:1133 > #23 0x4f5edf in ex_execute src/eval.c:21819 > #24 0x544222 in do_one_cmd src/ex_docmd.c:2940 > #25 0x53c708 in do_cmdline src/ex_docmd.c:1133 > #26 0x5ba897 in apply_autocmds_group src/fileio.c:9487 > #27 0x5b95ce in apply_autocmds src/fileio.c:9045 > #28 0x714a0e in did_set_string_option src/option.c:7153 > #29 0x70abcc in do_set src/option.c:4892 > > previously allocated by thread T0 here: > #0 0x7f93731c57b7 in __interceptor_malloc > (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x577b7) > #1 0x6705fb in lalloc src/misc2.c:921 > #2 0x7a2229 in nfa_regcomp src/regexp_nfa.c:7118 > #3 0x7a2aee in vim_regcomp src/regexp.c:8084 > #4 0x8744d1 in get_syn_pattern src/syntax.c:5667 > #5 0x86fab5 in syn_cmd_match src/syntax.c:
Re: SIGSEGV at syntax.c:2101
On Sat, Jan 31, 2015 at 06:30:05AM +0100, Dominique Pellé wrote: > No, I don't think it's your fault. It should be OK I think > to enable FEAT_CONCEAL the way you did but it's better > to build with --with-features=huge anyway. > > So it would still be interesting to see why it crashed it you > can. Unfortunately, you copied only the last lines of > the address sanitizer, we're missing the most important > piece of information from asan. Can you try it again with... > > $ cd vim/src > $ ./vim 2> asan.log > > ... and send the full output in asan.log I configured the build as before: CFLAGS=-g ./configure --enable-pythoninterp=yes --enable-multibyte And the asan.log is (I removed the first directories from file paths to make them shorter): = ==6353==ERROR: AddressSanitizer: heap-use-after-free on address 0x616fa790 at pc 0x79a090 bp 0x7fff2c094bd0 sp 0x7fff2c094bc0 READ of size 8 at 0x616fa790 thread T0 #0 0x79a08f in nfa_regmatch src/regexp_nfa.c:5505 #1 0x7a0c6c in nfa_regtry src/regexp_nfa.c:6860 #2 0x7a20a9 in nfa_regexec_both src/regexp_nfa.c:7050 #3 0x7a296a in nfa_regexec_multi src/regexp_nfa.c:7263 #4 0x7a32a3 in vim_regexec_multi src/regexp.c:8273 #5 0x866236 in syn_regexec src/syntax.c:3284 #6 0x8601d4 in syn_current_attr src/syntax.c:2097 #7 0x85ee2c in get_syntax_attr src/syntax.c:1854 #8 0x7b9d36 in win_line src/screen.c:4354 #9 0x7ad9c5 in win_update src/screen.c:2011 #10 0x7a6e0b in update_screen src/screen.c:678 #11 0x89a9d7 in set_shellsize src/term.c:3174 #12 0x89a451 in shell_resized src/term.c:3036 #13 0x72cf4d in handle_resize src/os_unix.c:487 #14 0x72cd55 in mch_inchar src/os_unix.c:399 #15 0x8a5748 in ui_inchar src/ui.c:199 #16 0x5dbfb7 in inchar src/getchar.c:3098 #17 0x5db251 in vgetorpeek src/getchar.c:2873 #18 0x5d5de6 in vpeekc src/getchar.c:1875 #19 0x5d5fd1 in char_avail src/getchar.c:1925 #20 0x7da67a in redrawing src/screen.c:10421 #21 0x7a5963 in update_screen src/screen.c:500 #22 0x95691b in main_loop src/main.c:1237 #23 0x95616e in main src/main.c:1034 #24 0x7f9370260ec4 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21ec4) #25 0x431558 (/usr/local/bin/vim+0x431558) 0x616fa790 is located 528 bytes inside of 640-byte region [0x616fa580,0x616fa800) freed by thread T0 here: #0 0x7f93731c553f in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x5753f) #1 0x6728d3 in vim_free src/misc2.c:1741 #2 0x7a2730 in nfa_regfree src/regexp_nfa.c:7182 #3 0x7a2c4b in vim_regfree src/regexp.c:8138 #4 0x868120 in syn_clear_pattern src/syntax.c:3598 #5 0x867404 in syntax_clear src/syntax.c:3495 #6 0x86866e in syn_cmd_clear src/syntax.c:3655 #7 0x87790b in ex_syntax src/syntax.c:6285 #8 0x544222 in do_one_cmd src/ex_docmd.c:2940 #9 0x53c708 in do_cmdline src/ex_docmd.c:1133 #10 0x4ff928 in call_user_func src/eval.c:23618 #11 0x4ba42f in call_func src/eval.c:8598 #12 0x4b97a7 in get_func_tv src/eval.c:8434 #13 0x4a682d in ex_call src/eval.c:3505 #14 0x544222 in do_one_cmd src/ex_docmd.c:2940 #15 0x53c708 in do_cmdline src/ex_docmd.c:1133 #16 0x5ba897 in apply_autocmds_group src/fileio.c:9487 #17 0x5b95ce in apply_autocmds src/fileio.c:9045 #18 0x71490a in did_set_string_option src/option.c:7145 #19 0x70abcc in do_set src/option.c:4892 #20 0x570bc2 in ex_set src/ex_docmd.c:11972 #21 0x544222 in do_one_cmd src/ex_docmd.c:2940 #22 0x53c708 in do_cmdline src/ex_docmd.c:1133 #23 0x4f5edf in ex_execute src/eval.c:21819 #24 0x544222 in do_one_cmd src/ex_docmd.c:2940 #25 0x53c708 in do_cmdline src/ex_docmd.c:1133 #26 0x5ba897 in apply_autocmds_group src/fileio.c:9487 #27 0x5b95ce in apply_autocmds src/fileio.c:9045 #28 0x714a0e in did_set_string_option src/option.c:7153 #29 0x70abcc in do_set src/option.c:4892 previously allocated by thread T0 here: #0 0x7f93731c57b7 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x577b7) #1 0x6705fb in lalloc src/misc2.c:921 #2 0x7a2229 in nfa_regcomp src/regexp_nfa.c:7118 #3 0x7a2aee in vim_regcomp src/regexp.c:8084 #4 0x8744d1 in get_syn_pattern src/syntax.c:5667 #5 0x86fab5 in syn_cmd_match src/syntax.c:4947 #6 0x87790b in ex_syntax src/syntax.c:6285 #7 0x544222 in do_one_cmd src/ex_docmd.c:2940 #8 0x53c708 in do_cmdline src/ex_docmd.c:1133 #9 0x4f5edf in ex_execute src/eval.c:21819 #10 0x544222 in do_one_cmd src/ex_docmd.c:2940 #11 0x53c708 in do_cmdline src/ex_docmd.c:1133 #12 0x4ff928 in call_user_func src/eval.c:23618 #13 0x4ba42f in call_func src/eval.c:8598 #14 0x4b97a7 in get_func_tv src/eval.c:8434 #15 0x4a682d in ex_call src/eval.c:3505 #16 0x544222 in do_one_cmd src/ex_docmd.c:2940 #17 0x53c708 in do_cmdline src/ex_docmd.c:1133
Re: SIGSEGV at syntax.c:2101
On Fri, Jan 30, 2015 at 08:12:05PM -0500, Jakson Alves de Aquino wrote: > On Fri, Jan 30, 2015 at 07:59:19PM -0500, Jakson Alves de Aquino wrote: > > On Sat, Jan 31, 2015 at 12:14:14AM +0100, Dominique Pellé wrote: > > > In the stack, I see update_screen() being called twice as > > > a result of a screen resize event. Maybe that's causing the > > > problem. > > > > You might be right. I was running Vim inside Tmux (Ubuntu 14.10) > > and it splits the Tmux window to start R. So, the size of the > > screen changes while the Vim function StartR() is being executed. > > If I run either Vim not in Tmux or GVim, R is started in another > > terminal emulator and there is no crash. > > > > > I don't know how to reproduce it. > > > > > > Can you try to reproduce it after recompiling Vim with the > > > address sanitizer (asan)? It's only a matter of compiling > > > and linking with -fsanitize=address. It assumes that your > > > compiler is recent enough (gcc >= 4.8 or clang >= 3.3?) > > > > With the patch, it crashes and seems to output the same backtrace > > of gdb, but I cannot see the first lines, even if I try to scroll > > the Tmux pane. > > Sorry, I applied the patch wrongly because there was a line break > in the longest line. After applying it correctly, the output that > I can copy in Tmux copy mode is: > > 0x0c2c80017c20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > 0x0c2c80017c30: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > 0x0c2c80017c40: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > 0x0c2c80017c50: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > 0x0c2c80017c60: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > 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 > ==4435==ABORTING > > > > > Please also try to run vim with valgrind (without building with asan) > > > It may find other bugs than asan: uninitialized memory accesses > > > are not found by asan but they are found by valgrind. > > > > Running vim with valgrind, before the patch, there is no crash. The crash was my fault. I had enabled CONCEAL in this way: diff -r 84171683fd66 src/feature.h --- a/src/feature.h Tue Jan 27 22:52:15 2015 +0100 +++ b/src/feature.h Fri Jan 30 20:16:50 2015 -0500 @@ -522,9 +522,7 @@ * +conceal'conceal' option. Needs syntax highlighting * as this is how the concealed text is defined. */ -#if defined(FEAT_BIG) && defined(FEAT_SYN_HL) # define FEAT_CONCEAL -#endif /* * +spell spell checking There is no crash if I configure the build with: ./configure --with-features=huge --enable-pythoninterp=yes I am sorry for the noise! -- Jakson Alves de Aquino www.lepem.ufc.br/aquino.php?lang=en -- -- 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: SIGSEGV at syntax.c:2101
On Fri, Jan 30, 2015 at 07:59:19PM -0500, Jakson Alves de Aquino wrote: > On Sat, Jan 31, 2015 at 12:14:14AM +0100, Dominique Pellé wrote: > > In the stack, I see update_screen() being called twice as > > a result of a screen resize event. Maybe that's causing the > > problem. > > You might be right. I was running Vim inside Tmux (Ubuntu 14.10) > and it splits the Tmux window to start R. So, the size of the > screen changes while the Vim function StartR() is being executed. > If I run either Vim not in Tmux or GVim, R is started in another > terminal emulator and there is no crash. > > > I don't know how to reproduce it. > > > > Can you try to reproduce it after recompiling Vim with the > > address sanitizer (asan)? It's only a matter of compiling > > and linking with -fsanitize=address. It assumes that your > > compiler is recent enough (gcc >= 4.8 or clang >= 3.3?) > > With the patch, it crashes and seems to output the same backtrace > of gdb, but I cannot see the first lines, even if I try to scroll > the Tmux pane. Sorry, I applied the patch wrongly because there was a line break in the longest line. After applying it correctly, the output that I can copy in Tmux copy mode is: 0x0c2c80017c20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c2c80017c30: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c2c80017c40: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c2c80017c50: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c2c80017c60: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 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 ==4435==ABORTING > > Please also try to run vim with valgrind (without building with asan) > > It may find other bugs than asan: uninitialized memory accesses > > are not found by asan but they are found by valgrind. > > Running vim with valgrind, before the patch, there is no crash. -- -- 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: SIGSEGV at syntax.c:2101
On Sat, Jan 31, 2015 at 12:14:14AM +0100, Dominique Pellé wrote: > In the stack, I see update_screen() being called twice as > a result of a screen resize event. Maybe that's causing the > problem. You might be right. I was running Vim inside Tmux (Ubuntu 14.10) and it splits the Tmux window to start R. So, the size of the screen changes while the Vim function StartR() is being executed. If I run either Vim not in Tmux or GVim, R is started in another terminal emulator and there is no crash. > I don't know how to reproduce it. > > Can you try to reproduce it after recompiling Vim with the > address sanitizer (asan)? It's only a matter of compiling > and linking with -fsanitize=address. It assumes that your > compiler is recent enough (gcc >= 4.8 or clang >= 3.3?) With the patch, it crashes and seems to output the same backtrace of gdb, but I cannot see the first lines, even if I try to scroll the Tmux pane. > Please also try to run vim with valgrind (without building with asan) > It may find other bugs than asan: uninitialized memory accesses > are not found by asan but they are found by valgrind. Running vim with valgrind, before the patch, there is no crash. Thanks! -- Jakson -- -- 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.
SIGSEGV at syntax.c:2101
Hi, When I am editing an Rnoweb file and start R with the Vim-R-plugin, Vim crashes: (gdb) bt #0 0x005c75c8 in syn_current_attr (syncing=0, displaying=1, can_spell=0x0, keep_state=0) at syntax.c:2101 #1 0x005c6da6 in get_syntax_attr (col=0, can_spell=0x0, keep_state=0) at syntax.c:1854 #2 0x00586dcc in win_line (wp=0x8d3720, lnum=15, startrow=14, endrow=28, nochange=1) at screen.c:4354 #3 0x005823bf in win_update (wp=0x8d3720) at screen.c:2011 #4 0x0057f9d1 in update_screen (type=40) at screen.c:678 #5 0x005dfbed in set_shellsize (width=0, height=0, mustset=0) at term.c:3174 #6 0x005df9d1 in shell_resized () at term.c:3036 #7 0x00548332 in handle_resize () at os_unix.c:487 #8 0x0054820b in mch_inchar (buf=0xc3d558 "", maxlen=71, wtime=0, tb_change_cnt=21) at os_unix.c:399 #9 0x005e403e in ui_inchar (buf=0xc3d558 "", maxlen=71, wtime=0, tb_change_cnt=21) at ui.c:199 #10 0x004d05c2 in inchar (buf=0xc3d558 "", maxlen=215, wait_time=0, tb_change_cnt=21) at getchar.c:3098 #11 0x004d01ae in vgetorpeek (advance=0) at getchar.c:2873 #12 0x004ce91c in vpeekc () at getchar.c:1875 #13 0x004ce9b7 in char_avail () at getchar.c:1925 #14 0x00591b48 in redrawing () at screen.c:10421 #15 0x0057f4bb in update_screen (type=10) at screen.c:500 #16 0x0062a6bc in main_loop (cmdwin=0, noexmode=0) at main.c:1237 #17 0x0062a215 in main (argc=4, argv=0x7fffdc88) at main.c:1034 (gdb) Rnoweb files combine LaTeX and R code. When R starts, it sends a message to Vim using the clientserver feature. The message is a list of loaded packages and Vim reacts to the message updating the syntax of R functions. To update the syntax of R code, Vim sources syntax scripts which add the new functions and then run the following command: silent exe 'set filetype=' . &filetype I first noted the crash on Monday. I build Vim from mercurial repository and, to get the backtrace with gdb, I have configured the build with the command: CFLAGS=-g ./configure --enable-pythoninterp=yes --enable-multibyte Thanks! -- Jakson Alves de Aquino www.lepem.ufc.br/aquino.php?lang=en -- -- 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: New digraph
On Tue, Jun 17, 2014 at 7:21 AM, John Beckett wrote: [...] > Can I hijack this to ask about U+2022 which is a nice bullet. > > One way to insert that in Vim is to execute the following > (using :put="\u2022" fails because the quote is a comment): > > :let s = "\u2022" > :put =s In Insert mode, you can do the following to insert the bullet: u2022 -- -- 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.
Enable clientserver after startup
Hi, Currently, the clientserver feature is automatically enabled when GVim starts, but it has to be enable by the command line argument --servername when Vim runs in a terminal emulator. The Vim-R-plugin uses the clientserver feature to receive messages from R. The messages tell Vim to: - Update the list of functions for syntax highlight. - Update the list of objects for omnicompletion. - Update the list of objects in the Object Browser (if opened). Everything works fine. The problem is that users of Vim in a terminal emulator have to read the documentation to discover that they must use the argument --servername, which is a uncommon requirement for using Vim effectively. So, I wonder how difficult it would be to allow the clientserver feature to be enabled either after Vim startup (so the Vim-R-plugin could start it) or while the vimrc is being sourced. An alternative idea to improve the situation is to create a function that queues commands to be executed when Vim is ready to do it, so a server written in Python, C or other language could receive commands and call this function. Note: The Vim-R-plugin is here: http://www.vim.org/scripts/script.php?script_id=2628 Thank you! -- Jakson Alves de Aquino Federal University of Ceara Social Sciences Department www.lepem.ufc.br/aquino.php -- -- 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: "7.4" not listed in upload form
On Fri, Mar 7, 2014 at 4:45 PM, Bram Moolenaar wrote: > > I have added 7.4 to the menu entry. > 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: "7.4" not listed in upload form
On Fri, Mar 7, 2014 at 1:58 PM, Nikolay Pavlov wrote: > On Mar 7, 2014 5:16 PM, "Jakson Alves de Aquino" > wrote: > > The form to upload new versions of scripts at www.vim.org doesn't show > > "7.4" as an option of required Vim version; the highest version is > > "7.3". I think that "7.4" should be included in the drop down list. > > Vim version string is mostly not filtered on the server side, so as a > temporary fix you can just add a userscript/browser plugin that adds it to > dropdown list. > Thanks! This is a good idea and it seems that I can do this with Google Chrome standard developer tools. So it may not be necessary to create an userscript/plugin just for this. Anyway, I'm not going to upload a new version of my script (Vim-R-plugin) right now. I plan to release it only in April. -- Jakson -- -- 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.
"7.4" not listed in upload form
Hi, The form to upload new versions of scripts at www.vim.org doesn't show "7.4" as an option of required Vim version; the highest version is "7.3". I think that "7.4" should be included in the drop down list. Thanks, -- Jakson Aquino -- -- 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.
The word "shell" in vim tutor
Hello, People using Windows may get confused while doing the vim tutor wherever the word "shell" appears. I suggest the following small change in step 3 of Lesson 1.2 (EXITING VIM): Current wording: 3. When you see the shell prompt, type the command that got you into this tutor. That would be: vimtutor Suggested wording (may be improved): 3. Repeat the procedure that got you into this tutor. In most cases, you will see the shell prompt and should type: vimtutor I believe that the change above alleviates the problem because it gives a clearer hint that the tutor was written to an environment that may be different from what the user is. Thanks! -- Jakson Alves de Aquino Federal University of Ceará Social Sciences Department www.lepem.ufc.br/aquino.php -- -- 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/groups/opt_out.
Re: Documentation of Funcref
Em 23-08-2013 03:04, Tony Mechelynck escreveu:
> On 23/08/13 06:01, Nikolay Pavlov wrote:
>>
>> On Aug 23, 2013 1:24 AM, "Jakson Alves de Aquino" > <mailto:jalve...@gmail.com>> wrote:
>> >
>> >
>> > Hi,
>> >
>> > The documentation of Funcref includes the following statement:
>> >
>> > A Funcref variable must start with a capital, "s:", "w:",
>> > "t:" or "b:".
>> >
>> > It seems that sentence is incomplete. I think the intention was to
>> > write:
>> >
>> > A Funcref variable must start with a capital letter and both
>> > the function being referred to and the Funcref variable must
>> > have the same scope, being prefixed by "s:", "w:", "t:" or
>> > "b:".
>>
>> I do not understand. Vim currently has nothing else but global
>> functions. There are no scoped ones, s:Fname is simply a shortcut for
>> N_Fname, where N is current script number. Anonymous functions are
>> global ones with just N as their name, N is number of anonymous
>> functions defined in this session (i.e. it is just an incremented
>> counter).
>
> The function is global. The _Funcref variable_ is a variable and as such
> it can be a global variable, or it can be script-local, buffer-local,
> window-local or tabpage-local. Not mentioned is the case where the
> variable would be function-local. Such locality just means that the
> _variable_ is only visible from within the same scope; it says nothing
> about the underlying function which can be called indirectly through the
> variable.
>
> The difference here is between
>
> function Funcname(arg1, arg2, arg3)
> ...
> endfunction
>
> and
>
> let t:VarFuncRef = function("Funcname")
>
> Funcname() is the function, and as such it is global.
> t:VarFuncRef is a Funcref variable referencing that function, and in
> this case the variable is tabpage-local.
>
> A global function can, however, be defined with s: (or the equivalent
> bur more cumbersome SID_) and then it will normally not be visible from
> outside the script where it was defined, except maybe via a
> non-script-local mapping defined within the same script. In order to use
> that s:Function as argument to function() to create a Funcref you must
> be within that very same script.
>
>>
>> Thus I have not seen the "must have the same scope" behavior you
>> describe.
>>
>> Also note that using b:Fname (or g:Fname) as function name is
>> undocumented. And it is as well NOT a name of buffer-local function.
>
> See above.
>
>>
>> > But there is other problem in the documentation: although not
>> > mentioned, "g:" also works even if it isn't explicitly prefixed in
>> > the script, as in the example below where script_b.vim sources
>> > script_a.vim. If we do :so % while editing script_b.vim,
>> > FunctionA is executed:
> [...]
>
> It is stated elsewhere that g: is implicit for variables used anywhere
> except inside a function, where l: is implicit.
Thanks for the explanations, Nikolay Pavlov and Tony Mechelynck!
Now it's clear to me.
Best regards!
--
Jakson Alves de Aquino
Federal University of Ceará
Social Sciences Department
www.lepem.ufc.br/aquino.php
--
--
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/groups/opt_out.
Re: Documentation of Funcref
Em 23-08-2013 01:01, Nikolay Pavlov escreveu:
>
> On Aug 23, 2013 1:24 AM, "Jakson Alves de Aquino" <mailto:jalve...@gmail.com>> wrote:
>>
>>
>> Hi,
>>
>> The documentation of Funcref includes the following statement:
>>
>> A Funcref variable must start with a capital, "s:", "w:",
>> "t:" or "b:".
>>
>> It seems that sentence is incomplete. I think the intention was to
>> write:
>>
>> A Funcref variable must start with a capital letter and both
>> the function being referred to and the Funcref variable must
>> have the same scope, being prefixed by "s:", "w:", "t:" or
>> "b:".
>
> I do not understand. Vim currently has nothing else but global
> functions. There are no scoped ones, s:Fname is simply a shortcut for
> N_Fname, where N is current script number. Anonymous functions are
> global ones with just N as their name, N is number of anonymous
> functions defined in this session (i.e. it is just an incremented counter).
>
> Thus I have not seen the "must have the same scope" behavior you describe.
I'm glad that my understanding of the sentence was wrong because I
want both the function and the Funcref to be global.
> Also note that using b:Fname (or g:Fname) as function name is
> undocumented. And it is as well NOT a name of buffer-local function.
>
>> But there is other problem in the documentation: although not
>> mentioned, "g:" also works even if it isn't explicitly prefixed in
>> the script, as in the example below where script_b.vim sources
>> script_a.vim. If we do :so % while editing script_b.vim,
>> FunctionA is executed:
>>
>> " script_a.vim:
>> function FunctionA()
>> echo "Hello World!"
>> endfunction
>>
>> " script_b.vim
>> source script_a.vim
>> let CallFunctionA = function("FunctionA")
>> call CallFunctionA()
>>
>> Note: I'm using global Funcref to global functions in the
>> Vim-R-plugin. So I hope that the problem is in the documentation
>> and not in the actual Vim behavior.
>
> I would say that putting funcrefs directly into global or function-local
> variable is the worst idea: your code will break if someone defines
> CallFunctionA function. Use dictionaries:
>
> let d={}
> let d.CallFunctionA = function("FunctionA")
Thanks for the suggestion, but actually I incentive people to
create extensions to the Vim-R-plugin which will source other
scripts if the vimrplugin_source variable is defined.
--
Jakson Alves de Aquino
Federal University of Ceará
Social Sciences Department
www.lepem.ufc.br/aquino.php
--
--
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/groups/opt_out.
Documentation of Funcref
Hi,
The documentation of Funcref includes the following statement:
A Funcref variable must start with a capital, "s:", "w:",
"t:" or "b:".
It seems that sentence is incomplete. I think the intention was to
write:
A Funcref variable must start with a capital letter and both
the function being referred to and the Funcref variable must
have the same scope, being prefixed by "s:", "w:", "t:" or
"b:".
But there is other problem in the documentation: although not
mentioned, "g:" also works even if it isn't explicitly prefixed in
the script, as in the example below where script_b.vim sources
script_a.vim. If we do :so % while editing script_b.vim,
FunctionA is executed:
" script_a.vim:
function FunctionA()
echo "Hello World!"
endfunction
" script_b.vim
source script_a.vim
let CallFunctionA = function("FunctionA")
call CallFunctionA()
Note: I'm using global Funcref to global functions in the
Vim-R-plugin. So I hope that the problem is in the documentation
and not in the actual Vim behavior.
Thanks!
--
Jakson Alves de Aquino
Federal University of Ceará
Social Sciences Department
www.lepem.ufc.br/aquino.php
--
--
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/groups/opt_out.
Re: diff syntax update (translations to many languages need to be checked)
On Sun, Jul 21, 2013 at 12:39 PM, Antonio Giovanni Colombo wrote: > Italian is practically OK, but I have the following remarks: > > syn match diffOnly "^Only in .*" > The format of the above [English] line is different (missing ": .*$") OK. I added the : .* By the way, I think I could remove the "$" from all strings ending as ".*$" > syn match diffDiffer "^I file .* e .* sono diversi$" > should be: > syn match diffBDiffer "^I file binari .* e .* sono diversi$" OK. > syn match diffIsA "^File .* è un .* mentre file .* è un .*$" > should be: > syn match diffIsA "^File .* è un/o/a .* mentre file .* è un/o/a .*$" The diffutils-3.3/po/it.po file has only one translation for this message: "File %s è un %s mentre file %s è un %s\n" -- Jakson Alves de Aquino Federal University of Ceará Social Sciences Department www.lepem.ufc.br/aquino.php -- -- 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/groups/opt_out.
Re: diff syntax update (translations to many languages need to be checked)
On Sun, Jul 21, 2013 at 11:47 AM, Yukihiro Nakadaira wrote: > On Sun, Jul 21, 2013 at 10:42 PM, Jakson Alves de Aquino > wrote: >> >> Hi, >> >> I updated the translations of diff messages in syntax/diff.vim to >> version 3.3 of diffutils. Some messages are translated twice to >> match both diffutils 3.3 and older versions. The messages are in >> many languages and they were collected from the po files by a >> script. It would be good if speakers of the many languages could >> check if the diff.vim syntax script works for them. The languages >> are: >> >> Catalan, Chinese, Croatian, Czech, Danish, Dutch, >> Esperanto, Finnish, French, Galician, German, >> Greek, Hebrew, Hungarian, Indonesian, Irish, >> Italian, Japanese, Latvian, Malay, Polish, >> Portuguese, Romanian, Russian, Serbian, Spanish, >> Swedish, Turkish, Uzbek and Vietnamese. > > > Japanese messages looks good to me. > > Perhaps diffNoEOL should have backslash? > - syn match diffNoEOL"^No newline at end of file .*" > - syn match diffNoEOL"^\\ No newline at end of file .*" Yes, you are right. The backslash doesn't appear in the po files, but it's added by src/diff3.c just before the message to be translated. The backslash should be added to all diffNoEOL strings. The attached file fix this. -- Jakson Alves de Aquino Federal University of Ceará Social Sciences Department www.lepem.ufc.br/aquino.php -- -- 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/groups/opt_out. diff.vim Description: Binary data
diff syntax update (translations to many languages need to be checked)
Hi, I updated the translations of diff messages in syntax/diff.vim to version 3.3 of diffutils. Some messages are translated twice to match both diffutils 3.3 and older versions. The messages are in many languages and they were collected from the po files by a script. It would be good if speakers of the many languages could check if the diff.vim syntax script works for them. The languages are: Catalan, Chinese, Croatian, Czech, Danish, Dutch, Esperanto, Finnish, French, Galician, German, Greek, Hebrew, Hungarian, Indonesian, Irish, Italian, Japanese, Latvian, Malay, Polish, Portuguese, Romanian, Russian, Serbian, Spanish, Swedish, Turkish, Uzbek and Vietnamese. Best regards, -- Jakson Alves de Aquino Federal University of Ceará Social Sciences Department www.lepem.ufc.br/aquino.php -- -- 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/groups/opt_out. diff.vim Description: Binary data
Re: svn syntax with localization?
On Fri, Jul 19, 2013 at 3:17 AM, Ingo Karkat wrote:
> On 19-Jul-2013 05:57 +0200, studog wrote:
>
>> On Thursday, July 18, 2013 4:15:22 PM UTC-4, Marcin Szamotulski wrote:
>>> Writting a pattern which has to match all the languages is not the best
>>> idea. But maybe refining the pattern would help:
>>>
>>> ^--[a-zA-Z ,^-]\{-}--$
>>
>> No, I mean:
>>
>> syn region svnRegion
>> start="^--This line, and those below, will be ignored--$"
>> start="^$"
>> start="^$"
>> ...
>> end="\%$" contains=ALL
>>
>> since syn region can take multiple start conditions.
>
> Yes, I would go with that (though it's some effort to maintain). I
> remember seeing some syntax file that did this (but can't find the
> reference right now).
I've write a script that get the translations of diffutils:
https://groups.google.com/forum/#!topic/vim_dev/7H_JVwx8H5U
--
Jakson Alves de Aquino
Federal University of Ceará
Social Sciences Department
www.lepem.ufc.br/aquino.php
--
--
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/groups/opt_out.
Re: Issue 103 in vim: Python thread are not running in background
On Wed, Jan 16, 2013 at 11:59 AM, wrote: > Comment #8 on issue 103 by zyx@gmail.com: Python thread are not running > in background > http://code.google.com/p/vim/issues/detail?id=103 > >> On which platform are you testing? I would guess Windows since >> pythoninterp=dynamic seems to only be available on this platform. > > > Nope. It is available anywhere, but pythoninterp=dynamic is the only choice > if you want to have both python and python3 support in one binary. It is > Gentoo on amd64. And Ubuntu ARM (efika MX smartbook modification of Ubuntu, > stripped of almost any package that was there in a fresh installation). > >> Reverting commit 7f10daa706bb solves the issue (the test-case is correclty >> incrementing the variable in background). It also prevents vim to compile >> when PY_CAN_RECURSE is not set. > > > Now when you mentioned it I remember I saw some (threading?) problems with > this commit on vim-dev. Did not came to my mind as I forgot about threads as > they are not working on ARM and are not forcefully terminatable. This is > also why I suggest processes to anyone wanting to use threads. > > Though reverting commit is not an option: it itself is solving some issues. > Better to check why I have the code running correctly and you do not. Perhaps this problem is related with the one that I've reported two moths ago: https://groups.google.com/forum/?fromgroups=#!topic/vim_dev/1B2habthlBs -- Jakson Alves de Aquino Federal University of Ceará Social Sciences Department www.lepem.ufc.br/aquino.php -- 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
Re: patch 691: Python, thread
On Sun, Dec 23, 2012 at 8:22 PM, Bram Moolenaar wrote: > > Jakson Alves de Aquino wrote a few weeks ago: > >> I'm adding more details on the problem... >> >> On Thu, Nov 8, 2012 at 6:21 PM, Jakson Alves de Aquino >> wrote: >> > I'm the maintainer of Vim-R-plugin which may start a separate Vim >> > instance to run an "Object Browser". This Vim instance has a UDP >> > server running in a new thread. The server is written in Python and it >> > receives messages from R to update the list of objects. This Vim >> > instance isn't used to edit code and thus there is no problem if Vim >> > code is executed from the server thread. >> > >> > Problem: The server stopped working after patch 691. The problem is >> > the line 748 of src/if_python.c. If I delete this line, the server >> > works as before. The server is created by the function VimServer() of >> > https://github.com/jcfaria/Vim-R-plugin/blob/master/r-plugin/vimcom.py >> >> The line 748 of src/if_python.c is: >> >> pygilstate = PyGILState_Ensure(); >> >> The function VimServer() is called by RunServer() which uses the >> threading module to create a new thread running VimServer(). The >> VimServer() becomes immediately unresponsive. For example, there one >> message that the VimServer() function sends to R when the server is >> successfully started, but this message is actually being sent only >> when the server is joined to the main thread or when the thread is >> killed. >> >> It seems that currently it's not possible to run a thread in parallel >> to the main Vim process. >> >> > I'm far from an expert in Python programming, and I don't know how to >> > solve the problem. Any help is appreciated. >> >> The solutions that I think that may be possible are: >> >> 1) Undo the effect of PyGILState_Ensure() in the vimcom.py code >>(I don't know if this is possible). >> >> 2) Create a Vim option to call/not call PyGILState_Ensure(). That >>is, transfer to plugin developers the option to use or not use >>unsafe threads. >> >> In the Vim-R-plugin, the server is only used when Vim is running >> inside a Tmux session and we have two independent Vim instances. I use >> the server in the editor instance of Vim only to change the value of a >> variable storing the number of the port of the Object Browser server. >> In the Object Browser instance of Vim, the server calls functions to >> rewrite the content of the buffer but that is almost always done when >> the user is editing code in the editor instance and, thus, it's almost >> always idle and almost never crashes. And when it does crash, no data >> is lost since the Object Browser is not used to edit code. > > Just found this email (again). > Was there a conclusion about this problem? I solved my problem by using the Vim's clientserver feature. It's much more stable than using a Python server running in a new thread. Thanks! -- Jakson Alves de Aquino Federal University of Ceará Social Sciences Department www.lepem.ufc.br/aquino.php -- 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
Re: patch 691: Python, thread
Hello! I'm replying to my own message again, but this time to inform people reading this thread how I have solved the problem: 1) I no longer create a socket server in Vim. I now use the Vim's +clientserver feature. 2) I adapted the C code of vim-remote to be used in the R package vimcom. The vim-remote library is available at http://www.vim.org/scripts/script.php?script_id=3482 The new files vimremote.c, vimremote.h, vimthings.c and vimthings.h were added to the src directory of vimcom: https://github.com/jalvesaq/VimCom/tree/master/src Thanks to Yukihiro Nakadaira for writing vim-remote! On Fri, Nov 9, 2012 at 6:25 PM, Jakson Alves de Aquino wrote: > I'm adding more details on the problem... > > On Thu, Nov 8, 2012 at 6:21 PM, Jakson Alves de Aquino > wrote: >> I'm the maintainer of Vim-R-plugin which may start a separate Vim >> instance to run an "Object Browser". This Vim instance has a UDP >> server running in a new thread. The server is written in Python and it >> receives messages from R to update the list of objects. This Vim >> instance isn't used to edit code and thus there is no problem if Vim >> code is executed from the server thread. >> >> Problem: The server stopped working after patch 691. The problem is >> the line 748 of src/if_python.c. If I delete this line, the server >> works as before. The server is created by the function VimServer() of >> https://github.com/jcfaria/Vim-R-plugin/blob/master/r-plugin/vimcom.py > > The line 748 of src/if_python.c is: > > pygilstate = PyGILState_Ensure(); > > The function VimServer() is called by RunServer() which uses the > threading module to create a new thread running VimServer(). The > VimServer() becomes immediately unresponsive. For example, there one > message that the VimServer() function sends to R when the server is > successfully started, but this message is actually being sent only > when the server is joined to the main thread or when the thread is > killed. > > It seems that currently it's not possible to run a thread in parallel > to the main Vim process. > >> I'm far from an expert in Python programming, and I don't know how to >> solve the problem. Any help is appreciated. > > The solutions that I think that may be possible are: > > 1) Undo the effect of PyGILState_Ensure() in the vimcom.py code >(I don't know if this is possible). > > 2) Create a Vim option to call/not call PyGILState_Ensure(). That >is, transfer to plugin developers the option to use or not use >unsafe threads. > > In the Vim-R-plugin, the server is only used when Vim is running > inside a Tmux session and we have two independent Vim instances. I use > the server in the editor instance of Vim only to change the value of a > variable storing the number of the port of the Object Browser server. > In the Object Browser instance of Vim, the server calls functions to > rewrite the content of the buffer but that is almost always done when > the user is editing code in the editor instance and, thus, it's almost > always idle and almost never crashes. And when it does crash, no data > is lost since the Object Browser is not used to edit code. > > Thanks -- Jakson Alves de Aquino Federal University of Ceará Social Sciences Department www.lepem.ufc.br/aquino.php -- 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
Re: patch 691: Python, thread
I'm adding more details on the problem... On Thu, Nov 8, 2012 at 6:21 PM, Jakson Alves de Aquino wrote: > I'm the maintainer of Vim-R-plugin which may start a separate Vim > instance to run an "Object Browser". This Vim instance has a UDP > server running in a new thread. The server is written in Python and it > receives messages from R to update the list of objects. This Vim > instance isn't used to edit code and thus there is no problem if Vim > code is executed from the server thread. > > Problem: The server stopped working after patch 691. The problem is > the line 748 of src/if_python.c. If I delete this line, the server > works as before. The server is created by the function VimServer() of > https://github.com/jcfaria/Vim-R-plugin/blob/master/r-plugin/vimcom.py The line 748 of src/if_python.c is: pygilstate = PyGILState_Ensure(); The function VimServer() is called by RunServer() which uses the threading module to create a new thread running VimServer(). The VimServer() becomes immediately unresponsive. For example, there one message that the VimServer() function sends to R when the server is successfully started, but this message is actually being sent only when the server is joined to the main thread or when the thread is killed. It seems that currently it's not possible to run a thread in parallel to the main Vim process. > I'm far from an expert in Python programming, and I don't know how to > solve the problem. Any help is appreciated. The solutions that I think that may be possible are: 1) Undo the effect of PyGILState_Ensure() in the vimcom.py code (I don't know if this is possible). 2) Create a Vim option to call/not call PyGILState_Ensure(). That is, transfer to plugin developers the option to use or not use unsafe threads. In the Vim-R-plugin, the server is only used when Vim is running inside a Tmux session and we have two independent Vim instances. I use the server in the editor instance of Vim only to change the value of a variable storing the number of the port of the Object Browser server. In the Object Browser instance of Vim, the server calls functions to rewrite the content of the buffer but that is almost always done when the user is editing code in the editor instance and, thus, it's almost always idle and almost never crashes. And when it does crash, no data is lost since the Object Browser is not used to edit code. Thanks -- Jakson Alves de Aquino Federal University of Ceará Social Sciences Department www.lepem.ufc.br/aquino.php -- 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 691: Python, thread
Hi, I'm the maintainer of Vim-R-plugin which may start a separate Vim instance to run an "Object Browser". This Vim instance has a UDP server running in a new thread. The server is written in Python and it receives messages from R to update the list of objects. This Vim instance isn't used to edit code and thus there is no problem if Vim code is executed from the server thread. Problem: The server stopped working after patch 691. The problem is the line 748 of src/if_python.c. If I delete this line, the server works as before. The server is created by the function VimServer() of https://github.com/jcfaria/Vim-R-plugin/blob/master/r-plugin/vimcom.py I'm far from an expert in Python programming, and I don't know how to solve the problem. Any help is appreciated. Thanks -- Jakson Alves de Aquino Federal University of Ceará Social Sciences Department www.lepem.ufc.br/aquino.php -- 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
Re: awk indentation
On Wed, Oct 26, 2011 at 5:19 PM, erik wrote:
> New version on the same location: http://dl.dropbox.com/u/26176183/awk.vim
The attached patch fix a minor bug in the script.
--
Jakson
--
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
--- awk.vim 2011-11-09 21:48:37.762922283 -0300
+++ .vim/indent/awk.vim 2011-11-09 21:48:07.142921795 -0300
@@ -179,9 +179,9 @@
function! s:Get_line_of_matching_brace()
let c = col('.')
let r = v:lnum
- cursor(0,1)
+ call cursor(0,1)
let the_r = searchpair('{','','}','nbW')
- cursor(r,c)
+ call cursor(r,c)
" if the_r == -1
"echomsg 'Searchpair didn't find open brace'
" endif
Re: awk indentation
On Mon, Oct 10, 2011 at 6:41 PM, erik wrote: > A new attempt. It is a near-rewrite > > It handles correctly now all cases from Zvezdan as well as some more > code of my own. > May I ask for volunteers for testing again. > > You can find the indenter here: http://dl.dropbox.com/u/26176183/awk.vim The command "call" is missing in lines 179 and 181. Best regards, -- Jakson -- 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
Re: awk indentation
On Sat, Sep 17, 2011 at 9:18 AM, Donald Allen wrote: > On Fri, Sep 16, 2011 at 9:06 AM, Jakson Alves de Aquino > wrote: >> I agree that the indent/r.vim script is very slow, but I don't know >> how to improve the speed. For each line to be indented, the script has >> to calculate what was the indent level of the last command, but the >> last command is not always the line above. So the algorithm goes >> slowly upwards until finding the beginning of the last command. I >> think it would be necessary to take a different approach. > > I haven't read your code, but perhaps remember the indent level of the > 'last command' as you make your forward pass over the indentation > region? Yes, I have already thought about this. Instead of going backwards looking for the beginning of the command the script could first go backwards looking for any character in column 1 or the beginning of the file and, then, goes forward, remembering the current indent level. While going forward, it would be possible to keep track of the indentation level. This could be faster, but I don't have the necessary spare time to implement this alternate algorithm. Best regards, Jakson -- 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
Re: awk indentation
On Thu, Sep 15, 2011 at 5:56 PM, Donald Allen wrote: > I tried this with the same build of vim as I used for the example in > my original post, current as of last night (on the East Coast of the > US). Setting the filetype to R does indeed produce the correct result, > but after a 3-second delay. Doing the same in emacs/viper is > essentially instantaneous. [...] > Thanks for your response. Despite the performance issue, which I'm > confident can be fixed, your R version is a definite improvement over > the awk version. I agree that the indent/r.vim script is very slow, but I don't know how to improve the speed. For each line to be indented, the script has to calculate what was the indent level of the last command, but the last command is not always the line above. So the algorithm goes slowly upwards until finding the beginning of the last command. I think it would be necessary to take a different approach. Best regards, Jakson -- 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
Re: awk indentation
On Thu, Sep 15, 2011 at 3:51 PM, Donald Allen wrote:
> If you have following in a vim buffer, file named, say, foo.awk
>
> /some test/ {
> if (foo != "bar") {
> if (baz != ""){
> array1[xyz] = N
> if (N > max_N) max_N = N
> }
> xyz = temp[1]
> # Create
> print "," > "something.sql"
> split(description,temp,parse_descriptions[file])
> print "\t-- "temp[1] > "something.sql"
> printf "\t%s %s", xyz, pg_type > "something.sql"
> # Load
> insert = insert",\n\t"xyz
> fields[M]=xyz
> M++
> N = 1
> }
> field_to_XX_field[xyz,N] = field
> N++
> }
>
> position the cursor on the '{' that ends the first line. Then do =%. You get
[...]
I guess that the R indent script may work better for awk code. The awk
script was my starting point to develop the R one. Could you please
set the file type as "r" before indenting the code and tell us whether
the indentation becomes correct? As you certainly know, to set the
file type you should do:
:set ft=r
Note: Bram added the indent/r.vim to Vim's runtime recently (today, I think).
Best regards,
Jakson Aquino
--
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
Re: Indent R code
On Fri, Sep 2, 2011 at 7:57 AM, Bram Moolenaar wrote: > Jakson Alves de Aquino wrote: > >> My Vim-R-plugin (#2628) includes a script to indent R code. I improved >> the script on February, 2011 and since then only one bug was reported >> (and fixed). So I believe that the script is mature enough to be >> considered for inclusion in Vim runtime directory. [...] > Thanks, I'll include it. > > If you make improvements, please send me the updated file. Thanks! I'll send updates to you. Best regards, Jakson Aquino -- 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
Indent R code
Hi Bram,
My Vim-R-plugin (#2628) includes a script to indent R code. I improved
the script on February, 2011 and since then only one bug was reported
(and fixed). So I believe that the script is mature enough to be
considered for inclusion in Vim runtime directory.
One remaining problem of the script is that it is slow. The
indentation algorithm sometimes slowly goes backwards looking for an
opening parenthesis or brace or for the beginning of a "for", "if" or
"while" statement. This is necessary because the indentation level of
a given line depends on the indentation level of the previous one, but
the previous line is not always the line above. It's the line where
the statement immediately above started.
The indent/r.vim script is attached. I also attached a patch to doc/indent.txt.
Best regards,
Jakson Aquino
--
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
r.vim
Description: Binary data
diff -r ba9f075a347d runtime/doc/indent.txt
--- a/runtime/doc/indent.txt Sun Aug 28 16:02:28 2011 +0200
+++ b/runtime/doc/indent.txt Wed Aug 31 00:25:26 2011 -0300
@@ -706,6 +706,43 @@
let g:pyindent_continue = '&sw * 2'
+R*ft-r-indent*
+
+Function arguments are aligned if they span for multiple lines. If you prefer
+do not have the arguments of functions aligned, put in your |vimrc|:
+>
+ let r_indent_align_args = 0
+<
+All lines beginning with a comment character, #, get the same indentation
+level of the normal R code. Users of Emacs/ESS may be used to have lines
+beginning with a single # indented in the 40th column, ## indented as R code,
+and ### not indented. If you prefer that lines beginning with comment
+characters are aligned as they are by Emacs/ESS, put in your |vimrc|:
+>
+ let r_indent_ess_comments = 1
+<
+If you prefer that lines beginning with a single # are aligned at a column
+different from the 40th one, you should set a new value to the variable
+r_indent_comment_column, as in the example below:
+>
+ let r_indent_comment_column = 30
+<
+Any code after a line that ends with "<-" is indented. Emacs/ESS does not
+indent the code if it is a top level function. If you prefer that the
+Vim-R-plugin behaves like Emacs/ESS in this regard, put in your |vimrc|:
+>
+ let r_indent_ess_compatible = 1
+<
+Below is an example of indentation with and without this option enabled:
+>
+ ### r_indent_ess_compatible = 1 ### r_indent_ess_compatible = 0
+ foo <-foo <-
+ function(x) function(x)
+ { {
+ paste(x) paste(x)
+ } }
+<
+
SHELL *ft-sh-indent*
The amount of indent applied under various circumstances in a shell file can
Re: Re: filetype.vim: could R be the default instead of Rexx?
On Sun, Jul 17, 2011 at 5:36 PM, Bram Moolenaar wrote: > Tom wrote: >> > I don't know how to read these graphs. Also, it's Debian only, suppose >> > the picture is very different for mac or MS-Windows users? >> > >> R is at position 33 in the tiobe index: >> http://www.tiobe.com/content/paperinfo/tpci/index.html >> >> rexx isn't listed at all. I doubt it has much of a following anymore. > > OK, I'm convinced. I'll make the default R. I'll add a note in the > docs for Rexx users how they can change the default. Thanks! -- Jakson -- 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
Re: filetype.vim: could R be the default instead of Rexx?
On Sat, Jul 16, 2011 at 4:38 PM, Tony Mechelynck wrote: [...] >> However, I wonder whether this default could be changed to R >> because, at least in Linux systems, it seems that there are far more R >> users than Rexx users: [...] > > Always comment your sources abundantly. It makes them more human-readable, > and in this case it helps Vim determine the filetype: if there is a line > whose first nonspace character is # Vim treats it as r, if there is a line > whose first two nonspace characters are /* Vim treats it as rexx. This is > done in one loop, testing all lines in turn for both possibilities until one > is found or the end-of-file is reached. Since Rebol is easiest to determine > (and is done first), this leaves only uncommented r and rexx sources for the > fallback. Your suggestion is good for existing scripts, but the problem would remain for new files which when created are identified as Rexx. I maintain a plugin which includes a ftdetect/r.vim script that makes R to be the default, but R users who don't know about the plugin may think that Vim doesn't have syntax highlight for R if they start to edit a newly created file saved with .R extension. Best regards, Jakson Aquino -- 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
filetype.vim: could R be the default instead of Rexx?
Hi, When the file extension is either .r or .R, Vim looks for some clues that may allow the identification of the script as R, Rebol or Rexx. If no clue is found, filetype.vim assumes that the file is a Rexx script. However, I wonder whether this default could be changed to R because, at least in Linux systems, it seems that there are far more R users than Rexx users: http://qa.debian.org/popcon.php?package=regina-rexx http://qa.debian.org/popcon.php?package=r-base Best regards, Jakson Aquino -- 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
Priority of rare words over good words
Hi,
I have made a suggestion a year ago about increasing highlighting
priority of rare words:
http://groups.google.com/group/vim_dev/browse_thread/thread/acf58ea11dd98120
I'm just remembering the suggestion...
I'm also attaching a list of Portuguese words that I marked as rare,
so people who write in Portuguese could more easily test the patch.
The file should be appended to ~/.vim/spell/pt.utf-8.add and, then,
the following Vim command should be run:
:mkspell! pt.utf-8.add
I have even put the following in my .vimrc:
if has("autocmd")
autocmd BufWritePost ~/.vim/spell/pt.utf-8.add mkspell! pt.utf-8.add
endif
Best regards,
Jakson Aquino
--
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
pt_rare_words.utf-8.add
Description: Binary data
Re: Patch 7.3.196
On Fri, Jun 10, 2011 at 11:53 PM, Bram Moolenaar wrote:
>
> Jakson Aquino wrote:
>
>> On Thu, May 19, 2011 at 12:26 PM, Bram Moolenaar wrote:
>> > Patch 7.3.196
>> > Problem: Can't intercept a character that is going to be inserted.
>> > Solution: Add the InsertCharPre autocommand event. (Jakson A. Aquino)
>> > Files: runtime/doc/autocmd.txt, runtime/doc/eval.txt,
>> > runtime/doc/map.txt, src/edit.c, src/eval.c, src/fileio.c,
>> > src/vim.h
>>
>> [...]
>>
>> When using the Conque Shell plugin with the patch 7.3.196 applied to
>> Vim I have to type very slowly in the Conque Term buffer because I get
>> the following error when I type in normal speed:
>>
>> Error detected while processing function conque_term#key_press:
>> line 1:
>> E523: Not allowed here
>> Press ENTER or type command to continue
>>
>> This error only happens if the text is locked (edit.c, lines 1394 and
>> 1415). I can type normally if I comment out these two lines.
>
> So what is line 1 in conque_term#key_press ?
sil exe s:py . ' ' . b:ConqueTerm_Var . ".write_ord(" . char2nr(v:char) . ")"
And 'write_ord' is:
def write_ord(self, input, set_cursor=True, read=True):
""" Write a single character to the subprocess, using an
unicode ordinal. """
if CONQUE_PYTHON_VERSION == 2:
self.write(unichr(input), set_cursor, read)
else:
self.write(chr(input), set_cursor, read)
And 'write' is:
def write(self, input, set_cursor=True, read=True):
""" Write a unicode string to the subprocess.
set_cursor -- Position the cursor in the current buffer when finished
read -- Check program for new output when finished
"""
# check if window size has changed
if read:
self.update_window_size()
# write and read
self.proc.write(input)
# read output immediately
if read:
self.read(1, set_cursor)
>> I only use the InsertCharPre event through the Conque Shell plugin. It
>> would be nice if other people could comment on the need of locking the
>> text since it doesn't seem to be necessary while using the Conque
>> Shell. I've written to Nico Raffo, the author of the plugin, to know
>> whether this problem could be fixed in the Conque Shell, but I didn't
>> get any answer yet.
>
> How come this function gets invoked from the InsertCharPre event?
autocmd InsertCharPre call conque_term#key_press()
which is in ~/.vim/autoload/conque_term.vim
> The text is lockec because it may cause big problems. E.g. undo could
> be messed up. This doesn't depend on actualy use of the event but on
> what could possibly done with the event.
Thanks for the explanation!
Best regards,
Jakson Aquino
--
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
Re: Patch 7.3.196
On Thu, May 19, 2011 at 12:26 PM, Bram Moolenaar wrote: > Patch 7.3.196 > Problem: Can't intercept a character that is going to be inserted. > Solution: Add the InsertCharPre autocommand event. (Jakson A. Aquino) > Files: runtime/doc/autocmd.txt, runtime/doc/eval.txt, > runtime/doc/map.txt, src/edit.c, src/eval.c, src/fileio.c, > src/vim.h [...] When using the Conque Shell plugin with the patch 7.3.196 applied to Vim I have to type very slowly in the Conque Term buffer because I get the following error when I type in normal speed: Error detected while processing function conque_term#key_press: line1: E523: Not allowed here Press ENTER or type command to continue This error only happens if the text is locked (edit.c, lines 1394 and 1415). I can type normally if I comment out these two lines. I only use the InsertCharPre event through the Conque Shell plugin. It would be nice if other people could comment on the need of locking the text since it doesn't seem to be necessary while using the Conque Shell. I've written to Nico Raffo, the author of the plugin, to know whether this problem could be fixed in the Conque Shell, but I didn't get any answer yet. Best regards, Jakson Aquino -- 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
Re: Feature Request: highlight group for explicit bad words
On Fri, Feb 25, 2011 at 1:41 PM, Till Maas wrote: > I use a shared additional vim spell file that contains word marked as bad > like 'foo/!'. For words that can be written in different correct ways, which > at least exists in German, sometimes one of both variants is marked as bad > to help writing uniform texts. To distinguish these explicit bad words from > words that are not known by the wordlist and therefore marked as bad, it > woulc be nice to have a different highlight group in vim for these kind of > words like SpellExplicitBad or something better named. Vim can highlight "rare" words in a different color. The problem is that, currently, rare word are considered good if they are also listed as good words. I have written a small patch to increase the priority of rare words and posted it in this list before. I think the patch does what you want: http://groups.google.com/group/vim_dev/browse_thread/thread/acf58ea11dd98120 -- Jakson Aquino Federal University of Ceara Brazil -- 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
Re: InsertCharPre patch
On 29-01-2011 17:33, Jakson A. Aquino wrote: > On February, 5, 2010, Nico Raffo requested the implementation of the > auto command event InsertCharPre, which would be useful to his Conque > Shell plugin [1]. As the developer of the Vim-R-plugin [2], which > optionally uses the Conque Shell plugin, I was also interested in the > patch. We developed the patch, tested it for some weeks, and now I am > submitting the patch to the Vim developers to evaluate. > > [1] > http://groups.google.com/group/vim_dev/browse_thread/thread/67020478db647370 > [2] http://www.vim.org/scripts/script.php?script_id=2628 Did anyone have time to check the patch? The Conque Shell plugin allows Vim users tor run a shell in a Vim buffer. We can then easily copy and paste the content of the application running in the shell, syntax highlight the output, and even use Vim to process the output and take useful actions based on the output. This is very useful for interpreted languages. Are there plans to add this feature to Vim, making Conque Shell unnecessary? In Vim's documentations, at develop.txt, it's stated that Vim wasn't designed to run other applications interactively: "Vim is not a shell or an Operating System. You will not be able to run a shell inside Vim or use it to control a debugger." So, are there objections to support Conque Shell? Thanks! -- Jakson Aquino Dept. of Social Sciences Federal University of Ceará Brazil signature.asc Description: OpenPGP digital signature
