bug-ncurses
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: What, exactly, _is_ "line-breakout optimization"?


From: Thomas Dickey
Subject: Re: What, exactly, _is_ "line-breakout optimization"?
Date: Sun, 19 May 2024 18:23:10 -0400

On Sun, May 19, 2024 at 03:55:04PM -0500, G. Branden Robinson wrote:
> Hi Thomas,
> 
> At 2024-05-19T15:19:32-0400, Thomas Dickey wrote:
> > > But this doesn't explain why the term is used in the man page.
> > 
> > It's in the oldest checkin of curs_inopts.3x (December 1994).
> 
> I looked at the tag 'v1_8_7' in the ncurses-snapshots Git repo because
> it _looked_ the oldest on cursory inspection.
> 
> > I see it earlier in ncurses 1.8.5 (February 1994).
> > The "CHANGES" file in 1.8.5 says (for ncurses 1.8.3)
> > 
> >     3) Eric S. Raymond has supplied a complete set of man pages for
> >     ncurses in ?roff format. They will eventually replace most of
> >     the current docs. Both sets are included in this release.
> 
> I have complained before about the characterization (by others, not you)
> of this import and its authorship, and I expect I will do so again,
> if/when I get around to revising the man pages for the form and menu
> libraries.
> 
> > Rewriting it wouldn't hurt.
> > 
> > (If either Eric or Zeyd had an rcs or cvs archive of this stuff,
> > to give a better picture, that would have been mentioned long ago -
> > all I have before 1996 is a collection of tarballs and some patches).
> 
> I guess we don't have a copy of the first ncurses release, 1.8.1.  It

1.8.1 is here

https://invisible-island.net/archives/ncurses/archive/

but it wasn't the first release.  That jump from 0.7 to 1.8.1 is odd.

I didn't have a copy of 1.8.1 when I started my ncurses archive in 1996.
I did that using (from memory) about 18 tarballs.

Looks like I started with 1.8.7, and had several in-between steps.
Later, I found the other earlier tarballs (and 30 years ago,
it's possible that I could have found more which are no longer available).

> would be instructive to compare that to Pavel Curtis's final pcurses
> release, assuming _that_ is available.  I'm curious to see the delta
> upon which Zeyd predicated so much authorial priority.

I have a copy of pcurses there too - but in between pcurses/ncurses,
there's pccurses which became the basis for pdcurses.  (I have tarballs...)
 
> > > a description of the optimization technique itself, the use of a
> > > shorthand term that might make sense to developers is useless--or
> > > worse--to the user of the API.
> > > 
> > > X/Open Curses is much more general in its description, and
> > > consequently clearer.
> > 
> > As far as I know, documentation for X/Open Curses wasn't available in
> > 1994.  (Some drafts were ftp-able in 1995).
> 
> That doesn't surprise me.  TOG was pretty slow to let go of the idea of
> extracting revenue, even to the detriment of their own influence as
> promulgators of a standard.  Rentiers gonna seek rent.
> 
> > yes - some of that's amusing (actually I looked up the Heckel paper a
> > long time ago, and didn't see the resemblance versus the algorithm -
> > chalked it up to hyperbole).
> 
> From that source?  Perish the thought.
> 
> Here's my revision of the function description, in draft.  Of course
> font styling helps, but it's lacking in email.
> 
> Before:
> 
>    typeahead
>      curses does “line‐breakout optimization” by looking for typeahead
>      periodically while updating the screen.  If input is found, and it
>      is coming from a terminal, the current update is postponed until
>      refresh(3NCURSES) or doupdate is called again.  This allows faster
>      response to commands typed in advance.  Normally, the input FILE
>      pointer passed to newterm, or stdin in the case that initscr was
>      used, will be used to do this typeahead checking.  The typeahead
>      routine specifies that the file descriptor fd is to be used to
>      check for typeahead instead.  If fd is -1, then no typeahead
>      checking is done.
> 
> After:
> 
>    typeahead
>      Normally, a curses library checks the terminal for input while
>      updating the screen.  If any is found, the update is postponed
>      until the next wrefresh(3NCURSES) or doupdate(3NCURSES) call,
>      allowing faster response to user key strokes.  The library tests
>      the file descriptor corresponding to the FILE stream pointer passed
>      to newterm(3NCURSES) (or stdin if initscr(3NCURSES) was called),
>      for pending input.  typeahead instructs curses to test file
>      descriptor fd instead.  An fd of -1 disables the check.

curses also has a fifo, and that can have data pending for input
 
> Here's wc(1):
>   10   98  658 /tmp/branden/typeahead1
>    8   74  553 /tmp/branden/typeahead2
> 
> That's about a 15% reduction in letters to read (~23% in words), and
> even that understates the improvement IMO (darn that fat "3NCURSES"
> suffix blowing it back out, but hyperlinkable cross references seemed
> valuable here).
> 
> People have occasionally griped to me about my lengthy emails, but when
> updating documentation I do strive for economy of expression.
> 
> Regards,
> Branden



-- 
Thomas E. Dickey <dickey@invisible-island.net>
https://invisible-island.net

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]