On 19-Jan-2010 17:25, Bram Moolenaar wrote:
Ingo Karkat wrote:
After some more days of contemplation, I still find this behavior odd.
Bram, can your standpoint be paraphased as such: complete() doesn't
respect 'completeopt=longest', because it may result in only partial
insertion of match text, and complete() should always offer the script
full control over what is inserted.
(But then, what's the point of protecting the inserted match; I can
always use <BS> to partially remove text from the match after
completion?! And, if a script really wants this, it could temporarily
remove 'longest' from 'completeopt' to achieve this. Are there any
examples where this is useful?)
Please give me a short note if you won't consider changing this; I
will then submit a patch for the help, as I think this special
behavior needs to be mentioned somewhere.
You can try changing the source code to make it work like you want.
Problem is that the insert completion is a bit of a mess and very hard
to understand. I rather leave it alone.
Perhaps you can insert this line:
compl_get_longest = (vim_strchr(p_cot, 'l') != NULL);
near the end of set_completion(). Might work, might break some
things...
All right, so my reasoning isn't totally off and you're open to changes in this
area. Thanks!
As I mentioned, it's quite easy to switch to 'completefunc' to work around this
issue. But anyway, I put it on my list to look into next time I dig into Vim's
sources. (I'm more into Vim scripting.) This might warrant a low-priority entry
on todo.txt, too, so that maybe someone else is inclined to consider this.
the insert completion is a bit of a mess
Sorry to hear; this is such a great and powerful feature.
-- regards, ingo
--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
