gcc tab completion strangeness

gcc tab completion strangeness

[Peter Münster]

Hello,

After switching from version 5.13 to No Gnus, the tab completion on the
Gcc: line adds several spaces.

How could I avoid those spaces?

TIA for any help!
-- 
Peter Münster

Contact information: http://pmrb.free.fr/contact/

Re: gcc tab completion strangeness

[Tassilo Horn]

pmlists@free.fr (Peter Münster) writes:

Hi!

> After switching from version 5.13 to No Gnus, the tab completion on
> the Gcc: line adds several spaces.
>
> How could I avoid those spaces?

Oh, I've thought I'm the only one with these problems.  Does it really
happen only in Gcc lines?

Here, I also have that problem when completing mail addresses (from
bbdb) in From, To, or Cc.  However, it really happens only when
competing mail addresses.  Groups can be completed fine.

Bye,
Tassilo
-- 
Sent from my Emacs

Re: gcc tab completion strangeness

[Eric Abrahamsen]

On Mon, Jan 10 2011, Tassilo Horn wrote:

> pmlists@free.fr (Peter Münster) writes:
>
> Hi!
>
>> After switching from version 5.13 to No Gnus, the tab completion on
>> the Gcc: line adds several spaces.
>>
>> How could I avoid those spaces?
>
> Oh, I've thought I'm the only one with these problems.  Does it really
> happen only in Gcc lines?
>
> Here, I also have that problem when completing mail addresses (from
> bbdb) in From, To, or Cc.  However, it really happens only when
> competing mail addresses.  Groups can be completed fine.

Ditto here, in all address headers.

Re: gcc tab completion strangeness

[Adam Sjøgren]

On Mon, 10 Jan 2011 12:58:05 -0800, Eric wrote:

> On Mon, Jan 10 2011, Tassilo Horn wrote:

>> pmlists@free.fr (Peter Münster) writes:

>>> After switching from version 5.13 to No Gnus, the tab completion on
>>> the Gcc: line adds several spaces.

>>> How could I avoid those spaces?

>> Oh, I've thought I'm the only one with these problems.  Does it really
>> happen only in Gcc lines?

>> Here, I also have that problem when completing mail addresses (from
>> bbdb) in From, To, or Cc.  However, it really happens only when
>> competing mail addresses.  Groups can be completed fine.

> Ditto here, in all address headers.

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.

<http://git.gnus.org/cgit/gnus.git/commit/?id=9464be87c026c732bc4a0b15e533cef2cf55f1a4> 


  Best regards,

     Adam

-- 
 "Accept the mystery!"                                        Adam Sjøgren
                                                         asjo@koldfront.dk

Re: gcc tab completion strangeness

[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

Re: gcc tab completion strangeness

[Lars Ingebrigtsen]

asjo@koldfront.dk (Adam Sjøgren) writes:

> +         (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.

The patch looks OK to me, if that's the only way to get the bbdb stuff
working.  But I don't use bbdb, so I can't really tell.

Should I apply the patch?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: gcc tab completion strangeness

[Adam Sjøgren]

On Sun, 30 Jan 2011 18:18:03 -0800, Lars wrote:

> asjo@koldfront.dk (Adam Sjøgren) writes:

>> I looks quite ugly.
[...]

> The patch looks OK to me, if that's the only way to get the bbdb stuff
> working.  But I don't use bbdb, so I can't really tell.

> Should I apply the patch?

Stefan Monnier has come up with a less ugly solution, so I think his
patch should be applied; the updated one in <jwv62t47qh5.fsf-monnier+emacs@gnu.org>


  Best regards,

    Adam

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

Re: gcc tab completion strangeness

[Adam Sjøgren]

On Mon, 31 Jan 2011 10:05:38 -0500, Stefan wrote:

>> I looks quite ugly.

> Yes, I'd rather not hard code that much info about BBDB-internals in
> message.el.  Can you try the patch below instead, which should work
> about as well, but without relying on internal knowledge about BBDB?

In my brief testing your patch below works great - thanks for looking
into this!

> === modified file 'lisp/gnus/message.el'
> --- lisp/gnus/message.el	2011-01-25 04:08:28 +0000
> +++ lisp/gnus/message.el	2011-01-31 15:04:55 +0000
> @@ -7867,7 +7867,12 @@
>  	 (eudc-expand-inline))
>  	((and (memq 'bbdb message-expand-name-databases)
>  	      (fboundp 'bbdb-complete-name))
> -	 (bbdb-complete-name))
> +         (let ((starttick (buffer-modified-tick)))
> +           (or (bbdb-complete-name)
> +               ;; Apparently, bbdb-complete-name can return nil even when
> +               ;;  completion took place.  So let's double check the buffer was
> +               ;;  not modified.
> +               (!= starttick (buffer-modified-tick)))))
>  	(t
>  	 (expand-abbrev))))
 

  Best regards,

    Adam

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

Re: gcc tab completion strangeness

[Stefan Monnier]

>>> I looks quite ugly.
>> Yes, I'd rather not hard code that much info about BBDB-internals in
>> message.el.  Can you try the patch below instead, which should work
>> about as well, but without relying on internal knowledge about BBDB?
> In my brief testing your patch below works great - thanks for looking
> into this!

Must have been about as brief as my testing, indeed, since my patch
uses != which doesn't exist (it's called /= is Elisp).


        Stefan ;-)


=== modified file 'lisp/gnus/message.el'
--- lisp/gnus/message.el	2011-01-25 04:08:28 +0000
+++ lisp/gnus/message.el	2011-01-31 15:04:55 +0000
@@ -7867,7 +7867,12 @@
 	 (eudc-expand-inline))
 	((and (memq 'bbdb message-expand-name-databases)
 	      (fboundp 'bbdb-complete-name))
-	 (bbdb-complete-name))
+         (let ((starttick (buffer-modified-tick)))
+           (or (bbdb-complete-name)
+               ;; Apparently, bbdb-complete-name can return nil even when
+               ;;  completion took place.  So let's double check the buffer was
+               ;;  not modified.
+               (/= starttick (buffer-modified-tick)))))
 	(t
 	 (expand-abbrev))))
 

Re: gcc tab completion strangeness

[Adam Sjøgren]

On Mon, 31 Jan 2011 16:14:28 -0500, Stefan wrote:

>> In my brief testing your patch below works great - thanks for looking
>> into this!

> Must have been about as brief as my testing, indeed, since my patch
> uses != which doesn't exist (it's called /= is Elisp).

Haha, well, the _result_ was correct with !=, because it errored out
before the the part that inserts the bogus spaces, but I should have
paid more attention so I could have reported the error... :-)


  Thanks again,

    Adam

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

Re: gcc tab completion strangeness

[Stefan Monnier]

>>> In my brief testing your patch below works great - thanks for looking
>>> into this!
>> Must have been about as brief as my testing, indeed, since my patch
>> uses != which doesn't exist (it's called /= is Elisp).
> Haha, well, the _result_ was correct with !=, because it errored out
> before the the part that inserts the bogus spaces, but I should have
> paid more attention so I could have reported the error... :-)

Thanks, installed,


        Stefan

Re: gcc tab completion strangeness

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Must have been about as brief as my testing, indeed, since my patch
> uses != which doesn't exist (it's called /= is Elisp).
>
>         Stefan ;-)
>
> === modified file 'lisp/gnus/message.el'

Thanks.  Should I apply your patch via git Gnus, or are you doing it via
bzr Emacs?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: gcc tab completion strangeness

[Stefan Monnier]

>> Must have been about as brief as my testing, indeed, since my patch
>> uses != which doesn't exist (it's called /= is Elisp).
>> 
>> Stefan ;-)
>> 
>> === modified file 'lisp/gnus/message.el'

> Thanks.  Should I apply your patch via git Gnus, or are you doing it via
> bzr Emacs?

I've installed it in Emacs yesterday.


        Stefan

Re: gcc tab completion strangeness

[Gijs Hillenius]

On 10 Jan 2011, Peter Münster wrote:

> Hello,
>
> After switching from version 5.13 to No Gnus, the tab completion on the
> Gcc: line adds several spaces.
>
> How could I avoid those spaces?
>
> TIA for any help!

That sounds like this bug reported to Debian in December..

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607048