GNU bug report logs - #6830
widget-complete bad completions in :type 'file

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Chong Yidong <cyd <at> gnu.org>
Cc: rgm <at> gnu.org, 6830 <at> debbugs.gnu.org
Subject: bug#6830: widget-complete bad completions in :type 'file
Date: Mon, 05 Mar 2012 19:28:14 +0200

> From: Chong Yidong <cyd <at> gnu.org>
> Cc: rgm <at> gnu.org,  6830 <at> debbugs.gnu.org
> Date: Mon, 05 Mar 2012 11:07:44 +0800
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > What do you get on GNU/Linux for the values of `field',
> > `before_field', and `after_field'?
> 
> This is from doing M-x customize-variable RET abbrev-file-name RET, and
> doing C-M-i after the end of the file name in the editable field:
> 
> (gdb) pp after_field
> boundary
> (gdb) pp before_field
> completion
> (gdb) pp field
> completion

Then it looks like my analysis was partially incorrect: I assumed that
the problem was with the value of `before_field', but it actually is
with the value of `field'.  (Same reason, though: sorting two items
whose keys compare equal.)

> >> FWIW, increasing the priority of the `completion' overlay does not cause
> >> widget file name completion to fail on GNU/Linux.  Could you try on
> >> Windows?
> >
> > Give me a patch to try, and I will.
> 
> === modified file 'lisp/minibuffer.el'
> *** lisp/minibuffer.el	2012-02-23 15:41:12 +0000
> --- lisp/minibuffer.el	2012-03-05 03:04:20 +0000
> ***************
> *** 1483,1488 ****
> --- 1483,1489 ----
>             (minibuffer-completion-predicate predicate)
>             (ol (make-overlay start end nil nil t)))
>         (overlay-put ol 'field 'completion)
> +       (overlay-put ol 'priority 5)
>         (when completion-in-region-mode-predicate
>           (completion-in-region-mode 1)
>           (setq completion-in-region--data

Yes, this fixes the problem, thanks.

But is this a safe solution?  Can we safely assume that no code in
widget.el or its companions will ever run between overlay-put and
delete-overlay in the above function?  If some widget.el code can run
in between, it will find a value of the field property different from
what it expects.

In general, the semantics of having more than one overlay with the
same property on the same text is only clear to me when these
properties specify display features, or more generally features
related to the same parent feature.  Otherwise, it's not really clear
what the precedence means; if we use it just as a means to get the
upper hand in some use-case, we are running the risk that some other
use-case will lose.

Previous Next

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