Sounds like a good plan to me... that's sorta the direction
I was trying to go with my code-change proposal, but I think
your solution is cleaner.
I am obviously not the best choice to make the code modifications...
I already revealed my glaring ignorance in that area.
Troy
-----Original Message-----
From: Hrvoje Niksic [mailto:hniksicīŧ arsdigita.com]
Sent: Thursday, October 26, 2000 9:27 AM
To: XEmacs Beta List; Troy Noble
Subject: Re: auto-save-list-file-name
Troy Noble <troy.noble(a)channelpoint.com> writes:
Yoshiki> Of course you can avoid this by calling
save-some-buffers
Yoshiki> but IMHO it should no be toggled in one session. It should
Yoshiki> persist one session or you'll end up with a lot of .save-*
Yoshiki> files left around after several sessions.
In light of this fact, I would agree you might not want to add
my changes... however should probably add a comment to the
definition for auto-save-list-file-prefix to the effect:
"This option should only be set once per session, preferably
in the user's initialization file. If it is set any time
later in the session, it may produce unpredictable behavior
with auto-save and session-recover."
This would hopefully help (most) others avoid falling into the trap
that Steve discovered.
Or...
we could argue that unsetting auto-save-list-file-prefix is a bad way
to disable the list autosaves in the first place. For one, it's
completely non-obvious from the name.
We could introduce a new variable named `inhibit-auto-save-session'
that would do exactly what its named implied. In addition to better
clarity, the advantage would be that the auto-save code could always
recover from a change of that variable in the middle of operation,
because changing it does not destroy any actual information.
For compatibility with the FSF and for sanity, we could also make
setting auto-save-list-file-prefix to nil have the same effect. The
warning would then not be necessary because you're not supposed to do
that anyway.
Yoshiki, Troy, what do you think?