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: Tue, 16 Oct 2001 10:28:11 +0200 (IST)

On 15 Oct 2001, David Masterson wrote:

> > Emacs doesn't track the files at all, it only tracks buffers.  When
> > Emacs visits a file, it opens the file, read its contents into a
> > buffer, then immediately closes the file and forgets about it.  Only
> > the file's name and some other information (e.g., time it was visited)
> > is kept as part of the buffer object.
> 
> How much "other information" is there?

Not much.  Apart of what I mentioned, there's the file's directory,
and that's about it.

> Is that "other information" kept as a list?

A buffer object is represented as a C structure in Emacs.

> Could more information as necessary be hung off it?

Not without changes to the buffer object's structure.

> After Emacs opens the file and loads the list, other functions (like
> after-find-file) or hooks (like after-* hooks) can decide what to do
> with the info.  For instance, after-find-file could take the file
> referred to and do a find-alternate-file if read-thru-shortcutp is 't'
> whereas, if it's 'nil, it would process auto-mode-alist against the
> "*.lnk" file which might startup a shortcut-edit-mode.

You seem to assume that the shortcut's contents is static and, once
recorded in the shortcut, never changes.  But that's not true: the
shortcut's target and other attributes can change outside Emacs's
control, in which case the info Emacs holds will be stale.

> The other area where I could see Emacs running into a shortcut is in
> trying to execute a subprogram.  In this case, if it was asked to run
> a program "X" and it determined (by checking a list of file types)
> that "X" was "X.lnk", then it could just "Start X.lnk" and let Windows
> handle the rest.

That's true, but going through `start' introduces more problems than
it solves (for example, redirection of standard handles will not work
with some programs).  Emacs could simply do the necessary magic to
invoke the target itself, without relying on `start'.  That's a
localized change in a single low-level function specific to the
Windows port; no need to change the buffer object or any other Emacs
data structure.

In other words, supporting invocation of programs through shortcuts is
easy; it's the other kinds of support that are much harder.  My
impression was that the OP asked for such support everywhere in Emacs
where we deal with file names.



reply via email to

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