[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [O] Completing with anything
From: |
Antoine Levitt |
Subject: |
Re: [O] 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.
- Re: [O] Completing with anything, (continued)
- Re: [O] Completing with anything, Stefan Monnier, 2011/05/04
- Re: [O] Completing with anything, Julien Danjou, 2011/05/04
- Re: [O] Completing with anything, Stefan Monnier, 2011/05/23
- Re: [O] Completing with anything, Julien Danjou, 2011/05/24
- Message not available
- Re: [O] Completing with anything, Stefan Monnier, 2011/05/24
- Re: [O] Completing with anything, Antoine Levitt, 2011/05/24
- Re: [O] Completing with anything, Stefan Monnier, 2011/05/24
- Re: [O] Completing with anything, Stefan Monnier, 2011/05/24
- Re: [O] Completing with anything, Antoine Levitt, 2011/05/24
- Re: [O] Completing with anything, Stefan Monnier, 2011/05/24
- Re: [O] Completing with anything,
Antoine Levitt <=
- Re: [O] Completing with anything, Stefan Monnier, 2011/05/25
- Re: [O] Completing with anything, Antoine Levitt, 2011/05/26
- Re: [O] Completing with anything, Stefan Monnier, 2011/05/27