Re: Larger GC thresholds for non-interactive Emacs

[Eli Zaretskii <eliz@gnu.org>]

> From: Lynn Winebarger <owinebar@gmail.com>
> Date: Thu, 23 Jun 2022 13:07:44 -0400
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, Stefan Monnier <monnier@iro.umontreal.ca>, 
> 	Ihor Radchenko <yantar92@gmail.com>, Mattias Engdegård <mattiase@acm.org>, 
> 	Tim Cross <theophilusx@gmail.com>, rms@gnu.org, Alan Mackenzie <acm@muc.de>, 
> 	emacs-devel <emacs-devel@gnu.org>
> 
> > We lack someone in the role of the "project historian", who would then
> > summarize and publish the design discussions in the form of such
> > notes.  Volunteers are most welcome.
> >
> 
> It's not the discussion (or history) per se, but the factors that decided
> the current
> design choices.  An example would be the #ifdef DOUG_LEA_MALLOC blocks in
> lisp_align_malloc
> of alloc.c that prevent allocating via mmap.  So far what I've read
> indicates
> that step is there to enable dumping by unexec (assuming I've understood
> correctly).
> Ideally there would be a design note (possibly generated from comments,
> possibly free standing)
> that would explain what the purpose of the restriction is, so you could
> tell if it's still
> relevant, and any negative impacts it has.  Also, if there are plans to
> remove it at
> some point, what (if any) the requirements/test for removing it would be,
> etc.  By "it",
> I mean any hypothetical design point, not just this particular one.
> Alternative designs could also be discussed along with the factors that led
> to their rejection, if it was significant enough.
> Now, those could be derived from mailing list discussions, but I wouldn't
> consider them
> "history".  Per subsequent mails in this thread, if a developer or code
> reviewer made
> a practice of citing particular mail messages (or even other sources), some
> extraction
> process might even be automated, but then there would be the question of
> copyright
> assignment.

What you describe is a full-time job, more or less.  I'd love to have
someone who'd volunteer to record all those points, but we don't have
him/her yet.

The only places where design is document are the large comments in
some source files.

> It would help if there were some taxonomy of features/design
> points for
> reference.  Is the bug database being used for that?

I don't think so (IIUC what you mean by that), and I don't really see
how bugs could serve in that role.  Most of the design changes and
redesigns in Emacs were developed without any bug report, simply
because those who did the job knew that a particular group of problems
needs to be taken care of.

> Actually, a good example (even though it's more post facto description than
> prospective
> design & cost-benefit tradeoff analysis) would be
> https://github.com/rocky/elisp-bytecode
> That is really useful documentation that would ideally be in the emacs docs
> or etc directory.

That's not design description, though.

> I put in a request to assign@gnu.org a few days ago, but I have not
> received any response yet.

Please ping them and CC me and Lars.