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
[email protected]
_______________________________________________
bug-ed mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-ed
