Re: failure notice
Hi vimmers, Sorry for sending this mail for the second time because my previous mail with attachment was rejected by the mail daemon. :-( On 8/11/06, Bram Moolenaar [EMAIL PROTECTED] wrote: [...] The menu.vim file should never change 'encoding'. It should load menus that are appropriate for the current 'encoding' and language. But gvim doesn't support an encoding named 'gbk'. If the system encoding is 'gbk', the menu and toolbar get malformed. In the past two years (or more), all gvim users in mainland China should add the following two lines in their .vimrc if they are using Linux with GBK encoding: set enc=cp936 so $VIMRUNTIME/delmenu.vim so $VIMRUNTIME/menu.vim That's why I had wanted to change the encoding value in menu.vim. :-) If the intention is to have the default for 'encoding' use something specific in $LANG then this must be done in enc_locale() in src/mbyte.c I modified mbyte.c, added gbk as an alias of cp936, then the menubar was displayed properly with the unmodified menu.vim. But there is still some problem with the toolbar - every last character of the tooltip becomes two question marks. I'm trying to debug the code and will send you another patch as soon as I solve the problem. Hope you can offer me some hints, too. :-) [...] Regards, Edward L. Fox
can we set vim to use magic=very ??
all, rtfm didn't help ... I'd like to *always* make my regexes behave like perl, but I find no way to set it as a default. will I have to always use \v ?? I tend to think that if I can't get vim to do something it's because I don't know why, not because it is not possible ... so how do I do this? cheers, martin begin:vcard fn:Martin Kraegeloh n:Kraegeloh;Martin adr:;;Am Alten Pfarrhof 24;Oberbergkirchen;;84564;Germany email;internet:[EMAIL PROTECTED] tel;work:+49 8637 985806 tel;cell:+49 160 98943453 x-mozilla-html:FALSE version:2.1 end:vcard smime.p7s Description: S/MIME Cryptographic Signature
Re: Tips for advance use of Vim
On Thu, Aug 10, 2006 at 10:22:11AM +0800, Vincent Wang wrote:
Good idea and I am sure it will help many persons!
One suggestion, why not put your tips to www.vim.org's tips page and
post a notification in this maillist? That will make your tip well
archived and easier to reach.
This tip had a specific topic (Workspace efficiency)
This leads me to another idea:
Why not use some kind of wiki where we can write down many tips sorted
by topic? Eg the wiki might have an index like this and much more content..
Working with vim efficiently
oppening/saving files
don't losse time creating directoryies, let vim create them
for you!
augroup BufWritePre
autocmd BufWritePre * if !isdirectory(expand('%:h'))|
mkdir(expand('%:h'),'p') | endif
augroup end
You accidently edited a file on disk and in vim? No problem:
diff them:
fun! DiffWithFileFromDisk()
let filename=expand('%')
let diffname = filename.'.fileFromBuffer'
exec 'saveas! '.diffname
diffthis
vsplit
exec 'edit '.filename
diffthis
endfun
managing windows
Insert Code Snippets
moving curosr
(there is - and cr why not introduce your own mappings
for k$ or j$? map s-cr esco is realy useful,...)
(do a fast mappnig eg c-s-w :windcmd w and use
numberc-s-w to go to the next window, you'll need
oonly 2 keys most of the time!)
editing text
searching in text
( pipe to | g -
and use a mapping like this
filter lines
noremap m-fm-l :exec 'g!/'.input(filter expr
:).'/d'cr
drop lines
noremap m-dm-l :exec 'g/'.input(filter expr
:).'/d'cr
Now you can see all matches at one glance instead of
pressing n n over and over again..
)
Have you ever wondered wether it's faster to use jkeep
pressnig this key or use 5j?
reduce the repetition and hold time of your keyboard and j
will be fastter ;)
file-type plugins
use an autocommand like this to automatically resource it:
augroup reloadftplugins
au BufWritePost ~/.vim/ftplugin/*.vim bufdo let ft=ft
augroup end
use a shortcut like this to open the ftplugin file directly (mw
is my shortcut so I can insttall different plugins easily)
map m-s-fm-s-tm-s-p :exec 'e
~/.vim/ftplugin/'.filetype.'_mw.vim'cr
Tips for working with
xml (content eg xmllint, completion, dtd - there was another
nice tutorial somewhere)
C (tags, templates, .., quickfix)
bash/sh
vimhelp
vimscripting:
... It would be nice to create a collection of useful
functions...
fun! IfConfirm(confirm_requirement, message, cmd)
if a:confirm_requirement
if !input(a:message.' [y/sth. else]')=='y'
return
endif
endif
exec a:cmd
endfun
just use exec DontLoadTwice(scriptname) to not load the
script twice
fun! DontLoadTwice(name)
let cmd = if exists('.a:name.') | finish| let
g:.a:name.=1|endif
endfun
some kind of ? operator (then_v and else_v will be
evaluated!)
function! If(condition, then_v, else_v)
if a:condition
exec a:then_v
else
exec a:else_v
endif
endfunction
usage:
let a=If(condition,thenvalue,elsevalue)
If you think functions like this make your code harder to read
I'd suggest running exuberant-ctags in.vim and using tags or
the excellent
wherefrom plugin
Why this? It's said that the tim you need to write a program is
proportional to the number of lines you need if you are
familiar enough with
the languge + libs
I don't think this should replace vim.org but it might link to the tips/
scripts there
Benefits: Its easier to keep it up to date (on vim.org you'll get
still outdated matches..
Would http://www.vi-improved.org/wiki/ be a good place?
I've some ideas and scripts I want to share..
some are so small that
Re: can we set vim to use magic=very ??
martin kraegeloh wrote: all, rtfm didn't help ... I'd like to *always* make my regexes behave like perl, but I find no way to set it as a default. will I have to always use \v ?? I tend to think that if I can't get vim to do something it's because I don't know why, not because it is not possible ... so how do I do this? cheers, martin Only thing I can see is :map / /\\v :map ? ?\\v but that wouldn't solve the case of ex-commands (:s, :helpgrep, :vimgrep, etc.) which accept a pattern. Or else (but I don't recommend it) find where patterns are handled in the C code and hack the source. Best regards, Tony.
Patch (Unofficial): Malformed characters in menu and toolbar when using zh_CN.GBK encoding under Linux
Patch Unofficial Problem:Menu and toolbar: Doesn't display properly when using zh_CN.GBK encoding under Linux. Solution: Use gb2312 to generate the menu and toolbar to get proper display, then use cp936 instead of GBK which is a correct alias under Linux. Files: runtime/menu.vim *** runtime/menu.vim 2006-04-18 06:06:31.0 +0800 --- ../vim7.my/runtime/menu.vim2006-08-09 16:21:03.0 +0800 *** *** 48,53 --- 48,56 same menu file for them. let s:lang = substitute(s:lang, 'iso_8859-15\=$', latin1, ) menutrans clear + if s:lang == zh_cn.gbk || s:lang == zh_cn.gb18030 + set enc=gb2312 + endif exe runtime! lang/menu_ . s:lang . .vim if !exists(did_menu_trans) *** *** 1094,1097 --- 1097,1104 let cpo = s:cpo_save unlet s:cpo_save + if s:lang == zh_cn.gbk || s:lang == zh_cn.gb18030 + set enc=cp936 + endif + vim: set sw=2 :
Re: can we set vim to use magic=very ??
Hi Martin, Unfortunately, I don't think there's any way to use \v by default for every pattern. It may help to remember that when you have the default 'magic' option set, Vim only recognizes 5 special characters without backslash: ^ $ . * [ (if there is a matching ] to make a collection) Every other special sequence needs a '\'. regards, Peter martin kraegeloh wrote: all, rtfm didn't help ... I'd like to *always* make my regexes behave like perl, but I find no way to set it as a default. will I have to always use \v ?? I tend to think that if I can't get vim to do something it's because I don't know why, not because it is not possible ... so how do I do this? cheers, martin Send instant messages to your online friends http://au.messenger.yahoo.com
[RFC] fising f-args bug wrt '\\ '
I am about to fix the f-args bug that is mentioned in the todo.
There is one remaining ambiguity on which I need to consut the
community. The testcase that illustrates the bug is at the end.
First, about the bug that needs to be fixed. It is in handling of \\ when
\\ precedes th whitespace. I was bitten by this bug myself.
Sequence '\ ' is currently [correctly] treated as whitespace that's
embedded in the whitespace. Sequence '\\ ' is [incorrectly] treated
as '\ ' embedded into argument. It shall be treated as '\' then
argument break. (Current incorrect treatment does now allow to
have an argument consisting of single \, or of argument ending
with \).
There is one remaining ambiguity on which I need to consut the
community. It is how to treat \\ (when \\ is not preceding the whitespace).
One possibility is to treat \\ as \\. Second possibility is to treat
\\ as \. I am inclined to first (\\-\\), because (a) it is backward-compatible
and (b) it seems less surprising when \\ is embedded into arguments
containing regular expressions and the like.
What are your opinions on expanding \\ as \\ vs \ in f-args ?
Yakov
--
XX \\ works, 2 args ('\\')
XX a bworks, 2 args ('a','b')
XX a\ b works, 1 arg ('a b')
XX a\\b 1 arg ('a\\b') Shall it be 1 arg('a\b') ?
XX a\\ b bug: 1 arg('a\ b') Expected 2 args('a\','b')
XX a\\ b bug: 2 args ('a\ ','b'). Expected 2 args('a\','b')
command! -nargs=* XX :call Test(f-args)
fun! Test(...)
echo XX: .a:0. args(
let i=1
let argc=a:0
while i = a:0
echon '.a:{i}.'
if i != a:0 | echon , | endif
let i = i + 1
endwhile
echon )
endfun
Re: Re[2]: filename completion and filereadable
On Wed, 9 Aug 2006 23:03:12 -0400, Alan G Isaac [EMAIL PROTECTED] wrote: On Thu, 10 Aug 2006, A.J.Mechelynck apparently wrote: What is the raw string notation from Python ? IMHO it would only create one additional type of string. We already have single-quoted 'raw' strings in Vim, yet many people constantly forget that double-quoted strings in Vim are cooked. Yes, that is my point: Many people forget the difference between single and double quoted strings. Indeed when reading vimscript the difference is not immediately obvious (easily forgettable), which is unfortunate. Taking the Python approach that values explicitness, http://docs.python.org/ref/strings.html a raw string can be created r'like this' or rlike this. But ... versus '...' is just as explicit. It's also something shared by every Unix shell I've used, along with quite a few other languages such as Perl. In fact, apart from Python and XML I can't think of any languages that don't make a distinction between double and single quotes, as it's an extremely useful difference and it's a waste of a limited character set to ignore it. -- Matthew Winn
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
Re: filename completion and filereadable
Hi Am 10.08.2006 16:02:54 schrieb Alan G Isaac: On Thu, 10 Aug 2006, Matthew Winn apparently wrote: But ... versus '...' is just as explicit. Ah, that explains why the question keeps coming up on this list and never in a Python forum ... Or not? In fact, apart from Python and XML I can't think of any languages that don't make a distinction between double and single quotes, as it's an extremely useful difference and it's a waste of a limited character set to ignore it. Hmm, I guess you 'never need' nested quotes? As an additional note not especially related to ViM - with '...' and ... you have 2 kind of strings. But how do you express unicode-strings? Use `...` or something like that? And what happens, when in the future there will be a 4. string-type? With the syntax of python that's no problem. cu boesi -- A Achkatz'l ofm Baam des hot a schins Laam braucht keen Pfenng Gald un freit sich of dr Walt
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: changed-yet-not-saved-lines highlighting feature
On 8/10/06, Eddy Zhao [EMAIL PROTECTED] wrote: 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. You can invoke vimdff to see differences. That requires temp copying: 1. :!cp % %.orig :diffsplit %.orig or :vert diffsplit %.orig It would be more convenient if :vimslpit allowed diff of the current buffer with original file on disk directly, but as far as I can see it doesn't allow it, you need to copy the file. It's not that bad, can be assigned to a macro: :nmap F5 :!cp % %.origcr:vert diffsplit %.origcr 2. :w! %.tmp and invoke 'vimdiff file file.tmp' in the other window 3. Less sophisticated method of revewing the changes: :w !diff -u - % (NB you must have space between 'w' and '!'). It does not highlight any lines but it's simple an it let you review your changes. Yakov
Re: can we set vim to use magic=very ??
martin kraegeloh wrote: rtfm didn't help ... I'd like to *always* make my regexes behave like perl, but I find no way to set it as a default. will I have to always use \v ?? I tend to think that if I can't get vim to do something it's because I don't know why, not because it is not possible ... so how do I do this? Do you happen to use any plugins? This sort of thing would likely break any that use search, etc - ie. a lot of them. Regards, Chip Campbell
Show/Hide Split Windows
Hi all, The ability to split windows is an absolute essential; however, there are times when I want to focus on one buffer in one window and hide all of the other windows. But, I don't know of any show/hide feature that hides all windows but the current window. As a workaround, I resize all of the windows to give maximum space to the window I want to see, but this then makes me resize all of the windows again when I want to restore the windows. So, by any chance, is this a feature that is already implemented and I don't know of it? Or, can it be put on a wishlist? If so, here's how I imagine it could work: Some keystroke does the toggle for show/hide inactive windows (non-current windows). Also, a statusline entry is available that can be used as a visible reminder that the inactive windows are hidden. Feedback? Thanks, Steve Amerige Adobe Systems Incorporated
delete lines
Hey everyone,
Is there a way to make it so that when I am editing something like this:
function foo() {
$blah;
$blah2;
}
And then I decide that I want to remove $blah2, so I start to press
backspace from here:
fucntion foo() {
$blah;
$blah2; - cursor here
}
and then when I get to the beginning of the line, it stops. Can I make
it so that it will follow up to the end of $blah on the previous line?
thanks!
Ben
Re: delete lines
And then I decide that I want to remove $blah2, so I start to press
backspace from here:
fucntion foo() {
$blah;
$blah2; - cursor here
}
and then when I get to the beginning of the line, it stops. Can I make
it so that it will follow up to the end of $blah on the previous line?
Sounds like you want to tweak your 'backspace' option.
:set backspace
should tell you what it currently is.
:help 'backspace'
should describe what's available in how backspace behaves with
regards to various conditions.
You likely want to have a line in your vimrc that looks something
like
set backspace=indent,eol,start
that will allow you to backspace over all three categories of
things that might not otherwise be backspace-over-able. :)
-tim
RE: delete lines
The problem is your setting of backspace. It sounds like currently bs is
equal to indent,start or something similar. You need
indent,start,eol. The easiest way to do this is simply put this in
your .vimrc file:
:set bs=2
That should do it!
Max
-Original Message-
From: Ben lemasurier [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 10, 2006 10:51 AM
To: vim@vim.org
Subject: delete lines
Hey everyone,
Is there a way to make it so that when I am editing something like
this:
function foo() {
$blah;
$blah2;
}
And then I decide that I want to remove $blah2, so I start to press
backspace from here:
fucntion foo() {
$blah;
$blah2; - cursor here
}
and then when I get to the beginning of the line, it stops. Can I make
it so that it will follow up to the end of $blah on the previous line?
thanks!
Ben
Re: delete lines
Today (Thu, 10 Aug 2006), Ben lemasurier wrote:
And then I decide that I want to remove $blah2, so I start to press
backspace from here:
fucntion foo() {
$blah;
$blah2; - cursor here
}
and then when I get to the beginning of the line, it stops. Can I
make it so that it will follow up to the end of $blah on the
previous line?
Try :set backspace+=eol -- see :help 'backspace'.
- Christian
--
They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety. -- Ben Franklin
Christian J. Robinson [EMAIL PROTECTED] http://infynity.spodzone.com/
PGP keys: 0x893B0EAF / 0xFB698360 http://infynity.spodzone.com/pgp
Re: Show/Hide Split Windows
Yes there is a way in Vim without additional plugins. Take a look at :help :mksession and :help :mkview The way I use it is to set up 3-4 open windows with the files I frequently visit. Then :mksession myview.vim Then when I want to go back to that configeration I use: :so myview.vim Kevin On Aug 10, 2006, at 1:44 PM, Steve Amerige wrote: Hi all, The ability to split windows is an absolute essential; however, there are times when I want to focus on one buffer in one window and hide all of the other windows. But, I don't know of any show/ hide feature that hides all windows but the current window. As a workaround, I resize all of the windows to give maximum space to the window I want to see, but this then makes me resize all of the windows again when I want to restore the windows. So, by any chance, is this a feature that is already implemented and I don't know of it? Or, can it be put on a wishlist? If so, here's how I imagine it could work: Some keystroke does the toggle for show/hide inactive windows (non- current windows). Also, a statusline entry is available that can be used as a visible reminder that the inactive windows are hidden. Feedback? Thanks, Steve Amerige Adobe Systems Incorporated
RE: Show/Hide Split Windows
I personally have never found the need to actually hide the other windows, but I do always keep the current window maximised. One way to do this is to set wh=10, but this kills the quickfix window. If you use the quickfix window a lot (that's the one which shows compile errors or grep results), then I have a little function that I use. It is hugely personalised and I am sure there are better ways to do it, but here it is for posterity, and perhaps you can modify it to do what you want: function! WinEnter() if (getwinvar(0, 'buftype')==quickfix) return endif let retcmd=winnr().wincmd w wincmd b if (getwinvar(0, 'buftype')==quickfix) cclose wincmd _ exec copen wincmd p let sizecmd=resize .winheight(0) exe retcmd exe sizecmd else exe retcmd wincmd _ endif endfunction au! WinEnter*call WinEnter() set wh=1 -Original Message- From: Steve Amerige [mailto:[EMAIL PROTECTED] Sent: Thursday, August 10, 2006 10:44 AM To: vim@vim.org Subject: Show/Hide Split Windows Hi all, The ability to split windows is an absolute essential; however, there are times when I want to focus on one buffer in one window and hide all of the other windows. But, I don't know of any show/hide feature that hides all windows but the current window. As a workaround, I resize all of the windows to give maximum space to the window I want to see, but this then makes me resize all of the windows again when I want to restore the windows. So, by any chance, is this a feature that is already implemented and I don't know of it? Or, can it be put on a wishlist? If so, here's how I imagine it could work: Some keystroke does the toggle for show/hide inactive windows (non-current windows). Also, a statusline entry is available that can be used as a visible reminder that the inactive windows are hidden. Feedback? Thanks, Steve Amerige Adobe Systems Incorporated
Re: delete lines
From: Christian J. Robinson [EMAIL PROTECTED]
Subject: Re: delete lines
Date: Thu, 10 Aug 2006 12:00:45 -0600 (MDT)
Hi,
Today (Thu, 10 Aug 2006), Ben lemasurier wrote:
And then I decide that I want to remove $blah2, so I start to press
backspace from here:
fucntion foo() {
$blah;
$blah2; - cursor here
}
and then when I get to the beginning of the line, it stops. Can I
make it so that it will follow up to the end of $blah on the
previous line?
Try :set backspace+=eol -- see :help 'backspace'.
- Christian
--
They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety. -- Ben Franklin
Christian J. Robinson [EMAIL PROTECTED] http://infynity.spodzone.com/
PGP keys: 0x893B0EAF / 0xFB698360 http://infynity.spodzone.com/pgp
is it also possible to enable the backspace key in normal mode --
the delete key is working in normal, so why should I miss the
backspace key ?
:)
mcc
Re: delete lines
is it also possible to enable the backspace key in normal mode -- the delete key is working in normal, so why should I miss the backspace key ? :nnoremap BS X (all typed literally with greater-than and less-than signs included) should do the trick. -tim
Re: Show/Hide Split Windows
Steve Amerige wrote: The ability to split windows is an absolute essential; however, there are times when I want to focus on one buffer in one window and hide all of the other windows. But, I don't know of any show/hide feature that hides all windows but the current window. As a workaround, I resize all of the windows to give maximum space to the window I want to see, but this then makes me resize all of the windows again when I want to restore the windows. So, by any chance, is this a feature that is already implemented and I don't know of it? Perhaps ZoomWin will do what you want... http://vim.sourceforge.net/scripts/script.php?script_id=508 Type ctrl-w o to toggle between maximizing one window and restoring to all. By maximizing, I mean that the current window will take over the entire display, not leaving a lot of status bars around. Regards, Chip Campbell
Re: filename completion and filereadable
Alan G Isaac wrote: On Thu, 10 Aug 2006, Matthew Winn apparently wrote: But ... versus '...' is just as explicit. Ah, that explains why the question keeps coming up on this list and never in a Python forum ... Or not? In fact, apart from Python and XML I can't think of any languages that don't make a distinction between double and single quotes, as it's an extremely useful difference and it's a waste of a limited character set to ignore it. Hmm, I guess you 'never need' nested quotes? In any case, I did not suggest changing the current quote behavior, just adding an additional syntax. Cheers, Alan Isaac No, in Vim v7, 'I don''t need nested quotes.' because a pair of single quotes within a single-quoted string means a single single-quote at that point in the resulting string. In pre-v7 Vim, I could have used string concatenation, which is less elegant, but works too. Best regards, Tony.
Re: Show/Hide Split Windows
On 8/10/06, Charles E Campbell Jr [EMAIL PROTECTED] wrote: Type ctrl-w o to toggle between maximizing one window and restoring to all. By maximizing, I mean that the current window will take over the entire display, not leaving a lot of status bars around. Actually, Ctrl-w o will close all other windows. You can't get back to them using Ctrl-w o again -- Rodolfo Borges
RE: Show/Hide Split Windows
He means when using the script that he wrote and which he was discussing in the same email, which remaps ctrl-w o to do something else. Max -Original Message- From: Rodolfo Borges [mailto:[EMAIL PROTECTED] Sent: Thursday, August 10, 2006 11:43 AM To: vim@vim.org Subject: Re: Show/Hide Split Windows On 8/10/06, Charles E Campbell Jr [EMAIL PROTECTED] wrote: Type ctrl-w o to toggle between maximizing one window and restoring to all. By maximizing, I mean that the current window will take over the entire display, not leaving a lot of status bars around. Actually, Ctrl-w o will close all other windows. You can't get back to them using Ctrl-w o again -- Rodolfo Borges
Re: changed-yet-not-saved-lines highlighting feature
On Thu, Aug 10, 2006 at 11:02:50PM +0800, Eddy Zhao wrote: 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. I would have proposed using the diff commands, too.. (See DiffWithFileOnDisk in my privious post.) Perhaps it would be better to save to tempname() because those files will be deleted automatically.. Another waay would be : do u until vim no longer shows the modified tag ;) u will also show you what you've done. Marc Weber
Re: can we set vim to use magic=very ??
Charles E Campbell Jr wrote: martin kraegeloh wrote: rtfm didn't help ... I'd like to *always* make my regexes behave like perl, but I find no way to set it as a default. will I have to always use \v ?? I tend to think that if I can't get vim to do something it's because I don't know why, not because it is not possible ... so how do I do this? Do you happen to use any plugins? This sort of thing would likely break any that use search, etc - ie. a lot of them. hmmm ... true. but wouldn't it be nice if vim eventually treated the quasi-standard as default? even java understands regexes in the meantime ;-) I personally find it hard to quote things to make them regain their special meaning. I would suggest that this be at least considered, and if vim switched the default behaviour the plugin authors would fix this once ... anyway, thanks for all responses, martin Regards, Chip Campbell begin:vcard fn:Martin Kraegeloh n:Kraegeloh;Martin adr:;;Am Alten Pfarrhof 24;Oberbergkirchen;;84564;Germany email;internet:[EMAIL PROTECTED] tel;work:+49 8637 985806 tel;cell:+49 160 98943453 x-mozilla-html:FALSE version:2.1 end:vcard smime.p7s Description: S/MIME Cryptographic Signature
Re: Show/Hide Split Windows
Hi Chip, Perhaps ZoomWin will do what you want... http://vim.sourceforge.net/scripts/script.php?script_id=508 Thank you for this... it's just what I was hoping for! And, thanks for the other responses. It shows how great Vim is! Enjoy, Steve Amerige Adobe Systems Incorporated
Re: Show/Hide Split Windows
On Thu, 10 Aug 2006 11:43:56 -0700 Max Dyckhoff [EMAIL PROTECTED] wrote: He means when using the script that he wrote and which he was discussing in the same email, which remaps ctrl-w o to do something else. and it works perfectly :-) Use it a lot here. -- Kim Schulz| Private : http://www.schulz.dk [EMAIL PROTECTED] | Business: http://www.devteam.dk +45 5190 4262 | Sparetime: http://www.fundanemt.com
Re: filename completion and filereadable
Alexander 'boesi' Bösecke wrote: Hi Am 10.08.2006 16:02:54 schrieb Alan G Isaac: On Thu, 10 Aug 2006, Matthew Winn apparently wrote: But ... versus '...' is just as explicit. Ah, that explains why the question keeps coming up on this list and never in a Python forum ... Or not? In fact, apart from Python and XML I can't think of any languages that don't make a distinction between double and single quotes, as it's an extremely useful difference and it's a waste of a limited character set to ignore it. Hmm, I guess you 'never need' nested quotes? As an additional note not especially related to ViM - with '...' and ... you have 2 kind of strings. But how do you express unicode-strings? Use `...` or something like that? And what happens, when in the future there will be a 4. string-type? With the syntax of python that's no problem. cu boesi What happens in the future when there's a 4th string type? The whole point of this argument is to show you that there's even no need for a 3rd one. If the script is in Unicode, I can enter any character into a 'raw' or cooked string, using digraphs, a keymap, or the method described under :help i_CTRL-V_digit. No problem. To describe, in a non-Unicode script, strings containing Unicode codepoints not available in the script's encoding, I would have to use a cooked string with \u or maybe \Char-0x in it, where every h is a nybble, or else (for one or a few particular codepoints) move them to a data item at the start of the script, using for instance 'let s:bom = \uFEFF' then use string concatenation elsewhere in the script. This only shows that when describing strings containing non-Latin characters, Latin1 is not the best encoding for the script (and BTW, the :scriptencoding command may come in handy if the script is neither in Latin1 nor in UTF-8 with BOM.) Best regards, Tony.
Re: Show/Hide Split Windows
On Thu, Aug 10, 2006 at 02:42:57PM EDT, Rodolfo Borges wrote:
On 8/10/06, Charles E Campbell Jr [EMAIL PROTECTED] wrote:
Type ctrl-w o to toggle between maximizing one window and restoring
to all. By maximizing, I mean that the current
window will take over the entire display, not leaving a lot of status
bars around.
Actually, Ctrl-w o will close all other windows.
You can't get back to them using Ctrl-w o again
Immediately went to check that. How stupid of me not to have tried it,
I thought. Well unfortunately all I got was an error - Ye already have
only one window.
Question:
Could this be scripted -- using the error code from the failed C-O
attempt to restore the previous layout?
1. When in split mode:
. Vim saves screen layout -- size, position, etc.
. Vim hides all buffers save the current one
. Vim maked the current buffer stretch to occupy entire window
2. When not in split mode:
. Vim checks whether there's is a previous split mode
. If so, Vim restores the previous layout
. If not, displays error message
Would be very cool, afaic ..save me having to look for and then memorize
yet another mapping.
:-)
I use :unhide N but it's usually a pain restoring the layout via C-W +
{H/J/K/L} and then having to resize the sub-windows. But then, I'm no
unhide master.
Thanks,
cga.
Re: delete lines
:nnoremap BS X with this I cannot cross lines (delete $ between line n+1 and line n coming from line n+1 while backspacing and it is not possible to delete the last (or in other words the first char after ^ ) char of a line. Something perhaps like :nnoremap bs ibsrightesc might do the trick. One edge-case I found with this one is if you're on a blank line and use backspace, you delete the backspace, but end up on the last character of the previous line, thus if you have abcd X with the cursor on the X, and hit backspace, you end up on top of the d on the previous line (rather than after it). Thus, hitting backspace again will leave you with abd instead of abc as one would normally want. Haven't yet found a good solution to that one. -tim
Re: changed-yet-not-saved-lines highlighting feature
On 8/10/06, Marc Weber [EMAIL PROTECTED] wrote:
On Thu, Aug 10, 2006 at 11:02:50PM +0800, Eddy Zhao wrote:
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.
I would have proposed using the diff commands, too..
(See DiffWithFileOnDisk in my privious post.)
Perhaps it would be better to save to tempname() because those files
will be deleted automatically..
I think Tim's method is better in that it doesn't require a file at
all. Depending on personal preference, it might be better to
explicitly make the diff buffer a scratch buffer, in something like
the following:
command! -nargs=0 ShowDifferences
\ let ShowDifferencesOriginalBuffer=bufnr('%')
\|execute 'bufdo diffoff'
\|execute 'buffer' ShowDifferencesOriginalBuffer
\|diffthis
\|unlet ShowDifferencesOriginalBuffer
\|below vert new
\|set buftype=nofile noswapfile bufhidden=wipe
\|r #
\|1d
\|diffthis
There's a little extra there to clear diff mode from other buffers to
avoid including more than the two intended buffers in the diff mode.
Re: fast file locating plugin (like ido.el in emacs)
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)
Determine the parent dir.
let parent = matchstr(a:pattern, '^.*/')
let pattern = strpart(a:pattern, len(parent))
let files = glob(parent.((pattern != '') ? '*'.pattern.'*' : '*'))
let fl = split(files, \NL)
let entries = []
for f in fl
let word = isdirectory(f)?f./:f
let fname = matchstr(f, '[^/]*$')
call add(entries, {
\ 'word': word,
\ 'abbr': fname,
\ 'menu': substitute(fname, '\V'.pattern, '**', ''),
\ 'kind': (isdirectory(f)?'/':' '),
\ })
endfor
return entries
endfunction
--
Thanks,
Hari
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Omnicompletion top window
Hello, I'd like to know if there's a way to get rid of the top horizontal window that appears while we're using omnicompletion. Right now, after I Ctrl_X Ctrl_O and find the one I want I just type it. While the balloon list disappears the horizontal window with the info stays, so I have to Ctr_W k :q to get rid of it. Is there a faster way to make it go away once I'm done with completion? -- Panos Laganakos
RE: Search and Replace with a Regular Expression
I agree with Chip and have a recommendation. Since you have been using Vim, Perl will be much easier to learn. When I first began studying programming Perl was over my head and seemed very difficult. I found it incredibly easy to learn Perl. I was faced with a large data-reformatting program written in uncommented C that needed to be adapted to a new input format. I started to work on it but it soon became clear that fixing the program would take a couple of weeks. I had vague memories of a language named Perl that was good for that sort of text processing, so at the weekend I went into London, bought the Camel book, skimmed through it on the train home, went into work on Monday and rewrote the entire application in Perl. Not only did it take me less than half the time to rewrite the code as it would have taken to fix it, but the Perl version ran three times faster than the original C. And quite likely, a 'lex' script would be able to do the same in about half as many lines, and taken half that time to do it. :D 'lex' rules!
Re: Tips for advance use of Vim
I don't think this should replace vim.org but it might link to the tips/
scripts there
Benefits: Its easier to keep it up to date (on vim.org you'll get
still outdated matches..
IMO this is an excellent idea. I am a web developer and willing to help.
4mir
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
4mir - http://amix.dk
---
/(bb|[^b]{2})/ that is the Question
Unwanted leading spaces in reltimestr()
Hello Vim List, The function reltimestr() return a string which may have leading spaces. Is that a bug or a feature? A workaround for this is: function Reltimestr(t) return matchstr(reltimestr(a:t),'[0-9.]\+') endfunction -- Best regards, Bill
Re: Show/Hide Split Windows
On Thu, Aug 10, 2006 at 03:28:22PM EDT, Charles E Campbell Jr wrote: cga2000 wrote: On Thu, Aug 10, 2006 at 02:42:57PM EDT, Rodolfo Borges wrote: On 8/10/06, Charles E Campbell Jr [EMAIL PROTECTED] wrote: Type ctrl-w o to toggle between maximizing one window and restoring to all. By maximizing, I mean that the current window will take over the entire display, not leaving a lot of status bars around. Actually, Ctrl-w o will close all other windows. You can't get back to them using Ctrl-w o again Immediately went to check that. How stupid of me not to have tried it, I thought. Well unfortunately all I got was an error - Ye already have only one window. Please look at the rest of my email concerning the ZoomWin plugin. It what makes ctrl-w o do the trick mentioned above. And, of course, there's always my website (http://mysite.verizon.net/astronaut/vim) where I keep the latest versions (albeit perhaps still alpha/beta-ish) of my plugins. This is weird .. I got the message you are referring to after I posted mine .. although the one I was replying to was posted later to the list. Thanks much for taking the trouble to write this reminder. The plugin does exactly what I want. Thanks, cga
RE: Patch (Unofficial): Malformed characters in menu and toolbar when using zh_CN.GBK encoding under Linux
Bram, you have an overflow in your signature :) Max -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, August 10, 2006 1:44 PM Subject: Re: Patch (Unofficial): Malformed characters in menu and toolbar when using zh_CN.GBK encoding under Linux snip -- hundred-and-one symptoms of being an internet addict: 102. When filling out your driver's license application, you give your IP address. snip
Re: using syntax match two time in one line? fst blocks snd?
I am assuming that you have output like this: --- | Field1 | Field2 | Field3 | Field4 | ... | --- | Value1 | Value2 | Value3 | Value4 | ... | --- Exactly ! In which case you might want to try something like this: syntax match Border '^-\+$' syntax match Border '^|' nextgroup=Col1 syntax match Col1 '[^|]\+|' contained nextgroup=Col2 syntax match Col2 '[^|]\+|' contained nextgroup=Col3 syntax match Col3 '[^|]\+|' contained nextgroup=Col4 syntax match Col4 '[^|]\+|' contained [ ... etc ... ] syntax match Border | contained containedin=Col1,Col2,Col3,Col4 hi link Border Error hi link Col1 Macro hi link Col2 Type hi link Col3 Statement hi link Col4 String [ ... etc ... ] This should highlight each column in a different color for you. In case this doesn't help you, the following might help you: Unfortunately it took till now to discover you mail ;) I ended up trying this: - hi def link Color1 Comment hi def link Color2 Function hi def link Color3 Label hi def link Color4 Define hi def link Border Error hi def link DummyColor Underlined add display option function! AddColumnSynMatches() let colors = ['Color1','Color2','Color3','Color4'] let sep='[|\t]' tab or | let non_sep='[^|\t]' let sep='[|\t]' let start_line='^\s*' let dummyColor=Ignore let color_list=join(colors,',') This is used to start the chain using nextgroup=colors[0] exec 'syn match '.dummyColor. '.start_line.' nextgroup=.colors[0].' transparent' for i in range(0,2) len(colors)-1) let color = colors[i % len(colors)] let next_color = colors[(i+1) % len(colors)] let regex=non_sep.'\+'.sep exec 'syn match '.color. '.regex.' containedin=foo nextgroup=.next_color echo 'syn match '.color. '.regex.' containedin=foo nextgroup=.next_color endfor echo done This border idea is from Peter exec 'syntax match Border | contained containedin='.join(colors,,) endfunction call AddColumnSynMatches() outdated command! InsertTestline normal oatabbtabctabdtabetabftabgtabhtab - But I can't see why it does'nt work. Explanation: exec 'syn match '.dummyColor. '.start_line.' nextgroup=.colors[0].' transparent' starts highlighting the line. nextgroup tells vim to start with Color1 for i in range(0,2) len(colors)-1) let color = colors[i % len(colors)] let next_color = colors[(i+1) % len(colors)] let regex=non_sep.'\+'.sep exec 'syn match '.color. '.regex.' containedin=foo nextgroup=.next_color echo 'syn match '.color. '.regex.' containedin=foo nextgroup=.next_color endfor This should add support for 3 columns (use len(colors)-1 to support as much as you have RAM.. contained=foo should ensure that they don't start on their own (because foo isn't defined and nextgroup overrides this behaviourr anyway) But all I can see is the line beeing highlighted in Error (the color of the dummy start line syntax area) Try it out by using :source|InsertTestline Do you see what I've done wrong? Marc Weber
Re: _vimrc in fedora core 5
Vu The Cuong wrote:
Currently I'm using win XP.
I just install dual OS with fedora core 5 and I installed vim 7
mannually from source. installation successful.
I created .gvimrc in my home folder and I put gvimrc.vim.example in to
this folder but vim seems not detected this file.
Could anyone tell me what's the exact name of this file under linux?
Thanks
Under Linux, Vim will read:
1) $HOME/.vimrc and if not found, $HOME/_vimrc
2) only in GUI mode: $HOME/.gvimrc and if not found, $HOME/_gvimrc
These are files, not folders. If you want to use the example scripts, I
recommend to source (using :source or :runtime) them than copy them:
that way, if ever there is a bugfix to them you won't be stuck with the
older version.
Under Windows, the searching order is reversed (underscores first, then
dots). Thus, on a dual-boot system, if your HOME folder is the same, you
can have a single vimrc called either .vimrc or _vimrc provided that
there is no file by the other name; or one for Linux with a dot and
another one for Windows with an underscore.
Personally I don't use the gvimrc; I have built my own vimrc around the
line runtime vimrc_example.vim which invokes the example script. Most
user settings go after that line; a :language messages command (if
any) goes before it if it is to set the languages for the menus.
The reason is I find it easier to maintain a single rc file; any
settings peculiar to gvim or to console vim can be wrapped as follows
if has(gui_running)
settings for gvim
else
settings for console Vim
endif
Even if you prefer to have a separate gvimrc, remember that gvim also
reads the vimrc; so if you have settings in the vimrc which are for
console Vim only you will still have to wrap them in if !
has('gui_running').
After looking at what there is in the gvimrc_example, I don't miss it.
Some settings (such as set ch=2 hlsearch) I have set in my vimrc so
Console Vim and gvim behave identically; :set mousehide isn't
necessary since it is the default; and whatever colors displease me I
have changed in a small colorscheme named almost-default.vim. As for the
'guifont', the example given in a comment won't work on all systems; I
use, in my vimrc, a snippet of code similar to what is mentioned under
:help setting-guifont, but slightly more complicated because there is
still a version of kvim (gvim for kde) on this system, and that requires
a 4th 'guifont' format.
Best regards,
Tony.
Re: Patch (Unofficial): Malformed characters in menu and toolbar when using zh_CN.GBK encoding under Linux
Hi, Max Dyckhoff wrote: Bram, you have an overflow in your signature :) Max -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, August 10, 2006 1:44 PM Subject: Re: Patch (Unofficial): Malformed characters in menu and toolbar when using zh_CN.GBK encoding under Linux snip -- hundred-and-one symptoms of being an internet addict: 102. When filling out your driver's license application, you give your IP address. snip from another mail by Bram: | 257. Your ``hundred-and-one´´ lists include well over 101 items, | since you automatically interpret all numbers in hexadecimal | notation. (hex 101 = decimal 257) Regards, Jürgen -- Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us. (Calvin)
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!
