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

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Jorgen Schaefer <forcer <at> forcix.cx>
Cc: 12619 <at> debbugs.gnu.org
Subject: bug#12619: completion-at-point and changing buffer
Date: Wed, 10 Oct 2012 20:37:42 -0400

> 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

Previous Next

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