* Re: Interactive hat.
@ 2009-03-27 0:20 naesten
0 siblings, 0 replies; 33+ messages in thread
From: naesten @ 2009-03-27 0:20 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Alan Mackenzie, emacs-devel, Juanma Barranquero
[-- Attachment #1: Type: text/plain, Size: 479 bytes --]
On Thu, Mar 26, 2009 at 5:18 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> As explained in my message of a couple days ago, it should always
> be easy to turn an interactive string into the corresponding lisp form.
Perhaps there should be a function (and command?) to do just that? It might help people to remember not to add anything to the string without providing a corresponding lisp function/macro. (Not that that is likely to happen very often or anything...)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply [flat|nested] 33+ messages in thread
[parent not found: <20090323223703.GA5650@muc.de>]
[parent not found: <jwvfxh392k9.fsf-monnier+emacsbugreports@gnu.org>]
[parent not found: <20090324135210.GA4657@muc.de>]
[parent not found: <jwvzlfacrk0.fsf-monnier+emacsbugreports@gnu.org>]
* Interactive hat. [Was: CUA-like stuff spuriously enables transient-mark-mode] [not found] ` <jwvzlfacrk0.fsf-monnier+emacsbugreports@gnu.org> @ 2009-03-25 10:16 ` Alan Mackenzie 2009-03-25 10:30 ` Interactive hat Miles Bader 2009-03-25 11:26 ` Interactive hat. [Was: CUA-like stuff spuriously enables transient-mark-mode] Juanma Barranquero 0 siblings, 2 replies; 33+ messages in thread From: Alan Mackenzie @ 2009-03-25 10:16 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel Hi, Stefan, On Tue, Mar 24, 2009 at 09:38:29PM -0400, Stefan Monnier wrote: > >> Where do you see it hardcoded in the command loop? > > In Fcall_interactively, Lines 207 and 231, where it is interpreting the > > interactive string: > > else if (*string == '^') > > { > > if (! NILP (Vshift_select_mode)) > > call1 (Qhandle_shift_selection, Qnil); <================ > > /* Even if shift-select-mode is off, temporarily active > > regions could be set using the mouse, and should be > > deactivated. */ > > else if (CONSP (Vtransient_mark_mode) > > && EQ (XCAR (Vtransient_mark_mode), Qonly)) > > call1 (Qhandle_shift_selection, Qt); <================ > > string++; > > } > > . > I see. I guess we just disagree on what is meant by "hardcoded in the > command loop": this code is explicitly requested by the "^" code in the > `interactive' string of a command, so it seems (to me) pretty far from > "hardcoded in the command loop". It's hard-coded to the shift-key, rather than using the normal Emacs mechanism of putting the "shifted" versions of movement commands into a minor mode map. Interactive strings which use "^" are incompatible with other Emacs versions. This will cause problems. How is an external library writer going to use the interactive "^"? Assuming that the library should also work under XEmacs and Emacs 22, just using the "^" won't work; an interactive string with "^" throws an error in Emacs 22. The next try is to use a macro which will generate an appropriate interactive string. Something like: (defmacro foo-interactive (s-22 s-23) "doc string" `(interactive ,(if (emacs-got-interactive-hat) s-23 s22))) , but I can't get defun to take a macro-generated interactive string. I suspect it's not possible. It seems to work, sort of, in byte-compiled defuns. Could we supply some sort of macro which will add "^" to an interactive string? Then at least each external library author won't have to figure it out himself. > Stefan -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Interactive hat. 2009-03-25 10:16 ` Interactive hat. [Was: CUA-like stuff spuriously enables transient-mark-mode] Alan Mackenzie @ 2009-03-25 10:30 ` Miles Bader 2009-03-25 10:53 ` Alan Mackenzie 2009-03-25 16:18 ` Stefan Monnier 2009-03-25 11:26 ` Interactive hat. [Was: CUA-like stuff spuriously enables transient-mark-mode] Juanma Barranquero 1 sibling, 2 replies; 33+ messages in thread From: Miles Bader @ 2009-03-25 10:30 UTC (permalink / raw) To: Alan Mackenzie; +Cc: Stefan Monnier, emacs-devel Alan Mackenzie <acm@muc.de> writes: > How is an external library writer going to use the interactive "^"? > Assuming that the library should also work under XEmacs and Emacs 22, > just using the "^" won't work; an interactive string with "^" throws an > error in Emacs 22. Isn't that a pretty basic problem with _any_ extension to interactive? Do you think `interactive' should never be extended? In this case, I think the right solution would be to simply add another, possibly clunkier method for commands to indicate they want to enable shift-selection behavior. E.g.: have the command loop also look for a `handle-shift-select' property on command-name's plist, and treat that as it would "^" in the interactive string. Then external library authors who are worried about backwards compability could use (put COMMAND 'handle-shift-select t) instead of putting ^ in COMMAND's interactive string. [Yeah, that only works for commands which are defined functions, but I think that's an acceptable limitation for a feature like this which should be used only rarely.] -Miles -- "1971 pickup truck; will trade for guns" ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Interactive hat. 2009-03-25 10:30 ` Interactive hat Miles Bader @ 2009-03-25 10:53 ` Alan Mackenzie 2009-03-25 11:03 ` Lennart Borgman 2009-03-25 14:59 ` Miles Bader 2009-03-25 16:18 ` Stefan Monnier 1 sibling, 2 replies; 33+ messages in thread From: Alan Mackenzie @ 2009-03-25 10:53 UTC (permalink / raw) To: Miles Bader; +Cc: Stefan Monnier, emacs-devel Hi, Miles! On Wed, Mar 25, 2009 at 07:30:13PM +0900, Miles Bader wrote: > Alan Mackenzie <acm@muc.de> writes: > > How is an external library writer going to use the interactive "^"? > > Assuming that the library should also work under XEmacs and Emacs 22, > > just using the "^" won't work; an interactive string with "^" throws an > > error in Emacs 22. > Isn't that a pretty basic problem with _any_ extension to interactive? > Do you think `interactive' should never be extended? Yes, and yes. Or, rather, yes and yes except in the most exceptional of circumstances, such as adding a new parameter type. > In this case, I think the right solution would be to simply add another, > possibly clunkier method for commands to indicate they want to enable > shift-selection behavior. Agreed. > E.g.: have the command loop also look for a `handle-shift-select' > property on command-name's plist, and treat that as it would "^" in the > interactive string. Then external library authors who are worried about > backwards compability could use (put COMMAND 'handle-shift-select t) > instead of putting ^ in COMMAND's interactive string. Agreed, except I wouldn't put it in the command loop - I'd put it in a hook (pre-command-hook), for the same reason font-locking is in a hook rather than directly in the command loop. M-x shift-select would install/remove this function onto/from the hook. Now the question arises, if we've got the property `handle-shift-select', doesn't the "^" in the interactive string become redundant? > [Yeah, that only works for commands which are defined functions, but I > think that's an acceptable limitation for a feature like this which > should be used only rarely.] Yes, a lambda expression can't use this. That's the only use of "^" I can see which absolutely requires "^". But let's be honest, how often do hackers write movement commands as anonymous lambdas? > -Miles > -- > "1971 pickup truck; will trade for gnus" Hey, you can get gnus for nothing. :-) -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Interactive hat. 2009-03-25 10:53 ` Alan Mackenzie @ 2009-03-25 11:03 ` Lennart Borgman 2009-03-25 14:24 ` Alan Mackenzie 2009-03-26 11:29 ` Alan Mackenzie 2009-03-25 14:59 ` Miles Bader 1 sibling, 2 replies; 33+ messages in thread From: Lennart Borgman @ 2009-03-25 11:03 UTC (permalink / raw) To: Alan Mackenzie; +Cc: emacs-devel, Stefan Monnier, Miles Bader Hi Alan, On Wed, Mar 25, 2009 at 11:53 AM, Alan Mackenzie <acm@muc.de> wrote: > Agreed, except I wouldn't put it in the command loop - I'd put it in a > hook (pre-command-hook), for the same reason font-locking is in a hook > rather than directly in the command loop. M-x shift-select would > install/remove this function onto/from the hook. We discussed this before and my conclusion was that this would not work well enough because of the order of things in the hook would be crucial. I suggested adding a new hook to run before pre-command-hook. (And something similar for pos-command-hook.) ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Interactive hat. 2009-03-25 11:03 ` Lennart Borgman @ 2009-03-25 14:24 ` Alan Mackenzie 2009-03-26 11:29 ` Alan Mackenzie 1 sibling, 0 replies; 33+ messages in thread From: Alan Mackenzie @ 2009-03-25 14:24 UTC (permalink / raw) To: Lennart Borgman; +Cc: emacs-devel Hi, Lennart! On Wed, Mar 25, 2009 at 12:03:08PM +0100, Lennart Borgman wrote: > Hi Alan, > On Wed, Mar 25, 2009 at 11:53 AM, Alan Mackenzie <acm@muc.de> wrote: > > Agreed, except I wouldn't put it in the command loop - I'd put it in a > > hook (pre-command-hook), for the same reason font-locking is in a hook > > rather than directly in the command loop. M-x shift-select would > > install/remove this function onto/from the hook. > We discussed this before and my conclusion was that this would not > work well enough because of the order of things in the hook would be > crucial. I suggested adding a new hook to run before pre-command-hook. > (And something similar for pos-command-hook.) Yes, I remember that discussion. ;-) It was about a year ago. I'll go and look it up, and see what you said. Thanks for the pointer! -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Interactive hat. 2009-03-25 11:03 ` Lennart Borgman 2009-03-25 14:24 ` Alan Mackenzie @ 2009-03-26 11:29 ` Alan Mackenzie 1 sibling, 0 replies; 33+ messages in thread From: Alan Mackenzie @ 2009-03-26 11:29 UTC (permalink / raw) To: Lennart Borgman; +Cc: Miles Bader, Stefan Monnier, emacs-devel Hi again, Lennart! On Wed, Mar 25, 2009 at 12:03:08PM +0100, Lennart Borgman wrote: > Hi Alan, > On Wed, Mar 25, 2009 at 11:53 AM, Alan Mackenzie <acm@muc.de> wrote: > > Agreed, except I wouldn't put it in the command loop - I'd put it in a > > hook (pre-command-hook), for the same reason font-locking is in a hook > > rather than directly in the command loop. M-x shift-select would > > install/remove this function onto/from the hook. > We discussed this before and my conclusion was that this would not > work well enough because of the order of things in the hook would be > crucial. I suggested adding a new hook to run before pre-command-hook. > (And something similar for pos-command-hook.) I've searched the archive from a year ago, looking at your posts which contain the word "hook". You've certainly asserted that the order of functions in the pre-command-hook is important, but I don't think you gave any concrete examples of where an unfortunate ordering would mess things up. I think you were thinking of things like Viper Mode, and the use of commands like `d' (for delete) combined with, say `)' (for end of sentence). In my experience, these feelings of unease are usually justified. ;-) All the same, could you possibly construct a realistic example of two functions in pre-command-hook which work properly in one order, but foul up in the other? -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Interactive hat. 2009-03-25 10:53 ` Alan Mackenzie 2009-03-25 11:03 ` Lennart Borgman @ 2009-03-25 14:59 ` Miles Bader 2009-03-26 11:51 ` Alan Mackenzie 1 sibling, 1 reply; 33+ messages in thread From: Miles Bader @ 2009-03-25 14:59 UTC (permalink / raw) To: emacs-devel Alan Mackenzie <acm@muc.de> writes: > Now the question arises, if we've got the property > `handle-shift-select', doesn't the "^" in the interactive string become > redundant? Not at all. For the vast majority of uses -- functions distributed with emacs (and in external packages that don't care about xemacs or older versions of emacs), it's more convenient and prettier. -Miles -- Accord, n. Harmony. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Interactive hat. 2009-03-25 14:59 ` Miles Bader @ 2009-03-26 11:51 ` Alan Mackenzie 2009-03-26 12:14 ` David Kastrup 2009-03-26 13:48 ` Stefan Monnier 0 siblings, 2 replies; 33+ messages in thread From: Alan Mackenzie @ 2009-03-26 11:51 UTC (permalink / raw) To: Miles Bader; +Cc: emacs-devel Hi, Miles! On Wed, Mar 25, 2009 at 11:59:58PM +0900, Miles Bader wrote: > Alan Mackenzie <acm@muc.de> writes: > > Now the question arises, if we've got the property > > `handle-shift-select', doesn't the "^" in the interactive string become > > redundant? > Not at all. For the vast majority of uses -- functions distributed with > emacs (and in external packages that don't care about xemacs or older > versions of emacs), it's more convenient and prettier. It is, perhaps, more convenient, but prettier? Well, let's just say that it is possible to take different viewpoints on this. Mine is that it's an ugly hack, utterly different from anything that's gone before, and it will have negative implications, not all of which will be foreseen before the release of Emacs 23. I think it's more "clever" than smart, a bit like C++'s abuse of the shift-left operator: cout << (byte_count << 3) ; . Somebody will end up having to code round it. If it's possible to code everything we need with a symbol property, I think the interactive hat mechanism should be removed. There are currently only 28 defuns (in simple.el, lisp.el and paragraphs.el) which use this, so changing them to use a property instead would be a trivial amount of work. > -Miles -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Interactive hat. 2009-03-26 11:51 ` Alan Mackenzie @ 2009-03-26 12:14 ` David Kastrup 2009-03-26 12:51 ` Alan Mackenzie 2009-03-26 13:48 ` Stefan Monnier 1 sibling, 1 reply; 33+ messages in thread From: David Kastrup @ 2009-03-26 12:14 UTC (permalink / raw) To: emacs-devel Alan Mackenzie <acm@muc.de> writes: > On Wed, Mar 25, 2009 at 11:59:58PM +0900, Miles Bader wrote: >> Alan Mackenzie <acm@muc.de> writes: >> > Now the question arises, if we've got the property >> > `handle-shift-select', doesn't the "^" in the interactive string become >> > redundant? > >> Not at all. For the vast majority of uses -- functions distributed with >> emacs (and in external packages that don't care about xemacs or older >> versions of emacs), it's more convenient and prettier. > > It is, perhaps, more convenient, but prettier? Well, let's just say > that it is possible to take different viewpoints on this. Mine is that > it's an ugly hack, utterly different from anything that's gone before, > and it will have negative implications, not all of which will be > foreseen before the release of Emacs 23. I think it's more "clever" > than smart, a bit like C++'s abuse of the shift-left operator: > > cout << (byte_count << 3) ; > > . Somebody will end up having to code round it. > > If it's possible to code everything we need with a symbol property, I > think the interactive hat mechanism should be removed. > > There are currently only 28 defuns (in simple.el, lisp.el and > paragraphs.el) which use this, so changing them to use a property > instead would be a trivial amount of work. You can't put a symbol property on an anonymous function, and quite a few interactive functions are autogenerated within Emacs, particularly in mouse keymaps. -- David Kastrup ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Interactive hat. 2009-03-26 12:14 ` David Kastrup @ 2009-03-26 12:51 ` Alan Mackenzie 0 siblings, 0 replies; 33+ messages in thread From: Alan Mackenzie @ 2009-03-26 12:51 UTC (permalink / raw) To: David Kastrup; +Cc: emacs-devel Hi, David! On Thu, Mar 26, 2009 at 01:14:21PM +0100, David Kastrup wrote: > Alan Mackenzie <acm@muc.de> writes: > > If it's possible to code everything we need with a symbol property, I > > think the interactive hat mechanism should be removed. > > There are currently only 28 defuns (in simple.el, lisp.el and > > paragraphs.el) which use this, so changing them to use a property > > instead would be a trivial amount of work. > You can't put a symbol property on an anonymous function, and quite a > few interactive functions are autogenerated within Emacs, particularly > in mouse keymaps. Could you point out an example of this, please? Do any of these autogenerated commands use interactive-hat? Would it be practical and not too ugly to amend these commands to use a symbol, possibly not interned? Does shift-select-mode even make any sense for mouse commands? (I'm not a mouse user.) > -- > David Kastrup -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Interactive hat. 2009-03-26 11:51 ` Alan Mackenzie 2009-03-26 12:14 ` David Kastrup @ 2009-03-26 13:48 ` Stefan Monnier 2009-03-26 14:33 ` Alan Mackenzie 2009-03-26 14:47 ` Stephen J. Turnbull 1 sibling, 2 replies; 33+ messages in thread From: Stefan Monnier @ 2009-03-26 13:48 UTC (permalink / raw) To: Alan Mackenzie; +Cc: emacs-devel, Miles Bader > If it's possible to code everything we need with a symbol property, I > think the interactive hat mechanism should be removed. You got things backwards here: the "^" describes the behavior of the command, so it should be part of the command, not its name. The ability to use a symbol property for that is a hack that can come in handy at times, but it's still just a hack. Stefan ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Interactive hat. 2009-03-26 13:48 ` Stefan Monnier @ 2009-03-26 14:33 ` Alan Mackenzie 2009-03-26 16:30 ` Stefan Monnier 2009-03-26 14:47 ` Stephen J. Turnbull 1 sibling, 1 reply; 33+ messages in thread From: Alan Mackenzie @ 2009-03-26 14:33 UTC (permalink / raw) To: Stefan Monnier; +Cc: Miles Bader, emacs-devel Hi, Stefan! On Thu, Mar 26, 2009 at 09:48:11AM -0400, Stefan Monnier wrote: > > If it's possible to code everything we need with a symbol property, I > > think the interactive hat mechanism should be removed. > You got things backwards here: the "^" describes the behavior of the > command, so it should be part of the command, not its name. NOT SO FAST THERE, BUDDY!!! Most, possibly nearly all, properties attached to a symbol describe either the symbol-function or the symbol-value. So, whilst I agree you have some sort of point, it would require a massive change to Emacs Lisp to allow properties to be attached to a function or value, as opposed to the symbol holding them. > The ability to use a symbol property for that is a hack that can come > in handy at times, but it's still just a hack. I don't think so. It is the standard canonical use of symbol properties. A quick bit of grepping reveals 4278 uses of `put'. Of the ones in the first 100 or so, they all look recording properties of the function rather than the symbol itself. > Stefan -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Interactive hat. 2009-03-26 14:33 ` Alan Mackenzie @ 2009-03-26 16:30 ` Stefan Monnier 2009-03-26 16:45 ` Alan Mackenzie 0 siblings, 1 reply; 33+ messages in thread From: Stefan Monnier @ 2009-03-26 16:30 UTC (permalink / raw) To: Alan Mackenzie; +Cc: Miles Bader, emacs-devel >> The ability to use a symbol property for that is a hack that can come >> in handy at times, but it's still just a hack. > I don't think so. It is the standard canonical use of symbol > properties. A quick bit of grepping reveals 4278 uses of `put'. Of the > ones in the first 100 or so, they all look recording properties of the > function rather than the symbol itself. And they're all hacks (some of them a bit less so because the property is actually installed as part of the symbol's definition (I'm thinking of the `declare' thingy in macros used to set the indent and edebug properties). Stefan ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Interactive hat. 2009-03-26 16:30 ` Stefan Monnier @ 2009-03-26 16:45 ` Alan Mackenzie 2009-03-26 18:57 ` Stefan Monnier 0 siblings, 1 reply; 33+ messages in thread From: Alan Mackenzie @ 2009-03-26 16:45 UTC (permalink / raw) To: Stefan Monnier; +Cc: Miles Bader, emacs-devel Hi, Stefan! On Thu, Mar 26, 2009 at 12:30:38PM -0400, Stefan Monnier wrote: > >> The ability to use a symbol property for that is a hack that can come > >> in handy at times, but it's still just a hack. > > I don't think so. It is the standard canonical use of symbol > > properties. A quick bit of grepping reveals 4278 uses of `put'. Of the > > ones in the first 100 or so, they all look recording properties of the > > function rather than the symbol itself. > And they're all hacks (some of them a bit less so because the property > is actually installed as part of the symbol's definition (I'm thinking > of the `declare' thingy in macros used to set the indent and edebug > properties). Well, what can one say? The property list is part of a symbol. The other parts are its name, its function and its value. If it's a hack for a property to describe the function, it's just as much a hack for the property to describe the value. So a property describes either the property list (which is non-sensical) or the name, or the property is free-standing. So I think you're arguing that a property can only properly describe the name part of a symbol. Or, maybe, just maybe, using properties in the customary way isn't such a bad hack after all. :-) > Stefan -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Interactive hat. 2009-03-26 16:45 ` Alan Mackenzie @ 2009-03-26 18:57 ` Stefan Monnier 2009-03-29 0:44 ` Kim F. Storm 0 siblings, 1 reply; 33+ messages in thread From: Stefan Monnier @ 2009-03-26 18:57 UTC (permalink / raw) To: Alan Mackenzie; +Cc: Miles Bader, emacs-devel > So I think you're arguing that a property can only properly describe the > name part of a symbol. Yes. > Or, maybe, just maybe, using properties in the customary way isn't such a > bad hack after all. :-) They're convenient hacks. But when the property can be put directly on the object, it's usually preferable. Stefan ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Interactive hat. 2009-03-26 18:57 ` Stefan Monnier @ 2009-03-29 0:44 ` Kim F. Storm 2009-03-29 1:40 ` Miles Bader 0 siblings, 1 reply; 33+ messages in thread From: Kim F. Storm @ 2009-03-29 0:44 UTC (permalink / raw) To: Stefan Monnier; +Cc: Alan Mackenzie, emacs-devel, Miles Bader Stefan Monnier <monnier@iro.umontreal.ca> writes: >> So I think you're arguing that a property can only properly describe the >> name part of a symbol. > > Yes. > >> Or, maybe, just maybe, using properties in the customary way isn't such a >> bad hack after all. :-) > > They're convenient hacks. But when the property can be put directly on > the object, it's usually preferable. Based on my years of experience with CUA-mode, I fully agree with Alan. Using symbol property + dedicated pre/post hooks is IMHO superior to interactive-hat for several reasons (that I gave a long time ago). But I've given up that battle - as long as CUA-mode seems to keep working despite the ^ thingy, I'm indifferent to how its done in "standard" emacs. -- Kim F. Storm <storm@cua.dk> http://www.cua.dk ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Interactive hat. 2009-03-29 0:44 ` Kim F. Storm @ 2009-03-29 1:40 ` Miles Bader 2009-03-29 2:02 ` Lennart Borgman 0 siblings, 1 reply; 33+ messages in thread From: Miles Bader @ 2009-03-29 1:40 UTC (permalink / raw) To: emacs-devel storm@cua.dk (Kim F. Storm) writes: > Based on my years of experience with CUA-mode, I fully agree with Alan. > Using symbol property + dedicated pre/post hooks is IMHO superior to > interactive-hat for several reasons (that I gave a long time ago). I don't think the giant glutinous mess that is CUA-mode is a particularly compelling example... -Miles -- Accord, n. Harmony. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Interactive hat. 2009-03-29 1:40 ` Miles Bader @ 2009-03-29 2:02 ` Lennart Borgman 0 siblings, 0 replies; 33+ messages in thread From: Lennart Borgman @ 2009-03-29 2:02 UTC (permalink / raw) To: Miles Bader; +Cc: emacs-devel On Sun, Mar 29, 2009 at 2:40 AM, Miles Bader <miles@gnu.org> wrote: > storm@cua.dk (Kim F. Storm) writes: >> Based on my years of experience with CUA-mode, I fully agree with Alan. >> Using symbol property + dedicated pre/post hooks is IMHO superior to >> interactive-hat for several reasons (that I gave a long time ago). > > I don't think the giant glutinous mess that is CUA-mode is a > particularly compelling example... Why not? Kim gave reasons. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Interactive hat. 2009-03-26 13:48 ` Stefan Monnier 2009-03-26 14:33 ` Alan Mackenzie @ 2009-03-26 14:47 ` Stephen J. Turnbull 2009-03-26 15:23 ` Miles Bader 1 sibling, 1 reply; 33+ messages in thread From: Stephen J. Turnbull @ 2009-03-26 14:47 UTC (permalink / raw) To: Stefan Monnier; +Cc: Alan Mackenzie, Miles Bader, emacs-devel Stefan Monnier writes: > > If it's possible to code everything we need with a symbol property, I > > think the interactive hat mechanism should be removed. > > You got things backwards here: the "^" describes the behavior of > the command, so it should be part of the command, not its name. In XEmacs, both descriptions are incorrect. "Shifted motion selects" is a property of the key, not of the command nor of its name. > The ability to use a symbol property for that is a hack that can > come in handy at times, but it's still just a hack. XEmacs has used a variable containing a list of key names that might have this behavior for ten years with no apparent ill-effects. And it similarly has been hard-coded to the shift key for ten years with no apparent ill-effects. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Interactive hat. 2009-03-26 14:47 ` Stephen J. Turnbull @ 2009-03-26 15:23 ` Miles Bader 2009-03-26 17:43 ` Stephen J. Turnbull 0 siblings, 1 reply; 33+ messages in thread From: Miles Bader @ 2009-03-26 15:23 UTC (permalink / raw) To: emacs-devel "Stephen J. Turnbull" <stephen@xemacs.org> writes: > > You got things backwards here: the "^" describes the behavior of > > the command, so it should be part of the command, not its name. > > In XEmacs, both descriptions are incorrect. "Shifted motion selects" > is a property of the key, not of the command nor of its name. Er, so if I rebind "C-f" to some command in my mode which is completely unrelated to the default binding, does it still inherit the default shifted-select feature?! What if I rebind some other key to "forward-char"? Does that new binding then lack shifted-select? [If so -- wacky...] -Miles -- Christian, n. One who follows the teachings of Christ so long as they are not inconsistent with a life of sin. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Interactive hat. 2009-03-26 15:23 ` Miles Bader @ 2009-03-26 17:43 ` Stephen J. Turnbull 0 siblings, 0 replies; 33+ messages in thread From: Stephen J. Turnbull @ 2009-03-26 17:43 UTC (permalink / raw) To: Miles Bader; +Cc: emacs-devel Miles Bader writes: > "Stephen J. Turnbull" <stephen@xemacs.org> writes: > > In XEmacs [...] "shifted motion selects" is a property of the > > key, not of the command nor of its name. > > Er, so if I rebind "C-f" to some command in my mode which is completely > unrelated to the default binding, does it still inherit the default > shifted-select feature?! No, because by default C-f isn't in the list. The default list contains the arrow keys and the motion keys on the keypad, along with certain combinations of those keys with other modifiers. So let's talk about rebinding 'right instead. If by "unrelated" you mean "not a motion command", then the answer is "yes, but you'll never know the difference." If by "unrelated" you mean something else (what?), the answer is "yes, and the difference is observable if and only if the new binding is a motion command". > What if I rebind some other key to "forward-char"? Does that new > binding then lack shifted-select? Yes. In fact, if (as is most probably the case) you have both 'right and C-f bound to `forward-char', then (by default) 'right has the property and C-f does not. > [If so -- wacky...] Only because you buy in to Stefan's notion that this is a property of the command rather than of the key binding. But talk about wacky hacks! if it's a property of the command, why does the command need to inspect the key binding to figure out what to do? If taken seriously, that implies Alan's right about defining a separate motion command with shift-motion-selects behavior. BTW, this was a key[sic] strategy to get shifted-motion-selects past Ye Olde Guard who detested CUA. Ye Olde Guard don't use no steenkin' arrows (IIRC some versions of the Happy Hacker keyboard don't have arrows at all). It doesn't bother the Windows Volk either, since they are usually a bit upset that C-f doesn't invoke Find. ;-) Cheers! ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Interactive hat. 2009-03-25 10:30 ` Interactive hat Miles Bader 2009-03-25 10:53 ` Alan Mackenzie @ 2009-03-25 16:18 ` Stefan Monnier 1 sibling, 0 replies; 33+ messages in thread From: Stefan Monnier @ 2009-03-25 16:18 UTC (permalink / raw) To: Miles Bader; +Cc: Alan Mackenzie, emacs-devel >> How is an external library writer going to use the interactive "^"? >> Assuming that the library should also work under XEmacs and Emacs 22, >> just using the "^" won't work; an interactive string with "^" throws an >> error in Emacs 22. > Isn't that a pretty basic problem with _any_ extension to interactive? Indeed. > Do you think `interactive' should never be extended? Indeed no. > In this case, I think the right solution would be to simply add another, > possibly clunkier method for commands to indicate they want to enable > shift-selection behavior. It needs to be easy to translate any `interactive' string into an `interactive' Elisp expression. Currently, that's not always the case, and I think it's a problem that needs to be solved. If you start with an `interactive' string and later need to add an argument which needs fancier treatment, you sometimes end up struggling to find an equivalent Elisp form for each of your arguments. Yes, this is indeed a problem. Of course, not specific to "^". If someone were to rewrite `call-interactive' such that it comes with a alist associating each char-code to the corresponding Elisp expression, that would be very helpful (and we could then even provide a command in emacs-lisp-mode to automatically turn a (interactive "foo") into (interactive (blabla))). Stefan ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Interactive hat. [Was: CUA-like stuff spuriously enables transient-mark-mode] 2009-03-25 10:16 ` Interactive hat. [Was: CUA-like stuff spuriously enables transient-mark-mode] Alan Mackenzie 2009-03-25 10:30 ` Interactive hat Miles Bader @ 2009-03-25 11:26 ` Juanma Barranquero 2009-03-25 13:20 ` Interactive hat Chong Yidong 2009-03-25 14:19 ` Interactive hat. [Was: CUA-like stuff spuriously enables transient-mark-mode] Alan Mackenzie 1 sibling, 2 replies; 33+ messages in thread From: Juanma Barranquero @ 2009-03-25 11:26 UTC (permalink / raw) To: Alan Mackenzie; +Cc: Stefan Monnier, emacs-devel On Wed, Mar 25, 2009 at 11:16, Alan Mackenzie <acm@muc.de> wrote: > The next try is to use a macro which will generate an appropriate > interactive string. Something like: > > (defmacro foo-interactive (s-22 s-23) > "doc string" > `(interactive ,(if (emacs-got-interactive-hat) s-23 s22))) > > , but I can't get defun to take a macro-generated interactive string. I > suspect it's not possible. It seems to work, sort of, in byte-compiled > defuns. It is not possible to use the `interactive-form' symbol property, as documented in (elisp)"21.2.1 Using `interactive'" ? Juanma ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Interactive hat. 2009-03-25 11:26 ` Interactive hat. [Was: CUA-like stuff spuriously enables transient-mark-mode] Juanma Barranquero @ 2009-03-25 13:20 ` Chong Yidong 2009-03-25 14:19 ` Interactive hat. [Was: CUA-like stuff spuriously enables transient-mark-mode] Alan Mackenzie 1 sibling, 0 replies; 33+ messages in thread From: Chong Yidong @ 2009-03-25 13:20 UTC (permalink / raw) To: Juanma Barranquero; +Cc: Alan Mackenzie, Stefan Monnier, emacs-devel Juanma Barranquero <lekktu@gmail.com> writes: > It is not possible to use the `interactive-form' symbol property, as > documented in (elisp)"21.2.1 Using `interactive'" ? I think we have a winner. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Interactive hat. [Was: CUA-like stuff spuriously enables transient-mark-mode] 2009-03-25 11:26 ` Interactive hat. [Was: CUA-like stuff spuriously enables transient-mark-mode] Juanma Barranquero 2009-03-25 13:20 ` Interactive hat Chong Yidong @ 2009-03-25 14:19 ` Alan Mackenzie 2009-03-25 16:41 ` Juanma Barranquero 1 sibling, 1 reply; 33+ messages in thread From: Alan Mackenzie @ 2009-03-25 14:19 UTC (permalink / raw) To: Juanma Barranquero; +Cc: Stefan Monnier, emacs-devel Hi, Juanma, On Wed, Mar 25, 2009 at 12:26:58PM +0100, Juanma Barranquero wrote: > On Wed, Mar 25, 2009 at 11:16, Alan Mackenzie <acm@muc.de> wrote: > > The next try is to use a macro which will generate an appropriate > > interactive string. Something like: > > (defmacro foo-interactive (s-22 s-23) > > "doc string" > > `(interactive ,(if (emacs-got-interactive-hat) s-23 s22))) > > , but I can't get defun to take a macro-generated interactive string. I > > suspect it's not possible. It seems to work, sort of, in byte-compiled > > defuns. > It is not possible to use the `interactive-form' symbol property, as > documented in (elisp)"21.2.1 Using `interactive'" ? I don't think so. `interactive-form' is a DEFUN (in data.c) which hoiks the interactive string out of three different places for three different sorts of defun. There's currently no `put-interactive-form', but there's no reason why one couldn't be written. > Juanma -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Interactive hat. [Was: CUA-like stuff spuriously enables transient-mark-mode] 2009-03-25 14:19 ` Interactive hat. [Was: CUA-like stuff spuriously enables transient-mark-mode] Alan Mackenzie @ 2009-03-25 16:41 ` Juanma Barranquero 2009-03-26 12:44 ` Alan Mackenzie 0 siblings, 1 reply; 33+ messages in thread From: Juanma Barranquero @ 2009-03-25 16:41 UTC (permalink / raw) To: Alan Mackenzie; +Cc: Stefan Monnier, emacs-devel On Wed, Mar 25, 2009 at 15:19, Alan Mackenzie <acm@muc.de> wrote: > I don't think so. `interactive-form' is a DEFUN (in data.c) which hoiks > the interactive string out of three different places for three different > sorts of defun. I don't think I'm understanding you. I'm talking about the `interactive-form' symbol property, not the `interactive-form' function. I.e.: The `interactive' form must be located at top-level in the function body, or in the function symbol's `interactive-form' property (*note Symbol Plists::). It has its effect because the command loop looks for it before calling the function (*note Interactive Call::). Once the function is called, all its body forms are executed; at this time, if the `interactive' form occurs within the body, the form simply returns `nil' without even evaluating its argument. ELISP> (defun test (&optional arg) (message "Arg = %S" arg)) test ELISP> (commandp 'test) nil ELISP> (put 'test 'interactive-form '(interactive "p")) (interactive "p") ELISP> (commandp 'test) t ELISP> (call-interactively #'test) "Arg = 1" ELISP> > There's currently no `put-interactive-form', but > there's no reason why one couldn't be written. What does that gain over (put SYMBOL 'interactive-form INTERACTIVE-SPEC) ? Juanma ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Interactive hat. [Was: CUA-like stuff spuriously enables transient-mark-mode] 2009-03-25 16:41 ` Juanma Barranquero @ 2009-03-26 12:44 ` Alan Mackenzie 2009-03-26 13:50 ` Interactive hat Stefan Monnier 0 siblings, 1 reply; 33+ messages in thread From: Alan Mackenzie @ 2009-03-26 12:44 UTC (permalink / raw) To: Juanma Barranquero; +Cc: Stefan Monnier, emacs-devel Hi, Juanma, On Wed, Mar 25, 2009 at 05:41:01PM +0100, Juanma Barranquero wrote: > On Wed, Mar 25, 2009 at 15:19, Alan Mackenzie <acm@muc.de> wrote: > > I don't think so. `interactive-form' is a DEFUN (in data.c) which hoiks > > the interactive string out of three different places for three different > > sorts of defun. > I don't think I'm understanding you. I'm talking about the > `interactive-form' symbol property, not the `interactive-form' > function. I.e.: > > The `interactive' form must be located at top-level in the > function body, or in the function symbol's `interactive-form' > property (*note Symbol Plists::). It has its effect because the > command loop looks for it before calling the function (*note > Interactive Call::). Once the function is called, all its body > forms are executed; at this time, if the `interactive' form occurs > within the body, the form simply returns `nil' without even > evaluating its argument. Sorry, I wasn't aware of this property. It does indeed work, but ONLY in Emacs 23. [ .... ] > > There's currently no `put-interactive-form', but there's no reason > > why one couldn't be written. > What does that gain over (put SYMBOL 'interactive-form INTERACTIVE-SPEC) ? The source for such a function, `put-interactive-form' assuming we could write it in lisp, could be printed in the elisp manual (page "Using Interactive"), and the maintainer of Foo Mode encouraged to copy it into her package and use it to maintain compatibility with older Emacsen and XEmacs, thusly: (defun foo-forward-blag (arg) "Move forward to the end of the current blag, ...." (interactive "^P") .....) (if (not emacs-23) (put-interactive-form 'foo-forward-blag "P")) Alternatively, we could recommend package maintainers not to use "^" directly in interactive strings, instead only putting them in the `interactive-form' property. But this kind of makes the "^" look contrived and kludgey. If we're going to be keeping interactive-hat, I think we definitely need some sort of warning to package maintainers to be careful with it, and we should offer them a recipe for maintaining compatibility. > Juanma -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Interactive hat. 2009-03-26 12:44 ` Alan Mackenzie @ 2009-03-26 13:50 ` Stefan Monnier 2009-03-26 15:27 ` Alan Mackenzie 0 siblings, 1 reply; 33+ messages in thread From: Stefan Monnier @ 2009-03-26 13:50 UTC (permalink / raw) To: Alan Mackenzie; +Cc: Juanma Barranquero, emacs-devel > If we're going to be keeping interactive-hat, I think we definitely need > some sort of warning to package maintainers to be careful with it, and we > should offer them a recipe for maintaining compatibility. I think you're blinded by your hatred of this (mis)feature. It has nothing particularly more special than any other new feature we introduced. Yes, if people use it, they get backward compatibility problems. So what? Stefan ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Interactive hat. 2009-03-26 13:50 ` Interactive hat Stefan Monnier @ 2009-03-26 15:27 ` Alan Mackenzie 2009-03-26 17:09 ` Stefan Monnier 0 siblings, 1 reply; 33+ messages in thread From: Alan Mackenzie @ 2009-03-26 15:27 UTC (permalink / raw) To: Stefan Monnier; +Cc: Juanma Barranquero, emacs-devel Hi, Stefan! On Thu, Mar 26, 2009 at 09:50:27AM -0400, Stefan Monnier wrote: > > If we're going to be keeping interactive-hat, I think we definitely need > > some sort of warning to package maintainers to be careful with it, and we > > should offer them a recipe for maintaining compatibility. > I think you're blinded by your hatred of this (mis)feature. Yes, I hate this feature. But rather than blinding me, this has opened my eyes to its problems, and I am thus motivated to root them out. By contrast, those who like the feature will be blind to these problems. > It has nothing particularly more special than any other new feature > we introduced. Sorry, I disagree. > Yes, if people use it, they get backward compatibility problems. > So what? OK, I'm speaking here as a representative of external package maintainers, even if not elected. I don't feel it's appropriate to be so cavalier with external hackers' time and effort. More than once, in the past 8 or 9 years, I've asked myself "what were these idiots thinking about when they implemented this?". It's not good to encourage package maintainers to think of the Emacs core team as idiots, especially since I've become one myself ;-). It is not a good use of hackers' time and energy to keep reinventing the wheel. It isn't fun working round incompatibilities between various (X)Emacs versions. Really it isn't. It's boring, it's drudgery, isn't at all creative, saps enthusiasm and it diverts effort from adding new snazzy features. This particular feature is an order of magnitude nastier to field than most. A typical conscientious package maintainer is going to go through all the thoughts that we've posting on emacs-devel, and most of the time will come up with some sub-optimal half-solution. Probably, they'll just decide not to use "^". At the end of it all, a weekend's hacking time per hacker has been lost. ######################################################################### Anyhow, I've discovered that this problem is not new, and it's already been solved. XEmacs put a "_" into their interactive string long ago, and there's a macro `defunx' in antlr-mode.el which, when used in place of `defun', strips out the "_" from an interactive string; OK, it does a few other things, too. How about adapting this macro and putting it into a special source file in .../lisp/, and making a discreet mention of it in "Using Interactive" in the elisp manual? For example: "Note that using \"^\" will prevent your function running in older Emacs versions. If you need this compatibility, consider using the macro `defunh' in the file lisp/compatibility.el.". I would far rather put the work in here and now than have to field complaints on bug-cc-mode in a year's time, asking why the CC Mode commands don't work with shift-select-mode. So, how about it? This solution will leave interactive-hat, as it is currently implemented, untouched, and it will stop me moaning about it for ever. > Stefan -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Interactive hat. 2009-03-26 15:27 ` Alan Mackenzie @ 2009-03-26 17:09 ` Stefan Monnier 2009-03-26 19:06 ` Alan Mackenzie 0 siblings, 1 reply; 33+ messages in thread From: Stefan Monnier @ 2009-03-26 17:09 UTC (permalink / raw) To: Alan Mackenzie; +Cc: Juanma Barranquero, emacs-devel > Yes, I hate this feature. But rather than blinding me, this has opened > my eyes to its problems, and I am thus motivated to root them out. By > contrast, those who like the feature will be blind to these problems. The feature is a result of a long and painful process. I have no intention to go through it again. I think the result is pretty clean, so I'm not open to changing it, except for minor aspects. > Anyhow, I've discovered that this problem is not new, and it's already > been solved. XEmacs put a "_" into their interactive string long ago, > and there's a macro `defunx' in antlr-mode.el which, when used in place > of `defun', strips out the "_" from an interactive string; OK, it does a > few other things, too. > How about adapting this macro and putting it into a special source file > in .../lisp/, and making a discreet mention of it in "Using Interactive" > in the elisp manual? For example: "Note that using \"^\" will prevent > your function running in older Emacs versions. If you need this > compatibility, consider using the macro `defunh' in the file > lisp/compatibility.el.". > I would far rather put the work in here and now than have to field > complaints on bug-cc-mode in a year's time, asking why the CC Mode > commands don't work with shift-select-mode. > So, how about it? This solution will leave interactive-hat, as it is > currently implemented, untouched, and it will stop me moaning about it > for ever. What about my other suggestion to make it available to interactive specs using a Lisp form rather than a string? That would seem a lot simpler and cleaner. So, I've indeed done that, which incidentally simplifies the code. Now inserting a "^" in the interactive string is just the same as calling (handle-shift-selection), so you can write (interactive (progn (if (fboundp 'handle-shift-selection) (handle-shift-selection)) ...blabla...)) -- Stefan ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Interactive hat. 2009-03-26 17:09 ` Stefan Monnier @ 2009-03-26 19:06 ` Alan Mackenzie 2009-03-26 21:18 ` Stefan Monnier 0 siblings, 1 reply; 33+ messages in thread From: Alan Mackenzie @ 2009-03-26 19:06 UTC (permalink / raw) To: Stefan Monnier; +Cc: Juanma Barranquero, emacs-devel Hi, Stefan! On Thu, Mar 26, 2009 at 01:09:48PM -0400, Stefan Monnier wrote: > > Yes, I hate this feature. But rather than blinding me, this has > > opened my eyes to its problems, and I am thus motivated to root them > > out. By contrast, those who like the feature will be blind to these > > problems. > The feature is a result of a long and painful process. I have no > intention to go through it again. I think the result is pretty clean, > so I'm not open to changing it, except for minor aspects. The process was painful in the extreme, I remember it well. I don't want to go through it again either. I'm confident that my suggestion below doesn't change the status quo; it justs adds a facility for external maintainers. > > Anyhow, I've discovered that this problem is not new, and it's > > already been solved. XEmacs put a "_" into their interactive string > > long ago, and there's a macro `defunx' in antlr-mode.el which, when > > used in place of `defun', strips out the "_" from an interactive > > string; OK, it does a few other things, too. > > How about adapting this macro and putting it into a special source > > file in .../lisp/, and making a discreet mention of it in "Using > > Interactive" in the elisp manual? For example: "Note that using > > \"^\" will prevent your function running in older Emacs versions. If > > you need this compatibility, consider using the macro `defunh' in the > > file lisp/compatibility.el.". > > I would far rather put the work in here and now than have to field > > complaints on bug-cc-mode in a year's time, asking why the CC Mode > > commands don't work with shift-select-mode. > > So, how about it? This solution will leave interactive-hat, as it is > > currently implemented, untouched, and it will stop me moaning about it > > for ever. > What about my other suggestion to make it available to interactive > specs using a Lisp form rather than a string? That would seem a lot > simpler and cleaner. I'm assuming an external package maintainer wanting to use (interactive "^P\nr"), still have the command work in Emacs <23 and XEmacs, yet not have to waste time working out for herself how to achieve this. I think I might have misunderstood your suggestion. > So, I've indeed done that, which incidentally simplifies the code. > Now inserting a "^" in the interactive string is just the same as > calling (handle-shift-selection), so you can write > (interactive > (progn (if (fboundp 'handle-shift-selection) (handle-shift-selection)) > ...blabla...)) No, that's not simpler or clearer. It's just pushing the work onto the package maintainer. And it's a LOT of work. For example, (interactive "^P\nr") becomes (interactive (progn (if (fboundp 'handle-shift-selection) (handle-shift-selection)) `(current-prefix-arg ,(if (< (point) (mark)) ,@((point) (mark)) ,@((mark) (point)))))) , or something equally repulsive, requiring infinitely more debugging than the string it replaces. My proposal is to suggest to the maintainer she copy the macro from .../lisp/compatibility.el into her own sources, rename it `foo-defunh'[*] and write: [*] think of this as a hyperbolic defun. ;-) (foo-defunh foo-forward-blarg (arg beg end) "..." (interactive "^P\nr") ....) Although there's a certain tedium involved in that suggestion, it's a straightforward recipe that doesn't require thinking. > -- Stefan -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Interactive hat. 2009-03-26 19:06 ` Alan Mackenzie @ 2009-03-26 21:18 ` Stefan Monnier 2009-03-26 22:32 ` Johan Bockgård 2009-03-26 23:32 ` Alan Mackenzie 0 siblings, 2 replies; 33+ messages in thread From: Stefan Monnier @ 2009-03-26 21:18 UTC (permalink / raw) To: Alan Mackenzie; +Cc: Juanma Barranquero, emacs-devel > No, that's not simpler or clearer. It's just pushing the work onto the > package maintainer. And it's a LOT of work. For example, > (interactive "^P\nr") > becomes > (interactive > (progn (if (fboundp 'handle-shift-selection) > (handle-shift-selection)) > `(current-prefix-arg > ,(if (< (point) (mark)) > ,@((point) (mark)) > ,@((mark) (point)))))) Yes, that's because "r" hasn't yet received the treatment I just gave to "^". As explained in my message of a couple days ago, it should always be easy to turn an interactive string into the corresponding lisp form. > , or something equally repulsive, requiring infinitely more debugging > than the string it replaces. Actually, in all likelyhood, (interactive (progn (if (fboundp 'handle-shift-selection) (handle-shift-selection)) (list current-prefix-arg (point) (mark)))) will work just fine (in 99% of the cases, the subsequent code has to figure out anyway whether `start' is indeed before `end' in case the function is called from Lisp rather than interactively). So you're exaggerating a little bit. > My proposal is to suggest to the maintainer she copy the macro from > .../lisp/compatibility.el into her own sources, rename it > `foo-defunh'[*] and write: Feel free to recommend it. I find it hideous. Stefan ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Interactive hat. 2009-03-26 21:18 ` Stefan Monnier @ 2009-03-26 22:32 ` Johan Bockgård 2009-03-26 23:34 ` Alan Mackenzie 2009-03-26 23:32 ` Alan Mackenzie 1 sibling, 1 reply; 33+ messages in thread From: Johan Bockgård @ 2009-03-26 22:32 UTC (permalink / raw) To: emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: > (list current-prefix-arg (point) (mark)))) region-beginning/region-end ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Interactive hat. 2009-03-26 22:32 ` Johan Bockgård @ 2009-03-26 23:34 ` Alan Mackenzie 0 siblings, 0 replies; 33+ messages in thread From: Alan Mackenzie @ 2009-03-26 23:34 UTC (permalink / raw) To: emacs-devel Hi, Johan! On Thu, Mar 26, 2009 at 11:32:42PM +0100, Johan Bockgård wrote: > Stefan Monnier <monnier@iro.umontreal.ca> writes: > > (list current-prefix-arg (point) (mark)))) > region-beginning/region-end Thanks for that! It's so easy to lose track of the obvious in the heat of debate. -- Alan Mackenzie (Nuremberg, Germany) ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Interactive hat. 2009-03-26 21:18 ` Stefan Monnier 2009-03-26 22:32 ` Johan Bockgård @ 2009-03-26 23:32 ` Alan Mackenzie 2009-03-27 2:50 ` Stefan Monnier 1 sibling, 1 reply; 33+ messages in thread From: Alan Mackenzie @ 2009-03-26 23:32 UTC (permalink / raw) To: Stefan Monnier; +Cc: Juanma Barranquero, emacs-devel Hi, Stefan! On Thu, Mar 26, 2009 at 05:18:05PM -0400, Stefan Monnier wrote: > > No, that's not simpler or clearer. It's just pushing the work onto the > > package maintainer. And it's a LOT of work. For example, > > (interactive "^P\nr") > > becomes > > (interactive > > (progn (if (fboundp 'handle-shift-selection) > > (handle-shift-selection)) > > `(current-prefix-arg > > ,(if (< (point) (mark)) > > ,@((point) (mark)) > > ,@((mark) (point)))))) > Yes, that's because "r" hasn't yet received the treatment I just gave > to "^". As explained in my message of a couple days ago, it should > always be easy to turn an interactive string into the corresponding > lisp form. > > , or something equally repulsive, requiring infinitely more debugging > > than the string it replaces. > Actually, in all likelyhood, > (interactive > (progn (if (fboundp 'handle-shift-selection) > (handle-shift-selection)) > (list current-prefix-arg (point) (mark)))) OK, perhaps I was exaggerating a bit. > will work just fine (in 99% of the cases, the subsequent code has to > figure out anyway whether `start' is indeed before `end' in case the > function is called from Lisp rather than interactively). So you're > exaggerating a little bit. I think we'd both go with Johan's (region-beginning) and (region-end). > > My proposal is to suggest to the maintainer she copy the macro from > > .../lisp/compatibility.el into her own sources, rename it > > `foo-defunh'[*] and write: > Feel free to recommend it. I find it hideous. Actually I'm rather surprised about that. But as I said, my main aim here is to minimise the time and mental effort the change will cause package maintainers. How about I take your suggestion as meaning that page "Interactive Codes" should be enhanced to give the lisp equivalent for each code letter, and it is made clear that the string version is a convenient abbreviation which works nearly all the time, and the lisp code is the fully general version? I could even write a patch. Just not tonight. > Stefan -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Interactive hat. 2009-03-26 23:32 ` Alan Mackenzie @ 2009-03-27 2:50 ` Stefan Monnier 2009-03-27 11:15 ` Alan Mackenzie 0 siblings, 1 reply; 33+ messages in thread From: Stefan Monnier @ 2009-03-27 2:50 UTC (permalink / raw) To: Alan Mackenzie; +Cc: Juanma Barranquero, emacs-devel > How about I take your suggestion as meaning that page "Interactive Codes" > should be enhanced to give the lisp equivalent for each code letter, and > it is made clear that the string version is a convenient abbreviation > which works nearly all the time, and the Lisp code is the fully general > version? That's the idea, yes. Additionally, the equivalent Lisp code should be simple (a single funcall), which isn't always possible right now, IIRC. Stefan ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Interactive hat. 2009-03-27 2:50 ` Stefan Monnier @ 2009-03-27 11:15 ` Alan Mackenzie 0 siblings, 0 replies; 33+ messages in thread From: Alan Mackenzie @ 2009-03-27 11:15 UTC (permalink / raw) To: Stefan Monnier; +Cc: Juanma Barranquero, emacs-devel Hi, Stefan, On Thu, Mar 26, 2009 at 10:50:11PM -0400, Stefan Monnier wrote: > > How about I take your suggestion as meaning that page "Interactive > > Codes" should be enhanced to give the lisp equivalent for each code > > letter, and it is made clear that the string version is a convenient > > abbreviation which works nearly all the time, and the Lisp code is > > the fully general version? > That's the idea, yes. Additionally, the equivalent Lisp code should > be simple (a single funcall), which isn't always possible right now, > IIRC. OK, I'll get on with that. Hopefully, I'll post a patch to commands.texi in the next few days. Thanks for all the arguments! > Stefan -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 33+ messages in thread
end of thread, other threads:[~2009-03-29 2:02 UTC | newest] Thread overview: 33+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2009-03-27 0:20 Interactive hat naesten [not found] <20090323223703.GA5650@muc.de> [not found] ` <jwvfxh392k9.fsf-monnier+emacsbugreports@gnu.org> [not found] ` <20090324135210.GA4657@muc.de> [not found] ` <jwvzlfacrk0.fsf-monnier+emacsbugreports@gnu.org> 2009-03-25 10:16 ` Interactive hat. [Was: CUA-like stuff spuriously enables transient-mark-mode] Alan Mackenzie 2009-03-25 10:30 ` Interactive hat Miles Bader 2009-03-25 10:53 ` Alan Mackenzie 2009-03-25 11:03 ` Lennart Borgman 2009-03-25 14:24 ` Alan Mackenzie 2009-03-26 11:29 ` Alan Mackenzie 2009-03-25 14:59 ` Miles Bader 2009-03-26 11:51 ` Alan Mackenzie 2009-03-26 12:14 ` David Kastrup 2009-03-26 12:51 ` Alan Mackenzie 2009-03-26 13:48 ` Stefan Monnier 2009-03-26 14:33 ` Alan Mackenzie 2009-03-26 16:30 ` Stefan Monnier 2009-03-26 16:45 ` Alan Mackenzie 2009-03-26 18:57 ` Stefan Monnier 2009-03-29 0:44 ` Kim F. Storm 2009-03-29 1:40 ` Miles Bader 2009-03-29 2:02 ` Lennart Borgman 2009-03-26 14:47 ` Stephen J. Turnbull 2009-03-26 15:23 ` Miles Bader 2009-03-26 17:43 ` Stephen J. Turnbull 2009-03-25 16:18 ` Stefan Monnier 2009-03-25 11:26 ` Interactive hat. [Was: CUA-like stuff spuriously enables transient-mark-mode] Juanma Barranquero 2009-03-25 13:20 ` Interactive hat Chong Yidong 2009-03-25 14:19 ` Interactive hat. [Was: CUA-like stuff spuriously enables transient-mark-mode] Alan Mackenzie 2009-03-25 16:41 ` Juanma Barranquero 2009-03-26 12:44 ` Alan Mackenzie 2009-03-26 13:50 ` Interactive hat Stefan Monnier 2009-03-26 15:27 ` Alan Mackenzie 2009-03-26 17:09 ` Stefan Monnier 2009-03-26 19:06 ` Alan Mackenzie 2009-03-26 21:18 ` Stefan Monnier 2009-03-26 22:32 ` Johan Bockgård 2009-03-26 23:34 ` Alan Mackenzie 2009-03-26 23:32 ` Alan Mackenzie 2009-03-27 2:50 ` Stefan Monnier 2009-03-27 11:15 ` Alan Mackenzie
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).