[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Changes for emacs 28
From: |
Boruch Baum |
Subject: |
Re: Changes for emacs 28 |
Date: |
Tue, 8 Sep 2020 07:52:02 -0400 |
User-agent: |
NeoMutt/20180716 |
On Tue, 08 Sep 2020 12:13:04 +0100, João Távora wrote:
> Richard Stallman <rms@gnu.org> writes:
> > I like the idea, but this should be something to set in .emacs,
> > not a command-line option.
>
> It must be a command-line option because when reproducing and fixing
> bugs on Emacs, you very frequently have the need to run "a bare Emacs
> -Q" frequently from a shell, devoid of any third-party packages that may
> be interfering.
That's only ever is true when reporting a bug to the emacs project
itself. Should your proposal be adopted as an add-on loaded via .emacs
as Richard Stallman suggests, it can be treated like any of the other
zillion emacs third-party packages that are competently and
professionally debugged by their own authors and maintainers, without
imposing extra burdens on the maintainers of the core emacs project.
I do think it would be great for emacs to include a curated collection
of sample init files descriptively labeled for use-case. I would go
further and suggest that the technique of using an org-mode file with
embedded code blocks as one's emacs init file be adopted as standard,
and be used for those collection of init files. That way each code block
can be explained and annotated to 'new' users.
--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0
Re: Changes for emacs 28, Tassilo Horn, 2020/09/11
Re: Changes for emacs 28, Boruch Baum, 2020/09/07
Re: Changes for emacs 28, Boruch Baum, 2020/09/08
Re: Changes for emacs 28, Boruch Baum, 2020/09/08
Re: Changes for emacs 28,
Boruch Baum <=
Re: Changes for emacs 28, Boruch Baum, 2020/09/08
Re: Changes for emacs 28, TEC, 2020/09/08