[bug #61710] [me] $v and $V are in the wrong namespace

[G. Branden Robinson]

Follow-up Comment #6, bug #61710 (project groff):

[comment #5 comment #5:]
> Yeah, there's a delicate balancing act between implementing a
> good design and preserving historical functionality and
> design, the latter two sometimes being at odds with each
> other, as you note.
> 
> On the one hand, I would hate to see $v and $V -- which,
> despite their misnamings, have been long documented in groff
> -- stop working as they always have.  I would suggest that any
> replacement mechanism work on top of those two registers, so
> that pre-2022 -me documents can continue to exist in blissful
> ignorance of this newer mechanism and fiddle with $v and $V as
> they always have.

That feels rather tedious to implement.  :(  Granted, that isn't
the most honorable motivation for not wanting to deal with the
problem.  But it is true that there is _already_ undocumented
support for BSD me(7)'s (documented) '$r' and '$R' registers.
This support has been in place for many years.

> On the other hand, a case could be made that by the time groff
> came along, -me use was already fading well behind its more
> popular cousins, and thus, for -me, compatibility with
> pre-groff implementations is far more important than
> post-groff ones.  But I have no data to support or refute this
> conjecture.  (Back compatibility on this, or lack thereof,
> doesn't concern me personally: I follow -me changes pretty
> closely and can easily adapt to any changes made here.)

Yes, it seems even harder to gather any empirical evidence of
relative popularity.

> But I sort of feel this is an important question to answer
> first, because deciding to preserve historical $v/$V behavior
> may influence what can feasibly be built on top of it.  How
> important do you think it is to preserve the functionality of
> existing documents that set $v and/or $V?

That depends on how many there are.  But corpora of .me
documents apart from Eric Allman's own, distributed with the
package, seem to be hard to find.

I propose that we ditch $v/$V for 1.23.0-rc2, and for that
release candidate, actually put out some release notes this
time.  Feedback on rc1 was almost nonexistent, and that was
dispiriting.  But we didn't give reasons why people might want
to play with it.

If an angry mob of me(7) document authors appears demanding that
`$v` and `$V` be put back, then we can go from there.

In the meantime, I reckon it's easy enough to implement `fv`,
`pv`, `qv`, `sv`, and `tv` registers as counterparts for the
type size registers.

That leaves the original question of `sz` behavior.

I propose:
1. `sz` with no argument or with a ±p argument is handed as
   before.  This means the same 120% alteration to vertical
   spacing, except that this value will no longer be retrieved
   from a documented register.
2. `sz` will accept a numeric second argument, a vertical
   spacing size in points (or increment thereto).  If someone
   wants to simulate the ms(7) `LG` or `SM` macros (see ms.ms),
   they can specify '+0' as this argument.
3. As seen in my earlier straw-man patch, me(7) calls `sz`
   internally.  That will probably need to change to support the
   five new vertical spacing registers noted above.  I would
   probably make a new internal macro to manage this stuff.

Setting `sv` and `pv` to different values and then omitting a
paragraph macro call immediately after `.sh` will likely have
ugly results.  But that could be done with `sz`, too, so maybe
that's not a real drawback.

What do you think?


    _______________________________________________________

Reply to this item at:

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

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