Re: The linux terminal now supports alternative screen

"G. Branden Robinson" <[email protected]> Wed, 1 Apr 2026 03:57:43 -0500
Newsgroups	gmane.comp.lib.ncurses.bugs
Message-ID	<20260401085743.h3zicoapkrzgje7z@illithid>
Hi Sébastien,

At 2026-04-01T10:03:53+0200, Sébastien Hinderer wrote:
> Hey Branden, Thomas, all,
> 
> Many thanks for your reactivity.

A potent word in the discipline of nuclear engineering.  ;-)

> G. Branden Robinson (2026/04/01 02:33 -0500):
> > Okay.  As a rule of thumb it's a good idea to have some
> > understanding of code patches you submit.  Doing so facilitates
> > effective communications between developers from different projects
> > (and in general).
> 
> I certainly agree. It's just that I did what my current life
> circumstances permit, hoping that it would be enough for upstream to
> get the intention and do the rest.

Not always a vain hope.  My advice was a technique for reducing the
amount of friction that can afflict patches that seem to reveal a lack
of understanding of the system to be modified.

> Okay I can try to have a look. Just to clarify, though, are you
> talking in a general way, or do you want me to improve this specific
> patch and saying that updating the database will not be done unless I
> submit a better patch?

I'm not saying you have to improve the patch; the gist of it is clear.
And I definitely do not insist that you must provide actionable feedback
on the terminfo(5) man page before your patch will be considered.  That
would strike me as an unwarranted and unfair coupling--or contrived
pipelining--to me.  Any time you see a software developer doing such a
thing, you should make note of it and proceed cautiously--allocate your
resources of time and energy carefully.

(By contrast, it's often worthwhile and even considered a best practice
in software engineering to couple code changes with updates to
documentation and, ideally, to an automated test suite such that the
correct operation of the change is verifiable.  In another project, I
frequently find myself having to write documentation and automated tests
for code changes that other people contribute.)

Also, even were I inclined to erect such a hoop for you to jump through,
I'm not in a position to do so.  Thomas Dickey is the sole ncurses
maintainer and, as far as I know, the only person with commit privileges
to its development repository.  As I understand it, he uses RCS for
version control, which means that it's not a "distributed" VCS--the only
"official" repository resides on a machine under his control.

All changes I've made to ncurses have taken the form of patches proposed
to this mailing list, just as yours was, and are subject to his review.
While he accepts most of my contributions, I don't have a 100%
acceptance rate--that's not even a goal of mine.

I asked you to review the beginning of the terminfo(5) page so that you
could (1) increase your knowledge in an area that obviously concerns you
and (2) so that I, as a contributor to ncurses documentation, can get a
newcomer's perspective on the tractability of the material.  The two
best sorts of people to have working on documentation of a system are a
rank novice and a domain expert.  The expert knows how things "really
work" and the novice can question "obvious" assumptions that the expert
has internalized.  People who have mastered a system often know it so
deeply that they can fail to notice that their fundamental presumptions
have failed to make it into the written record.

Unfortunately I myself am somewhere between these extremes, and
therefore the least useful type of person to be contributing.  :-O

Regards,
Branden
signature.asc (application/pgp-signature, 833 B)