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

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

bug#18851: 24.4; emacs cannot be started if the current directory has be


From: Eli Zaretskii
Subject: bug#18851: 24.4; emacs cannot be started if the current directory has been removed
Date: Wed, 29 Oct 2014 18:07:33 +0200

> Date: Wed, 29 Oct 2014 16:39:59 +0100
> From: Vincent Lefevre <vincent@vinc17.net>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, 18851@debbugs.gnu.org
> 
> >   . the default-directory of *scratch*
> 
> IMHO, if the current directory no longer exists, the default-directory
> of *scratch* can be nil.
> 
> >   . invocation-name and invocation-directory, if Emacs was invoked via
> >     a relative file name, like "../foo/bar/emacs".
> > 
> > In the first case, we could try using nil instead, maybe not all hell
> > will break lose.  The second case is rare even without the removal
> > (and makes no sense to me).
> 
> emacs --eval '(setq default-directory nil) (find-file "~/out")'
> 
> fails, but I wonder why.

You can assume without testing that there will be problems, because
Emacs expects to find a meaningful default-directory in *scratch*.
The only question is are those problems easy to solve, or are they
extremely complex to solve.

There's one more subtlety here which you might not be aware of: when
Emacs comes up initially, its first steps through the startup process
are made before it figures out the user locale and sets up the
coding-systems required by that.  Until that point, Emacs uses
undecoded file names, i.e. essentially byte streams that it can barely
interpret (unless they are pure-ASCII).  So the code which gives you
trouble, that is run very early during startup, is already complicated
to support building and starting Emacs in a non-ASCII directory.

> Well, it happens that the current directory is removed for some
> reasons, either on purpose or because of some FS error (in particular
> if the FS is remote). Now, I may have already an application running
> with this current directory, for instance, a MUA. If I want to write
> a mail, the MUA will start an editor on an absolute pathname, Emacs
> in my case, with the same current directory. But Emacs cannot be
> started, just because the current directory no longer exists, meaning
> that I can't write my mail without restarting the whole application.

Can't you use the --chdir command-line argument to make Emacs start in
a safe place?  Or does that not work in this situation?





reply via email to

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