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: Wed, 26 Mar 2008 12:47:19 +0100 Message-ID: <47EA37C7.7080502@gmail.com> References: <87k5k69p92.fsf@stupidchicken.com> <87abl11ilo.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=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1206532074 9552 80.91.229.12 (26 Mar 2008 11:47:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 26 Mar 2008 11:47:54 +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:48:24 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 1JeU78-0002yh-9K for ged-emacs-devel@m.gmane.org; Wed, 26 Mar 2008 12:48:18 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JeU6W-0003Zz-Qs for ged-emacs-devel@m.gmane.org; Wed, 26 Mar 2008 07:47:40 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JeU6S-0003Zi-Bh for emacs-devel@gnu.org; Wed, 26 Mar 2008 07:47:36 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JeU6Q-0003Xi-UN for emacs-devel@gnu.org; Wed, 26 Mar 2008 07:47:36 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JeU6Q-0003XK-N1 for emacs-devel@gnu.org; Wed, 26 Mar 2008 07:47:34 -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 1JeU6M-00005x-VE; Wed, 26 Mar 2008 07:47:31 -0400 Original-Received: from c83-254-148-228.bredband.comhem.se ([83.254.148.228]:62455 helo=[127.0.0.1]) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1JeU6K-0003DC-43; Wed, 26 Mar 2008 12:47:28 +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: <87ve3993dt.fsf@jurta.org> X-Antivirus: avast! (VPS 080326-0, 2008-03-26), Outbound message X-Antivirus-Status: Clean X-Originating-IP: 83.254.148.228 X-ACL-Warn: Too high rate of unknown addresses received from you X-Scan-Result: No virus found in message 1JeU6K-0003DC-43. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1JeU6K-0003DC-43 20e9a92303270ed13620e652c34ccc4e 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:93524 Archived-At: Juri Linkov wrote: > 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. > > The only problem I see is that properties currently are hard to discover. > 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. > > 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. Agreed. If description of properties are added it will also be easy to add specific description for properties with known use.