Re: 21.x feature request: windows shortcut support

[David Masterson]

>>>>> Richard Stallman writes:

>> With respect to opening a shortcut, does Emacs keep any side-lists
>> of information about the files that it opens?

> When Emacs visits a file, it keeps lots of information about that
> file in local variables in the buffer.  But I don't know whether
> that relates to your question; the question is very general.  What
> sort of information do you want to save?

In a previous post, I listed (my understanding of) shortcut data.

>> Could Emacs resolve the shortcut and stuff the above information
>> into such a "side-list"?

> In what scenario?  What is the operation that the user did?

For this "side-list" of shortcut data, I'm mostly thinking of
find-file type operations as that is the only type of user-level
operations that I can think of that would run into a shortcut (but see
below).  For this type of operation, two things could conceptually be
done with the buffer that loaded a shortcut:

1. (find-alternate-file referred-file)
2. (edit-shortcut-mode side-list)

Notes

* #1 should cd back to original directory so subsequent operations
   assume they are in the directory of the link rather than the file.
* Would that cd in #1 impact write-file?  (it shouldn't) 
* #2 would be done via The normal auto-mode-alist route (to allow
   elispers to write better versions).
* If #2 does not exist, it should probably force #1.

>> I'm not much of a Windows developer, but I think the terminology is
>> wrong here.  Windows doesn't use shortcuts for "execution" -- it
>> uses them for "resolution".

> If "resolution" could entail diverse activities such as running a
> program or opening a text file, then Emacs has no such concept and
> that cannot fit into Emacs.  

Hmmm.  I think a Windows program determines when and how much of a
shortcut to "resolve".  Emacs could do the same.

> When you use the Emacs command find-file, it is supposed to visit a
> file in some way.  Variations on how this is done can fit in to the
> conceptual structure, but running a program instead of visiting a
> file just does not fit.

Most (all?) Windows editors will simply do the equivalent of a
find-alternate-file when opening a shortcut.  I'm suggesting the above
extension (ie. w32-read-thru-shortcutp) to allow Emacs an enhanced
capability that (to me) fits into the Emacs structure.

> Likewise, when you do start-process, it has to make a subprocess; to
> visit a file instead would be unacceptable.

Agreed, but...

If Emacs needed to do a start-process on "PROGRAM" in Windows, it
would probably search the list (.EXE, .CMD, .COM, .LNK) for the full
name of the program to execute.  If it came up with "PROGRAM.LNK" to
execute, it should "START" it (is this what start-process would do
anyway?) and let Windows handle the rest.  If the shortcut happened to
point to a text file, that might mean that the default Windows editor
would startup to edit the file.  Advanced Windows users may, however,
have setup "gnuclient" as their default editor and, thus, cause the
file to come up in a new Emacs buffer.

> Maybe this means Emacs cannot usefully support shortcuts.  Or maybe
> Emacs can do so somehow but it won't be like what happens in some
> other programs.

To me, the above is all conceptually sound with respect to both how
Emacs works and how Windows works.

> I think the thing to do is leave it up to Windows users to handle
> shortcuts.  If they write clean code for shortcuts and Windows users
> are happy with the results, we can install it.

I'm not an expert in this area, but I hope I've suggested some things
that are conceptually sound that someone could run with.

-- 
David Masterson                dmaster AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA