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