From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Shift selection using interactive spec Date: Wed, 26 Mar 2008 12:32:34 +0100 Message-ID: <86d4ph67ql.fsf@lola.quinscape.zz> References: <87k5k69p92.fsf@stupidchicken.com> <874pb9koyw.fsf@stupidchicken.com> <87od9gzqv9.fsf@stupidchicken.com> <87bq5gytbi.fsf@stupidchicken.com> <8763vndi0r.fsf@kfs-lx.rd.rdm> <87hcf6ratt.fsf@stupidchicken.com> <878x0if9ul.fsf@stupidchicken.com> <87od9e9gnx.fsf@stupidchicken.com> <87skyo5bvk.fsf@stupidchicken.com> <87skynrin5.fsf@stupidchicken.com> <87iqzju0lq.fsf@kfs-lx.rd.rdm> <851w5xx5ya.fsf@lola.goethe.zz> <87ve3993dt.fsf@jurta.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1206531189 6375 80.91.229.12 (26 Mar 2008 11:33:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 26 Mar 2008 11:33:09 +0000 (UTC) Cc: M Jared Finder , emacs-devel@gnu.org To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 26 12:33:39 2008 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 1JeTsn-0006VB-58 for ged-emacs-devel@m.gmane.org; Wed, 26 Mar 2008 12:33:29 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JeTsB-0005gv-1n for ged-emacs-devel@m.gmane.org; Wed, 26 Mar 2008 07:32:51 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JeTs5-0005gB-81 for emacs-devel@gnu.org; Wed, 26 Mar 2008 07:32:45 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JeTrz-0005e6-Kg for emacs-devel@gnu.org; Wed, 26 Mar 2008 07:32:44 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JeTry-0005e3-NW for emacs-devel@gnu.org; Wed, 26 Mar 2008 07:32:39 -0400 Original-Received: from mail.quinscape.de ([212.29.44.217]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JeTry-0004NS-BP for emacs-devel@gnu.org; Wed, 26 Mar 2008 07:32:38 -0400 Original-Received: (qmail-ldap/ctrl 26702 invoked from network); 26 Mar 2008 11:32:36 -0000 Original-Received: from unknown (HELO lola.quinscape.zz) ([10.0.3.43]) (envelope-sender ) by ns.quinscape.de (qmail-ldap-1.03) with SMTP for ; 26 Mar 2008 11:32:35 -0000 Original-Received: by lola.quinscape.zz (Postfix, from userid 1001) id E003F8FC5B; Wed, 26 Mar 2008 12:32:34 +0100 (CET) In-Reply-To: <87ve3993dt.fsf@jurta.org> (Juri Linkov's message of "Wed, 26 Mar 2008 12:48:22 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-AntiVirus: checked by AntiVir MailGate (version: 2.1.3-2; AVE: 7.6.0.75; VDF: 7.0.3.76; host: quinx) X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 3) 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:93523 Archived-At: Juri Linkov writes: >> Changing a command's behavior after the thought can be dealt with by >> using advice. >> >> Attaching properties is a can of worms that does not work for anonymous >> functions. > > But an interactive code does not work when a spec is a Lisp expression > that is not a string. So just as an interactive Lisp expression should > call a special function `shift-translation-handler' explicitly, > anonymous functions can call the same function as well (though it is > not recommended to use anonymous functions for commands). So both these > approaches are on a par in this regard. Which two approaches are you discussing here? I don't see that your argument addresses anything regarding properties. > But using properties seems to be more preferable since there is a need > to implement more related features like delete-selection-mode and > inventing more funny interactive codes doesn't seem like a wise thing > to do. Attaching information magically to symbols rather than the actual function seems much more unwise to me. > The only problem I see is that properties currently are hard to > discover. That is because properties are not part of a function, but part of a symbol. And a symbol has all of function cell, value cell, property list and name. Those are disparate things. Storing information about the function in the property list scatters the information and makes it impossible to use the actual function rather than the referring symbol. > I think that just as `C-h f' describe-function displays information > when the function is advised, we should change `C-h v' > describe-variable to display information about attached variable > properties as well. But we are talking right now about _functions_. And it is a mistake to consider the property list part of either variable or function: it has different scopes and is independent from both variable or function. > Also as Kim already noted supporting external packages using the > interactive specification code approach would be a nightmare. So it > seems it would be the best to go the way Kim suggested and just > reimplement in C cua-selection-mode with properties that was proven by > time and experience to be the right solution. Uh, "could be made to work" does not imply "right solution". -- David Kastrup