[Top][All Lists]

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

Re: emacsclient: support `/' directory separator on w32

From: David Kastrup
Subject: Re: emacsclient: support `/' directory separator on w32
Date: Tue, 28 Nov 2006 15:49:57 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.91 (gnu/linux)

"Juanma Barranquero" <address@hidden> writes:

> On 11/28/06, Lennart Borgman <address@hidden> wrote:
>> Well, it actually have to either require full path names or translate
>> relative file names to full file names before sending the file names to
>> emacs, or?
> I don't understand the question. It currently accepts absolute
> pathnames, or pathnames relative to the current directory. Seems
> sensible to me. And portable.

I would not call that portable.  "portable" means "work everywhere",
not "work everywhere under the assumption that everywhere is supposed
to be like Unix".

> Most operating systems have the concept of a default current
> directory. I don't think most of them have the concept of a default
> current directory for each drive/device/filesystem/younameit (but I
> could be wrong).

Most operating systems have the concept of relative file names that
can resolve to different files in different environments.

So Emacsclient has to deal with this.  At the moment it appears to do
this by passing both the relative filename as well as what it
considers relevant for absolutizing it, the current work directory.

It appears that the current work directory alone is not sufficient.  I
see two approaches here: either Emacsclient will pass more info to
Emacs, or it creates the absolute file names itself.  The latter
sounds more sane to me, however it requires that Emacsclient itself
knows which parts on the command lines are filenames to be opened, and
which are just arguments to be interpreted by commands or stuff.

Maybe we really don't want to go there, but in the mean time, it
sounds flaky.

David Kastrup, Kriemhildstr. 15, 44793 Bochum

reply via email to

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