Re: Regression in gvim 7.0.00x
On Thu, May 25, 2006 at 03:17:54PM +0200, Luc Hermitte wrote: > * On Thu, May 25, 2006 at 08:30:52AM -0400, Benji Fisher <[EMAIL PROTECTED]> > wrote: > > > I see the following note in doc/version7.txt : > > > > --- fixes and changes since Vim 7.0f --- > > [...] > > Prevent that using CTRL-R = in Insert mode can start Visual mode. > > Must I understand that the workaround I've found won't work in the > future ? (the workaround consists in returning > gv to i_CTRL-R=) AFAIK this will continue to work. The change is what you already noticed (I think): if = calls a function, and that function changes the mode, that will not be respected. It is OK if the function returns characters that change the mode. You might also have a look at :help :map-expression I have not played with it yet, but I think the idea is to give a simpler alternative to certain = constructions. > What about @= ? Can I use it to execute a sequence that will change the > mode to insert- or select-mode, according to the result of my function ? > Or is it also an undocumented feature that may not be supported in the > future ? I am not sure what you have in mind. Changes like this are not at all common. In this case, vim was put in an undocumented mode, and Bram was afraid that its behavior would be unpredictable in that case. (It could be considered a bug, since all of vim's modes are supposed to be listed under :help vim-modes .) HTH --Benji Fisher
Re: netrw, winxp, and a problem...
From: Charles E Campbell Jr, May 25, 2006 9:52 AM > Steve Hall wrote: > > > Just assume all paths are Windows-hostile unless passed through > > such a wrapper. (I never see these errors on *nix, so I assume > > it's path related.) > > I'll try it! The unfortunate part is, I can't test it. Or rather, I > can test to see if the wrapper introduces some new problem, but as I > haven't been able to duplicate the problem others are having I can't > do the test. Same thing I saw, I never could track down if the errant slashes were coming from tempname(), expand(), fnamemodify(), existing environment vars, ones Vim found (Vim contrives $HOME if it doesn't exist), etc. But the reports went away, so it seemed to fix it for us. -- Steve Hall [ digitect mindspring com ] :: Cream... something good to put in your Vim! :: http://cream.sourceforge.net
Re: netrw, winxp, and a problem...
Steve Hall wrote: Just assume all paths are Windows-hostile unless passed through such a wrapper. (I never see these errors on *nix, so I assume it's path related.) I'll try it! The unfortunate part is, I can't test it. Or rather, I can test to see if the wrapper introduces some new problem, but as I haven't been able to duplicate the problem others are having I can't do the test. Thank you! Chip Campbell
Re: Regression in gvim 7.0.00x
* On Thu, May 25, 2006 at 08:30:52AM -0400, Benji Fisher <[EMAIL PROTECTED]> wrote: > > The problem consists in the combination of a few things: > > - a nmapping selects (as in select-mode) a few characters > > - an imapping calls a function (through i_CTRL-R) that executes the > > previous mapping with :normal, and then returns "\" to terminate > > the INSERT-SELECT mode and finish in select-mode. > > I do not have time to look at this closely, but I assume it is > because certain undocumented modes are now no longer supported. This > was discussed on the vim users' list on the thread "Insert Visual > mode", started by Gerald Lai on April 22. (That is from my personal > mail archive; I assume that is enough information for you to find the > thread.) Indeed that's linked my problem. Thanks for the reference. The fork of mu-template i'm maintaining is one of these scripts that rely on i_CTRL-R to insert stuff (with :r actually), and then finish in insert- or in select-mode depending on the presence of a placeholder/marker in the text inserted. > I see the following note in doc/version7.txt : > > --- fixes and changes since Vim 7.0f --- > [...] > Prevent that using CTRL-R = in Insert mode can start Visual mode. Must I understand that the workaround I've found won't work in the future ? (the workaround consists in returning gv to i_CTRL-R=) What about @= ? Can I use it to execute a sequence that will change the mode to insert- or select-mode, according to the result of my function ? Or is it also an undocumented feature that may not be supported in the future ? -- Luc Hermitte http://hermitte.free.fr/vim/
Re: Regression in gvim 7.0.00x
On Thu, May 25, 2006 at 02:06:55AM +0200, Luc Hermitte wrote: > Hello, > > I've been observing a regression on gvim since the release of vim 7.0. > I'm observing it on gvim 7.0.000 on windows, gvim 7.0.015 (or 17, I do > not remember) on Linux (gui=GTK2/Athena). It seems I do not have it with > the console version on Linux -- I haven't had the opportunity to test > the following lines of code with the console version. > > I don't remember the problem on gvim 7.0e (at least I do not have it on > vim 7.0a on windows) > > > The problem consists in the combination of a few things: > - a nmapping selects (as in select-mode) a few characters > - an imapping calls a function (through i_CTRL-R) that executes the > previous mapping with :normal, and then returns "\" to terminate > the INSERT-SELECT mode and finish in select-mode. I do not have time to look at this closely, but I assume it is because certain undocumented modes are now no longer supported. This was discussed on the vim users' list on the thread "Insert Visual mode", started by Gerald Lai on April 22. (That is from my personal mail archive; I assume that is enough information for you to find the thread.) I see the following note in doc/version7.txt : --- fixes and changes since Vim 7.0f --- [...] Prevent that using CTRL-R = in Insert mode can start Visual mode. HTH --Benji Fisher
