From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Lennart Borgman (gmail)" Newsgroups: gmane.emacs.devel Subject: Re: Shift selection using interactive spec Date: Sat, 29 Mar 2008 15:45:08 +0100 Message-ID: <47EE55F4.9030703@gmail.com> References: <87k5k69p92.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> <47EA37C7.7080502@gmail.com> <47EADCC4.2000207@gmail.com> <87iqz7wx7n.fsf@jurta.org> <851w5vti9y.fsf@lola.goethe.zz> <87tziqqtd0.fsf@jurta.org> <853aqarp06.fsf@lola.goethe.zz> <8763v5k8zq.fsf@jurta.org> <85ve35pqss.fsf@lola.goethe.zz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1206801946 22682 80.91.229.12 (29 Mar 2008 14:45:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 29 Mar 2008 14:45:46 +0000 (UTC) Cc: Juri Linkov , jared@hpalace.com, rms@gnu.org, emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 29 15:46:17 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 1JfcJn-0003hz-GF for ged-emacs-devel@m.gmane.org; Sat, 29 Mar 2008 15:46:03 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JfcJB-000819-Tp for ged-emacs-devel@m.gmane.org; Sat, 29 Mar 2008 10:45:25 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JfcJ8-00080h-2g for emacs-devel@gnu.org; Sat, 29 Mar 2008 10:45:22 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JfcJ6-00080V-LI for emacs-devel@gnu.org; Sat, 29 Mar 2008 10:45:21 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JfcJ6-00080S-JI for emacs-devel@gnu.org; Sat, 29 Mar 2008 10:45:20 -0400 Original-Received: from ch-smtp01.sth.basefarm.net ([80.76.149.212]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JfcIz-0007rq-At; Sat, 29 Mar 2008 10:45:13 -0400 Original-Received: from c83-254-150-27.bredband.comhem.se ([83.254.150.27]:61395 helo=[127.0.0.1]) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1JfcIx-00064m-3J; Sat, 29 Mar 2008 15:45:11 +0100 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.666 In-Reply-To: <85ve35pqss.fsf@lola.goethe.zz> X-Antivirus: avast! (VPS 080328-0, 2008-03-28), Outbound message X-Antivirus-Status: Clean X-Originating-IP: 83.254.150.27 X-Scan-Result: No virus found in message 1JfcIx-00064m-3J. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1JfcIx-00064m-3J 962afece6d6f9fe8f9a964e86bc7a809 X-detected-kernel: by monty-python.gnu.org: Linux 2.6? (barebone, rare!) 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:93798 Archived-At: David Kastrup wrote: > But there is no way to change the DOC string when one tacks a property > onto the function. And that means that the DOC string change and the > property tack-on are not inherently _synchronized_. And that is a bad > idea. I think you are attaching the wrong point. What is important is not only the doc string, but what the help system does. Of course the help system can take care of this. In this respect there is no problem with using a property here. > Again, this hides away part of the interactive behavior of a command to > a different place. And again, it makes the mechanism depend on the > _name_ (aka symbol) of the called function rather than its function > definition. David, may I remind you that I asked you earlier about a way to change the interactive spec in the function cell. You answered with a way to instead attach a property to the symbol name.