Ingo Karkat wrote:
> 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.
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...
--
hundred-and-one symptoms of being an internet addict:
123. You ask the car dealer to install an extra cigarette lighter
on your new car to power your notebook.
/// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
