From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tim X Newsgroups: gmane.emacs.help Subject: Re: line-move-visual Date: Tue, 15 Jun 2010 19:20:16 +1000 Organization: Unlimited download news at news.astraweb.com Message-ID: <87d3vs4ppr.fsf@rapttech.com.au> References: <871vcmhq79.fsf@wivenhoe.ul.ie> <580d5f23-e251-483f-9752-7e77b1ca2fb7@40g2000pry.googlegroups.com> <2a7dc148-e2cc-4681-9d8c-ccd1140aa6d7@j36g2000prj.googlegroups.com> <089883ee-0a63-4cb4-a0ec-d2fe4e71cc03@y18g2000prn.googlegroups.com> <87wruco5yq.fsf@lola.goethe.zz> <87wrubfd8p.fsf@rapttech.com.au> <848w6ndwn0.fsf@cs.bham.ac.uk> <87y6ekevet.fsf@rapttech.com.au> <87bpbgq32f.fsf@unm.edu> <87hbl857xp.fsf@kzsu.stanford.edu> <87pqzvd7yx.fsf@rapttech.com.au> <87d3vuo2zv.fsf@rapttech.com.au> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1291835145 29117 80.91.229.12 (8 Dec 2010 19:05:45 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 8 Dec 2010 19:05:45 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Wed Dec 08 20:05:40 2010 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PQPKc-0006cR-Dt for geh-help-gnu-emacs@m.gmane.org; Wed, 08 Dec 2010 20:05:39 +0100 Original-Received: from localhost ([127.0.0.1]:41043 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PQPKb-0005GX-Eu for geh-help-gnu-emacs@m.gmane.org; Wed, 08 Dec 2010 14:05:37 -0500 Original-Path: usenet.stanford.edu!news.glorb.com!news2.glorb.com!news.glorb.com!news.astraweb.com!border1.newsrouter.astraweb.com!not-for-mail Original-Newsgroups: gnu.emacs.help User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:/HZxg58JGo5yp2j1Fq3wkv5TFdQ= Original-Lines: 231 Original-NNTP-Posting-Host: ec180751.news.astraweb.com Original-X-Trace: DXC=X<`lZ; CG[lRLZ1S List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:75853 Archived-At: Uday S Reddy writes: > On 6/14/2010 1:46 AM, Tim X wrote: > >> Not at all. It was suggested that mature reliable software that is >> maintained by competant, mature and experienced programmers /never/ >> changes its interface. This implies that change is not only unnecessary, >> but cannot occur in a mature system.... I reject this assertion that >> interfaces cannot change and that any change in an interface >> automatically means the software is immature, unreliable and/or >> maintained by incompetant developers. I would go further and argue that >> in some situations, changing the interface is actually the correct and >> responsible thing to do. > > Sorry, Tim. Your rejection would carry some weight if you mentioned the > situations where changing the interface is "the correct and responsible" thing > to do. > > You also seem to believe that the `line-move-visual' issue did not present > such a situation where changing the interface was the correct and responsible > thing to do. So, I am not sure what your point is, other than providing some > political support to the developers. > OK, fair criticism. I have muddied the waters too much by trying to address to many issues in a sigle thread. I should probably have put things in different threads to avoid confusion. I also should have been more careful with some terminology and phrasing. I will attempt to clarify. The issues I've tried to address are 1. The suggestion that interfaces for mature software packages never change and that such change means the software is immature or poorly maintained. 2. The issue of line-move-visual and whether it in itself is a bad idea or whether the way it was implemented was a mistake 3. The frequently personal, overly general and somewhat arrogant criticisms of emacs maintainers based largely on unsubstantiated assumptions. 1. While we would like to believe interfaces of mature software packages never change, this simply isn't reality. If it were, we would always have backwards compatibility, which we don't. Likewise, it would not be necessary for programs to use version numbering schemes that incorporate this information. For example, the Apache scheme uses a format of 'x.y.z' where 'x' indicates significant interface changes that are not backwards compatible, 'y' indicates a version with interface changes that are extensions and are backwards compatible and 'z' indicates a patch. In this context, interface can refer to either API changes or UI changes. While I cannot think of specific examples of interface changes in emacs, I can certainly recall changes in many other mature packages. For example, Apache has changed the interface for external modules, Java has changed its interface for core classes, Microsoft has changed some of its low level OS interfaces, breaking backwards compatibility for 16 bit programs and Linux has changed its interface in a number of areas. With this last one, I have run into issues with a driver I used to use that is no longer compatible with current 2.6.x kernels. I have maintained that interface changes are not something that should be done unnecessarily. The interface should be treated conservatively and changes should be avoided where possible. However, I think it is a mistake to ignore or deny the possibility of interface change because doing so results in failing to understand and consider the consequences. This is necessary to know how to properly manage such changes and minimize impact. It is also necessary because different domains have different requirements and constraints. For these reasons, I reject blanket statements that say the interface of mature software packages must never change. > Regarding your questions, yes, I do regard /all/ changes to *existing* > behavior of mature software systems as bad. Under exceptional circumstances, > they could be the *lesser evil* and then we accept them as being unfortunately > necessary. > Right. However, this doesn't fit with the claim of /never/ changing or with the simplistic view that a change in interface indicates software that is immature. > This does not mean that you can't add new features or extend the existing > behavior. Extend it as much as you please, without changing what already > exists. > Agree. Extension is not what I would call change as it doesn't usually affect backwards compatibility. However, in some cases, most notably user interfaces, extensions and enhancements can be seen as a change that breaks backwards compatibility because it modifies the interface to such an extent that the user feels they no longer recognize it or know how to use the system despite the fact core operations and APIs have not been modified. However, this is an edge case. Adding functionality etc usually doesn't have the level of impact as modifying what already exists. > The Emacs NEWS file currently does not make any distinction between *changes*, > meaning changes to the existing behavior, and *extensions* (or improvements or > new features). All of them are generically labelled as "Changes" (meaning > changes to the software system, not changes to the behavior of features). > This is probably a hangover from the time when the file might have been called > a ChangeLog, rather than NEWS. Please don't confuse "changes" in this generic > sense to be actual changes. > Hmmm, I don't think I agree. While it could be possible to improve the labelling, its nowhere as bad as you indicate. Here are the top level headings from the current NEWS file for the dev version (these basic headings have been in all the NEWS files I've seen for the past 15 years) * Installation Changes in Emacs 24.1 * Startup Changes in Emacs 24.1 * Changes in Emacs 24.1 * Editing Changes in Emacs 24.1 * Changes in Specialized Modes and Packages in Emacs 24.1 * New Modes and Packages in Emacs 24.1 * Incompatible Lisp Changes in Emacs 24.1 * Lisp changes in Emacs 24.1 * Changes in Emacs 24.1 on non-free operating systems >> That isn't how I interpreted Stefan's response at all. My interpretation >> was that he believes, based on feedback, that many users found visual >> line mode a beneficial new feature, but he acknowledges that it hasn't >> come without some problems. >> >> I don't understand why you are asking if C-n should move by logical line >> or visual line in logical line mode. Isn't this what the difference is >> between the two modes? In logical line mode, the behavior is exactly the >> same as it has always been - C-n moves by logical line. In visual line >> mode, it moves by visual line. I don't see any issue here and there is >> no evidence anywhere that I am aware of that proposes any changes to >> line movement when not in visual line mode. > > These two paragraphs suggest that you don't really know what the issue is. > Perhaps you should read the manual sections on line-move-visual and > visual-line-mode and try them out before discussing them? > That was poor expression and haste on my part. I meant line-move-visual and not visual-line-mode. I suspect the confusion is with the general use of 'mode' and the emacs specific definition of a buffer mode. After what you wrote, I thought it would be a good idea to check my facts and experiment a bit. My understanding wasn't too far off the mark. I would suggest you have a look at the code for visual-line-mode as it uses line-move-visual - essentially, setting it to t locally in the buffer when you turn the mode on. If it was nil before starting visual-line-mode, it sets it back to nil when you turn off the mode. So, it seems that visual-line-mode uses line-move-visual to alter the next line/previous line definitions when in visual line mode. I still don't understand the question you referred to when you wrote "When I asked "do you want C-n to move by logical line or visual line in the logical line mode", the gallery has been silent." Perhaps I don't understand what you mean by logical line mode. My interpretation was that logical line mode referred to what some would call the 'traditional' default mode that emacs had until v23 i.e. C-n and Cp moved to the next and previous lines where a line would be defined by standard eol characters. If you had line wrap on for a long line that filled 10 visual lines in your window, a single C-n would move down to the 11th visual line i.e. C-n moves to next logical line. In visual line mode or with line-move-visual enabled, C-n would move to the second visual screen line i.e. you would have to do multiple C-n to get past the 'logical line'. For convenience of argument, since visual line mode uses line-move-visual, lets just call it visual line mode. Noting that I expect all the possible problems that line-move-visual would cause with macros will also exist if you are using visual line mode as they both redefine the movement semantics in the same way. >From this perspective, for me, the semantics of the movement keys are what determine which mode you are operating in. It makes no sense to ask if C-n should move by logical lines or visual lines in logical line mode because moving by logical lines is what defines logical line mode. If you move by visual lines, your not in logical line mode, your in visual line mode (using the term mode in its general sense, not its emacs sense). So, I still don't understand your question and I suspect I'm not alone. This could explain the lack of response to your question and provides an alternative to your rather negative and somewhat arrogant assertion regarding an 'ill informed gallery'. A failure to illicit a response to a question can easily be due to the way it is presented and does not in itself tell you anything about the audience. To again make my position clear. I believe that setting line-move-visual to t by default was a mistake. I believe the introduction of the ability to change the semantics of line movement is a good addition, despite some of the negative consequences and the fact that I think there is still some work to be done to handle things like macros in a reliable consistent manner. This ability to change the movement semantics has enabled improved support for a number of activities, many of which have been mentioned elsewhere in this thread. I agree that its introduction does come with some pain, but I think its worth it. From a theoretical basis, I can see where some of the concerns are coming from, but I've yet to hear of an actual example where the change has caused the cataclysmic disasters that have been predicted. I think despite some valid points, things have been over stated. Which brings me to my final issue and the one that actually dragged me into this thread. The arrogance, derogatory comments about the emacs maintainers, sweeping generalizations and assumptions regarding everything from their personal motivations, experience, egos and even age has been quite outrageous. Arrogant claims of teaching them lessons and demands for more accountability etc have been over the top and all of this due essentially to one poor decision to change the default behavior. There has been no recognition for all the recent improvements in font handling, support for GTK, dbus, etc, X window support enhancements, emacsclient improvements, improved and extended support for different character encodings, support for larger buffers and much more. I'm quite amazed at the development and improvements we have been seeing. Remember how slow it was to go from emacs 20 to 21? Remember the constant frustrations of an emacs that frequently ran into limitations that other systems didn't experience? I think the work that has been done over the last few years has been quite remarkable. > > I hope you understand the issue better now. If you still think this is an > acceptable change, let us know. I understood it before, thank you master! I hope you now understand my position better! Tim -- tcross (at) rapttech dot com dot au