Re: [PATCH v2] [grotty]: Use terminfo.

[G. Branden Robinson]

At 2023-09-01T21:31:17+0000, Lennart Jablonka wrote:
> I will look at all that, though not right now.

No worries--no rush.

> I wanna tell you:  When manually testing, I found MR man page
> references followed by space to be followed by a backslash preceding
> the space and I found no OSC 8 emitted.   Or similar.

Yes, I'm having trouble observing any OSC 8 sequences getting to the
output at all with your patch.  I tried figuring out why, but failed.
the tty_printer::special_link() function is definitely being entered and
definitely processing the individual chars of the sequence, but those
are somehow not making it to the output.  Something got disconnected
somewhere.

One thing to know is that grotty builds an entire rectangular array of
character cells (a "page") at a time, and only writes that page out to
the standard output stream once it's time to eject the page.  This is
the reason it never has to do reverse line feeds as AT&T nroff did.

Possibly the invisible escape sequences that should be attached to some
cells are getting lost.

> I’ll debug that later.   While I know tty.cpp fairly well now, I have
> to admit the OSC 8 stuff, I haven’t looked at very much yet.

Naturally enough that's the sticking part.  The test failure
some_escapes_accept_newline_delimiters.sh was easily addressed by
passing "-P -c" in a couple more cases, which is reasonable enough.

So src/devices/grotty/tests/osc8_works.sh seems to be the only failing
case, and it is catching a real problem, from what I can see.

At 2023-09-01T22:03:54+0000, Lennart Jablonka wrote:
> Quoth G. Branden Robinson:
> > At 2023-08-21T21:40:18+0000, Lennart Jablonka wrote:
> > > This has nothing at all to do with making it easier to customize the
> > > look of man pages.
> > > 
> > > Hyperlinks are still marked up using OSC 8, hoping that whatever
> > > terminal sits in front of the user interprets or ignores those.
> > > Terminfo naturally doesn’t have a capability for hyperlinks.
> > > 
> > > Autoconf is not informed about the dependence on Curses; we simply link
> > > with -lcurses, as that is what X/Open Curses specifies.
> > 
> > I think I will want to stress here that only the terminfo bits are used.
> 
> Sure.   Though then, too, that per X/Open Curses, there is no library
> but -l curses.

Not a showstopper, but I'd like to see if there's an existing Autoconf
check for linking just "tinfo".  Thomas Dickey has a somewhat storied
history with (and of) Autoconf.

https://invisible-island.net/autoconf/

> or use cat pages

Apparently no one does that anymore.  :P

https://lists.gnu.org/archive/html/groff/2023-04/msg00046.html

> Ehh … so should I change it back to terminfo(5)?

Not at all!  terminfo(3) works and should be retained.  If we want to
refer to the capability list, terminfo(5) is the better resource.

> You are almost correct.   The OK and ERR constants are defined in
> <curses.h> only.

Oh, good grief.  What a layering violation!  (Take a drink.  Now I have
to go bro down with some functional reactive lambdas with lazy immutable
XML JSON WSDL SOAP XML-RPC buffers.[1])

More seriously, I'd rather:

1.  #include <term.h> and add "#ifndef"s for "OK" and "ERR"; and
2.  Send a patch to Thomas Dickey to make term.h itself do this.

For a foundational library to have to include a header from a
superimposed library just for the former to encode its functions'
success/failure states is just ghastly bad.  As concerned with
efficiency as they reputedly are, C programmers sure are wasteful
sometimes.  ("We cant be botherd 2 draw a dependency graph of our header
files so just #include everything everywhere and itll work lol".)

> > >   +  void change_color(const environment * const);
> > 
> > We might call this "change_stroke_color".  I tend to dislike
> > nomenclatures where an unmodified noun is coupled with a modified
> > one; it's harder to infer what the scope/meaning of the unmodified
> > noun is.
> 
> not in scope for this patch

True.

> > >   +// Both ovrestrike and update_attributes need be called for text
> oops, “ovrestrike”
> > >   +// attributes; only one of them will take effect.  Call overstrike for
> > >   +// every glyph.  The update_attributes function, too, can be called for
> > >   +// every glyph, as it's a noop for the same attributes.
> > 
> > I'll need to study the code more to make full sense of this comment.
> 
> Indeed;  reading it again, it’s worded badly.
> 
> Because overstriking happens for every single glyph, call overstrike
> for every glyph you want overstruck.
> 
> Because terminfo-set text attributes stay in effect until changed, you
> need not call update_attributes for every new glyph.   If it makes
> things simpler for you, the caller, you may do so, though:  If called
> with the same arguments as the last time, update_attributes does not
> print anything.

Okay.  Well, see what you can do with the comment for v3.  ;-)

> If I understand it correctly:  The parameters were pushed right to
> left.  If you gave tparm merely four arguments, only those four were
> pushed.

Oh, it's a macro (or was in the 1980s before generalized variadic
functions became a language feature).  And sure enough, that's what its
man page says.

> tparm would then only read those arguments it needed (as told by the
> capability string), not caring about whether more arguments to the
> right of those four were passed—they would be lower in the stack,
> after all.

One wonders how alloca() managed to not get standardized after all these
years.  Linux man-pages claims it appeared as far back as 32V.

Sure enough...

https://minnie.tuhs.org/cgi-bin/utree.pl?file=32V/usr/src/libc/sys/alloca.s

Answering one question answers the other, I reckon... ;-)

> In that way, tparm behaves as a variadic function in K&R C.   Now, it
> doesn’t.   We have a replacement, tiparm;  alas, my OpenBSD box
> doesn’t have that yet.
> 
>       char *tiparm(const char *, ...);
> 
> You haven’t seen it (outside ncurses docs, perhaps) because it was
> introduced in X/Open Curses Issue 7, which doesn’t seem to be
> available as “onlinepub.”

I guess OpenBSD uses NetBSD curses then--I'm not aware of OpenBSD having
its own implementation.  It's _really ugly_ to have to use tparm rather
than tiparm.  But that's not your problem.

To sum up, I don't see much remaining to tune in this patch except (1)
address the OSC 8 test failure and (2) clarifying a comment.  Everything
else I gripe about I can take on myself, or just add to my list of
grievances against the universe.

Thanks for staying on top of this!

Regards,
Branden

[1] 
https://medium.com/@uicynthia/lessons-from-very-bad-recruiting-emails-14d15bf46cd2

signature.asc
Description: PGP signature