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: Sun, 13 Jun 2010 11:41:58 +1000 Organization: Unlimited download news at news.astraweb.com Message-ID: <87pqzvd7yx.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> <87y6ekevet.fsf@rapttech.com.au> <87bpbgq32f.fsf@unm.edu> <87hbl857xp.fsf@kzsu.stanford.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1291831775 11357 80.91.229.12 (8 Dec 2010 18:09:35 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 8 Dec 2010 18:09:35 +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 19:09:31 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 1PQOSI-0008K4-SW for geh-help-gnu-emacs@m.gmane.org; Wed, 08 Dec 2010 19:09:31 +0100 Original-Received: from localhost ([127.0.0.1]:42494 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PQOSI-0008Hn-2C for geh-help-gnu-emacs@m.gmane.org; Wed, 08 Dec 2010 13:09:30 -0500 Original-Path: usenet.stanford.edu!news.glorb.com!news2.glorb.com!feed.news.qwest.net!mpls-nntp-07.inet.qwest.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:07I0ZINay32rTqmJ6+VfsJ2odmA= Original-Lines: 98 Original-NNTP-Posting-Host: a7ce27d3.news.astraweb.com Original-X-Trace: DXC=OeeMb:Vd6[ZkR1VMS3E6>\L?0kYOcDh@Z5RIWMIBb; `UbgIl@OC:[Y]hC7WB^JD^RSF>i434LVh5W Original-Xref: usenet.stanford.edu gnu.emacs.help:178887 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:75763 Archived-At: Joseph Brenner writes: > Evans Winner writes: >> Tim X wrote: >> | 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. >> >> Actually I think that would be a great idea -- I think >> that's exactly what ought to be done. > > Some software projects publish summaries of what's been > happening on the developers list. If you can find a volunteer > to do the job, these weekly newsletters are obviously a good > thing to have. > A good idea if someone is prepared to step up and do it. > But this isn't the solution to the problem at hand. > >> I have read a number of posts on the devel list discussing the >> question of how to communicate with Emacs users about things like >> proposed changes to defaults. > > The right answer is that you should not be changing the defaults. I tend to agree that defaults should usually not change. However, you cannot anticipate all possible situations and should avoid absolutes. Defaults should only change after serious consideration and discussion and should be as inclusive of users as possible. However, they should not be treated as sacred and can never be changed. > > If we really can't convince the developers that they need to respect > backwards compatibility, an actual solution to the problem might > be something like creating a switch that needs to be flipped on to > get the new whizzy behavior, something like: > > (setq modernize-emacs t) > > You then recommend that the default ~/.emacs for *new* users should > include that line. > > Existing users should never have their existing ~/.emacs over-written > the default, so they should only see the old behavior (unless, of > course, they choose to add that line). > > Documentation for "modernize-emacs" should make it clear that it's > under development, and that for the immediate future at least, > the behavior it imposes may change. > > Doing something like this would be far better than the current > practices, though it's obviously not perfect. Problems include: > > o A third-party developer may be suprised by the need to ask > users not to flip on "modernize-emacs", and may have to > write code to shut it off and live with some user confusion > when the "modernized" behavior goes away temporarily. > > o It's effectively a project fork that at the very least > complicates documentation and testing. > >> I agree that there is a limit to what complaining about it >> after the fact can accomplish, > > If you minimize UI changes, then these complaints are minimized. > If you eliminate UI changes, then these complaints are eliminated. Again, we need to be very wary of any absolute such as UI will never chnage or defaults can never change. We live in an environment that changes and need to be able to adapt. It would be a mistake to eliminate UI changes. There have been a number of improvements in the emacs UI over the last couple of versions. Many of htem I don't like, such as using dialog boxes for find file and yes-no questions if you use the menu etc, but many others, think they are excellent improvements that helps emacs reamin current and of interest to new developers (who are important as some of them will likely be future dev/maintainers). You also have things like the current work on bi-directional editing, which will obviously be a UI change. The developments in handling various character encodings also had some impact on the UI. Many of these were positive and some of them were important and some are necessary. 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. Tim -- tcross (at) rapttech dot com dot au