From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: storm@cua.dk (Kim F. Storm) Newsgroups: gmane.emacs.devel Subject: Re: Files in wrong subdirs of emacs/lisp? Date: 22 Dec 2003 12:00:48 +0100 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <87wu8vxtqg.fsf@emptyhost.emptydomain.de> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1072087410 1957 80.91.224.253 (22 Dec 2003 10:03:30 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 22 Dec 2003 10:03:30 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Mon Dec 22 11:03:25 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AYMuL-0002cs-00 for ; Mon, 22 Dec 2003 11:03:25 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1AYMuL-0004Ii-00 for ; Mon, 22 Dec 2003 11:03:25 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AYNqa-0002bb-Ga for emacs-devel@quimby.gnus.org; Mon, 22 Dec 2003 06:03:36 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AYNpv-0002b2-KL for emacs-devel@gnu.org; Mon, 22 Dec 2003 06:02:55 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AYNpN-0002Ti-9I for emacs-devel@gnu.org; Mon, 22 Dec 2003 06:02:53 -0500 Original-Received: from [212.88.64.25] (helo=mail-relay.sonofon.dk) by monty-python.gnu.org with smtp (Exim 4.24) id 1AYNpM-0002Sy-Go for emacs-devel@gnu.org; Mon, 22 Dec 2003 06:02:20 -0500 Original-Received: (qmail 9574 invoked from network); 22 Dec 2003 10:00:49 -0000 Original-Received: from unknown (HELO kfs-l.imdomain.dk.cua.dk) (213.83.150.2) by 0 with SMTP; 22 Dec 2003 10:00:49 -0000 Original-To: rms@gnu.org In-Reply-To: Original-Lines: 75 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:18791 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:18791 Richard Stallman writes: > We already have both pc-selection-mode and cua-mode doing the > same thing, so IMO s-region is obsolete. > > The behavior of cua-mode is very different from the behavior > of s-region, so we certainly cannot tell users "use cua mode > instead of s-region." Yes, s-region has one unique feature (compared to cua and pc-select) which is that it only shows the region highlight temporarily (for one second). But other than that, cua can be customized to just provide the same functionality as s-region and pc-selection mode. But there are some fundamental problems with s-region which make me doubt doubt that anyone is actually using it: The list of keys which are rebound by s-region is pretty short. Based on the feedback I have got from users of CUA, I believe that those who use shifted movement keys to select a region want such a mode to work for practically all commands that move the cursor, not just the very incomplete list provided by s-region.el. S-region is activated just by loading the file, i.e. it doesn't have a toggle-mode function with an autoload cookie. It works by modifying the global key bindings, and there is no way to turn it off again. This also means that if some modes redefines these keys in their local map, they lose their s-region binding (this happens for cua and pc-select as well, but at least with cua mode, this is *easy* to handle). Also s-region uses an awful method of binding all the keys that it controls to the same function (so C-h k doesn't really work). > > Would a user who uses pc-selection-mode instead of s-region > notice any differences in behavior? If so, what differences? The major difference is that with pc-selection-mode the region remains highlighted while s-region only highlights it temporarily. Also pc-selection-mode has a few more bindings to make it recognize more shifted movements. BTW, pc-selection-mode also uses a method of rebinding a lot of keys in the -mark (shifted) and -nomark (unshifted) state, e.g. S-left is bound to forward-char-mark and left is bound to forward-char-nomark. This means that it is non-trivial to add more movement commands to pc-selection-mode, as you need to write lisp code to do that. And it also repeats the doc string for each of the original commands. CUA on the other hand doesn't rebind any of the movement keys (it actually looks for the shift-modifier on user input), and it is trivial to add more movement commands to be recognized by CUA (via customize). My conclusion is that s-region, no matter how ugly it is, has a unique feature (temporary region highlighting) which may make it useful for some users. It doesn't harm to keep it, but I would still make it obsolete, as I don't think it is something we should actively spend any time on maintaining it. Actually, the temporary highlighting of the region is ortogonal to the shift region selection, so it might be useful to implement that as a general mechanism based on transient-mark-mode: We could add a transient-region-highlight-timeout setting which causes the highlighting of the region to disappear N milliseconds after the last user command (and shows the highlighting again if the mark is still active when you execute the next command). Personally, I would find that confusing though... -- Kim F. Storm http://www.cua.dk