bugGNU roff - Bugs: bug #60954, [troff] implement environment...

 
 

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

Submitter:  G. Branden Robinson <gbranden>
Submitted:  Wed 21 Jul 2021 07:34:00 PM UTC
   
 
Category:  Core 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
   

Jump to the original submission

Wed 16 Mar 2022 07:55:50 AM UTC, comment #8: 

GBR, orthogonality = parallel or perpendicular?

carly <cface>
Wed 16 Mar 2022 03:37:41 AM UTC, comment #7: 

comment #6:

> I think that's the problem.  We don't know where to go in
> our evasion if we traverse into a deleted node.


I admit I haven't looked at the code.  But deducing how it works based on the behavior ("the grand thing is to be able to reason backwards" -- Sherlock Holmes), it seems there must be two separate sets of objects: a data structure containing all the information associated with an environment (I'll call it the "EDS" here to avoid having to take two minutes to look at the code and find out its proper name; see "rat seeking minimum of effort"), indexed by the environment name; and a stack containing a list of names of environments.  The notable fact that an environment can appear on the stack multiple times seems to preclude the EDS itself from containing the pointers that comprise the stack, else multiple pushes of the same environment would create less a stack and more a pretzel.  And an EDS can't be created anew on every push, else changes to one structure on the stack wouldn't propagate to other stack nodes with the same name.

So freeing a single EDS (what I think of as a "delete") seemingly wouldn't affect the stack, because the behavior seems to dictate this is maintained separately.  The stack may in reality contain pointers to EDSes rather than strings of names, but those pointers can be null without a problem: the "next" pointer is the only thing you need to navigate your way back down the stack, and I see no way this can be part of an EDS itself.  But maybe James Clark has done something cleverer than I can dream up.

Dave <barx>
Group Member
Wed 16 Mar 2022 12:37:06 AM UTC, comment #6: 

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

G. Branden Robinson <gbranden>
Group administrator
Tue 15 Mar 2022 11:53:04 PM UTC, 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.

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.  (There's no requirement that the stack be empty upon program exit, so a user might delete an active environment knowing full well that they'll never pop back to it.)

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

Dave <barx>
Group Member
Tue 15 Mar 2022 10:59:07 PM UTC, comment #4: 

I spent some time in env.cpp thanks to bug #62036.

Deleting environments will be a pain.  If an environment whose deletion is requested is in the environment stack, we either have to refuse the deletion request or rejigger the pointers in the singly-linked list to jump over each sequence of deleted list nodes.  Pointer manipulation--how hard could it be?  We should delegate the task to a second-year computer science student...

On the bright side, I only imagined accepting one environment name argument at a time on a deletion request.  That would simplify the stack-editing logic, however making `evrm` (or whatever we call it) asymmetric with `rm` at the interface level would be kind of a bummer.

So maybe refusing to delete an "active" environment, as Dave terms it, is the best way to go, if/when deletion is undertaken.

(Renaming should be simple.  An environment's name is dumb data inside a structure.  Nothing maintains references to it except its parent.)

G. Branden Robinson <gbranden>
Group administrator
Wed 21 Jul 2021 08:21:43 PM UTC, comment #3: 

Thanks, Kurt!

Further musings:

I suppose environment removal would be called '.rev' by analogy with .rchar, .rfschar, and .rr.  I shy away from '.rmev' because it collides in its first two letters with '.rm', though this is already true of '.rn' and '.rnn', so I guess it's not a serious problem.

On the other hand, '.evr' would be lexically close to the only other environment-related requests there are, '.ev' and '.evc'.

To the bikeshed!

G. Branden Robinson <gbranden>
Group administrator
Wed 21 Jul 2021 07:46:48 PM UTC, comment #2: 

Tadziu Hoffmann's version is

.de CI
.ds xx \\n[.fam]
.fam C
.I \\$@\F[]\F[\\*[xx]]
.fam
..


Werner then says:

> Excellent!  This is very nice.  BTW, attaching something directly to
> \$@ doesn't work: Saying `\$@foo' as a macro argument is equivalent to
> `\$@ foo'.  So this is probably the final version:



.de CI
.  ds xx \\n[.fam]
.  fam C
.  I \\$@ \F[]\F[\\*[xx]]
.  fam
..


The mailbox archives of the list have the messages as originally delivered, with no address obfuscation.

T. Kurt Bond <tkurtbond>
Wed 21 Jul 2021 07:34:57 PM UTC, comment #1: 


original submission:

> Unsurprisingly, Werner Lemberg already noticed this fact 14 years ago.


...15 years ago.

G. Branden Robinson <gbranden>
Group administrator
Wed 21 Jul 2021 07:34:00 PM UTC, original submission:  

It offends my sense of orthogonality that environments can be created but not destroyed.

Unsurprisingly, Werner Lemberg already noticed this fact 14 years ago.

https://lists.gnu.org/archive/html/groff/2006-05/msg00094.html

Sadly, the mailing list's crude and oversensitive email address censorship code obliterated the clever part of Tadziu's solution that worked around the need for environment removal, and which motivated Werner to shelve the idea.

I suppose that workaround lingers in the hdtbl directory somewhere, though.

No immediate plans to work on this, but I wanted to note it.

G. Branden Robinson <gbranden>
Group administrator

 

(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 cface (Posted a comment)
  • -email is unavailable- added by barx (Posted a comment)
  • -email is unavailable- added by tkurtbond (Posted a comment)
  • -email is unavailable- added by gbranden (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.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-03-15 gbranden Summary[troff] implement environment removal [troff] implement environment renaming and/or removal
    2022-01-11 gbranden Item GroupNone Feature change

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code