bug-groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #57510] not all TTY output controls simultaneously available (nroff


From: G. Branden Robinson
Subject: [bug #57510] not all TTY output controls simultaneously available (nroff needs -P)
Date: Mon, 20 Jan 2020 13:22:40 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0 PureBrowser/60.9.0

Update of bug #57510 (project groff):

                  Status:             In Progress => Need Info              

    _______________________________________________________

Follow-up Comment #12:

Take 2 attached.

* Undeprecated -c and -h.

* Implemented -V.  Just the simple version.  Initially I considered -VV for
invoking groff with -V, but groff already supports -VV meaning something else,
and supporting -VVV starts to sound a little nuts to me, and in any case the
parallelism is lost at that point.

* Discarded $Popts.  You're right, it helped nothing.

* I disagree about how to represent an option with an option argument and
arity 0..n.  I think [-Popt ...] gets the idea across just fine, in parallel
to [FILE ...].  Synopsis language is (almost?) isomorphic to POSIX Basic
Regular Expressions.  A ... indicates an arity of >= 1 for the preceding atom,
and surrounding brackets permit an arity of 0.  As you can guess I'd love to
have a mathematical argument about this. >:-)

* I have no plans to reuse nroff's -c and -h for anything, nor even any ideas
for enhancements they could be attached to.

* Pulled -mtty-char into $opts.

* Got rid of eye-watering ${1+"$@"} construction.  This is another instance of
Autoconf shell dialect.  POSIX shells should have no trouble.

* In a subsequent commit, I'd like to more aggressively dispose of
pre-POSIXisms, but here I confined my radical updates to 1995 standards only
on lines I was already touching.

[comment #5 comment #5:]
> Regarding the patch:
> 
> * I strongly oppose deprecating -c.  As i repeatedly said before, i consider
it superior to SGR output because it doesn't require running the pager in an
insecure mode (depending on which pager mode the user picks, it may be
marginally or substantially insecure).  I recommend using -c and still think
it should be the default.  It is also the only output mode supported by
mandoc(1), and it looks extremely unlikely that mandoc will ever support SGR.
> * I have no opinion about -h, it doesn't seem to matter much either way.
> * Adding the -P option to nroff(1) makes sense to me.
> * What's the point in adding a separate $Popts variable?  Why not just add
each -P argument to $opts using a line like: opts="$opts -P$1"?
> * I believe the changes to the handling of the -c and -h options are buggy. 
Either you have to leave them untouched (adding them to $opts) or you have to
change the "opts=" to "Popts=" lest -c and -h suddenly clobber other options
given earlier on the command line.  Also, you don't want "-c -h" to copy the
previous content of $Popts to $opts twice.
> * I believe the ellipsis in "[-Popt ...]" in the usage() is incorrect.  It
should just be "[-Popt]".  You can only give one argument to -P.  For example,
"-P-d -o" wouldn't work.  Instead, "-P-d -P-o" would be required.
> 
> The man(1) option name space is indeed crowded: 
http://mandoc.bsd.lv/man/man.options.1.html
> Not sure it is wise to add more options of low usefulness and non-existent
portability like the one you propose.
> 
> Reusing options for a different purpose isn't a particularly bright idea. 
At least, a very long time should pass between deprecation and reuse.  The
point of deprecating stuff isn't to free up namespace for reuse.  The point is
to make the user interface smaller and simpler.

[comment #11 comment #11:]
> A dry-run flag for nroff sounds like a reasonable plan to me.
> 
> Consulting https://mandoc.bsd.lv/man/man.options.1.html ,  i notice the -n
that is often used for dry-run functionality is already taken for troff (since
Version 7 AT&T UNIX) and hence also in groff and GNU nroff.
> 
> I think i'd suggest using -V because that is already used for a very similar
purpose in groff (since groff-0.6 (Sep 2, 1990)), does not appear to clash
with anything else, and being an upper-case option, gives it relatively little
prominence, which is good for this option.
> 
> After printing the constructed groff command, you might even consider
appending -V and then running *that*, too, such that the groff pipeline is
also printed.  Or maybe not.  Not sure - just suggesting to think about it. 
Does it add significant value?  If not, keep it minimal.

    _______________________________________________________

Reply to this item at:

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

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]