[net.emacs] Mlisp Function Inquiry

mr@isrnix.UUCP (michael regoli) (02/03/85)

]):([

I'm interested in a "repeat-last-command" mlisp macro which 
would essentially function as the "!!" shell substitution.

Is there such a beast?

-- 
     .          .:.
    /=@==: - - - |                       michael regoli
   (/           .:.      ...ihnp4!inuxc!iuvax!isrnix!mr
                          <mr%isrnix.uucp@BRL-TGR.ARPA>
		                     indiana university

chris@umcp-cs.UUCP (Chris Torek) (02/08/85)

First define "the last command".  In a moded editor it is relatively clear
that the last command is the last single operation done while in command
mode; since Emacs is (mostly) modeless, this definition cannot apply.

Spencer Thomas has an MLisp function (in C; i.e., it's a "wired function")
that returns the last 100 keystrokes, which could be used to construct a
command-repeating function, but I haven't yet come up with a really good
way to decide how much to repeat....
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251)
UUCP:	{seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@maryland

thomas@utah-gr.UUCP (Spencer W. Thomas) (02/08/85)

In article <3084@umcp-cs.UUCP> chris@umcp-cs.UUCP (Chris Torek) writes:
>First define "the last command".  In a moded editor it is relatively clear
>that the last command is the last single operation done while in command
>mode; since Emacs is (mostly) modeless, this definition cannot apply.
>
>Spencer Thomas has an MLisp function (in C; i.e., it's a "wired function")
>that returns the last 100 keystrokes, which could be used to construct a
>command-repeating function, but I haven't yet come up with a really good
>way to decide how much to repeat....

I've thought about this some, but never started to implement anything.
Here are my thoughts so far:

	- It is probably the case that any sequence of self-inserting
	  characters constitutes a "single command".
	- Should ^H (or rubout) be included in the above?
	- Also, probably any sequence of the same key repeated constitutes
	  a single command (e.g. ^D^D^D^D).
	- Argument prefixes should be included in the command (so ^U^D is
	  the same as above).
	- Cursor motion is probably not considered a "command" (so you can
	  move to a new location, then execute repeat-command).
	- You have to be careful about command-prefixes (e.g., ^X, ESC, and
	  any other keys that are bound to keymaps -- we have ^Z bound
	  bound to a keymap, for example).
	- The real killer, though, is commands that read arguments by
	  prompting in the minibuffer.  I don't think you can easily 
	  determine, just by looking at what was typed, where the command
	  begins.  (^Q is another insidious one.)
	
So, it begins to look as if just knowing the last N keystrokes is
insufficient to determine the "last command".  One could easily provide
a facility to edit the string of keystrokes, then turn it into a
keyboard macro, though.  (Let human intelligence do the hard part.)

Further discussion is welcomed (especially if it leads to a good
solution of the problem).  Another idea: perhaps something based on the
"generate" facility would work better.

(BTW - the last-N-keystrokes facility is really nice when you type
something random, and you want to see what damage you might have done to
your buffer.)

-- 
=Spencer
	({ihnp4,decvax}!utah-cs!thomas, thomas@utah-cs.ARPA)
	<<< "Humor is the poetry of ideas that do not match."
		- Leonard Feeney >>>

pedz@smu.UUCP (02/21/85)

I think of a "command" as something that starts at the root of
the keymap tree and eventually terminates a function being
called.  Added to this, I would exclude some commands from the
definition.  In fact, I would make a mlisp command which has the
effect of saying "don't count me as a command".  (A rule forcing
that this command be the first statement in the mlisp function
would be reasonable.  I would definately make this command act
only if it was in the function called directly by the keymap.
Thus if a function which wishes to be counted as a command,
called a second function which did not, the first function would
still be remembered).  This could be done by simply keeping a
two entry queue of commands and when a command was called, it
would get put into the queue.  If the function did not want to
be counted as a command, it could call the "forget" function
which would backup the queue.  I really have no idea of what
these ideas involve.  Perhaps someone else could comment futher.

Perry