[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Eliminating etc/DOC - formatting multiline strings
From: |
Eli Zaretskii |
Subject: |
Re: Eliminating etc/DOC - formatting multiline strings |
Date: |
Sat, 25 Jan 2025 15:15:43 +0200 |
> Date: Sat, 25 Jan 2025 09:05:08 +0000
> Cc: emacs-devel@gnu.org, Stefan Monnier <monnier@gnu.org>
> From: Pip Cet via "Emacs development discussions." <emacs-devel@gnu.org>
>
> "Stefan Kangas" <stefankangas@gmail.com> writes:
>
> > I've been looking a little bit at how we could rid of etc/DOC, as per
> > this item in TODO:
> >
> > ** Eliminate the etc/DOC file altogether
> > We could try and eliminate the DOC file altogether. See
> > https://lists.gnu.org/r/emacs-devel/2021-05/msg00237.html
>
> I'd interpret this TODO item as narrowly as possible for a first step:
> let's get rid of etc/DOC and put its contents into the Emacs pdmp
> instead. It seems to be less than 1MB; my understanding is it's only
> read (while there is a quoting mechanism which modifies read docstrings,
> it uses characters which make-docfile never emits), which means that
> most operating systems will share the memory between Emacs binaries, and
> they can evict the pages entirely and reread it from disk if required.
>
> That's all I think we should do at first: read etc/DOC in temacs in
> loadup.el, stringify it, place it in a variable, dump it.
>
> For a second step, I'd like to suggest to rewrite the docfile part of
> make-docfile.c, incrementally, in Lisp. We would still parse C files
> with Emacs extensions into fragments which are then concatenated into a
> string that looks like etc/DOC does now, but it would be more obvious
> how to change things afterwards.
Please hold your horses.
I'd like to take a step back and ask why do we have that item in
etc/TODO in the first place? What do we have to gain from eliminating
the file?
I think we should start from answering those questions, because
otherwise the proposed path forward means a significant investment of
energy and development of non-trivial code, when the current code
works quite well. Unless eliminating the file is really important,
I'd hate to have our scarce resources devoted to that, instead of
working on much more important issues (like the igc branch etc.).