From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.help Subject: RE: can a command specify overwrite selection behavior? Date: Mon, 27 Dec 2010 21:34:49 -0800 Message-ID: References: <33ac6984-0a0c-4db8-8ea1-50ec5c271a25@x18g2000pro.googlegroups.com><05a87fbb-31a7-40c3-a890-6c7aacaefac3@t5g2000prd.googlegroups.com><92235e12-464c-41d9-9a49-33598c157113@i25g2000prd.googlegroups.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1293514586 3019 80.91.229.12 (28 Dec 2010 05:36:26 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 28 Dec 2010 05:36:26 +0000 (UTC) To: "'Stefan Monnier'" , Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Tue Dec 28 06:36:22 2010 Return-path: Envelope-to: geh-help-gnu-emacs@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 1PXSEL-0004q0-U1 for geh-help-gnu-emacs@m.gmane.org; Tue, 28 Dec 2010 06:36:18 +0100 Original-Received: from localhost ([127.0.0.1]:51668 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PXSEL-00028O-7R for geh-help-gnu-emacs@m.gmane.org; Tue, 28 Dec 2010 00:36:17 -0500 Original-Received: from [140.186.70.92] (port=39908 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PXSDx-00028J-O7 for help-gnu-emacs@gnu.org; Tue, 28 Dec 2010 00:35:55 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PXSDw-00064b-Lt for help-gnu-emacs@gnu.org; Tue, 28 Dec 2010 00:35:53 -0500 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]:22984) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PXSDw-00064X-FP for help-gnu-emacs@gnu.org; Tue, 28 Dec 2010 00:35:52 -0500 Original-Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id oBS5Zm58019974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 28 Dec 2010 05:35:50 GMT Original-Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id oBS5ZlA8030929; Tue, 28 Dec 2010 05:35:47 GMT Original-Received: from abhmt021.oracle.com by acsmt354.oracle.com with ESMTP id 909729091293514491; Mon, 27 Dec 2010 21:34:51 -0800 Original-Received: from dradamslap1 (/10.159.240.115) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 27 Dec 2010 21:34:51 -0800 X-Mailer: Microsoft Office Outlook 11 In-reply-to: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Thread-Index: AcumQPNJOQ1MChhETiyhZqTjici6LQAAk1Jw X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:77928 Archived-At: > > This behavior is _by design_. > > No, it's because of the implementation: a pre-command-hook. To say that (implementation vs design) is to claim that the implementation somehow mistakes and does not follow the design. As there is no explicit design document separate from the code, we cannot make such a distinction. We can only infer the design and intention from the code itself, code comments, and some idea about the implementors. `delsel.el' was written by Matthieu Devin, a longtime XEmacs developer who worked on the original Lucid Emacs development. (I do not know him; I just googled the name from the source file.) I would seriously doubt that Matthieu was not aware of the subtleties of pre-command hooks, `this-command', and `last-command'. My bet is that he opted for this design with cognizance of any limitations. Whether his choice is the best one for delete-selection can of course be questioned, but I see no reason to claim that the implementation does not fit the design, that he didn't code what he intended. It appears on the contrary that use of a pre-command hook is the way delete-selection mode was designed and implemented from the outset. It is not some implementation detail that somehow deviates from the chosen approach. It is the approach (design and implementation) that was adopted for delete-selection. The design could have been different. And it could always be changed. But that was how delete-selection was meant to work AFAICT - with the attendant limitations of such an approach (which I pointed to). > That's one of the reasons why I wanted the shift-select code > not to rely on this-command and things like that, but be > triggered by explicit code in the interactive spec. Arguing that a different approach would have been or would now be better could be a legitimate argument. It is not legitimate to argue that this is somehow an implementation bug, something unexpected or not understood by those who built it the way they did. Unless you can show that they didn't know what they were doing. I made several references to the limitations of using a pre-command hook and the inherent problems of simply comparing `last-command' and `this-command'. That there are such limitations does not mean that the delsel code is not acting as it was designed. And it does not mean that delete-selection mode misbehaves, not doing what its users expect. It means that those limitations were accepted from the get-go and are inconsequential for the intended use. I haven't seen any argument to the contrary, any demonstration that the chosen design/implementation does not DTRT wrt the intended use. Every approach has its strengths and its weaknesses. Late binding, indirection, procedural attachment, etc. always bring with them possibilities of dislocation (and sometimes inefficiency), even as they can sometimes offer convenience or added flexibility. But let's be clear that delete-selection mode is about the behavior of interactively using keys to edit text. That is all that it was meant for AFAIK, and that is all that the `delete-selection' symbol property was intended for. Given that as the use case, the existing design does its job quite well. About the only real limitation wrt its use case is the inability to use an anonymous command (since it uses a symbol property). And that's a negligible case, IMO. No bug has been shown here regarding delete-selection mode. The code that Xah wrote works fine. He just did not understand that it should be tested the same way it will be used: bound to a key. His command shows no behavior that its user would find surpising or unwanted, assuming that it is intended to be invoked from a key. It is not a _bug_ that you do not always and necessarily see the same behavior invoking or evaluating something using `M-x' or `M-:' or `pp-eval-expression' as you do invoking or evaluating the same thing non-interactively from Lisp. These are different things, and it is normal that they can sometimes have different behavior. That was the question raised in this thread: whether it is a bug that `M-x COMMAND' can sometimes behave differently from COMMAND invoked from a key binding. In particular, a command with a `delete-selection' property. Delete-selection behavior is not intended to be used from `M-x'. That would be silly - I see zero argument supporting such a use case. No design bug here; no implementation bug.