[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[eev] Demonstration mode: eewalk

From: Eduardo Ochs
Subject: [eev] Demonstration mode: eewalk
Date: Mon, 25 Jul 2005 06:52:39 -0300

In a message to the emacs-devel mailing list - archived at
and at <> - RMS said:

> I used to teach classes in editing with Emacs, and people would
> watch a big screen acting as a secondary monitor for my computer. I
> would tell them what I was typing as I typed it, and go slow enough
> that they could follow what I did and what effect it had.
> (...)
> Why not just display the keys you type in another window?
> That would also enable people to follow what you are doing.

This suggests keeping two frames, one in which we use Emacs normally,
and another one in which the keys are shown after they've been typed,
like a dynamically-updated `M-x view-lossage'... or, alternatively,
that second frame can show both the keys that we have typed *and the
keys that we are about to type*...

Remember that `eesteps' already does something similar to that, but
not in a visual way - the "keys" (actually "actions") are programmed
all at once and put in a list, and then typing <f12> executes the
current action of the list and advances the pointer to the next
action. The docstring of `eesteps' has an example of this, let me
quote it here.

  Here's an example: run

    (eesteps '("C-x b * scratch * RET   ;;; change to the buffer
               (insert "!")))

  then type <f12> four times.

  Each step is either a string -- meaning a series of keys, in the
  format used by `edmacro-mode' -- or a sexp to be evaluated.

These sequences of steps are hard to edit and to follow. You can check
what's the next step using M-0 <f12>, but there's no easy way to jump
to the part of the `eesteps' sexp -- for example, the "3*<left>" --
that corresponds to the next step; the problem is that the list of
steps for <f12> exists only "inside the Lisp interpreter", in a format
that does not make reference to any buffer...

One possible solution - eewalk

<f12> reads the next step from a list; <f8> reads the next step from a
buffer -- i.e., it reads the sexp at point in that buffer, advances
point, and executes that step. This is a simplification, actually; it
needs to be a bit more complex than that. We have the "main" frame and
the "eewalk" frame; the "eewalk" frame holds a buffer, called
"*eewalk*", from which the steps are read. Every time that we type
<f8> Emacs switches temporarily to the *eewalk* buffer, reads a sexp
from there, advancing point (note: if the end of the buffer is reached
or if we hit a ")" this means that there are no more steps, and an
error is signaled), and then emacs returns to the original buffer and
executes the sexp that it has read.

  (find-eev "eev-walk.el")
  (find-eevex "demos.e" "eewalk-demo4")

Random notes: marking a region and doing `M-x eewalk-region' or `M-x
eewr' creates a temporary buffer called *eewalk* in another frame;
that buffer contains a header (see the screenshot attached to this
message; there the first 6 lines are the header) followed by a copy of
the contents of the region. When we only we have only one frame a
second frame is created, when we have more than one frame the next
frame is used. This "eewalk" frame becomes the selected frame, but the
first action stored there is `(eewalk-orig-frame)', which switches the
selection beack to the frame where the `M-x eewalk-region' was run.
`eewr-bounded' is a "bounded version" of `eewr'; the frame and the
buffer at the right in the screenshot were created by just typing
`M-e' on a line of the file demos.e that says ";; (eewr-bounded)", and
after that we just typed <f8> several times.

That's it for now -- this thing took me at least two weeks and four
total redesigns and rewrites to become something that works reasonably
well and whose code I don't hate too much. The code will probably
still change a lot. Suggestions and fixes are very welcome.

    Edrx (very sleepy - sorry for typos and incoherences)

-- - I mean, what is it about a decent email service?

Attachment: shot-f8.png
Description: PNG image

reply via email to

[Prev in Thread] Current Thread [Next in Thread]