RE: should `minibuffer-complete' use `abbreviate-file-name'?

[Drew Adams]

> >  set my directory-abbrev-alist up like
> >    (("^/exe" . "/very-long-path-here/exe"))
>
> This is definitely not the way directory-abbrev-alist
> was intended to be used.

So what? Regardless of the original intention, what's important is how it
actually behaves. Unless there is some reason to think that the behavior is
bugged and needs to be changed to conform rigidly to the intention you
assume, the assumption should be dropped in favor of reality.

Anyway, who's to say that that was the only intention, back in the dawn of
history when this was introduced? Are you basing that assumption only on the
doc or on the actual effect? The current doc speaks of symlinks as an useful
example, but the actual behavior is not limited to symlinks. The effect
doesn't exclude the user's interpretation and use case at all, AFAICT. The
abbreviation mechanism in fact takes no account of whether there are any
symlinks - they are certainly not a requirement.

> `directory-abbrev-alist' should turn a valid filename into
> another valid filename, the difference between the two being
> mostly cosmetic.

What's a valid filename in this context? Presumably, it's a valid directory
name, but what's that? Syntactic validity only, or must it also correspond
to an existing directory?

This is a rewrite mechanism for directory names; that's all. The effect is
just to match the regexp in the car against (part of) a directory name and
to replace the matched part by the cdr, another directory name.

Directory name does not imply existing directory. Why impose an
interpretation that the directory name matched by the car must correspond to
an existing directory? It is enough, for the actual effect, that it have
directory-name syntax. If a user types a directory name that is matched by
the regexp in the car, then that satisfies the requirement, even if the name
s?he typed does not correspond to an existing directory.

Beyond the rewriting, no use is ever made of the car - it's irrelevant
whether it matches the name of an existing directory. That's the whole point
of the rewrite: to get beyond the car and its matched name and use the cdr
instead.

The same is even true for the cdr: The abbreviation mechanism itself is
agnostic on whether it names an existing directory. It is the use context,
not the rewrite mechanism, that determines whether the name in the cdr is
OK. That context might expect the name of an existing directory or it might
expect only valid directory-name syntax (e.g. to create a new directory).

And even if there were a requirement that the cdr always name an existing
directory, that requirement would anyway be satisfied by the user's use
case: /very-long-path-here/exe names an existing directory. It is the car,
^/exe, that matches a directory name, but one that does not name an existing
directory. That's fine - the name matched by the car is never used as a
directory; it is used only to come up with the cdr.

> E.g. It should be (("^/very-long-path-here/exe" . "/exe")

C'est toi qui le dit. The abbreviation mechanism doesn't impose that.

> instead, or something like that.  For shorthands, she can use
> any number of other things like environment variables (which
> *are* expanded by TAB) or bookmarks.

The fact that there exist other shorthand means is not an argument that one
should not also use this directory shorthand to go from short name to long
(as well as from long to short). You wouldn't argue that because we have
environment variables we should forego bookmarks, would you?

BTW, the user mentioned that he also uses env variables with completion.
Perhaps that's in fact what gave him the idea that it would be good for
completion to also support dir abbreviations.

The directory abbreviation mechanism substitutes the dir name in the cdr for
whatever dir name the regexp in the car matches. If that is its only effect,
as it seems to be, then there is nothing wrong with putting that effect to
good uses that might not have been foreseen originally.

Perhaps the user misread the doc, or perhaps he read it in a new and more
general way. In any case, he discovered something new for himself that works
and is useful. It would be even more useful to extend its use to completion,
as he requested.

My question was, and is, would there be any downside to letting completion
take advantage of this shorthand? If it completes env vars, why not let it
also complete dir abbrevs?