[Top][All Lists]

[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: Wed, 10 Oct 2001 21:16:07 +0200

> From: address@hidden (Jari Aalto+mail.emacs)
> Newsgroups: gnu.emacs.bug
> Date: Thu, 04 Oct 2001 22:30:34 +0300
>     In Windows, it is possible to create shortcuts that refer to
>     the original files. The cygwin development team already uses
>     windows shortcuts as substitute for native Unix symlinks.
>     I'd very much hope that Emacs would also offer support
>     for Windows shortcuts so that the actual file pointed by
>     shortcut is loaded.

I'd rather have Emacs support the Cygwin-style emulation of symlinks
than the semi-broken support for shortcuts that Windows offers.  I
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).

Since the shortcuts are semi-broken, supporting them in Emacs in a
consistent way, like Emacs does with symlinks, would be confusing for
a Windows user, because programs other than Emacs won't support those
shortcuts in the same way as Emacs does.  It is better to simulate
symlinks like Cygwin does in its earlier versions.

>     The binary format is easily parseable and support
>     in 21.x could be easily provided at C-level.

It's not easy; at least not as easy as it is in Cygwin.  Cygwin
replaces the Windows run-time libraries (or most of them), so it in
effect provides a separate, Posix-compliant run-time environment for
programs which use the Cygwin runtime.  Therefore, Cygwin programs
don't need to worry too much about idiosyncrasies of Windows system

By contrast, Emacs uses the Windows run-time libraries.  So in order
to support shortcuts as if they were symlinks, the Windows port of
Emacs needs to have a wrapper for each file-oriented library function,
and that wrapper needs to resolve the shortcut, and then call the
library function with the actual file name recorded in the shortcut.
That's a very non-trivial job.  However, if you are volunteering to
write that code, I'm sure it will be seriously considered for

reply via email to

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