[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 21.x feature request: windows shortcut support

From: Stefan Monnier
Subject: Re: 21.x feature request: windows shortcut support
Date: 13 Oct 2001 12:02:56 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.107

>>>>> "Jason" == Jason Rumney <address@hidden> writes:
> address@hidden (David Masterson) writes:
>> > That doesn't appear to be the only use on Windows.  You can have a
>> > shortcut to a text file (for instance).  When clicked on, it will
>> > "Open" the text file (ie. invoke the editor [Notepad] on it).  A
>> > shortcut has a "Target type" that tells Windows what to do with the
>> > referenced file.  So, the two basic target types seem to be
>> > "Application" and "Text file"
> The basic target types for shortcuts I am aware of are:
>    "Application", which can include extra information such as command
>    line arguments, default working directory, console window
>    properties if it is a console application, and can accept further
>    command line arguments through drag and drop.

I think that when opening such a shortcut, what Emacs should do is
to present the data in a sensible form (and you can then click on the
target if you want to open it).

>    "Data file", which acts as you describe above, but is not limited
>    to text files.

>    "File folder", which doesn't really need to be different than data
>    file, since the default action for folders is invoked the same way
>    as for data files. But apparently an extra bit is set for these, so
>    they must be handled slightly differently.

>    "Network drive"

>    "URL"

>    Probably more for printers, control panels and other special cases.

Thank you for that info.  I really think more and more that supporting
shortcuts anywhere else than in find-file (and when exec'ing a process)
is a bad idea.
And I don't see the point of fetching mailcap.lnk when mailcap
was requested.  If you want symlinks, then use symlinks (f.ex.
those implemented in cygwin which we probably should try to support).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]