Re: OSC8 hyperlink support in ncurses
On Wed, Aug 23, 2023 at 03:21:43AM -0500, G. Branden Robinson wrote: > Hi Thomas, > > At 2023-08-23T03:24:51-0400, Thomas Dickey wrote: > > On Tue, Aug 22, 2023 at 01:12:04PM -0400, Dusty Mabe wrote: > > > I'm wondering if anyone has ever requested OSC8 hyperlink support > > > [1] in ncurses > > > > This is probably the first mention on this list. > > > > I don't see any use in my working on this, because: > > > > a) it opens up a new set of security vulnerabilities > > There was a humdinger of an argument about this on Egmont Koblinger's > Gist about this feature. > > https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda sure - he's glib (odd, that I just noticed that pun). But this is the developer responsible for the feature that caused gnome-terminal to run out of memory while I ran an ncurses test-program. See the end of this section: https://invisible-island.net/ncurses/ncurses-slang.html#compare_picsmap (coincidentally, he fixed _that_ bug two weeks after I wrote that section) > I offer that link mainly for the edification of bystanders; I trust > you've already read and considered that material. yes, I've had a few years to consider it. Now that it's becoming more prevalent, others are thinking about it as well. It would be nice to have the full presentation for this: https://www.theregister.com/2023/08/09/ansi_escape_sequence_risks/ > >(which if you read this list, and investigate, you'll notice that I > >do _all_ of the work to mitigate those issues). > > Fair. > > > b) doing this as you might expect will interfere with performance for > >_all_ applications. > > Maybe some clever volunteer can think of an unexpected implementation > that doesn't. sure - someone with a lot of time :-) > > The developer working on tmux is working through the latter, and > > ignoring the former. Perhaps in a few years, after both aspects are > > resolved, he might want to adapt some of that to ncurses. > > In the meantime it would be helpful if you could add a terminfo > capability so that applications using terminfo but not curses per se can > pay their money and take their chances, as with groff's grotty(1), for > which Lennart Jablonka is preparing patches to make the program a > terminfo application (at long last, one might say). Nicolas has a feature for this which his users can configure :-) > We'd like to be able to ask terminfo if the terminal description > supports OSC 8, but we can't. Actually, that's mostly due to Egmont's interference, as you're probably aware. > Meanwhile, my crystal ball says I'll be using gnome-terminal to check > grotty's OSC 8 support for the foreseeable future--but only on occasion, > as xterm is my daily driver and I have no plans to change that. > > Regards, > Branden -- Thomas E. Dickey https://invisible-island.net signature.asc Description: PGP signature
Re: OSC8 hyperlink support in ncurses
On Fri, Aug 25, 2023 at 03:25:10AM -0500, G. Branden Robinson wrote: > Hi Thomas, > > At 2023-08-23T15:25:24-0400, Thomas Dickey wrote: > > On Wed, Aug 23, 2023 at 03:21:43AM -0500, G. Branden Robinson wrote: > > > There was a humdinger of an argument about this on Egmont Koblinger's > > > Gist about this feature. > > > > > > https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda > [...] > > But this is the developer responsible for the feature that caused > > gnome-terminal to run out of memory while I ran an ncurses > > test-program. > > > > See the end of this section: > > > > https://invisible-island.net/ncurses/ncurses-slang.html#compare_picsmap > > Ah, ha. Yes, you've had that story up for a long time--I remember > reading it, but having no idea of the principals behind > the...entertainment. > > > (coincidentally, he fixed _that_ bug two weeks after I wrote that > > section) > > We take bug reports as we find them. :P In this case, it was coincidence. Though my page was being reviewed, and it was visible on the Internet, it wasn't advertised -- it was one of several things that I did in developing ncurses 6.1: making test-programs for extended colors, validating them on various terminals, etc. Actually I'd noticed the problem in August, and with one distraction and another documented the problem in my page on November 3, for the "dots" program. I noticed the (coincidental report) in my routine snapshot of https://gist.github.com/XVilka/8346728 I have a few hundred Git clones, and pull those about once a week, but the gist for this wouldn't come via wget (and wasn't in Git). So I snapshotted the page from Firefox and kept my own Git repo for it, until its owner trashed it. (The suggested replacement site has similar problems, as you might have noticed). As I recall it, when I began this one, the Internet Archive had trouble with it too, but see in responding that it has a few snapshots (not as many as I). So I can offer you a URL: https://web.archive.org/web/20171119155902/https://gist.github.com/XVilka/8346728 which contains this comment: Up to today VTE contained a significant memory leak if the colon form was used (https://github.com/neovim/neovim/issues/7573";>1, https://bugzilla.gnome.org/show_bug.cgi?id=790539"; rel="nofollow">2, https://git.gnome.org/browse/vte/commit/?id=dda73cc"; rel="nofollow">3). Embarrassing. Searching on bugzilla.gnome.org no longer works, but at the moment I am (still) able to visit its URLs, and match that up with the Git: commit dda73cc07250ea324b4227907197c39b93fcd365 Author: Christian Persch Date: Sat Nov 18 18:40:03 2017 +0100 matcher: Fix memory leak Don't leak the GValueArray. https://bugzilla.gnome.org/show_bug.cgi?id=790539 Seeing the comment about GValueArray, I recalled reading a discussion between Egmont and Christian which said that one had noticed a memory leak, but that it wasn't something that they need not fix at that time. At that time, I took a look for it, but didn't find that. Since searches are no longer working, it would be a lot harder (for me) to get that information. The neovim report explains the problem, which lets us find the change which produced it: commit b8a021330c0375ef6411f9abf2e4f717d0a5fb1d Author: Egmont Koblinger Date: Mon Jan 13 17:29:26 2014 +0100 Allow ":" as subparameter delimiter in SGR color sequences. https://bugzilla.gnome.org/show_bug.cgi?id=685759 So that was in the code for more than three and a half years. OSC8 is more complicated to implement, will rely upon being developed by _several_ developers, etc. (I take it for granted that my audience knows how to use the hash to find the relevant commits). > > > I offer that link mainly for the edification of bystanders; I trust > > > you've already read and considered that material. > > > > yes, I've had a few years to consider it. Now that it's becoming more > > prevalent, others are thinking about it as well. It would be nice to > > have the full presentation for this: > > > > https://www.theregister.com/2023/08/09/ansi_escape_sequence_risks/ > > Yes. This is the sort of thing Ingo was alluding to. I went off on my > own rant about it on the groff list. > > https://lists.gnu.org/archive/html/groff/2023-08/msg00106.html I like mailing list archives because they're likely to have related mails from people which I didn't collect, though (in a recent work) I've noticed that they're not always complete, omitting some message that I'
Re: OSC8 hyperlink support in ncurses
On Sat, Sep 02, 2023 at 04:16:53PM -0400, Thomas Dickey wrote: ... > Seeing the comment about GValueArray, I recalled reading a discussion between > Egmont and Christian which said that one had noticed a memory leak, but that > it wasn't something that they need not fix at that time. At that time, was > I took a look for it, but didn't find that. Since searches are no longer > working, it would be a lot harder (for me) to get that information. fwiw, I still have the files which I collected in a crawl of the bugzilla. > > That goes for plagiarists, too. I appreciate your pages documenting > > your encounters with them. > > :-) looking forward to further discussion -- Thomas E. Dickey https://invisible-island.net signature.asc Description: PGP signature
Re: why page-local macro definitions come after `TH` call in man(7)
On Tue, Mar 05, 2024 at 03:48:24PM -0600, G. Branden Robinson wrote: > Hi Thomas, > > I saw the following recent commit to the X11 Athena widget set.[1] > > commit 080e6e49825c2e03adb0c5dd8dad53767ec41ce6 > Author: Thomas E. Dickey > AuthorDate: Thu Feb 29 18:12:40 2024 -0500 > Commit: Thomas E. Dickey > CommitDate: Sat Mar 2 16:40:07 2024 + > > manpage: assume .EX/.EE macros > > Branden Robinson says macros have to go after ".TH"; the existing macros > did > not match the format used in groff, etc., and can be simply removed. The > ".TQ" macro is used only without a parameter, causing an extra space to be > emitted (and fixed that by dropping the parameter). > > Signed-off-by: Thomas E. Dickey > > Being cited as an authority stimulated in me not just a desire to pull a > James "Kibo" Parry impression but also to further clarify this topic in > the groff_man(7) document. > > The reason for this placement is the widespread usage of the "mandoc" > wrapper, which isn't a mere GNUism as one might suspect, but dates all > the way back to 4.3BSD-Reno (1990). iirc, that's what you reported on bug-ncurses, but adding the url in the commit-message seemed a lot more work than just citing who reported the detail that I had in mind. if my script had warned about that, I may have been more terse :-) (at the moment, my script doesn't flag that detail for warnings, but does tell me if the macro is defined differently - and on moving the macros past .TH, the result was not so good) anyway, I was in libXaw to repair the issue reported here: https://github.com/TeX-Live/texlive-source/pull/64 (better late than never, and with the push to "Modern C", I expect that change will be generally-available sooner than later) -- Thomas E. Dickey https://invisible-island.net signature.asc Description: PGP signature
