Re: noimd don't works under linux
I do the following
- gvim -u NONE
- :set stl=%{imd} ls=2
- :inoremap ESC ESC:set imdCR
- :nnoremap i :set noimdCRi
- :set nocp
- switching back forth between normal mode insert mode using ESC i
When I pressing i, the input focus is on command line command line
shows :set noimdCRi.
If I using :nnoremap i :set noimdCRiCR, pressing i get me to
insert mode (with an extra newline). But switching back forth between
normal mode insert mode, status line always shows 0
Does this reveal some root cause of the problem? How can I further narrow
down the problem?
Thanks
Eddy
Re: noimd don't works under linux
I tried this on FC2:
:set stl=%{imd}
:inoremap ESC ESC:set imdCR
:nnoremap i :set noimdCRi
The first line (along with my usual :set laststatus=2) means that I can
check my 'imd' setting in the status line. When I go between Normal and
Insert modes with i and Esc, it changes from 1 to 0 and back, so I
think it is working.
Yes, I get the same result.
Please try this and see whether you get anything different. Also,
try it with
$ vim -u NONE
:set nocp
If you get the same results but are still having trouble, then the
problem might be some other setting.
HTH --Benji Fisher
When starting with -u NONE, status line isn't showed.
Is there anything else I can do to locate the problem?
Thanks
Eddy
Re: noimd don't works under linux
2006/11/5, A.J.Mechelynck [EMAIL PROTECTED]:
Eddy Zhao wrote:
I tried this on FC2:
:set stl=%{imd}
:inoremap ESC ESC:set imdCR
:nnoremap i :set noimdCRi
The first line (along with my usual :set laststatus=2) means that I can
check my 'imd' setting in the status line. When I go between Normal and
Insert modes with i and Esc, it changes from 1 to 0 and back, so I
think it is working.
Yes, I get the same result.
Please try this and see whether you get anything different. Also,
try it with
$ vim -u NONE
:set nocp
If you get the same results but are still having trouble, then the
problem might be some other setting.
HTH --Benji Fisher
When starting with -u NONE, status line isn't showed.
Is there anything else I can do to locate the problem?
Thanks
Eddy
Enter :set stl=%{imd} ls=2 after starting Vim, and the status line will be
shown, with 0 ('noimdisable') or 1 ('imdisable') on it.
Thanks (I forget to set ls).
I do the following
- gvim -u NONE
- :set stl=%{imd} ls=2
- :inoremap ESC ESC:set imdCR
- :nnoremap i :set noimdCRi
- :set nocp
- switching back forth between normal mode insert mode using ESC i
When I pressing i, the input focus is on command line command line
shows :set noimdCRi.
If I using :nnoremap i :set noimdCRiCR, pressing i get me to
insert mode (with an extra newline). But switching back forth between
normal mode insert mode, status line always shows 0
BTW, I discover that in vim (not gvim), even start without -u NONE,
statusline always shows 0 (while gvim statusline will switch between
0 1)
Anything I can do to further nail down the problem?
Thanks
Eddy
Re: noimd don't works under linux
2006/11/5, A.J.Mechelynck [EMAIL PROTECTED]:
Eddy Zhao wrote:
2006/11/5, A.J.Mechelynck [EMAIL PROTECTED]:
Eddy Zhao wrote:
I tried this on FC2:
:set stl=%{imd}
:inoremap ESC ESC:set imdCR
:nnoremap i :set noimdCRi
The first line (along with my usual :set laststatus=2) means that I
can
check my 'imd' setting in the status line. When I go between
Normal and
Insert modes with i and Esc, it changes from 1 to 0 and back, so I
think it is working.
Yes, I get the same result.
Please try this and see whether you get anything different.
Also,
try it with
$ vim -u NONE
:set nocp
If you get the same results but are still having trouble, then the
problem might be some other setting.
HTH --Benji Fisher
When starting with -u NONE, status line isn't showed.
Is there anything else I can do to locate the problem?
Thanks
Eddy
Enter :set stl=%{imd} ls=2 after starting Vim, and the status line
will be
shown, with 0 ('noimdisable') or 1 ('imdisable') on it.
Thanks (I forget to set ls).
I do the following
- gvim -u NONE
- :set stl=%{imd} ls=2
- :inoremap ESC ESC:set imdCR
- :nnoremap i :set noimdCRi
- :set nocp
- switching back forth between normal mode insert mode using ESC
i
When I pressing i, the input focus is on command line command line
shows :set noimdCRi.
If I using :nnoremap i :set noimdCRiCR, pressing i get me to
insert mode (with an extra newline). But switching back forth between
normal mode insert mode, status line always shows 0
BTW, I discover that in vim (not gvim), even start without -u NONE,
statusline always shows 0 (while gvim statusline will switch between
0 1)
Anything I can do to further nail down the problem?
Thanks
Eddy
- Is your console Vim compiled with IM support? (I suppose it is, but check
the :version output for +xim or +multi_byte_ime). Note: On Unix-like
systems, IM support may require X11 support, and IM functionality may require
access to an X server (thus, maybe in xterm displaying through X, not in
/dev/tty which has no access to X).
- Does it make any difference if you start Console Vim in 'nocompatible' mode,
e.g.
vim -u NONE -i NONE -N +set stl=%{imd} ls=2
?
Hi Tony,
I only using IM in gvim. So I only want IM work correctly in gvim.
gvim is with +xim support.
Thanks
Eddy
noimd don't works under linux
Hi All, I Have the below configuration in vimrc inoremap ESC ESC:set imdCR nnoremap i :set noimdCRi Press Esc to change from insert mode to normal mode DO disable the input method. But after that, when I press i to change from normal mode back to insert mode, the input method is not enbabled (in other words, I have to press C-SPACE to bring back the input method). I've tried on below software enviroment, all doesn't get things work (vim is with xim support) - fc5+ion3+scim+vim7.0(selfbuild officalrpm) - fc6+gnome+scim+vim7.0(selfbuild officalrpm) Meanwhile, the configuration works on windows. I've posted on mailing list similar problem before, but get no solution, the feature is so important, so I'm posting it again. Hope someone have the solution. Thanks Eddy
Re: imd don't take effect under linux
2006/10/1, Bram Moolenaar [EMAIL PROTECTED]: Eddy Zhao wrote: I'm use setting below to disable input method when enter normal mode inoremap ESC ESC:set imdCR The setting works under window, but under linux the setting don't take effect. I'm using gvim 7.0, with xim support, under linux, desktop is ion3 . :verbose map! Esc show: Esc * Esc:set imdCR How could I fix that? (I've searched through the mailing list archive, found a thread report the same problem, but without final conclusion) There must be something wrong with your build. When Vim leaves Insert mode, going back to Normal mode, it always disables the input method. Thus your mapping will not have an effect (well, side effects perhaps). Hi Bram, I'm using FC5 vim package, and I just build vim from source, and the problem still there. Remove inoremap ESC ESC:set imdCR setting in vimrc also don't fix the problem. Thanks Eddy
Re: imd don't take effect under linux
2006/10/2, Alexis S. L. Carvalho [EMAIL PROTECTED]: Thus spake Eddy Zhao: Hello all, I'm use setting below to disable input method when enter normal mode inoremap ESC ESC:set imdCR The setting works under window, but under linux the setting don't take effect. I'm using gvim 7.0, with xim support, under linux, desktop is ion3 . :verbose map! Esc show: Esc * Esc:set imdCR How could I fix that? (I've searched through the mailing list archive, found a thread report the same problem, but without final conclusion) What input method (scim, uim, kinput2, ...) are you using? And what's the value of the GTK_IM_MODULE environment variable? Hi Alexis, I'm using scim, GTK_IM_MODULE is set to scim Thanks Eddy
Re: imd don't take effect under linux
2006/10/2, Dasn [EMAIL PROTECTED]: On Sun, Oct 01, 2006 at 01:37:53PM +0800, Eddy Zhao wrote: Hello all, I'm use setting below to disable input method when enter normal mode inoremap ESC ESC:set imdCR The setting works under window, but under linux the setting don't take effect. Does :set imd take effect in Normal mode of your build? And you could use :set imd? to see if this option is avaliable in your build. Hello Dasn, :set imd DO take effect in normal mode. :set imd? output imdisable Thanks Eddy -- Dasn
Re: imd don't take effect under linux
2006/10/2, A.J.Mechelynck [EMAIL PROTECTED]: Dasn wrote: On Sun, Oct 01, 2006 at 01:37:53PM +0800, Eddy Zhao wrote: Hello all, I'm use setting below to disable input method when enter normal mode inoremap ESC ESC:set imdCR The setting works under window, but under linux the setting don't take effect. Does :set imd take effect in Normal mode of your build? And you could use :set imd? to see if this option is avaliable in your build. To see if the option is available and working (as opposed to defined but not working in this executable version) use :echo exists(+imd) The answer is zero for no (not working), nonzero (normally 1) for yes (working). Similarly in a script: if exists(+imdisable) do something else do something else endif Best regards, Tony. Hello tony, :echo exists(+imd) output 1 Is there other things I can do to locate the problem? Thanks Eddy
Re: imd don't take effect under linux
2006/10/2, A.J.Mechelynck [EMAIL PROTECTED]: Eddy Zhao wrote: 2006/10/2, A.J.Mechelynck [EMAIL PROTECTED]: Dasn wrote: On Sun, Oct 01, 2006 at 01:37:53PM +0800, Eddy Zhao wrote: Hello all, I'm use setting below to disable input method when enter normal mode inoremap ESC ESC:set imdCR The setting works under window, but under linux the setting don't take effect. Does :set imd take effect in Normal mode of your build? And you could use :set imd? to see if this option is avaliable in your build. To see if the option is available and working (as opposed to defined but not working in this executable version) use :echo exists(+imd) The answer is zero for no (not working), nonzero (normally 1) for yes (working). Similarly in a script: if exists(+imdisable) do something else do something else endif Best regards, Tony. Hello tony, :echo exists(+imd) output 1 Is there other things I can do to locate the problem? Thanks Eddy I'm not sure, I don't use an IME myself. (When I need CJK characters in Vim, I either paste them from somewhere else, or use the Unicode number as said under :help i_CTRL-V_digit.) But at least we know that you are supposed to have a functioning 'imdisable' option. Well, let's see what I can find in the help. Maybe you already know most of it, but as they say, there is more in two heads than in one (which is why policemen ride horses ;-) ): - Some IM servers require a helper application (usually a conversion server: kana-kanji for Japanese, pinyin-hanzi for Chinese, etc.) - Vim (IM client), the IM server, and the conversion server if any, must all be configured in a compatible way. This may require settings in ~/.vimrc, in ~/.Xdefaults, in some shell startup script, and maybe elsewhere. - Vim can use OverTheSpot, OffTheSpot or Root styles but not OnTheSpot. - Vim can use a backend server or a frontend one. Windows usually uses backend, X usually uses frontend. - If your IM server is one that Vim can fully control, you must define 'imactivatekey' according to what the IM requires. This is said to be only possible with the GTK versions of gvim at present. - Other IM-related options are 'imcdline', 'iminsert' and 'imsearch' - One of the possible ways to start the XIM (if properly configured) is from the right-click popup menu. I think these are the most important things which I can abstract from the help. Since you know how to use the XIM, you may want to read section 7 (:help mbyte-XIM) of the mbyte.txt helpfile, while trying various settings until you get somethings that works. Hello Tony, Thanks for the extensive info on IM. I'll read the related help in detail. Eddy.
Re: first character cutted when v,j,x
Hi all, The problem is solved as Dasn indicated, by put set selection=exclusive setting in vimrc. (using V instead of v also works in my original mentioned case) Thanks everybody! Eddy 2006/10/1, A.J.Mechelynck [EMAIL PROTECTED]: cga2000 wrote: On Sat, Sep 30, 2006 at 06:03:28PM EDT, Dasn wrote: [..] How to make linux gvim behave like windows vim (l not cutted)? Take a look at your 'selection', it should be 'exclusive' on your windows platform. For more info: :h :behave :h 'selection' Could you explain further? After reading the recommended help files I still don't see the logic of Vim deleting more characters than what I highlighted in the first place _and_ making this the default in *nix environments. What am I missing and what is the purpose of this confusing behavior? Thanks cga What you highlighted includes the cursor (move the cursor to the other end with o -- and with selection=inclusive -- to check it). The Unix default is to delete the whole Visual area, including the cursor character. This, IIUC, predates Vim. The Windows default is different: on Windows, in non-Vim programs, the bar cursor is between characters, not on a character, and the highlighted area (when using shift-right or shift-down, i.e., forward motions) stops left of the cursor. The purpose of the confusing exclusive behaviour on Windows is to cater to the peculiar customs of Windows users. Notice that gvim has a block cursor in Visual mode when 'selection' is inclusive, and a thick bar cursor when it is exclusive. Note: to highlight and delete full lines, use linewise visual mode (with V not v). Linewise-visual always includes (and highlights) the cursor line. Best regards, Tony.
imd don't take effect under linux
Hello all, I'm use setting below to disable input method when enter normal mode inoremap ESC ESC:set imdCR The setting works under window, but under linux the setting don't take effect. I'm using gvim 7.0, with xim support, under linux, desktop is ion3 . :verbose map! Esc show: Esc * Esc:set imdCR How could I fix that? (I've searched through the mailing list archive, found a thread report the same problem, but without final conclusion) Thanks Eddy
Re: case insensitive glob (fwd)
Just tried your new version lookupfile plugin, it can now works in
case-insensitive mode!
Thanks everybody!
Eddy
2006/9/3, Hari Krishna Dara [EMAIL PROTECTED]:
On Sat, 2 Sep 2006 at 10:25pm, Hari Krishna Dara wrote:
On Fri, 1 Sep 2006 at 11:19pm, Eddy Zhao wrote:
Sorry, forget to mention, I'm using vim on linux.
2006/9/1, Eddy Zhao [EMAIL PROTECTED]:
Hi,
I'm using vim 7.0, and find glob is case-sensitive. Is there way
to make glob case-insensitive ? I'm asking this because some plugin
(like lookupfile) rely on glob, and case-sensitive globbing is very
inconvenient. (BTW, I'm finding on windows glob is case-insensitive)
Thanks
Eddy
I came up with the below following Tim's suggestion (sorry, don't have
his email, so replying to yours), but this has a problem as it seems
like using sub-replace-special recursively doesn't work. Is this not
supported or a bug?
Translates the file pattern to ignore case on non-case-insensitive systems.
function! FilePatIgnoreCase(filePat)
return substitute(a:filePat, '\(\[.\{-}\]\)\|\(\a\)',
\
'\=submatch(0)=~^[?[.TranslateAlpha(strpart(submatch(0),1,len(submatch(0))-1),
1).]:TranslateAlpha(submatch(0), 0)', 'g')
endfunction
function! TranslateAlpha(pat, insideCollection)
if a:insideCollection
return substitute(a:pat, '\(\a-\a\)\|\a',
\
'\=submatch(0)=~-?submatch(0).toupper(submatch(0)):submatch(0).toupper(submatch(0))',
'g')
else
return substitute(a:pat, '\a', '[\l\u]', 'g')
endif
endfunction
I need to rework this to avoid one or both of the sub-replace-specials.
--
Thanks,
Hari
I got the below working, without using the sub-replace-special for
second function:
function! FilePatIgnoreCase(filePat)
return substitute(a:filePat, '\(\[.\{-}]\)\|\(\a\)',
\ '\=submatch(0)=~^[?TranslateAlpha(submatch(0),
1):TranslateAlpha(submatch(0), 0)', 'g')
endfunction
function! TranslateAlpha(pat, inCollection)
if a:inCollection
return substitute(substitute(a:pat, '-\@[EMAIL PROTECTED]', '\u', 'g'),
\ '\(\a\)-\(\a\)', '\1-\2\u\1-\u\2', 'g')
else
return substitute(a:pat, '\a', '[\l\u]', 'g')
endif
endfunction
--
Thanks,
Hari
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: case insensitive glob
Sorry, forget to mention, I'm using vim on linux. 2006/9/1, Eddy Zhao [EMAIL PROTECTED]: Hi, I'm using vim 7.0, and find glob is case-sensitive. Is there way to make glob case-insensitive ? I'm asking this because some plugin (like lookupfile) rely on glob, and case-sensitive globbing is very inconvenient. (BTW, I'm finding on windows glob is case-insensitive) Thanks Eddy
Re: fast file locating plugin (like ido.el in emacs)
Hi Hari:
Problem reported yesterday
- calling LookupNotifyFunc prematurely problem seems solved
- path is very long problem seems solved
Problem found today (using the new plugin)
- Without set shellslash, open one file manually, open lookupfile window,
the path's backward slash is not replaced by forward slash
- Sometimes, the following error msg popup when open file thru lookupfile
(after that file is opened successfully). The problem can't be reproduced
everytime (and can't find out how to reproduce it, I haven't seem
this problem
when using the previous version plugin)
Error detected while processing function
SNR55_OpenCurFile..SNR15_LookupReset:
line10:
E31: No such mapping
E31: No such mapping
- Sometimes, after I open one file manually, and then open lookupfile window,
directory path is not updated with the newly opened file's path.
The problem can't be
reproduced everytime (and can't find out how to reproduce it,
previous version plugin
also have this problem)
New feature request
- Directory in showed in directory-content-window is postfixed by
/, but the / is
too far from the path name. It might be more eye easy to postfix
directory name with
/ directly after it.
Thanks
Eddy
2006/8/15, Hari Krishna Dara [EMAIL PROTECTED]:
On Mon, 14 Aug 2006 at 9:02pm, Eddy Zhao wrote:
Hi Hari:
Problems reported yesterday
- Put the set shellslash in vimrc solves most of the backward-slash
problems.
May be it's worth mention in the plugin doc.
I think a better option is to replace backslashes with forwardslashes in
the plugin itself. If Tab inserted path with the right slashes, you
wouldn't have faced this problem, so this is a bug in lookupfile.
- I can't reproduce the Press TAB, C-b, find a lot of error message
problem today,
I'll report the problem when I find the way to reproduce it.
Thanks.
- MRU.vim provide history to files (not buffers) recently used. It is
especially
useful in switching between serveral frequently accessed
directories (even between
vim sessions). Combined with current lookupfile, user can locate
file even more
effeciently.
I looked at this plugin. It doesn't provide any interface to access this
list programmatically, so we need to somehow get this patched up.
Problems find today
- When path is very long (exceed screen width), find
directory-content-window's filelist is messed up
This seems to be a bug in completion. As a workaround, I am going to
enable 'wrap' in this buffer. This seems to avoid the problem, though
you will not then utilize the screen real estate properly.
- Input wrong path, RETURN, find input focus is automatically move to
the line beginning. It's more desirable that the input focus remain at
line end to facilitate user correct the last path segment
- Input wrong path, RETURN, move to line end and delete the last path
segment, input correct path segment keyword, find popup-match-window
not showup
- Input wrong path, RETURN, move to line end and delete the last path
segment, input intact correct path segment (not path keyword), RETURN,
find an empty buffer opened (instead of popup
directory-content-window)
- Sometimes, the following error msg popup serveral times when open
file thru lookupfile (after that file is opened successfully). The
problem can't be reproduced everytime (and can't find out how to
reproduce it)
Error detected while processing function
SNR74_AcceptFile..SNR33_IdoAccept..lookupfile#AcceptFile:
line15:
E121: Undefined variable: g:LookupFile_LookupNotifyFunc
All the above problems are due to calling LookupNotifyFunc prematurely,
which is doing an internal reset. I now moved the call to a different
location, and now it will reset only when the validation has already
been done.
My vimrc configuration is
command! WalkCur :exec LUWalk expand('%:p:h').'/'
nmap unique silent w :WalkCurCR
nmap unique silent b :LUBufsCR
let g:LookupFile_PreserveLastPattern=0
let g:LookupFile_AlwaysAcceptFirst=1
let g:LookupFile_FileFilter =
'\.class$\|\.o$\|\.obj$\|\.exe$\|\.jar$\|\.zip$\|\.war$\|\.tgz$\|\.ear$'
Thanks
Eddy
Thanks for your feedback. I now updated the version at the below URL, so
please give it another try:
http://haridara.googlepages.com/lookupfile.zip
--
Thanks,
Hari
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: fast file locating plugin (like ido.el in emacs)
- Sometimes, the following error msg popup when open file thru lookupfile (after that file is opened successfully). The problem can't be reproduced everytime (and can't find out how to reproduce it, I haven't seem this problem when using the previous version plugin) Error detected while processing function SNR55_OpenCurFile..SNR15_LookupReset: line10: E31: No such mapping E31: No such mapping I can't reproduce this. David Fishburn reported the same error as something that gets generated while using the C-B, so I tried it with several variations with no success. I put in some trace which will give more information, so hopefully I can figure out something the next time it happens to you. This time error message is Error detected while processing function SNR64_OpenCurFile..SNR33_LookupReset: line13: 0 Error detected while processing function SNR64_OpenCurFile: line11: E171: Missing :endif I find way to reproduce it - create lookupfile.vim in ftplugin, which contains the following content nnoremap buffer EscEsc C-Wq inoremap buffer EscEsc EscC-Wq - open lookupfile, open one file, open lookupfile, Esc Esc, open lookupfile, open one file Regards Eddy
Re: fast file locating plugin (like ido.el in emacs)
Hari: Could you upload the pervious version plugin? The latest version plugin always generate error message after I restart lookupfile window Thanks Eddy 2006/8/16, Eddy Zhao [EMAIL PROTECTED]: - Sometimes, the following error msg popup when open file thru lookupfile (after that file is opened successfully). The problem can't be reproduced everytime (and can't find out how to reproduce it, I haven't seem this problem when using the previous version plugin) Error detected while processing function SNR55_OpenCurFile..SNR15_LookupReset: line10: E31: No such mapping E31: No such mapping I can't reproduce this. David Fishburn reported the same error as something that gets generated while using the C-B, so I tried it with several variations with no success. I put in some trace which will give more information, so hopefully I can figure out something the next time it happens to you. This time error message is Error detected while processing function SNR64_OpenCurFile..SNR33_LookupReset: line13: 0 Error detected while processing function SNR64_OpenCurFile: line11: E171: Missing :endif I find way to reproduce it - create lookupfile.vim in ftplugin, which contains the following content nnoremap buffer EscEsc C-Wq inoremap buffer EscEsc EscC-Wq - open lookupfile, open one file, open lookupfile, Esc Esc, open lookupfile, open one file Regards Eddy
Re: fast file locating plugin (like ido.el in emacs)
Hi Hari:
Problems reported yesterday
- Put the set shellslash in vimrc solves most of the backward-slash problems.
May be it's worth mention in the plugin doc.
- I can't reproduce the Press TAB, C-b, find a lot of error message
problem today,
I'll report the problem when I find the way to reproduce it.
- MRU.vim provide history to files (not buffers) recently used. It is
especially
useful in switching between serveral frequently accessed
directories (even between
vim sessions). Combined with current lookupfile, user can locate
file even more
effeciently.
Problems find today
- When path is very long (exceed screen width), find
directory-content-window's filelist is messed up
- Input wrong path, RETURN, find input focus is automatically move to
the line beginning. It's more desirable that the input focus remain at
line end to facilitate user correct the last path segment
- Input wrong path, RETURN, move to line end and delete the last path
segment, input correct path segment keyword, find popup-match-window
not showup
- Input wrong path, RETURN, move to line end and delete the last path
segment, input intact correct path segment (not path keyword), RETURN,
find an empty buffer opened (instead of popup
directory-content-window)
- Sometimes, the following error msg popup serveral times when open
file thru lookupfile (after that file is opened successfully). The
problem can't be reproduced everytime (and can't find out how to
reproduce it)
Error detected while processing function
SNR74_AcceptFile..SNR33_IdoAccept..lookupfile#AcceptFile:
line15:
E121: Undefined variable: g:LookupFile_LookupNotifyFunc
My vimrc configuration is
command! WalkCur :exec LUWalk expand('%:p:h').'/'
nmap unique silent w :WalkCurCR
nmap unique silent b :LUBufsCR
let g:LookupFile_PreserveLastPattern=0
let g:LookupFile_AlwaysAcceptFirst=1
let g:LookupFile_FileFilter =
'\.class$\|\.o$\|\.obj$\|\.exe$\|\.jar$\|\.zip$\|\.war$\|\.tgz$\|\.ear$'
Thanks
Eddy
2006/8/14, Hari Krishna Dara [EMAIL PROTECTED]:
On Sun, 13 Aug 2006 at 11:42pm, Eddy Zhao wrote:
Hi Hari:
I tested the new plugin, most new features works as expected. Some
problems found,
see comments below:
- Backspace will delete the whole path, it's better it delete the
directory path
back only to the previous path delimiter
- Press TAB, delete path to parent directory, find
directory-content-window doesn't popup (it
might because path delimiter is \, not /, it's better to popup
all files in the
parent directory at that time)
Both of these are related/same, I am not going to support \ as path
separator, since it also needs to be supported to protect meta
characters. This also reduces confusion and complexity. Just use
forward-slash consistently in both windows and unix.
I don't see ido.el recognizing \ either, at least with the default
configuration.
- Press TAB, delete path to parent directory, press TAB, find TAB is
inserted as TAB character.
It's better to universally use TAB as
directory-content-display-command in lookup window, and
never insert it as TAB character
Tab in ido.el results in showing the mini buffer (the one with the full
matches). We don't have that problem here, as the matches are not
limited by screen real estate. I don't actually see a need to press
Tab, unless you are habitual, in which case you can map it yourself in
your ftplugin to whatever you want.
- Press TAB, delete path to parent directory, enter filename keyword,
find file-match-window
doesn't popup (it might because path delimiter is \, not /)
This is same as the first two. Try changing the \ to / immediately
and see if the popup comes up with any matches.
- Press TAB, C-b, find a lot of error message
I can't reproduce this problem, though I see an issue with C-B when
there is no token typed yet (only path), which I Will fix. Can you give
me reproducible steps, and also copy the error messages and send them?
- Press TAB, Esc Esc, LUBufs, find lookup window contain previous path info
The previous pattern is shared for all modes. If you want to always
start empty, use :LUBufs!. You can create a custom command for this, and
use that instead of remembering to suffix with bang.
Some more features seems to be useful
- TAB could also used to show all buffers at LUBufs window
It is not possible to show matches without having anything typed (a
limitation of Vim popup completion). You can press a single . to match
with all the buffer names (the match is done using Vim regex).
- There's a plugin called MRU.vim, it saves files most recently used
in file named _vim_mru_files.
I use this plugin extensively. May be lookupfile could also make
use of it, and to provide a
consistent file locating frontend for directoryfile, mrufile, buffer.
I am not going to promise any support for this soon. I don't use this
plugin as I use my selectbuf
Re: fast file locating plugin (like ido.el in emacs)
Hi Hari: I tested the new plugin, most new features works as expected. Some problems found, see comments below: - Backspace will delete the whole path, it's better it delete the directory path back only to the previous path delimiter - Press TAB, delete path to parent directory, find directory-content-window doesn't popup (it might because path delimiter is \, not /, it's better to popup all files in the parent directory at that time) - Press TAB, delete path to parent directory, press TAB, find TAB is inserted as TAB character. It's better to universally use TAB as directory-content-display-command in lookup window, and never insert it as TAB character - Press TAB, delete path to parent directory, enter filename keyword, find file-match-window doesn't popup (it might because path delimiter is \, not /) - Press TAB, C-b, find a lot of error message - Press TAB, Esc Esc, LUBufs, find lookup window contain previous path info Some more features seems to be useful - TAB could also used to show all buffers at LUBufs window - There's a plugin called MRU.vim, it saves files most recently used in file named _vim_mru_files. I use this plugin extensively. May be lookupfile could also make use of it, and to provide a consistent file locating frontend for directoryfile, mrufile, buffer. Thanks for take time look into that Eddy 2006/8/13, Eddy Zhao [EMAIL PROTECTED]: Hi Hari, Sorry for the late response (been busy at some family stuff). I'll try the new version very soon and post the feedback. Thanks for you quick response and great work (being happily maintain my large wiki docbase using your lookupfile plugin now :) Thanks Eddy 2006/8/13, Hari Krishna Dara [EMAIL PROTECTED]: Give the new version a try, I uploaded it to the below URL: http://haridara.googlepages.com/lookupfile.zip Here are the improvements for LUWalk command: - g:LookupFile_AlwaysAcceptFirst setting to always accept the first entry (set it to 1, the default is 0). - g:LookupFile_FileFilter to specify a filter. Ex: let g:LookupFile_FileFilter = '\.o$\|\.so$\|\.exe$' - LUWalk command accepts the initial directory as argument. This provides a number of possibilities to create your own custom commands (see |lookupfile-tips| for some examples). - Pressing Tab first time, fills up the directory of the current buffer. - You can now use BS to remove the entire directory component at a time. This applies to insert mode only. - Pressing CR on directory works as expected. Instead of opening the directory, it now selects it, and updates the matches for that directory, so navigation is much faster when you get unique matches. - You can also press C-F and C-B to switch between file and buffer modes. - The g:LookupFile_MinPatLength is automatically set to 0 (this really makes sense only for tag lookup and 'path' search). - Enclose matching pattern in []. - You can now create ftplugin/lookupfile.vim, and put commands such as: nnoremap buffer EscEsc C-Wq inoremap buffer EscEsc EscC-Wq Regarding your below points: - prefix filename with (or something else) will searching file recursively in the current directory It is already possible by specifying ** as a path component. Try it out. - order matching files by mru first, file already visible in the frame at end (ido feature) I don't see any specific order while using ido, and this makes sense only while showing the buffer list. I already have a TODO to support other types of sorting, so I am not going to do this for now, and I think this is not that big of a deal for its usability. Also go through the help file, it has a number of tips and other useful information to customize and extend without much effort. Please send me your feedback. -- Thanks, Hari On Fri, 11 Aug 2006 at 2:33pm, Hari Krishna Dara wrote: On Fri, 11 Aug 2006 at 1:31pm, Eddy Zhao wrote: Hi Hari: I tried the new plugin. Excellent! Exactly what I want. There are several missing features I think could make lookupfile even more effecient useful. Can you evaluate these features also ? - include opened buffer as matching target (ido feature) The LUBuf command already does this. Is this not good enough for you? The ido feature doesn't seem to restrict the list to any directory, so I think LUBuf is what you want. (Did you actually read through the help file?) You can switch from one mode to another (LUBufs to LUWalk) by creating separate mappings. I will add support for defining lookupfile ftplugins so that you can create such custom mappings to your liking. - order matching files by mru first, file already visible in the frame at end (ido feature) This requires some work, but can be done. I will most probably take advantage of one of my other plugins that maintain and expose MRU list (SelectBuf), to reduce work and duplication. This means you will need
Re: fast file locating plugin (like ido.el in emacs)
Hi Hari: I detailed compared ido.el and lookupfile.vim today, below are some of the ido features that I personally think more convenient than the current lookupfile plugin: - Ido don't need user to generate update tagfile (and don't have things like LookupFile_MinPatLength and performance balance) - Ido can locate file by keyword (not regexp). For Example user only need to input keyword c to locate file my_ from file my_, my_, my_ in the current directory. User don't need to locate file by regexp everytime (though ido DO support regexp based locating, I find myself almost never used that feature. User's file locating pattern is more keyword based, NOT regexp based !!). - Ido will automatically complete the filename under the current input focus while user is inputing keyword, and at the same time it will show other candidate filename list that match the keyword. These two features have a lot of advantages: * User can more quickly detect that the target file is already located using the current keyword subset * User can more quickly detect that no file will be located using the current keyword subset (and further-keyword-based-on-that-subset) * User don't need to press TAB to check the matched filenames, all happened automatically - Ido can locate file in any directory (not only file in the current directory, user only need to prefix directory path, and directory patch could be completed by TAB) - Ido can highlight the keyword in the matched filenames The above features make ido very effecient, could lookupfile be modified to achieve the same effect? I think lookupfile is a very important plugin that could affect the whole vim community's editing effeciency. If you want to know anything more about ido's feature, pls let me know, I'll investigate and feedback. And I strongly recommend you to try ido once. Thanks for look into that Eddy 2006/8/10, Hari Krishna Dara [EMAIL PROTECTED]: On Wed, 9 Aug 2006 at 10:49pm, Yakov Lerner wrote: On 8/9/06, Hari Krishna Dara [EMAIL PROTECTED] wrote: I am not completely clear on your question. You can always generate a single tag file which includes all the directories that you would visit. Normally, for development branches, this is easy as you can generate the tag file right at the root of the branch, including everything under it. If your usage scenario is such that the directories that you visit are scattered all over the filesystem, then you should still be able to create a command that will build a central tag file for all these directories. The sample find command given can be extended for this case, as the find manual suggests that you can have multiple paths. Create a script and have it run on demand or through a scheduler. Hari, This is certain burden that you place on the users. I'd prefer that you had a hotkey such that when you press it at the script prompt, script would automatically runs 'find' from the current dir to refresh the filelist. And if dirlist for current dir does not exist, that it create it automatically on the first invocation. Yes I am spoiled kid Yakov Building filelist for large directories takes significant time (especially on windows, as cygwin find is slow), so running the command outside in a separate window is preferale, and the script doesn't need to bother about platform/shell specific issues (like what if cygwin is not installed?). The plugin is written to be independent of any external tools, and it uses well known file format (tags) to index filenames. How you build the index is complete independent, and there is no generic tool to support it (like ctags). You don't need to even use find to build this index. Also, all my scripts that refresh tag files (and even ID database) do the below trick: command tags.new mv tags.new tags The advantage is that while the command is taking a long time to run, I can continue to work with the old tags file. This flexibility is lost if your vim session is typed up while the plugin is rebuilding the file. I don't understand the advantage of having a separate filelist for each directory (this means, you have to change Lookupfile_TagExpr such that it looks only into the current directory). I very often move around in the filesytem (which is why I created PushPop.vim plugin), so the current directory is kind of relatively insignificant. Isn't it preferable to have a single list at the root level, though it means building the list takes longer (but how often do you have the list changing anyway)? What if you cd into a directory, whose one of the parents already has the filelist built? Do you still want to build it? I guess a usage scenario will help me understand the usefulness of this. It will also help if someone can explain how the emacs tool behaves in this regard. Does it use a file index and if so how does it build? If not file indexing is involved, how does
changed-yet-not-saved-lines highlighting feature
Hi, Very often, I open a lot of files to edit. When I exiting vim, vim prompt me to save every file which contain changes not saved yet. So, - Is there plugin that could highlight the changed-yet-not-saved-lines (possibly with yellow background), so that I could easily locate and check those changes and decide whether to save it or not. - Furthermore, is there plugin that could highlight the changed-and-saved-lines in a vim session in the file (possibly with green background), so that I could easily audit all changes of a file in a vim edit session. BTW, this feature is borrowed from a commercial editor I tried sometime ago, and find very useful when editing a lot of source code files. Thanks Eddy
Re: fast file locating plugin (like ido.el in emacs)
Hi Hari: I tried the new plugin. Excellent! Exactly what I want. There are several missing features I think could make lookupfile even more effecient useful. Can you evaluate these features also ? - include opened buffer as matching target (ido feature) - order matching files by mru first, file already visible in the frame at end (ido feature) - one enter keystroke will open the first matching file in the matching list (this scenario happens frequently, ido feature) - backspace will delete the directory path back to previous path delimiter (filename is still deleted char-by-char, ido feature) - default searching directory is based on file most recently used - open the lookup window and pressing tab (no keyword is entered yet) will display files in the current directory (and buffers currrently opened) - double ESC could close the lookup window - prefix filename with (or something else) will searching file recursively in the current directory - provide option to filter out some of the files when matching (eg. *.o, *.so ... ) - using [] instead of ** to enclose pattern in the matched filename Thanks for looking into this Eddy 2006/8/11, Hari Krishna Dara [EMAIL PROTECTED]: I had some trouble but I was able to try ido.el. At first, emacs that came with cygwin didn't start at all, even when I had X running, so I downloaded it separately from gnu.org. I installed ido.el directly under lisp directory, as I don't know how to put it in a user directory. Next I had trouble understanding how to invoke it. Once I figured out that I need to use M-x, I was able to try it. See below for my response. On Thu, 10 Aug 2006 at 10:38pm, Eddy Zhao wrote: Hi Hari: I detailed compared ido.el and lookupfile.vim today, below are some of the ido features that I personally think more convenient than the current lookupfile plugin: - Ido don't need user to generate update tagfile (and don't have things like LookupFile_MinPatLength and performance balance) As I explained before, the basic lookup mode is designed to be a lookup in a full index. However, the plugin comes with a few other means to lookup, and a generic extension mechanism to add more means. The version I attached with my previous email includes a new mode which works similar to ido.el. - Ido can locate file by keyword (not regexp). For Example user only need to input keyword c to locate file my_ from file my_, my_, my_ in the current directory. User don't need to locate file by regexp everytime (though ido DO support regexp based locating, I find myself almost never used that feature. User's file locating pattern is more keyword based, NOT regexp based !!). This is totally in the control of the new function that I added (see below for an improved version), and I think it already behaves this way. It may interpret some characters as filename-wildcards, as recognized by glob(), so we might need to protect them (but there are not many of them). - Ido will automatically complete the filename under the current input focus while user is inputing keyword, and at the same time it will show other candidate filename list that match the keyword. These two features have a lot of advantages: * User can more quickly detect that the target file is already located using the current keyword subset * User can more quickly detect that no file will be located using the current keyword subset (and further-keyword-based-on-that-subset) * User don't need to press TAB to check the matched filenames, all happened automatically I think all this is covered. - Ido can locate file in any directory (not only file in the current directory, user only need to prefix directory path, and directory patch could be completed by TAB) Covered as well. - Ido can highlight the keyword in the matched filenames This can't be done, as I am using the Vim7 completion popup, and it doesn't support highlighting. However, I worked around by wrapping the pattern with asterisks (in the new function below), so it kind of works, though not that easy to read. The above features make ido very effecient, could lookupfile be modified to achieve the same effect? I think lookupfile is a very important plugin that could affect the whole vim community's editing effeciency. If you want to know anything more about ido's feature, pls let me know, I'll investigate and feedback. And I strongly recommend you to try ido once. Thanks for look into that Eddy Replace the s:LookupWalk function in the plugin/lookupfile.vim with the one below and try it out. Let me know if this meets your needs. If you read a bit about Vim scripting basics, you can start playing around with this function to make the matches look better (e.g, if '/' should be separate or as part of 'abbr'). See help on |complete-items| on how the map works. function! s:LookupWalk(pattern
Re: have to switch back and forth between different language input method problem
Tried, exactly what I want, fantastic! Thanks Tony! Eddy 2006/8/9, A.J.Mechelynck [EMAIL PROTECTED]: Eddy Zhao wrote: Hi, Very often, I write file in vim using my native language (not english), Problem occurs like this - edit file in insert mode using my native language input method - Esc - using Ctrl-space to change to english input method (*) - hjkl - i - using Ctrl-space to revert back to my native language input method (*) So, every time I switch between insert mode and normal mode (eg. when moving edit point or issue edit command), I always have to change back and forth between differnet language input method, which is really a big burden. So - Is there a way to automaticlly change the input method to english input method , when Esc - Further, is there a way to automatically change back to the original input method, after return back to insert mode (from normal mode) Thanks Eddy For Windows, see help mbyte-IME. For X11, see help mbyte-XIM The status of the IM is remembered in option 'iminsert' when switching between Normal and Insert/Replace modes (0 = type ASCII, 2 = use IM). You need (see output of :version): - not console Vim, but a GUI version, and run as gvim, not in an xterm - for Windows, compiled with +multi_byte_ime or +multi_byte_ime/dyn - for X11, compiled with +xim - for full control of the XIM under X11, it must be a GTK (or GTK2) GUI. Best regards, Tony.
fast file locating plugin (like ido.el in emacs)
Hi,
Does anyone ever used ido.el in emacs? (www.cua.dk/ido.el)
The plugin could considerably speedup file accessing performance,
especially when I'm maintaining a large wiki docbase. So I really
want to know
- if vim have equivalent plugin like ido.el
- if not, is there any simple way to achieve the same effect in
vim? (don't want to explicitly edit directory and locate file)
Thanks
Eddy
BTW, for those who never used ido.el. Below is the description of its
functionality
snipped from ido.el
;; Substring matching (The default method)
;;
;; As you type in a substring, the list of buffers or files currently
;; matching the substring are displayed as you type. The list is
;; ordered so that the most recent buffers or files visited come at
;; the start of the list.
;; The buffer or file at the start of the list will be the one visited
;; when you press return. By typing more of the substring, the list is
;; narrowed down so that gradually the buffer or file you want will be
;; at the top of the list.
;;
;; If I have two buffers called 123456 and 123, with 123456 the
;; most recent, when I use ido-switch-buffer, I first of all get
;; presented with the list of all the buffers
;;
;; Buffer: {123456,123}
;;
;; If I then press 2:
;; Buffer: 2[3]{123456,123}
;;
;; The list in {} are the matching buffers, most recent first (buffers
;; visible in the current frame are put at the end of the list by
;; default). At any time I can select the item at the head of the
;; list by pressing RET. I can also bring the put the first element
;; at the end of the list by pressing C-s or [right], or put the last
;; element at the head of the list by pressing C-r or [left].
;; The item in [] indicates what can be added to my input by pressing TAB.
;; In this case, I will get 3 added to my input. So, press TAB:
;; Buffer: 23{123456,123}
;;
;; At this point, I still have two matching buffers.
;; If I want the first buffer in the list, I simply press RET. If I
;; wanted the second in the list, I could press C-s to move it to the
;; top of the list and then RET to select it.
;;
;; However, If I type 4, I only have one match left:
;; Buffer: 234[123456] [Matched]
;;
;; Since there is only one matching buffer left, it is given in [] and we
;; see the text [Matched] afterwards. I can now press TAB or RET to go
;; to that buffer.
vtreeexplorer problem
Hi, I'm trying vtreeexplorer plugin, it works great. But one problem prevents me adopting it as the replacement for explorer plugin. The problem looks like below - cut a line from file_a - open vtreeexplorer - open file_b from vtreeexplorer - paste the line cut before, but find the line pasted is not the line from file_a (but something from vtreeexplorer's treeview) Does anyone know how to solve the problem ? Thanks Eddy
Re: fast file locating plugin (like ido.el in emacs)
Hi Yakov, Thanks for the prompt help. I tried the lookupfile plugin, looks great at first glance, can you throw light on the below problems I encountered - do I always have to generate tagfile for every directory i visited? if so, I feel its a big burden that prevent me using the plugin frequently and globally. is there any way to eliminate this burden? - It seems that I can't locate file named aaabbb thru directly typing bbb, do I always have to locate file begin with the first letter of the filename? Thanks Eddy 2006/8/8, Yakov Lerner [EMAIL PROTECTED]: On 8/8/06, Eddy Zhao [EMAIL PROTECTED] wrote: Hi, Does anyone ever used ido.el in emacs? (www.cua.dk/ido.el) The plugin could considerably speedup file accessing performance, especially when I'm maintaining a large wiki docbase. So I really want to know - if vim have equivalent plugin like ido.el This question was raised on the list ~1/2 years ago, and Hari created the file-selection plugin in response: http://www.vim.org/scripts/script.php?script_id=1581 lookupfile : Lookup files using filename completion There are several plugins dealing with recently-used files, on vim.org. Vim mappings and functions can be used to open often-used files quickly. gf command is helpful, too. NB that vim has built-in recursive filename completion (**/xyztab) as well as simple filename completion (tab). Yakov
have to switch back and forth between different language input method problem
Hi, Very often, I write file in vim using my native language (not english), Problem occurs like this - edit file in insert mode using my native language input method - Esc - using Ctrl-space to change to english input method (*) - hjkl - i - using Ctrl-space to revert back to my native language input method (*) So, every time I switch between insert mode and normal mode (eg. when moving edit point or issue edit command), I always have to change back and forth between differnet language input method, which is really a big burden. So - Is there a way to automaticlly change the input method to english input method , when Esc - Further, is there a way to automatically change back to the original input method, after return back to insert mode (from normal mode) Thanks Eddy
How to permanently save the buffer without accidentally undo the change ?
At some point, I want to permanently save the buffer with out the possibility of accidentally undo the changes I've made (this happens sometimes). How can I clear the undo stack (without leaving the current buffer). Or any other simpler way of achieving this? Thanks Eddy
Using minibufexpl delete last buffer not take effect !
I'm using minibufexpl.vim 6.3.2. The configuration like below let g:miniBufExplorerMoreThanOne=0 When I - open only one file - move cursor to minibufexpl - use 'd' to close that file buffer Problem happens - minibufexpl window disappears (which should be persistent on) - the file buffer not closed (which should be closed) Can anyone throw light on how to fix the above two problems in minibufexpl.vim? Thanks Eddy
Re: How to permanently save the buffer without accidentally undo the change ?
Great tip and super fast reply ! : ) Thanks Bryce 2006/4/30, Bryce Wagner [EMAIL PROTECTED]: Eddy Zhao wrote: At some point, I want to permanently save the buffer with out the possibility of accidentally undo the changes I've made (this happens sometimes). How can I clear the undo stack (without leaving the current buffer). Or any other simpler way of achieving this? Thanks Eddy After you save the file, type :e This will reopen the current file for editing. -Bryce
Re: How to permanently save the buffer without accidentally undo the change ?
Yakov I've tried similar way before. It works, but the window flashes when I'm saving (because the buffer switches between dummy and this) which is not very decent. :wCR:eCR works simple and great ! Thanks Eddy 2006/4/30, Yakov Lerner [EMAIL PROTECTED]: On 4/30/06, Eddy Zhao [EMAIL PROTECTED] wrote: At some point, I want to permanently save the buffer with out the possibility of accidentally undo the changes I've made (this happens sometimes). How can I clear the undo stack (without leaving the current buffer). Or any other simpler way of achieving this? I believe this sequence clears undo stack: :up! | set nohidden | e dummy | bw It might be useful add save/restore of 'hidden' option: :up! | let x=hidden | set nohid | e dummy |bw | let hidden=x If you want to map it , remember to change | to bar map f9 :up! bar ...etc Yakov
