From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/76134 Path: news.gmane.org!not-for-mail From: asjo@koldfront.dk (Adam =?utf-8?Q?Sj=C3=B8gren?=) Newsgroups: gmane.emacs.gnus.general Subject: Re: gcc tab completion strangeness Date: Sun, 30 Jan 2011 14:49:06 +0100 Organization: koldfront - analysis & revolution, Copenhagen, Denmark Message-ID: <87sjwa5wod.fsf@topper.koldfront.dk> References: <871v4kio15.fsf@micropit.couberia.bzh> <87lj2sbidu.fsf@member.fsf.org> <87pqs4jx2a.fsf@ericabrahamsen.net> <87ipxwwg22.fsf@topper.koldfront.dk> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: dough.gmane.org 1296395378 25528 80.91.229.12 (30 Jan 2011 13:49:38 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 30 Jan 2011 13:49:38 +0000 (UTC) Cc: Stefan Monnier To: ding@gnus.org Original-X-From: ding-owner+M24486@lists.math.uh.edu Sun Jan 30 14:49:34 2011 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PjXen-0001aL-Q4 for ding-account@gmane.org; Sun, 30 Jan 2011 14:49:34 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1PjXed-0002T3-D3; Sun, 30 Jan 2011 07:49:23 -0600 Original-Received: from mx2.math.uh.edu ([129.7.128.33]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1PjXeb-0002Sw-M1 for ding@lists.math.uh.edu; Sun, 30 Jan 2011 07:49:21 -0600 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx2.math.uh.edu with esmtp (Exim 4.72) (envelope-from ) id 1PjXeZ-0005tJ-SX for ding@lists.math.uh.edu; Sun, 30 Jan 2011 07:49:21 -0600 Original-Received: from lo.gmane.org ([80.91.229.12]) by quimby.gnus.org with esmtp (Exim 4.72) (envelope-from ) id 1PjXeX-0002lF-Nd for ding@gnus.org; Sun, 30 Jan 2011 14:49:17 +0100 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PjXeX-0001Vj-1s for ding@gnus.org; Sun, 30 Jan 2011 14:49:17 +0100 Original-Received: from rain.gmane.org ([80.91.229.7]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 30 Jan 2011 14:49:17 +0100 Original-Received: from asjo by rain.gmane.org with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 30 Jan 2011 14:49:17 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: ding@gnus.org Original-Lines: 99 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: rain.gmane.org Mail-Copies-To: never X-Now-Playing: Richard Lewis, Theme Time Radio Hour - Hello (Bob Dylan) X-Face: )qY&CseJ?.:=8F#^~GcSA?F=9eu'{KAFfL1C3/A&:nE?PW\i65"ba0NS)97,Q(^@xk}n4Ou rPuR#V8I(J_@~H($[ym:`K_+]*kjvW>xH5jbgLBVFGXY:(#4P>zVBklLbdL&XxL\M)%T}3S/IS9lMJ ^St'=VZBR Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:76134 Archived-At: 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 > 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