ERC completion

ERC completion

[Antoine Levitt]

The change from 2011-04-26 13:50:09 by Stefan Monnier introduced the
following changes:

- Completion is now case-sensitive. I think the old behaviour was a
  better default (I know I highlight many people with capitalized nick)

- erc-complete-functions seems to be ignored, but is still documented as
  a variable. Could you mark it as obsolete and document how to get the
  same effect with the new framework?

It's good to see all of emacs moving towards the new completion
framework. Thanks for all the work!

Re: ERC completion

[Stefan Monnier]

> The change from 2011-04-26 13:50:09 by Stefan Monnier introduced the
> following changes:

> - Completion is now case-sensitive. I think the old behaviour was a
>   better default (I know I highlight many people with capitalized nick)

Hmm... oh I think I see where is the problem: erc-pcomplete.el sets
pcomplete-ignore-case, but pcomplete-completions-at-point does not obey
this variable.  The patch I just installed (attached) should fix it.

> - erc-complete-functions seems to be ignored, but is still documented as
>   a variable. Could you mark it as obsolete and document how to get the
>   same effect with the new framework?

What makes you think it's ignored?


        Stefan


=== modified file 'lisp/ChangeLog'
--- lisp/ChangeLog	2011-04-27 19:51:19 +0000
+++ lisp/ChangeLog	2011-04-28 00:17:24 +0000
@@ -1,3 +1,13 @@
+2011-04-28  Stefan Monnier  <monnier@iro.umontreal.ca>
+
+	* pcomplete.el (pcomplete-completions-at-point):
+	Obey pcomplete-ignore-case.  Don't call pcomplete-norm-func unless
+	pcomplete-seen is non-nil.
+	(pcomplete-comint-setup): Also recognize the new comint/shell
+	completion functions.
+	(pcomplete-do-complete): Don't call pcomplete-norm-func unless
+	pcomplete-seen is non-nil.
+
 2011-04-27  Niels Giesen  <niels.giesen@gmail.com>
 
 	* calendar/icalendar.el (diary-lib): Add require statement.

=== modified file 'lisp/pcomplete.el'
--- lisp/pcomplete.el	2011-04-19 13:44:55 +0000
+++ lisp/pcomplete.el	2011-04-28 00:14:41 +0000
@@ -522,23 +522,24 @@
                                        (directory-file-name f)))
                             pcomplete-seen))
               (lambda (f)
-                (not (member
+                (not (when pcomplete-seen
+                       (member
                       (funcall pcomplete-norm-func
                                (directory-file-name f))
-                      pcomplete-seen))))))
-
-      (list
-       beg (point)
+                        pcomplete-seen)))))))
+      (unless (zerop (length pcomplete-termination-string))
        ;; Add a space at the end of completion.  Use a terminator-regexp
        ;; that never matches since the terminator cannot appear
        ;; within the completion field anyway.
-       (if (zerop (length pcomplete-termination-string))
-           table
-         (apply-partially 'completion-table-with-terminator
+        (setq table
+              (apply-partially #'completion-table-with-terminator
                           (cons pcomplete-termination-string
                                 "\\`a\\`")
-                          table))
-       :predicate pred))))
+                               table)))
+      (when pcomplete-ignore-case
+        (setq table
+              (apply-partially #'completion-table-case-fold table)))
+      (list beg (point) table :predicate pred))))
 
  ;; I don't think such commands are usable before first setting up buffer-local
  ;; variables to parse args, so there's no point autoloading it.
@@ -781,7 +782,9 @@
   (set (make-local-variable completef-sym)
        (copy-sequence (symbol-value completef-sym)))
   (let* ((funs (symbol-value completef-sym))
-	 (elem (or (memq 'shell-dynamic-complete-filename funs)
+	 (elem (or (memq 'comint-filename-completion funs)
+                   (memq 'shell-filename-completion funs)
+                   (memq 'shell-dynamic-complete-filename funs)
 		   (memq 'comint-dynamic-complete-filename funs))))
     (if elem
 	(setcar elem 'pcomplete)
@@ -1248,11 +1251,12 @@
       (setq completions
             (apply-partially 'completion-table-with-predicate
                              completions
+                             (when pcomplete-seen
                              (lambda (f)
                                (not (member
                                      (funcall pcomplete-norm-func
                                               (directory-file-name f))
-                                     pcomplete-seen)))
+                                       pcomplete-seen))))
                              'strict)))
     ;; OK, we've got a list of completions.
     (if pcomplete-show-list

Re: ERC completion

[Antoine Levitt]

28/04/11 02:18, Stefan Monnier
>> The change from 2011-04-26 13:50:09 by Stefan Monnier introduced the
>> following changes:
>
>> - Completion is now case-sensitive. I think the old behaviour was a
>>   better default (I know I highlight many people with capitalized nick)
>
> Hmm... oh I think I see where is the problem: erc-pcomplete.el sets
> pcomplete-ignore-case, but pcomplete-completions-at-point does not obey
> this variable.  The patch I just installed (attached) should fix it.

Yes, fixed, thanks.

>
>> - erc-complete-functions seems to be ignored, but is still documented as
>>   a variable. Could you mark it as obsolete and document how to get the
>>   same effect with the new framework?
>
> What makes you think it's ignored?

Sorry, it isn't ignored. But rather, erc-pcompletions-at-point always
return non-nil, even when it does not complete anything, so that my
customization

  (setq erc-complete-functions '(erc-pcompletions-at-point
  my-dabbrev-expand))

does not work as expected. (the intent is to have dabbrev take over if
I'm not completing a nick)

Re: ERC completion

[Stefan Monnier]

> Sorry, it isn't ignored. But rather, erc-pcompletions-at-point always
> return non-nil, even when it does not complete anything, so that my
> customization

>   (setq erc-complete-functions '(erc-pcompletions-at-point
>   my-dabbrev-expand))

> does not work as expected. (the intent is to have dabbrev take over if
> I'm not completing a nick)

Hmm, does the patch below help?


        Stefan


=== modified file 'lisp/pcomplete.el'
--- lisp/pcomplete.el	2011-04-28 00:18:12 +0000
+++ lisp/pcomplete.el	2011-04-28 19:31:21 +0000
@@ -489,10 +489,10 @@
            ;; prefix from pcomplete-stub.
            (beg (max (- (point) (length pcomplete-stub))
                      (pcomplete-begin)))
-           (buftext (buffer-substring beg (point)))
-           (table
+           (buftext (buffer-substring beg (point))))
+      (when completions
+        (let ((table
             (cond
-             ((null completions) nil)
              ((not (equal pcomplete-stub buftext))
               ;; This isn't always strictly right (e.g. if
               ;; FOO="toto/$FOO", then completion of /$FOO/bar may
@@ -514,8 +514,8 @@
                         (pcomplete-quote-argument res)
                       res)))))))
            (pred
-            ;; pare it down, if applicable
-            (when (and table pcomplete-use-paring pcomplete-seen)
+               ;; Pare it down, if applicable.
+               (when (and pcomplete-use-paring pcomplete-seen)
               (setq pcomplete-seen
                     (mapcar (lambda (f)
                               (funcall pcomplete-norm-func
@@ -539,7 +539,7 @@
       (when pcomplete-ignore-case
         (setq table
               (apply-partially #'completion-table-case-fold table)))
-      (list beg (point) table :predicate pred))))
+          (list beg (point) table :predicate pred))))))
 
  ;; I don't think such commands are usable before first setting up buffer-local
  ;; variables to parse args, so there's no point autoloading it.

Re: ERC completion

[Antoine Levitt]

28/04/11 21:34, Stefan Monnier
>> Sorry, it isn't ignored. But rather, erc-pcompletions-at-point always
>> return non-nil, even when it does not complete anything, so that my
>> customization
>
>>   (setq erc-complete-functions '(erc-pcompletions-at-point
>>   my-dabbrev-expand))
>
>> does not work as expected. (the intent is to have dabbrev take over if
>> I'm not completing a nick)
>
> Hmm, does the patch below help?

It's looks like it's a step in the right direction, but it does not fix
the problem: "completions" is still non-nil, and includes every nick,
even those that don't begin by the word before point.

Also, while on the subject of ERC completions, it seems an extra space
is appended after erc-pcomplete-nick-postfix, originating from the same
commit.

Re: ERC completion

[Stefan Monnier]

>>> Sorry, it isn't ignored. But rather, erc-pcompletions-at-point always
>>> return non-nil, even when it does not complete anything, so that my
>>> customization
>>> (setq erc-complete-functions '(erc-pcompletions-at-point
>>> my-dabbrev-expand))
>>> does not work as expected. (the intent is to have dabbrev take over if
>>> I'm not completing a nick)
>> Hmm, does the patch below help?

> It's looks like it's a step in the right direction, but it does not fix
> the problem: "completions" is still non-nil, and includes every nick,
> even those that don't begin by the word before point.

I see.  The problem is that completion-at-point-functions is meant to
first decide what kind of completion should take place at point,
regardless of whether the text at point might match any one of those
completions (and determining whether or not it matches would need to pay
attention to completion-styles and completion-in-region-function, ...,
i.e. do a dry-run of completion-in-region).  Note that the decision
should take place separately from the completion itself since we want to
be able to do things like completion-help-at-point.

IIUC in your case, you seem to want to use "nick completion if such
a completion exists, or else fallback on dabbrev".

I'm not sure how best provide that kind of behavior (other than by
trying to merge the two entries using something like
completion-table-in-turn).

> Also, while on the subject of ERC completions, it seems an extra space
> is appended after erc-pcomplete-nick-postfix, originating from the same
> commit.

Hmm... can you show me exactly what you've done, what was the result
with the code and what is the result with the new code?


        Stefan

Re: ERC completion

[Antoine Levitt]

29/04/11 02:50, Stefan Monnier
>>>> Sorry, it isn't ignored. But rather, erc-pcompletions-at-point always
>>>> return non-nil, even when it does not complete anything, so that my
>>>> customization
>>>> (setq erc-complete-functions '(erc-pcompletions-at-point
>>>> my-dabbrev-expand))
>>>> does not work as expected. (the intent is to have dabbrev take over if
>>>> I'm not completing a nick)
>>> Hmm, does the patch below help?
>
>> It's looks like it's a step in the right direction, but it does not fix
>> the problem: "completions" is still non-nil, and includes every nick,
>> even those that don't begin by the word before point.
>
> I see.  The problem is that completion-at-point-functions is meant to
> first decide what kind of completion should take place at point,
> regardless of whether the text at point might match any one of those
> completions (and determining whether or not it matches would need to pay
> attention to completion-styles and completion-in-region-function, ...,
> i.e. do a dry-run of completion-in-region).  Note that the decision
> should take place separately from the completion itself since we want to
> be able to do things like completion-help-at-point.
>
> IIUC in your case, you seem to want to use "nick completion if such
> a completion exists, or else fallback on dabbrev".
>
> I'm not sure how best provide that kind of behavior (other than by
> trying to merge the two entries using something like
> completion-table-in-turn).

Can't you just wrap the new framework as a function that completes and
returns nil if it did not do anything, and use this for erc-complete-functions?

In any cases the change breaks erc-complete-functions. Maybe this
should be resolved in a general way before converting ERC (and maybe
others that use a similar way of customizing completions) to the new
completion framework.

Or just drop erc-complete-functions support and document a way of
achieving the same effect under the new framework.

>
>> Also, while on the subject of ERC completions, it seems an extra space
>> is appended after erc-pcomplete-nick-postfix, originating from the same
>> commit.
>
> Hmm... can you show me exactly what you've done, what was the result
> with the code and what is the result with the new code?

Just run emacs -Q, join any channel, and complete a username. Old code
did

"ERC> some_nick: "
new code does
"ERC> some_nick:  "

Re: ERC completion

[Stefan Monnier]

> Can't you just wrap the new framework as a function that completes and
> returns nil if it did not do anything, and use this for
> erc-complete-functions?

You can replace erc-pcompletions-at-point with erc-pcomplete on
erc-complete-functions to get back the old behavior, and if you want to
use the standard UI for it, we could create a new erc-pcomplete-std
which calls erc-pcompletions-at-point and passes the result to
completion-in-region, but that would not be compatible for example with
completion-help-at-point.

Think about the problem: completion-help-at-point should be able to show
either the completions at point for nicks or for dabbrev depending on
the situation.

> In any cases the change breaks erc-complete-functions. Maybe this
> should be resolved in a general way before converting ERC (and maybe
> others that use a similar way of customizing completions) to the new
> completion framework.

In foo-completion-functions, where you have a list of possible
completions and use the first that works, there are two different cases:
- a completion function can decide based on context that it does not
  apply at this point and we should hence try the next
  completion function.
- a completion function may think that we may indeed be completing one
  of the things for which it was designed, but it happens to find no
  valid completion, and then decides that maybe we should then try the
  next completion function.

The first is what is supported by completion-at-point-functions, and the
second is what is supported by completion-table-in-turn.
comint-dynamic-complete-functions and erc-complete-functions support
a combination of the two (AFAICT this was not so much a conscious design
decision as just a natural way to write the simple code).

completion-at-point-functions happens to support the second as well, tho
deprecates it because it's incompatible with the underlying idea of
separating the completion data from the completion operations.

We could change erc-pcompletions-at-point to assume that
completion-in-region-functions is nil and to check that
`completion-try-completion' returns non-nil before returning the
completion data.  Or maybe this test should be done only in
ERC's pcomplete-default-completion-function.

[...time passes...]

I think the basic problem is that we need here to combine various
"default completion" alternatives (nicks, from erc-pcomplete, and
dabbrev), i.e. completion functions which are valid everywhere.
Maybe completion-at-point-functions should provide special support
for such things.

> Or just drop erc-complete-functions support and document a way of
> achieving the same effect under the new framework.

The problem is in the precise effect you're trying to achieve, rather
than in erc-complete-functions ;-)

>>> Also, while on the subject of ERC completions, it seems an extra space
>>> is appended after erc-pcomplete-nick-postfix, originating from the same
>>> commit.
>> Hmm... can you show me exactly what you've done, what was the result
>> with the code and what is the result with the new code?
> Just run emacs -Q, join any channel, and complete a username. Old code
> did
> "ERC> some_nick: "
> new code does
> "ERC> some_nick:  "

Ah, I see the problem: pcomplete-completions-at-point does not pay
attention to pcomplete-suffix-list (because it solves the problem that
pcomplete-suffix-list was meant to solve in a different way (relying on
the completion table's `boundaries' method instead).  Can you try the
patch below to see if it solves the problem?


        Stefan


=== modified file 'lisp/erc/erc-pcomplete.el'
--- lisp/erc/erc-pcomplete.el	2011-04-26 13:50:09 +0000
+++ lisp/erc/erc-pcomplete.el	2011-04-29 15:19:43 +0000
@@ -48,7 +48,7 @@
   "Programmable completion for ERC"
   :group 'erc)
 
-(defcustom erc-pcomplete-nick-postfix ": "
+(defcustom erc-pcomplete-nick-postfix ":"
   "*When `pcomplete' is used in the first word after the prompt,
 add this string to nicks completed."
   :group 'erc-pcomplete
@@ -93,8 +93,6 @@
        t)
   (set (make-local-variable 'pcomplete-use-paring)
        nil)
-  (set (make-local-variable 'pcomplete-suffix-list)
-       '(?  ?:))
   (set (make-local-variable 'pcomplete-parse-arguments-function)
        'pcomplete-parse-erc-arguments)
   (set (make-local-variable 'pcomplete-command-completion-function)

Re: ERC completion

[Antoine Levitt]

29/04/11 17:20, Stefan Monnier
> I think the basic problem is that we need here to combine various
> "default completion" alternatives (nicks, from erc-pcomplete, and
> dabbrev), i.e. completion functions which are valid everywhere.
> Maybe completion-at-point-functions should provide special support
> for such things.
>
>> Or just drop erc-complete-functions support and document a way of
>> achieving the same effect under the new framework.
>
> The problem is in the precise effect you're trying to achieve, rather
> than in erc-complete-functions ;-)

FWIW I think it's very a nice feature to have completion fall back to
dabbrev by default. I used to have an extremely hackish way of doing
this before the new tab completions: I used to listen for key input, and
if it was a TAB, get the function bound to TAB in the current context,
and dynamically advice it to have it run a dabbrev completion if it did
not move the point. That way I had dabbrev complete when TAB was not
indenting, in every mode, no matter how diverse their bindings for TAB
were. It was incredibly bad code, but it worked perfectly :)

Nowadays, I have in my .emacs the following, which actually works fine but which
I now realize is utterly wrong :)

(setq tab-always-indent 'complete)
(defun my-dabbrev-expand ()
  (when (and (not (bolp))
	     (looking-at "\\_>"))
    (dabbrev-expand nil)))
(defun my-dabbrev-expand-and-nil ()
  (my-dabbrev-expand)
  nil)
(setq completion-at-point-functions '(my-dabbrev-expand-and-nil))

I seem to recall talks of priority for completions. Couldn't that be
used here? That way, I'd set completion-at-point-functions to something
that returns the list of dabbrev expands with a low priority, and every
other completion would take precedence over it.

>
>>>> Also, while on the subject of ERC completions, it seems an extra space
>>>> is appended after erc-pcomplete-nick-postfix, originating from the same
>>>> commit.
>>> Hmm... can you show me exactly what you've done, what was the result
>>> with the code and what is the result with the new code?
>> Just run emacs -Q, join any channel, and complete a username. Old code
>> did
>> "ERC> some_nick: "
>> new code does
>> "ERC> some_nick:  "
>
> Ah, I see the problem: pcomplete-completions-at-point does not pay
> attention to pcomplete-suffix-list (because it solves the problem that
> pcomplete-suffix-list was meant to solve in a different way (relying on
> the completion table's `boundaries' method instead).  Can you try the
> patch below to see if it solves the problem?
>
>
>         Stefan
>
>
> === modified file 'lisp/erc/erc-pcomplete.el'
> --- lisp/erc/erc-pcomplete.el	2011-04-26 13:50:09 +0000
> +++ lisp/erc/erc-pcomplete.el	2011-04-29 15:19:43 +0000
> @@ -48,7 +48,7 @@
>    "Programmable completion for ERC"
>    :group 'erc)
>  
> -(defcustom erc-pcomplete-nick-postfix ": "
> +(defcustom erc-pcomplete-nick-postfix ":"
>    "*When `pcomplete' is used in the first word after the prompt,
>  add this string to nicks completed."
>    :group 'erc-pcomplete
> @@ -93,8 +93,6 @@
>         t)
>    (set (make-local-variable 'pcomplete-use-paring)
>         nil)
> -  (set (make-local-variable 'pcomplete-suffix-list)
> -       '(?  ?:))
>    (set (make-local-variable 'pcomplete-parse-arguments-function)
>         'pcomplete-parse-erc-arguments)
>    (set (make-local-variable 'pcomplete-command-completion-function)

Yes it does. It does change the semantics of erc-pcomplete-nick-postfix though, by adding
an extra space automatically. I guess nobody will ever need to complete
without a space, so that's fine.

Re: ERC completion

[Stefan Monnier]

> Nowadays, I have in my .emacs the following, which actually works fine
> but which I now realize is utterly wrong :)

> (setq tab-always-indent 'complete)
> (defun my-dabbrev-expand ()
>   (when (and (not (bolp))
> 	     (looking-at "\\_>"))
>     (dabbrev-expand nil)))
> (defun my-dabbrev-expand-and-nil ()
>   (my-dabbrev-expand)
>   nil)

Why my-dabbrev-expand-and-nil?

> (setq completion-at-point-functions '(my-dabbrev-expand-and-nil))

`setq' on a hook is almost always the wrong thing to do.
Either use `setq-default' here if you really intend to throw away the
default global completion functions, or otherwise use something like:

(add-hook 'completion-at-point-functions 'my-dabbrev-expand 'append)

> I seem to recall talks of priority for completions. Couldn't that be
> used here? That way, I'd set completion-at-point-functions to something
> that returns the list of dabbrev expands with a low priority, and every
> other completion would take precedence over it.

By placing it at the end of the hook, you're giving it the lowest priority.

> Yes it does. It does change the semantics of
> erc-pcomplete-nick-postfix though, by adding an extra space
> automatically. I guess nobody will ever need to complete without
> a space, so that's fine.

Every other erc-pcomplete completion adds a space, so it shouldn't be
too much of a surprise,


        Stefan

Re: ERC completion

[Antoine Levitt]

02/05/11 17:02, Stefan Monnier
>> Nowadays, I have in my .emacs the following, which actually works fine
>> but which I now realize is utterly wrong :)
>
>> (setq tab-always-indent 'complete)
>> (defun my-dabbrev-expand ()
>>   (when (and (not (bolp))
>> 	     (looking-at "\\_>"))
>>     (dabbrev-expand nil)))
>> (defun my-dabbrev-expand-and-nil ()
>>   (my-dabbrev-expand)
>>   nil)
>
> Why my-dabbrev-expand-and-nil?

Because I'm dumb. :) (that was for some old code I don't use anymore)

>
>> (setq completion-at-point-functions '(my-dabbrev-expand-and-nil))
>
> `setq' on a hook is almost always the wrong thing to do.
> Either use `setq-default' here if you really intend to throw away the
> default global completion functions, or otherwise use something like:
>
> (add-hook 'completion-at-point-functions 'my-dabbrev-expand 'append)

That was mostly for tests.

>
>> I seem to recall talks of priority for completions. Couldn't that be
>> used here? That way, I'd set completion-at-point-functions to something
>> that returns the list of dabbrev expands with a low priority, and every
>> other completion would take precedence over it.
>
> By placing it at the end of the hook, you're giving it the lowest
> priority.

Cool! Then all that'd be needed is to write a dabbrev-completions
function that'd return all completions, as found by dabbrev, and set it
at the end of the hook. Then erc nick completions would take precedence,
and life would be good again.

This doesn't seem to be trivial, as dabbrev relies on an internal state
(for instance, calling dabbrev--find-all-expansions twice results in a
different result each time), and there seems to be more issues -
http://www.emacswiki.org/emacs/CompletionUI#toc6 says that it doesn't
get the ordering right, for instance. But surely dabbrev would be a
worthy addition to the completion framework (unless everybody uses
something else of which I'm not aware?)

Re: ERC completion

[Stefan Monnier]

>>> I seem to recall talks of priority for completions. Couldn't that be
>>> used here? That way, I'd set completion-at-point-functions to something
>>> that returns the list of dabbrev expands with a low priority, and every
>>> other completion would take precedence over it.
>> By placing it at the end of the hook, you're giving it the lowest
>> priority.
> Cool! Then all that'd be needed is to write a dabbrev-completions
> function that'd return all completions, as found by dabbrev, and set it
> at the end of the hook. Then erc nick completions would take precedence,
> and life would be good again.

No, I think your problem is not that dabbrev had too high a priority,
but rather than erc-nick completion is too eager to complete
everywhere, and never lets the lower-priority completions (such as
dabbrev) play.


        Stefan

Re: ERC completion

[Antoine Levitt]

02/05/11 20:04, Stefan Monnier
>>>> I seem to recall talks of priority for completions. Couldn't that be
>>>> used here? That way, I'd set completion-at-point-functions to something
>>>> that returns the list of dabbrev expands with a low priority, and every
>>>> other completion would take precedence over it.
>>> By placing it at the end of the hook, you're giving it the lowest
>>> priority.
>> Cool! Then all that'd be needed is to write a dabbrev-completions
>> function that'd return all completions, as found by dabbrev, and set it
>> at the end of the hook. Then erc nick completions would take precedence,
>> and life would be good again.
>
> No, I think your problem is not that dabbrev had too high a priority,
> but rather than erc-nick completion is too eager to complete
> everywhere, and never lets the lower-priority completions (such as
> dabbrev) play.

Right, I think I (finally) see. I thought the completion-at-point thingy
was designed from the ground up to merge several completion sources,
which is why I was thoroughly confused by this conversation. Judging
from the various codes on the internet
(http://www.emacswiki.org/emacs/HippieExpand for instance), several
others have a need for this kind of things.

What about a switch, completion-include-alternate-completions or
something, that'd make completion-at-point do what I thought it did, ie
also run the other completion-at-point functions, and not stop at the
first one that returns non-nil, and then merge all these completions,
hopefully doing something clever when the START and END of these
different completions change between each one? Would that be doable?

Re: ERC completion

[Stefan Monnier]

> Right, I think I (finally) see. I thought the completion-at-point thingy
> was designed from the ground up to merge several completion sources,
> which is why I was thoroughly confused by this conversation.

It is designed for this, but for completions which are context
sensitive.

> Judging from the various codes on the internet
> (http://www.emacswiki.org/emacs/HippieExpand for instance), several
> others have a need for this kind of things.

Yes, that's why I'm keeping this thread open.

> What about a switch, completion-include-alternate-completions or
> something, that'd make completion-at-point do what I thought it did, ie
> also run the other completion-at-point functions, and not stop at the
> first one that returns non-nil, and then merge all these completions,
> hopefully doing something clever when the START and END of these
> different completions change between each one? Would that be doable?

I'm thinking of letting the completion function return some :fallthrough
option which would tell completion-at-point that in case the completion
data it returned leads to a completion failure, then it should continue
with the next completion function.

And yes, if the start&end of the various alternatives is the same, we
can merge them easily via completion-table-in-turn (which would have
effects such as: first try prefix-nick-completion, then
prefix-dabbrev-completion, then partial-nick-completion, then
partial-dabbrev-completion).  OTOH if start&end aren't the same it
forces separate calls to the completion UI, relying on the completion UI
to tell us whether the completion operation (whether it is to perform
completion, or to display completions, or whatever else)
was successful in order to know whether to try with the next
completion data.


        Stefan