I would suggest, as a user of ed since Ken Thompson sent Version 6 out on 9 track tape, that when either one of two ways of doing some small detail can be argued to be "correct", and either way can be worked with to get the same result, that the "right" thing to do is "don't change it."
Changing it so that one thing works that was broken will just break something else that was depending on the other way of doing it. Both pieces of code that depend on such a detail are arguably "broken" ... depending on some fussy detail. That's life. Leave it unchanged, and thus continue to provide a stable "target" behaviour that users (code and humans) can adapt to. That's the "ed way", and has been for decades :). Not breaking interfaces takes priority over fiddling with details that are already in use, unless there is no other way to achieve some necessary capability. -- Paul Jackson p...@usa.net _______________________________________________ bug-ed mailing list bug-ed@gnu.org https://lists.gnu.org/mailman/listinfo/bug-ed