>>>>> Kaushal Modi writes: > Understood. My only hope that I can convince the maintainers with my reason > that this proposal fixes a real-life problem with the help democratic voting > system (if the opinions asked on emacs-devel matter and can be called that). That's fair, though we still need to be personally convinced. :) Ancient behavior has a mystique that requires a fair bit of motivation for us to change. It really just comes down to the fact that Eli and I are conservative fellows in these things. > Wouldn't the master branch be a good playground for this? If it affects > people negatively, it's just a one-line commit and thus easy to revert. I'm not sure enough people use the master branch for it to determine how it will affect the majority. In all likelihood it won't affect anyone badly at all (I don't really see how it could), it's just not something we need to do today. I'm fine with keeping the issue open, though. My preference would be that another solution will solve this, and all similar issues, by way of a better design. Otherwise, we're picking at gnats in a sensitive area (i.e., long-held behavior). > I should have used the term "wall time". This issue has wasted quite a few > minutes for me. Understood. > Of course. I will do that. I was just hoping the "right fix" would get in. > (Otherwise why would anyone bother to submit bug reports and patches?) You're making us aware of bad implementation decisions made long ago, which are good to know about. There have been other, fairly long, debates on the meaning of the "read-only" bit, and when a buffer should get marked as modified. I'm sure these issues relate to yours as well. For example: should a buffer-modifying operation be aborted early even if the actual operation of the function won't change anything? People argue that M-q shouldn't mark a buffer as modified if the reformatting changes nothing: does that mean M-q should be allowed on a read-only buffer if it doesn't modify, or should it abort early because its makes no sense? And how many people have built up macros or customizations or custom functions in their configuration that rely on ultimately-non-modifying operations being allowed in read-only buffers, rather than turning them into errors? Arguably their code is "wrong", but how much of their time should we waste by fixing this and causing their keyboard macros to break? I realize my argument tends toward "change nothing", but that's not what I mean. I'm only saying that there's a lot of users to be considered, so unless we *need* to risk breakage, we prefer to avoid it. The current behavior has been around for a long, long time, and while it's painful for your use case, I know you have the expertise to advise Emacs as needed. > I haven't yet got an answer to a real-life scenario that would break by this > change. What kind of (i) side-effects would one be relying on (ii) while > running indent-region (iii) on read-only files? > > It's a bit sad, I am presenting a solution to a real problem and the counter > argument is just one, and hypothetical. We don't normally have any counter-evidence that an old, bad behavior *should* be kept. It's more an argument that we don't change them until we're convinced it's time. -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2