GNU bug report logs -
#10721
24.0.93; M-TAB for :type (file :must-match t) in Customize
Previous Next
Reported by: "Drew Adams" <drew.adams <at> oracle.com>
Date: Sat, 4 Feb 2012 16:38:02 UTC
Severity: minor
Found in version 24.0.93
Done: Chong Yidong <cyd <at> gnu.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 10721 in the body.
You can then email your comments to 10721 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#10721
; Package
emacs
.
(Sat, 04 Feb 2012 16:38:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
"Drew Adams" <drew.adams <at> oracle.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Sat, 04 Feb 2012 16:38:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
(elisp) `Simple Types' says "The value must be a file name
for an existing file, and you can do completion with `M-<TAB>'."
That's vague, but I would expect that the text in the edit field is
somehow completed. The actual behavior is not described and somewhat
surprising.
When I try `M-TAB' in the edit field for a must-match file name, the set
of completion candidates displayed seems to be the file names that match
the text that follows, not precedes, point in the edit field. And
matching seems to be substring matching rather than prefix matching.
Is that really what this is supposed to do? Why is the text _after_
point "completed" (matched), rather than the text before point?
E.g. if the text in the field is "te" and point is on the `t' then I see
substring matches for "te". If point is after the `e' then I see
matches for _all_ files in the `default-directory' (which hardly
"completes" the text in the edit field - it is apparently completing
the empty string).
If this is not the intended behavior, please fix according to what is
intended (whatever that is).
Whatever the behavior, please document it. The doc in the manual is too
vague: "you can do completion with `M-<TAB>'". It tells you nothing
about what "completion" behavior to expect. In particular, it should
say what it is that is completed (which text), and it should say what
kind of matching is used - IOW, how the text that is completed is
matched against the names of the existing files.
In GNU Emacs 24.0.93.1 (i386-mingw-nt5.1.2600)
of 2012-01-29 on MARVIN
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
`configure --with-gcc (4.6) --no-opt --cflags
-ID:/devel/emacs/libs/libXpm-3.5.8/include
-ID:/devel/emacs/libs/libXpm-3.5.8/src
-ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
-ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
-ID:/devel/emacs/libs/giflib-4.1.4-1/include
-ID:/devel/emacs/libs/jpeg-6b-4/include
-ID:/devel/emacs/libs/tiff-3.8.2-1/include
-ID:/devel/emacs/libs/gnutls-3.0.9/include --ldflags
-LD:/devel/emacs/libs/gnutls-3.0.9/lib'
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#10721
; Package
emacs
.
(Mon, 06 Feb 2012 14:04:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 10721 <at> debbugs.gnu.org (full text, mbox):
> When I try `M-TAB' in the edit field for a must-match file name, the set
> of completion candidates displayed seems to be the file names that match
> the text that follows, not precedes, point in the edit field. And
> matching seems to be substring matching rather than prefix matching.
> Is that really what this is supposed to do? Why is the text _after_
> point "completed" (matched), rather than the text before point?
Sounds odd. Could yo include a recipe?
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#10721
; Package
emacs
.
(Mon, 06 Feb 2012 15:39:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 10721 <at> debbugs.gnu.org (full text, mbox):
> Sounds odd. Could yo include a recipe?
1. See also bug #8397.
2. emacs -Q
M-x customize-face font-lock-comment-delimiter-face
Delete the text in the Face: field.
Type c in that field.
M-TAB ; you see the completions for `c'
Type u in that field, so you have `cu', with point after the `u'.
M-TAB ; you see all completions for all faces, not the faces that start with
`cu' or that have substring `cu'.
Etc.
Move point to before the `c' in `cu'. Hit M-TAB.
Now you see the completions for face names with substring `cu'.
Move point to between the `c' and `u' in `cu'. Hit M-TAB.
Point is moved after the `u'. And you see the completions for all face names,
not just those with `c' or `u' or `cu' as substring.
Etc.
Type an `r', so the field has `cur'. With point after the `r', hit `M-TAB'.
You see all completions for all face names.
Move point before the `c'. M-TAB completes the input to `cursor' correctly.
Put back only `cur'. Move point before the `r'. Hit M-TAB. You see the face
names that have `cu' as prefix (and not as substring).
Etc.
Contrast with Emacs 23. This surprising or "odd" behavior is a regression.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#10721
; Package
emacs
.
(Mon, 06 Feb 2012 21:03:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 10721 <at> debbugs.gnu.org (full text, mbox):
>> Sounds odd. Could you include a recipe?
> 1. See also bug #8397.
It doesn't seem directly relevant.
> 2. emacs -Q
> M-x customize-face font-lock-comment-delimiter-face
> Delete the text in the Face: field.
> Type c in that field.
> M-TAB ; you see the completions for `c'
Indeed, I see completions starting with "c".
> Type u in that field, so you have `cu', with point after the `u'.
> M-TAB ; you see all completions for all faces, not the faces that start with
> `cu' or that have substring `cu'.
No, I see completions starting with "cu".
We must be doing something different, but I don't know what. I typed:
% emacs -Q
M-x customize-face RET font-lock-comment-delimiter-face RET
click on "font-lock-comment-face"
C-a C-k
c M-TAB u M-TAB
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#10721
; Package
emacs
.
(Mon, 06 Feb 2012 21:28:03 GMT)
Full text and
rfc822 format available.
Message #17 received at 10721 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> > emacs -Q
> > M-x customize-face font-lock-comment-delimiter-face
> > Delete the text in the Face: field.
> > Type c in that field.
> > M-TAB ; you see the completions for `c'
>
> Indeed, I see completions starting with "c".
I was mistaken saying that. See below.
> > Type u in that field, so you have `cu', with point after the `u'.
> > M-TAB ; you see all completions for all faces, not the
> > faces that start with `cu' or that have substring `cu'.
>
> No, I see completions starting with "cu".
> We must be doing something different, but I don't know what. I typed:
> % emacs -Q
> M-x customize-face RET font-lock-comment-delimiter-face RET
> click on "font-lock-comment-face"
> C-a C-k
> c M-TAB u M-TAB
I'm using the latest Windows binary:
In GNU Emacs 24.0.93.1 (i386-mingw-nt5.1.2600)
of 2012-01-29 on MARVIN
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
`configure --with-gcc (4.6) --no-opt --cflags
-ID:/devel/emacs/libs/libXpm-3.5.8/include
-ID:/devel/emacs/libs/libXpm-3.5.8/src
-ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
-ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
-ID:/devel/emacs/libs/giflib-4.1.4-1/include
-ID:/devel/emacs/libs/jpeg-6b-4/include
-ID:/devel/emacs/libs/tiff-3.8.2-1/include
-ID:/devel/emacs/libs/gnutls-3.0.9/include --ldflags
-LD:/devel/emacs/libs/gnutls-3.0.9/lib'
Are you?
Actually, even after typing `c' and hitting M-TAB (your recipe and mine), I see
all possible font names, not just those containing `c'.
And after typing `u' and hitting M-TAB again (still with point at the end, i.e.,
after `u'), I still see all possible font names, not just those with `c' or `u'
or `cu'.
Again, I must move point to be _before_ the text for M-TAB to match it (as a
substring). Before `c' with only `c' present it shows all font names containing
`c'. After `c' with only `c' present it shows _all_ font names.
Before `c' with `cu' present it shows all font names having substring `cu'.
Before `u' with `cu' present, however, it shows _all_ font names (not just names
containing `u'), and it moves point after the `u'. After `u' with `cu' present
it shows _all_ font names (same).
See attachment.
Perhaps the problem is platform-specific?
[throw-emacs-bug-10721.png (image/png, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#10721
; Package
emacs
.
(Tue, 07 Feb 2012 02:54:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 10721 <at> debbugs.gnu.org (full text, mbox):
> I'm using the latest Windows binary:
[...]
> Are you?
No, I'm luckily using a Free system.
> Perhaps the problem is platform-specific?
Sounds unlikely, but of course, it's possible. Can someone else
reproduce the problem?
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#10721
; Package
emacs
.
(Tue, 07 Feb 2012 05:56:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 10721 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> I'm using the latest Windows binary:
> [...]
>> Are you?
>
> No, I'm luckily using a Free system.
>
>> Perhaps the problem is platform-specific?
>
> Sounds unlikely, but of course, it's possible. Can someone else
> reproduce the problem?
Not me (also on GNU/Linux).
But if the recipe involves face names, the bug title is misleading. It
appears that general inline completion in fields is broken for Drew;
nothing to do with (file :must-match t) types.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#10721
; Package
emacs
.
(Tue, 07 Feb 2012 16:46:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 10721 <at> debbugs.gnu.org (full text, mbox):
> But if the recipe involves face names, the bug title is
> misleading. It appears that general inline completion in
> fields is broken
> nothing to do with (file :must-match t) types.
Correct - it seems that all such completion fields are broken (or at least all
that I have tried). The bug report mentioned `(file :must-match t)' because
that is where I first noticed this regression.
Here's another recipe, this time with `(file :must-match t)'. This provides a
little more info that might help: For file names, it seems that
`default-directory' is used, even if the input file name starts with "~/".
(defcustom foobar "~/.emacs"
""
:type '(file :must-match t)
:group 'convenience)
Note: "~/" is "c:/" for me. Change the default value of the option to a
corresponding file on your system, and change the rest of the recipe
accordingly.
`M-x customize-option foobar'
Put point after the `e' in "~/.emacs", and hit C-k, so the field text is "~/.e"
and point is after the `e'.
Hit M-TAB. All files in the _current directory_, are shown in *Completions*.
That is, (a) the "~/" is ignored, and `default-directory' is used for
completion, and (b) the file names shown do not necessarily contain `e'.
IOW, as with the previous desciptions I've given, the text before point is
ignored for matching.
If I put point before the `e' then *Completions* shows the names of all files in
"~/" that start with `.' and contain `e'.
I'm not sure what matching algorithm you're using - it does not include all
names that contain both `.' and `e' or `.' followed somewhere by `e'. It
contains only the names that start with `.' and contain `e' somewhere.
If I put point before the `.' then *Completions* apparently shows all names that
contain `.e' as a substring. (That's a very different set than when point is
between the `.' and `e'.)
If I put point before the `/' then Emacs says are no matches at all.
If I put point before the `~' then *Completions* shows only the file names that
contain a (literal) `~'.
(To me, besides the bug reported, this mix of matchings does not seem very user
friendly, but I do not expect you will agree about that.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#10721
; Package
emacs
.
(Sat, 10 Mar 2012 09:57:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 10721 <at> debbugs.gnu.org (full text, mbox):
"Drew Adams" <drew.adams <at> oracle.com> writes:
>> But if the recipe involves face names, the bug title is
>> misleading. It appears that general inline completion in
>> fields is broken
>
>> nothing to do with (file :must-match t) types.
>
> Correct - it seems that all such completion fields are broken
So it looks like this was Bug#6830, which Stefan fixed. Closing.
bug closed, send any further explanations to
10721 <at> debbugs.gnu.org and "Drew Adams" <drew.adams <at> oracle.com>
Request was from
Chong Yidong <cyd <at> gnu.org>
to
control <at> debbugs.gnu.org
.
(Sat, 10 Mar 2012 09:58:01 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sat, 07 Apr 2012 11:24:03 GMT)
Full text and
rfc822 format available.
This bug report was last modified 13 years and 80 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.