GNU bug report logs - #12619
completion-at-point and changing buffer

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Jorgen Schaefer <forcer <at> forcix.cx>
Subject: bug#12619: closed (Re: bug#12619: completion-at-point and
 changing buffer)
Date: Wed, 24 Oct 2012 19:43:02 +0000

[Message part 1 (text/plain, inline)]

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 <at> debbugs.gnu.org.

-- 
12619: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12619
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Jorgen Schaefer <forcer <at> forcix.cx>
Cc: 12619-done <at> debbugs.gnu.org
Subject: Re: bug#12619: completion-at-point and changing buffer
Date: Wed, 24 Oct 2012 15:40:48 -0400

>> Can you confirm that this patch fixes it?
> It does indeed. :-)

Thanks, installed,


        Stefan

[Message part 3 (message/rfc822, inline)]

From: Jorgen Schaefer <forcer <at> forcix.cx>
To: bug-gnu-emacs <at> gnu.org
Subject: completion-at-point and changing buffer
Date: Wed, 10 Oct 2012 21:39:13 +0200

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  <forcer <at> forcix.cx>

        * 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.