Re: Vim 7.3f ready for beta testing
On 14/08/10 00:12, Ben Fritz wrote: On Aug 13, 3:40 pm, Bram Moolenaarb...@moolenaar.net wrote: Omitted in this version are: - Extra and lang archives, these are now included in the main source and runtime archives. - The 16-bit DOS, OS/2 and Amiga versions, these are obsolete. What does it mean, that OS/2 and Amiga are obsolete? Has the code for these platforms been removed? Will it be? Maybe it will, maybe it won't, but AFAICT Bram is not willing to waste time and effort in preparing precompiled distributions for them. Feel free to compile them yourself if you are. :-) Best regards, Tony. -- How doth the VAX's C compiler Improve its object code. And even as we speak does it Increase the system load. How patiently it seems to run And spit out error flags, While users, with frustration, all Tear their clothes to rags. -- 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: Vim 7.3f ready for beta testing
Tony Mechelynck wrote: On 14/08/10 00:12, Ben Fritz wrote: On Aug 13, 3:40 pm, Bram Moolenaarb...@moolenaar.net wrote: Omitted in this version are: - Extra and lang archives, these are now included in the main source and runtime archives. - The 16-bit DOS, OS/2 and Amiga versions, these are obsolete. What does it mean, that OS/2 and Amiga are obsolete? Has the code for these platforms been removed? Will it be? Maybe it will, maybe it won't, but AFAICT Bram is not willing to waste time and effort in preparing precompiled distributions for them. Feel free to compile them yourself if you are. :-) Best regards, Tony. Speaking of exotic OS, I have installed Haiku (OS compatible with BeOS, see http://www.haiku-os.org) and downloaded latest Vim from Mercurial. Vim-7.3f compiles without warning and passes all tests on Haiku. I noticed a few minor glitches though: * The configure script says... checking for BeOS... no I suppose it should say checking for BeOS... yes since Haiku is meant to be compatible with BeOS. I did not observe anything wrong as a result so far anyway. * Vim-7.3f works fine in the terminal on Haiku but there is no GUI (no gVim). The BeOS GUI was dropped in Vim-7 according to :help compile-changes-7: == COMPILE TIME CHANGEScompile-changes-7 Dropped the support for the BeOS and Amiga GUI. They were not maintained and probably didn't work. If you want to work on this: get the Vim 6.x version and merge it back in. == However, :help BeOs still contains information about the BeOS GUI without stating that it was dropped in Version-7. * I did set mouse=a. I can use the mouse to position the cursor and mouse also works fine with Netrw (clicking on directories opens them...). However, I cannot use the mouse to resize Vim's windows (nothing happens when I click the statusline and try to drag it). ~ uname -a Haiku shredder 1 r36769 May 8 2010 20:58:31 BePC Haiku ~ echo $TERM xterm-color ~ vim --version VIM - Vi IMproved 7.3f BETA (2010 Aug 13, compiled Aug 14 2010 06:59:00) Compiled by u...@shredder Huge version without 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 +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_sysmouse +mouse_xterm +multi_byte +multi_lang -mzscheme -netbeans_intg -osfiletype +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 -xterm_clipboard -xterm_save system vimrc file: $VIM/vimrc user vimrc file: $HOME/.vimrc user exrc file: $HOME/.exrc fall-back for $VIM: /boot/home/opt/share/vim Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -g -O2 Linking: gcc-o vim -lncurses -liconv -- Dominique -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Vim 7.3f ready for beta testing
2010/8/14 Dominique Pellé dominique.pe...@gmail.com: * I did set mouse=a. I can use the mouse to position the cursor and mouse also works fine with Netrw (clicking on directories opens them...). However, I cannot use the mouse to resize Vim's windows (nothing happens when I click the statusline and try to drag it). That would be expected behavior if ttymouse=xterm instead of xterm2 (as far as I can tell, the original xterm mouse protocol had no drag-and-drop support). Does :set ttymouse=xterm2 fix it? ~Matt -- 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: Vim 7.3f ready for beta testing
On 14/08/10 09:44, Matt Wozniski wrote: 2010/8/14 Dominique Pellédominique.pe...@gmail.com: * I did set mouse=a. I can use the mouse to position the cursor and mouse also works fine with Netrw (clicking on directories opens them...). However, I cannot use the mouse to resize Vim's windows (nothing happens when I click the statusline and try to drag it). That would be expected behavior if ttymouse=xterm instead of xterm2 (as far as I can tell, the original xterm mouse protocol had no drag-and-drop support). Does :set ttymouse=xterm2 fix it? ~Matt With +termresponse compiled-in, and no :set ttymouse= command in the vimrc, Vim should set it to xterm2 on receipt of a v:termresponse reply from the terminal (if it has the capability and t_RV is properly set, either in the disk termcap, or the builtin termcap (whichever is being used, see :help 'ttybuiltin'), or if in neither, it must be set by e.g. :let t_RV = \e[c Best regards, Tony. -- The human race has been fascinated by sharks for as long as I can remember. Just like the bluebird feeding its young, or the spider struggling to weave its perfect web, or the buttercup blooming in spring, the shark reveals to us yet another of the infinite and wonderful facets of nature, namely the facet that it can bite your head off. This causes us humans to feel a certain degree of awe. -- Dave Barry, The Wonders of Sharks on TV -- 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: Vim 7.3f ready for beta testing
Matt Wozniski wrote: 2010/8/14 Dominique Pellé dominique.pe...@gmail.com: * I did set mouse=a. I can use the mouse to position the cursor and mouse also works fine with Netrw (clicking on directories opens them...). However, I cannot use the mouse to resize Vim's windows (nothing happens when I click the statusline and try to drag it). That would be expected behavior if ttymouse=xterm instead of xterm2 (as far as I can tell, the original xterm mouse protocol had no drag-and-drop support). Does :set ttymouse=xterm2 fix it? ~Matt You're right. After I do :set ttymouse=xterm2, I can then use the mouse to resize Windows in Vim-7.3f on Haiku. Thanks! -- Dominique -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Mouse control in a Quick Edit mode Windows console
On Aug 14, 1:46 am, John Beckett johnb.beck...@gmail.com wrote: You have had some probably not replies, so let me be more definite. You are talking about Windows command prompt, where you can right-click a command prompt title bar and choose Properties, Options tab, QuickEdit Mode. The whole point of QuickEdit Mode is that the operating system will handle mouse events, and will NOT pass them to the application runnning in the command prompt window. There is NOTHING an application like Vim can do to use the mouse under those conditions. You can make a Windows shortcut that opens command prompt with QuickEdit mode off, and makes the window the size you want, and uses something like Ctrl-Alt-V to open, then do all your editing there (other command prompts can have QuickEdit mode on). BTW using gvim is better once you choose a suitable color scheme and get used to it. John Thank you John, that is clear. 1/ However, as a user, I see that a QuickEdit mode command prompt windows behaves more or less like all unix terminals (plus Mintty in Cygwin). With these terminals, mouse selection is active at the command prompt (allowing quick copy/paste of file names), but these terminals are able to give back mouse control to Vim when the later is launched inside the terminal with set mouse=a. Why is Windows QuickEdit mode command prompt unable to do the same? That seems incredible. 2/ Thank you for the tips. However using multiple consoles is complicated for me (see below). 3/ I use Windows command prompt to launch Cygwin ssh to connect to a distant unix server over a slow ADSL connection. In these conditions, Vim is quick if it launched in the original command prompt. Of course, I could launch gvim if I connect with ssh -X (with XWin active), but as you know, X11 is very, very slow on Mbps range connections. That the reason why I am bound to console Vim (which colors I like, except the blue) and why I would like to have both the comfort of QuickEdit mode and mouse control in Vim. BTW, I found recently that doing the same with Mintty yields all the desired features. The reason of my thread is that I was amazed that it was not possible with cmd console (which is the default console in Cygwin). Best regards Jean Johner -- 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: Vim 7.3f: :r file fails when 'compatible'
Gary Johnson wrote: In a directory containing a simple text file named 'mary', execute the following: $ vim -u NONE -i NONE :r mary The result is the following two error messages: E812: Autocommands changed buffer or buffer name E484: Can't open file mary I don't know what autocommand that could be since I started Vim without plugins and :scriptnames shows nothing. This works without error if Vim is started in 'noncompatible' mode or when using Vim 6.3. I can reproduce it. Strange that nobody noticed until now. I'll fix it ASAP. -- hundred-and-one symptoms of being an internet addict: 65. The last time you looked at the clock it was 11:30pm, and in what seems like only a few seconds later, your sister runs past you to catch her 7am school bus. /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Vim 7.3f ready for beta testing
Ben Fritz wrote: On Aug 13, 3:40 pm, Bram Moolenaar b...@moolenaar.net wrote: Omitted in this version are: - Extra and lang archives, these are now included in the main source and runtime archives. - The 16-bit DOS, OS/2 and Amiga versions, these are obsolete. What does it mean, that OS/2 and Amiga are obsolete? Has the code for these platforms been removed? Will it be? The code is still there and I even generate the archives for the Amiga. But it's all untested and there are no binaries. I don't think anybody runs OS/2 or Amiga OS except for fun. -- hundred-and-one symptoms of being an internet addict: 63. You start using smileys in your snail mail. /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Testdir use of rmdir /Q /S for DOS/Windows
John Beckett wrote: src/testdir/Make_dos.mak runs for every test on DOS/Windows (I think), and it includes: rmdir /s /q Xfind Isn't that redundant, because it is only needed for test73.in which performs the above operation? test73.in includes: : if has(win16) || has(win32) || has(win64) || has(dos16) || has(dos32) : exec silent !rmdir /Q /S . a:dir I guess the list of has(...) items is what you have to do to say DOS or Windows, but not cygwin, however there was no /q /s in rmdir for DOS or win16 (they had deltree /y). I would not worry about about that (i.e. accept that test73 is not going to work on DOS or win16). The problem is that the rmdir command in test73.in does not work for the DJGPP build. I have tried various alternatives, but could not figure it out. Somehow it uses an rmdir command that doesn't take /Q or /S. With the rmdir command in the build file it should hopefully work, although when using the gmake that comes with DJGPP you have the same problem. You may get a few warnings, also for the del X*.*, but they are harmless. For me all the tests pass with all the builds I do, that is the most important thing. -- hundred-and-one symptoms of being an internet addict: 62. If your doorbell rings, you think that new mail has arrived. And then you're disappointed that it's only someone at the door. /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: [patch] 2 bugs in :find command
Dominique Pelle wrote: Using Vim-7.3f (2559:84ba6293f9d7) on Linux, I see 2 bugs with the :find command. Bug #1: I can reproduce the following error with Valgrind: ==13725== Source and destination overlap in strcat(0x469774c, 0x4697756) ==13725==at 0x4025E30: strcat (mc_replace_strmem.c:176) ==13725==by 0x810BA06: uniquefy_paths (misc1.c:9558) ==13725==by 0x810C14D: gen_expand_wildcards (misc1.c:9842) ==13725==by 0x810A9AF: expand_wildcards (misc1.c:8593) ==13725==by 0x810A95E: expand_wildcards_eval (misc1.c:8564) ==13725==by 0x80B6214: ExpandFromContext (ex_getln.c:4468) ==13725==by 0x80B4C5E: ExpandOne (ex_getln.c:3496) ==13725==by 0x80B4843: nextwild (ex_getln.c:3319) ==13725==by 0x80B0BBA: getcmdline (ex_getln.c:803) ==13725==by 0x80B2CF6: getexline (ex_getln.c:2126) ==13725==by 0x809D9F3: do_cmdline (ex_docmd.c:1018) ==13725==by 0x8121DFF: nv_colon (normal.c:5319) ==13725==by 0x811BEC3: normal_cmd (normal.c:1190) ==13725==by 0x80DF966: main_loop (main.c:1260) ==13725==by 0x80DF3A9: main (main.c:965) Steps to reproduce: $ mkdir /tmp/foo $ touch /tmp/foo/xx $ valgrind 2 /tmp/vg.log vim -u NONE -N -c ':cd /tmp/foo' \ -c ':call feedkeys(:find /tmp/foo/\C-D)' And observe error in /tmp/vg.log. Attached patch fixes this bug. Thanks. The strcat should actually work, unless it's implemented in a weird way. Bug #2: Using the same file /tmp/foo/xx as above, file completion does not work if I do: :cd /tmp :find /tmp/foC-D does not work, no completion. For file completion to work in the current directory, I have to use: :cd /tmp :find ./foC-D this works. I have not fixed this second bug yet. I assume that's not the expected behavior, is it? It works OK for me. What is your 'path' set to? It should be the default, and it works for me with the default. When I complete :find /tmp/fo it shortens to :find foo/. A bit strange, but it's correct. -- hundred-and-one symptoms of being an internet addict: 61. Your best friends know your e-mail address, but neither your phone number nor the address where you live. /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Vim 7.3f ready for beta testing
Dominique Pelle wrote: Speaking of exotic OS, I have installed Haiku (OS compatible with BeOS, see http://www.haiku-os.org) and downloaded latest Vim from Mercurial. Vim-7.3f compiles without warning and passes all tests on Haiku. I noticed a few minor glitches though: * The configure script says... checking for BeOS... no I suppose it should say checking for BeOS... yes since Haiku is meant to be compatible with BeOS. I did not observe anything wrong as a result so far anyway. Maybe it's better this way? BeOS had the strange notion of putting filetypes first. Doing things the BeOS way might break some stuff. * Vim-7.3f works fine in the terminal on Haiku but there is no GUI (no gVim). The BeOS GUI was dropped in Vim-7 according to :help compile-changes-7: == COMPILE TIME CHANGEScompile-changes-7 Dropped the support for the BeOS and Amiga GUI. They were not maintained and probably didn't work. If you want to work on this: get the Vim 6.x version and merge it back in. == However, :help BeOs still contains information about the BeOS GUI without stating that it was dropped in Version-7. I'll update that section in the help. * I did set mouse=a. I can use the mouse to position the cursor and mouse also works fine with Netrw (clicking on directories opens them...). However, I cannot use the mouse to resize Vim's windows (nothing happens when I click the statusline and try to drag it). Good luck :-). -- hundred-and-one symptoms of being an internet addict: 64. The remote to the T.V. is missing...and you don't even care. /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Persistent undo usage
I'm trying to get used to persistent undo, but hmmm, I find it still a bit difficult to use. What I want is persistent undo enabled for certain files (not enabled in the vimrc, I don't want all the undo files). So I thought it would be enough to :setlocal undofile when it's needed, and an easy and reliable setup would be to place 'undofile' in the modeline - this way I cannot forget to set the option for the file. But it doesn't work. What works is to set 'undofile' BEFORE editing the file (which is surprising, and I can't think of a technical reason). It would be nice if persistent undo would try harder to continue the undo history. Ideally, 'undofile' can be set at any time, and the undo file is loaded then (if 'undofile' was off); if possible, recent changes (collected while 'undofile' was off) are added to the history of the undo file, making up the new history. Comments? Andy -- 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: Persistent undo usage
Andy Wokula wrote: I'm trying to get used to persistent undo, but hmmm, I find it still a bit difficult to use. What I want is persistent undo enabled for certain files (not enabled in the vimrc, I don't want all the undo files). So I thought it would be enough to :setlocal undofile when it's needed, and an easy and reliable setup would be to place 'undofile' in the modeline - this way I cannot forget to set the option for the file. But it doesn't work. What works is to set 'undofile' BEFORE editing the file (which is surprising, and I can't think of a technical reason). It would be nice if persistent undo would try harder to continue the undo history. Ideally, 'undofile' can be set at any time, and the undo file is loaded then (if 'undofile' was off); if possible, recent changes (collected while 'undofile' was off) are added to the history of the undo file, making up the new history. Comments? It's not that easy, because when you set 'undofile' Vim has to compute a checksum of the text to verify that it matches the undo file. Reloading the file would be the simple solution. Adding code to separate the functionality from reading the file is possible, requires some work. Why not use an BufReadPre autocommand? Usually you can come up with a file pattern (directory, extension) to decide whether to use 'undofile'. -- hundred-and-one symptoms of being an internet addict: 67. Your hard drive crashes. You haven't logged in for two hours. You start to twitch. You pick up the phone and manually dial your ISP's access number. You try to hum to communicate with the modem. You succeed. /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Vim 7.3f: :r file fails when 'compatible'
I wrote: Gary Johnson wrote: In a directory containing a simple text file named 'mary', execute the following: $ vim -u NONE -i NONE :r mary The result is the following two error messages: E812: Autocommands changed buffer or buffer name E484: Can't open file mary I don't know what autocommand that could be since I started Vim without plugins and :scriptnames shows nothing. This works without error if Vim is started in 'noncompatible' mode or when using Vim 6.3. I can reproduce it. Strange that nobody noticed until now. I'll fix it ASAP. It was most likely introduced by patch 7.2.132, sent out March 5 2009. This patch should fix it, please verify it doesn't introduce any new problems: --- a/src/fileio.c 2010-08-08 18:45:40.0 +0200 +++ b/src/fileio.c 2010-08-14 14:20:54.0 +0200 @@ -317,20 +317,14 @@ char_u conv_rest[CONV_RESTLEN]; intconv_restlen = 0; /* nr of bytes in conv_rest[] */ #endif - #ifdef FEAT_AUTOCMD -/* Remember the initial values of curbuf, curbuf-b_ffname and - * curbuf-b_fname to detect whether they are altered as a result of - * executing nasty autocommands. Also check if fname and sfname - * point to one of these values. */ -buf_T *old_curbuf = curbuf; -char_u *old_b_ffname = curbuf-b_ffname; -char_u *old_b_fname = curbuf-b_fname; -int using_b_ffname = (fname == curbuf-b_ffname) - || (sfname == curbuf-b_ffname); -int using_b_fname = (fname == curbuf-b_fname) - || (sfname == curbuf-b_fname); +buf_T *old_curbuf; +char_u *old_b_ffname; +char_u *old_b_fname; +intusing_b_ffname; +intusing_b_fname; #endif + write_no_eol_lnum = 0; /* in case it was set by the previous read */ /* @@ -349,6 +343,19 @@ return FAIL; } +#ifdef FEAT_AUTOCMD +/* Remember the initial values of curbuf, curbuf-b_ffname and + * curbuf-b_fname to detect whether they are altered as a result of + * executing nasty autocommands. Also check if fname and sfname + * point to one of these values. */ +old_curbuf = curbuf; +old_b_ffname = curbuf-b_ffname; +old_b_fname = curbuf-b_fname; +using_b_ffname = (fname == curbuf-b_ffname) + || (sfname == curbuf-b_ffname); +using_b_fname = (fname == curbuf-b_fname) || (sfname == curbuf-b_fname); +#endif + /* After reading a file the cursor line changes but we don't want to * display the line. */ ex_no_reprint = TRUE; -- hundred-and-one symptoms of being an internet addict: 66. You create a homepage with the impression to cure the afflicted...but your hidden agenda is to receive more e-mail. /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: [patch] 2 bugs in :find command
Bram Moolenaar wrote: Bug #2: Using the same file /tmp/foo/xx as above, file completion does not work if I do: :cd /tmp :find /tmp/foC-D does not work, no completion. For file completion to work in the current directory, I have to use: :cd /tmp :find ./foC-D this works. I have not fixed this second bug yet. I assume that's not the expected behavior, is it? It works OK for me. What is your 'path' set to? It should be the default, and it works for me with the default. When I complete :find /tmp/fo it shortens to :find foo/. A bit strange, but it's correct. Sorry, I did not describe well bug #2. Here is how I can reproduce it with Vim-7.3f (2562:5769dc787ec5): $ mkdir /tmp/foo $ vim -u NONE -N -c 'set wildmode=longest,list' :set path? path=.,/usr/include,, :cd go to home dir :find /tmp/foTab Good, completes to :find /tmp/foo/ :cd /tmp :find /tmp/foTab Bad, does not complete anything I assume that's not the expected behavior. Regards -- Dominique -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Vim 7.3f: :r file fails when 'compatible'
On Sat, Aug 14, 2010 at 02:41:04PM +0200, Bram Moolenaar wrote: I wrote: Gary Johnson wrote: In a directory containing a simple text file named 'mary', execute the following: $ vim -u NONE -i NONE :r mary The result is the following two error messages: E812: Autocommands changed buffer or buffer name E484: Can't open file mary I don't know what autocommand that could be since I started Vim without plugins and :scriptnames shows nothing. This works without error if Vim is started in 'noncompatible' mode or when using Vim 6.3. I can reproduce it. Strange that nobody noticed until now. I'll fix it ASAP. It was most likely introduced by patch 7.2.132, sent out March 5 2009. This patch should fix it, please verify it doesn't introduce any new problems: That fixes the error message, but not the issue with the other buffer that I mentioned. $ printf foo\n mary $ vim -u NONE -i NONE existingfile :r mary :ls! 1 %a + existingfile line 2 2u#mary line 1 $ vim -u NONE -i NONE -N :r mary :ls! 1 %a + [No Name]line 2 2u#mary line 1 This only happens in 'nocompatible' mode or if there is an existing buffer loaded. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com signature.asc Description: Digital signature
Re: Vim 7.3f: :r file fails when 'compatible'
On 14/08/10 17:13, James Vega wrote: On Sat, Aug 14, 2010 at 02:41:04PM +0200, Bram Moolenaar wrote: I wrote: Gary Johnson wrote: In a directory containing a simple text file named 'mary', execute the following: $ vim -u NONE -i NONE :r mary The result is the following two error messages: E812: Autocommands changed buffer or buffer name E484: Can't open file mary I don't know what autocommand that could be since I started Vim without plugins and :scriptnames shows nothing. This works without error if Vim is started in 'noncompatible' mode or when using Vim 6.3. I can reproduce it. Strange that nobody noticed until now. I'll fix it ASAP. It was most likely introduced by patch 7.2.132, sent out March 5 2009. This patch should fix it, please verify it doesn't introduce any new problems: That fixes the error message, but not the issue with the other buffer that I mentioned. $ printf foo\n mary $ vim -u NONE -i NONE existingfile :r mary :ls! 1 %a + existingfile line 2 2u#mary line 1 $ vim -u NONE -i NONE -N :r mary :ls! 1 %a + [No Name]line 2 2u#mary line 1 This only happens in 'nocompatible' mode or if there is an existing buffer loaded. I think it is intentional: If a filename is given with :r, it becomes the alternate file. (insert.txt line 1846, sub |inserting-file|). You can't have an alternate file which doesn't appear in :ls!. Note that the file is unlisted though (as shown by the u left of its name), an ordinary :ls won't show it. The fact that there is a buffer name and number doesn't necessarily mean that that buffer is loaded into Vim, just that Vim remembers something about that file. Best regards, Tony. -- What I tell you three times is true. -- 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: Vim 7.3f: :r file fails when 'compatible'
James Vega wrote: On Sat, Aug 14, 2010 at 02:41:04PM +0200, Bram Moolenaar wrote: I wrote: Gary Johnson wrote: In a directory containing a simple text file named 'mary', execute the following: $ vim -u NONE -i NONE :r mary The result is the following two error messages: E812: Autocommands changed buffer or buffer name E484: Can't open file mary I don't know what autocommand that could be since I started Vim without plugins and :scriptnames shows nothing. This works without error if Vim is started in 'noncompatible' mode or when using Vim 6.3. I can reproduce it. Strange that nobody noticed until now. I'll fix it ASAP. It was most likely introduced by patch 7.2.132, sent out March 5 2009. This patch should fix it, please verify it doesn't introduce any new problems: That fixes the error message, but not the issue with the other buffer that I mentioned. $ printf foo\n mary $ vim -u NONE -i NONE existingfile :r mary :ls! 1 %a + existingfile line 2 2u#mary line 1 $ vim -u NONE -i NONE -N :r mary :ls! 1 %a + [No Name]line 2 2u#mary line 1 This only happens in 'nocompatible' mode or if there is an existing buffer loaded. I would think that works as intended. An extra buffer entry is created for the file, so that you can do :e #. Do you see a problem in that? -- hundred-and-one symptoms of being an internet addict: 70. ISDN lines are added to your house on a hourly basis /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Vim 7.3f: :r file fails when 'compatible'
On 14/08/10 17:56, James Vega wrote: On Sat, Aug 14, 2010 at 05:42:21PM +0200, Tony Mechelynck wrote: On 14/08/10 17:13, James Vega wrote: That fixes the error message, but not the issue with the other buffer that I mentioned. $ printf foo\n mary $ vim -u NONE -i NONE existingfile :r mary :ls! 1 %a + existingfile line 2 2u#mary line 1 $ vim -u NONE -i NONE -N :r mary :ls! 1 %a + [No Name]line 2 2u#mary line 1 This only happens in 'nocompatible' mode or if there is an existing buffer loaded. I think it is intentional: If a filename is given with :r, it becomes the alternate file. (insert.txt line 1846, sub |inserting-file|). You can't have an alternate file which doesn't appear in :ls!. Note that the file is unlisted though (as shown by the u left of its name), an ordinary :ls won't show it. Ah, I guess that makes sense. The lack of 'f' incpo when using -N explains, I think, why the behavior in my second example only happens in 'nocompatible' mode. Yes, in 'compatible' mode I expect you would instead see: 1 %a+ mary line 2 Best regards, Tony. -- Democracy is a government where you can say what you think even if you don't think. -- 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] 2 bugs in :find command
2010/8/14 Bram Moolenaar b...@moolenaar.net: Dominique Pelle wrote: Bram Moolenaar wrote: Bug #2: Using the same file /tmp/foo/xx as above, file completion does not work if I do: :cd /tmp :find /tmp/foC-D does not work, no completion. For file completion to work in the current directory, I have to use: :cd /tmp :find ./foC-D this works. I have not fixed this second bug yet. I assume that's not the expected behavior, is it? It works OK for me. What is your 'path' set to? It should be the default, and it works for me with the default. When I complete :find /tmp/fo it shortens to :find foo/. A bit strange, but it's correct. Sorry, I did not describe well bug #2. Here is how I can reproduce it with Vim-7.3f (2562:5769dc787ec5): $ mkdir /tmp/foo $ vim -u NONE -N -c 'set wildmode=longest,list' :set path? path=.,/usr/include,, :cd go to home dir :find /tmp/foTab Good, completes to :find /tmp/foo/ :cd /tmp :find /tmp/foTab Bad, does not complete anything I assume that's not the expected behavior. OK, I see it now. It's interference between longest in 'wildmode' and the shortening that the :find completion is doing. Using CTRL-L shows it without changing the 'wildmode' option. At the last step, if you use CTRL-D instead of Tab, you see it lists foo/. That's the shortened version of /tmp/foo/. The method longest uses to find the longest common string doesn't really work here, because when there are multiple matches you get a short string which then has a different meaning. The shortening for :find completion only works if you use the whole result. Example: Suppose /tmp/foobar and /tmp/foofoo exist. Then completing :find /tmp/fo would result in :find foo, since foo is the longest common part of foobar and foofoo. But removing /tmp/ now has changed the meaning, further completion on :find foo will give a different set of results. I'll add a remark in the todo list. Attached patch fixes this issue. nazri -- 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 --git a/src/misc1.c b/src/misc1.c index c4a6015..f8e51a2 100644 --- a/src/misc1.c +++ b/src/misc1.c @@ -9722,6 +9722,9 @@ gen_expand_wildcards(num_pat, pat, num_file, file, flags) char_u *p; static int recursive = FALSE; int add_pat; +#if defined(FEAT_SEARCHPATH) +int did_expand_in_path = FALSE; +#endif /* * expand_env() is called to expand things like ~user. If this fails, @@ -9814,6 +9817,7 @@ gen_expand_wildcards(num_pat, pat, num_file, file, flags) recursive = FALSE; add_pat = expand_in_path(ga, p, flags); recursive = TRUE; + did_expand_in_path = TRUE; } else #endif @@ -9838,7 +9842,7 @@ gen_expand_wildcards(num_pat, pat, num_file, file, flags) } #if defined(FEAT_SEARCHPATH) - if (ga.ga_len 0 (flags EW_PATH)) + if (did_expand_in_path == TRUE ga.ga_len 0 (flags EW_PATH)) uniquefy_paths(ga, p); #endif if (p != pat[i])
Re: [patch] 2 bugs in :find command
2010/8/15 Nazri Ramliy ayieh...@gmail.com:
2010/8/14 Bram Moolenaar b...@moolenaar.net:
Dominique Pelle wrote:
Bram Moolenaar wrote:
Bug #2:
Using the same file /tmp/foo/xx as above, file completion does
not work if I do:
:cd /tmp
:find /tmp/foC-D does not work, no completion.
For file completion to work in the current directory, I have to use:
:cd /tmp
:find ./foC-D this works.
I have not fixed this second bug yet. I assume that's not the expected
behavior, is it?
It works OK for me. What is your 'path' set to? It should be the
default, and it works for me with the default.
When I complete :find /tmp/fo it shortens to :find foo/. A bit
strange, but it's correct.
Sorry, I did not describe well bug #2.
Here is how I can reproduce it with Vim-7.3f (2562:5769dc787ec5):
$ mkdir /tmp/foo
$ vim -u NONE -N -c 'set wildmode=longest,list'
:set path?
path=.,/usr/include,,
:cd go to home dir
:find /tmp/foTab Good, completes to :find /tmp/foo/
:cd /tmp
:find /tmp/foTab Bad, does not complete anything
I assume that's not the expected behavior.
OK, I see it now. It's interference between longest in 'wildmode' and
the shortening that the :find completion is doing. Using CTRL-L shows
it without changing the 'wildmode' option.
At the last step, if you use CTRL-D instead of Tab, you see it lists
foo/. That's the shortened version of /tmp/foo/. The method
longest uses to find the longest common string doesn't really work
here, because when there are multiple matches you get a short string
which then has a different meaning. The shortening for :find completion
only works if you use the whole result.
Example: Suppose /tmp/foobar and /tmp/foofoo exist. Then completing
:find /tmp/fo would result in :find foo, since foo is the longest
common part of foobar and foofoo. But removing /tmp/ now has
changed the meaning, further completion on :find foo will give a
different set of results.
I'll add a remark in the todo list.
Attached patch fixes this issue.
Excerpt from help 'path':
This is a list of directories which will be searched when using the
|gf|, [f, ]f, ^Wf, |:find|, |:sfind|, |:tabfind| and other commands,
provided that the file being searched for has a relative path (not
starting with /, ./ or ../).
is the attached patch (review.patch) a better check for triggering
the find-completion?
nazri.
--
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 --git a/src/misc1.c b/src/misc1.c
index f8e51a2..a9a61fb 100644
--- a/src/misc1.c
+++ b/src/misc1.c
@@ -9811,7 +9811,12 @@ gen_expand_wildcards(num_pat, pat, num_file, file, flags)
if (mch_has_exp_wildcard(p))
{
#if defined(FEAT_SEARCHPATH)
- if (*p != '.' !vim_ispathsep(*p) (flags EW_PATH))
+ if ((flags EW_PATH) !mch_isFullName(p)
+ STRNCMP(p, ./, 2) STRNCMP(p, ../, 3)
+#if defined(MSWIN) || defined(MSDOS)
+ STRNCMP(p, .\\, 2) STRNCMP(p, ..\\, 3)
+#endif
+ )
{
/* recursiveness is OK here */
recursive = FALSE;
Re: [PATCH] bugfix for find completion
On Sat, Aug 14, 2010 at 3:20 AM, Bram Moolenaar b...@moolenaar.net wrote: I have now taken another look at the code. I have done a few cleanups. I found one bug: when 'path' has an item ./subdir it was not used relative to the current buffer. Attached patch adds a check for this in test73. Please check that I didn't break anything. Looks good. nazri -- 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 --git a/src/testdir/test73.in b/src/testdir/test73.in index 3518e80..5472247 100644 --- a/src/testdir/test73.in +++ b/src/testdir/test73.in @@ -150,6 +150,14 @@ SVoyager 2:w :exec cd . cwd . /Xfind/in :find file :exec w . test_out +: Test for relative to current buffer 'path' item +:exec cd . cwd . /Xfind/ +:set path=./path +: Open the file where Jimmy Hoffa is found +:e in/file.txt +: Find the file containing 'E.T.' in the Xfind/in/path directory +:find file +:exec w . test_out :q :exec cd . cwd :call DeleteDirectory(Xfind) diff --git a/src/testdir/test73.ok b/src/testdir/test73.ok index 4dd48fb..366f951 100644 --- a/src/testdir/test73.ok +++ b/src/testdir/test73.ok @@ -16,3 +16,4 @@ Voyager 1 Voyager 1 Voyager 2 Jimmy Hoffa +E.T.
Re: Vim 7.3f: :r file fails when 'compatible'
On 2010-08-14, Bram Moolenaar wrote: I wrote: Gary Johnson wrote: In a directory containing a simple text file named 'mary', execute the following: $ vim -u NONE -i NONE :r mary The result is the following two error messages: E812: Autocommands changed buffer or buffer name E484: Can't open file mary I don't know what autocommand that could be since I started Vim without plugins and :scriptnames shows nothing. This works without error if Vim is started in 'noncompatible' mode or when using Vim 6.3. I can reproduce it. Strange that nobody noticed until now. I'll fix it ASAP. It was most likely introduced by patch 7.2.132, sent out March 5 2009. This patch should fix it, please verify it doesn't introduce any new problems: I was about to apply this patch when I checked hg incoming and saw that it was already in the repo, so I updated to change set 4b7929dad28a (Fix building the Mac version with GUI.) and built that. It seems to work fine. Thank you. Regards, Gary -- 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: Mouse control in a Quick Edit mode Windows console
Why is Windows QuickEdit mode command prompt unable to do the same? That seems incredible. xterm (and so many of its emulators) defines an escape sequence that requests mouse events to be passed to the app as escape sequences. cmd.exe presumably lacks such a mechanism. It seems to be a bare- bones terminal emulator; the solution would be to find a better one, or use gvim. Regards, John -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: RFC: use hunspell dictionaries
Sorry to bump a very old thread. I write in reference to https://bugzilla.redhat.com/show_bug.cgi?id=219777 and https://fedorahosted.org/fedora-engineering-services/ticket/12 As part of my work with Fedora Engineering Services I have been assigned the task of revisiting the possibility of modifying vim to use the hunspell dictionaries in an effort to save some space on our media. As some of you would know some time ago a patch was submitted and at the time Bram Moolenaar wrote: Interesting idea. It appears it doesn't handle words with non-words characters in them. Would be a good idea to compare, both the quality and speed, for checking and making suggestions. Especially for more complicated languages. The patch is crude, has a few hard-coded paths and hardly any comments, but it's good for trying it out. What I would like to ask at this stage is for some feedback on the best way to accomplish this and any assistance, in terms of information, examples, code, you may see fit to provide. I would like to get this done in a manner that as many people as possible are happy with and that can benefit as many in the community as possible. Cheers, Brad -- 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: RFC: use hunspell dictionaries
Sorry to bump a very old thread. I write in reference to https://bugzilla.redhat.com/show_bug.cgi?id=219777 and https://fedorahosted.org/fedora-engineering-services/ticket/12 As part of my work with Fedora Engineering Services I have been assigned the task of revisiting the possibility of modifying vim to use the hunspell dictionaries in an effort to save some space on our media. As some of you would know some time ago a patch was submitted and at the time Bram Moolenaar wrote: Interesting idea. It appears it doesn't handle words with non-words characters in them. Would be a good idea to compare, both the quality and speed, for checking and making suggestions. Especially for more complicated languages. The patch is crude, has a few hard-coded paths and hardly any comments, but it's good for trying it out. What I would like to ask at this stage is for some feedback on the best way to accomplish this and any assistance, in terms of information, examples, code, you may see fit to provide. I would like to get this done in a manner that as many people as possible are happy with and that can benefit as many in the community as possible. Cheers, Brad -- 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: Mouse control in a Quick Edit mode Windows console
On Sun, 15 Aug 2010, Matt Wozniski wrote: If you really want to work with Cygwin, I'd go with Cygwin + X11 + xterm + ssh... if you've got a full unix environment set up, might as well use it. xterm is a much more feature-filled terminal emulator than cmd.exe, and mouse support will Just Work for you with both Cygwin/X + xterm and with PuTTY. Incidentally, I like to use Cygwin but I don't like running the X server under Cygwin unless I have to, so I tend to use PuTTYCyg, rather than X11 + xterm, found here: https://code.google.com/p/puttycyg/ It has some quirks, but for the most part it works well for me--better than using Cygwin's rxvt that can run with or without the X server. Basically it's just PuTTY with the ability to run your Cygwin shell as well as ssh/telnet/whatever. For gVim, I usually just use a native Windows install. - Christian -- Christian J. Robinson hept...@gmail.com -- http://christianrobinson.name/ -- 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
