Subject: Re: bug#1085: 23.0.60; all-completions, try-completion inconsistent: Info-read-node-name-1

From: Stefan Monnier <[email-masked]>
Date: Tue, 07 Oct 2008 17:07:08 -0400

> "png-file" cannot be a directory, we are no longer talking about "like
> all other file completions in Emacs" - where subdirectory names *are*
> treated as file names.

See http://en.wikipedia.org/wiki/PNG to learn what is a PNG file.

> I think you've extrapolated from the file-completion case, but you've ignored
> the fact that Emacs file-completion does treat directory names as valid file
> names (for completion).

You talk as if there was only a single form of file-name completion in
Emacs, even though it's clearly not the case: it depends on the kind of
file name you want to get.  It may be restricted to directories, to
files of a particular kind, etc...

> Is "png-file" like file-completion or something different? Do you want
> to let directories be completed or not? These are design decisions for
> png-file completion. But I see no reason that "png-file" couldn't be
> defined to be able to complete as one would like.

If you want to be able to enter /usr/share/foo/bar/toto/foo.png with
completion, that means that all-completions should either return all png
files in your file system (this is impractical) or that it returns both
png files and directories, so that you can complete "/u" to "/usr/",
etc...  But that doesn't mean that test-completion should accept "/usr/".

> Perhaps I'm missing some of what you're saying here; dunno.

What I'm saying is that your invariant is too restrictive and it makes
sense to break it sometimes.  So it's not a valid invariant and code
should not rely on it being true.

> "(emacs)" in Info would be treated the same way, and there too you
> could consider it a prefix, so the same mechanism could be used to do
> the wish-list completion we discussed, no?

Very much so.

> But I don't see why this extra information should always be considered
> a prefix.  It could be anything really. It's just something that lets
> COLLECTION (aka TABLE) do its job and something that we do *not* want
> to appear as a prefix of each completion. In the case of file-name and
> Info node completion you *could* consider it as in some sense an
> invisible prefix (but not a prefix that is part of each completion),
> but you need not think of it that way.

I have no clue what you're talking about.

> How about making the boundaries feature less dependent on treating
> this separate info as a (pseudo-)prefix? Instead of a string, it could

Because it wouldn't provide the info you need to write drew-all-completions.

> The problem, as I see it, is that among STRING, PREDICATE, and ACTION,
> there is no explicit provision for passing the additional info
> (e.g. directory). So we have fudged. We use PREDICATE for the dir.

No: "we useD PREDICATE for the dir".  This is being phased out.

> Or we fudge ACTION so it can sneak in the dir as
> a pseudo-prefix. Fudging ACTION is maybe better than fudging
> PREDICATE, and it leaves more room for manoeuver and engenders less
> conflict, but it is still a fudge. And if ACTION is fudged to do this,
> that still doesn't mean that the extra info should be treated as
> a prefix (string, start, end, etc.).

Neither should be fudged.  The extra info can be passed via buffer-local
variables, or stored inside the function (e.g. using lexical-let).

> Shouldn't we fix this right, so the extra info that the COLLECTION
> function needs is passed as an arg in its own right? I agree with your
> changes (still in progress, IIUC) to clean up PRED so it is always
> a predicate. But it seems to me that sneaking the extra info in in the
> form of a "prefix" string inside ACTION is  also an ugly hack. Why
> don't we try to come up with something that fits legacy but also DTRT?

Oh, is that what you're talking about?  No you completely misunderstand,
there's no relationship between the "prefix" stuff and the directory
info that used to be fudged into PREDICATE.

That directory info that used to be passed in PREDICATE is now passed
via buffer-local variables instead.

        Stefan