Vim 7.0 (1-109 patches) completion bug.
Hi, i think i have found a bug in vim 7.0 Patch level 1-109. Windows version +perl +python (i don't think this matters in this case) here is how to reproduce: gvim -u NONE -U NONE :set complete-=t " don't want complete from tags file - it's not important, just to switch off message :set complete+=longest " that's important i "now we in insert mode one two o:t"now trying to complete second time - no completion, nothing" i.e. i've got resulting text in buffer like this: one two one:t and no 'two' on second C-N when trying to complete 'two' and message "Back at original" (First completion works as expected, but second didn't shown and not complete at all) if remove 'longest' from 'complete' then everything works as expected. Can you reproduce that bug? Or it's intended behaviour? --- [EMAIL PROTECTED]
Re: Patch 7.0.111
On Wed, 4 Oct 2006 at 10:30pm, Bram Moolenaar wrote: > > Fan Decheng wrote: > > > Bram Moolenaar wrote: > > > Patch 7.0.111 > > > Problem:The gzip plugin can't handle filenames with single quotes. > > > Solution: Add and use the shellescape() function. (partly by Alexey Froloff) > > > Files: runtime/autoload/gzip.vim, runtime/doc/eval.txt, src/eval.c, > > > src/mbyte.c, src/misc2.c, src/proto/misc2.pro > [...] > > I wonder whether it is possible to use execv() instead of escaping the > > command and then sending it to the shell. How do you think? > > Vim doesn't have an execv() function. Implementing this properly for > all systems isn't that simple. At least you would need to take care of > $PATH. How about using the underlying execv() where it is supported, and when it is not support just behave like system() does? This approach will probably cover more than 95% of the vim users. The problems that exist with using system() and different shells and environments is a huge usability issue (this will also avoid the minimized window on windows that most people feel bothered), and it might even make big difference in the performance when external commands are executed often (like using external commands to find matches for popup completion, everytime a character is typed). One caceat is that currently, if the external command execution takes a lot of time, you want to terminate it, you can un-minimize the window and kill it. If this window is avoided, Vim should still provide a means to kill it (like doing an explicit kill() when user presses ^C while waiting for the process). -- Thanks, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Gvim closing unexpectedly
[cross-posting to connect threads]
On Thu, 2006-10-05 at 10:04 +1000, Robbie Gates wrote:
> Hi All,
>
> i was having problems with gvim hanging when i tried to edit my
> vimrc.
>
> After a bit of sleuthing, i tracked it down to has("tcl") hanging
> (called from syntax/vim.vim).
It appears your post and one on the vim list are related:
http://tech.groups.yahoo.com/group/vim/message/74227
http://tech.groups.yahoo.com/group/vimdev/message/45215
I'm not on a Windows box tonight to track this down, can anyone help
us figure out if this is in the binary or runtime?
1. Verify syntax/vim.vim is not corrupt
2. Test the binary:
:echo has("tcl")
Greg, do you have Cygwin installed?
Interesting that this just cropped up twice in two hours, these
packages have been downloaded nearly 300 times over 8 days.
--
Steve Hall [ digitect dancingpaper com ]
win32 gvim 7.0 (1-118) hang on has("tcl") with cygwin
Hi All,
i was having problems with gvim hanging when i tried to edit my vimrc.
After a bit of sleuthing, i tracked it down to has("tcl") hanging
(called from syntax/vim.vim). If i :echo has("tcl"), the gvim window
stops responding, and clicking the close box pops up the windows
"program not responding" dialog, etc. A bit more sleuthing revealed
that the culprit is the cygwin tcl84.dll which (in my setup) is in the
path visible to gvim. If i hide that (e.g. by putting an empty file
called tcl84.dll earlier in the path, or in the directory containing
gvim.exe), has("tcl") reports 0 as expected.
Note that i don't actually want tcl support, and certainly don't
expect the cygwin tcl84.dll to work - if i want tcl i can download the
windows version and put it earlier in my path. The workaround of an
empty tcl84.dll in the vim directory works fine for me.
I just figured this was worth reporting, since hangs are annoying, and
i couldn't find anything in the archives about this (or the
workaround). I'm a little curious that the empty file hack worked - i
guess the cygwin dll looks enough like the real one that vim tries to
call something in it and gets hosed ? Sorry i haven't had a chance to
compile my own and take a look at it in a debugger yet.
I'm using the gvim-7-0-118.exe installer from the cream soruceforge
site. Note that i've not installed cream, just one of their plain vim
installers, as this seemed the easiest way to get a compiled, patched,
win32 vim. The download site i used was
http://sourceforge.net/project/showfiles.php?group_id=43866&package_id=39721
- robbie
Re: [macvim] modifiers should be applied to special keys too (patch)
Here is one key that doesn't work for me: Shift-Tab. Most notably when doing command line completion, where Tab gets the next match and Shift-Tab goes to the previous match. I can see it, I'll try to fix it tomorrow. I always use C-P for previous match (much easier to type imho ;-) ), so I didn't notice this... Bye, Nico
Re: Patch 7.0.118
On 10/4/06, Bram Moolenaar <[EMAIL PROTECTED]> wrote: Nikolai Weibull wrote: > Just a quick question: Wasn't "printf" a bit of a misnomer? Why? formattedprinting() would be a bit long, thus using the C library name sounds logical to me. Sprintf() would have been more logical to me, given that printf() in C prints a formatted string to stdout, while printf() in Vim returns a formatted string to its caller. Format() is another name used in some languages for this function. It's too late to change anyway. I realize that. nikolai
Re: [macvim] modifiers should be applied to special keys too (patch)
Nicolas - > > I tried the patch, but it appears that CTRL-F and CTRL-B no longer > > work > > in Normal mode. They do something in Insert mode after CTRL-V. > > CTRL-F and CTRL-B work for me in Normal mode (they scroll forward/ > backward). I'm using mac gvim svn (patches 1-110) and the second > version of my patch. > > Can you give more detailed instructions on how to reproduce the problem? I verified I had used your second patch and found a difference. CTRL-F and CTRL-B are working now. > > It looks like this patch needs more careful testing. Perhaps you > > should > > make a list of keys with various modifiers that need to be tried to > > verify the code works correctly. > > I made a small list ( http://macvim.blogspot.com/2006/10/keyboard- > handling-patch.html ), I'll add further items as problems arise. Here is one key that doesn't work for me: Shift-Tab. Most notably when doing command line completion, where Tab gets the next match and Shift-Tab goes to the previous match. Note that in Insert mode you can use CTRL-K and then a key to find out what Vim gets. - Bram -- A consultant is a person who takes your money and annoys your employees while tirelessly searching for the best way to extend the consulting contract. (Scott Adams - The Dilbert principle) /// Bram Moolenaar -- [EMAIL PROTECTED] -- 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///
Re: Patch 7.0.111
Fan Decheng wrote: > Bram Moolenaar wrote: > > Patch 7.0.111 > > Problem:The gzip plugin can't handle filenames with single quotes. > > Solution: Add and use the shellescape() function. (partly by Alexey > > Froloff) > > Files: runtime/autoload/gzip.vim, runtime/doc/eval.txt, src/eval.c, > > src/mbyte.c, src/misc2.c, src/proto/misc2.pro [...] > I wonder whether it is possible to use execv() instead of escaping the > command and then sending it to the shell. How do you think? Vim doesn't have an execv() function. Implementing this properly for all systems isn't that simple. At least you would need to take care of $PATH. -- For society, it's probably a good thing that engineers value function over appearance. For example, you wouldn't want engineers to build nuclear power plants that only _look_ like they would keep all the radiation inside. (Scott Adams - The Dilbert principle) /// Bram Moolenaar -- [EMAIL PROTECTED] -- 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///
Re: Patch 7.0.118
Nikolai Weibull wrote: > On 10/3/06, Bram Moolenaar <[EMAIL PROTECTED]> wrote: > > > Problem:printf() does not do zero padding for strings. > > Just a quick question: Wasn't "printf" a bit of a misnomer? Why? formattedprinting() would be a bit long, thus using the C library name sounds logical to me. It's too late to change anyway. -- The process for understanding customers primarily involves sitting around with other marketing people and talking about what you would to if you were dumb enough to be a customer. (Scott Adams - The Dilbert principle) /// Bram Moolenaar -- [EMAIL PROTECTED] -- 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///
Missing CursorHold after return from insert to normal ?
CursorHold is suppsed to be triggered in normal mode after &updatetime, correct ? But in the scenario below, when vim gets into normal mode after insert mode, CursorHold is not triggered: 1. vim -u NONE -U NONE 2. :let x=0 3. :let ut=200" just some low value 3. :au CursorHold * let x=x+1 | echo x 4. -- watch CursorHold working 5. ii wait there's not CursorHold ii wait there's not CursorHold ii wait there's not CursorHold Why ? Bug or feature ? Yakov
Re: compilation of regular expressions/ enhancement?
On 10/4/06, Peter Hodge <[EMAIL PROTECTED]> wrote: --- Nikolai Weibull <[EMAIL PROTECTED]> wrote: > On 10/4/06, Peter Hodge <[EMAIL PROTECTED]> wrote: > > > > --- Nikolai Weibull <[EMAIL PROTECTED]> wrote: > > > > > > Great idea, > > > > Nikolei! > > >^- gaah! > > > > > > nikolai > > > > > > > iabbrev Nikolei Nikolai > > match Error /Nikol[^a]i/ > > I'd extended to > > match Error /\/ > > You'd be surprised how often people come up with their very own > spelling of my name. It's alright, once your name has been out there for a couple thousand years (like mine), people will start getting it right more often. Given that both names are Greek in origin, I wouldn't say that either has been around longer than the other, see, for example: http://en.wikipedia.org/wiki/Nikolai http://en.wikipedia.org/wiki/Peter_%28name%29 nikolai
Re: compilation of regular expressions/ enhancement?
Dnia wtorek, 3 października 2006 12:34, Marc Weber napisał: > If this is an issue, there might be the solution introducing a compiled > regular expression as used in python additional to Number, String, > Funcref, List, Dictionary > > What do you think? Would this be an enhancement? IMO compilation of only regexps isn't worth of time. Compilation of whole scripts, THAT would be difference. m.
Re: compilation of regular expressions/ enhancement?
Nikolai Weibull wrote: > match Error /\/ But that will only matches entries that mispell all three letters. You probably want something like: match Error /\/ match Error /\/ match Error /\/ David Brown
Re: Time to remove naming restrictions?
> > Seeing as you've identified the location and apparent fix, why not you? > Because I don't want to maintain my own set of patches, that would be more tiring than using upper-case commands. On Yahoo!7 Messenger - IM with Windows Live Messenger friends. http://au.messenger.yahoo.com
Re: compilation of regular expressions/ enhancement?
--- Nikolai Weibull <[EMAIL PROTECTED]> wrote: > On 10/4/06, Peter Hodge <[EMAIL PROTECTED]> wrote: > > > > --- Nikolai Weibull <[EMAIL PROTECTED]> wrote: > > > > > > Great idea, > > > > Nikolei! > > >^- gaah! > > > > > > nikolai > > > > > > > iabbrev Nikolei Nikolai > > match Error /Nikol[^a]i/ > > I'd extended to > > match Error /\/ > > You'd be surprised how often people come up with their very own > spelling of my name. It's alright, once your name has been out there for a couple thousand years (like mine), people will start getting it right more often. - Peter On Yahoo!7 Fuel Price Watch: Find the cheapest petrol in your area http://au.maps.yahoo.com/fuelwatch/
Re: compilation of regular expressions/ enhancement?
On 10/4/06, Peter Hodge <[EMAIL PROTECTED]> wrote: --- Nikolai Weibull <[EMAIL PROTECTED]> wrote: > On 10/3/06, Marc Weber <[EMAIL PROTECTED]> wrote: > > > parsed, it's just executed line-by-line. What /would/ make sense is > > > to cache the compiled regexes so that regexes used in a loop won't > > > have to be compiled as often. That's a fairly trivial fix, although > > > I'm not going to perform it. > > Great idea, > > Nikolei! >^- gaah! > > nikolai > iabbrev Nikolei Nikolai match Error /Nikol[^a]i/ I'd extended to match Error /\/ You'd be surprised how often people come up with their very own spelling of my name. nikolai
Re: Time to remove naming restrictions?
On 10/4/06, Peter Hodge <[EMAIL PROTECTED]> wrote: There's about 4 lines of vim source code which you need to remove so that you can have lower-case user commands. You're not interested in making your own patch? Seeing as you've identified the location and apparent fix, why not you? Anyway, I felt there was no need to provide a patch before a we had discussion on the merit (or acceptance) of such a patch. nikolai
