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
