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: Sat, 29 Mar 2008 15:07:15 +0100 Message-ID: <85ve35pqss.fsf@lola.goethe.zz> 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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1206799793 16880 80.91.229.12 (29 Mar 2008 14:09:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 29 Mar 2008 14:09:53 +0000 (UTC) Cc: lennart.borgman@gmail.com, jared@hpalace.com, rms@gnu.org, emacs-devel@gnu.org To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 29 15:10: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 1JfblH-0001lh-79 for ged-emacs-devel@m.gmane.org; Sat, 29 Mar 2008 15:10:23 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jfbkf-0000Gt-JV for ged-emacs-devel@m.gmane.org; Sat, 29 Mar 2008 10:09:45 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JfbiX-0007U1-Fn for emacs-devel@gnu.org; Sat, 29 Mar 2008 10:07:33 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JfbiV-0007TZ-QB for emacs-devel@gnu.org; Sat, 29 Mar 2008 10:07:32 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JfbiV-0007TT-Es for emacs-devel@gnu.org; Sat, 29 Mar 2008 10:07:31 -0400 Original-Received: from mail-in-13.arcor-online.net ([151.189.21.53]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JfbiR-0001Yu-1b; Sat, 29 Mar 2008 10:07:27 -0400 Original-Received: from mail-in-11-z2.arcor-online.net (mail-in-11-z2.arcor-online.net [151.189.8.28]) by mail-in-13.arcor-online.net (Postfix) with ESMTP id 72F191E520E; Sat, 29 Mar 2008 15:07:20 +0100 (CET) Original-Received: from mail-in-06.arcor-online.net (mail-in-06.arcor-online.net [151.189.21.46]) by mail-in-11-z2.arcor-online.net (Postfix) with ESMTP id 591B23465CB; Sat, 29 Mar 2008 15:07:20 +0100 (CET) Original-Received: from lola.goethe.zz (dslb-084-061-014-217.pools.arcor-ip.net [84.61.14.217]) by mail-in-06.arcor-online.net (Postfix) with ESMTP id E569D35E6AA; Sat, 29 Mar 2008 15:07:19 +0100 (CET) Original-Received: by lola.goethe.zz (Postfix, from userid 1002) id 03E1C1C4CE00; Sat, 29 Mar 2008 15:07:15 +0100 (CET) In-Reply-To: <8763v5k8zq.fsf@jurta.org> (Juri Linkov's message of "Sat, 29 Mar 2008 14:30:49 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-Virus-Scanned: ClamAV 0.92.1/6462/Sat Mar 29 14:14:09 2008 on mail-in-06.arcor-online.net X-Virus-Status: Clean X-detected-kernel: by monty-python.gnu.org: Linux 2.4-2.6 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:93795 Archived-At: Juri Linkov writes: >>>>> And the easiest way to do this is to change properties. >>>> >>>> I am not concerned about the easiest, but an appropriate way. >>> >>> Emacs should be easy to use and customize, not appropriate for some >>> abstract goal. >> >> Giving a function a well-defined default behavior is not customization. >> It is function definition. > > Shift-selection is not an inherent part of function definition since a > function can normally work with or without this feature either way. How is this different from any interactive call specification? In particular, from, say, the "*" flag in an interactive call string? > And it would be very confusing to set a default behavior using > interactive codes, but allow to modify it using properties. So the solution is not to let properties meddle with this. Fine with me. >>>> Properties are not part of either variable or function. They are >>>> part of the symbol. >>> >>> So what? There are already about 200 distinct properties in Emacs >>> attached indirectly to functions and variables via symbols, and they >>> modify the default behavior, so the documentation should reveal them >>> to users. >> >> But there is no _meaning_ conveyed by some property. It is >> undocumented. > > Of course, a property has a meaning, but it is different from the > meaning of a command. It has no _inherent_ meaning. And there is no way of documenting any meaning of it, anyway. > For instance, `forward-char' has the meaning of moving point right n > characters. OTOH, the `shift-selection' property has the meaning of > activating the mark before executing the command. Before executing a command that happens to be bound to a particular symbol, when this command is called in a particular way in the command loop by doing symbol lookup. That's very arbitrary. > Those are different meanings of different features. This is not even comparing apples and oranges. It is comparing apples and geography. >>>> Lisp is Lisp, and Scheme is Scheme. >>> >>> And Emacs is Emacs (_extensible_, _customizable_, _self-documenting_ >>> real-time display editor). >> >> So what about "self-documenting" applies to arbitrary properties? We >> don't document functions by disassembling them, but by documentation >> strings. The presence of a property is not self-explanatory, and it is >> not apparent whether it may affect the variable, the function, or >> something else. > > Actually you presented the argument against using interactive codes > for the shift-selection feature. Using an interactive code will > require adding a text like "This command activates the mark before its > execution when Shift key is pressed" to the documentation string of > the command. Your point being? Of course one adapts the function documentation string as well when one changes the interactive code. That's the same with all other interactive calls. 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. > But when the user will turn off this feature (external to the function > definition) the documentation string will lie to the user. Make up a better documentation string, then, referring to the variable which presumably turns on/off the feature. > So it is clear that the shift-selection feature should not be part of > function definition (not to have an interactive code nor corresponding > text in its documentation string). We can stop this right here. There is _no_ _way_ whatsoever that you will convince me that a part of the interactive behavior of the function should _not_ be put into its interactive form and _not_ into its documentation. I consider this completely inappropriate. You will not change my mind on that. > The only alternative to assigning properties to function symbols I see > is creating a new user option with a list of command names that should > activate the mark before their execution. 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 Kastrup, Kriemhildstr. 15, 44793 Bochum