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 22:30:14 +1000 Organization: Unlimited download news at news.astraweb.com Message-ID: <87y6ekcu21.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> <87iq5oy7p2.fsf@lola.goethe.zz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1291840319 23734 80.91.229.12 (8 Dec 2010 20:31:59 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 8 Dec 2010 20:31:59 +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:31:55 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 1PQQg6-0004eq-M9 for geh-help-gnu-emacs@m.gmane.org; Wed, 08 Dec 2010 21:31:54 +0100 Original-Received: from localhost ([127.0.0.1]:38180 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PQQg5-0000Mp-Jx for geh-help-gnu-emacs@m.gmane.org; Wed, 08 Dec 2010 15:31:53 -0500 Original-Path: usenet.stanford.edu!news.glorb.com!news2.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:g4RK4wcqMqVHf/jExO6P+qCDyGM= Original-Lines: 44 Original-NNTP-Posting-Host: 2ea0427f.news.astraweb.com Original-X-Trace: DXC=:ZG=S^:iNclf3Y_QHDVbKhL?0kYOcDh@j5RIWMIBb; `eo0=8]>8dTXgL1o>O\n]NHbWZoP:1hcodo Original-Xref: usenet.stanford.edu gnu.emacs.help:178865 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:75985 Archived-At: Uday S Reddy writes: > On 6/12/2010 9:30 AM, David Kastrup wrote: > >> It would mean mechanically routing the developer list here. That's >> nonsensical. Anybody really wanting this sort of mixup can tell his >> newsreader to create a virtual group that does it. > > No, not really. > > The discussion that needs to be routed here is about potential changes to the > user's manual. How those changes are *implemented* can continue to stay on > the developer list. Evans suggested "RFC" which I think is a great term for > these kinds of things. > > Ideas that add bits to the user's manual can also be brought here, perhaps > selectively. For instance, there is a discussion going on there right now > about how to deliver "bidirectional text" editing, for buffers that intermix > English and Arabic, say. There are lots of tricky issues there about key > bindings and functionality. The discussion is impoverished by the dearth of > people that actually do bidirectional editing. I don't see why that > discussion could not be brought here, where there is some chance of running > into people that might actually do bidirectional editing and who might provide > valuable input. > > In any organization, virtual or real, there are decisions that should be taken > by small groups of people and there are decisions that can benefit from broad > participation. The organizations that can't figure out the difference usually > decline over time. > My only concern here is with identification of what should and should not be posted in g.e.h as well as on the developer mail list. While I think Evans suggestion is worth consideration, I still see it failing because it relies too much on everyone doing the 'right thing' and as can be seen from this discussion, knowing what is the right thing is not that straight-forward. However, discussions on possibilities are certainly worthwhile and essentila to finding the right balance. Tim -- tcross (at) rapttech dot com dot au