Re: Changes for emacs 28, Re: Changes for emacs 28

[Robert Pluim <rpluim@gmail.com>]

>>>>> On Mon, 14 Sep 2020 14:15:40 +0200, Thibaut Verron <thibaut.verron@gmail.com> said:

    Thibaut> Le lun. 14 sept. 2020 à 13:54, Robert Pluim <rpluim@gmail.com> a écrit :
    >> >>>>> On Mon, 14 Sep 2020 09:53:28 +0200, Thibaut Verron <
    >> thibaut.verron@gmail.com> said:
    >> >>
    >> >> We could set 'kill-buffer-hook' to a querying function in buffers
    >> >> created via the toolbar.
    >> >>
    >> 
    Thibaut> There is already a (buffer-local) variable buffer-offer-save
    >> which, set to
    Thibaut> 'always, causes save-some-buffers to query for save the
    >> corresponding
    Thibaut> buffer, if non-empty.
    >> 
    >> Right, but toolbar-save doesnʼt run save-some-buffers. That could be
    >> added, but it seems people feel toolbar space is precious (here the
    >> default toolbar uses slightly more than 50% of the available width
    >> when running -Q)
    >> 

    Thibaut> The save button runs save-buffer, so it should DTRT already, no?

Sorry, yes. The 'new' button forces you to choose a filename for the
buffer, so saving it works (that will teach me to talk about features
I donʼt use)

    >> That covers the 'exiting emacs' scenario, weʼd still need something to
    >> cover the 'clicked the kill-buffer button'.

And again, this is already covered, since the buffer has an associated
file, emacs queries if you try to kill a buffer with unsaved changes.

    Thibaut> That's correct, I didn't have this usage in mind. Kill-buffer-hook seems to
    Thibaut> be more for cleanup, but kill-buffer-query-functions could do the job as a
    Thibaut> first step (as in, "do you really want to kill without saving?"). I believe
    Thibaut> that
    Thibaut> the most natural would be to add such a test to kill-buffer, since it
    Thibaut> already
    Thibaut> takes care of modified file buffers.

    Thibaut> All those approaches would also affect other commands killing the buffer,
    Thibaut> preventing a user from accidentally losing data because of an unfortunate
    Thibaut> keypress.

And now that Iʼve tested it, attempting to exit emacs with a modified
buffer throws up the GUI version of the 'save/no save/view' question,
so thatʼs OK.

So in short: nothing to implement :-)


    Thibaut> Or if we really want to go
    >> whole hog, we automatically save the state of buffers created via the
    >> toolbar, and restore them on startup.
    >> 

    Thibaut> Restoring them as-is is what notepad++ does (or did when I last used it
    Thibaut> 10 years ago). I personally did not like this behavior, and I didn't have
    Thibaut> remotely as many open files in notepad++ as I do in a typical emacs session.

Itʼs a behaviour thatʼs become strongly expected, mainly because
people have become conditioned to 'restart where I left off' behaviour
from web browsers, I suspect.

    Thibaut> On the other hand, auto-saving and offering to restore could be sensible.
>>>>> On Mon, 14 Sep 2020 09:18:29 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said:

    Eli> But with a buffer that doesn't visit a file, you don't get any prompt
    Eli> at all.

The toolbar does not let you create such buffers (I thought it did,
but it doesnʼt).

    >> We could set 'kill-buffer-hook' to a querying function in buffers
    >> created via the toolbar.

    Stefan> Beside this question of "save" there's also the issue of "autosave".

    Stefan> Why not create a new and "normal" file-buffer whose file name is
    Stefan> something like `~/.emacs.d/newfiles/untitled<N>`?

See above: the buffer will have an associated file, so autosave should
just work.

Robert