* bug#10721: 24.0.93; M-TAB for :type (file :must-match t) in Customize
@ 2012-02-04 16:35 Drew Adams
2012-02-06 14:02 ` Stefan Monnier
0 siblings, 1 reply; 9+ messages in thread
From: Drew Adams @ 2012-02-04 16:35 UTC (permalink / raw)
To: 10721
(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'
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#10721: 24.0.93; M-TAB for :type (file :must-match t) in Customize
2012-02-04 16:35 bug#10721: 24.0.93; M-TAB for :type (file :must-match t) in Customize Drew Adams
@ 2012-02-06 14:02 ` Stefan Monnier
2012-02-06 15:36 ` Drew Adams
0 siblings, 1 reply; 9+ messages in thread
From: Stefan Monnier @ 2012-02-06 14:02 UTC (permalink / raw)
To: Drew Adams; +Cc: 10721
> 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#10721: 24.0.93; M-TAB for :type (file :must-match t) in Customize
2012-02-06 14:02 ` Stefan Monnier
@ 2012-02-06 15:36 ` Drew Adams
2012-02-06 21:01 ` Stefan Monnier
0 siblings, 1 reply; 9+ messages in thread
From: Drew Adams @ 2012-02-06 15:36 UTC (permalink / raw)
To: 'Stefan Monnier'; +Cc: 10721
> 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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#10721: 24.0.93; M-TAB for :type (file :must-match t) in Customize
2012-02-06 15:36 ` Drew Adams
@ 2012-02-06 21:01 ` Stefan Monnier
2012-02-06 21:26 ` Drew Adams
0 siblings, 1 reply; 9+ messages in thread
From: Stefan Monnier @ 2012-02-06 21:01 UTC (permalink / raw)
To: Drew Adams; +Cc: 10721
>> 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#10721: 24.0.93; M-TAB for :type (file :must-match t) in Customize
2012-02-06 21:01 ` Stefan Monnier
@ 2012-02-06 21:26 ` Drew Adams
2012-02-07 2:52 ` Stefan Monnier
0 siblings, 1 reply; 9+ messages in thread
From: Drew Adams @ 2012-02-06 21:26 UTC (permalink / raw)
To: 'Stefan Monnier'; +Cc: 10721
[-- Attachment #1: Type: text/plain, Size: 2243 bytes --]
> > 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?
[-- Attachment #2: throw-emacs-bug-10721.png --]
[-- Type: image/png, Size: 50490 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#10721: 24.0.93; M-TAB for :type (file :must-match t) in Customize
2012-02-06 21:26 ` Drew Adams
@ 2012-02-07 2:52 ` Stefan Monnier
2012-02-07 5:54 ` Chong Yidong
0 siblings, 1 reply; 9+ messages in thread
From: Stefan Monnier @ 2012-02-07 2:52 UTC (permalink / raw)
To: Drew Adams; +Cc: 10721
> 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#10721: 24.0.93; M-TAB for :type (file :must-match t) in Customize
2012-02-07 2:52 ` Stefan Monnier
@ 2012-02-07 5:54 ` Chong Yidong
2012-02-07 16:44 ` Drew Adams
0 siblings, 1 reply; 9+ messages in thread
From: Chong Yidong @ 2012-02-07 5:54 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 10721
Stefan Monnier <monnier@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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#10721: 24.0.93; M-TAB for :type (file :must-match t) in Customize
2012-02-07 5:54 ` Chong Yidong
@ 2012-02-07 16:44 ` Drew Adams
2012-03-10 9:26 ` Chong Yidong
0 siblings, 1 reply; 9+ messages in thread
From: Drew Adams @ 2012-02-07 16:44 UTC (permalink / raw)
To: 'Chong Yidong', 'Stefan Monnier'; +Cc: 10721
> 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.)
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#10721: 24.0.93; M-TAB for :type (file :must-match t) in Customize
2012-02-07 16:44 ` Drew Adams
@ 2012-03-10 9:26 ` Chong Yidong
0 siblings, 0 replies; 9+ messages in thread
From: Chong Yidong @ 2012-03-10 9:26 UTC (permalink / raw)
To: Drew Adams; +Cc: 10721
"Drew Adams" <drew.adams@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.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2012-03-10 9:26 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-02-04 16:35 bug#10721: 24.0.93; M-TAB for :type (file :must-match t) in Customize Drew Adams
2012-02-06 14:02 ` Stefan Monnier
2012-02-06 15:36 ` Drew Adams
2012-02-06 21:01 ` Stefan Monnier
2012-02-06 21:26 ` Drew Adams
2012-02-07 2:52 ` Stefan Monnier
2012-02-07 5:54 ` Chong Yidong
2012-02-07 16:44 ` Drew Adams
2012-03-10 9:26 ` Chong Yidong
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).