From: Eli Zaretskii <eliz@gnu.org>
To: Glenn Morris <rgm@gnu.org>
Cc: 6830@debbugs.gnu.org
Subject: bug#6830: widget-complete bad completions in :type 'file
Date: Fri, 24 Feb 2012 21:35:15 +0200 [thread overview]
Message-ID: <83ty2grpn0.fsf@gnu.org> (raw)
In-Reply-To: <wf1upmh7sr.fsf@fencepost.gnu.org>
> From: Glenn Morris <rgm@gnu.org>
> Date: Wed, 22 Feb 2012 16:33:56 -0500
>
> Chong Yidong wrote:
>
> > If I enter "~/aaa" in the widget field and there is no file starting
> > with "aaa" in my home directory, M-TAB does nothing except for
> > displaying "No match" in the echo area.
> >
> > This is with the latest trunk, on GNU/Linux.
>
> I also cannot reproduce this.
> If no-one can reproduce this using stock Emacs on MS Windows, I suggest
> closing this.
Please don't close it. IIUC (and I'm not at all sure, as the
complexity of wid-edit.el and minibuffer.el is above my pay-grade),
the fact that it works on GNU/Linux is sheer luck.
What seems to happen is this:
. widget-complete calls completion-in-region, which in turn calls
minibuffer-complete, after let-binding the necessary variables:
(let ((minibuffer-completion-table collection)
(minibuffer-completion-predicate predicate)
(ol (make-overlay start end nil nil t)))
(overlay-put ol 'field 'completion)
(when completion-in-region-mode-predicate
(completion-in-region-mode 1)
(setq completion-in-region--data
(list (current-buffer) start end collection)))
(unwind-protect
(call-interactively 'minibuffer-complete)
. minibuffer-complete calls completion--do-completion, which does
this at its very beginning:
(let* ((beg (field-beginning))
(end (field-end))
(string (buffer-substring beg end))
(md (completion--field-metadata beg))
On GNU/Linux, field-beginning is correctly computed to be at the
beginning of the field, and thus buffer-substring correctly
extracts whatever you typed into the field, and that substring is
thereafter correctly completed.
In contrast, on Windows, field-beginning returns the position of
point, so if point is at the end of whatever you typed (as it
usually is when one hits M-TAB), buffer-substring extracts an empty
string, which is then "completed" to the files in the
default-directory.
The difference between the two system is, so it seems, that
find_field, which is the workhorse of field-beginning, looks at
overlays at point and before point which have the `field' property.
The problem is that we have 2 such overlays before point: one whose
`field' value is `completion' (as can be seen above, this overlay is
put there by completion-in-region), and another whose `field' value is
identical to the `field' text property at point. Both of these
overlays have nil as their priority, so when
get_char_property_and_overlay sorts the overlays by priority, the
resulting order is arbitrary. On GNU/Linux, the first overlay in the
sorted array happens to be the one whose `field' value is equal to the
text property, so find_field works. On MS-Windows, the first overlay
is the one whose value is `completion', so find_field decides that the
field begins and ends at the same position. The rest, as they say, is
history.
I hope that this analysis (if it is correct) will allow someone
smarter than myself to figure out how to fix this.
next prev parent reply other threads:[~2012-02-24 19:35 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-09 11:45 bug#6830: widget-complete bad completions in :type 'file Lennart Borgman
2010-09-04 17:48 ` Chong Yidong
2010-09-04 22:16 ` Lennart Borgman
2010-09-05 1:47 ` Chong Yidong
2012-02-22 21:33 ` Glenn Morris
2012-02-22 23:02 ` Drew Adams
2012-02-22 23:51 ` Drew Adams
2012-02-23 3:57 ` Glenn Morris
2012-02-23 15:27 ` Drew Adams
2012-02-24 19:38 ` Eli Zaretskii
2012-02-25 12:16 ` Richard Stallman
2012-02-24 19:35 ` Eli Zaretskii [this message]
2012-02-24 19:47 ` Drew Adams
2012-02-25 3:30 ` Chong Yidong
2012-02-25 5:26 ` Stefan Monnier
2012-02-25 7:45 ` Eli Zaretskii
2012-02-25 6:54 ` Eli Zaretskii
2012-03-04 9:37 ` Chong Yidong
2012-03-04 17:06 ` Eli Zaretskii
2012-03-05 3:07 ` Chong Yidong
2012-03-05 17:28 ` Eli Zaretskii
2012-03-05 21:28 ` Stefan Monnier
2012-03-06 3:50 ` Eli Zaretskii
2012-03-06 20:45 ` Stefan Monnier
2012-03-06 21:12 ` Eli Zaretskii
2012-03-07 22:09 ` Stefan Monnier
2012-03-09 9:14 ` Eli Zaretskii
2012-03-09 16:35 ` Stefan Monnier
2012-03-09 16:46 ` Stefan Monnier
2012-03-12 8:36 ` Paul Eggert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83ty2grpn0.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=6830@debbugs.gnu.org \
--cc=rgm@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.