[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debbugs-tracker] bug#12619: closed (completion-at-point and changing bu

From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#12619: closed (completion-at-point and changing buffer)
Date: Wed, 24 Oct 2012 19:43:02 +0000

Your message dated Wed, 24 Oct 2012 15:40:48 -0400
with message-id <address@hidden>
and subject line Re: bug#12619: completion-at-point and changing buffer
has caused the debbugs.gnu.org bug report #12619,
regarding completion-at-point and changing buffer
to be marked as done.

(If you believe you have received this mail in error, please contact

12619: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12619
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: completion-at-point and changing buffer Date: Wed, 10 Oct 2012 21:39:13 +0200
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

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  <address@hidden>

        * 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.

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

        -- Jorgen

--- End Message ---
--- Begin Message --- Subject: Re: bug#12619: completion-at-point and changing buffer Date: Wed, 24 Oct 2012 15:40:48 -0400 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux)
>> Can you confirm that this patch fixes it?
> It does indeed. :-)

Thanks, installed,


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]