[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Larger GC thresholds for non-interactive Emacs
From: |
Eli Zaretskii |
Subject: |
Re: Larger GC thresholds for non-interactive Emacs |
Date: |
Fri, 24 Jun 2022 09:53:55 +0300 |
> From: Lynn Winebarger <owinebar@gmail.com>
> Date: Thu, 23 Jun 2022 18:08:53 -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>
>
> On Thu, Jun 23, 2022 at 2:37 PM Eli Zaretskii <eliz@gnu.org> wrote:
> >
>
> > > 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.
>
> I agree, but some of the bug reports are classified as something along
> the lines of "feature request" or "wishlist".
If you look at those, you will see that almost all of them request
minor features that have no impact on the design whatsoever. It is
very rare to have a feature request on the bug tracker that changes
the design or introduces new designs. I would even dare to say it
never happened, definitely not on my watch.
> I haven't found any other database tracking anything corresponding
> to features, proposed or otherwise.
We do have etc/TODO. Did you look there?
> Once something is in place, no matter how bare-bones, the key would be
> maintainers mandating that any substantive introduction or revision of
> features be tied to appropriate entries for the corresponding
> design/spec documentation, in the same way and for the same reason
> coding standards are enforced.
I think you are greatly underestimating the efforts required to
maintain documentation of this kind, let alone the effort for creating
it basically from scratch.
Programmers usually don't like writing documentation, and most of them
cannot write good documentation even if they did want, in large part
because that take years of practice actually doing it. In a project
like Emacs, it is nigh impossible to force contributors and developers
do what they are reluctant to do in the first place. Without everyone
updating the documentation as they change code, any documentation
about design and internals will quickly become outdated, and thus not
just useless, but downright harmful. We have trouble keeping even our
user documentation up-to-date.
Are you aware of _any_ Free Software project that has any useful
documentation of this kind? Every project I ever knew or was involved
with which tried ended up abandoning that. A case in point is GDB,
which once had a "GDB Internals" manual -- it was always outdated, and
was eventually scrapped because the maintainers decided they could not
and didn't want to invest the effort. XEmacs tried in its time to
have the internals documented, but that was basically a one-man
effort, and even in it whole chapters were never written. Etc. etc.
I think there's some conclusion waiting here.
> That's assuming the maintainers consider such documentation
> important enough for enabling future potential contributors and
> maintainers to hold otherwise useful contributions in limbo.
And you think we don't? Of course we do! We also want to release
Emacs much more frequently, and we want it to have no bugs, and a few
other things. But somehow, each such goal cannot be reached for some
boring practical reasons, none of them related to their importance in
our eyes.
We do in general consider it somewhat more important to develop Emacs
and accept contributions than to document its internals, that's true.
Which is why I said up-thread that without someone who'd volunteer to
do this job (thus dedicating his/her time almost exclusively to it),
this will probably never happen, given the current state of our
resources, which are barely enough to maintain the status quo and move
forward at some reasonable pace.
> > 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.
>
> It's not like there isn't any discussion or justification of features
> offered prior to code being integrated into the main branch. It's more
> a challenge of how to weave what's there into a coherent account of
> what's going on in the code.
IME, you are wrong in that assumption. The significant changes in
Emacs design are almost never publicly discussed, not in the way that
would allow someone to glean the design from them.
E.g., take the bidirectional display example. That one I'm intimately
familiar with, so I can tell you with 100% confidence: the current
design cannot be possibly gleaned from any discussions. Quite the
contrary: the special emacs-bidi mailing list, created back there for
such discussions, holds many ideas expressed by people, none of them
actually relevant to what we have in Emacs today. At some point I
realized that I should stop wasting my time on those discussions, and
instead sit down and code this stuff, or the job will never be done.
It is no coincidence that the discussions on emacs-bidi died right
about the time I started implementing.
I did document the main design points in bidi.c, but if you look for
design decisions explained there, you won't find such explanations,
only the description of the design's end point.
And this example is somewhat exceptional, because the amount of
documentation of the design and the implementation there is relatively
large. In other areas the situation is more bleak.
> It would just be easier to automate some sort of design note
> extraction from the git log if references to mails could be associated
> with relevant features. I've never used org, but maybe there's some
> syntax that would be useful? Or maybe some notation from supercite
> for precise pulling of relevant text from list archives?
I wish this were true. It isn't. The discussions and the commit log
messages rarely describe the design, and in many cases barely describe
even the particular implementation. In a project where people with
write access can commit changes without any review, I don't know how
can anything else to be expected. We basically rely on each
individual to do the job perfectly and contribute to what you want to
see documented. The results are before our eyes, and they shouldn't
surprise anyone.
> > > 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.
>
> You probably have a more nuanced view than me on this. It's true,
> that document is focused on the specification (the "what") rather than
> the (detailed) "how" and "why" - is that what you mean?
Of course.
> Either way, if you want to understand how the operational semantics
> of emacs lisp work in practice, a document of that sort is
> invaluable. Without that, a document explaining the "why" isn't
> going to be able to be very concrete.
I agree, but the "what" is usually already available in the comments
to the code, though not everywhere and for every significant feature.
The "why" and "how", by contrast are almost completely missing.
To summarize: I'm not sure we should continue this discussion, because
I don't see where is it going and what could it possibly change in
practice. I agree with the value of having all of that documented,
I'm just saying it's a large job that needs dedicated individuals, and
I don't see how that could be replaced by any semi-automated means.
- Re: Larger GC thresholds for non-interactive Emacs, (continued)
- Re: Larger GC thresholds for non-interactive Emacs, Eli Zaretskii, 2022/06/23
- Re: Larger GC thresholds for non-interactive Emacs, Ihor Radchenko, 2022/06/23
- Re: Larger GC thresholds for non-interactive Emacs, Eli Zaretskii, 2022/06/23
- Re: Larger GC thresholds for non-interactive Emacs, Ihor Radchenko, 2022/06/25
- Re: Larger GC thresholds for non-interactive Emacs, Eli Zaretskii, 2022/06/25
- Re: Larger GC thresholds for non-interactive Emacs, Yuri Khan, 2022/06/25
- Re: Larger GC thresholds for non-interactive Emacs, Eli Zaretskii, 2022/06/25
- Re: Larger GC thresholds for non-interactive Emacs, Lynn Winebarger, 2022/06/23
- Re: Larger GC thresholds for non-interactive Emacs, Eli Zaretskii, 2022/06/23
- Re: Larger GC thresholds for non-interactive Emacs, Lynn Winebarger, 2022/06/23
- Re: Larger GC thresholds for non-interactive Emacs,
Eli Zaretskii <=
- Re: Larger GC thresholds for non-interactive Emacs, Lynn Winebarger, 2022/06/25
- Re: Larger GC thresholds for non-interactive Emacs, Stefan Monnier, 2022/06/22
- Re: Larger GC thresholds for non-interactive Emacs, Lynn Winebarger, 2022/06/22
- Re: Larger GC thresholds for non-interactive Emacs, Lynn Winebarger, 2022/06/20
- Re: Larger GC thresholds for non-interactive Emacs, Ihor Radchenko, 2022/06/19
- Re: Larger GC thresholds for non-interactive Emacs, Eli Zaretskii, 2022/06/19
- Re: Larger GC thresholds for non-interactive Emacs, Ihor Radchenko, 2022/06/19
- Re: Larger GC thresholds for non-interactive Emacs, Ihor Radchenko, 2022/06/19
- Re: Larger GC thresholds for non-interactive Emacs, Stefan Monnier, 2022/06/19
- Re: Larger GC thresholds for non-interactive Emacs, Ihor Radchenko, 2022/06/20