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: Mon, 14 Jun 2010 10:46:12 +1000 Organization: Unlimited download news at news.astraweb.com Message-ID: <87d3vuo2zv.fsf@rapttech.com.au> References: <878w6vq7ew.fsf@thinkpad.tsdh.de> <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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1291842153 32596 80.91.229.12 (8 Dec 2010 21:02:33 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 8 Dec 2010 21:02:33 +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 22:02:29 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 1PQR9g-0002VB-FQ for geh-help-gnu-emacs@m.gmane.org; Wed, 08 Dec 2010 22:02:28 +0100 Original-Received: from localhost ([127.0.0.1]:43743 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PQQvN-00061V-Rh for geh-help-gnu-emacs@m.gmane.org; Wed, 08 Dec 2010 15:47:42 -0500 Original-Path: usenet.stanford.edu!news.glorb.com!news2.glorb.com!news-xfer.nntp.sonic.net!news.astraweb.com!border2.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:aqgrJF0gtmJq1q1TF9vjYdgQKlo= Original-Lines: 263 Original-NNTP-Posting-Host: c5b188c7.news.astraweb.com Original-X-Trace: DXC=hoSV>K>Mi\Cc_WgCkn9MLEL?0kYOcDh@Ji=VFiPm?<[EE^ZA\hJ`SILb3>MO4FYV[MBl>C:dXO?dG Original-Xref: usenet.stanford.edu gnu.emacs.help:178916 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor 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:76004 Archived-At: Uday S Reddy writes: > On 6/13/2010 2:41 AM, Tim X wrote: > >> Change is not the issue. Change can be positive and is necessary. The >> issue is managing that change. Any attempt to enforce a static >> unchanging environment will fail. > > You are demolishing a strawman. None of us ever said that change is > unnecessary. The thought that was in my mind when I wrote the previous > message is better expressed as follows: > 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. The implication was that because visual line mode changes the interface, the developers and maintainers were immature, inexperienced and arrogant. 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. Changing the interface is not the problem, it is how that change is implemented that is the issue. If we accept a generalisation that interfaces cannot change, we run the risk of artificially constraining possibilities and fail to focus on the important challenge of establishing processes that will allow the itnerface to develop and mature without undesirable side effects. Arguing that the interface can never change is over simplifying the situation and encourages a mindsset where change is feared and raises the real possiblity that the software will stagnate and fail to either keep pace with evolving technology or user expectations. > > In the OS & network protocols world /where Mark Crispin comes from/ things can > never change essentially. I don't disagree. Different domains have different constraints. However, just because the domain someone works in has specific constraints does not mean that those constraints should be automatically applied to other domains. > So, Mark has every right to blow up when things have changed essentially. > Emacs devs needed that lesson and, judging from Stefan's last post, I think > they continue to need it. Do you disagree? (Don't be too focused on surface > niceties and etiquette and all that. Different people have different ways of > expressing themselves. The substance is what matters in the end.) I have stated repeatably that I agree that making visual line mode the default was a mistake. I also agree that the maintainers probably need to create better channels of communication to get more feedback from end users. I totally disagree with the arguments that introduction of visual line mode was a mistake. I totally disagree with the persoanl attacks on the developers and insinuations regarding their maturity, competance and experience and charges of arrogance. I totally disagree with absolutes such as interfaces should never change and defaults should never change. I do accept that interfaces should be treated in a very conservative manner and that any change should be considered extremely carefully. I even have trouble coming up with an example that wold support changing of defaults. However, I see a big difference between saying that we should be very conservative regarding change in these areas and saying that these areas should /never/ change. I expect some will respond with "well yes, there are exceptions where change would be OK if blah blah" etc and "you are being too literal, there are always exceptions to the rule" etc. In which case, I would say that it is better to be clearer regarding what is meant. Avoid setting up 'rules' that deal in absolutes which distract from core issues and create false constraints. Say that interfaces and defaults should be treated extremely conservatively and should not change without clear justification. Once we accept that change is possible in this respect, we can then focus on how to assess when a change to the interface is justified, how such changes should be implemented, how end users should be consulted and how to roll the change out. Denying that change is possible means that we don't properly consider the implications of the change and don't establish propper processes for dealing with it. [snip] > In the Emacs world, it is easy to think that we are delivering services to the > human user, who is clever enough to figure things out. Emacs is a /text > editor/ after all. So, change is ok. But the problem is that Emacs is not > just a text editor any more. Unbeknownst to the developers, or perhaps even > known to them in some instances, it is being used as a critical system > component in other applications or services. Emacs has certainly earned the > right to be such a component. It is some 30-40 years old. Its core is rock > solid. Who has ever had a file corrupted by Emacs? (On the other hand, I > have had files corrupted by file servers sold by even reputable > companies.) I have had files currupted by emacs and I have had files currupted by VM. In both cases, they were bugs in production versions. However, given that I've been using emacs pretty much all day, everyday for 15 years, I do consider it very stable. > We use Emacs for email in VM, which I regard as mission-critical, because all > hell can break loose if a mail folder gets corrupted or somebody can't read > their email. We regularly use Emacs to develop code with all kinds additional > functionality from editing modes and interfaces to code repositories. If > something goes wrong there, other developed software can break, with untold > consequences. I have had VM fail on a number of occasions and have had it currupt my mail folder at least once. Yes, it has been mostly very stable and reliable. However, problems/bugs do occur regardless of how mission critical you assume it is. Likewise, you cannot make assumptions regarding how mission critical developers view a system based on a bug or single decision. > I am dying to figure out what application Mark Crispin is > putting Emacs to that makes it so hard for him to accommodate the > line-move-visual change. To be honest, while I believe Mark raised a valid issue regarding visual line mode being the default, I think he over reacted and his somewhat personal attacks on the emacs developer community only distracted form the important issues he raised. There have been a couple of suggestions regarding how he can work around the issue, which he does not seem to respond to and I suspect that he may be "throwing the baby out with the bath water". > So, changes that can potentially break things are > *not* ok. Sounds nice, but the reality is that any change can potentially break things. We can certainly establish processes that help mitigate this. However, we need to first accept that change is possible and sometimes needed in order to then establish these processes. This is why I reject the claim that the interface should never change and/or defaults should never change. > We don't have to be as diligent as the on-board kernel hackers, but > we certainly have to be a lot more careful than we seem to be at the moment. > Emacs devs have to grow up into this real world. I still think this is all being wildly over stated. We are talking about one change largely implemented by one developer. We cannot make assumptions about all the developers and what they do or do not need based on a single change. Consider the substantial interface changes that have occured between emacs 22 and emacs 23. Given how stable emacs has remained despite all these changes, I would suggest the developers need to be congratulated for doing an excellent job. There has been a lot of theorizing about how badly visual line mode will break things, but I've not actually seen much evidence of people who are using visual line mode experiencing problems. Furthermore, if you disable visual line mode, the impact is absolutely nil. The issue is not that visual line mode was a mistake, but rather that it was introduced as a default and that implications of doing so were not well thought out, especially with respect to keyboard macros etc and that this change in default was not adequately communicated. > > Changing the meaning of next-line has consequences far beyond what the Emacs > devs have been able to grasp. I have mentioned previously that I found three > calls to `next-line' in VM. They were not in VM core, in third party > contributions, but try telling that to somebody whose mail folder gets > corrupted! Emacs devs might say one should never have used `next-line' in > elisp code, but that is not really good enough, is it? Emacs manual never > said one *must not* use next-line in elisp code. It only said that there are > better ways of doing it. So, an elisp programmer cannot be faulted for using > next-line'. > [snip] > > Imagine what I have to say in the next release notes of VM: "Emacs 23 has > introduced an incompatible change to the meaning of `next-line' which can > cause folder corruption. This release of VM is the first safe version of VM > for use with Emacs 23". This doesn't stop other users still using older > versions of VM from facing folder corruption. Nor will it stop some > downstream distribution from packaging an old version of VM with the later > version of Emacs. Is that the kind of situation we want to be in? There is nothing new here. We have always been in this position. Look at the emacs NEWS files. They contain a section on incompatible lisp changes. There is always the potential for existing packages to break with new versions of emacs and it isn't uncommon for packages to need changes in order to work with a new major version. I also think your over stating the situation. The potential problem only occurs if you enable visual line mode. > > Stefan says, perhaps half-jokingly, that he never uses Emacs while being root. > Does RMS think the same? Do all the trustees of FSF accept that Emacs is > unfit to be used while being root? What other Gnu software is similarly unfit > to be used as root? Mark Crispin's criticism has to be taken seriously, even > if it comes with a heavy dose of vitriole, because he is a top-level systems > programmer who knows better. Mark's criticism regarding visual line mode being the default is valid. His heavy does of vitriole against the whole emacs developer community is not. As I don't know him and have not worked with him, I cannot judge his credentials as a programmer and would never presume to do so. > > When you say that this change has been around for a year and no complaints > were raised, you are not being clear about how software changes are > propagated. It takes years for changes to go through the pipeline of > downstream distributions and even longer for users to upgrade their systems. > Smart users who want to play safe are always careful to let the dust settle > before upgrading. Our local sys admins haven't even installed Emacs 23.1 yet > on our departmental machines. That will probably happen during this summer. > If I was a normal user, rather than a developer, I would have probably taken > an additional year or so to make the switch. So, these late complaints are > the most important ones. They come from the more serious and conservative > users. Emacs devs are going to have to face the heat for quite a while to > come. > That is a fair point. However, I would also suggest that many of the experienced and active users are also the first ones to adopt or trial emacs versions. At work, I run emacs 23.1. However, at home and for most of my personal development work, I run the latest development system, which I upgrade at least once a week. > Mark Crispin is not satisfied with Stefan's response. Neither am I, to tell > you the truth. When says, "Given the reactions we've seen since Emacs-23.1 > was released, I don't regret the decision", he is indicating that he is happy > to play to the gallery, and quite an uninformed gallery at that. 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. If this is the measure of support needed > to introduce incompatible changes in Emacs, then Emacs does seem to be in > trouble! > 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. There are two issues I am aware of where it appears there has been a lack of in-depth analysis. The first and I think most serious is the impact of visual line mode on existing saved keyboard macros. More thought is required in this area. Personally, I would be inclined to somehow restrict macros in such a way that they won't work if the buffer is in a different line mode to the one it was in when the macro was defined. The second issue, which /may/ be a problem is the impact of next-line in packages people use while also using visual line mode. I would suggest that both of these are enough justification for not setting visual line mode as the default - at least not yet. It definitely should have been introduced as an optional non-default feature. Tim -- tcross (at) rapttech dot com dot au