groff
[Top][All Lists]
Advanced

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

Re: synchronous and asynchronous grout (was: Novel use of .char)


From: G. Branden Robinson
Subject: Re: synchronous and asynchronous grout (was: Novel use of .char)
Date: Wed, 18 Dec 2024 12:12:01 -0600

Hi Deri,

At 2024-12-18T17:41:59+0000, Deri wrote:
> On Wednesday, 18 December 2024 01:07:45 GMT G. Branden Robinson wrote:
> > This is an extremely helpful presentation.  I have some questions.
> > 
> > 1.  Where was the foregoing distinction documented in, say, the
> >     groff 1.22.3 era?
> > 
> > 2.  How confident are you that these distinctions were consciously
> >     designed in, and to what _extent_ do you think that was the
> >     case?  Are they (or were they, back in groff 1.22.4 and earlier)
> >     consistent between .devicem and \Y as well?
> > 
> > 3.  I want to understand one of your applications better.
[...]
> Explication part 2.
> 
> Although the concept of in-band and side-band streams is a well known
> concept, 

From AM radio to microarchitectural timing channel attacks! 😈

[rearranging]
> I suspect its presence in groff is only due to the second feature of
> these escapes - that they copy 'anything' to grout (in copy mode)
>
> This feature is well documented,

Yes.  That bit of it is.

> and to achieve this groff avoids parsing the line into nodes, so it
> never gets added to the node list.  and given the way it was
> implemented, it resulted in the side-band channel.

Yes.  That bit of it was not, and I submit that it is startling behavior
with hard-to-predict consequences unless one thinks to look closely at
the grout GNU troff produces.

> The in-band channel is far more useful and if \!, .output, et al,
> produced a new kind of node which had a value of "anything" in copy
> mode, I would cheer, since synchronicity would be preserved.

I'm thrilled to hear you say that.  The tray of surgical instruments
gleams at me seductively.

> After your changes to \X it now provides curated content to grout,
> removing "nodes" from the string (except \ [uXXXX]), it would be nice
> to have an in-band "anything" escape.

Agreed.  I think it would be nice to close the side channel and come up
with a different way to encapsulate an uninterpreted character stream[1]
(that can be constructed on the fly, unlike with `cf` or `trf`) for
embedding in grout, and at a point in the stream that is (fairly) easily
predictable given any text, requests, or escape sequences in propinquity
to it.

Mmmm.  Good objective for 1.25.

Regards,
Branden

[1] You already know what's coming.  My hobnail boots and swagger stick
    say "you get code points 0x20 to 0x7E in your uninterpreted stream
    and nothing else".

Attachment: signature.asc
Description: PGP signature


reply via email to

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