From: Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Stefan Kangas <stefan@marxist.se>, 44743@debbugs.gnu.org
Subject: bug#44743: native-comp: confirm-exit-emacs warns about active processes when compiling
Date: Sat, 21 Nov 2020 20:35:03 +0000 [thread overview]
Message-ID: <xjfzh3a78js.fsf@sdf.org> (raw)
In-Reply-To: <831rgmze3f.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 21 Nov 2020 21:47:48 +0200")
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Stefan Kangas <stefan@marxist.se>
>> Date: Sat, 21 Nov 2020 11:22:58 -0800
>> Cc: 44743@debbugs.gnu.org
>>
>> > FWIW, I think this should be controlled by a user option. It is not
>> > at all obvious that everyone would like compilation processes to be
>> > killed automatically, people might want to wait for them to complete.
>>
>> Compiling in the background should in my opinion work as transparently
>> as possible. The fact that we cache compilation results should be
>> considered an implementation detail. We don't need to shape our
>> outwardly behavior by such implementation details.
>
> I understand your opinion, but I don't think that's the only opinion
> that could exist. Caching the compiled modules can hardly be regarded
> as an implementation detail when compilation takes a tangible amount
> of time -- which is why we cache the results in the first place. IOW,
> if compilation is interrupted, Emacs will try to compile it again the
> next time, and the code will run slower than expected. So if this is
> an implementation detail, it will be acutely obvious to users, and
> they may wish to wait a bit with exiting Emacs to let the compilation
> run to the end. It is not unlike the case where you sent an email
> message and want to exit Emacs before the message transmission has
> ended. Users will appreciate a degree of control in these cases.
>
>> We could of course support what you suggest. I'm not against it as an
>> option. But I don't think it is very important, and it would take some
>> time and effort to implement and maintain. I'm not sure that effort is
>> well-spent at this point, and would rather leave it for the future.
>
> I think interrupting compilation also comes with maintenance
> head-aches, such as the temporary files left behind, incomplete .eln
> files we'd need to clean up, etc.
>
>> IOW, I think we should work on reasonable defaults first, and only add
>> options in later once we are sure that we really need them.
>
> I think the argument is about what is "reasonable" here, all the rest
> is agreed upon.
I also think this option should be controlled by a customize.
I can picture most "power users" legitimately willing to be informed of
these processes being killed if present at exit. OTOH I guess the
majority of non "power users" would like just to close Emacs
transparently.
Because of this my idea I think I'm for the transparent behavior as
default.
Andrea
next prev parent reply other threads:[~2020-11-21 20:35 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-19 22:24 bug#44743: native-comp: confirm-exit-emacs warns about active processes when compiling Stefan Kangas
2020-11-20 8:35 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-11-20 11:35 ` Eli Zaretskii
2020-11-21 19:22 ` Stefan Kangas
2020-11-21 19:47 ` Eli Zaretskii
2020-11-21 20:35 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2020-11-24 7:52 ` Lars Ingebrigtsen
2020-11-24 15:42 ` Eli Zaretskii
2020-11-24 16:08 ` Stefan Kangas
2020-11-24 16:29 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-02-25 22:51 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-02-26 0:45 ` Stefan Kangas
2021-02-26 7:05 ` Eli Zaretskii
2021-02-26 13:02 ` Stefan Kangas
2021-02-26 13:44 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-02-26 14:12 ` Eli Zaretskii
2021-02-26 14:28 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-02-26 17:26 ` Stefan Kangas
2021-02-26 18:55 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-02-26 19:54 ` Eli Zaretskii
2021-02-26 20:31 ` Glenn Morris
2021-02-27 2:14 ` Stefan Kangas
2021-02-27 7:23 ` Eli Zaretskii
2020-11-24 16:36 ` Eli Zaretskii
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xjfzh3a78js.fsf@sdf.org \
--to=bug-gnu-emacs@gnu.org \
--cc=44743@debbugs.gnu.org \
--cc=akrl@sdf.org \
--cc=eliz@gnu.org \
--cc=stefan@marxist.se \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.