[bug #60954] [troff] implement environment renaming and/or removal

[G. Branden Robinson]

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

[comment #5 comment #5:]
> I suppose the overarching question is how much time to devote to a difficult
problem the solution of which serves only to appease a sense of orthogonality
rather than solve a real-world problem.

A fair point, but this is not nearly the most difficult problem in the groff
bug list.  :)

When I comment on tickets it is often to record information to help spin
myself (or another contributor) up on the underlying issue at some
undetermined future date.  Chatting to the ticket is often, but not always, a
sign that I'm trying to do something about it for my next push.  (Because I am
a rat who wants to mash the endorphin-release button with a minimum of effort
in a now-discredited study[1], when I comment on a ticket while passing over
it, it is often to record the particulars of the difficulty I encountered
before moving on to the next, easier, thing.)

> If you decide to allow deletion of active environments (and I agree that the
simplest solution is to disallow it, as it wouldn't even have helped with the
problem Werner thought he needed to solve back in '06), it shouldn't require
any pointer manipulation upon the delete itself: it's only upon popping back
to the now-nonexistent environment that some evasive action need be taken.

I think that's the problem.  We don't know where to go in our evasion if we
traverse into a deleted node.  In a horrible implementation, we'd follow a
pointer to deallocated storage; in a less-bad one, we'd see a null pointer
marking the node's deleted status, but have no way to locate the node that the
deleted node pointed to (and if _that_ node had also been deleted, we'd
_still_ have a problem, hence my musing about sequences of deleted nodes).

I was, however, I think, incorrect about multiple arguments to this notional
`evrm` request being a problem; it would simply process them serially and no
extra complications should arise.  My career has gotten me more and more
preoccupied with concurrency problems, and I sometimes forget that a *roff
formatter is a comparatively simple machine.

> (There's no requirement that the stack be empty upon program exit,

One of the things that bothers me about the current implementation; is that
the stack can ever be empty at all.  In documenting it for the manual I wrote
as if the current environment is the stack top even if there is nothing below.
 As _implemented_, that isn't really true; there's a current environment and
if environments beyond the initial one are ever created, the pointer
`env_stack` never becomes non-null.

This grates on me, but I admit it's pretty much a philosophical complaint.

> so a user might delete an active environment knowing full well that they'll
never pop back to it.)

Right.  If they're not crazy, those two notions should be coupled.  :)

> Deleting the _current_ environment raises thornier questions and I presume
would be disallowed in any case.

Agreed.  I _want_ to think in terms of a chain of biconditionals.

There is always a current environment. <=> There is always an environment
stack. <=> The current environment is always at the top of the stack.

...but when we get down to C++ data types, that's just not how James Clark
wrote it.  It works _as if_ these were the case, but they're not.  Thus my
Nolanesque adventure in bug #62036.

Another thing I wanted was a simplified version of `pev` that lists _only_ the
environment names in the stack, in order.  The present implementation (1)
lists them in dictionary order, which is useless for all practical purposes
and (2) sprays dozens of lines of output detailing each environment's state to
the terminal, which is great if you need to debug environment _contents_, but
bewildering if all you needed to know was whether you'd screwed up the stack
arrangement--as (1) notes, it can't tell you that except in trivial cases
anyway.

Regards,
Branden

[1] https://en.wikipedia.org/wiki/Rat_Park

    _______________________________________________________

Reply to this item at:

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

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