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.