line-move-visual
in [Lisp]
|
From: Thad Floryan on 6 Jun 2010 21:07 On 6/6/2010 11:17 AM, Mark Crispin wrote: > [...] > All because of clueless developers who broke emacs in version 23. This is OT so I'll keep it short. Similar braindamage recently with Fedora where a developer stated "I don't particularly care how UNIX has always worked." Refs: <http://linux.slashdot.org/story/09/11/18/2039229/Fedora-12-Lets-Users-Install-Signed-Packages-Sans-Root-Privileges> <http://linux.slashdot.org/story/09/11/20/1241231/Fedora-12-Package-Installation-Policy-Tightened> <https://www.redhat.com/archives/fedora-announce-list/2009-November/msg00012.html> <https://www.redhat.com/archives/fedora-devel-list/2009-November/msg01445.html> Developer's blog: <http://blogs.gnome.org/hughsie/2009/11/20/the-fedora-12-installing-saga/>
From: Mark Crispin on 6 Jun 2010 22:53 On Sun, 6 Jun 2010, Thad Floryan posted: > This is OT so I'll keep it short. Similar braindamage recently with > Fedora where a developer stated "I don't particularly care how UNIX > has always worked." Wow. I've dealt with broken "improvements" in RedHat/Fedora before; they don't seem to have a very good review process for functionality changes. The two that I remember the most are making flock() return ENOLCK for an NFS file (instead of no-op) and getaddrinfo() doing a reverse DNS lookup for the ai_canonname return value. In both cases, the developer insisted that the change was a "fix", never mind all the applications that were broken by it. Eventually, both of these changes were reverted after a huge hue and cry. This one takes the cake. I don't know which amazes me more, the fact that such an ill-conceived change was made in the first place, or the developer's reaction when called to account. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote.
From: Uday S Reddy on 7 Jun 2010 04:19 On 6/6/2010 4:21 PM, Tassilo Horn wrote: >> In this particular instance, the customization needed is not a big >> deal: set line-move-visual to nil. Almost everybody can do it. But >> the time they had to spend in discovering that they needed to change >> it is what has been significant. > > IMO, the first thing a new emacs user should learn is using the help > facilities. So after seeing that `C-n' moved point not to the next > (logical) line as it always did should be a reflexive `C-h C-n': Note that we are talking about the old emacs users, not the new ones. (The C-n compromise was apparently made to help the new Emacs users!) An old emacs user might see a long logical line only very rarely, and he might take quite a while to realize that anything had changed. As Mark Crispin explained, he had to purposefully go looking for it by doing M-<large number> C-n on a number of Emacs versions to discover that something had changed. I had to hear of Mark's experience before I started suspecting that there could be vulnerabilities in VM. (I accept that using `next-line' in elisp code is not a clever thing to do, but we live in the world of "free software" where lots of people contribute.) How much elisp code might still be there that has this vulnerability? We won't know. Just as an experiment, I went to the emacs-23.2 lisp directory and did a grep for next-line. There were 91 hits. How many of them are safe? I myself noticed the changed C-n very quickly because I work with Emacs debugger a lot, where long lines are common. First I thought it was kind of cute, then I got annoyed because I had to find new ways of skipping over bytecode pieces that span lots of lines, and now I am alarmed as I think of the vulnerabilities that might exist in elisp code. If I used keyboard macros a whole lot (which I don't), then I would have been even more affected. However, it didn't occur to me that I could freely set `line-move-visual' to nil and all the problems would disappear. I thought that the setting was probably mixed up with word wrapping and visual-line-mode and all that stuff that I care about. It was only after Stefan himself said: "Yes, it's inconsistent, yes, it's a compromise, no not everybody likes it. Then (setq line-move-visual nil) in your .emacs and live happily ever after." .... only then did I understand that the emacs devs had done a completely pointless thing that I could easily revert. Cheers, Uday
From: Tim X on 7 Jun 2010 04:46 Uday S Reddy <uDOTsDOTreddy(a)cs.bham.ac.uk> writes: > On 6/6/2010 10:39 AM, David Kastrup wrote: > >> Free software is based on the premise of empowering the recipient of >> software to change and adapting it according to his own needs. >> >> Pampering to the needs of users who are not interested in changing and >> adapting the software according to their needs is not a major priority. >> >> Feel free to fork any free software which does not behave like you want >> it: you have the power. You are not dependent on upstream developers. > > Good point. But not all users have the time or the ability to do their own changing or forking or even significant customization. Allowing the *possibility* of users to change things is not the same as *expecting* them to change things. > > In this particular instance, the customization needed is not a big deal: set line-move-visual to nil. Almost everybody can do it. But the time they had to spend in discovering that they needed to change it is what has been significant. (In fact, after this thread started, I began to wonder if VM might be vulnerable to the problem as well, and went and checked if there were calls to next-line anywhere. There were three of them!) > The change was clearly documented in the NEWS file, which also explained how to restore the old behavior. Any user who upgrades to a new version and is too lazy to check the NEWS file (and the PROBLEMS file for that matter), especially after observing unexpected or different behavior gets what they deserve. Tim -- tcross (at) rapttech dot com dot au
From: Andreas Politz on 7 Jun 2010 06:21
Tim X <timx(a)nospam.dev.null> writes: > If you don't like what they have done, either > > a) get on the devel list and present a case and maybe build support > Wouldn't this contradict the cause, now that line-move-visual is the *default* ? Heh. -ap |