GNU bug report logs - #10721
24.0.93; M-TAB for :type (file :must-match t) in Customize

Previous Next

Package: emacs;

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.

View this report as an mbox folder, status mbox, maintainer mbox


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):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: <bug-gnu-emacs <at> gnu.org>
Subject: 24.0.93; M-TAB for :type (file :must-match t) in Customize
Date: Sat, 4 Feb 2012 08:35:55 -0800
(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):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 10721 <at> debbugs.gnu.org
Subject: Re: bug#10721: 24.0.93;
	M-TAB for :type (file :must-match t) in Customize
Date: Mon, 06 Feb 2012 09:02:19 -0500
> 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):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>
Cc: 10721 <at> debbugs.gnu.org
Subject: RE: bug#10721: 24.0.93;
	M-TAB for :type (file :must-match t) in Customize
Date: Mon, 6 Feb 2012 07:36:56 -0800
> 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):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 10721 <at> debbugs.gnu.org
Subject: Re: bug#10721: 24.0.93;
	M-TAB for :type (file :must-match t) in Customize
Date: Mon, 06 Feb 2012 16:01:15 -0500
>> 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):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>
Cc: 10721 <at> debbugs.gnu.org
Subject: RE: bug#10721: 24.0.93;
	M-TAB for :type (file :must-match t) in Customize
Date: Mon, 6 Feb 2012 13:26:54 -0800
[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):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 10721 <at> debbugs.gnu.org
Subject: Re: bug#10721: 24.0.93;
	M-TAB for :type (file :must-match t) in Customize
Date: Mon, 06 Feb 2012 21:52:31 -0500
> 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):

From: Chong Yidong <cyd <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 10721 <at> debbugs.gnu.org, Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#10721: 24.0.93;
	M-TAB for :type (file :must-match t) in Customize
Date: Tue, 07 Feb 2012 13:54:08 +0800
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):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Chong Yidong'" <cyd <at> gnu.org>,
	"'Stefan Monnier'" <monnier <at> iro.umontreal.ca>
Cc: 10721 <at> debbugs.gnu.org
Subject: RE: bug#10721: 24.0.93;
	M-TAB for :type (file :must-match t) in Customize
Date: Tue, 7 Feb 2012 08:44:05 -0800
> 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):

From: Chong Yidong <cyd <at> gnu.org>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 'Stefan Monnier' <monnier <at> iro.umontreal.ca>, 10721 <at> debbugs.gnu.org
Subject: Re: bug#10721: 24.0.93;
	M-TAB for :type (file :must-match t) in Customize
Date: Sat, 10 Mar 2012 17:26:58 +0800
"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.