[comp.emacs] vi feature I miss

pml@usl (Patrick Landry) (02/24/89)

When I first starting working with Unix I used
vi. I now use emacs because I have a version
on every computer I use regularly. 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.
Thanks
--
patrick
pml@usl.usl.edu
...!uunet!dalsqnt!usl!pml

wjc@ho5cad.ATT.COM (Bill Carpenter) (02/26/89)

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.

I'm taking you're word for it that the period in "vi" acts as you
describe.  There is a similar feature in GNUemacs, although I can't
tell if this is what you're looking for.  I found out about it by
reading the manual, but every time I demonstrate it to somebody, I get
a reaction like "wow!  how'd you do that?"  By default, this is bound
to "C-x ESC".  For more elaborate stuff, check out
"electric-command-history".

  repeat-complex-command:
  Edit and re-evaluate last complex command, or ARGth from last.
  A complex command is one which used the minibuffer.
  The command is placed in the minibuffer as a Lisp form for editing.
  The result is executed, repeating the command as changed.
  If the command has been changed or is not the most recent previous command
  it is added to the front of the command history.
  Whilst editing the command, the following commands are available:
  
  ESC             Prefix Command
  LFD             exit-minibuffer
  RET             exit-minibuffer
  C-g             abort-recursive-edit
  
  ESC n           next-complex-command
  ESC p           previous-complex-command

--
--
   Bill Carpenter         att!ho5cad!wjc  or  attmail!bill

tale@pawl.rpi.edu (David C Lawrence) (02/27/89)

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.89Feb26100439@hoswjc.ho5cad.ATT.COM>,
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

derrell@retix.retix.retix.com (Derrell Lipman) (03/03/89)

In article <600@usl> pml@usl (Patrick Landry) writes:

> When I first starting working with Unix I used
> vi. I now use emacs because I have a version
> on every computer I use regularly. 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.

i have often thought about implementing this feature, but i have not
determined who to ascertain the "beginning" and "end" of a command.
unlike vi, you do not go in and out of "modes" (e.g. insert mode) in
emacs.  in vi, if you go into insert mode and enter two pages of text
and then press escape to exit insert mode, that whole insert (two
pages) will be repeated if you type dot.

if anyone has suggestions for determining "beginning" and "end" of a
command, i will implement this feature.  for the time being, keyboard
macros are the closest we can come.
--


--derrell    (derrell@retix)

------------------------------------------------------------------------------
"The process of living is the process of reacting to stress."

dave@cs.wisc.edu (Dave Cohrs) (03/10/89)

In artivle <DERRELL.89Mar2103325@retix.retix.retix.com>
derrell@retix.retix.retix.com (Derrell Lipman) writes:

> 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 often thought about implementing this feature, but i have not
>determined who to ascertain the "beginning" and "end" of a command.

I would want the unit of "command" to be the same as that of undo.
I haven't looked at the undo code, but I don't think it remembers the
commands that caused the changes, just the changes that took place.
perhaps something that looked at "lossage" would be able to do the
trick.

dave cohrs
--
Dave Cohrs
+1 608 262-6617                        UW-Madison Computer Sciences Department
dave@cs.wisc.edu                       ...!{harvard,rutgers,ucbvax}!uwvax!dave