bug-groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #61886] [grotty] want anchor support to complement OSC 8 hyperlinks


From: G. Branden Robinson
Subject: [bug #61886] [grotty] want anchor support to complement OSC 8 hyperlinks
Date: Thu, 20 Jan 2022 22:11:18 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

Update of bug #61886 (project groff):

                Severity:              3 - Normal => 1 - Wish               
                  Status:                    None => Postponed              
                 Summary: grotty: OSC-8 support does not offer IDs aka id=,
only link => [grotty] want anchor support to complement OSC 8 hyperlinks

    _______________________________________________________

Follow-up Comment #2:

Hi, Steffen.

[comment #0 original submission:]
> Wonderful. But really it is not nice that you did not support the
possibility to generate id= anchors.  Or did i miss something.

No, that's not present yet.  There was some discussion about it
<https://lists.gnu.org/archive/html/groff/2021-08/msg00000.html>, but we
didn't settle on a design].

For other output devices, the `devtags` auxiliary macro package already takes
care of this, and there is already some integration with user-facing macro
packages like `man` and `ms` (though a quick glance at ms.ms rendered as HTML
reveals that the `ms` support is buggy, sigh).

> It would be tremendous if that could be added, so that one could create
macros which generate in-document anchors and thus in-document references! 
Aka warp such to the TTY device, too.

I think the main problem here is that there is no proposed standard for
_declaring_ these anchors in the byte stream sent to the terminal.  I reckon
another OSC escape sequence, a counterpart to OSC 8, is required.

I'm marking this as "wish, postponed" because we can't implement this before
there's a way to elicit such functionality from terminal emulators (or pager
programs, which I suppose could supply it by maintaining a list of pointers
into their rendering buffer, if an implementor were ambitious enough).  (Come
to think of it, any pager that can search its buffer for text probably has
most of the machinery it needs already.)

> (I am back at github and maybe i can get an acceptable path to add this to
less.  I am steffen AT, you know.)

Cool!  Good to hear from you again.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?61886>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]