bug-groff
[Top][All Lists]
Advanced

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

[bug #61100] [troff] do_request(): assertion failed: 'do_old_compatible_


From: G. Branden Robinson
Subject: [bug #61100] [troff] do_request(): assertion failed: 'do_old_compatible_flag == -1'
Date: Sat, 4 Sep 2021 14:13:36 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

Follow-up Comment #6, bug #61100 (project groff):

[comment #5 comment #5:]
> [comment #4 comment #4:]
> > 
> > @code{de} defines a macro that inherits the compatibility mode
> > enablement status of its context (@pxref{Implementation Differences}).
> > 
> 
> The above seems to say that the defined macro runs in the compatibility
state in which it is invoked, while...
> 
> > 
> > compatibility mode needs to be switched off while such a macro is
> > interpreted---without disturbing that state when it is finished.
> > 
> 
> ...this seems to say the defined macro runs in a fixed compatibility state
regardless of that of its invoker.
> 
> The problem may be the overloading of the word "context"?

I think the problem may be that I left out too much...context!


@code{de} defines a macro that inherits the compatibility mode
enablement status of its context (@pxref{Implementation Differences}).
Often it is desirable to make a macro that uses @code{groff} features
callable from contexts where compatibility mode is on; for instance,
when writing extensions to a historical macro package.  To achieve this,
compatibility mode needs to be switched off while such a macro is
interpreted---without disturbing that state when it is finished.


The foregoing paragraph follows the lengthy presentation of `de` in detail,
and is present not just to articulate the foregoing points but to motivate the
very next thing presented...`de1`, which creates a macro that switches off
compatibility mode as described.

> Its second appearance specifically says "callable from contexts where...,"
so it's clear this is talking about the invoker's context.  The first instance
may be talking instead about the context in which the macro is _defined_
rather than that in which it is invoked.  That at least lets me mentally
reconcile the above two quoted passages, but I'm not sure if it's the correct
reading.  (I have little real-world experience with using compatibility mode,
so much about it remains mysterious to me.)

The difference is that the first instance is describing the behavior of the
request just presented, and the second is setting the reader up for a macro
that behaves differently.

> I may be getting us lost in the weeds re: this bug's topic, so feel free to
redirect this discussion to the email list or other alternate venue.

No, that's okay, I think the problem is simply that I was too terse with my
presentation in Savannah.  If you get a chance to review the Texinfo manual
subsequent to these changes, I'd appreciate hearing if you feel I've still
left the point at issue murky.

Granted, there is still other murkiness cavorting about madly...

    _______________________________________________________

Reply to this item at:

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

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




reply via email to

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