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

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

[Stefan Monnier]

>   Run kill-emacs when exiting for display closed or SIGTERM/HUP.
>   * xsmfns.c (CHDIR_OPT): New define.
>   (smc_save_yourself_CB): Add CHDIR_OPT to options to use when
>   restarting emacs.

Not sure what's the relationship between the kill-emacs part and the
chdir part.  But I'm really wondering what this chdir thingy is
good for.  I mean: the current directory of Emacs is something rather
vague: Emacs has as many current directories as it has buffers, do does
it just refer to the default-directory of *scratch* and *Messages*?
If so, why/when is that so important as to justify a startup option?
  

        Stefan

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

[Jan Djärv]

2 maj 2010 kl. 21.24 skrev Stefan Monnier <monnier@iro.umontreal.ca>:

>>  Run kill-emacs when exiting for display closed or SIGTERM/HUP.
>>  * xsmfns.c (CHDIR_OPT): New define.
>>  (smc_save_yourself_CB): Add CHDIR_OPT to options to use when
>>  restarting emacs.
>
> Not sure what's the relationship between the kill-emacs part and the
> chdir part.  But I'm really wondering what this chdir thingy is
> good for.  I mean: the current directory of Emacs is something rather
> vague: Emacs has as many current directories as it has buffers, do  
> does
> it just refer to the default-directory of *scratch* and *Messages*?
> If so, why/when is that so important as to justify a startup option?
>

In some older Gnome versions, you could save current ditectory in the  
session manager and Emacs would then restart in that directory.

But now you can't so Emacs is restarted in a different directory.  If  
you are saving different desktops in different directories, restarting  
Emacs is kind of pointless unless you are in the right directory.

So making sure the desktop is saved wont solve the bug unless it is  
also read back properly.

         Jan D.

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

[Stefan Monnier]

> But now you can't so Emacs is restarted in a different directory.  If you
> are saving different desktops in different directories, restarting Emacs is
> kind of pointless unless you are in the right directory.

So, IIUC the question is not "Emacs's current directory" but "the
location of the relevant desktop file" (which happens to be currently
found via the current directory), right?

> So making sure the desktop is saved wont solve the bug unless it is also
> read back properly.

I'd be tempted to say that we need a "--desktop FILE" argument, then.


        Stefan

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

[Jan D.]

On 2010-05-03 02:55, Stefan Monnier wrote:
>> But now you can't so Emacs is restarted in a different directory.  If you
>> are saving different desktops in different directories, restarting Emacs is
>> kind of pointless unless you are in the right directory.
>
> So, IIUC the question is not "Emacs's current directory" but "the
> location of the relevant desktop file" (which happens to be currently
> found via the current directory), right?

For this bug report, yes.  But for the more general session management 
handling, it really is "start where we stopped".  Who knows what 
other/future packages save in the current directory?  Relative filenames 
perhaps?  Not to mention the fact that I personally get irritated that 
C-x C-f from *scratch* starts with the wrong directory in this case.

>
>> So making sure the desktop is saved wont solve the bug unless it is also
>> read back properly.
>
> I'd be tempted to say that we need a "--desktop FILE" argument, then.
>

That is too simplified, Emacs has more state than just the desktop file.

	Jan D.

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

[Stefan Monnier]

> For this bug report, yes.  But for the more general session management
> handling, it really is "start where we stopped".

But that's the whole problem: what do you define as "where we stopped"?
As I said, there are as many current directories as there are buffers.

> Who knows what other/future packages save in the current directory?

There's really no such thing as "Emacs's current directory".

> Relative filenames perhaps?  Not to mention the fact that I personally
> get irritated that C-x C-f from *scratch* starts with the wrong
> directory in this case.

Then desktop should save the default-directory of *scratch* (and
maybe/probably other buffers as well).  IIUC you can do that by adding
default-directory to desktop-locals-to-save.

> That is too simplified, Emacs has more state than just the desktop file.

But "--chdir" is too simplified, Emacs has many more current directories
than just "the one" ;-)


        Stefan

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

[Jan Djärv]

Stefan Monnier skrev 2010-05-03 19.43:
>> For this bug report, yes.  But for the more general session management
>> handling, it really is "start where we stopped".
>
> But that's the whole problem: what do you define as "where we stopped"?
> As I said, there are as many current directories as there are buffers.

Yes there is, it is what getcwd returns.  That is where the process is 
started.  That is the current directory according to the OS.  A process can 
only have one current directory, and Emacs is no different.

>
>> Who knows what other/future packages save in the current directory?
>
> There's really no such thing as "Emacs's current directory".
>

Yes there is, it is what getcwd returns.  Anything else is just cosmetics and 
not the current directory of the Emacs process.


>> Relative filenames perhaps?  Not to mention the fact that I personally
>> get irritated that C-x C-f from *scratch* starts with the wrong
>> directory in this case.
>
> Then desktop should save the default-directory of *scratch* (and
> maybe/probably other buffers as well).  IIUC you can do that by adding
> default-directory to desktop-locals-to-save.
>
>> That is too simplified, Emacs has more state than just the desktop file.
>
> But "--chdir" is too simplified, Emacs has many more current directories
> than just "the one" ;-)
>

No, a process can only have one current directory, and so does Emacs,
it is what getcwd returns.

	Jan D.

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

[Stefan Monnier]

>>> For this bug report, yes.  But for the more general session management
>>> handling, it really is "start where we stopped".
>> But that's the whole problem: what do you define as "where we stopped"?
>> As I said, there are as many current directories as there are buffers.
> Yes there is, it is what getcwd returns.  That is where the process is
> started.

A far cry from "where we stopped".

> That is the current directory according to the OS.  A process can
> only have one current directory, and Emacs is no different.

But that directory is mostly invisible to Emacs, because Emacs really
doesn't have such a concept (that the OS imposes it on us doesn't make
any difference to it).

>>> Who knows what other/future packages save in the current directory?
>> There's really no such thing as "Emacs's current directory".
> Yes there is, it is what getcwd returns.  Anything else is just cosmetics
> and not the current directory of the Emacs process.

In which way is this getcwd data relevant/useful?


        Stefan

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

[Jan Djärv]

2010-05-04 04:38, Stefan Monnier skrev:
>>>> For this bug report, yes.  But for the more general session management
>>>> handling, it really is "start where we stopped".
>>> But that's the whole problem: what do you define as "where we stopped"?
>>> As I said, there are as many current directories as there are buffers.
>> Yes there is, it is what getcwd returns.  That is where the process is
>> started.
>
> A far cry from "where we stopped".

No, according to the OS, that is exactly where the process current directory 
is when we stop.  Where do you say the process current directory is when Emacs 
stops?

Just because Emacs can remember a bunch of directories doesn't men it "has" 
different current directories.  Eamcs does not do chdir, except in 
subprocesses, so the original process stays in the same directory the whole time.

A file dialog can remember where it was when closed last, and by default show 
that directory again.  That doesn't mean that the process now has two current 
directories.

>
>> That is the current directory according to the OS.  A process can
>> only have one current directory, and Emacs is no different.
>
> But that directory is mostly invisible to Emacs, because Emacs really
> doesn't have such a concept (that the OS imposes it on us doesn't make
> any difference to it).

So what?  Session management doesn't care what the processes do internally. 
Restarting Emacs in the same directory as it stopped always work, but just 
pointing out a desktop file does not.  For example, the directory remembered 
by *scratch* is not restored.

>
>>>> Who knows what other/future packages save in the current directory?
>>> There's really no such thing as "Emacs's current directory".
>> Yes there is, it is what getcwd returns.  Anything else is just cosmetics
>> and not the current directory of the Emacs process.
>
> In which way is this getcwd data relevant/useful?

It is where Emacs was started, it is where Emacs was stopped, and thus where 
Emacs should be restarted.  Where else should Emacs be restarted?
Its not like we didn't do this before, but by the aid of the Gnome session 
manager.  Now the session manager don't do this for us anymore.  It is not 
radically new behavior, it is restoring old behaviour.

I don't understand, why would we ever want Emacs to restart in a different 
directory than where it stopped?  You claim there is a bunch of directories to 
choose from, so we should just give up and not do anything?  That is hardly 
constructive.

	Jan D.

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

[Stephen J. Turnbull]

Jan Djärv writes:

 > So what?  Session management doesn't care what the processes do
 > internally.

No, but users do.  And users don't care what Emacs's actual cwd is
(except that I am daily thankful that Emacs doesn't chdir because that
means that Emacs's cwd is never on the USB key that I want to umount!)

 > It is where Emacs was started, it is where Emacs was stopped, and
 > thus where Emacs should be restarted.  Where else should Emacs be
 > restarted?

For desktop.el users, it should be restarted in desktop-dirname* as of
the time Emacs stops, because otherwise desktop won't find the right
desktop file.

*I suspect this means not chdir(DESKTOP-DIRNAME) in C, but rather
(progn (switch-to-buffer "*scratch*") (cd DESKTOP-DIRNAME)), before
invoking desktop-read.

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

[Jan D.]

On 2010-05-04 13:49, Stephen J. Turnbull wrote:
> Jan Djärv writes:
>
>   >  So what?  Session management doesn't care what the processes do
>   >  internally.
>
> No, but users do.  And users don't care what Emacs's actual cwd is
> (except that I am daily thankful that Emacs doesn't chdir because that
> means that Emacs's cwd is never on the USB key that I want to umount!)

So you don't care but you do care?

--chdir solves a problem for current users of session restarted Emacs. 
Not all problems, but enough to get by.  You are still just arguing for 
enhancements, not that chdir is bad.  If you don't care (except when you 
do in the USB case), why do you think removing it is such a good idea? 
If someone wants enhancements to session restore, please implement it then.

	Jan D.

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

[Stefan Monnier]

>>>>> For this bug report, yes.  But for the more general session management
>>>>> handling, it really is "start where we stopped".
>>>> But that's the whole problem: what do you define as "where we stopped"?
>>>> As I said, there are as many current directories as there are buffers.
>>> Yes there is, it is what getcwd returns.  That is where the process is
>>> started.
>> A far cry from "where we stopped".

> No, according to the OS, that is exactly where the process current directory
> is when we stop.  Where do you say the process current directory is when
> Emacs stops?

What I say is that users couldn't care less what's the POSIX cwd of
Emacs (as long as it's sane, that is).

> A file dialog can remember where it was when closed last, and by default
> show that directory again.  That doesn't mean that the process now has two
> current directories.

You're suggesting a user-level feature (a new command line arg) based on
some obscure internal detail.  That doesn't make much sense unless
there's no other way to get the user-level behavior you want.

> internally. Restarting Emacs in the same directory as it stopped always
> work, but just pointing out a desktop file does not.  For example, the
> directory remembered by *scratch* is not restored.

The --chdir is not enough to restore the default-directory of all the
buffers either.  So if you want to preserve that info, then add
`default-directory' to desktop-locals-to-save rather than try to get
that same result in a round about way by adding a new vaguely related
feature which doesn't quite do what we want anyway.

>>>>> Who knows what other/future packages save in the current directory?
>>>> There's really no such thing as "Emacs's current directory".
>>> Yes there is, it is what getcwd returns.  Anything else is just cosmetics
>>> and not the current directory of the Emacs process.
>> In which way is this getcwd data relevant/useful?

> It is where Emacs was started, it is where Emacs was stopped, and thus where
> Emacs should be restarted.

Why?  Why would a user care?

> Where else should Emacs be restarted?

Doesn't matter as long as the end result is the one we want.
Usually I'd expect $HOME to be a good choice.

> I don't understand, why would we ever want Emacs to restart in a different
> directory than where it stopped?  You claim there is a bunch of directories
> to choose from, so we should just give up and not do anything?

Exactly, because that cwd doesn't matter to Emacs (and by extension to
Emacs's users).


        Stefan

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

[Jan D.]

On 2010-05-04 15:48, Stefan Monnier wrote:

>
> What I say is that users couldn't care less what's the POSIX cwd of
> Emacs (as long as it's sane, that is).

Oh, they do care where Emacs is started from the command line.  How else 
can they get Emacs to automatically read saved desktops?

>
> You're suggesting a user-level feature (a new command line arg) based on
> some obscure internal detail.  That doesn't make much sense unless
> there's no other way to get the user-level behavior you want.

I didn't think automatic loading of desktops and getting the right 
default-direcotry was obscure.

>
> The --chdir is not enough to restore the default-directory of all the
> buffers either.   So if you want to preserve that info, then add
> `default-directory' to desktop-locals-to-save rather than try to get
> that same result in a round about way by adding a new vaguely related
> feature which doesn't quite do what we want anyway.

No, if I have done a cd in some buffer, it is not enough.  But for all 
other uses, it is.
How will desktop-locals-to-save restore the default-directory if I don't 
use desktop.el?


>
>> Where else should Emacs be restarted?
>
> Doesn't matter as long as the end result is the one we want.
> Usually I'd expect $HOME to be a good choice.

And how will Emacs avoid to load my desktop file there if I didn't use 
it previously?

	Jan D.

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

[Stephen J. Turnbull]

Jan Djärv writes:

 > > There's really no such thing as "Emacs's current directory".

 > Yes there is, it is what getcwd returns.  Anything else is just
 > cosmetics and not the current directory of the Emacs process.

You're taking the implementation way too seriously.  The question is,
do any users (other than the one named "Jan Djärv", of course) think
that what getcwd() returns is of interest?  I certainly don't, for one
sample point.  And, if the do care at all, how does that rank compared
to the local values of `default-directory'?

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

[Jan Djärv]

2010-05-04 05:03, Stephen J. Turnbull skrev:
> Jan Djärv writes:
>
>   >  >  There's really no such thing as "Emacs's current directory".
>
>   >  Yes there is, it is what getcwd returns.  Anything else is just
>   >  cosmetics and not the current directory of the Emacs process.
>
> You're taking the implementation way too seriously.  The question is,
> do any users (other than the one named "Jan Djärv", of course) think
> that what getcwd() returns is of interest?  I certainly don't, for one
> sample point.  And, if the do care at all, how does that rank compared
> to the local values of `default-directory'?
>
>

We are talking about restarting Emacs from the session manager.  So far no one 
has come up with a better solution.  Should we start an Emacs process for each 
unique default-directory?  Pick one at random?  Ignore the problem and let the 
session manager descide?

Put up a solution that addresses the problems:

Desktop file isn't loaded.
*scratch* and *Messages* and more get the wrong default directory.

It is nice of you to let us know that you don't care about getcwd, but not 
very helpful.

	Jan D.

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

[Stephen J. Turnbull]

Jan Djärv writes:

 > Put up a solution that addresses the problems:
 > 
 > Desktop file isn't loaded.
 > *scratch* and *Messages* and more get the wrong default directory.
 > 
 > It is nice of you to let us know that you don't care about getcwd, but not 
 > very helpful.

As I wrote, it's *one* data point.

Specifically, I can't recall ever saving *scratch* or " *Message-Log*"
to wherever I started my session; I want to save it to a project-
specific directory, which in typical cases for me is many characters
of typing away from what getcwd would return.  (In fact, I often do
C-x h M-w C-x b RET C-x C-f log RET C-y C-x C-s or the like.)

Similarly, in my usage, it's very likely that the reason I have
multiple sessions to choose from is that I split a session, by simply
killing a bunch of buffers I don't need in the new session, and saving
a desktop file somewhere appropriate.  AFAICT that place is highly
unlikely to have anything to do with getcwd(), but I'm willing to
listen to your explanation.

So my solution would be to (1) add `default-directory' to
`desktop-locals-to-save' (which handles the default directory settings
for *scratch* and " *Message-Log*", I think somebody already mentioned
this), (2) write the desktop file to somewhere appropriate (probably
`desktop-dirname', maybe asking the user), (3) write a thunk library

    (cd (or DESKTOP-DIRNAME "~"))
    (load-user-init-file)          ; does Emacs have this?

to ~/.emacs.d/sessions/xsm-XSM-CLIENT-ID.el, and set SmRestartCommand to

emacs -q -l ~/.emacs.d/sessions/xsm-XSM-CLIENT-ID.el -clientId XSM-CLIENTID

This is pretty kludgy; an improvement would be to build knowledge of
XSM and any other common desktop session management protocols into
Emacs, lose the "-q -l ~/.emacs.d/sessions/xsm-XSM-CLIENT-ID.el", and
have an internal `session-manager-client-id' variable, which if
non-nil is a string representing a session manager client ID, and use
that to generate and load the thunk library.

The thunk library probably can't really be avoided, because with it,
the generalization to Emacs session managers other than desktop.el
should be fairly straightforward.  Without it, you'd need to build
that knowledge into Emacs core.  Yucky.

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

[Jan D.]

On 2010-05-04 13:33, Stephen J. Turnbull wrote:

> Specifically, I can't recall ever saving *scratch* or " *Message-Log*"
> to wherever I started my session; I want to save it to a project-
> specific directory, which in typical cases for me is many characters
> of typing away from what getcwd would return.  (In fact, I often do
> C-x h M-w C-x b RET C-x C-f log RET C-y C-x C-s or the like.)

I don't save *scratch*, but I rely on the fact that
   C-x b *sc<TAB><RETURN> C-x C-f
makes it easy to open files where Emacs was started.


>
> Similarly, in my usage, it's very likely that the reason I have
> multiple sessions to choose from is that I split a session, by simply
> killing a bunch of buffers I don't need in the new session, and saving
> a desktop file somewhere appropriate.  AFAICT that place is highly
> unlikely to have anything to do with getcwd(), but I'm willing to
> listen to your explanation.

The way to get Emacs to load a desktop file when starting Emacs is to 
start Emacs in the directory where it was saved.  The --chdir emulated 
that.  I'm not saying that setting a desktop file to another directory 
is handled well by this, but it wasn't handeled at all previously.

It is obvious that the arguments against --chdir comes without any long 
term usage of restoring Emacs sessions through the session manager. 
Otherwise, this would have been fixed by those affected by it.  I'm not 
affected, as I start Emacs in the directory where I save my desktop (if 
I do save it that is).

What you are arguing for is an enhancement that works just as fine with 
or without --chdir.  With Emacs today, you can't restart an Emacs and 
load a desktop file saved in another place different from where Emacs is 
started.


>
> So my solution would be to (1) add `default-directory' to
> `desktop-locals-to-save' (which handles the default directory settings
> for *scratch* and " *Message-Log*", I think somebody already mentioned
> this),

This assumes you are using desktop.  If you restart an Emacs without any 
desktop saved, the default directory is still wrong.  But with --chdir 
it is not.


> (2) write the desktop file to somewhere appropriate (probably
> `desktop-dirname', maybe asking the user), (3) write a thunk library
>
>      (cd (or DESKTOP-DIRNAME "~"))
>      (load-user-init-file)          ; does Emacs have this?
>
> to ~/.emacs.d/sessions/xsm-XSM-CLIENT-ID.el, and set SmRestartCommand to
>
> emacs -q -l ~/.emacs.d/sessions/xsm-XSM-CLIENT-ID.el -clientId XSM-CLIENTID
>

There is no need to use -l or fiddle with SmRestartCommand, Emacs has 
had automatic save and restore of session data in a session file since 
2002 (actually, it is called ~/emacs.d/session-CLIENT-ID), but nobody 
has taken advantage of this fact AFAIK.

desktop.el would have to add a function to the hook 
emacs-save-session-functions that stores whatever data it needs to 
recover.  For example, the desktop file name in use.

	Jan D.

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

[Stefan Monnier]

> The way to get Emacs to load a desktop file when starting Emacs is to start
> Emacs in the directory where it was saved.  The --chdir emulated that.  I'm
> not saying that setting a desktop file to another directory is handled well
> by this, but it wasn't handeled at all previously.

Yes, --chdir solves partially the problem you encountered.  The problem
with that is the "partially".  Adding a new feature to *partially* fix
a bug is only a good idea if that bug can't be solved fully some other
way (e.g. by adding a different feature).

>> So my solution would be to (1) add `default-directory' to
>> `desktop-locals-to-save' (which handles the default directory settings
>> for *scratch* and " *Message-Log*", I think somebody already mentioned
>> this),
> This assumes you are using desktop.  If you restart an Emacs without any
> desktop saved, the default directory is still wrong.  But with --chdir it
> is not.

If you don't use desktop, then Emacs is restarted in a completely
different state, so it's really no surprise that the default-directory
in *scratch* is different.  It's just a very minor detail in
this respect.

> desktop.el would have to add a function to the hook
> emacs-save-session-functions that stores whatever data it needs to
> recover.  For example, the desktop file name in use.

That would sound like The Right Way to solve the problem, don't you think?


        Stefan

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

[Jan D.]

On 2010-05-04 15:54, Stefan Monnier wrote:

> Yes, --chdir solves partially the problem you encountered.  The problem
> with that is the "partially".  Adding a new feature to *partially* fix
> a bug is only a good idea if that bug can't be solved fully some other
> way (e.g. by adding a different feature).

The --chdir was introduced to restore a feature we had earlier, it is 
not a new feature.  It is a new command line option, but an old feature 
w.r.t. session management.


>> This assumes you are using desktop.  If you restart an Emacs without any
>> desktop saved, the default directory is still wrong.  But with --chdir it
>> is not.
>
> If you don't use desktop, then Emacs is restarted in a completely
> different state, so it's really no surprise that the default-directory
> in *scratch* is different.  It's just a very minor detail in
> this respect.

It may be to you, but it is not to me.  I open files all the time from 
*scratch* just because the default directory there is right.  It is a 
bug for Emacs not to restore this after a session restart.

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.

>
>> desktop.el would have to add a function to the hook
>> emacs-save-session-functions that stores whatever data it needs to
>> recover.  For example, the desktop file name in use.
>
> That would sound like The Right Way to solve the problem, don't you think?
>

It solves another problem, that of not having the desktop file in Emacs 
current directory.  It still does not solve the problem of default 
directory for buffers like *scratch*.

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.

	Jan D.

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

[Stefan Monnier]

>> Yes, --chdir solves partially the problem you encountered.  The problem
>> with that is the "partially".  Adding a new feature to *partially* fix
>> a bug is only a good idea if that bug can't be solved fully some other
>> way (e.g. by adding a different feature).
> The --chdir was introduced to restore a feature we had earlier, it is
> not a new feature.

Arguing on words.

> It is a new command line option, but an old feature
> w.r.t. session management.

I still don't understand what was that feature you're talking about.
The way I see it, it was more like some accidental behavior which
happened to be convenient.  I'd like to use this "breakage" as an
opportunity to replace those lucky accidents by sound behavior.

> > What I say is that users couldn't care less what's the POSIX cwd of
> > Emacs (as long as it's sane, that is).
> Oh, they do care where Emacs is started from the command line.  How else can
> they get Emacs to automatically read saved desktops?

The fact that there are no other way currently is (one of) the problem(s)
I'd like to fix here.

> > You're suggesting a user-level feature (a new command line arg) based on
> > some obscure internal detail.
> I didn't think automatic loading of desktops and getting the right
> default-directory was obscure.

You misread, since neither of those two are internal details.

> > The --chdir is not enough to restore the default-directory of all the
> > buffers either.   So if you want to preserve that info, then add
> > `default-directory' to desktop-locals-to-save rather than try to get
> > that same result in a round about way by adding a new vaguely related
> > feature which doesn't quite do what we want anyway.
> No, if I have done a cd in some buffer, it is not enough.  But for all
> other uses, it is.

No, there are plenty of other cases, since the default-directory is
generally inherited from the buffer from which you create the new
buffer: no need to "cd", just open a file, and then do C-h f car RET and
you'll get that file's directory as default-directory in *Help*.

> > Doesn't matter as long as the end result is the one we want.
> > Usually I'd expect $HOME to be a good choice.
> And how will Emacs avoid to load my desktop file there if I didn't use
> it previously?

That argues for a change in desktop.el to make it behave better with
session management.

>> If you don't use desktop, then Emacs is restarted in a completely
>> different state, so it's really no surprise that the default-directory
>> in *scratch* is different.  It's just a very minor detail in
>> this respect.
> It may be to you, but it is not to me.  I open files all the time from
> *scratch* just because the default directory there is right.  It is a bug
> for Emacs not to restore this after a session restart.

Can you describe your use-case more precisely?

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'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?

> 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.


        Stefan

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

[Stephen J. Turnbull]

Stefan Monnier writes:

 > That argues for a change in desktop.el to make it behave better with
 > session management.

Maybe.  The scheme I proposed (a thunk library in .emacs.d/session/)
will work fine with desktop.el as it is.  Modulo this problem, that is:

 > > 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.

This is a bug in desktop.el.  .emacs.d/session/ is a reasonable place
to put the desktop file for cases where there's no opportunity for
user interaction, or the user has expressed a preference for no
interaction (which is a very plausible preference with a good session
manager).  Name it .emacs.desktop.CLIENT-ID or so for uniqueness.

 > > When the session manager then restarts Emacs in $HOME it will
 > > read my desktop file in $HOME.  That is a bug also.

My scheme deals with that issue without changing desktop.el.  I think
that is important, because you're likely to (a) break stuff for CLI
users, and (b) there's no desktop manager spec on the table yet, so
you're likely to end up changing everything a few times as the spec
becomes clearer.  The thunk gives you a way to experiment with
interacting with the GUI session manager without horking desktop.el.

Note that my scheme is also upward-compatible with the kinds of
changes you are proposing to desktop.el -- the desktop file just moves
to .emacs.d/session/.  CLI users will still need some way to select
sessions.  One possibility would be the traditional .emacs.desktop
file method, another would be for desktop to look in .emacs.d/session/
for "active" sessions and offer the user a menu at startup.  I suspect
CLI users will detest the menu idea, but it's just proof of concept.

I don't actually advocate my scheme -- I haven't time to think
carefully about it or implement it for Emacs.  But it seems to me that
you have to do at least that well.

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

[Jan Djärv]

2010-05-04 20:50, Stefan Monnier skrev:

>
> I still don't understand what was that feature you're talking about.
> The way I see it, it was more like some accidental behavior which
> happened to be convenient.  I'd like to use this "breakage" as an
> opportunity to replace those lucky accidents by sound behavior.

To get Emacs to automatically read my desktop:
% cd to/dir/of/interest
% emacs &

To get session management to automatically read my desktop, --chdir emulates 
that usage.

Maybe people just start Emacs at $HOME and load desktop interactivly, I don't 
know.


>>> Doesn't matter as long as the end result is the one we want.
>>> Usually I'd expect $HOME to be a good choice.
>> And how will Emacs avoid to load my desktop file there if I didn't use
>> it previously?
>
> That argues for a change in desktop.el to make it behave better with
> session management.

Yes it does.


>> It may be to you, but it is not to me.  I open files all the time from
>> *scratch* just because the default directory there is right.  It is a bug
>> for Emacs not to restore this after a session restart.
>
> Can you describe your use-case more precisely?

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.

>
> 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'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.  But desktop-read can't read just part 
of a file, so restore may become an issue.  Ideally we would just load the 
session specific file on restart, but desktop has some cleanups it does in 
desktop-read after load.

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).  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.  And 
there is the possibility that the desktop file is locked, so it will ask a 
question anyway.

>
>> 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.  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).

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.  After we 
have restored from the session file, we must then tell desktop that it is now 
okay to save to its file again.

If desktop-save-mode isn't on, this becomes easier.

	Jan D.

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

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

[Jan Djärv]

Stefan Monnier skrev 2010-05-05 16.00:

>>> 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,

I took "even without" to mean "with an without".

> 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.

It is how the current code works. It can be fixed.


>
>> 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.

             ;; `desktop-create-buffer' puts buffers at end of the buffer list.
             ;; We want buffers existing prior to evaluating the desktop (and
             ;; not reused) to be placed at the end of the buffer list, so we
             ;; move them here.
             (mapc 'bury-buffer
                   (nreverse (cdr (memq desktop-first-buffer (nreverse 
(buffer-list))))))
             (switch-to-buffer (car (buffer-list)))
             (run-hooks 'desktop-delay-hook)
             (setq desktop-delay-hook nil)
             (run-hooks 'desktop-after-read-hook)


	Jan D.

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

[Stefan Monnier]

>>> 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.

>  ;; `desktop-create-buffer' puts buffers at end of the buffer list.
>  ;; We want buffers existing prior to evaluating the desktop (and
>  ;; not reused) to be placed at the end of the buffer list, so we
>  ;; move them here.
>  (mapc 'bury-buffer
>        (nreverse (cdr (memq desktop-first-buffer (nreverse (buffer-list))))))
>  (switch-to-buffer (car (buffer-list)))
>  (run-hooks 'desktop-delay-hook)
>  (setq desktop-delay-hook nil)
>  (run-hooks 'desktop-after-read-hook)

It looks perfectly harmless to run it when restoring a session.


        Stefan

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

[Juri Linkov]

> Put up a solution that addresses the problems:
>
> *scratch* and *Messages* and more get the wrong default directory.

Yes, it's important that *scratch* and *Messages* should get the
directory where Emacs was started.  That's why I did this change
to set the right directory in the startup screen's buffer:

  2008-02-12  Juri Linkov  <juri@jurta.org>

          * startup.el (fancy-startup-screen, normal-splash-screen):
          Set default-directory to command-line-default-directory.

Now the question is where `command-line-default-directory'
should get its value.  It's docstring says:

  (defvar command-line-default-directory nil
    "Default directory to use for command line arguments.
  This is normally copied from `default-directory' when Emacs starts.")

All this is right and it seems currently there is no problem with
*scratch* and *Messages*, i.e. they get the right directory.

However, a new command line arg --chdir seems unnecessary.  When the
user wants `command-line-default-directory' to be another directory,
then the user can cd to this directory before running Emacs.

If this is necessary for the session management, it's another problem.
There is a special arg --smid that could be used.

> Desktop file isn't loaded.

I think --smid should restore the same desktop file that was saved
in the previous session.  And also restore the old value of
`command-line-default-directory'.

-- 
Juri Linkov
http://www.jurta.org/emacs/

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

[Jan Djärv]

2010-05-04 18:45, Juri Linkov skrev:

>           * startup.el (fancy-startup-screen, normal-splash-screen):
>           Set default-directory to command-line-default-directory.
>
> Now the question is where `command-line-default-directory'
> should get its value.  It's docstring says:
>
>   (defvar command-line-default-directory nil
>     "Default directory to use for command line arguments.
>   This is normally copied from `default-directory' when Emacs starts.")

Isn't this circular?  Who gets its value first?  And remember, when starting 
from the session manager, no splash screen is shown, so the code that the 
Changelog entry above refers to is never run.

>
> However, a new command line arg --chdir seems unnecessary.  When the
> user wants `command-line-default-directory' to be another directory,
> then the user can cd to this directory before running Emacs.

The user can not cd if Emacs is started from the session manager.

>
> If this is necessary for the session management, it's another problem.
> There is a special arg --smid that could be used.

I don't follow.  --smid is strictly for session manager use.  If you mean 
Emacs could save command-line-default-directory when it is terminated by the 
session manager, that is doable.

>
>> Desktop file isn't loaded.
>
> I think --smid should restore the same desktop file that was saved
> in the previous session.  And also restore the old value of
> `command-line-default-directory'.
>

And if no session file was used, and there is one in the directory Emacs is 
restarted from?

	Jan D.

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

[Juri Linkov]

>>   (defvar command-line-default-directory nil
>>     "Default directory to use for command line arguments.
>>   This is normally copied from `default-directory' when Emacs starts.")
>
> Isn't this circular?  Who gets its value first?

Yes, this is a problem.  The very first thing `command-line' does
is to set `command-line-default-directory' from `default-directory',
and the very last thing it does is to load the session file.

I think this order is not right.  At least, restoring the saved session
should cooperate with restoring the saved desktop.  `command-line'
restores the desktop when it runs `after-init-hook'.  So perhaps
`emacs-session-restore' should be called before `desktop-read'.
Then desktop.el could save the desktop file name in the session file
and restore it in another session using the desktop file name
from the session data.

>> However, a new command line arg --chdir seems unnecessary.  When the
>> user wants `command-line-default-directory' to be another directory,
>> then the user can cd to this directory before running Emacs.
>
> The user can not cd if Emacs is started from the session manager.

This means that --chdir should not be a user-level command-line arg
If it is intended for the session manager, then `--smid' should be
enough for the session manager.

>> If this is necessary for the session management, it's another problem.
>> There is a special arg --smid that could be used.
>
> I don't follow.  --smid is strictly for session manager use.  If you
> mean Emacs could save command-line-default-directory when it is
> terminated by the session manager, that is doable.

Emacs can save `command-line-default-directory', but not restore (I mean
the problem mentioned above).  But the code saved to the session file
could explicitly set `default-directory' of *scratch* and *Messages* to
the saved value of `command-line-default-directory'.

>>> Desktop file isn't loaded.
>>
>> I think --smid should restore the same desktop file that was saved
>> in the previous session.  And also restore the old value of
>> `command-line-default-directory'.
>
> And if no session file was used, and there is one in the directory
> Emacs is restarted from?

When `emacs-save-session-functions' will save the current desktop
file name, then `emacs-session-restore' will restore the desktop
using this file name.

-- 
Juri Linkov
http://www.jurta.org/emacs/