bug-groff
[Top][All Lists]
Advanced

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

[bug #59290] add register to enable/disable backtraces on diagnostics


From: G. Branden Robinson
Subject: [bug #59290] add register to enable/disable backtraces on diagnostics
Date: Fri, 30 Apr 2021 11:13:57 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

Update of bug #59290 (project groff):

                Category:              Macro - ms => Core                   
                 Summary: [ms]: add register to enable backtraces on
diagnostics => add register to enable/disable backtraces on diagnostics

    _______________________________________________________

Follow-up Comment #4:

I agree with Ingo that this is a generalizable issue.

Unfortunately the only naming convention that the groff core honors is that a
leading dot means a register is read-only.  By definition, this one would be
writable.

I therefore have no brilliant ideas what to call it.  The one most congruent
with existing "core" writable registers suggests a choice of `backtrace`,
which is also pretty likely users' choice for a name.

On the other hand, it's hard to imagine what use user code would have for such
a variable name unless it was to do something similar to what we already have
in mind.  I.e., it's conceivable someone is doing something like this.


.de my*deep*macro
.if \n[backtrace] .backtrace


While this would step on such a hypothetical roff author's toes, there is no
way to ask the formatter whether it recently issued an error or warning
message, so I can see the above sort of thing being written to work around
such a deficiency, possibly with hand-written and possibly redundant validity
checks on string or register contents.

(I'm on the record--but I'll reiterate here--that I am not a fan of
Thompsonesque abbreviation practices. `bt` is not only uncommunicative but
even more likely to collide with user-selected names.)

Worthy of consideration for groff 1.23.1, maybe.

    _______________________________________________________

Reply to this item at:

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

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




reply via email to

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