Follow-up Comment #3, bug #67817 (group groff):
[comment #2 comment #2:]
> [comment #1 comment #1:]
>> I agree with you that "troff -a" is now communicating less
>> information. My point is that, given the way "-a" is implemented
>> (as a set of member functions of node classes that "print
>> themselves approximately" as opposed to "tprinting" themselves
>> (in device-independent format) or "dumping" themselves to the
>> standard error stream, a new feature), I feel it makes more
>> sense for "-a" output to align itself closely with what gets
>> written as device-independent output than to capture details
>> of input that have, at the time output is written, are discarded.
>
> This is a long-winded way of saying that reverting this behavior would be a
> layering violation.
Long-winded it may be, but I hold a permanent grudge against the phrases
"leaky abstraction" and "layering violation", because I have so often seen
them deployed by developers attempting to suggest a greater level of
expertise, or greater mastery of the subject under discussion, than they
possess.
So if something constitutes a "layering violation", I expect to hear what
those layers are and what the specified interface between them is. Put
differently, I need to know the limits of the interfaces' coupling.
> I see no point in telling users "you need to do more work to get the same
> info -a used to give you, just so groff can maintain conceptual purity." But
> as you say, this is a question better raised on the list. I'll start a
> thread.
>
>> more helpfully gets across the fact of its existence than
>> simply omitting it does.
>
> This is a straw man argument: no one is advocating for simple omission.
No, but they *could*, and reasonably so. The _troff_(1) man page and our
Texinfo manual already enumerate several other things `-a` output doesn't
attempt to represent. Device extension commands (really, _any_ device
command, not limited to extensions) and drawing commands are further
examples.
> The question is _how_ to represent it: with a string indistinguishable from
> all other special characters, or with one unique to each character.
Should we be unique over the naming scheme of *roff special characters or
unique over their output representations? Remember that multiple special
characters can have the same definition.
>> Yes, the formatter does "know" the "name" of the special
>> character, "S trademarksans", but this is an internal
>> representation form only--you'll note that this is not a valid
>> identifier, and should not be exposed to external consumers.
>
> This is unconvincing. -a output, being "approximate," has never made
> guarantees that what appears between angle brackets is a valid identifier.
That's true; our docs are at pains to communicate that its output makes no
guarantees at all.
> That name is an obvious combination of two things the document author (the
> one most likely to be using -a) does know: the font name and the character
> name as defined by the document.
But the character name as defined by the document is not what the output
driver uses to produce the glyph. I don't know what applications you've had
for "groff -a" to date, but another user could, with every bit as much
justice, assert that they don't care which of several *roff input aliases were
used to select a glyph--they want to know what ends up being demanded of the
output device.
It would be fair to observe that the angle-bracketed-special-character-name
syntax is insufficiently expressive for that.
> And in the case where someone unfamiliar with a document source uses -a on
> it, arguing that "<S trademarksans>" is not meaningful to that person glosses
> over the fact that "<--->" certainly isn't either.
Like I said, "-a" output cannot express everything and for several kinds of
formatting object or command, it makes no attempt. Font style and type size
changes are further examples, and are not esoteric.
>> [quoting the Texinfo manual:]
>> The above description should not be considered a
>> specification; the details of -a output are subject to
>> change.
>
> I don't take issue with that precept. I take issue that the change in
> question results in less informative output without any measurable trade-off.
> (I presume that if the change made the code more maintainable, for instance,
> you'd have mentioned this, but I'm open to correction.)
I'd have to go back and look to see if that was the case. But I think my
decision is defensible on the merits I've offered given the manner of its
implementation ("printing" member functions of node types).
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?67817>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
