GNU bug report logs - #1085
23.0.60; all-completions, try-completion inconsistent: Info-read-node-name-1

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: <1085 <at> debbugs.gnu.org>, <emacs-pretest-bug <at> gnu.org>
Subject: bug#1085: 23.0.60; all-completions, try-completion inconsistent: Info-read-node-name-1
Date: Wed, 08 Oct 2008 12:10:01 -0400

>> > I was following my analogy and thought that you did the 
>> > same thing for both, using the directory part as a
>> > boundary/contextual "prefix" of the relative file name.
>> > But IIUC, there is no invalidation of the invariants for
>> > file-name completion.
>> Your 3rd invariant is invalidated because all-completions does not
>> return the directory part of a completion.

> But if you call try-completion directly using a relative file name,
> then it, just like all-completions, returns the completed relative
> file name - completed in the default directory.

Not if the relative file name includes a slash.

> (try-completion "icicles." 'read-file-name-internal nil) gives "icicles.el".

That's just a happy corner case.  We're discussing the general case.

>> > Why couldn't we treat this completion the same way we treat 
>> > file-name completion?
>> We do treat it identically.
> Not if I understand correctly. Isn't it true that we use the boundary thing
> (with prefix "(") for the Info file/node completion, and we don't use it for
> file-name completion?

We use it for file-name completion just the same.
If you're in the particular case where the file name has no directory
component, then the prefix is the empty string so you may get fooled
into thinking that it's not used, but it is.


        Stefan

Previous Next

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