From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jorgen Schaefer Newsgroups: gmane.emacs.bugs Subject: bug#12619: completion-at-point and changing buffer Date: Wed, 10 Oct 2012 21:39:13 +0200 Message-ID: <20121010213913.46dc940b@forcix.kollektiv-hamburg.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1349898751 2798 80.91.229.3 (10 Oct 2012 19:52:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 10 Oct 2012 19:52:31 +0000 (UTC) To: 12619@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Oct 10 21:52:36 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TM2KW-0005CR-AB for geb-bug-gnu-emacs@m.gmane.org; Wed, 10 Oct 2012 21:52:32 +0200 Original-Received: from localhost ([::1]:43603 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TM2KQ-0002qC-2p for geb-bug-gnu-emacs@m.gmane.org; Wed, 10 Oct 2012 15:52:26 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:33461) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TM2KM-0002pt-SH for bug-gnu-emacs@gnu.org; Wed, 10 Oct 2012 15:52:24 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TM2KL-0000bi-Sk for bug-gnu-emacs@gnu.org; Wed, 10 Oct 2012 15:52:22 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:56054) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TM2KL-0000be-Or for bug-gnu-emacs@gnu.org; Wed, 10 Oct 2012 15:52:21 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TM2Kz-0003JG-OA for bug-gnu-emacs@gnu.org; Wed, 10 Oct 2012 15:53:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Jorgen Schaefer Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 10 Oct 2012 19:53:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 12619 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.134989875512686 (code B ref -1); Wed, 10 Oct 2012 19:53:01 +0000 Original-Received: (at submit) by debbugs.gnu.org; 10 Oct 2012 19:52:35 +0000 Original-Received: from localhost ([127.0.0.1]:38072 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TM2KY-0003IZ-JH for submit@debbugs.gnu.org; Wed, 10 Oct 2012 15:52:35 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:44922) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TM28W-00030F-VN for submit@debbugs.gnu.org; Wed, 10 Oct 2012 15:40:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TM27m-00045f-6O for submit@debbugs.gnu.org; Wed, 10 Oct 2012 15:39:23 -0400 Original-Received: from lists.gnu.org ([208.118.235.17]:49308) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TM27m-00045b-3p for submit@debbugs.gnu.org; Wed, 10 Oct 2012 15:39:22 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:58356) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TM27k-0008Pb-VD for bug-gnu-emacs@gnu.org; Wed, 10 Oct 2012 15:39:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TM27j-000458-Jj for bug-gnu-emacs@gnu.org; Wed, 10 Oct 2012 15:39:20 -0400 Original-Received: from istinn.electusmatari.com ([83.169.37.145]:53294) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TM27j-00043U-9m for bug-gnu-emacs@gnu.org; Wed, 10 Oct 2012 15:39:19 -0400 Original-Received: from forcix.kollektiv-hamburg.de (hmbg-5f77e47c.pool.mediaWays.net [95.119.228.124]) by istinn.electusmatari.com (Postfix) with ESMTPSA id 89DEED10037E for ; Wed, 10 Oct 2012 21:39:15 +0200 (CEST) X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; i486-pc-linux-gnu) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Mailman-Approved-At: Wed, 10 Oct 2012 15:52:32 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:65470 Archived-At: Hello! In the process of porting our IRC client to the `completion-at-point-functions' interface, we have noticed the following behavior: When using cycle completion (using `completion-cycle-threshold'), the completion cycle gets aborted if the buffer contents are modified. For an IRC buffer, this means that the completion cycle terminates when new text arrives. The same problem should be the case for other process-related buffers, like shells with regular output or similar. This is very confusing because the text change is expected and does not interfere with the completion text at all. While hunting down this bug, I have found two changes to minibuffer.el that solve my problem and *seem* not to introduce (major) other problems. First, in `completion-at-point', `completion-in-region-mode-predicate' is set to a function that compares the old start value with the new using `eq'. This prevents markers to work in this case. Simply replacing `eq' with `=' means markers work, so the positions used by completion just move together with text changes. Second, `completion--cache-all-sorted-completions' adds a function to `after-change-functions' that cleans up the cache of sorted completions. I'm not entirely sure why it does so, but my patch adds that function only if not both of the returned positions are markers. I'm unsure about possible ramifications of the second change. It might be that completion needs to terminate on text change that will not be caught by the other tests, but that I have not thought of. But if not, or if those cases are minor, these changes would be really useful. 2012-10-10 Jorgen Schaefer * minibuffer.el (completion--cache-all-sorted-completions): Don't clean cache on text change if the completion code uses markers, as those follow text changes. * minibuffer.el (completion-at-point): Compare completion positions using `=' instead of `eq' to support markers in addition of fixed integers. -----8<----------8<----- --- lisp/minibuffer.el 2012-10-06 17:29:15 +0000 +++ lisp/minibuffer.el 2012-10-10 19:10:40 +0000 @@ -1047,8 +1047,12 @@ (_ t))))) (defun completion--cache-all-sorted-completions (comps) - (add-hook 'after-change-functions - 'completion--flush-all-sorted-completions nil t) + ;; Flush the cache on text change only if the given indicators for + ;; the completion are not markers that move with the change. + (when (or (not (markerp (nth 1 completion-in-region--data))) + (not (markerp (nth 2 completion-in-region--data)))) + (add-hook 'after-change-functions + 'completion--flush-all-sorted-completions nil t)) (setq completion-all-sorted-completions comps)) (defun completion--flush-all-sorted-completions (&rest _ignore) @@ -1883,7 +1887,7 @@ (completion-in-region-mode-predicate (lambda () ;; We're still in the same completion field. - (eq (car-safe (funcall hookfun)) start)))) + (= (car-safe (funcall hookfun)) start)))) (completion-in-region start end collection (plist-get plist :predicate)))) ;; Maybe completion already happened and the function returned t. ----->8---------->8----- Regards, -- Jorgen