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: emacs 22 - regular-expression isearch on spaces extremely lenient Date: Tue, 30 May 2006 16:21:03 +1000 Organization: Posted via Supernews, http://www.supernews.com Message-ID: <87hd38hw34.fsf@tiger.rapttech.com.au> References: <2cd46e7f0604281356i582388e2kef07922b6b6a9a3a@mail.gmail.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1148971278 27874 80.91.229.2 (30 May 2006 06:41:18 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 30 May 2006 06:41:18 +0000 (UTC) Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Tue May 30 08:41:14 2006 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Fkxug-0002qj-KR for geh-help-gnu-emacs@m.gmane.org; Tue, 30 May 2006 08:41:11 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Fkxuf-00008M-KZ for geh-help-gnu-emacs@m.gmane.org; Tue, 30 May 2006 02:41:09 -0400 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!newsserver.news.garr.it!newsserver.cilea.it!univ-lyon1.fr!news.in2p3.fr!in2p3.fr!proxad.net!proxad.net!feeder1.cambrium.nl!feed.tweaknews.nl!138.199.65.86.MISMATCH!sn-ams-06!sn-xt-ams-05!sn-post-ams-01!sn-post-sjc-01!supernews.com!corp.supernews.com!not-for-mail Original-Newsgroups: gnu.emacs.help User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) Cancel-Lock: sha1:yV9XFbWieSqArcabSk/7LzrzkoY= Original-X-Complaints-To: abuse@supernews.com Original-Lines: 119 Original-Xref: shelby.stanford.edu gnu.emacs.help:139658 Original-To: help-gnu-emacs@gnu.org 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:35281 Archived-At: dkcombs@panix.com (David Combs) writes: > Emacs has been such a well incrementally-designed system (what, > 35, 40 years?) that it's been a real pleasure to use. > > What DWIM there has been of the type that when you discover > a piece, in your ordinary use of emacs, that your (well, > mine, anyway) reaction is NOT of the type: > > 1: God damn to hell -- WHY did those idiots make it do that! > > , but rather of the type: > > 2: Incredible -- this thing has not only a doctor built in to > it, but a world-class *mind-reader* as well! > > Never once have I been confronted with some surprising behaviour > that I haven't felt that it was exactly what I wanted it to do. > > ------ > > This space-->whitespaces thing seems very, very different; I haven't > seen in this thread *anyone* who'd give a type-2 (above) opinion > about this "feature", nor can I even *imagine* any normal emacs-user > who would. > > So how did this thing get included? > > Are we all subject to whatever whim that occurs to the devel-people? > > Does (gnu)=Emacs *belong* to just them -- such that whatever > *they* vote for becomes "law"? > > How many thousands, or tens (hundreds?) of thousands of people > daily use emacs, in fact *rely* on emacs for > their most important work? > > Now, maybe it's infeasible to try to get a vote from that world-user-base; > but heck, aren't there a lot of people who read this newsgroup > at least once a week? > > Why not set up a vote among all of *us* (yes, include the devel-people > too)? > > Come up with a description of this "feature" that's acceptable > to both sides on this issue, and set up some kind of a computer-based > vote. > > (To help avoidng vote-fraud, we could limit it to those who have > posted within, say, the last year or two -- and we'd suspect > funny-tricks if any voter appeared twice.) > > ----- > > We really have to have some final hurdle that any controversial > feature must pass before it gets included -- *especially* > when it's not being defaulted "off". > > I've been using emacs for *so* long (since 1980 with twenex-emacs, > rms on gnu jumping over the moon), even if not so expertly, > that this (by now) old dog's paws have a really hard time > switching now hard-wired habits and expectations. > > Seems like as good a time as any to set up a better > procedure for (thus far) few "controversial" changes. > > Just my two bits -- but I hope I'm not the only one > who feels like I do. > Just a couple of comments.... While I can appreciate where your coming from, I am not as convinced your suggestions are very practicle. As it is, a lot of debate tends to happen on the devel list prior to major changes - I'd be concerned widening that debate would result in even more difficulty in arriving at a consensus. One often sighted complaint about emacs is that it is so slow to change (something I actually like). Widening debate and input is only going to make that slower. I'm also not sure that introducing a vote on features would be a good thing. We see far too many posts to this group which contain complaints regarding some feature and all too often, those complaints are based on either ignorance or lack of familiarity with either the emacs philosophy or the emacs way of approaching a problem. It takes a while before you really begin to appreciate the power of emacs and I cannot see how we wold isolate those who just want emacs to be more like what they are already use to and those experienced enough to fully understand why some features or operations are the way they are. One thing I've always liked about emacs has been that generally, when an existing feature changes in some substantial way, there is a relatively simple way of getting the old behavior bac. Is this not the case with the new RE behavior in emacs 22? I saw a post on this list only a few weeks ago which outlined some of the benefits of the new RE behavior. Unfortunately, I cannot remember what they were, but at the time, they seemed to make sense. Without wanting to sound rude, are you certain your disatisfaction isn't merely the result of change and that the change may actually have some advantages and not be as 'ad hoc' as you seem to feel? having lurked on the develop list for a while at one time, I don't recall seeing any new feature or change of an existing feature which wasn't debated and argued over extensively. My gut feeling is that if anyone has strong enough feelings regarding how emacs should change/evolve, they really should just participate on the devel process rather than possibly muddying the waters with a lot of opinion regarding how things should be done by people who are most likely largely uninformed regarding the internals, history and limitations inherent in the code of any system with as long a history as emacs. just my 2 cnets Tim -- tcross (at) rapttech dot com dot au