[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
signature.asc
Description: PGP signature
- What, exactly, _is_ "line-breakout optimization"?, G. Branden Robinson, 2024/05/19
- Re: What, exactly, _is_ "line-breakout optimization"?, G. Branden Robinson, 2024/05/19
- Re: What, exactly, _is_ "line-breakout optimization"?, Thomas Dickey, 2024/05/19
- Re: What, exactly, _is_ "line-breakout optimization"?, Bill Gray, 2024/05/19
- Re: What, exactly, _is_ "line-breakout optimization"?, G. Branden Robinson, 2024/05/19
- Re: What, exactly, _is_ "line-breakout optimization"?, Bill Gray, 2024/05/19
- Re: What, exactly, _is_ "line-breakout optimization"?, G. Branden Robinson, 2024/05/25
- Re: What, exactly, _is_ "line-breakout optimization"?, G. Branden Robinson, 2024/05/19
- Re: What, exactly, _is_ "line-breakout optimization"?,
Thomas Dickey <=
Re: What, exactly, _is_ "line-breakout optimization"?, Benno Schulenberg, 2024/05/19