Re: ERC completion

[Antoine Levitt <antoine.levitt@gmail.com>]

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?)