bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#56682: feature/improved-locked-narrowing 9dee6df39c: Reworked locked


From: Gregory Heytings
Subject: bug#56682: feature/improved-locked-narrowing 9dee6df39c: Reworked locked narrowing.
Date: Wed, 01 Feb 2023 22:42:56 +0000



I must admit that it's very strange to hear this from you.


When I erred, I have no problems whatsoever to admit that I erred.


Those very opinions were voiced by several other people over the last year, and you always disagreed with these very arguments in the strongest terms, citing various use cases and data points, with several relevant files and modes. I wonder what have happened that you now see in the code what you didn't see then, even when others told you they saw it.


I don't think it's useful to start a discussion about what I said and meant to say, but FTR I do not agree with the above. The only thing I strongly disagreed with is Dmitry's claim that the existing mechanisms are sufficient to limit the damage of ill-behaving modes. For the rest, I tried to find the best compromise to handle buffers with long lines as well as possible. As we all know, determining where to place the cursor is hard. I did believe that adding a forced narrowing would be helpful, and in some cases it is, but in other cases it isn't, and all in all I now consider that Emacs would be in a better shape without that mechanism. In particular, the fifth point is the result of the (recent) addition of a mechanism to unlock a locked narrowing, which makes the exercise almost pointless.


Anyway, after thinking about this, I cannot agree to removing what we now have on emacs-29. It's too late for that, and I'm not prepared to delay the pretest for any significant time. So we will go into the pretest with what we have, and decide what to do with it in Emacs 29.2 and 30.1 according to how the chips will fall.


Okay, if that's your decision. IMO just going back to what the code did earlier is (very) safe, but I cannot do that without your approval.


I guess by suggesting to remove the code you were also telling me that you won't be fixing those documentation issues, which you promised to work on a month ago? If so, I guess this is one more buck that stops with me...


Even if I think it's not TRT to do, I can still do that.






reply via email to

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