Re: [bug #61025] [me] want control of line height alteration when super-, subscripting

[G. Branden Robinson]

Hi, Robert!

At 2022-01-02T11:22:21-0500, Robert Goulding wrote:
> Unless I'm doing something wrong, the change in spacing only seems to
> kick in with the *second *footnote - the first still adds the (to me)
> unsightly line gap.

You're right.  I incorrectly assumed that the use of footnotes in
doc/meref.me(.in) and the meintro* documents in the tree served as an
adequate test for this function but they don't, because of a somewhat
subtle problem.

Here is the present definition of the string that starts superscripting.

.ds { \v'-0.4m'\x'\\n(0x=0*-1u*\\n(sxu'\s-3

The above request is not in a macro; it is interpreted once, when the
macro package is loaded.

You can see that it interpolates the `0x` and `sx` registers, and that
those interpolations are guarded by an extra backslash, meaning that the
registers' values aren't interpolated at the time the string is defined,
but later, when the string itself is interpolated.  That's good--that's
what we want.  Otherwise setting `sx` at the top of a me(7) document
occurs too late to affect the string definition.

Unfortunately...`*` itself also has a default definition in the macro
file...which interpolates the string before the document is read.

.ds _* \\*{\\n($f\\*}\k*\"
.ds * \*(_*\"                   \" footnote mark

I introduced a new string `_*` recently, to make it convenient to reset
the `*` string in the `+c` macro (because one of that macro's jobs is to
reset the automatic footnote number, and the string will need to be
resynced--hmm, maybe I should check that).  Unfortunately, while I again
guarded the string and register interpolations with an extra layer of
backslashes, the very next line elicited the current value of the `sx`
register--the package's default.

That would mean I need yet another layer of escaping in the definition
of `{` itself, but then that would make the string unsuitable for more
general use.

So what I should probably do is go ahead and risk violating the DRY
principle, and return to initializing and resetting the `*` string more
verbosely.

All this rigmarole is why GNU troff has the \E escape sequence.
However, me(7) is still _mostly_ written in a Unix V7-compatible dialect
and is intended to work in AT&T compatibility mode.  There isn't a good
substitute for \E if you have to interpolate a string or register at
varying nesting depths.  However, I don't think that problem is the case
here.

I'll reopen the ticket.  Maybe the third time will be the charm.  :)

Thanks for your patience with this surprisingly thorny issue.

Regards,
Branden

signature.asc
Description: PGP signature