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
next prev parent 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).