Re: [Emacs-diffs] /srv/bzr/emacs/trunk r100117: Run kill-emacs when exiting for display closed or SIGTERM/HUP.

[Stefan Monnier]

> Some directory trees I work with are very deep, 7 to 8 layers of
> subdirectories are not uncommon.  But they are part of the same project.
> I save the desktop at the top of that tree, because I do a svn up there
> before I start Emacs.  When I am at the deepest part of the tree and want to
> open a file that is in another directory, I have to either

>   C-x C-f <delete file name to the top> <move down in tree to file>
> or
>   C-x b *s<TAB><RET> C-x C-f <move down in tree to file>

> I find the latter to be much faster.

[ Reminds me that we should add special support for "get back to root of
  project" in the read-file-name minibuffer.  I don't use the
  same setup as you do, but the same needs show up.  One way I imagine
  it working is that the completion uses the union of files at cwd
  and at the project's root so that it "just works" as long as the file
  name is not ambiguous.  It could even work regardless of project
  root: just automatically try to move up the directory hierarchy until
  we find a file name that matches.  ]

>> BTW, why use --chdir rather than save the default-directories in the
>> session file if you think that it should work even without desktop.el?
> I doesn't work with desktop.  desktop adds itself to after-init-hook, and
> that is run before session restore.  So desktop will load my desktop in
> $HOME before default-directories are restored.

I don't understand what you're saying here.  For one, I was talking
about the "no desktop" case, and second I don't understand if you're
talking about some accidental problem in the current way desktop works
or a fundamental limitation in the way desktop can work.

>>> I'd like desktop.el to be more modular so we could save desktop
>>> automatically in the session specific restore data file.  I tried
>>> once, but it was so hard coded to use just one file, so I gave up.
>> 
>> Ah, now you're starting to talk.  Can you give some details of what you
>> tried and where the "hardcoding" was showing its ugly head?

> desktop-save can't save to an arbitrary buffer.  When desktop isn't used and
> Emacs is to be killed by the session manager, it would be good to save the
> desktop in the session-specific file.

Yes.  And when desktop is used, either the desktop data should also be
saved into the session file (rather than the desktop file), or at least
the location of the desktop file should be saved in the session file.

> But desktop-read can't read just part of a file, so restore may become
> an issue.

You lost me here.

> Ideally we would just load the session specific file on restart, but
> desktop has some cleanups it does in desktop-read after load.

I don't know what you're talking about.

> You never know if desktop-save is going to ask questions or not (well,
> except duplicating the logic behind ask-if-new and so on).

When called from the session management, I think desktop should be
forced to not ask questions.

> This makes it unsuitable for use when the session manager says "save
> state".  Note that in those cases, we may not be stopped at all, and
> user interaction should not take place.

Exactly, so desktop needs to be changed to account for that situation.

> And there is the possibility that the desktop file is locked,
> so it will ask a question anyway.

There shouldn't be any such problem with the session file (which is one
reason I suggest desktop should save to the session file, even if the
user is using a desktop file).

>>> If I start emacs in /some/dir without a desktop file and have desktop-mode
>>> enabled, there will be no desktop saved when I log out.
>>> When the session manager then restarts Emacs in $HOME it will read my
>>> desktop file in $HOME.  That is a bug also.
>> OK, let's try and fix it right, then.
> My first attemt was to let desktop save its state if desktop is
> enabled, otherwise save it in the session specific file.  But I now
> think that we must save in the session specific files always, due to
> the locking and stuff in desktop.

Agreed.

> Desktop may also choose to save in its file, so we save desktop
> in two places (just one if desktop-save-mode isn't enabled).

Not sure what desktop users would prefer.

> On restore, you should somehow tell desktop not to load its file, because if
> it does, it might be the wrong thing to do.  We wan't to restore to the
> state we had when stopped, and we don't know what has happend to that
> desktop file while we weren't running (some other Emacs may have modified
> it).  But now session restore kicks in after desktop has already read its
> file.

We need to change this ordering so session restore takes place before
(or "at the same time as") desktop-load, so it can prevent desktop from
loading another desktop.

> After we have restored from the session file, we must then tell
> desktop that it is now okay to save to its file again.

Of course.


        Stefan