On Windows - other tabs close when netrw explore navigates to a directory
Hi, I have noticed this bug[1] occurring on Windows 7 since version 8.0. It looks to me that this does not happen on linux console or gui versions. I just observed it occurring with vim and gvim on Windows 10. Please let me know if anyone can reproduce this. Thanks, Brian [1] : To reproduce (On Windows): start Vim edit a file (README.txt) type :tabe -- now we have two tabs open and are on the second tab open netrw explorer with :E navigate to a folder -- at this point, 1. the tab for README.txt no longer appears. 2. The buffer for README.txt does not appear in the list of buffers 3. If I navigate to the README.txt in netrw explorer and open it, that file does not show - netrw explorer shows. 4. Opening with `:e README.txt` opens the file. Good. This part works. But... 5. netrw explorer will open the netrw explorer looking at the folder navigated to any time README.txt is selected in any window with netrw explorer in it. -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/1bce4a8b-2014-4df2-9ea2-b3039f7ec8d6%40googlegroups.com.
Re: Patch 8.0.1194
Hey Bram, > Patch 8.0.1194 > Problem:Actual fg and bg colors of terminal are unknown. > Solution: Add t_RF. Store response to t_RB and t_RF, use for terminal. > Files: src/term.c, src/term.h, src/proto/term.pro, src/terminal.c, > src/vim.h, src/eval.c, runtime/doc/eval.txt I think this is having issues when running vim inside of tmux. I am receiving a segfault when running vim through a tmux session. vim -u NONE works okay, but the segfault occurs without any local plugins. (gdb) bt #0 0x0059865f in may_req_bg_color () #1 0x005d8559 in vim_main2 () #2 0x0042b429 in main () compiled vim at 65e4c4f68 compiled tmux at fb02df66c The problem does not appear when compiling v8.0.1193 and local plugins are able to load fine in tmux sessions. -- -- 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: Set line breaks, word wraps and word searching for Thai and other non-latin languages
>Bram Moolenaar wrote: > Can we see the start and/or end of a word by recognizing characters? > Or do we need to recognize words? > > The spell checker does have some knowledge about where words start and > end. It's a bit slow doing it that way, but might still be acceptable. > > I suppose we could have a character class that indicates no spaces are > used to separated words. That will assume the character is only used in > that kind of language. > Thank you Bram. I believe there are C algorithms (someplace) that define what is a Thai syllable. (I am not sure if this is the same as the ICU algorithms or not.) This would allow wrapping and navigation etc. at syllable level. I wouldn't recommend it for line breaking, but it would be less CPU intensive than a dictionary solution. However, for use of '*' and other nifty word level commands, tapping into ICU dictionary algorithms seems necessary. In my naivety, I ask, could we enable a setting that turns on/off ICU dictionary algorithms for Southeast and Southern Asian languages "in one fell swoop"? Or does this need to be hammered out one language at a time? And?? If ICU dictionary algorithms are supported, would this mean thai spelling would be naturally supported, or would this be a separate step? -- -- 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: Set line breaks, word wraps and word searching for Thai and other non-latin languages
On Saturday, November 14, 2015 at 9:02:24 PM UTC-8, ZyX wrote:
> `gq` behaviour is by a and option values and you may
> use them if you know a program which serves your purposes. `w` and other
> motions can be remapped, same for `J` (in the last case you may manually
> choose between `J` (join with spaces) and `gJ` (join without inserting
> spaces, but also without removing them)). So you can have some minor level of
> convenience by configuring Vim without patching it. But this does not work for
>
>
> 1. Motions inside “nore” mappings.
> 2. expand('') and other means of getting word under the cursor (e.g.
> :edit ).
> 3. Behaviour when option is set.
> 4. `\<`/`\>`. Though I am unsure that this should be fixed: I always parsed
> this as “place between non-word and word character” and “place between word
> and non-word character”, and not “place where word starts” and “place where
> word ends”. Documentation says about the second interpretation, but I have a
> strong impression (based on wording, actual implementation and the fact that
> this is my interpretation) that author meant the first variant.
>
>
Thank you ZyX,
Learning the difference between J and gJ is very helpful
Regarding remapping of w, I do not know how to remap it such that it would move
to the next Thai word.
4. Perhaps an example will clarify the technical description of what I mean
since I am not sure of the difference between the two examples that you give.
:) If I type '*' while sitting on a Thai word, I would expect it to go the next
matching word and not try to match the entire unspaced-phrase. 'diw' should not
delete the entire phrase, but only the Thai word that I am sitting on. etc.
Brian
> --
>
> 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+u...@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.
Set line breaks, word wraps and word searching for Thai and other non-latin languages
I posted the following question on the vi/vim stack exchange <http://vi.stackexchange.com/questions/5452/set-line-breaks-word-wraps-and-word-searching-for-thai-and-other-non-latin-lang> and was told that the vim-dev mailing list would be a more appropriate place to ask. Brian It is edited here as best I can with the assumption that the entered text is utf-8. My purpose is for a Thai solution, but instead of a hack, a more general solution should be available that will help the more than 1 Billion people of the various Indic languages. I can set the text width and can manually line break imported paragraphs with the following as an example. set textwidth=72 gqq I can also navigate English text files with the standard 'w' 'b' 'e' '*' commands, etc. This works well for English, however Thai and other Brahmic scripts of South and South-east Asia space at the phrasal level. Libreoffice, Word, Indesign, TeX, etc. "know" where line breaks should occur. They also "know" where individual words are, even though there are no spaces. I can navigate by Thai word in these programs. And I can even type English, Thai and Lao in the chrome address bar and then use alternate arrow on my mac to navigate at the word level in all three of these languages. It seems that these programs are tapping into work that has already been done at some lower level. If vim could tap into the same work, then someone could edit a multi-language document without having to do anything fancy. 'w' 'dw' (etc.) would just work happily from one word to the next regardless of the language. Line breaking poses a different challenge as these languages space at the phrasal level so that the trailing space or absence of a trailing space at the end of the line has meaning when breaking and joining lines. For purpose of example, the spaces are similar to an oxford comma and other punctuation and is the difference of whether or not we had Grandma for breakfast. (Let's eat Grandma. vs. Let's eat, Grandma.) One, also, doesn't, want, random, spaces, coming, when, they, are, not, needed. *My question is two fold:* 1. How can vim tap into already available libraries in order to recognize words from Indic languages (including and especially Thai) for the purpose of navigation and other vim word level commands. 2. Is it possible to add language awareness for the purpose of line breaking so that vim does not strip/add spaces when breaking/joining lines at words in Thai or other Indic languages. -- -- 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] clean up C/C++ string and character literal highlighting
A few bugs with C and C++ syntax highlighting: 1. In C mode, if c_no_c11 is set, then the highlighting of u8foo depends on c_no_cformat. If c_no_cformat is on, it gets highlighted even though u8foo is not a valid string literal pre-C11. 2. In C++ mode, if c_no_c11 is set, then (u8foo) doesn't get highlighted. 3. In C++ mode, if c_no_c11 is not set, then the highlighting of u8foo depends on c_no_cformat. If c_no_cformat is off, it doesn't get highlighted regardless of whether cpp_no_cpp11 is set. It's not hard to see where these bugs come from: the conditions for various syn region cString and syn region cCppString commands in c.vim seem very confused. I think, for instance, that someone who changed this file in the past mistakenly thought cCppString means C++ string. But even still I'm at a loss to explain why the C++11 string literal definitions are conditioned upon c_no_cformat. I'd like to submit a patch to tidy up this code so I can cleanly add support for highlighting C++11 user-defined literals (to come in a future patch). https://gist.github.com/t3nsor/14aa2ceb43896476eefd -- -- 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.
How are we going to deal with C++14 features in syntax highlighting?
cpp.vim has a lot of if statements like this: if !exists(cpp_no_cpp11) ... endif for C++11-only features. C++14 adds binary literals and digit separators and I'm interested in adding these to cpp.vim. In analogy, should I just wrap them in if !exists(cpp_no_cpp14) ... endif blocks? -- -- 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.
:silent ! requires redraw!
After :silent !, vim looks blank. I have to ^L or :redraw! to make it look normal. Sorry if this isn't the right list; I'm sending this here because :help bug said to. Let me know if this isn't enough bugreport.txt. VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Dec 8 2012 16:47:21) Included patches: 1-754 Compiled by ArchLinux Big version with GTK2 GUI. Features included (+) or not (-): +arabic +autocmd +balloon_eval +browse ++builtin_terms +byte_offset +cindent +clientserver +clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments +conceal +cryptv +cscope +cursorbind +cursorshape +dialog_con_gui +diff +digraphs +dnd -ebcdic +emacs_tags +eval +ex_extra +extra_search +farsi +file_in_path +find_in_path +float +folding -footer +fork() +gettext -hangul_input +iconv +insert_expand +jumplist +keymap +langmap +libcall +linebreak +lispindent +listcmds +localmap +lua +menu +mksession +modify_fname +mouse +mouseshape +mouse_dec +mouse_gpm -mouse_jsbterm +mouse_netterm +mouse_sgr -mouse_sysmouse +mouse_urxvt +mouse_xterm +multi_byte +multi_lang -mzscheme +netbeans_intg +path_extra +perl +persistent_undo +postscript +printer -profile +python -python3 +quickfix +reltime +rightleft +ruby +scrollbind +signs +smartindent -sniff +startuptime +statusline -sun_workshop +syntax +tag_binary +tag_old_static -tag_any_white -tcl +terminfo +termresponse +textobjects +title +toolbar +user_commands +vertsplit +virtualedit +visual +visualextra +viminfo +vreplace +wildignore +wildmenu +windows +writebackup +X11 -xfontset +xim +xsmp_interact +xterm_clipboard -xterm_save system vimrc file: /etc/vimrc user vimrc file: $HOME/.vimrc user exrc file: $HOME/.exrc system gvimrc file: /etc/gvimrc user gvimrc file: $HOME/.gvimrc system menu file: $VIMRUNTIME/menu.vim fall-back for $VIM: /usr/share/vim Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -pthread -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng15 -I/usr/include/harfbuzz -I/usr/local/include -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 Linking: gcc -L. -Wl,-O1,--sort-common,--as-needed,-z,relro -rdynamic -Wl,-export-dynamic -Wl,-E -Wl,-rpath,/usr/lib/perl5/core_perl/CORE -Wl,-O1,--sort-common,--as-needed,-z,relro -L/usr/local/lib -Wl,--as-needed -o vim -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lglib-2.0 -lSM -lICE -lXt -lX11 -lXdmcp -lSM -lICE -lm -lncurses -lnsl -lacl -lattr -lgpm -ldl -L/usr/lib -llua -Wl,-E -Wl,-rpath,/usr/lib/perl5/core_perl/CORE -Wl,-O1,--sort-common,--as-needed,-z,relro -fstack-protector -L/usr/local/lib -L/usr/lib/perl5/core_perl/CORE -lperl -lnsl -ldl -lm -lcrypt -lutil -lpthread -lc -L/usr/lib/python2.7/config -lpython2.7 -lpthread -ldl -lutil -lm -Xlinker -export-dynamic -lruby -lpthread -lrt -ldl -lcrypt -lm -L/usr/lib -- -- 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: if_xcmdsrv.c patches
On Tuesday, July 17, 2012 9:30:42 AM UTC-4, James McCoy wrote:
On Jul 17, 2012 6:47 AM, Brian D. Burns bu...@iosctr.com wrote:
I've attached a new patch, with an updated test and Makefile which
includes tests using --remote-send and --remote-expr.
Also, I've spent some time with gdb looking into this missing event
issue and I've determined what the root cause is.
This looks very similar to an issue xscreensaver used to have. Maybe the
solution[0] I found for that can provide some inspiration.
[0]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=486603#45
Cheers,
James
Thanks James, it does appear similar.
Given that the current code expects FD_ISSET to be true if events are
waiting, the following should be equivalent to the commented portion:
if (ret = 0 xterm_Shell != (Widget)0)
{
if (XtAppPending(app_context))
{
xterm_update();
if (((ret == 1 FD_ISSET(ConnectionNumber(xterm_dpy), rfds))
|| ret == 0) !input_available())
{
finished = FALSE;
}
}
}
/*
if (ret 0 xterm_Shell != (Widget)0
FD_ISSET(ConnectionNumber(xterm_dpy), rfds))
{
xterm_update();
if (--ret == 0 !input_available())
{
finished = FALSE;
}
}
*/
However, when I use this, and remove the other fixes:
- XCheckWindowEvent in ServerWait (when localLoop is FALSE)
- XCheckWindowEvent in serverPeekReply
(i.e. letting the call to xterm_update/XtAppPending trigger serverEventProc)
the test passes, but you have to tap ESC or something to get them to continue
running.
The same is true for several of the other tests.
These are two new backtraces for calls to RealWaitForChar I see when applying
these changes:
#0 RealWaitForChar (fd=0, msec=4000, check_for_gpm=0x0) at os_unix.c:4917
#1 0x0813f33b in WaitForChar (msec=4000) at os_unix.c:4870
#2 0x0813b5a7 in mch_inchar (buf=0x8245be7 , maxlen=85, wtime=-1,
tb_change_cnt=8) at os_unix.c:406
#3 0x081a57ce in ui_inchar (buf=0x8245be7 , maxlen=85, wtime=-1,
tb_change_cnt=8) at ui.c:193
#4 0x080d4914 in inchar (buf=0x8245be7 , maxlen=257, wait_time=-1,
tb_change_cnt=8) at getchar.c:3025
#5 0x080d45af in vgetorpeek (advance=1) at getchar.c:2800
#6 0x080d2bba in vgetc () at getchar.c:1582
#7 0x080d30d4 in safe_vgetc () at getchar.c:1787
#8 0x08115739 in normal_cmd (oap=0xbfffe968, toplevel=1) at normal.c:665
#9 0x081d5b3a in main_loop (cmdwin=0, noexmode=0) at main.c:1294
#10 0x081d5637 in main (argc=5, argv=0xbfffeb84) at main.c:998
#0 RealWaitForChar (fd=0, msec=-1, check_for_gpm=0x0) at os_unix.c:5244
#1 0x0813f33b in WaitForChar (msec=-1) at os_unix.c:4870
#2 0x0813b614 in mch_inchar (buf=0x8245be6 , maxlen=86, wtime=-1,
tb_change_cnt=7) at os_unix.c:436
#3 0x081a57ce in ui_inchar (buf=0x8245be6 , maxlen=86, wtime=-1,
tb_change_cnt=7) at ui.c:193
#4 0x080d4914 in inchar (buf=0x8245be6 , maxlen=258, wait_time=-1,
tb_change_cnt=7) at getchar.c:3025
#5 0x080d45af in vgetorpeek (advance=1) at getchar.c:2800
#6 0x080d2bba in vgetc () at getchar.c:1582
#7 0x080d30d4 in safe_vgetc () at getchar.c:1787
#8 0x08115739 in normal_cmd (oap=0xbfffe968, toplevel=1) at normal.c:665
#9 0x081d5b3a in main_loop (cmdwin=0, noexmode=0) at main.c:1294
#10 0x081d5637 in main (argc=5, argv=0xbfffeb84) at main.c:998
I'm guessing the extra events being dispatched must be causing this.
Stepping through the test doesn't work too well, but when I use the
commented (i.e. current) code above, along with the fixes in
ServerWait and serverPeekReply, I never see RealWaitForChar called with
anything other than msec=0.
The calls look more like this:
#0 RealWaitForChar (fd=0, msec=0, check_for_gpm=0x0) at os_unix.c:5254
#1 0x0813f2af in mch_breakcheck () at os_unix.c:4811
#2 0x081a593d in ui_breakcheck () at ui.c:367
#3 0x080d330d in vgetorpeek (advance=1) at getchar.c:2014
#4 0x080d2bba in vgetc () at getchar.c:1582
#5 0x080d30d4 in safe_vgetc () at getchar.c:1787
#6 0x080b5162 in getcmdline (firstc=58, count=1, indent=0) at ex_getln.c:360
#7 0x080b7fb2 in getexline (c=58, cookie=0x0, indent=0) at ex_getln.c:2155
#8 0x080a239d in do_cmdline (cmdline=0x0, fgetline=0x80b7f7a getexline,
cookie=0x0, flags=0) at ex_docmd.c:1018
#9 0x0811ccb2 in nv_colon (cap=0xbfffe8c0) at normal.c:5404
#10 0x0811620b in normal_cmd (oap=0xbfffe968, toplevel=1) at normal.c:1193
#11 0x081d5b22 in main_loop (cmdwin=0, noexmode=0) at main.c:1294
#12 0x081d561f in main (argc=9, argv=0xbfffeb84) at main.c:998
--
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: if_xcmdsrv.c patches
On 07/14/2012 06:21 AM, Bram Moolenaar wrote:
Brian Burns wrote:
I've attached a patch which includes an updated test and Makefile, with
the server being started and stopped in the Makefile. Also included is a
change to serverPeekReply() and an added note for ServerWait().
[...]
Thanks! I'll look into it later.
I've attached a new patch, with an updated test and Makefile which
includes tests using --remote-send and --remote-expr.
Also, I've spent some time with gdb looking into this missing event
issue and I've determined what the root cause is.
When ServerWait is called with localLoop FALSE, ui_delay is used and
ultimately calls RealWaitForChar. This function is using select/poll to
determine if there is an event waiting in order to call xterm_update.
However, this is not an accurate test, since the X server reads that fd.
In this case, it's doing so before RealWaitForChar has a chance to poll
the fd. So, even if select/poll returns 0 or FD_ISSET() returns false,
events may already be in the X queue, and a call to XtAppPending would
find it. In light of this, I was thinking that RealWaitForChar needs to
calls xterm_update regardless. Something like:
if (ret = 0 xterm_Shell != (Widget)0)
{
xterm_update(); /* Maybe we should hand out clipboard */
/* continue looping when we only got the X event and the input
* buffer is empty */
if (((ret == 1 FD_ISSET(ConnectionNumber(xterm_dpy), rfds))
|| ret == 0) !input_available())
{
/* Try again */
finished = FALSE;
}
}
While this appears to work in the debugger (so far), running the test
actually hangs, as something is waiting indefinitely for input.
Sometimes hitting return will allow the test to finish, sometimes you
have break out and forcibly kill the server. I've tried a few variations
on this, but at this point, I haven't tracked this down.
The fact that checking the fd isn't a true test of waiting events would
be the same in ServerWait when localLoop is TRUE. However, in this case
that loop is entered quickly; before the server has a chance to respond.
So you have a much better chance at detecting it's response. And, since
this loop checks the queue each time select/poll times out anyway, it's
not an issue.
For serverPeekReply, unless RealWaitForChar can call xterm_update or
check the X queue somehow, this function still needs to do this itself.
In fact, it may be best that it does this regardless.
In the end, it may be best to leave things as they are - with the
addition of the queue check in serverPeekReply. This, along with
checking the queue in ServerWait even when localLoop is FALSE, seems to
handle this issue. But I wanted to point this out, as I'm not sure what
other events (clipboard?) RealWaitForChar may miss due to this.
Also, I had mentioned that using gvim (GTK) with the following would
occasionally hang, yet I just ran this a few times with no failures:
for i in {1..100}; do
./gvim -u NONE +'echomsg remote_expr(vim_server_test, 2+2) | q';
done
Given that it's compiling as 'vim', I may have forgotten to copy this to
'gvim' or run it against my system gvim (7.3.515-2.fc16.i686) or
something. I stepped through this with gdb as well and didn't see any
problems. Gotta love intermittent errors :)
One more thing... I was able to run the tests in this patch (and all the
tests) against 'gvim' by copying src/vim to src/gvim, then changing
VIMPROG to ../gvim and adding '-f' to the command lines in the Makefile.
Is this how you would do this, or am I missing something?
--
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
diff -r 942df3a8051b src/if_xcmdsrv.c
--- a/src/if_xcmdsrv.c Mon Jul 16 19:27:29 2012 +0200
+++ b/src/if_xcmdsrv.c Tue Jul 17 06:37:02 2012 -0400
@@ -594,6 +594,10 @@
time(start);
while (TRUE)
{
+/* This is being used when localLoop is FALSE in order to catch
+ * XEvents which may be missed by the main ui loop.
+ * e.g. vim -u NONE +'echomsg remote_expr(server_name, 2+2)'
+ */
while (XCheckWindowEvent(dpy, commWindow, PropertyChangeMask, event))
serverEventProc(dpy, event);
@@ -850,6 +854,20 @@
{
struct ServerReply *p;
+/* Check the XEvent queue for any new server replies.
+ * Also used to catch XEvents which may be missed by the main ui loop.
+ * Without this, the following would produce some 0 responses:
+ *
+ * for i in {1..10};
+ * do vim -u NONE +call remote_send('server_name', \
+ * \:call server2client(expand('client'), '')CR\, 'serverid') \
+ * | sleep 1 | echomsg remote_peek(serverid) | sleep 200m | q;
+ * done
+ */
+XEvent event;
+while (XCheckWindowEvent(dpy, commWindow, PropertyChangeMask, event))
+serverEventProc(dpy, event);
+
if ((p
Re: if_xcmdsrv.c patches
On 07/07/2012 09:57 AM, Bram Moolenaar wrote:
Brian Burns wrote:
Recently, I have been looking into different methods for using Vim
to syntax highlight small blocks of code. In the process, I found
runtime/tools/xcmdsrv_client.c, which worked but seemed a little
outdated. So, after working with this a bit, I decided to create a
Ruby extension from src/if_xcmdsrv.c.
https://github.com/burns/vim_client-ruby
This is the most I've ever done in C, so it was quite the learning
experience. So, comments/suggestions are certainly welcome :)
While working with this, I found a few things I wanted to submit
for changes in if_xcmdsrv.c. I've attached 3 patches, which include
my comments.
if_xcmdsrv.patch.1 was a duplicate call to ga_init2.
if_xcmdsrv.patch.2 deals with the fact that the server is actually
sending a response to clients making input key requests (--remote-send),
even though they don't expect one, and some other thoughts.
if_xcmdsrv.patch.3 suggests some changes to the ServerWait() function,
which speeds up response time, handles an issue where the XEvent queue
is not being checked when 'localLoop' is true, and a few other thoughts.
I appreciate your time - and Vim! :)
It looks like you know what you are doing. I appreciate taking the time
to improve this code, it hasn't been worked on for a while. I'll look
into the details later.
While you are digging into this, could you find some way to test this
code? This might be complicated, since it requires starting two Vim
instances talking to each other, but it would be very useful to have at
least basic testing for this code.
Hey,
I've attached some basic tests.
I'm not sure if what I'm doing here would work on all systems,
but it's a start. Let me know what you think.
- Brian
--
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
ok
Tests for the +clientserver feature.
STARTTEST
:
: Set register 'a' to our expected result of 'ok'.
: Any error messages will be appended.
:
:call setreg('a', 'ok', 'l')
:
: Start the server and verify it's available.
:
:silent !../vim -nes -u NONE --servername vim_test_server - 21 /dev/null
:sleep 200m
:if index(split(serverlist(), \n), 'VIM_TEST_SERVER') 0
: if empty(system(../vim --serverlist | grep -i vim_test_server))
:call setreg('a', 'Server failed to start.', 'al')
: else
:call setreg('a', 'serverlist() failed.', 'al')
: endif
:endif
:
: Make sure remote_expr() works.
:
:let r = remote_expr('vim_test_server', '2+2')
:if r != 4
: call setreg('a', 'remote_expr() failed.', 'al')
: call setreg('a', 'Expected: ''4'' Got: '. r, 'al')
:endif
:
: Set a line in server's buffer.
: Give this a chance to process, since remote_send() returns immediately.
: Ask the server for the line to verify it was set.
:
:call remote_send('vim_test_server', 'call setline(1,test)cr')
:sleep 200m
:let r = remote_expr('vim_test_server', 'getline(1)')
:if r != 'test'
: call setreg('a', 'remote_send() failed to set server''s buffer.', 'al')
: call setreg('a', 'Expected: ''test'' Got: '. r, 'al')
:endif
:
: Lists should be returned as a newline joined string.
:
:call remote_expr('vim_test_server', 'setline(1,[one,two])')
:let r = remote_expr('vim_test_server', 'getline(1,$)')
:if r != one\ntwo\n
: call setreg('a', 'remote_expr() failed to return a newline joined string.',
'al')
: call setreg('a', 'Expected: ''one\ntwo\n'' Got: '. r, 'al')
:endif
:
: Ask the server to send us a message.
: Verify the message is waiting.
: Read the message.
:
:let sid = ''
:call remote_send('vim_test_server', 'call server2client(expand(client),
message)cr', 'sid')
:sleep 200m
:if empty(sid)
: call setreg('a', 'remote_send() failed to set the server id.', 'al')
:else
: let r = ''
: let a = remote_peek(sid, 'r')
: if a 1
:call setreg('a', 'remote_peek() failed to report a message is waiting.',
'al')
: endif
: if r != 'message'
:call setreg('a', 'remote_peek() failed to return the waiting message.',
'al')
:call setreg('a', 'Expected: ''message'' Got: '. r, 'al')
: endif
: let r = remote_read(sid)
: if r != 'message'
:call setreg('a', 'remote_read() failed to return the waiting message.',
'al')
:call setreg('a', 'Expected: ''message'' Got: '. r, 'al')
: endif
:endif
:
: Stop the server
:
:let pid = system(ps -eo pid,cmd | grep vim_test_server | grep -v grep | awk
'{print $1}')
:if !empty(pid) | exe(silent !kill .pid) | endif
:
: Store results and exit
:
Gap
:?RESULTS?1,$w! test.out
:qa!
ENDTEST
RESULTS
Re: if_xcmdsrv.c patches
On 07/08/2012 07:49 PM, Brian D. Burns wrote:
On 07/07/2012 09:57 AM, Bram Moolenaar wrote:
Brian Burns wrote:
Recently, I have been looking into different methods for using Vim
to syntax highlight small blocks of code. In the process, I found
runtime/tools/xcmdsrv_client.c, which worked but seemed a little
outdated. So, after working with this a bit, I decided to create a
Ruby extension from src/if_xcmdsrv.c.
https://github.com/burns/vim_client-ruby
This is the most I've ever done in C, so it was quite the learning
experience. So, comments/suggestions are certainly welcome :)
While working with this, I found a few things I wanted to submit
for changes in if_xcmdsrv.c. I've attached 3 patches, which include
my comments.
if_xcmdsrv.patch.1 was a duplicate call to ga_init2.
if_xcmdsrv.patch.2 deals with the fact that the server is actually
sending a response to clients making input key requests (--remote-send),
even though they don't expect one, and some other thoughts.
if_xcmdsrv.patch.3 suggests some changes to the ServerWait() function,
which speeds up response time, handles an issue where the XEvent queue
is not being checked when 'localLoop' is true, and a few other thoughts.
I appreciate your time - and Vim! :)
It looks like you know what you are doing. I appreciate taking the time
to improve this code, it hasn't been worked on for a while. I'll look
into the details later.
While you are digging into this, could you find some way to test this
code? This might be complicated, since it requires starting two Vim
instances talking to each other, but it would be very useful to have at
least basic testing for this code.
Hey,
I've attached some basic tests.
I'm not sure if what I'm doing here would work on all systems,
but it's a start. Let me know what you think.
- Brian
Small change. I meant to keep remote_read() from being called
if remote_peek() didn't see a message, so it won't block.
--
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
Tests for the +clientserver feature.
STARTTEST
:
: Set register 'a' to our expected result of 'ok'.
: Any error messages will be appended.
:
:call setreg('a', 'ok', 'l')
:
: Start the server and verify it's available.
:
:silent !../vim -nes -u NONE --servername vim_test_server - 21 /dev/null
:sleep 200m
:if index(split(serverlist(), \n), 'VIM_TEST_SERVER') 0
: if empty(system(../vim --serverlist | grep -i vim_test_server))
:call setreg('a', 'Server failed to start.', 'al')
: else
:call setreg('a', 'serverlist() failed.', 'al')
: endif
:endif
:
: Make sure remote_expr() works.
:
:let r = remote_expr('vim_test_server', '2+2')
:if r != 4
: call setreg('a', 'remote_expr() failed.', 'al')
: call setreg('a', 'Expected: ''4'' Got: '. r, 'al')
:endif
:
: Set a line in server's buffer.
: Give this a chance to process, since remote_send() returns immediately.
: Ask the server for the line to verify it was set.
:
:call remote_send('vim_test_server', 'call setline(1,test)cr')
:sleep 200m
:let r = remote_expr('vim_test_server', 'getline(1)')
:if r != 'test'
: call setreg('a', 'remote_send() failed to set server''s buffer.', 'al')
: call setreg('a', 'Expected: ''test'' Got: '. r, 'al')
:endif
:
: Lists should be returned as a newline joined string.
:
:call remote_expr('vim_test_server', 'setline(1,[one,two])')
:let r = remote_expr('vim_test_server', 'getline(1,$)')
:if r != one\ntwo\n
: call setreg('a', 'remote_expr() failed to return a newline joined string.',
'al')
: call setreg('a', 'Expected: ''one\ntwo\n'' Got: '. r, 'al')
:endif
:
: Ask the server to send us a message.
: Verify the message is waiting.
: Read the message.
:
:let sid = ''
:call remote_send('vim_test_server', 'call server2client(expand(client),
message)cr', 'sid')
:sleep 200m
:if empty(sid)
: call setreg('a', 'remote_send() failed to set the server id.', 'al')
:else
: let r = ''
: let a = remote_peek(sid, 'r')
: if a 1
:call setreg('a', 'remote_peek() failed to report a message is waiting.',
'al')
: else
:if r != 'message'
: call setreg('a', 'remote_peek() failed to return the waiting message.',
'al')
: call setreg('a', 'Expected: ''message'' Got: '. r, 'al')
:endif
:let r = remote_read(sid)
:if r != 'message'
: call setreg('a', 'remote_read() failed to return the waiting message.',
'al')
: call setreg('a', 'Expected: ''message'' Got: '. r, 'al')
:endif
: endif
:endif
:
: Stop the server
:
:let pid = system(ps -eo pid,cmd | grep vim_test_server | grep -v grep | awk
'{print $1}')
:if !empty(pid) | exe(silent !kill .pid) | endif
:
: Store results and exit
:
Gap
:?RESULTS?1,$w! test.out
:qa!
ENDTEST
RESULTS
if_xcmdsrv.c patches
Recently, I have been looking into different methods for using Vim to syntax highlight small blocks of code. In the process, I found runtime/tools/xcmdsrv_client.c, which worked but seemed a little outdated. So, after working with this a bit, I decided to create a Ruby extension from src/if_xcmdsrv.c. https://github.com/burns/vim_client-ruby This is the most I've ever done in C, so it was quite the learning experience. So, comments/suggestions are certainly welcome :) While working with this, I found a few things I wanted to submit for changes in if_xcmdsrv.c. I've attached 3 patches, which include my comments. if_xcmdsrv.patch.1 was a duplicate call to ga_init2. if_xcmdsrv.patch.2 deals with the fact that the server is actually sending a response to clients making input key requests (--remote-send), even though they don't expect one, and some other thoughts. if_xcmdsrv.patch.3 suggests some changes to the ServerWait() function, which speeds up response time, handles an issue where the XEvent queue is not being checked when 'localLoop' is true, and a few other thoughts. I appreciate your time - and Vim! :) - Brian -- 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 if_xcmdsrv.patch.1 Description: Unix manual page if_xcmdsrv.patch.2 Description: Unix manual page if_xcmdsrv.patch.3 Description: Unix manual page
Offset in netbeans API is different in insert and remove commands
It appears from my testing (with code checked out with hg today) that the offset parameter means different things in the netbeans insert command than it does in the remove command. The Vim insert and remove event offsets appear to match the remove command, but not the insert command. The objective of this email is to ask: 1) Am I correct? 2) If yes, is that intended? 3) If no, may I submit a patch to make them mean the same thing? Here's a shell command I use to test with vim: nc -l 3219 END 1:editFile!1 /tmp/test.txt 1:insert/2 0 This is a line of text 1:remove/3 5 2 1:insert/4 5 should be END Since the offset is the same on the removal and the insert, I would expect the result to be: This should be a line of text Instead, the result is: This a line of textshould be Based on other tests, it appears that the insert command is interpreting the offset as a line offset rather than a character offset. Given that the insert command offset is the only one that's different, I'd like to see it changed to match the others. However, I'm not sure if others are relying on the current behavior. And if nothing else, I'd like to give the doc page some love. It took me several hours and a few gdb sessions to figure out how to get the netbeans interface going, and I suspect I can save others the trouble I went through. -- Brian -- 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: Unicode input bug fix
On Feb 21, 2011, at 1:38 AM, Phil Carter wrote: Using ctrl+v U in insert mode, you can enter Unicode characters by code point. UTF-8 can only encode up to U+7FFF. Entering any code point up to that value works fine, but if if you type ctrl+v U 81234567 for example, you get t_ followed by some other bytes instead of the requested code point. Note that while the encoding used for UTF-8 can store up to 0x7FFF, Unicode only goes up to U+10. In fact, RFC 3629 explicitly limits UTF-8 to the range -10. Earlier versions do not include this range limit but since Unicode itself ends at 10, it is unclear what the longer byte sequences should mean. That said, I'm not sure Vim is really in the not letting the user shoot themselves in the foot business. Phil's fix does prevent completely incorrect output and (IMNSHO) should be applied even if we don't want to limit output to actual UTF-8/Unicode. :-) Feeling slightly pedantic, ~~ Brian Gernhardt -- 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
64-bit support for Windows (Vista)
Hello, With 7.2a now out, I didn't see any mention of support for 64-bit Windows. Vista (whatever you feel about it) really is the gateway to 64-bit on the Windows platform. This is my plea that 7.2 supports 64- bit Windows out of the box. All of the work is already done. There is a site here: http://georgevreilly.com/vim/ that already works. I sure would like to have an official version though. Thanks. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
