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