From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: Why act from point forward by default, instead of whole buffer? Date: Mon, 24 Sep 2007 11:55:30 -0700 Message-ID: References: <46512.128.165.123.18.1190655725.squirrel@webmail.lanl.gov> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1190660243 19419 80.91.229.12 (24 Sep 2007 18:57:23 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 24 Sep 2007 18:57:23 +0000 (UTC) Cc: Emacs-Devel To: Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 24 20:57:19 2007 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.50) id 1IZt7H-0003TF-Lq for ged-emacs-devel@m.gmane.org; Mon, 24 Sep 2007 20:57:11 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IZt7E-00068H-U0 for ged-emacs-devel@m.gmane.org; Mon, 24 Sep 2007 14:57:08 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IZt7C-00066v-3J for emacs-devel@gnu.org; Mon, 24 Sep 2007 14:57:06 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IZt7B-00066C-HZ for emacs-devel@gnu.org; Mon, 24 Sep 2007 14:57:05 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IZt7B-000667-7i for emacs-devel@gnu.org; Mon, 24 Sep 2007 14:57:05 -0400 Original-Received: from rgminet01.oracle.com ([148.87.113.118]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IZt7A-0004mM-GH for emacs-devel@gnu.org; Mon, 24 Sep 2007 14:57:04 -0400 Original-Received: from agmgw1.us.oracle.com (agmgw1.us.oracle.com [152.68.180.212]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id l8OIuut7024430; Mon, 24 Sep 2007 12:56:56 -0600 Original-Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by agmgw1.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id l8OGDgM6005198; Mon, 24 Sep 2007 12:56:55 -0600 Original-Received: from dhcp-4op11-4op12-west-130-35-178-158.us.oracle.com by acsmt350.oracle.com with ESMTP id 3240210761190660128; Mon, 24 Sep 2007 11:55:28 -0700 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <46512.128.165.123.18.1190655725.squirrel@webmail.lanl.gov> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-Detected-Kernel: Linux 2.4-2.6 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:79747 Archived-At: > > General question that occurred to me while reading thread > > "keep|flush-lines, how-many to be used backward": What is > > the advantage of having such commands (`keep-lines' and many > > others) act, by default, from point forward instead > > of (by default) on the entire buffer? > > > > They do act on the region, if it is active, so that's good. > > But why not have the entire buffer be the default if the > > region is not active? I use that behavior for many commands > > I define. > > Not everyone uses Transient Mark mode. If they acted on the whole buffer, > you would have to use narrowing to restrain them in any way. By acting > forward, one common case can be handled with no prefix, and the whole > buffer with just M-<, and narrowing (again) otherwise. Good point. So the current behavior is there to fit the default behavior of not having transient-mark mode on. We should change the default anyway, so transient-mark mode is on. We've discussed that before, but the battle has not yet been won. After it is, perhaps we can revisit this question, since the only reason given (so far) for this behavior is to fit non-transient-mark mode.