unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* kmacro.texi
@ 2004-11-30  4:30 Luc Teirlinck
  2004-11-30  9:53 ` kmacro.texi Kim F. Storm
                   ` (2 more replies)
  0 siblings, 3 replies; 10+ messages in thread
From: Luc Teirlinck @ 2004-11-30  4:30 UTC (permalink / raw)


I propose the following changes to man/kmacro.texi.  If they look OK,
I also will propose some (smaller) changes to docstrings.

I believe that we already decided earlier to move some sections to
emacs-xtra.

I believe that `(emacs)Keyboard Macro Counter' and `(emacs)Keyboard
Macro Step-Edit' are specialized sections and should be moved to
emacs-xtra.  Would that be OK?  Of course their functionality would
still be (briefly) described in kmacro.texi and xrefs would be
provided, so the interested reader still has the info one RET or mouse
click away.  It would just keep the size of the printed manual down.
`(emacs)Keyboard Macro Counter' has been expanded and made more
accurate in anticipation of a move to emacs-xtra where space is not at
a premium.  I have left `(emacs)Keyboard Macro Step-Edit' unchanged,
but `(emacs)Edit Keyboard Macro' already explains, much more briefly,
an easier to learn alternative way to edit kmacros.

We also decided some moths ago that it would be good to move
kmacro.texi back to after the discussion of key bindings and related
topics, which `(emacs)Save Keyboard Macro' heavily relies on.  Is this
still OK?  Currently, `(emacs)Save Keyboard Macro' is nearly
impossible to understand for a reader reading the manual back to
front.

I submit a patch without those "moving around" changes, because I want
to separate that from the actual content changes in the patch below.

===File ~/kmacro.texi-diff==================================
diff -c /home/teirllm/emacscvsdir/emacs/man/kmacro.texi.\~1.7.\~ /home/teirllm/emacscvsdir/emacs/man/kmacro.texi
*** /home/teirllm/emacscvsdir/emacs/man/kmacro.texi.~1.7.~	Mon Nov 29 22:00:51 2004
--- /home/teirllm/emacscvsdir/emacs/man/kmacro.texi	Mon Nov 29 19:21:05 2004
***************
*** 120,130 ****
  indefinitely (until it gets an error or you type @kbd{C-g} or, on
  MS-DOS, @kbd{C-@key{BREAK}}).
  
- @kindex C-x C-k C-s
- @kindex C-x C-k C-k
- Alternatively, you can use @kbd{C-x C-k C-s} to start a keyboard macro,
- and @kbd{C-x C-k C-k...} to end and execute it.
- 
    If you wish to repeat an operation at regularly spaced places in the
  text, define a macro and include as part of the macro the commands to move
  to the next place you want to use it.  For example, if you want to change
--- 120,125 ----
***************
*** 185,191 ****
  a list of sequences of keys.  There is only one keyboard macro ring,
  shared by all buffers.
  
!   All commands which operates on the keyboard macro ring use the
  same @kbd{C-x C-k} prefix.  Most of these commands can be executed and
  repeated immediately after each other without repeating the @kbd{C-x
  C-k} prefix.  For example,
--- 180,186 ----
  a list of sequences of keys.  There is only one keyboard macro ring,
  shared by all buffers.
  
!   All commands which operate on the keyboard macro ring use the
  same @kbd{C-x C-k} prefix.  Most of these commands can be executed and
  repeated immediately after each other without repeating the @kbd{C-x
  C-k} prefix.  For example,
***************
*** 207,218 ****
  repeat the macro immediately by typing another @kbd{C-k}, or you can
  rotate the macro ring immediately by typing @kbd{C-n} or @kbd{C-p}.
  
  @findex kmacro-cycle-ring-next
  @kindex C-x C-k C-n
  @findex kmacro-cycle-ring-previous
  @kindex C-x C-k C-p
    The commands @kbd{C-x C-k C-n} (@code{kmacro-cycle-ring-next}) and
! @kbd{C-x C-k C-p} (@code{kmacro-cycle-ring-previous}) rotates the
  macro ring, bringing the next or previous keyboard macro to the head
  of the macro ring.  The definition of the new head macro is displayed
  in the echo area.  You can continue to rotate the macro ring
--- 202,218 ----
  repeat the macro immediately by typing another @kbd{C-k}, or you can
  rotate the macro ring immediately by typing @kbd{C-n} or @kbd{C-p}.
  
+ When a keyboard macro is being defined, @kbd{C-x C-k C-k} behaves like
+ @kbd{C-x )} except that, immediately afterward, you can use most key
+ bindings of this section without the @kbd{C-x C-k} prefix.  For
+ instance, another @kbd{C-k} will re-execute the macro.
+ 
  @findex kmacro-cycle-ring-next
  @kindex C-x C-k C-n
  @findex kmacro-cycle-ring-previous
  @kindex C-x C-k C-p
    The commands @kbd{C-x C-k C-n} (@code{kmacro-cycle-ring-next}) and
! @kbd{C-x C-k C-p} (@code{kmacro-cycle-ring-previous}) rotate the
  macro ring, bringing the next or previous keyboard macro to the head
  of the macro ring.  The definition of the new head macro is displayed
  in the echo area.  You can continue to rotate the macro ring
***************
*** 227,240 ****
  @findex kmacro-view-macro-repeat
  @kindex C-x C-k C-v
  
!   The commands @kbd{C-x C-k C-v} (@code{kmacro-view-macro-repeat})
  displays the last keyboard macro, or when repeated (with @kbd{C-v}),
  it displays the previous macro on the macro ring, just like @kbd{C-x
  C-k C-p}, but without actually rotating the macro ring.  If you enter
  @kbd{C-k} immediately after displaying a macro from the ring, that
  macro is executed, but still without altering the macro ring.
  
!   So while e.g. @kbd{C-x C-k C-p C-p C-k C-k} makes the 3rd previous
  macro the current macro and executes it twice, @kbd{C-x C-k C-v C-v
  C-v C-k C-k} will display and execute the 3rd previous macro once and
  then the current macro once.
--- 227,240 ----
  @findex kmacro-view-macro-repeat
  @kindex C-x C-k C-v
  
!   The command @kbd{C-x C-k C-v} (@code{kmacro-view-macro-repeat})
  displays the last keyboard macro, or when repeated (with @kbd{C-v}),
  it displays the previous macro on the macro ring, just like @kbd{C-x
  C-k C-p}, but without actually rotating the macro ring.  If you enter
  @kbd{C-k} immediately after displaying a macro from the ring, that
  macro is executed, but still without altering the macro ring.
  
!   So while e.g. @kbd{C-x C-k C-p C-p C-p C-k C-k} makes the 3rd previous
  macro the current macro and executes it twice, @kbd{C-x C-k C-v C-v
  C-v C-k C-k} will display and execute the 3rd previous macro once and
  then the current macro once.
***************
*** 242,248 ****
  @findex kmacro-delete-ring-head
  @kindex C-x C-k C-d
  
!   The commands @kbd{C-x C-k C-d} (@code{kmacro-delete-ring-head})
  removes and deletes the macro currently at the head of the macro
  ring.  You can use this to delete a macro that didn't work as
  expected, or which you don't need anymore.
--- 242,248 ----
  @findex kmacro-delete-ring-head
  @kindex C-x C-k C-d
  
!   The command @kbd{C-x C-k C-d} (@code{kmacro-delete-ring-head})
  removes and deletes the macro currently at the head of the macro
  ring.  You can use this to delete a macro that didn't work as
  expected, or which you don't need anymore.
***************
*** 250,270 ****
  @findex kmacro-swap-ring
  @kindex C-x C-k C-t
  
!   The commands @kbd{C-x C-k C-t} (@code{kmacro-swap-ring})
  interchanges the head of the macro ring with the previous element on
  the macro ring.
  
  @findex kmacro-call-ring-2nd-repeat
  @kindex C-x C-k C-l
  
!   The commands @kbd{C-x C-k C-l} (@code{kmacro-call-ring-2nd-repeat})
  executes the previous (rather than the head) element on the macro ring.
  
  @node Keyboard Macro Counter
  @section The Keyboard Macro Counter
  
!   Each keyboard macro has an associated counter which is automatically
! incremented on every repetition of the keyboard macro.  Normally, the
  macro counter is initialized to 0 when you start defining the macro,
  and incremented by 1 after each insertion of the counter value;
  that is, if you insert the macro counter twice while defining the
--- 250,272 ----
  @findex kmacro-swap-ring
  @kindex C-x C-k C-t
  
!   The command @kbd{C-x C-k C-t} (@code{kmacro-swap-ring})
  interchanges the head of the macro ring with the previous element on
  the macro ring.
  
  @findex kmacro-call-ring-2nd-repeat
  @kindex C-x C-k C-l
  
!   The command @kbd{C-x C-k C-l} (@code{kmacro-call-ring-2nd-repeat})
  executes the previous (rather than the head) element on the macro ring.
  
+   The maximum number of macros stored in the keyboard macro ring is
+ determined by the customizable variable @code{kmacro-ring-max}.
+ 
  @node Keyboard Macro Counter
  @section The Keyboard Macro Counter
  
!   Each keyboard macro has an associated counter.  Normally, the
  macro counter is initialized to 0 when you start defining the macro,
  and incremented by 1 after each insertion of the counter value;
  that is, if you insert the macro counter twice while defining the
***************
*** 275,281 ****
    The command @kbd{C-x C-k C-i} (@code{kmacro-insert-counter}) inserts
  the current value of the keyboard macro counter and increments the
  counter by 1.  You can use a numeric prefix argument to specify a
! different increment.  If you specify a @kbd{C-u} prefix, the last
  inserted counter value is repeated and the counter is not incremented.
  For example, if you enter the following sequence while defining a macro
  
--- 277,283 ----
    The command @kbd{C-x C-k C-i} (@code{kmacro-insert-counter}) inserts
  the current value of the keyboard macro counter and increments the
  counter by 1.  You can use a numeric prefix argument to specify a
! different increment.  If you just specify a @kbd{C-u} prefix, the last
  inserted counter value is repeated and the counter is not incremented.
  For example, if you enter the following sequence while defining a macro
  
***************
*** 288,317 ****
  second execution of the macro @samp{3445} and @samp{6778} are
  inserted.
  
  @findex kmacro-set-counter
  @kindex C-x C-k C-c
    The command @kbd{C-x C-k C-c} (@code{kmacro-set-counter}) prompts
  for the initial value of the keyboard macro counter if you use it
! before you define a keyboard macro.  If you use it while defining a
! keyboard macro, you set the macro counter to the same (initial) value
! on each repetition of the macro.  If you specify a @kbd{C-u} prefix,
! the counter is reset to the value it had prior to the current
! repetition of the macro (undoing any increments so far in this
! repetition).
  
  @findex kmacro-add-counter
  @kindex C-x C-k C-a
    The command @kbd{C-x C-k C-a} (@code{kmacro-add-counter}) prompts
! for a value to add to the macro counter.
  
  @findex kmacro-set-format
  @kindex C-x C-k C-f
!   The command @kbd{C-x C-k C-f} (@code{kmacro-set-format}) prompts
! for the format to use when inserting the macro counter.  The default
! format is @samp{%d}.  If you set the counter format before you define a
! macro, that format is restored before each repetition of the macro.
! Consequently, any changes you make to the macro counter format while
! defining a macro are only active for the rest of the macro.
  
  @node Keyboard Macro Query
  @section Executing Macros with Variations
--- 290,355 ----
  second execution of the macro @samp{3445} and @samp{6778} are
  inserted.
  
+   This command usually only makes sense while defining a keyboard macro.
+ But its behavior when no keyboard macro is being defined or executed
+ is predictable: it inserts and increments the counter of the head of
+ the keyboard macro ring.
+ 
  @findex kmacro-set-counter
  @kindex C-x C-k C-c
    The command @kbd{C-x C-k C-c} (@code{kmacro-set-counter}) prompts
  for the initial value of the keyboard macro counter if you use it
! before you define a keyboard macro.  If you use it before executing a
! keyboard macro, it resets that macro's counter.  If you use it while
! defining a keyboard macro, then the macro counter gets reset to that same
! value on each repetition of the macro.  Rather than having the command
! prompt for a value, you can also specify the value with a numeric
! prefix argument.  If you just specify a @kbd{C-u} prefix, the counter
! is reset to the value it had prior to the current repetition of the
! macro (undoing any increments so far in this repetition).  If you just
! specify a @kbd{C-u} prefix while no macro is being defined or executed,
! then the new value of the counter is essentially unpredictable.
  
  @findex kmacro-add-counter
  @kindex C-x C-k C-a
    The command @kbd{C-x C-k C-a} (@code{kmacro-add-counter}) prompts
! for a value to add to the macro counter.  You can also specify the
! value with a numeric prefix argument.  If you just specify a @kbd{C-u}
! prefix, the counter is reset to the last value inserted by any
! keyboard macro.  Usually, this will only make sense if that value was
! inserted during the current macro definition or repetition.
! 
!   This command normally only makes sense while defining a keyboard macro.
! But its behavior when no keyboard macro is being defined or executed
! is predictable: it affects the counter of the head of the keyboard
! macro ring.
  
  @findex kmacro-set-format
  @kindex C-x C-k C-f
!   The command @kbd{C-x C-k C-f} (@code{kmacro-set-format}) prompts for
! the format to use when inserting the macro counter.  The default
! format is @samp{%d}, which means to insert the number in decimal
! without any padding.  You can exit with empty minibuffer to reset the
! format to this default.  If you know the Elisp function @code{format},
! then you can specify any format string that this function accepts and
! that makes sense with a single integer extra argument
! (@pxref{Formatting Strings,,, elisp, The Emacs Lisp Reference
! Manual}).  Do not put the format string inside double quotes when you
! insert it in the minibuffer.
! 
! If you use this command while no keyboard macro is being defined or
! executed, the new format will affect all new macros.  Existing macros
! will continue to use the format in effect when they were defined.  If
! you set the format while defining a keyboard macro, then this affects
! the macro being defined from that point on, but it will not affect
! subsequent macros.  During execution of a macro, the macro will, at
! each step, use the format in effect at that step during its
! definition.  Changes to the macro format during execution of a macro,
! like the corresponding changes during its definition, have no effect
! on subsequent macros.
! 
! The format set by @kbd{C-x C-k C-f} does not affect insertion of
! numbers stored in registers.
  
  @node Keyboard Macro Query
  @section Executing Macros with Variations
***************
*** 378,391 ****
  @cindex binding keyboard macros
  @findex kmacro-bind-to-key
  @kindex C-x C-k b
!   You can also bind the last keyboard macro to a key, using
! @kbd{C-x C-k b} (@code{kmacro-bind-to-key}) followed by the
! key sequence you want the keyboard macro to be bound to.  You can
! bind to any key sequence in the global keymap, but since most key
! sequences already have other bindings, you should select the key
! sequence carefully.  If you try to bind to a key sequence with an
! existing binding (in any keymap), you will be asked if you really
! want to replace the existing binding of that key.
  
  To avoid problems caused by overriding existing bindings, the key
  sequences @kbd{C-x C-k 0} through @kbd{C-x C-k 9} and @kbd{C-x C-k A}
--- 416,429 ----
  @cindex binding keyboard macros
  @findex kmacro-bind-to-key
  @kindex C-x C-k b
!   You can also bind the last keyboard macro (in its current form) to a
! key, using @kbd{C-x C-k b} (@code{kmacro-bind-to-key}) followed by the
! key sequence you want the keyboard macro to be bound to.  You can bind
! to any key sequence in the global keymap, but since most key sequences
! already have other bindings, you should select the key sequence
! carefully.  If you try to bind to a key sequence with an existing
! binding (in any keymap), you will be asked if you really want to
! replace the existing binding of that key.
  
  To avoid problems caused by overriding existing bindings, the key
  sequences @kbd{C-x C-k 0} through @kbd{C-x C-k 9} and @kbd{C-x C-k A}

Diff finished.  Mon Nov 29 22:01:10 2004
============================================================

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: kmacro.texi
  2004-11-30  4:30 kmacro.texi Luc Teirlinck
@ 2004-11-30  9:53 ` Kim F. Storm
  2004-12-01  2:57 ` kmacro.texi Richard Stallman
  2004-12-01  2:57 ` kmacro.texi Richard Stallman
  2 siblings, 0 replies; 10+ messages in thread
From: Kim F. Storm @ 2004-11-30  9:53 UTC (permalink / raw)
  Cc: emacs-devel

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> I propose the following changes to man/kmacro.texi.  If they look OK,

They are _really_ good.  Thanks.

> I believe that `(emacs)Keyboard Macro Counter' and `(emacs)Keyboard
> Macro Step-Edit' are specialized sections and should be moved to
> emacs-xtra.  Would that be OK?  

Since macros are the "poor mans" Lisp functions, I think the macro
counter is an important feature of macros (personally, I use them
quite often), so unless there are strong reasons to omit them,
I think they should be described in the printed manual.

It's ok to move the step-edit part to emacs-xtra.


> I have left `(emacs)Keyboard Macro Step-Edit' unchanged,
> but `(emacs)Edit Keyboard Macro' already explains, much more briefly,
> an easier to learn alternative way to edit kmacros.

True.

>
> We also decided some moths ago that it would be good to move
> kmacro.texi back to after the discussion of key bindings and related
> topics, which `(emacs)Save Keyboard Macro' heavily relies on.  Is this
> still OK?  Currently, `(emacs)Save Keyboard Macro' is nearly
> impossible to understand for a reader reading the manual back to
> front.

IIRC, I moved it to its current position (near text editing, search
and replace, etc) because macros basically is more related to
"repeating the same editing" than about key bindings and
customization.

But I wont object to the move if you think that gives a better flow.

>
> I submit a patch without those "moving around" changes, because I want
> to separate that from the actual content changes in the patch below.

I suggest you install these changes in the current position -- and do
the moves in a separate change.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: kmacro.texi
  2004-11-30  4:30 kmacro.texi Luc Teirlinck
  2004-11-30  9:53 ` kmacro.texi Kim F. Storm
@ 2004-12-01  2:57 ` Richard Stallman
  2004-12-01  2:57 ` kmacro.texi Richard Stallman
  2 siblings, 0 replies; 10+ messages in thread
From: Richard Stallman @ 2004-12-01  2:57 UTC (permalink / raw)
  Cc: emacs-devel

    I believe that `(emacs)Keyboard Macro Counter' and `(emacs)Keyboard
    Macro Step-Edit' are specialized sections and should be moved to
    emacs-xtra.  Would that be OK?

Yes, please do.

    We also decided some moths ago that it would be good to move
    kmacro.texi back to after the discussion of key bindings and related
    topics, which `(emacs)Save Keyboard Macro' heavily relies on.  Is this
    still OK?

Yes.

Your changes are basically good, but here are some specific comments.

    +   The maximum number of macros stored in the keyboard macro ring is
    + determined by the customizable variable @code{kmacro-ring-max}.

This calls for an index entry.

    ! format to this default.  If you know the Elisp function @code{format},
    ! then you can specify any format string that this function accepts and
    ! that makes sense with a single integer extra argument

Please change that to

    ! format to this default.   You can specify any format string
    ! that the @code{format} function accepts and
    ! that makes sense with a single integer argument


    ! If you use this command while no keyboard macro is being defined or
    ! executed, the new format will affect all new macros.

Use the present tense: ... the new format affects all subsequent
macro definitions.

      Existing macros
    ! will continue

Likewise, "Existing macros continue..."

      If
    ! you set the format while defining a keyboard macro, then this affects

Please delete "then".

    ! the macro being defined from that point on, but it will not affect

...does not affect

    ! subsequent macros.  During execution of a macro, the macro will, at
    ! each step, use the format in effect at that step during its

Execution of the macro will, at each step...

    !   You can also bind the last keyboard macro (in its current form) to a
    ! key, using @kbd{C-x C-k b} (@code{kmacro-bind-to-key}) followed by the
    ! key sequence you want the keyboard macro to be bound to.

you want to bind.

    ! binding (in any keymap), you will be asked if you really want to
    ! replace the existing binding of that key.

, it asks you for confirmation before replacing the existing binding.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: kmacro.texi
  2004-11-30  4:30 kmacro.texi Luc Teirlinck
  2004-11-30  9:53 ` kmacro.texi Kim F. Storm
  2004-12-01  2:57 ` kmacro.texi Richard Stallman
@ 2004-12-01  2:57 ` Richard Stallman
  2004-12-01 12:06   ` kmacro.texi Kim F. Storm
  2 siblings, 1 reply; 10+ messages in thread
From: Richard Stallman @ 2004-12-01  2:57 UTC (permalink / raw)
  Cc: emacs-devel

Reading your proposed changes to kmacro.texi made me aware that C-x
C-k has become a sort of special command mode, in which many ordinary
commands have special meanings.  That is against the spirit of Emacs,
and going against the spirit of Emacs in something that is rather
obscure and only rarely used is a bad thing.

So I want to get rid of this mode-like feature as it now stands.

However, there is a way it could be implemented, giving similar
results, that would be consistent with the spirit of Emacs: to make
this a major mode.  One command could create a buffer which represents
the macro ring, and switch to it.  That buffer could use a special
major mode in which single-character commands do things like navigate
through this ring.

For instance, if it makes one line per keyboard macro, then moving
point in this buffer could have the effect of rotating the ring.  That
way, C-p and C-n in this buffer would have the desired effect on the
macro ring, merely because they move point (as they usually do) in the
buffer that represents the ring.

Kim, could you work on these changes?
I'd like this feature to be changed before we do a release with it.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: kmacro.texi
  2004-12-01  2:57 ` kmacro.texi Richard Stallman
@ 2004-12-01 12:06   ` Kim F. Storm
  2004-12-02 13:10     ` kmacro.texi Richard Stallman
  0 siblings, 1 reply; 10+ messages in thread
From: Kim F. Storm @ 2004-12-01 12:06 UTC (permalink / raw)
  Cc: Luc Teirlinck, emacs-devel

Richard Stallman <rms@gnu.org> writes:

> Reading your proposed changes to kmacro.texi made me aware that C-x
> C-k has become a sort of special command mode, in which many ordinary
> commands have special meanings.  That is against the spirit of Emacs,

I looked for 'spirit' in the index of the Lisp ref, and didn't find it.

> and going against the spirit of Emacs in something that is rather
> obscure and only rarely used is a bad thing.

Why do you think this is rarely used -- I use it _often_.

And C-x e e e ...  already does something very similar.
Nobody has complained about that so far.

And C-u C-SPC C-SPC C-SPC ...

(Ok, I'm biased, as I added those short-cuts too)

>
> So I want to get rid of this mode-like feature as it now stands.
>
> However, there is a way it could be implemented, giving similar
> results, that would be consistent with the spirit of Emacs: to make
> this a major mode.  One command could create a buffer which represents
> the macro ring, and switch to it.  That buffer could use a special
> major mode in which single-character commands do things like navigate
> through this ring.

Lets consider C-x C-k C-p C-p C-p C-k which rotates the macro ring
three places and executes the resulting head macro.

While the user enters C-x C-k C-p ... the echo area shows the current
macro at the head of the macro ring after each C-p, so in effect it is
much like a major mode -- just using the echo area as a single line
window into the macro ring.

Instead, you want to open a different window to show the macro ring
and select another macro in that window.

However, very often, the macros I write refer to data in several
windows on the screen, i.e. they contain things like C-x o.  E.g. to
navigate between a *grep* buffer and source windows, and back again.

With your proposal, I have to mess up the window layout just to rotate
the macro ring -- I would consider that to be a HUGE drawback compared
to the current functionality.

But there are some nice possibilities with your proposed interface,
so I'll think more about it.

>
> For instance, if it makes one line per keyboard macro, then moving
> point in this buffer could have the effect of rotating the ring.  That
> way, C-p and C-n in this buffer would have the desired effect on the
> macro ring, merely because they move point (as they usually do) in the
> buffer that represents the ring.
>
> Kim, could you work on these changes?

Yes.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: kmacro.texi
  2004-12-01 12:06   ` kmacro.texi Kim F. Storm
@ 2004-12-02 13:10     ` Richard Stallman
  2004-12-02 14:17       ` kmacro.texi Kim F. Storm
  0 siblings, 1 reply; 10+ messages in thread
From: Richard Stallman @ 2004-12-02 13:10 UTC (permalink / raw)
  Cc: teirllm, emacs-devel

    I looked for 'spirit' in the index of the Lisp ref, and didn't find it.

We have never tried to make the Lisp Manual document all the design
principles of Emacs, because that's not part of its job.

    Why do you think this is rarely used -- I use it _often_.

I am sure most users only occasionally define a keyboard macro, and
don't have so many that they need to look at the definitions through a
ring.  Users who define keyboard macros often enough to want this
feature are surely few in number.

    And C-x e e e ...  already does something very similar.
    Nobody has complained about that so far.

    And C-u C-SPC C-SPC C-SPC ...

These are much more limited--but indeed the first of them bothers me.

    With your proposal, I have to mess up the window layout just to rotate
    the macro ring

I don't think that is a valid conclusion.  Exiting this mode
in the "usual" way could restore the old window layout.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: kmacro.texi
  2004-12-02 13:10     ` kmacro.texi Richard Stallman
@ 2004-12-02 14:17       ` Kim F. Storm
  2004-12-04  2:46         ` kmacro.texi Richard Stallman
  0 siblings, 1 reply; 10+ messages in thread
From: Kim F. Storm @ 2004-12-02 14:17 UTC (permalink / raw)
  Cc: teirllm, emacs-devel

Richard Stallman <rms@gnu.org> writes:

> I am sure most users only occasionally define a keyboard macro, and
> don't have so many that they need to look at the definitions through a
> ring.  Users who define keyboard macros often enough to want this
> feature are surely few in number.
>
>     And C-x e e e ...  already does something very similar.
>     Nobody has complained about that so far.
>
>     And C-u C-SPC C-SPC C-SPC ...
>
> These are much more limited--but indeed the first of them bothers me.

We could change the defaults:

(setq kmacro-repeat-no-prefix nil)
(setq kmacro-call-repeat-key nil)

Then the "non-spirit" behaviour would have to be enabled explicitly
by a user.  And we wouldn't have to write a lot of new code for the
(as you say) rarely used kmacro history feature.

>
>     With your proposal, I have to mess up the window layout just to rotate
>     the macro ring
>
> I don't think that is a valid conclusion.  Exiting this mode
> in the "usual" way could restore the old window layout.

True, it could work.

But I would prefer if we just change the defaults (and fix the docs)
as described above.  Would that be ok?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: kmacro.texi
@ 2004-12-03 19:42 Stefan Monnier
  2004-12-04  0:42 ` kmacro.texi Kim F. Storm
  0 siblings, 1 reply; 10+ messages in thread
From: Stefan Monnier @ 2004-12-03 19:42 UTC (permalink / raw)


[ I seem to have missed a bunch of email recently ;-( 
  I found this thread on the emacs-devel archive. ]

> >     And C-x e e e ...  already does something very similar.
> >     Nobody has complained about that so far.
> >
> >     And C-u C-SPC C-SPC C-SPC ...
> >
> > These are much more limited--but indeed the first of them bothers me.
> 
> We could change the defaults:

I really think the C-x e e e e e should stay.  It's really extremely useful
in my experience and everyone to whom I've shown it said something along the
lines of "hey that's cool" or "I've longed for this for years".


        Stefan

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: kmacro.texi
  2004-12-03 19:42 kmacro.texi Stefan Monnier
@ 2004-12-04  0:42 ` Kim F. Storm
  0 siblings, 0 replies; 10+ messages in thread
From: Kim F. Storm @ 2004-12-04  0:42 UTC (permalink / raw)
  Cc: emacs-devel

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> [ I seem to have missed a bunch of email recently ;-( 
>   I found this thread on the emacs-devel archive. ]
>
>> >     And C-x e e e ...  already does something very similar.
>> >     Nobody has complained about that so far.
>> >
>> >     And C-u C-SPC C-SPC C-SPC ...
>> >
>> > These are much more limited--but indeed the first of them bothers me.
>> 
>> We could change the defaults:
>
> I really think the C-x e e e e e should stay.  It's really extremely useful
> in my experience and everyone to whom I've shown it said something along the
> lines of "hey that's cool" or "I've longed for this for years".

The argument is not about what's useful or cool, but about the "spirit of emacs".

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: kmacro.texi
  2004-12-02 14:17       ` kmacro.texi Kim F. Storm
@ 2004-12-04  2:46         ` Richard Stallman
  0 siblings, 0 replies; 10+ messages in thread
From: Richard Stallman @ 2004-12-04  2:46 UTC (permalink / raw)
  Cc: teirllm, emacs-devel

    But I would prefer if we just change the defaults (and fix the docs)
    as described above.  Would that be ok?

We have never made a release with this feature, and I'd rather 
we fix it to work using a buffer and its mode before we include
it in a release.

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2004-12-04  2:46 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-11-30  4:30 kmacro.texi Luc Teirlinck
2004-11-30  9:53 ` kmacro.texi Kim F. Storm
2004-12-01  2:57 ` kmacro.texi Richard Stallman
2004-12-01  2:57 ` kmacro.texi Richard Stallman
2004-12-01 12:06   ` kmacro.texi Kim F. Storm
2004-12-02 13:10     ` kmacro.texi Richard Stallman
2004-12-02 14:17       ` kmacro.texi Kim F. Storm
2004-12-04  2:46         ` kmacro.texi Richard Stallman
  -- strict thread matches above, loose matches on Subject: below --
2004-12-03 19:42 kmacro.texi Stefan Monnier
2004-12-04  0:42 ` kmacro.texi Kim F. Storm

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).