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

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

[Drew Adams]

An Icicles user suggested this, so I added it. I wonder if it wouldn't also
make sense for Emacs:

For file-name completion, apply `abbreviate-file-name' to the user's input.
This would let a user take advantage of a customized
`directory-abbrev-alist' during completion.

Would there be any downside to that?

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

[Richard Stallman]

    For file-name completion, apply `abbreviate-file-name' to the user's input.
    This would let a user take advantage of a customized
    `directory-abbrev-alist' during completion.

    Would there be any downside to that?

I don't think Emacs should alter the names that the user enters.

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

[Drew Adams]

>     For file-name completion, apply `abbreviate-file-name' to the
>     user's input. This would let a user take advantage of a customized
>     `directory-abbrev-alist' during completion.
>
>     Would there be any downside to that?
>
> I don't think Emacs should alter the names that the user enters.

`directory-abbrev-alist' is nil by default. Users customize it. It lets them
sustitute their own abbreviations for directories.

Why shouldn't completion respect the user's preference for such
abbreviations (e.g. symlinks)?

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

[Stefan Monnier]

>> For file-name completion, apply `abbreviate-file-name' to the
>> user's input. This would let a user take advantage of a customized
>> `directory-abbrev-alist' during completion.
>> 
>> Would there be any downside to that?
>> 
>> I don't think Emacs should alter the names that the user enters.

> `directory-abbrev-alist' is nil by default. Users customize it. It lets them
> sustitute their own abbreviations for directories.

> Why shouldn't completion respect the user's preference for such
> abbreviations (e.g. symlinks)?

I must say I do not understand what you're asking for.  Can you spell out
a concrete example?


        Stefan

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

[Drew Adams]

> >> For file-name completion, apply `abbreviate-file-name' to the
> >> user's input. This would let a user take advantage of a customized
> >> `directory-abbrev-alist' during completion.
> >>
> >> Would there be any downside to that?
> >>
> >> I don't think Emacs should alter the names that the user enters.
>
> > `directory-abbrev-alist' is nil by default. Users customize it.
> > It lets them substitute their own abbreviations for directories.
>
> > Why shouldn't completion respect the user's preference for such
> > abbreviations (e.g. symlinks)?
>
> I must say I do not understand what you're asking for.  Can you spell out
> a concrete example?

`directory-abbrev-alist' substitutes matches of its regexps against
directory names with their corresponding directory-name "abbreviations".

The doc shows only examples where the resulting directory names are shorter,
but the reverse relation can be useful as well: expand instead of contract.
The point is to substitute one directory name for another that is more
convenient in some way. The symlink case is only one use case, IIUC.

Here is the original feature request I received, describing a use case. The
user requests that the cars of `directory-abbrev-alist' entries be completed
to the cdrs.

 I've been using Icicles about over 1 year (but still i'm
 a sort of newbie). recently, i found i can use
 'directory-abbrev-alist' not to type very long path that
 is hard to remember in 'find-file'. But I also found that
 Icicles' completion mechanism (including default Emacs' one)
 does not handle this abbrev consistently. for example, when
 i set my directory-abbrev-alist up like
   (("^/exe" . "/very-long-path-here/exe"))
 and, when i enter in minibuffer after 'find-file', "/exe",
 and TAB no expansion occurred. How can i utilize
 abbreviation to long path in Icicle ways?

IOW, `find-file /exe RET' correctly expands the abbreviation. But the same
is not true of `find-file /exe TAB'. The user requests that the latter
feature be added.

To implement this, i just call `abbreviate-file-name' on the user's current
file-name input. Then, in the example above, both `C-x C-f /exe TAB' and
`C-x C-f /whatever/you/might/have//exe TAB' complete to
`/very-long-path-here/exe'.

Seems useful to me. Again, does anyone see a downside to such behavior? The
abbreviation list is under user control (customization), so I don't see the
point of Richard's complaint that Emacs completion would then be altering
what the user entered. That's the whole point of completion, no?

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

[Stefan Monnier]

>  i 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.  `directory-abbrev-alist' should turn a valid filename into another
valid filename, the difference between the two being mostly cosmetic.
E.g. It should be

    (("^/very-long-path-here/exe" . "/exe")

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.


        Stefan

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?

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

[Juanma Barranquero]

On 10/13/07, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> This is definitely not the way directory-abbrev-alist was intended to be
> used.  `directory-abbrev-alist' should turn a valid filename into another
> valid filename, the difference between the two being mostly cosmetic.

FWIW, I use directory-abbrev-alist in my .emacs to show in the
modeline aliases (which are not directories, but shorter arbitrary
names) of the directory of the visited files.

             Juanma

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

[Richard Stallman]

    > 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.

If you want to know what it will do if you set variables to values
that are not intended to be used, you can read the code.

I made it clearer in the doc string what cases are supposed to be
used.

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

[Drew Adams]

>     > 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.
>
> If you want to know what it will do if you set variables to values
> that are not intended to be used, you can read the code.

I did, including all of the distribution Lisp code that uses it. I see
nothing in the code that contradicts what I said. There is nothing that
prevents FROM from matching a valid directory name that might not in fact
directly name an existing directory. The code still works fine in that case.
And at least some users have been putting that behavior to good use.

> I made it clearer in the doc string what cases are
> supposed to be used.

The only change you made, that I can see, was adding this phrase: "FROM and
TO should be equivalent names, which refer to the same directory."

I don't see how that contradicts what I said either. In the user's use case
that I cited, FROM is ^/exe and TO is /very-long-path-here/exe. Both FROM
and TO are equivalent names in terms of their effect, and both effectively
refer to the same directory, /very-long-path-here/exe.

Even if FROM had been ^/foo, they would be equivalent names and refer to the
same directory, if what ^/foo matches is a directory name.

 1. FROM: ^/foo
 2. what FROM matches (e.g. typed by user): /foobar
 3. replacement for the match: /very-long-path-here/exe
 4. TO: /very-long-path-here/exe

#3 and #4 are identical names for the same directory. #1 is an equivalent
name, by the behavior of `directory-abbrev-alist', to #4.

I believe that what I've described is what the code actually does. Don't you
think so? That behavior might not be as limited as what you intended, but
that is the current behavior AFAICT.

And I don't see why the behavior should be changed to fit the more limited
scenario you apparently have in mind. This is a useful mechanism. We've
already had two users (not counting me) who reported using it this way: (1)
the user I mentioned and (2) Juanma.

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

[Stefan Monnier]

> So what? Regardless of the original intention, what's important is how it
> actually behaves.

But if you use it to a different end, you shouldn't be surprised if the
behavior isn't always ideal (e.g. if TAB doesn't apply
directory-abbrev-alist).  This said, I have nothing against TAB calling
abbreviate-file-name.


        Stefan

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

[Richard Stallman]

    I don't see how that contradicts what I said either. In the user's use case
    that I cited, FROM is ^/exe and TO is /very-long-path-here/exe. Both FROM
    and TO are equivalent names in terms of their effect, and both effectively
    refer to the same directory, /very-long-path-here/exe.

I guess I do not understand your proposed usage.
I thought I did, but I can't follow this.

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

[Drew Adams]

>     I don't see how that contradicts what I said either. In the
>     user's use case that I cited, FROM is ^/exe and TO is
>     /very-long-path-here/exe. Both FROM
>     and TO are equivalent names in terms of their effect, and
>     both effectively
>     refer to the same directory, /very-long-path-here/exe.
>
> I guess I do not understand your proposed usage.
> I thought I did, but I can't follow this.

I didn't propose any particular usage. I described one user's use of this as
an abbreviation mechanism for directory names, but unrelated to symlinks.

His usage:

 FROM: Any easy-to-type and mnemonic regexp that matches
       a syntactically valid directory name, whether or not
       such a directory exists. Example: "^/proj1".

 TO:   An (absolute) name of an existing directory.
       Example: "/a/very/long/dir/name/to/my/project".

FROM and TO are equivalent, in that they have the same effect. TO is a valid
directory name and FROM matches a syntactically valid directory name, even
if no such directory exists. In the user's case, TO names an existing
directory.

So far, I've described no proposal wrt this. This already works, without
problem. He uses this with `find-file': C-x C-f /proj1 RET visits the (real)
directory /my/very/long/dir/name/to/a/project. This saves him time. Yes,
there are other possible abbreviation mechanisms, but this one is also
useful in this way.

His proposal, which I relayed to the list, is this: Let completion do the
same thing, so that C-x C-f /proj1 TAB completes to
/my/very/long/dir/name/to/a/project.

The only change needed is for TAB (`minibuffer-complete') to call
`abbreviate-file-name' (for file-name completion only, of course).

I don't want to belabor this. I think his idea is a good one. My question to
the list was whether there would be any important downsides to such a
feature. FWIW, I added this feature to Icicles, and I haven't had any
complaints.

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

[Stefan Monnier]

> FROM and TO are equivalent, in that they have the same effect. TO is a valid
> directory name and FROM matches a syntactically valid directory name, even
> if no such directory exists. In the user's case, TO names an existing
> directory.

Just for the record: the directory-abbrev-alist is AFAIK only used by
abbreviate-file-name which is only called occasionally rather than
systematically (because its intention is to only make cosmetic changes).
So using it to map non-existent filenames to real filenames is likely to
lead to occasional surprises.


        Stefan

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

[Richard Stallman]

    But if you use it to a different end, you shouldn't be surprised if the
    behavior isn't always ideal (e.g. if TAB doesn't apply
    directory-abbrev-alist).  This said, I have nothing against TAB calling
    abbreviate-file-name.

I do not like the idea of making TAB perform additional alterations
on the minibuffer text.

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

[Richard Stallman]

    His usage:

     FROM: Any easy-to-type and mnemonic regexp that matches
	   a syntactically valid directory name, whether or not
	   such a directory exists. Example: "^/proj1".

     TO:   An (absolute) name of an existing directory.
	   Example: "/a/very/long/dir/name/to/my/project".

That is definitely not what this feature is meant for.
It isn't meant for expanding abbreviations.
It is meant for replacing long names with equivalent short ones.

If he wants a short way to enter /a/very/long/dir/name/to/my/project,
he should make ~/proj1 a symlink to it.  Then he can use the
abbreviation ~/proj1 in EVERY program.

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

[Drew Adams]

>     His usage:
>
>      FROM: Any easy-to-type and mnemonic regexp that matches
> 	   a syntactically valid directory name, whether or not
> 	   such a directory exists. Example: "^/proj1".
>
>      TO:   An (absolute) name of an existing directory.
> 	   Example: "/a/very/long/dir/name/to/my/project".
>
> That is definitely not what this feature is meant for.
> It isn't meant for expanding abbreviations.
> It is meant for replacing long names with equivalent short ones.

It is nevertheless what this feature *does*. It is agnostic wrt name length.

> If he wants a short way to enter /a/very/long/dir/name/to/my/project,
> he should make ~/proj1 a symlink to it.  Then he can use the
> abbreviation ~/proj1 in EVERY program.

For various reasons, he might not WANT such symlinks. He can also create
environment variables, as Stefan suggested, but he might not WANT such env
vars. He might not WANT such abbreviation/substitution/rewriting (call it
what you like) in EVERY program.

Anyway, I understand that you are not in favor of either (1) letting TAB
completion respect `directory-abbrev-alist' or (2) documenting the existing
behavior of `directory-abbrev-alist' (beyond what is the originally intended
symlink use).

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

[Stefan Monnier]

> For various reasons, he might not WANT such symlinks. He can also create
> environment variables, as Stefan suggested, but he might not WANT such env
> vars. He might not WANT such abbreviation/substitution/rewriting (call it
> what you like) in EVERY program.

Then he can do it via file-name-handler-alist ;-)


        Stefan

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

[Drew Adams]

> > For various reasons, he might not WANT such symlinks. He can also create
> > environment variables, as Stefan suggested, but he might not 
> > WANT such env vars. He might not WANT such 
> > abbreviation/substitution/rewriting (call it
> > what you like) in EVERY program.
> 
> Then he can do it via file-name-handler-alist ;-)

;-) indeed.

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

[Richard Stallman]

    > That is definitely not what this feature is meant for.
    > It isn't meant for expanding abbreviations.
    > It is meant for replacing long names with equivalent short ones.

    It is nevertheless what this feature *does*. It is agnostic wrt name length.

You are welcome to use the feature for something other than its
intended purpose, if you like the result.  However, we don't have to
maintain Emacs or its manuals for the sake of such usage.