From: Tim X <timx@nospam.dev.null>
Subject: Re: emacs 22 - regular-expression isearch on spaces extremely lenient
Date: Tue, 30 May 2006 16:21:03 +1000 [thread overview]
Message-ID: <87hd38hw34.fsf@tiger.rapttech.com.au> (raw)
In-Reply-To: e5gkhb$2so$1@reader1.panix.com
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
next prev parent reply other threads:[~2006-05-30 6:21 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <2cd46e7f0604281353l38f7672gd3cfe0c64fdf0cb4@mail.gmail.com>
2006-04-28 20:56 ` emacs 22 - regular-expression isearch on spaces extremely lenient Ken Manheimer
2006-04-29 14:41 ` Drew Adams
2006-04-29 17:23 ` Eric Hanchrow
2006-05-01 14:51 ` Kevin Rodgers
2006-05-02 2:04 ` Richard Stallman
2006-05-01 18:04 ` ken manheimer
2006-05-01 18:44 ` emacs 22 - regular-expression isearch on spacesextremely lenient Drew Adams
[not found] ` <mailman.1189.1146507010.9609.help-gnu-emacs@gnu.org>
2006-05-30 5:17 ` emacs 22 - regular-expression isearch on spaces extremely lenient David Combs
2006-05-30 6:21 ` Tim X [this message]
2006-05-30 8:31 ` David Kastrup
[not found] ` <mailman.1109.1146290553.9609.help-gnu-emacs@gnu.org>
2006-04-29 7:47 ` Miles Bader
[not found] <mailman.1118.1146321681.9609.help-gnu-emacs@gnu.org>
2006-04-29 15:16 ` don provan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87hd38hw34.fsf@tiger.rapttech.com.au \
--to=timx@nospam.dev.null \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).