[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Completing with anything

From: Antoine Levitt
Subject: Re: Completing with anything
Date: Tue, 24 May 2011 20:30:06 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

24/05/11 20:05, Stefan Monnier
>> Oh well, I guess that I'm the only one who wants this kind of behaviour,
>> so I just ended up with an advice which seems to do the trick.  Sorry for
>> hijacking this thread.  In case anyone is interested:
> To get back to this discussion.  Before worrying about how to implement
> it, I'm wondering what should the behavior be.
> The way I look at it, the issue is whether the completion data returned
> by completion-at-point-functions is "exclusive": currently it is
> exclusive, which means that if that data leads to a completion failure,
> then the whole completion-at-point fails, even though there might be
> further functions on completion-at-point-functions which could return
> data that does lead to a successful completion.
> This "exclusive"ness is a bit similar to the must-match argument of
> completion-read: it presumes that the function knows that anything
> outside of the completion table is simply undesirable at point.
> This "exclusive" behavior is what causes you pain.  Now one possible
> strategy is to make the behavior non-exclusive and keep trying the next
> functions until one of them returns data that leads to a successful
> completion, which is largely what used to happen with
> comint-dynamic-complete-function.
> Another is to do it more selectively, flag some of
> completion-at-point-functions as "not-exclusive", meaning that if
> completion fails with those we should keep trying with subsequent
> functions.  E.g. the nick completion in rcirc could be flagged as
> non-exclusive since it applies everywhere, which in turn would let your
> dabbrev-expand kick in when nick-completion fails.

This seems to be the most flexible, while still keeping all the
completions in the same UI. I'd make the non-exclusive behaviour the
default though: let the functions that want to "take over" the
completion state it explicitely.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]