--- Begin Message ---
|
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 <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.
-----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
--- 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,
Stefan
--- End Message ---