From unknown Tue Jun 17 01:50:44 2025 X-Loop: help-debbugs@gnu.org Subject: bug#12619: completion-at-point and changing buffer 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: To: 12619@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.134989875512686 (code B ref -1); Wed, 10 Oct 2012 19:53:01 +0000 Received: (at submit) by debbugs.gnu.org; 10 Oct 2012 19:52:35 +0000 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 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 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 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.2 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 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 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 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 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) Date: Wed, 10 Oct 2012 21:39:13 +0200 From: Jorgen Schaefer Message-ID: <20121010213913.46dc940b@forcix.kollektiv-hamburg.de> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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-Received-From: 208.118.235.17 X-Spam-Score: -4.2 (----) 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 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.2 (----) 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 From unknown Tue Jun 17 01:50:44 2025 X-Loop: help-debbugs@gnu.org Subject: bug#12619: completion-at-point and changing buffer Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 11 Oct 2012 00:39:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12619 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Jorgen Schaefer Cc: 12619@debbugs.gnu.org Received: via spool by 12619-submit@debbugs.gnu.org id=B12619.13499159125677 (code B ref 12619); Thu, 11 Oct 2012 00:39:02 +0000 Received: (at 12619) by debbugs.gnu.org; 11 Oct 2012 00:38:32 +0000 Received: from localhost ([127.0.0.1]:38355 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TM6nI-0001TW-D6 for submit@debbugs.gnu.org; Wed, 10 Oct 2012 20:38:32 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.182]:53810) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TM6nG-0001TF-Gy for 12619@debbugs.gnu.org; Wed, 10 Oct 2012 20:38:30 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAG6Zu09FxLQG/2dsb2JhbABEtBGBCIIVAQEEAVYjBQsLDiYSFBgNJIgcBboJkEQDozOBWIMF X-IronPort-AV: E=Sophos;i="4.75,637,1330923600"; d="scan'208";a="201063676" Received: from 69-196-180-6.dsl.teksavvy.com (HELO ceviche.home) ([69.196.180.6]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 10 Oct 2012 20:37:42 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 7C9A7660CA; Wed, 10 Oct 2012 20:37:42 -0400 (EDT) From: Stefan Monnier Message-ID: References: <20121010213913.46dc940b@forcix.kollektiv-hamburg.de> Date: Wed, 10 Oct 2012 20:37:42 -0400 In-Reply-To: <20121010213913.46dc940b@forcix.kollektiv-hamburg.de> (Jorgen Schaefer's message of "Wed, 10 Oct 2012 21:39:13 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.8 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.8 (/) > 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. Indeed, good point. > 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. Sounds OK, tho we should make sure that those values can't be nil or some other non-numeric thingy. > 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. Hmm...but if the buffer modification happens right in the middle of the completion text what should we do? Should we really ignore this modification? Stefan From unknown Tue Jun 17 01:50:44 2025 X-Loop: help-debbugs@gnu.org Subject: bug#12619: completion-at-point and changing buffer Resent-From: Jorgen Schaefer Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 11 Oct 2012 18:21:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12619 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 12619@debbugs.gnu.org Received: via spool by 12619-submit@debbugs.gnu.org id=B12619.13499796173802 (code B ref 12619); Thu, 11 Oct 2012 18:21:02 +0000 Received: (at 12619) by debbugs.gnu.org; 11 Oct 2012 18:20:17 +0000 Received: from localhost ([127.0.0.1]:39842 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TMNMn-0000zH-4e for submit@debbugs.gnu.org; Thu, 11 Oct 2012 14:20:17 -0400 Received: from istinn.electusmatari.com ([83.169.37.145]:44498) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TMNMj-0000z7-ST for 12619@debbugs.gnu.org; Thu, 11 Oct 2012 14:20:15 -0400 Received: from forcix.kollektiv-hamburg.de (hmbg-5f77d9d0.pool.mediaWays.net [95.119.217.208]) by istinn.electusmatari.com (Postfix) with ESMTPSA id 0077FD10037E; Thu, 11 Oct 2012 20:19:26 +0200 (CEST) Date: Thu, 11 Oct 2012 20:19:25 +0200 From: Jorgen Schaefer Message-ID: <20121011201925.76b56a54@forcix.kollektiv-hamburg.de> In-Reply-To: References: <20121010213913.46dc940b@forcix.kollektiv-hamburg.de> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.8 (/) On Wed, 10 Oct 2012 20:37:42 -0400 Stefan Monnier wrote: > > 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. > > Sounds OK, tho we should make sure that those values can't be nil > or some other non-numeric thingy. True, I think some of those values can be nil in some cases (didn't happen during my testing, though). Pity that neither `eql' nor `equal' work on markers. > > 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. > > Hmm...but if the buffer modification happens right in the middle of > the completion text what should we do? Should we really ignore > this modification? Actually, I have no idea what would happen then and couldn't make a test case to reproduce it easily. :-) The patch below flushes the cache if the changed text intersects with the completion text. --- lisp/minibuffer.el 2012-10-06 17:29:15 +0000 +++ lisp/minibuffer.el 2012-10-11 17:56:42 +0000 @@ -1048,12 +1048,29 @@ (defun completion--cache-all-sorted-completions (comps) (add-hook 'after-change-functions - 'completion--flush-all-sorted-completions nil t) + 'completion--flush-all-sorted-completions-after-change nil t) (setq completion-all-sorted-completions comps)) -(defun completion--flush-all-sorted-completions (&rest _ignore) +(defun completion--flush-all-sorted-completions-after-change (change-start change-end pre-change-length) + (let ((start (nth 1 completion-in-region--data)) + (end (nth 2 completion-in-region--data))) + (when (or + ;; We don't even have completion data + (not start) + (not end) + ;; Change completely before our completion, but our + ;; completion didn't use markers. + (and (<= change-end start) + (not (and (markerp start) + (markerp end)))) + ;; Change overlaps our completion, regardless of markers. + (not (or (< change-end start) + (< end change-start)))) + (completion--flush-all-sorted-completions)))) + +(defun completion--flush-all-sorted-completions () (remove-hook 'after-change-functions - 'completion--flush-all-sorted-completions t) + 'completion--flush-all-sorted-completions-after-change t) (setq completion-cycling nil) (setq completion-all-sorted-completions nil)) @@ -1882,8 +1899,12 @@ (let* ((completion-extra-properties plist) (completion-in-region-mode-predicate (lambda () - ;; We're still in the same completion field. - (eq (car-safe (funcall hookfun)) start)))) + (let ((old-start (car-safe (funcall hookfun)))) + ;; We're still in the same completion field. + (condition-case error + (= old-start start) + (error + (eq old-start start))))))) (completion-in-region start end collection (plist-get plist :predicate)))) ;; Maybe completion already happened and the function returned t. (I have no idea at what point patches are considered non-trivial for copyright reasons, but there should be an assignment "for all future contributions to Emacs" with the FSF.) Regards, -- Jorgen From unknown Tue Jun 17 01:50:44 2025 X-Loop: help-debbugs@gnu.org Subject: bug#12619: completion-at-point and changing buffer Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 24 Oct 2012 03:22:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12619 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Jorgen Schaefer Cc: 12619@debbugs.gnu.org Received: via spool by 12619-submit@debbugs.gnu.org id=B12619.135104888518716 (code B ref 12619); Wed, 24 Oct 2012 03:22:02 +0000 Received: (at 12619) by debbugs.gnu.org; 24 Oct 2012 03:21:25 +0000 Received: from localhost ([127.0.0.1]:58468 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TQrX2-0004ro-TY for submit@debbugs.gnu.org; Tue, 23 Oct 2012 23:21:25 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.182]:11631) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TQrX1-0004rc-CL for 12619@debbugs.gnu.org; Tue, 23 Oct 2012 23:21:23 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAG6Zu09Ld/pO/2dsb2JhbABEtBGBCIIWAQVWIxALDiYSFBgNJIghugmQRAOjM4FYgwU X-IronPort-AV: E=Sophos;i="4.75,637,1330923600"; d="scan'208";a="202594665" Received: from 75-119-250-78.dsl.teksavvy.com (HELO pastel.home) ([75.119.250.78]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 23 Oct 2012 23:19:21 -0400 Received: by pastel.home (Postfix, from userid 20848) id 2D80758CA3; Tue, 23 Oct 2012 23:19:21 -0400 (EDT) From: Stefan Monnier Message-ID: References: <20121010213913.46dc940b@forcix.kollektiv-hamburg.de> <20121011201925.76b56a54@forcix.kollektiv-hamburg.de> Date: Tue, 23 Oct 2012 23:19:21 -0400 In-Reply-To: <20121011201925.76b56a54@forcix.kollektiv-hamburg.de> (Jorgen Schaefer's message of "Thu, 11 Oct 2012 20:19:25 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.8 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.8 (/) I've just installed a patch which should solve those problems. Can you confirm it fixes your case? Stefan From unknown Tue Jun 17 01:50:44 2025 X-Loop: help-debbugs@gnu.org Subject: bug#12619: completion-at-point and changing buffer Resent-From: Jorgen Schaefer Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 24 Oct 2012 16:38:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12619 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 12619@debbugs.gnu.org Received: via spool by 12619-submit@debbugs.gnu.org id=B12619.135109667117417 (code B ref 12619); Wed, 24 Oct 2012 16:38:02 +0000 Received: (at 12619) by debbugs.gnu.org; 24 Oct 2012 16:37:51 +0000 Received: from localhost ([127.0.0.1]:59819 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TR3xm-0004Ws-Un for submit@debbugs.gnu.org; Wed, 24 Oct 2012 12:37:51 -0400 Received: from istinn.electusmatari.com ([83.169.37.145]:53854) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TR3xl-0004Wk-8d for 12619@debbugs.gnu.org; Wed, 24 Oct 2012 12:37:50 -0400 Received: from forcix.kollektiv-hamburg.de (hmbg-5f763134.pool.mediaWays.net [95.118.49.52]) by istinn.electusmatari.com (Postfix) with ESMTPSA id C2BE6D10037E; Wed, 24 Oct 2012 18:35:48 +0200 (CEST) Date: Wed, 24 Oct 2012 18:35:46 +0200 From: Jorgen Schaefer Message-ID: <20121024183546.77834f77@forcix.kollektiv-hamburg.de> In-Reply-To: References: <20121010213913.46dc940b@forcix.kollektiv-hamburg.de> <20121011201925.76b56a54@forcix.kollektiv-hamburg.de> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.8 (/) On Tue, 23 Oct 2012 23:19:21 -0400 Stefan Monnier wrote: > I've just installed a patch which should solve those problems. > Can you confirm it fixes your case? I'm afraid it doesn't (tested with trunk/110646). The problem is that `minibuffer-force-complete' uses `field-beginning' and `field-end', neither of which returns a marker. So even if the original function uses markers, at this point they are turned into absolute buffer positions. Wrapping both calls in `copy-marker' fixes the problem for me. Regards, -- Jorgen From unknown Tue Jun 17 01:50:44 2025 X-Loop: help-debbugs@gnu.org Subject: bug#12619: completion-at-point and changing buffer Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 24 Oct 2012 17:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12619 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Jorgen Schaefer Cc: 12619@debbugs.gnu.org Received: via spool by 12619-submit@debbugs.gnu.org id=B12619.135110104623977 (code B ref 12619); Wed, 24 Oct 2012 17:51:02 +0000 Received: (at 12619) by debbugs.gnu.org; 24 Oct 2012 17:50:46 +0000 Received: from localhost ([127.0.0.1]:59926 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TR56M-0006Eg-Cc for submit@debbugs.gnu.org; Wed, 24 Oct 2012 13:50:46 -0400 Received: from relais.videotron.ca ([24.201.245.36]:20176) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TR56J-0006EX-6D for 12619@debbugs.gnu.org; Wed, 24 Oct 2012 13:50:45 -0400 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from ceviche.home ([96.21.127.30]) by VL-VM-MR002.ip.videotron.ca (Oracle Communications Messaging Exchange Server 7u4-22.01 64bit (built Apr 21 2011)) with ESMTP id <0MCE00A45S4XE160@VL-VM-MR002.ip.videotron.ca> for 12619@debbugs.gnu.org; Wed, 24 Oct 2012 13:48:34 -0400 (EDT) Received: by ceviche.home (Postfix, from userid 20848) id B6572661F0; Wed, 24 Oct 2012 13:48:33 -0400 (EDT) From: Stefan Monnier Message-id: References: <20121010213913.46dc940b@forcix.kollektiv-hamburg.de> <20121011201925.76b56a54@forcix.kollektiv-hamburg.de> <20121024183546.77834f77@forcix.kollektiv-hamburg.de> Date: Wed, 24 Oct 2012 13:48:33 -0400 In-reply-to: <20121024183546.77834f77@forcix.kollektiv-hamburg.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux) X-Spam-Score: 1.6 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: >> I've just installed a patch which should solve those problems. >> Can you confirm it fixes your case? > I'm afraid it doesn't (tested with trunk/110646). The problem is that > `minibuffer-force-complete' uses `field-beginning' and `field-end', > neither of which returns a marker. So even if the original function > uses markers, at this point they are turned into absolute buffer > positions. > Wrapping both calls in `copy-marker' fixes the problem for me. [...] Content analysis details: (1.6 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [24.201.245.36 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] 0.1 HDRS_LCASE Odd capitalization of message header 0.0 T_MANY_HDRS_LCASE Odd capitalization of multiple message headers X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: >> I've just installed a patch which should solve those problems. >> Can you confirm it fixes your case? > I'm afraid it doesn't (tested with trunk/110646). The problem is that > `minibuffer-force-complete' uses `field-beginning' and `field-end', > neither of which returns a marker. So even if the original function > uses markers, at this point they are turned into absolute buffer > positions. > Wrapping both calls in `copy-marker' fixes the problem for me. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [24.201.245.36 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] >> I've just installed a patch which should solve those problems. >> Can you confirm it fixes your case? > I'm afraid it doesn't (tested with trunk/110646). The problem is that > `minibuffer-force-complete' uses `field-beginning' and `field-end', > neither of which returns a marker. So even if the original function > uses markers, at this point they are turned into absolute buffer > positions. > Wrapping both calls in `copy-marker' fixes the problem for me. You mean the patch below? I guess you're right, it's still needed for the use of `start' in: (lambda () "Cycle through the possible completions." (interactive) (let ((completion-extra-properties extra-prop)) (completion-in-region start (point) table pred))))) Can you confirm that this patch fixes it? Stefan === modified file 'lisp/minibuffer.el' --- lisp/minibuffer.el 2012-10-24 03:22:21 +0000 +++ lisp/minibuffer.el 2012-10-24 17:47:17 +0000 @@ -1114,7 +1114,7 @@ ;; FIXME: Need to deal with the extra-size issue here as well. ;; FIXME: ~/src/emacs/t/lisp/minibuffer.el completes to ;; ~/src/emacs/trunk/ and throws away lisp/minibuffer.el. - (let* ((start (field-beginning)) + (let* ((start (copy-marker (field-beginning))) (end (field-end)) ;; (md (completion--field-metadata start)) (all (completion-all-sorted-completions)) From unknown Tue Jun 17 01:50:44 2025 X-Loop: help-debbugs@gnu.org Subject: bug#12619: completion-at-point and changing buffer Resent-From: Jorgen Schaefer Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 24 Oct 2012 19:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12619 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 12619@debbugs.gnu.org Received: via spool by 12619-submit@debbugs.gnu.org id=B12619.13511052201240 (code B ref 12619); Wed, 24 Oct 2012 19:01:02 +0000 Received: (at 12619) by debbugs.gnu.org; 24 Oct 2012 19:00:20 +0000 Received: from localhost ([127.0.0.1]:60002 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TR6Bg-0000Jx-KY for submit@debbugs.gnu.org; Wed, 24 Oct 2012 15:00:20 -0400 Received: from istinn.electusmatari.com ([83.169.37.145]:36922) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TR6Be-0000Jp-CQ for 12619@debbugs.gnu.org; Wed, 24 Oct 2012 15:00:19 -0400 Received: from forcix.kollektiv-hamburg.de (hmbg-5f763134.pool.mediaWays.net [95.118.49.52]) by istinn.electusmatari.com (Postfix) with ESMTPSA id A6568D10037E; Wed, 24 Oct 2012 20:58:17 +0200 (CEST) Date: Wed, 24 Oct 2012 20:58:15 +0200 From: Jorgen Schaefer Message-ID: <20121024205815.50b023ba@forcix.kollektiv-hamburg.de> In-Reply-To: References: <20121010213913.46dc940b@forcix.kollektiv-hamburg.de> <20121011201925.76b56a54@forcix.kollektiv-hamburg.de> <20121024183546.77834f77@forcix.kollektiv-hamburg.de> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.8 (/) On Wed, 24 Oct 2012 13:48:33 -0400 Stefan Monnier wrote: > You mean the patch below? > I guess you're right, it's still needed for the use of `start' in: > > (lambda () "Cycle through the possible completions." > (interactive) > (let ((completion-extra-properties extra-prop)) > (completion-in-region start (point) table pred))))) > > Can you confirm that this patch fixes it? It does indeed. :-) -- Jorgen From unknown Tue Jun 17 01:50:44 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.428 (Entity 5.428) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Jorgen Schaefer Subject: bug#12619: closed (Re: bug#12619: completion-at-point and changing buffer) Message-ID: References: <20121010213913.46dc940b@forcix.kollektiv-hamburg.de> X-Gnu-PR-Message: they-closed 12619 X-Gnu-PR-Package: emacs Reply-To: 12619@debbugs.gnu.org Date: Wed, 24 Oct 2012 19:43:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1351107782-4832-1" This is a multi-part message in MIME format... ------------=_1351107782-4832-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #12619: completion-at-point and changing buffer which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 12619@debbugs.gnu.org. --=20 12619: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D12619 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1351107782-4832-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 12619-done) by debbugs.gnu.org; 24 Oct 2012 19:42:51 +0000 Received: from localhost ([127.0.0.1]:60033 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TR6qo-0001Fa-LB for submit@debbugs.gnu.org; Wed, 24 Oct 2012 15:42:50 -0400 Received: from relais.videotron.ca ([24.201.245.36]:38560) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TR6qm-0001FT-Tb for 12619-done@debbugs.gnu.org; Wed, 24 Oct 2012 15:42:49 -0400 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from ceviche.home ([96.21.127.30]) by VL-VM-MR001.ip.videotron.ca (Oracle Communications Messaging Exchange Server 7u4-22.01 64bit (built Apr 21 2011)) with ESMTP id <0MCE0012TXC0ZC00@VL-VM-MR001.ip.videotron.ca> for 12619-done@debbugs.gnu.org; Wed, 24 Oct 2012 15:40:48 -0400 (EDT) Received: by ceviche.home (Postfix, from userid 20848) id A2501661F0; Wed, 24 Oct 2012 15:40:48 -0400 (EDT) From: Stefan Monnier To: Jorgen Schaefer Subject: Re: bug#12619: completion-at-point and changing buffer Message-id: References: <20121010213913.46dc940b@forcix.kollektiv-hamburg.de> <20121011201925.76b56a54@forcix.kollektiv-hamburg.de> <20121024183546.77834f77@forcix.kollektiv-hamburg.de> <20121024205815.50b023ba@forcix.kollektiv-hamburg.de> Date: Wed, 24 Oct 2012 15:40:48 -0400 In-reply-to: <20121024205815.50b023ba@forcix.kollektiv-hamburg.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux) X-Spam-Score: 1.6 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: >> Can you confirm that this patch fixes it? > It does indeed. :-) Thanks, installed, Stefan [...] Content analysis details: (1.6 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [24.201.245.36 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] 0.1 HDRS_LCASE Odd capitalization of message header 0.0 T_MANY_HDRS_LCASE Odd capitalization of multiple message headers X-Debbugs-Envelope-To: 12619-done Cc: 12619-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: >> Can you confirm that this patch fixes it? > It does indeed. :-) Thanks, installed, Stefan [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [24.201.245.36 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4449] >> Can you confirm that this patch fixes it? > It does indeed. :-) Thanks, installed, Stefan ------------=_1351107782-4832-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 10 Oct 2012 19:52:35 +0000 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 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 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 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.2 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 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 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 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 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) Date: Wed, 10 Oct 2012 21:39:13 +0200 From: Jorgen Schaefer To: bug-gnu-emacs@gnu.org Subject: completion-at-point and changing buffer Message-ID: <20121010213913.46dc940b@forcix.kollektiv-hamburg.de> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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-Received-From: 208.118.235.17 X-Spam-Score: -4.2 (----) X-Debbugs-Envelope-To: submit 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 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.2 (----) 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 ------------=_1351107782-4832-1--