Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!batcomputer!rpi!rpi.edu!tale From: tale@pawl.rpi.edu (David C Lawrence) Newsgroups: comp.emacs Subject: Re: vi feature I miss Message-ID: Date: 27 Feb 89 04:25:35 GMT References: <600@usl> Sender: usenet@rpi.edu Reply-To: tale@pawl.rpi.edu Distribution: comp Organization: The Octagon Room Lines: 40 In-reply-to: wjc@ho5cad.ATT.COM's message of 26 Feb 89 15:04:39 GMT In article <600@usl> pml@usl (Patrick Landry) writes: > There is one > feature of vi I miss; the period key. This feature > repeats the last 'editing' command issued. I have > not found a feature of Gnu-emacs which does the > same thing without user intervention (extra keystrokes). > If there is such a command, I'd like to know about > it. In article , wjc@ho5cad.ATT.COM (Bill Carpenter) writes: bc> I'm taking you're word for it that the period in "vi" acts as you bc> describe. There is a similar feature in GNUemacs, although I can't bc> tell if this is what you're looking for. Nope. As described by the documentation which you included, a complex command is one which used the minibuffer, which can be anything from a switch-to-buffer to an eval-expression. vi uses . to repeat the last command which altered the buffer while not in insert mode. Thus if you type dd to remove a line, subsequent .'s will delete more lines. The attack to this in Emacs would be to define a function which would capture every function passed and assign it to the "repeating command" spot if not a self-inserting or switch-to-buffer or a multitude of other things. It is not very feasible the way that GNU Emacs is configured, although it could presumably be done with a lot of kludging. Just map every function you would want to be seen by the repeater to one function which made the actually desired function a repeater and then called the function which was actually desired. This of course would play havoc with a lot of the help features. The above paragraph is all from the lisp perspective; I have not dug into the C source, but I would think that with a couple of small patches you could get similar behaviour to the "." key and still have very little additional overhead and working help functions. -- tale@rpitsmts.bitnet, tale%mts@rpitsgw.rpi.edu, tale@pawl.rpi.edu