bugGNU roff - Bugs: bug #61710, [me] $v and $V are in the wrong...

 
 

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

Submitter:  Dave <barx>
Submitted:  Tue 21 Dec 2021 01:13:58 AM UTC
   
 
Category:  Macro me Severity:  2 - Minor
Item Group:  Feature change Status:  Fixed
Privacy:  Public Assigned to:  gbranden
Open/Closed:  Closed Planned Release:  1.23.0
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Mon 24 Apr 2023 02:57:58 AM UTC, comment #23: 

comment #22:

> too late to fix in the git log, but is still changeable in ChangeLog


Fixed in commit b90e54ac.

Dave <barx>
Group Member
Sat 26 Feb 2022 10:04:54 PM UTC, comment #22: 

comment #21:

>       James Clark in 1992) attempting to illuminate the confusing history
>       (and naming) of `$[rRvR]`.


This seemingly should have said `$[rRvV]`, which is too late to fix in the git log, but is still changeable in ChangeLog (unless unsyncing the two is taboo).

Dave <barx>
Group Member
Mon 14 Feb 2022 06:52:16 AM UTC, comment #21: 


commit 47600ca4849ae504bb8fb9ae591de551dd1ee357
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Sat Feb 12 08:48:44 2022 +1100

    [me]: Rename registers `$v` -> `tv`, `$V` -> `dv`.

    * tmac/e.tmac: Do it.  Also include much commentary (including some from
      James Clark in 1992) attempting to illuminate the confusing history
      (and naming) of `$[rRvR]`.

    * doc/meref.me.in: Document it.  Introduce new terms "text vertical
      spacing" and "display vertical spacing" earlier and use them to
      condense and clarify discussions of their use.

    * NEWS: Add item.

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


G. Branden Robinson <gbranden>
Group administrator
Fri 11 Feb 2022 09:35:53 PM UTC, comment #20: 

comment #19:

> comment #18:
> > -me handles all other type-sizing matters by having the user
> > set registers, so it's incongruous to do something different
> > for line spacing.
>
> ...with the exception of the `sz` macro, yes.


Right, but .sz sets no registers; it's explicitly temporary and will be overridden with the next paragraph or similar macro.

> I prefer the second, so I'll go ahead with that.


Sounds good to me.  Thanks for all the discussion.

Dave <barx>
Group Member
Fri 11 Feb 2022 08:59:14 PM UTC, comment #19: 

Hi, Dave!

comment #18:

> > Any thoughts on comment #16?
>
> Still pondering, in between falling down Roman numeral rabbit
> holes.  My knee-jerk reaction is that of comment #2: -me
> handles all other type-sizing matters by having the user set
> registers, so it's incongruous to do something different for
> line spacing.


...with the exception of the `sz` macro, yes.  And that can be
somewhat hand-waved if we view that as a generalization of
ms(7)'s `LG`, `SM`, and `SZ`, as noted earlier.

> Still, even if this is done with a request, .vs wouldn't be my
> first choice, as then it will do distinctly different things
> in -me documents than in plain roff, which seems needlessly
> confusing when -me could simply invent a new name for this
> macro.


Fair point.

> Redefining .vs might also break some historical -me documents
> that call .vs directly.  True, the -me manual never condoned
> the use of troff's .vs request, so strictly conformant -me
> documents shouldn't use it, but in reality it was safe in
> limited contexts, such as working around bug #60553.  (The
> workaround I posted in that bug report goes to some effort to
> use only the approved -me interface, but a more
> straightforward solution would temporarily call .vs directly.)


Also a good point.

> And yes, I know -me already redefines .ll, which might seem to
> take the wind out of this argument's sails.  But the proposed
> .vs redefinition would set registers that -me would then use
> internally in many other macros, a situation more potentially
> far-reaching than the .ll redefinition.


True.

> For that matter, the two simplest ways to resolve this bug
> would be:
>
>  * change no code, and document that $v and $V are exceptions
>    to the general rule about $ registers; or
>  * change the names of $v and $V but nothing about how they
>    work.


I prefer the second, so I'll go ahead with that.  At least
calling them "text vertical spacing" and "display vertical
spacing" or similar will be less of a fib now after the fix to
bug #61973.

> Redesign is a worthy objective, but since no one, including
> me, has had a problem with the current functionality the whole
> time it's been around, maybe we're overthinking this.  I
> dunno, I need to ponder that idea some more. :-)


The best solution to overthinking is always more thinking! ;-)

Regards,
Branden

G. Branden Robinson <gbranden>
Group administrator
Fri 11 Feb 2022 03:25:50 PM UTC, comment #18: 


> Any thoughts on comment #16?


Still pondering, in between falling down Roman numeral rabbit holes.  My knee-jerk reaction is that of comment #2: -me handles all other type-sizing matters by having the user set registers, so it's incongruous to do something different for line spacing.

But I'm trying not to be reflexively wedded to the past (though -me's past and present are pretty similar) and entertain new ways of doing things.  And the five registers required to be strictly parallel to the type-size registers do seem like overkill.

Still, even if this is done with a request, .vs wouldn't be my first choice, as then it will do distinctly different things in -me documents than in plain roff, which seems needlessly confusing when -me could simply invent a new name for this macro.

Redefining .vs might also break some historical -me documents that call .vs directly.  True, the -me manual never condoned the use of troff's .vs request, so strictly conformant -me documents shouldn't use it, but in reality it was safe in limited contexts, such as working around bug #60553.  (The workaround I posted in that bug report goes to some effort to use only the approved -me interface, but a more straightforward solution would temporarily call .vs directly.)

And yes, I know -me already redefines .ll, which might seem to take the wind out of this argument's sails.  But the proposed .vs redefinition would set registers that -me would then use internally in many other macros, a situation more potentially far-reaching than the .ll redefinition. 

> I noticed that you've been waiting
> for feedback from me much longer than I have on you,


No problem, there's nothing urgent here.  Even if nothing here changes before 1.23 goes out the door, the current behavior isn't causing any functional problems, and can continue to work indefinitely.

For that matter, the two simplest ways to resolve this bug would be:

  • change no code, and document that $v and $V are exceptions to the general rule about $ registers; or
  • change the names of $v and $V but nothing about how they work.


Redesign is a worthy objective, but since no one, including me, has had a problem with the current functionality the whole time it's been around, maybe we're overthinking this.  I dunno, I need to ponder that idea some more. :-)

Dave <barx>
Group Member
Thu 03 Feb 2022 08:15:50 PM UTC, comment #17: 

Hi Dave,

Any thoughts on comment #16?  Upon composing this nag I noticed that you've been waiting for feedback from me much longer than I have on you, so let me address that with some chagrin.

comment #12:

> comment #10:
> > I'm not saying the 120% proportionality thing isn't a nice
> > feature--it's just that it's a PITA to integrate, maintain, and
> > test (nroff and "groff -a" are no help).
>
> That's part of why I asked about retaining $r/$R.  Those two registers are also proportions, and if those are retained, the above considerations still apply, yes?  (Two of them, anyway; $r and $R are already firmly integrated.)


I have no plans to drop any of $R/$r/$V/$v.  Especially not the first pair, as they were documented in ref.me and distributed with CSRG BSD for many years.  The latter pair are "ours" to get rid of, but I don't see how doing so would buy us anything, particularly given the news in...NEWS (comment #15).

My patch in comment #16 performs no assignments to $R or $r, and I see no reason to do so; nothing else in e.tmac assigns to them either.  They are knobs for the (advanced) user.  In 4.4BSD they were each assigned to once, at package initialization.


.\"^L           *** PARAMETRIC INITIALIZATIONS ***
.if (1m<0.1i)&(\nx) \
.       vs 9p                   \" for 12-pitch DTC terminals
.rr x
.nr $r \n(.v/\n(.s              \" ratio of vs to ps for .sz request
.nr $R \n($r                    \" ratio for displays & footnotes
.nr hm 4v                       \" header margin


> Unless I'm missing something, the testing situation isn't that much different with the proposed pv and friends: they're still settings to which terminal output is largely impervious.


Yes, you have to make them pretty big to affect the terminal.


$ cat EXPERIMENTS/big-v.me
.nr $v 185
.ll 30n
.lp
Jackdaws love my big sphinx of quartz.
Pack my box with five dozen liquor jugs.
$ nroff -me EXPERIMENTS/big-v.me | cat -s

Jackdaws love my big sphinx of

quartz.  Pack my box with five

dozen liquor jugs.


comment #13:

> comment #10:
> > Yes, but the mechanism of getting that proportionality is, in
> > *roff, typically left up to the user.  In other words, they
> > specify 10-on-12 with ".ps 10" and ".vs 12".
>
> In low-level *roff, I have no quarrel with that.
>
> -me is supposed to be higher level, so it should have license to take a less nuts-and-bolts approach (within the bounds of what's reasonable to code, and also recognizing the reality of the dearth of coders and maintainers).  I'm not sure whether any of the other classical macro packages support specifying leading as a proportion, but -mom does (in the optional second argument to her .AUTOLEAD macro: http://www.schaffter.ca/mom/momdoc/typesetting.html#autolead).


This is a good point.  My new approach in comment #16 attempts to recognize that by calling `vs`, the user is deliberately reaching under the hood...without larding up the name space with five registers, few of which will be used by few people, and those happy(?) few will, I'll guess, already be aware of `vs` as a *roff request in the first place.

> > Yes.  The thing is that I have no reason to suspect that all
> > that many me(7) users mess with setting `$v` or `$V` at all,
> > ever, in the first place.
>
> I agre with your suspicion.  And in truth, even with your proposed redesign, it should be pretty straightforward to write one's own short macro to handle setting both parameters in tandem using some document-defined proportion.


Setting both in tandem while maintaining backward compatibility seems tough to me.

Perhaps there is something obvious I have not sen.

comment #14:

> I'm afraid I can't quite glean from this whether you think the .sz changes, if any, merit a separate feature request, or are entangled enough with the register-space redesign that they should continue to be discussed here.


As can be seen from comment #16, I regard neither the `sz` changes nor the introduction of new registers as necessary.  I want to resolve the problem you originally noted: "$v and $V are in the wrong namespace".

I'm trying to do so without:

1. Breaking backward compatibility; and
2. Failing to give reasonable recourse to the user(s) who exercised the control `$V` and `$v` gave them.

Am I making sense?  (It's not a rhetorical question. ;-) )

Regards,
Branden

G. Branden Robinson <gbranden>
Group administrator
Tue 01 Feb 2022 08:38:05 AM UTC, comment #16: 

Hi Dave,

Here's a new approach that doesn't meddle with `sz` at all.

Instead, it intercepts the `vs` request.  Updated documentation is included in the diff.

It did not alter the formatting of our 3 in-tree me(7) documents.

What do you think?


diff --git a/doc/meref.me.in b/doc/meref.me.in
index 3ef233667..05b23da82 100644
--- a/doc/meref.me.in
+++ b/doc/meref.me.in
@@ -1105,6 +1105,19 @@ and
 .NR (tp
 (title point size)
 define the type size set in their corresponding contexts.
+.TL
+.b .vs
+.i \(+-v
+.DE
+Set the vertical spacing to
+.i \(+-p
+points.
+Recompute percentage of vertical spacing to type size
+and store it in
+.NR ($V
+if within a display or annotation,
+otherwise
+.NR ($v .
 .lp
 The following macros
 style or decorate an argument
@@ -2354,6 +2367,7 @@ and a square \(sq marks \*G extensions.
 \ew\(aq\fI\,S\/\fP\(aq F\(sc   interpolate formatted width of \fIS\fP
 \e*(wa S\(sq   term for \(lqappendix\(rq used by \fB.$c\fP
 \e*(wc S\(sq   term for \(lqchapter\(rq used by \fB.$c\fP
+\&.vs  M\(sq   set vertical spacing in points
 \&.xl  M       set line length (current environment)
 \&.xp  M       output index
 \en(xs R       index entry prespace
diff --git a/tmac/e.tmac b/tmac/e.tmac
index 91dc19830..4e515a2bd 100644
--- a/tmac/e.tmac
+++ b/tmac/e.tmac
@@ -135,7 +135,7 @@
 .nr _I \\n(.i
 .ev \\$1
 .ps \\n(_S
-.vs \\n(_Vu
+.xv \\n(_Vu
 .ft \\n(_F
 .ad \\n(_J
 .do @fam \\*(_A
@@ -551,6 +551,21 @@
 .nr _o \\n(.o
 ..
 .
+.rn vs xv              \" --- save troff vertical spacing request
+.
+.de vs                 \" *** vertical spacing
+.xv \\$1
+.\" Compute new vertical spacing to type size percentage (see .sz).
+.nr _r \\n(.vu/\\n(.su*100u
+.nr _V 0 \" Are we in a context where we use $V instead of $v?
+.if \\n(?k .nr _V 1
+.if "\\n(.z"|f" .nr _V 1
+.ie \\n(_V .nr $V \\n(_r
+.el        .nr $v \\n(_r
+.rr _V
+.rr _r
+..
+.
 .\" Redefine the groff fam request to set the family in
 .\" environment 2 as well as the current environment.
 .if !\n(.g .ig
@@ -1115,7 +1130,7 @@
 .@C 1
 .@F \\n(df
 .if \\n($R .@V
-.vs \\n(.sp*\\n($Vu/100u
+.xv \\n(.sp*\\n($Vu/100u
 .nf
 .if "\\*(|p"F" \
 .      fi                      \" set fill mode if "F" parameter
@@ -1495,7 +1510,7 @@
 .de sz                 \" *** set point size and vertical spacing
 .ps \\$1
 .if \\n($r .@v
-.vs \\n(.sp*\\n($vu/100u       \" default vs at pointsize + 20%
+.xv \\n(.sp*\\n($vu/100u       \" default vs at pointsize + 20%
 ..
 .
 .de @v                 \" --- possibly set $v from $r
@@ -1605,7 +1620,7 @@
 .      xl \\n($lu-\\n(fuu
 .      @F \\n(ff
 .      sz \\n(fp
-.      vs \\n(.sp*\\n($Vu/100u
+.      xv \\n(.sp*\\n($Vu/100u
 .      if !\\n(?f \
 \{\
 .              nr _b +1v       \" allow space for $s
@@ -1624,7 +1639,7 @@
 .              xl \\n($lu-\\n(fuu
 .              @F \\n(ff
 .              sz \\n(fp
-.              vs \\n(.sp*\\n($Vu/100u
+.              xv \\n(.sp*\\n($Vu/100u
 .              if !\\n(?f \
 .                      $s
 .              br
@@ -1645,7 +1660,7 @@
 .      xl \\n($lu-\\n(fuu
 .      @F \\n(ff
 .      sz \\n(fp
-.      vs \\n(.sp*\\n($Vu/100u
+.      xv \\n(.sp*\\n($Vu/100u
 .      fi
 \!.(f \\$1
 \!.@N
@@ -1776,7 +1791,7 @@
 .br
 .@C 2
 .ls 1
-.vs \\n(.sp*\\n($Vu/100u
+.xv \\n(.sp*\\n($Vu/100u
 .fi
 .in +\\n(piu
 .ds |X x


G. Branden Robinson <gbranden>
Group administrator
Sat 22 Jan 2022 12:00:29 PM UTC, comment #15: 

This isn't directly responsive to comment #13, but as I just stumbled across it, I thought it wise to share it.

It turns out that to understand the wherefores of these mysterious `$v` and `$V` registers, all we had to do was...read the NEWS.


VERSION 1.06
============

[...]

Macros
------

In previous releases the groff -me macros treated the $r and $R number
registers in a way that was incompatible with the BSD -me macros.  The
reason for this was that the approach used by the BSD -me macros does
not work with low resolution devices such as -TX75 and -TX100.  However,
this caused problems with existing -me documents.  In this release, the
vertical spacing is controlled by the $v and $V registers which have the
same meaning as $r and $R in earlier groff releases.  In addition, if
the $r or $R register is set to a value that would be correct for
the BSD -me macros and a low resolution device is not being used, then
an appropriate value for the $v or $V register is derived from the $r or
$R register.

The groff -me macros work with -C and (I think) with Unix troff.

For backward compatibility with BSD -me, the \*{ and \*} strings are
also available as \*[ and \*].  Of course, \*[ is only usable with -C.

The \*T string has been deleted.  Use \*(Tm instead.


Now, why this is NEWS-worthy but not of being documented in meintro, meref, or the groff_me(7) man page remains a mystery...

G. Branden Robinson <gbranden>
Group administrator
Mon 10 Jan 2022 06:40:12 AM UTC, comment #14: 

comment #11:

> comment #7:
> > Any changes to .sz can then be considered as a separate
> > enhancement.  (At least, from a UI perspective.  From a coding
> > perspective, they may still be coupled more tightly than that,
> > and you may want to consider the issues in tandem.)
>
> Right.  I want to get the most sensible UI I can within the
> constraints of maintainability, and then worry about the
> implementation.  (One can misjudge such things, of course, and
> have to go back to the UI question with an "I'm sorry, that
> turned out to be intractable".)


I'm afraid I can't quite glean from this whether you think the .sz changes, if any, merit a separate feature request, or are entangled enough with the register-space redesign that they should continue to be discussed here.

Dave <barx>
Group Member
Mon 10 Jan 2022 03:45:29 AM UTC, comment #13: 

comment #10:

> Yes, but the mechanism of getting that proportionality is, in
> *roff, typically left up to the user.  In other words, they
> specify 10-on-12 with ".ps 10" and ".vs 12".


In low-level *roff, I have no quarrel with that.

-me is supposed to be higher level, so it should have license to take a less nuts-and-bolts approach (within the bounds of what's reasonable to code, and also recognizing the reality of the dearth of coders and maintainers).  I'm not sure whether any of the other classical macro packages support specifying leading as a proportion, but -mom does (in the optional second argument to her .AUTOLEAD macro: http://www.schaffter.ca/mom/momdoc/typesetting.html#autolead).

> Yes.  The thing is that I have no reason to suspect that all
> that many me(7) users mess with setting `$v` or `$V` at all,
> ever, in the first place.


I agre with your suspicion.  And in truth, even with your proposed redesign, it should be pretty straightforward to write one's own short macro to handle setting both parameters in tandem using some document-defined proportion.

Dave <barx>
Group Member
Fri 07 Jan 2022 04:06:18 PM UTC, comment #12: 

comment #10:

> I'm not saying the 120% proportionality thing isn't a nice
> feature--it's just that it's a PITA to integrate, maintain, and
> test (nroff and "groff -a" are no help).


That's part of why I asked about retaining $r/$R.  Those two registers are also proportions, and if those are retained, the above considerations still apply, yes?  (Two of them, anyway; $r and $R are already firmly integrated.)

Unless I'm missing something, the testing situation isn't that much different with the proposed pv and friends: they're still settings to which terminal output is largely impervious.

Dave <barx>
Group Member
Thu 06 Jan 2022 12:25:08 AM UTC, comment #11: 

comment #7:

> comment #6:
> > 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.
>
> That's reasonable.  But does ditching $v and $V also
> necessitate ditching support for $r and $R, as the latter are
> essentially aliases of the former?


No, but it is not clear to me why the $[vV] registers were
introduced to groff in the first place.  I guess just to loosen
the conditions that cause $[rR] to have no effect at all.

> > That leaves the original question of `sz` behavior.
>
> As long as we're committing to using registers as the approved
> mechanism for specifying leading, we've decoupled the .sz
> issue from this one: .sz needn't change in order to reorganize
> the registers.  (The original proposal to change .sz was based
> on avoiding exposing registers for this functionality.)
>
> Any changes to .sz can then be considered as a separate
> enhancement.  (At least, from a UI perspective.  From a coding
> perspective, they may still be coupled more tightly than that,
> and you may want to consider the issues in tandem.)


Right.  I want to get the most sensible UI I can within the
constraints of maintainability, and then worry about the
implementation.  (One can misjudge such things, of course, and
have to go back to the UI question with an "I'm sorry, that
turned out to be intractable".)

G. Branden Robinson <gbranden>
Group administrator
Thu 06 Jan 2022 12:09:37 AM UTC, comment #10: 

comment #8:

> comment #4:
> > 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.
>
> Hold on, let me make sure I understand this proposal.  Are you
> saying the five new \*v registers would be, like their \*p
> counterparts, specified in points (or other size units)?


Yes.

> I ask because, as you note, making vertical spacing
> proportional to the type size is common.


Yes, but the mechanism of getting that proportionality is, in
*roff, typically left up to the user.  In other words, they
specify 10-on-12 with ".ps 10" and ".vs 12".

I'm not saying the 120% proportionality thing isn't a nice
feature--it's just that it's a PITA to integrate, maintain, and
test (nroff and "groff -a" are no help).

> So the user who currently sets $v to, say, 140 (a percentage),
> at the top of a document, can forget about it thereafter, and
> change pp a dozen times over the course of the document,
> knowing that the leading will follow the type size.  If the
> new pv register is also a percentage, then the transition from
> $v to pv is easy.  But if pv is a fixed size, and $v goes
> away, the migration has gotten a lot more complicated for this
> user.


Yes.  The thing is that I have no reason to suspect that all
that many me(7) users mess with setting `$v` or `$V` at all,
ever, in the first place.

Hence my proposal do something radical for 1.23.0-rc2, with
release notes that take notice of the change.  I'm hoping to
flush out people who truly rely on this groffism.

G. Branden Robinson <gbranden>
Group administrator
Wed 05 Jan 2022 07:12:45 PM UTC, comment #9: 

Oops, I failed to preview, and my attempted globs got turned into bold.  That should read: "Are you saying the five new *v registers would be, like their *p counterparts, specified in points (or other size units)?"

Dave <barx>
Group Member
Wed 05 Jan 2022 07:09:05 PM UTC, comment #8: 

comment #4:

> 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.


Hold on, let me make sure I understand this proposal.  Are you saying the five new *v registers would be, like their *p counterparts, specified in points (or other size units)?

I ask because, as you note, making vertical spacing proportional to the type size is common.  So the user who currently sets $v to, say, 140 (a percentage), at the top of a document, can forget about it thereafter, and change pp a dozen times over the course of the document, knowing that the leading will follow the type size.  If the new pv register is also a percentage, then the transition from $v to pv is easy.  But if pv is a fixed size, and $v goes away, the migration has gotten a lot more complicated for this user.

Dave <barx>
Group Member
Wed 05 Jan 2022 06:42:42 PM UTC, comment #7: 

comment #6:

> 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.


That's reasonable.  But does ditching $v and $V also necessitate ditching support for $r and $R, as the latter are essentially aliases of the former?

> That leaves the original question of `sz` behavior.


As long as we're committing to using registers as the approved mechanism for specifying leading, we've decoupled the .sz issue from this one: .sz needn't change in order to reorganize the registers.  (The original proposal to change .sz was based on avoiding exposing registers for this functionality.)

Any changes to .sz can then be considered as a separate enhancement.  (At least, from a UI perspective.  From a coding perspective, they may still be coupled more tightly than that, and you may want to consider the issues in tandem.)

Dave <barx>
Group Member
Wed 05 Jan 2022 03:30:00 PM UTC, comment #6: 

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?

G. Branden Robinson <gbranden>
Group administrator
Tue 28 Dec 2021 06:57:18 PM UTC, 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.

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.)

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?

Dave <barx>
Group Member
Tue 28 Dec 2021 11:20:31 AM UTC, comment #4: 

comment #2:

> 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?

G. Branden Robinson <gbranden>
Group administrator
Thu 23 Dec 2021 12:49:43 AM UTC, comment #3: 

To expand on the previous comment: I think it makes sense for .sz to take a second argument that temporarily overrides the $v-specified leading, in the same manner its first argument temporarily overrides the register-defined type size.  But .sz shouldn't set $v, as it doesn't set pp, fp, or their ilk: the user should be prepared for anything she sets with .sz to be clobbered with any number of normal -me macro calls.

(That is, I can see the theoretical utility of such a second .sz parameter, though I have no particular need of it myself.  And this should probably be a separate feature request.)

Dave <barx>
Group Member
Thu 23 Dec 2021 12:07:10 AM UTC, comment #2: 

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.

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

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.

Dave <barx>
Group Member
Tue 21 Dec 2021 04:51:58 PM UTC, comment #1: 

original submission:

> (This bug is sort of a counterpart to bug #61683 and a cousin to bug #61314.)
>
> The "me Reference Manual" says, "Registers and strings with names of the form $x may be used in expressions and text but should not be changed."  For most of them, this makes sense: they store values that are set by invoking specific -me macros.
>
> However, $v and $V (and seemingly $r and $R, the undocumented registers of bug #61683) are exceptions to this: the macro package provides no way* to set the line spacing other than by changing those registers directly.  Indeed, e.tmac initializes $v and $V to default values but otherwise never sets them (aside from the special case quoted in #61683 where $r or $R is set), meaning it is up to the user to change them if she cares to.  So they violate the manual's general edict concerning $-named registers.
>
> It probably doesn't make much sense to rename them at this stage, so maybe that sentence in the reference manual needs to carve out a $v/$V exception.  Alternately (and more complicatedly), new registers in the correct namespace could be defined for new -me documents, keeping $v and $V around only for back compatibility.
>
> * No sanctioned way, that is.  The user can call the low-level roff request .vs, but this request is not on -me's "use with impunity" list" -- which makes sense, because any line spacing the user set this way would get clobbered next time -me set it from $v or $V.


Good point.

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.

[Later...]

In fact I went ahead and whipped this up.  Please try this patch.  It does not appear to regress our in-tree me(7) documents.  (I merely eyeballed PostScript output, checking for page breaks remaining in the same places.)

There are tabs in it, so I am attaching it as well.

One can observe that adding this functionality to `sz` simplifies logic in several other parts of the package.

The two bits I'm unsure of are the argumentless call to `sz` in `@M`, which might revert the type size back to something undesirable, and the XXX comment.

What do you think?


diff --git a/tmac/e.tmac b/tmac/e.tmac
index a60b37cf7..9fd43d9bf 100644
--- a/tmac/e.tmac
+++ b/tmac/e.tmac
@@ -1087,10 +1087,10 @@
 .
 .de @M                 \" --- set modes for display
 .nr ?k 1
+.nr ?V 1
 .@C 1
 .@F \\n(df
-.if \\n($R .@V
-.vs \\n(.sp*\\n($Vu/100u
+.sz
 .nf
 .if "\\*(|p"F" \
 .      fi                      \" set fill mode if "F" parameter
@@ -1109,6 +1109,7 @@
 .br
 .if !"\\n(.z"|k" .do @err attempted close of never-opened keep
 .nr ?k 0
+.nr ?V 0
 .di
 .in 0
 .ce 0
@@ -1462,10 +1463,20 @@
 .\"            *** FONT AIDS ***
 .
 .
-.de sz                 \" *** set point size and vertical spacing
+.de sz                 \" *** set type size and vertical spacing
 .ps \\$1
-.if \\n($r .@v
-.vs \\n(.sp*\\n($vu/100u       \" default vs at pointsize + 20%
+.if \\n(.$>1 \{\
+.      ie \\n(?V .nr $V \\$2
+.      el        .nr $v \\$2
+.\}
+.ie \\n(?V \{\
+.      if \\n($R .@V
+.      vs \\n(.sp*\\n($Vu/100u
+.\}
+.el \{\
+.      if \\n($r .@v
+.      vs \\n(.sp*\\n($vu/100u
+.\}
 ..
 .
 .de @v                 \" --- possibly set $v from $r
@@ -1575,7 +1586,6 @@
 .      xl \\n($lu-\\n(fuu
 .      @F \\n(ff
 .      sz \\n(fp
-.      vs \\n(.sp*\\n($Vu/100u
 .      if !\\n(?f \
 \{\
 .              nr _b +1v       \" allow space for $s
@@ -1594,7 +1604,6 @@
 .              xl \\n($lu-\\n(fuu
 .              @F \\n(ff
 .              sz \\n(fp
-.              vs \\n(.sp*\\n($Vu/100u
 .              if !\\n(?f \
 .                      $s
 .              br
@@ -1615,7 +1624,6 @@
 .      xl \\n($lu-\\n(fuu
 .      @F \\n(ff
 .      sz \\n(fp
-.      vs \\n(.sp*\\n($Vu/100u
 .      fi
 \!.(f \\$1
 \!.@N
@@ -1749,6 +1757,7 @@
 .br
 .@C 2
 .ls 1
+.\" XXX: Consider not altering the vertical spacing.
 .vs \\n(.sp*\\n($Vu/100u
 .fi
 .in +\\n(piu
@@ -2069,6 +2078,8 @@
 .@R fu\"               \" footnote undent
 .@R bt\"               \" block keep threshold
 .@R *\"                        \" has \** been referenced?
+.
+.\" internal Booleans
 .@R ?a\"               \" pending floating keep at page top?
 .@R ?b\"               \" pending floating keep at page bottom?
 .@R ?C\"               \" at chapter header?
@@ -2080,6 +2091,7 @@
 .@R ?R\"               \" renumbered chapter?
 .@R ?s\"               \" skip next page?
 .@R ?T\"               \" inside .TS H?
+.@R ?V\"               \" inside keep that uses $V for vert spacing?
 .@R ?W\"               \" wide floating keep at page bottom?
 .@R ?w\"               \" wide floating keep at page top?
 .


(file #52543)

G. Branden Robinson <gbranden>
Group administrator
Tue 21 Dec 2021 01:13:58 AM UTC, original submission:  

(This bug is sort of a counterpart to bug #61683 and a cousin to bug #61314.)

The "me Reference Manual" says, "Registers and strings with names of the form $x may be used in expressions and text but should not be changed."  For most of them, this makes sense: they store values that are set by invoking specific -me macros.

However, $v and $V (and seemingly $r and $R, the undocumented registers of bug #61683) are exceptions to this: the macro package provides no way* to set the line spacing other than by changing those registers directly.  Indeed, e.tmac initializes $v and $V to default values but otherwise never sets them (aside from the special case quoted in #61683 where $r or $R is set), meaning it is up to the user to change them if she cares to.  So they violate the manual's general edict concerning $-named registers.

It probably doesn't make much sense to rename them at this stage, so maybe that sentence in the reference manual needs to carve out a $v/$V exception.  Alternately (and more complicatedly), new registers in the correct namespace could be defined for new -me documents, keeping $v and $V around only for back compatibility.

* No sanctioned way, that is.  The user can call the low-level roff request .vs, but this request is not on -me's "use with impunity" list" -- which makes sense, because any line spacing the user set this way would get clobbered next time -me set it from $v or $V.

Dave <barx>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #52543:  me-sz.diff added by gbranden (2KiB - text/x-patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by gbranden (Updated the item)
  • -email is unavailable- added by barx (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-02-14 gbranden StatusIn Progress Fixed
        Open/ClosedOpen Closed
        Planned ReleaseNone 1.23.0
    2022-02-11 gbranden StatusNeed Info In Progress
    2022-02-03 gbranden Item GroupDocumentation Feature change
    2021-12-21 gbranden Attached File- Added me-sz.diff, #52543
        StatusNone Need Info
        Assigned toNone gbranden
        Summary$v and $V are in the wrong namespace [me] $v and $V are in the wrong namespace

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code