bug-gnu-emacs
[Top][All Lists]
Advanced

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

Re: 21.x feature request: windows shortcut support


From: Eli Zaretskii
Subject: Re: 21.x feature request: windows shortcut support
Date: Fri, 12 Oct 2001 01:11:33 +0200

> From: "Stefan Monnier" <monnier+gnu.emacs.bug/news/@RUM.cs.yale.edu>
> Newsgroups: gnu.emacs.bug
> Date: 11 Oct 2001 16:05:16 -0400
> 
> >>>>> "Eli" == Eli Zaretskii <eliz@is.elta.co.il> writes:
> > consider the shortcuts semi-broken because many Windows system calls
> > which work with files don't know about shortcuts (that's the reason
> > why you need to ``support'' shortcuts specially in the first place:
> > the Windows run-time libraries don't).
> 
> I don't understand this thread and I think the reason is to be found
> in the quoted text above.  So here's my question: since application
> need to support shortcuts specially, what is the "hard coded" semantics
> of shortcuts (i.e. how do the runtime libraries treat them) and what
> is the usual semantics normally provided by application ?

I'm not 100% sure about the details of this, so people who know
Windows better please correct me where I'm wrong.

AFAIK, Windows applications do not support shortcuts at all.  The
shortcut support in Windows is implemented on the shell level.  That's
not the shell as in Bash or COMAMND.COM, that's the Windows shell: a
program which is responsible for launching other programs and
generally managing those programs.  The default Windows shell is the
Explorer.

Since running a program from another program requires to call a
special function provided by the Windows shell (i.e. Explorer), every
program which runs other programs ``inherits'' this shortcut support.
But that support is therefore limited to launching programs only.

> And what is the intended semantics ?

I think MS never meant for shortcuts to be more than what I described:
a way to run programs located elsewhere.  One reason for that is that
any icon on the Windows desktop is actually a file in a special
directory.  When you click on that icon, Windows ``invokes'' that
icon's file.  Making that file a shortcut whose target is the real
program is a convenient way of letting the icon do its magic.

> Are they intended to work just like POSIX symlinks (f.ex allow
> symlinks to directories in the middle of a path) ?

No.

> Based on the thread, I'd expect that there is no such thing as an "intended
> semantics", and it's completely ad-hoc instead.

That's what I know.

> In such a case, I'm
> not sure it's worth it for Emacs to do much better than provide a
> "shortcut-mode" for *.lnk files which either automatically redirects
> the find-file to the target of the shortcut or just displays the
> shortcut's content in a convenient way.

I was trying to argue that redirecting find-file (and other
primitives), if we want that, should be implemented on the lowest
possible level, or else it will have subtle misfeatures.



reply via email to

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