On 12-Jan-2010 16:07, Ingo Karkat wrote:
On 12-Jan-2010 15:40, Bram Moolenaar wrote:
No, this works as intended. The whole idea of complete() is that the
script has full control over the matches. If you want to return the
longest matching text, then pass that to complete().
At least the way I use completion, 'completeopt=longest' is orthogonal
to the content and number of matches. Take the calendar-month example I
used. When I type "M", and perform completion, it'll offer "March" and
"May"; by default (no "longest"), the first match "March" is inserted.
I use 'completeopt=longest' to have only "Ma" inserted, so that I can
refine and select the match by typing additional letters instead of
repeating CTRL-N to go through all matches sequentially.
If my script passed only the common text "Ma" on completion, I would
lose the ability to preview all matches (via the "match n of m" message
and the popup menu), and would then have to re-start the custom
completion in order to complete.
So, in my daily use 'completeopt=longest' is just a preference that
allows to gradually refine the number of matches while avoiding
sequential browsing through the list of matches, it has nothing to do
with what kind of matches are displayed.
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.
-- regards, ingo
--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
