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

[G. Branden Robinson]

Update of bug #61710 (project groff):

              Item Group:           Documentation => Feature change         

    _______________________________________________________

Follow-up 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 #12:]
> [comment #10 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 #13:]
> [comment #10 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 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

    _______________________________________________________

Reply to this item at:

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

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