From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: transient-mark-mode in 22.0 Date: Sun, 12 Jun 2005 12:09:38 -0400 Message-ID: <87vf4j8t7k.fsf-monnier+emacs@gnu.org> References: <1118265475.26257.16.camel@turtle.as.arizona.edu> <1118339690.31013.16.camel@turtle.as.arizona.edu> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1118592391 9520 80.91.229.2 (12 Jun 2005 16:06:31 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 12 Jun 2005 16:06:31 +0000 (UTC) Cc: emacs-devel@gnu.org, JD Smith Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jun 12 18:06:21 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DhUyQ-0006LM-GH for ged-emacs-devel@m.gmane.org; Sun, 12 Jun 2005 18:06:10 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DhV32-0005hd-Hz for ged-emacs-devel@m.gmane.org; Sun, 12 Jun 2005 12:10:56 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DhV2p-0005g1-4w for emacs-devel@gnu.org; Sun, 12 Jun 2005 12:10:43 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DhV2m-0005eV-HU for emacs-devel@gnu.org; Sun, 12 Jun 2005 12:10:40 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DhV2m-0005dt-7G for emacs-devel@gnu.org; Sun, 12 Jun 2005 12:10:40 -0400 Original-Received: from [209.226.175.4] (helo=tomts16-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DhV2f-0004u6-UG; Sun, 12 Jun 2005 12:10:34 -0400 Original-Received: from alfajor ([70.48.82.205]) by tomts16-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20050612160940.NEZO27508.tomts16-srv.bellnexxia.net@alfajor>; Sun, 12 Jun 2005 12:09:40 -0400 Original-Received: by alfajor (Postfix, from userid 1000) id 03333D73D3; Sun, 12 Jun 2005 12:09:38 -0400 (EDT) Original-To: rms@gnu.org In-Reply-To: (Richard Stallman's message of "Fri, 10 Jun 2005 18:37:34 -0400") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) 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:38643 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:38643 > To fix this problem, I maybe mouse-show-mark should be rewritten to > not use (read-event), but instead to use something like > pre-command-hook. > I think that is too risky. The reason this code has some bugs > is that there is no obvious simple rule for what it should do. > I could only patch it case by case, as various cases showed up > that did not work. > If you rewrite it to work differently, you'll have to start this > process from scratch, which means it will be more unstable than > it is now. No, the current code and the change-log-trail make it pretty clear what the function is meant to do: 1 - preserve the mouse-drag-overlay highlighting until the "next" command, where things like scrolls and switch-frames aren't considered real commands. 2 - implement the mouse-region-delete-keys functionality. The problem is that the loop that does read-event/key-binding/call-interactively basically can't be reliably re-implemented in elisp. That's why a solution using pre-command-hook would probably be more reliable. > if the event is `switch-frame', we'll do a key lookup for > [vertical-scroll-bar switch-frame] which of course will fail. > Does that lead to the wrong results? It don't know of any bug it introduces but since it fails to call handle-switch-frame at the proper time, I guess reading the code of handle-switch-frame should make it reasonably easy to come up with a scenario where it doesn't do the right thing. > - the overlay management has apparently been rendered completely > useless by the use of the temporary transient-mark-mode. So all that > this code really does is implement the mouse-region-delete-keys. > This variable was introduced in 1996, but is not documented anywhere. > We must have forgotten to document the feature. However, the feature > is not just this variable. The feature is that typing DELETE deletes > the selected region. That's what I meant by the "mouse-region-delete-keys" feature, of course. > It isn't documented, but I would expect that many people have simply > tried it, expecting it to work, and found that it did, so they use it. Could be. > Does anybody use > this? (I expect that people who want such a functionality probably use > delete-selection-mode instead anyway). > They might; but it isn't exactly the same, and it would not surprise > me if many users use this feature and don't use delete-selection-mode. > Perhaps they would be happy switching to delete-selection-mode, but it > is not obvious. > However, if the only function of that code is to implement this > feature, it might easy to reimplement the feature in a simpler way. Indeed. Stefan