From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: delete-selection-mode (was: Put scroll-bar on right by default on UNIX.) Date: Sat, 20 Mar 2010 01:37:09 +0900 Message-ID: <87d3z0i7yi.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87ocitw2dl.fsf@stupidchicken.com> <201003130001.o2D01FFQ003489@godzilla.ics.uci.edu> <87vdd1yqe4.fsf@stupidchicken.com> <87eijjzrkd.fsf_-_@mail.jurta.org> <20100317143519.GB4381@muc.de> <87vdcui6oh.fsf@uwakimon.sk.tsukuba.ac.jp> <20100318101223.GB2704@muc.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1269017461 20660 80.91.229.12 (19 Mar 2010 16:51:01 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 19 Mar 2010 16:51:01 +0000 (UTC) Cc: Juri Linkov , Chong Yidong , Dan Nicolaescu , emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 19 17:50:56 2010 Return-path: Envelope-to: ged-emacs-devel@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 1NsfPN-0006zX-A2 for ged-emacs-devel@m.gmane.org; Fri, 19 Mar 2010 17:50:49 +0100 Original-Received: from localhost ([127.0.0.1]:55330 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NsfPM-0000WW-GL for ged-emacs-devel@m.gmane.org; Fri, 19 Mar 2010 12:50:48 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NsfDE-0004Tf-39 for emacs-devel@gnu.org; Fri, 19 Mar 2010 12:38:16 -0400 Original-Received: from [140.186.70.92] (port=44647 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NsfDC-0004S1-Im for emacs-devel@gnu.org; Fri, 19 Mar 2010 12:38:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NsfD7-0008Hq-3m for emacs-devel@gnu.org; Fri, 19 Mar 2010 12:38:14 -0400 Original-Received: from mtps01.sk.tsukuba.ac.jp ([130.158.97.223]:36578) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NsfD6-0008Hf-Jx for emacs-devel@gnu.org; Fri, 19 Mar 2010 12:38:09 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps01.sk.tsukuba.ac.jp (Postfix) with ESMTP id 3F5111535AE; Sat, 20 Mar 2010 01:38:06 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id A2D6F1A3800; Sat, 20 Mar 2010 01:37:09 +0900 (JST) In-Reply-To: <20100318101223.GB2704@muc.de> X-Mailer: VM 8.0.12-devo-585 under 21.5 (beta29) "garbanzo" a03421eb562b XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:122289 Archived-At: Alan Mackenzie writes: > Clearly the convenience benefit dominates for you; the accidental > explosion hazard dominates for me (in non-Emacs environments, where I > can't disable the (mis)feature). I've no reason to suspect I'm unusual > here. I'm sure you're not. After all, I had exactly that experience ... for about three days. Note that in many non-Emacs environments, you also don't have decent undo. > It's "obviously" useful to be able to type extra text into an already > "existing" region. The region is used for many things other than just > being deleted. Could be, but I almost never use the region that way myself, and when I do, C-x C-x does what I need (I don't need a visible region for that use case, personally). > Do they? How do we know there aren't lots of "veteran" users who don't > really know how to configure the thing? Come now; if you're going to insist on being different to teach newbies to use Emacs effectively, shouldn't that apply all the more to using help and changing defaults for veterans? > I think we should also distinguish between pure new UI features, and > those that actively interfere with established usage. My view is that we > should never make something default in Emacs if it's likely to provoke > the angry reaction "How do I disable this *!=A3$ing thing?". > delete-select-mode falls into this latter category. So does > transient-mark-mode. Guess what? XEmacs did that experiment with zmacs-regions (~ t-m-m) almost 15 years ago. Oh, there was whining, and there was screaming, and there were predictions of The Imminent End of the World as We Know It (with which I quietly agreed). But the switch was flipped, zmacs-regions was made true by default, and you know what? *Nobody noticed!* Some experienced users switched (as I did). Many turned it off in their init file. The key is that nobody complained that they gave it a real chance and still it sucked. Since then there has been no question in my mind that changing defaults is definitely an implement we should have in our toolbox. > Is there any evidence that delete-select-mode is instrinsically a good > thing, disregarding the fact that it has become common? My personal experience. I really didn't like it in theory, I found it irritating in practice, but having given it a serious try, I now like it, and miss it when I'm borrowing somebody's Emacs or something. > Where is the proof that d-s-m has proven itself efficient, rather than > being mainly an irritation? That's a genuine question, not a rhetorical > one. The proof of this pudding is in the eating. It worked very well for XEmacs with zmacs-regions, and even Richard now uses t-m-m. I don't know if it will work as well for delsel. > One reason people might have come to Emacs is to escape the (to them) > deity-awful key sequences they've been forced to use up to now. It is > surely good to offer them an alternative. Of course it's good to offer alternatives. Whether that alternative should be default or alternative option is an empirical question. The only way to really find out is to try it, *as default*. If you see some significant fraction of experienced users switching to the default and none saying "I tried it and it sucked", it's probably a good idea.