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: Ingo Schwarze
Subject: [bug #57510] not all TTY output controls simultaneously available (nroff needs -P)
Date: Sat, 18 Jan 2020 07:34:22 -0500 (EST)
User-agent: Mozilla/5.0 (X11; OpenBSD amd64; rv:71.0) Gecko/20100101 Firefox/71.0

Update of bug #57510 (project groff):

                  Status:               Need Info => In Progress            

    _______________________________________________________

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

    _______________________________________________________

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]