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: Sat, 12 Jun 2010 14:18:02 +1000 Organization: Unlimited download news at news.astraweb.com Message-ID: <87y6ekevet.fsf@rapttech.com.au> References: <87pr07qjio.fsf@thinkpad.tsdh.de> <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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1291840186 22929 80.91.229.12 (8 Dec 2010 20:29:46 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 8 Dec 2010 20:29:46 +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 21:29:42 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 1PQQdy-0003Y1-Df for geh-help-gnu-emacs@m.gmane.org; Wed, 08 Dec 2010 21:29:42 +0100 Original-Received: from localhost ([127.0.0.1]:35839 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PQQdx-0007XV-RD for geh-help-gnu-emacs@m.gmane.org; Wed, 08 Dec 2010 15:29:41 -0500 Original-Path: usenet.stanford.edu!news.glorb.com!news2.glorb.com!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:jdKS5A0aYLSc+2bZ738JvNJCGBA= Original-Lines: 131 Original-NNTP-Posting-Host: d106a769.news.astraweb.com Original-X-Trace: DXC=FX0VHW<@\Mjfj0fd2JZgghL?0kYOcDh@ji=VFiPm?<[e5IU5<O\n]NHbP4Y[92l[Sgc Original-Xref: usenet.stanford.edu gnu.emacs.help:178849 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:75981 Archived-At: Mark Crispin writes: > On Thu, 10 Jun 2010, Uday S Reddy posted: >> By community ownership, I only mean that all the people that have a stake in >> the system have a voice in the matter and we all feel ownership of the >> system. When the community is divided, as seems to be the case on this >> issue, the developers have to make a decision and move on. > > The problem is that nobody ever asked the existing users whether or not they > wanted this global change foisted upon them. Rather, it was done > unilaterally, and the individuals responsible are saying "See! Some people > like it! It was a good change." > This is not really correct. The change was discussed in a forum that is open to anyone who is interested. More accurately, a criticism could be that it wasn't discussed in the correct forum. However, that in itself is extremely difficult to identify. For example, how would most of the users feel if every discussion regarding emacs development, even if restricted to discussions that directly impact on basic/core behavior (however that would be defined). was posted to this list? I suspect that many would be irritated as this is supposed to be an emacs help forum, not a discussion forum for developments. A possible solution would be to ensure a page is maintained on the emacs wiki that discussed some of the proposed developments, especailly those that may be contentious. A regular post could go to this list pointing to the relevant page. This would possibly let those who are interested know about propsed changes and enable them to participate. Of course this won't reach everyone and there will still be some who are surprised by changes and possibly get upset. This is unavoidable. All that can be done is to make it clear what forums are available and try harder to get wider discussion, particularly with changes that are likely to have a big impact. > This sort of thing happened in the past as well. The difference was that > there was accountability in the past that is absent today. > >> In my humble opinion, it is easy to argue that the current default was >> ill-chosen. But it is not so easy to argue that it should be changed. If >> we change it, then we face all the same issues all over again affecting the >> other users that are depending on the current default. So, it seems best to >> leave things as they are and make a note of all the lessons learned. > > I agree that we are probably screwed, and royally so. > > I have a new task on my list: replace emacs in the procedures for my target > audience since emacs is no longer suitable for that purpose. I simply can not > tell these users "make sure that you set line-move-visual to nil"; they would > have no clue what that means. More likely than not, I will end up being > obliged to write a program for the task; and there will be one less way those > users will be exposed to emacs. > Why not just set it back to its previous default in a site startup file? Most distributions already have one of these - all that is required is a single line! > One of the advantages of the "software tools" mindset of the past was that you > did not have to write a program for every task. Instead, you could leverage > the existing tools. That falls apart when those tools are corrupted so that > they no longer can be relied upon to produce predictable results. > >>> But even the laymen become power-corrupted. >> I think that is a bit of an exaggeration. They have a responsibility to >> bear and sometimes they get carried away. > > Every young programmer wants to put his own mark on things. The problem is > that these changes are frequently ill-considered and sometimes have bad > consequences. > Even well considered changes can have bad consequences. Hindsight is a wonderful thing! This personal attack you continue to make on the developers is very tiresome. Emacs is developed by a large range of people. They vary in age, vary in location and native language and vary in experience. Not many of them are regular posters to this list. You seem to be under the illusion that the developers are some closed powerful group sitting in a room somewhere together making random changes. GNU Emacs is open to anyone who wants to get involved. Patches and improvements come from all over the place - some are minor, some are major, some accepted and some rejected. Changes are discussed in an open forum that anyone can participate in. Valid points have been raised regarding the change in default behavior and possibly the developers may consider ways to improve discussion and communication (though I'm not sure how aware they are since this discussion has occured largely on the wrong forum). Nothing is gained by continued attacks. If you still feel the need to whinge, then perhaps you might show the backbone to actualy make your accusations to the developers and perhaps both get some real facts and just possibly contribute to improving how future changes are handled. >>> Since user interface surprise is a barrier to upgrade, they make sure there >>> aren't any such surprises. >> Yes, that point is well-made. But, the same argument now suggests that the >> default should not be changed yet again. > > Yup. We're probably screwed. > Your arguments all suggest an environment where interfaces never change. This just doesn't exist and never has. Frequently improvements and new functionality require changes to existing interfaces, both programming and user. This is the reason most programs have a major and minor revision number. It gives an end user an idea of how the program may have changed. It is also why any professional setup will put new software through evaluation and testing before putting it into production. This can result in considerable maintenance overheads, but cannot be avoided. It is also why many vendors, such as Red hat and Ubuntu provide versions that are extremely stable and supported for extended periods of time where the only changes/updates are for critical security fixes. As a professional, I'm sure, when deciding to upgrade a major version of some key software, you checked out the release notes to familiarise yourself with what has changed and any known problems and used this information to formulate your test plan that wold ensure no nasty surprises in your production environments. Luckily, the emacs developers made sure this was all clearly documented and where the changes involved modified defaults, clearly explained how to reset tot he previous default. Tim -- tcross (at) rapttech dot com dot au