bug-groff
[Top][All Lists]
Advanced

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

[bug #66187] [troff] permit control over flushing of output file state


From: G. Branden Robinson
Subject: [bug #66187] [troff] permit control over flushing of output file state
Date: Sun, 8 Sep 2024 21:30:59 -0400 (EDT)

Follow-up Comment #3, bug #66187 (group groff):

At 2024-09-08T20:45:53-0400, Deri James wrote:
> Follow-up Comment #2, bug #66187 (group groff):
> 
> You may remember a detailed breakdown I gave you, a few years ago, on
> the differences between .device and .output (\!).

Only vaguely.  :(  That would have been a good thing to get into the
manual.  I don't think I understood it well enough at the time to
explain it in my own words.  Even now I feel myself at the ragged edge
of my comprehension.  Only once I can get the formatter to dance to
whatever tune I call with no surprises do I achieve a sense of mastery.

> The main difference
> is shown by this:-
> 
> Here is some text
> .device Mark here
> Marked
> .device To here
> .output Where does this go?
> Ending with this.
> 
> Run with -Z and notice that .device follows the text flow, so I can
> bracket the word Marked" with device controls, whereas .output does
> what it says on the tin (Emit string directly to the gtroff
> intermediate output (subject to copy mode interpretation)).

Right.  I mean to preserve that property of `.output` and `\!`.

> Any text being built up on the current line is not flushed so the
> .output string appears before partial line is flushed.

Well, so far the changes in my working copy have
"device_extension_node"s (renamed from "special_node"s) _no longer_
unconditionally calling `do_motion()` when they get "tprint"ed.

I took your example and ran it through groff -T utf8 -Z with 1.23.0 and
my working copy.


$ cat /tmp/branden/deri-device.groff
Here is some text
.device Mark here
Marked
.device To here
.output Where does this go?
Ending with this.
$ diff -u deri-device-*
--- deri-device-1.23.0.grout    2024-09-08 19:59:18.705999501 -0500
+++ deri-device-GBR-wc.grout    2024-09-08 19:59:33.437928813 -0500
@@ -18,14 +18,14 @@
 wh24
 ttext
 wh24
+x X Mark here
 V40
 H432
-x X Mark here
 tMarked
 wh24
+x X To here
 V40
 H600
-x X To here
 tEnding
 wh24
 twith


The placement of the output commands generated by `device` shift
relative to some absolute positioning commands.  Does this make a
difference in actual output?


$ ~/groff-stable/bin/groff -T utf8 /tmp/branden/deri-device.groff >
deri-device-1.23.0.out
grotty:<standard input>:5: warning: unrecognized command 'W'
grotty:<standard input>:24: error: X command without 'tty:' tag ignored
grotty:<standard input>:29: error: X command without 'tty:' tag ignored
$ tgu /tmp/branden/deri-device.groff > deri-device-GBR-wc.out
grotty:<standard input>:5: warning: unrecognized command 'W'
grotty:<standard input>:22: error: X command with 'Mark' tag ignored; expected
'tty'
grotty:<standard input>:27: error: X command with 'To' tag ignored; expected
'tty'
$ cmp deri-device-*.out && echo SAME
SAME


Does this offer any reassurance?  Could we use an example (that we can
then turn into an automated test) that will illustrate how my change is
breaking something?

> This is why the markstart/markend instructions use .device. Both
> methods are useful in different situations, but with suitable control
> of the various flushing methods it should be possible to retain the
> current behaviour just using .device.

That's my hope.  I'm not trying to _reduce_ the author's control of the
page contents.

> I do have a slight worry in that I know to you this is incorrect
> behaviour,

I don't see anything wrong with the exhibit above as rendered by 1.23.0
or my working copy.  A pair of absolute motion commands (that I consider
somewhat noisy, but not incorrect) shifts in location, but not in a way
that alters rendering.  Rendering is what decides correctness to me.

> but to everyone else who has relied on this behaviour, it is a feature
> change.

I need to see some behavior changing in order to agree with you.

If I see that, then I agree, I've gotta raise the flag in the NEWS file.
Or abandon the change.

I was specifically concerned that killing the `do_motion()` calls would
screw up OSC 8 bookmark boundaries, but that didn't happen.  The change
I needed to make to expectations in tmac/tests/an_MR-works.sh was
minimal (3 output commands moved by 2 lines), and firing up
gnome-terminal revealed hyperlinked man page references cruising along
just like before.  No boundary changes.

> We can easily change our macros to avoid a regression, but we have
> given no warning of this big change in behaviour,

I wonder what tool you use to measure "big"--I get the feeling the
number of people who write output drivers for groff is extremely small.
Even the number who write macros that produce device extension commands
is not much larger.

Get used to the idea that you're in an elite class.

> so people may find their macros are no longer working the same.

I agree that behavior changes should be documented!  But judging by the
reception to 1.23.0, there is a paucity of people outside the _groff_
mailing list itself who will notice _anything_ that doesn't affect the
rendering of a man page in Teletype Model 37-compatible form.

That is not a situation I celebrate.

Regards,
Branden



    _______________________________________________________

Reply to this item at:

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

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

Attachment: signature.asc
Description: PGP signature


reply via email to

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