|
Subject: Demonstration mode: eewalk Newsgroups: gmane.emacs.eev.devel Date: 2005-07-25 09:52:39 GMT (3 years, 49 weeks, 1 day, 5 hours and 53 minutes ago) In a message to the emacs-devel mailing list - archived at <http://lists.gnu.org/archive/html/emacs-devel/2005-06/msg01574.html> and at <http://article.gmane.org/gmane.emacs.devel/39555> - 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 *scratch*" "foobar" "3*<left>" (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. Links: http://angg.twu.net/eev-current/eev-walk.el.html http://angg.twu.net/eev-current/examples/demos.e.html#eewalk-demo4 (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. Cheers, Edrx (very sleepy - sorry for typos and incoherences) http://angg.twu.net/ -- http://www.fastmail.fm - I mean, what is it about a decent email service? _______________________________________________ eev mailing list eev@... http://lists.nongnu.org/mailman/listinfo/eev |
|
|