Re: gcc tab completion strangeness

[asjo@koldfront.dk (Adam Sjøgren)]

On Mon, 10 Jan 2011 23:27:01 +0100, Adam wrote:

> I thought it was just me as well when I saw it when completing in To:.

> git bisect says:

>   9464be87c026c732bc4a0b15e533cef2cf55f1a4 is the first bad commit
>   commit 9464be87c026c732bc4a0b15e533cef2cf55f1a4
>   Author: Stefan Monnier <monnier@iro.umontreal.ca>
>   Date:   Tue Dec 7 04:05:42 2010 +0000

>       message.el: Use completion-at-point.
>        (message-completion-function): New fun, extracted from message-tab.
>        (message-mode): Use it for completion-at-point-functions.
>        (message-tab): Use it and completion-at-point.

I have been edebugging this a little. The problem seems to be that
message-expand-name returns nil even when it completed something.

Here is the message-tab function:

    (defun message-tab ()
      "Complete names according to `message-completion-alist'.
    Execute function specified by `message-tab-body-function' when not in
    those headers."
      (interactive)
      (cond
       ((if (and (boundp 'completion-fail-discreetly)
                 (fboundp 'completion-at-point))
            (let ((completion-fail-discreetly t)) (completion-at-point))
          (funcall (or (message-completion-function) #'ignore)))
        ;; Completion was performed; nothing else to do.
        nil)
       (message-tab-body-function (funcall message-tab-body-function))
       (t (funcall (or (lookup-key text-mode-map "\t")
                       (lookup-key global-map "\t")
                       'indent-relative)))))

When I step through it, I hit (completion-at-point), and the To: line
gets completed, but the "cond" doesn't end there because
completion-at-point returns nil, and so it also tries the last two cond
clauses; the last one inserting the unwanted whitespace.

If I make the "if" take the "else" part, I get the completion in the To:
line and then the funcall returns nil, and the "cond" continues to the
two other clauses.

It looks like it boils down to message-expand-name returning nil because
bbdb-complete-name does. So, how to fix that...

This is the ugly, simple workaround:

--- a/lisp/message.el
+++ b/lisp/message.el
@@ -7911,7 +7911,8 @@ those headers."
         (eudc-expand-inline))
        ((and (memq 'bbdb message-expand-name-databases)
              (fboundp 'bbdb-complete-name))
-        (bbdb-complete-name))
+         (bbdb-complete-name)
+         t)
        (t
         (expand-abbrev))))

but then expand-abbrew won't be called when bbdb is available but fails...

Here is an attempt to return nil/t according to whether
bbdb-complete-name suceeded:

--- a/lisp/message.el
+++ b/lisp/message.el
@@ -7911,7 +7911,10 @@ those headers."
         (eudc-expand-inline))
        ((and (memq 'bbdb message-expand-name-databases)
              (fboundp 'bbdb-complete-name))
-        (bbdb-complete-name))
+         (let ((bbdb-complete-did-succeed nil)
+               (bbdb-complete-name-hooks '(lambda () (setq bbdb-complete-did-succeed t))))
+           (bbdb-complete-name)
+           bbdb-complete-did-succeed))
        (t
         (expand-abbrev))))

I looks quite ugly.

But it calls expand-abbrev if bbdb-complete-name doesn't complete.

And then the annoying whitespace is added.

Hm.


  Best regards,

    Adam

-- 
 "My ethicator machine must've had a built-in moral           Adam Sjøgren
  compromise spectral release phantasmatron!"            asjo@koldfront.dk