From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Joseph Brenner Newsgroups: gmane.emacs.help Subject: Re: line-move-visual Date: Sat, 12 Jun 2010 13:09:54 -0700 Message-ID: <87hbl857xp.fsf@kzsu.stanford.edu> 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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1291840954 26957 80.91.229.12 (8 Dec 2010 20:42:34 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 8 Dec 2010 20:42:34 +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:42:30 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 1PQQnU-0007qc-FA for geh-help-gnu-emacs@m.gmane.org; Wed, 08 Dec 2010 21:42:29 +0100 Original-Received: from localhost ([127.0.0.1]:47705 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PQQlz-00044a-KB for geh-help-gnu-emacs@m.gmane.org; Wed, 08 Dec 2010 15:37:59 -0500 Original-Path: usenet.stanford.edu!postnews.google.com!news1.google.com!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!nntp.posted.rawbandwidth!news.posted.rawbandwidth.POSTED!not-for-mail Original-NNTP-Posting-Date: Sat, 12 Jun 2010 15:08:55 -0500 Original-Newsgroups: gnu.emacs.help User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:zrRNXax04V+Mm5gnfNrNRs2E+nI= Original-Lines: 61 X-Usenet-Provider: http://www.giganews.com Original-NNTP-Posting-Host: 198.144.208.84 Original-X-Trace: sv3-cgmgtEuTP3Ts42ZBqHv9Gt68PkE+cswZ0wVhEUMhm7/p/VZndu7oKK/NwkUM+eHo+8DAKCXfeRKYLes!iHvK1XXh7ylL6VLytuKcUfRGI7CW/DNLDIEGrnfuA5qWFXb6JGsAWuSLrXx40jYwyyrXuwquPTQ= X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 Original-Xref: usenet.stanford.edu gnu.emacs.help:178878 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:75993 Archived-At: 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. 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. 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.