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

[G. Branden Robinson]

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

[comment #2 comment #2:]
> [comment #1 comment #1:]
> > I think it would be straightforward to extend `sz` to accept an
> > optional second argument setting the vertical spacing.  The macro
> > can check its own context for whether it should set $v or $V.
> 
> I like the thinking outside the box!
> 
> Unfortunately, this proposal isn't congruent with the way -me operates
> regarding other type-size-related matters.

Yes, but I also don't think me(7) is historically congruent with
_itself_ when it comes to type size versus vertical spacing.

> In general, -me relies on the user to set registers (pp, sp, fp, et
> al.) to make persistent changes to the type size.

Yes, and registers `fv`, `pv`, `qv`, `sv`, tv` are not implemented to
manage the vertical spacing of the various contextual type faces.

Should they be?  Happily, all five names are available.

This would make me(7)'s design more orthogonal, the cost of five
registers that will seldom be used (because having the vertical spacing
be proportional to the type size is frequently what is desired), and for
the sake of backward compatibility we'll have to retain `sz` own
non-orthogonality which will stand out all the more.

> The .sz macro is specifically documented as _not_ persistent: -me
> frequently automatically resets the type size to the values stored in
> the appropriate register -- and, at the same time, the line spacing to
> that stored in $v -- clobbering whatever was set by the last call to
> .sz.  (The .sz section of the reference manual lists typical
> situations where this happens.)  Making one of its parameters
> persistent and the other not would be an odd design.

Yes, but as noted above, people more often want to fiddle the type size
and vertical spacing together than the alternative.

> So exposing $v and $V to the user as registers, rather than as macro
> parameters, is in line with the way all these others are handled.
> It's only their names that aren't.

If my proposed change to the `sz` macro doesn't suit, and five new
registers also don't (I'm not all that crazy about it, especially not
about figuring out what sorts of conditionals I would have to write into
a new `sz` to manage the interactions of them with `$[rRvR]`), then what
can be done?  Maybe `$v` and `$V` should be unexposed, and left to
"expert mode" like your `wh` requests that you must handle like
nitroglycerin?  ;-)

These two registers can be renamed into the correct part of the name
space, but I'm not precisely sure what to call them.  Any suggestions?


    _______________________________________________________

Reply to this item at:

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

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