Re: Terminal problem? man formatting problem?

[G. Branden Robinson]

Hi Oliver,

At 2023-04-23T12:23:06+0200, Oliver Corff wrote:
> I came across a minor case of misbehaviour when trying to open html
> links in man pages.
> 
> $ man 7 roff
> 
> has a section "SEE ALSO" with a number of links to Internet sites.
> 
> The first link under "History of Unix Manpages"
> ⟨http://manpages.bsd.lv/history.html⟩ is ready for opening in the
> browser once the mouse hovers over it but cannot be opened (404 file not
> found) because the closing parenthesis ")" erroneously makes its way
> into the link. See also the automated highlighting (on my terminal via
> underlining). The underlined region includes the closing parenthesis
> (but not the opening parenthesis).

I can't reproduce this problem with any combination of:

1. gnome-terminal;
2. the roff(7) man page in its groff 1.22.4 or Git HEAD revisions;
3. groff 1.22.4 or groff Git HEAD as the formatter.

This, to me, is pretty persuasive evidence that the problem here is a
bug in lxterminal.

> It seems to be that URLs ending in top-level domains are recognized
> correctly whereas URS with a page element (.../history.html in the
> first example) are not recognized correctly.

That seems likely, since to manufacture hyperlinks in the way that
people were accustomed to before the OSC 8 initiative, terminal
emulators had to pattern-match their inputs from the pseudoterminal
device, and that means maintaining a bunch of patterns.

> Is this an issue of the terminal (I use lxterminal 0.4.0) of of the
> formatting process chain?

I think so.

At 2023-04-24T03:49:05+0200, Oliver Corff wrote:
> that is an interesting problem indeed. First I thought the angle
> brackets (U+27E8, U+27E9) might be responsible, then I thought of
> trying a different terminal emulator.
> 
> Et voilà, strange things happen.
> 
> I cannot use xterm, uxterm and Eterm on my system because of the high
> screen resolution;

xterm/uxterm don't handle OSC 8 or contrive hyperlink support by pattern
matching anyway.  But if you want a readable size, you can configure the
X defaults for the XTerm and UXTerm classes to pick different defaults.

Or, much more simply, you can launch (u)xterm with an Xft (client-side)
font and a large type size.

You might try

uxterm -fa FreeMono -fs 36

I mention this even though it won't help you troubleshoot the hyperlink
problem because xterm is of excellent quality as a _terminal emulator_;
and sadly, GNU/Linux has over time grown a long list of terminal
emulators with flashy features like background pixmaps and alpha
blending that also fail pretty horribly at faithful emulation of
terminal behavior as soon as any ECMA-48 feature not used by the handful
of applications the emulator author personally runs is exercised.
I suppose that at one time, "writing your own terminal emulator" scored
a person a lot of cred in IRC channels populated wholly by what are now
termed "incels".  This was also true for window managers and digital
audio players and, to some extent, for XScreenSaver "screenhacks" and
"visualizers" for aforementioned audio players.  Many of these are now
deservedly forgotten.  The thing about a thousand flowers blooming is
that a certain substance must be spread over the soil first.

In summary, terminal emulation under GNU/Linux has a long history of
attracting the creative efforts of bad software developers.  I won't
name names, but I will observe that historically, before the development
of digital computers, such societal malefactors were paraded through the
streets of Seville in chains...

> those terminal windows appear as tiny stamps which do not accept the
> Ctrl-+ resizing command.

If you're using a reduced keyboard, that may be the problem.  The X11
keyboard model encodes the + and - keys on the alphabetic section of the
keyboard differently from the + and - keycaps on a numeric keypad.  And
the keypad plus and minus are what the XTerm resize events are bound to.
Your keyboard may be able to simulate a numeric keypad temporarily with
NumLock or Fn+Numlock or similar.

Or, you could use one of XTerm's pop-up menus to change fonts.  I use
Control+RightClick for this.  It pops up a "Unicode Fonts" menu.  You
may wish to experiment with the available menu items.  (These are also
documented in the very long xterm(1) man page.)

You can customize these aspects of XTerm on a permanent basis by
altering its "application defaults".  But I'll stop here for now.

My last experience with eterm was easily over 20 years ago, so I fear I
can offer no advice about it.

> So I tried gnome-terminal. In gnome-terminal, the same problem occurs,
> too, but its behaviour is exactly the reverse of lxterm. If in lxterm
> a URL is recognized correctly, in gnome-terminal the closing bracket
> is read as part of the URL. If in lxterm the closing bracket is
> erroneously taken as part of the URL, in gnome-terminal the URL
> correctly terminates *before* the closing bracket.
> 
> That also suggests an issue with the terminal emulator.

Yup.  This is one reason OSC 8 was such a good idea.

https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda

Regards,
Branden

[1] Technically, these are "actions" applied via "translations" to
    objects in a hierarchy[2] supported by the X Toolkit Intrinsics.
    And if you learn that then you already know more than most people
    ever did about the X Toolkit Intrinsics.  It did object-oriented
    programming in pure C, not C++, and while competently executed, it
    failed to convince anyone of C's merits as an OOP language.

[2] I almost said "widget hierarchy" but I think that is overly
    specific.  I can't think of any concrete examples, but I have a
    vague memory that you could use the Toolkit Intrinsics (Xt) to
    manage a _arbitrary_ object hierarchy.[3]  But far and away the main
    thing it was designed, and used, for was GUI management.

[3] Or at least one not coupled to X11 drawables.  I have no memory of
    whether Xt supported the construction of bespoke types.  Possibly I
    never learned this.

signature.asc
Description: PGP signature