unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Sergey Organov <sorganov@gmail.com>
To: "Daniel Martín" <mardani29@yahoo.es>
Cc: emacs-devel@gnu.org
Subject: Re: Tweaking save-some-buffers-action-alist
Date: Fri, 18 Jun 2021 22:16:20 +0300	[thread overview]
Message-ID: <878s37j857.fsf@osv.gnss.ru> (raw)
In-Reply-To: <m1bl84i2ad.fsf@yahoo.es> ("Daniel Martín"'s message of "Thu, 17 Jun 2021 23:55:54 +0200")

Daniel Martín <mardani29@yahoo.es> writes:

> Sergey Organov <sorganov@gmail.com> writes:
>
>>
>> #+BEGIN_SRC emacs-lisp
>> (nconc
>>  save-some-buffers-action-alist
>>  '((?\C-\M-g
>>     (lambda (buf)
>>       (with-current-buffer buf
>>         (revert-buffer)))
>>     "revert this buffer")))
>> #+END_SRC
>>
>> I'm concerned as I use `nconc` that sounds unsafe, and then original
>> definition has some ",(" and ",(purecopy" tricks that I dunno if I need
>> to follow, and if so, how?
>
> Purecopy is a no-op except while Emacs is being built and dumped, so
> user customizations can omit it.  Evaluate (info "(elisp) Pure Storage")
> in Emacs to read more about this.
>
> Backquoting the alist will instruct the Elisp interpreter to not
> evaluate KEY, but evaluate the lambda FUNC.  Evaluating lambda
> expressions is generally a good idea because that enables
> byte-compilation and all its benefits: Faster code, less memory usage,
> some static checks, specially under lexical scope, etc.

Thanks for clarification and pointers!

Is `nconc` safe here, or should I `copy-seq` the original and modify
that instead?

>
>>
>> And to finally justify posting to 'emacs-devel', does it make sense to
>> add this capability to the default value of
>> `save-some-buffers-action-alist`?
>>
>
> I think reverting a buffer when compiling is not a very common need.

Surprisingly, it /is/ rather common when one has a lot of (often
unrelated to compilation) buffers, and finding the buffer in question
after compilation just to revert it is boring and is often forgotten
until the next compilation. Annoying.

> More importantly, the prompt already has a lot of options and adding one
> more will make it more complex and difficult to understand.

Well, yes, but I believe that the "Discard changes" option is the second
or third by usefulness among the rest supported: "Save Changes, Discard
Changes, Save All". To me it's "Ignore the change and continue" that
seems to be the least useful one.

I just want to have a way to finish entire prompt series and have no
modified buffers at the end. Doesn't seem to be too much to ask for.

As a side note, if there are too many options already, 'C-r' could be
removed and the buffer in question be shown automatically instead.

> At some point you have to draw the line between what should be a
> customization and what should be included in Emacs

Yep. I just think that the line in this particular case has been chosen
long ago, when `enable-recursive-minibuffers` was enabled by default, or
was unheard of, and now, when it is disabled by default, the line should
be drawn at a different level, making it possible again to conveniently
revert the buffer.

> and I think your suggestion can perfectly be a personal customization.

Probably it could, but right now it isn't. I don't think we can expect a
novice user to be able to tweak it like I did above, no way. Do you
in fact suggest to support this through `customize` or what?

The current state is that to the actual question I got from a novice
user: "How do I discard changes to the buffer when I run `compile` and
Emacs asks me if I want to save some?" I have to either give the "No
way" answer, or tweak Emacs for them. Sad.

BTW, if there were a way to cancel the `save-some-buffers` after 'C-r'
yet leave the modified buffer current, it'd solve the issue as well,
though in a different, less convenient way.

Thanks,
-- Sergey Organov




  reply	other threads:[~2021-06-18 19:16 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-17 16:12 Tweaking save-some-buffers-action-alist Sergey Organov
2021-06-17 21:55 ` Daniel Martín
2021-06-18 19:16   ` Sergey Organov [this message]
2021-06-18 23:02     ` Stefan Monnier
2021-06-19 12:31       ` Sergey Organov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=878s37j857.fsf@osv.gnss.ru \
    --to=sorganov@gmail.com \
    --cc=emacs-devel@gnu.org \
    --cc=mardani29@yahoo.es \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).