Re: Novel use of .char

[G. Branden Robinson]

Hi Peter,

At 2024-12-17T13:58:15-0500, Peter Schaffter wrote:
> On Tue, Dec 17, 2024, G. Branden Robinson wrote:
> > I'm glad Peter raised; now that commit has to fold.  :)
> 
> I almost feel guilty for opening this can of worms. :) I was looking
> for an explanation for the behaviour, which I assumed was "correct",
> my (somewhat) novel mapping of image-to-glyph with .char being being
> to "blame."  Otherwise, I'd have posted a bug report.

It's a good thing to have raised.  Wrapping a diversion inside a
character definition is indeed a novel thing to do.  At first blush, I
admire the creativity.  At second blush, the prescriptivist and
black-gloved input validator in me recoils.  ("Why isn't this banned?"
he roars.)   My third reaction is as a system designer; we should allow
such feature composition unless we have a _good_ reason not to.

Orthogonality is a valuable property.

And without articulating how this stuff is supposed to work, without
having a basis upon which to construct our notions of what is "correct",
we won't have a good reason not to.

One thing that itches me a little about using a diversion this way is
that I've documented glyphs as being drawn upward and to the right from
the text baseline.  That's not happening here.  So either I've
documented the formatter wrong or you're exercising an underspecified
part of the system.  You string definition has to add motions to place
the glyph correctly.  So maybe when `char` or a similar request is
assembling its contents, it should check the node it's processing to
see if it is a diversion, and perform such adjustment itself.

(Normally, outputting a diversion draws it downward from the current
drawing position and leaves the drawing position at its bottom-left
corner.  When using a diversion as a glyph, we want to set it on the
text baseline, essentially drawing it upward, and leave the drawing
position at the diversion's bottom-RIGHT corner.)

That reminds me of another problem we have: we don't seem to have a
precise definition of how to measure a diversion's width and height.

https://savannah.gnu.org/bugs/?64728

> Interesting.  I, too, think chronologically about output.  This hit
> home when Branden said of .wh a while ago that the mnemonic was for
> "where" whereas I always think of it as "when."

Murray Hill's dedication to abbreviation strikes again.  :)

I didn't say so in the thread in question but Tadziu's coaching about
how to think about `ne` (and `sp`) has stuck with me.  By re-conceiving
these requests as requiring an output line to be (or making it) "taller"
by the specified amount (than it would otherwise be), some formatter
behavior seems easier to reason about.  I recently did some widow/orphan
work ("unstranding", as I put it), and applying that model satisfied me
in every case.

By hammering these things out I think we can make our documentation more
accessible and our users happier.  And I'd get frustrated less often.

Regards,
Branden

signature.asc
Description: PGP signature