bugGNU troff - Bugs: bug #62814, consolidate or distinguish...

 
 

bug #62814: consolidate or distinguish tty.tmac and tty-char.tmac

Submitter:  Dave <barx>
Submitted:  Tue 26 Jul 2022 02:19:42 AM UTC
 
Category:  Macro - others/general Severity:  1 - Wish
Item Group:  Feature change Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open Planned Release:  None
* Mandatory Fields

Add a New Comment (Rich Markup)
   

Comment Type & Canned Response:
       No canned response available

 

( Jump to the original submission )

Sun 13 Nov 2022 12:42:07 AM UTC, comment #6: 

Heh, I see James Clark anticipated this bug report back in groff 1.06, adding these lines to tty.tmac (then named tmac.tty) in commit b04d345e:

.\" If you want the character definitions in tmac.tty-char to be loaded
.\" automatically, remove the `\"' from the next line.
.\"do mso tmac.tty-char

These lines remain, almost unchanged, today.  So all it would take to resolve this bug is to reverse their sense, uncommenting the "mso" line and editing the comment to instruct users how to not include tty-char automatically.

Alternately, Ingo has addressed my concerns with the solution he proposed in comment #3, so that'd be another way to go.

In either case, it might also be good to incorporate Ingo's lucid explanation in comment #1 of the difference between the two files' goals into comments in the files themselves.

Dave <barx>
Project Member
Tue 02 Aug 2022 03:09:40 PM UTC, comment #5: 

comment #4:

> While not as often a problem in practice these days, the troffrc file is not editable by ordinary users, only by root.


As documented in the GNU troff(1) manual, that's trivial to solve for advanced users:

Copy troffrc to ~/tmac/troff, edit it as desired, then use "troff -M ~/tmac" or set GROFF_TMAC_PATH=~/tmac in the envoronment.

Ingo Schwarze <schwarze>
Project Member
Tue 02 Aug 2022 07:48:34 AM UTC, comment #4: 

comment #3:

> Please don't overengineer it by defining registers and adding .if statements


The advantage of an .if block, even if the condition is never used by any user, is that (assuming conventional code indentation) it very obviously visually groups together all the definitions of a certain classification.  (This is less a consideration if the two groups are kept in separate files, also a valid choice.)

> So power users who don't want it by default can simply comment it out


While not as often a problem in practice these days, the troffrc file is not editable by ordinary users, only by root.

Dave <barx>
Project Member
Mon 01 Aug 2022 10:53:33 AM UTC, comment #3: 

Please don't overengineer it by defining registers and adding .if statements and the like.

tty.tmac is called from troffrc.
One simple idea would be to just call tty-char.tmac from the same place.
So power users who don't want it by default can simply comment it out and call -m tty-tmac manually in those cases where they do want it.

Ingo Schwarze <schwarze>
Project Member
Mon 01 Aug 2022 12:04:29 AM UTC, comment #2: 

comment #1:

> So i think most users would be better served by loading it by default.


That's my gut feeling, though as someone who doesn't use most of this file's character palette, I defer to the judgment of more experienced users.  In general it just seems more user-friendly to render characters in a suboptimal way than to throw warnings and leave those spots empty.

> If you want to be extra careful, you could leave these in
> their own file though, such that people who want to scutinize a
> document for characters that render badly to ASCII can more
> easily do so by disabling loading the file in one way or another.


Giving power users that option would be good.  One possible mechanism would be wrapping the lower-quality definitions in an .if block, in such a way that a user defining a certain register on the command line would cause that block to be skipped.  Then it wouldn't matter as much which file they lived in.

There could be separate registers to control each set of fallbacks, in fact, in case a user wants to disable them all, such as for a testing scenario of the type Branden alluded to in the email thread.

Dave <barx>
Project Member
Sun 31 Jul 2022 05:31:34 PM UTC, comment #1: 

Arguably, the definitions in tty.tmac are of such a high quality that any user of terminal output wants to use term unconditionally, and warnings about characters in the input document that need any of these fallbacks would make little sense.

Most of the fallbacks in tty-char.tmac, on the other hand, are arguably desperate attempts to somehow render the respective characters even when good renderings don't really exist, and most are of dubious or even poor quality.  Some users might possibly prefer warnings about unavailable characters to poor or cryptic renderings, and hence decide to not load tty-char.tmac, in particular if they consider changing the input file to more gracefully render to ASCII.

That said, while i see why some users might want to not load tty-char.tmac for some uncommon purposes, personally i never felt a need to suppress its loading for my purposes.  Quite to the contrary, it happened several times that i simply forget loading it, resulting in badly degraded output.  So i think most users would be better served by loading it by default.

If you want to be extra careful, you could leave these in their own file though, such that people who want to scutinize a document for characters that render badly to ASCII can more easily do so by disabling loading the file in one way or another.

Ingo Schwarze <schwarze>
Project Member
Tue 26 Jul 2022 02:19:42 AM UTC, original submission:  

As discussed in the thread starting at http://lists.gnu.org/r/groff/2022-07/msg00041.html, it is unclear what utility is served by having tmac/tty-char.tmac loaded in different circumstances from tmac/tty.tmac.

troffrc unconditionally loads tty.tmac when the postprocessor is grotty--congruent with how it handles other postprocessors--so it's only tmac/tty-char.tmac that might not be loaded for some terminal output.

It seems that these files should always be loaded in tandem (whether by loading both files, or combining the files' content into one), or a use case for using tty.tmac without tmac/tty-char.tmac documented.

Presently, both files contain (disjoint) sets of tty fallback character definitions.  As Branden and I agreed in the email thread, all fallback character definitions should live in the same place, wherever ends up making the most sense for that.

For modularity, tty-char.tmac could continue to be its own file for this purpose, separating these definitions from other terminal-setup tasks that tty.tmac performs.  But if so, and absent a demonstrable (and preferably documented) use case for not loading these definitions, it seems tty.tmac ought to unconditionally include tty-char.tmac.

(One item from the email discussion has been resolved: Branden wrote "I think that definition [of "\[sd]"] in tty-char.tmac should be dropped," and this was done in commit 175c42d7.)

Dave <barx>
Project Member

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by schwarze (Posted a comment)
  • -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.

     

     

     

     

    No changes have been made to this item

    Back to the top


    Powered by Savane 3.9