|
Warning: this is an htmlized version!
The original is here, and the conversion rules are here. |
This is the `README-0.95.2' file of GNU eev.
Author and version: Eduardo Ochs, 2007oct04.
This file is in the Public Domain.
<http://angg.twu.net/eev-current/README-0.95.2>
<http://angg.twu.net/eev-current/README-0.95.2.html>
<http://article.gmane.org/gmane.emacs.sources/2705>
Hello gnu.emacs.sources,
I would like to call your attention to this package:
http://angg.twu.net/eev-current.tar.gz (the tarball)
http://angg.twu.net/eev-article.html (a doc)
http://angg.twu.net/emacs.html (some more stuff)
http://angg.twu.net/ (more pointers)
About its status: eev has already received most - or all - the
necessary "ok"s from the FSF years ago, but I felt that it still had
too many rough edges... and now most of the "technical" rough edges
have been solved:
* Installation: eev used to require patched rcfiles to be able to
send blocks of commands to external programs. For example, it
"sent" blocks of commands to shells by storing them into temporary
script files, and then the user would type "ee" at the shell to
source that temporary script; that required that the shell had
"ee" defined as a shell function. There's an awk script that helps
patching rcfiles (and it makes unpatching them very easy), but
now, thanks to an idea from Rubikitch (a function called
`eepitch'), there are ways to send commands to external programs
running in Emacs buffers that need no "installation" - i.e., no
rcfile changes.
* Upgrading: `M-x find-eev-update-links' generates a temporary
buffer with an update script.
* The internals are much cleaner (in the main source files).
On the documentation
====================
The main document about eev is the "eev article", at
<http://angg.twu.net/eev-article.html>. At this point ***I AM NOT
INCLUDING IT IN THE TARBALL*** - it has too many important links
pointing to outside the eev package. So: if you don't have a
(semi-)permanent web connection then reading an offline copy of the
"article" can be frustrating - please wait a bit more.
At some point - soon, I hope - the program ("blogme") that generates
the html of the article will be able to generate TeXinfo too, and then
there will be an Info version and a printable (.dvi) version of it.
I still need to rewrite the documentation to a bit to always mention
<f8> (= eepitch, Rubikitch's trick) as soon as possible. The original
way of sending blocks of commands out in eev, `M-x eev', is
technically trivial, but it requires a temporary directory and a
"prepared shell" at the receiving end; <f8> sends lines to a comint
buffer and needs no installation.
Conceptual rough edges
======================
Again: I am sorry for the delay, but eev is a big package, and even
though its main features fit in very little code - see the
"miniatures" at
http://angg.twu.net/eev-current/eev-mini.el.html
http://angg.twu.net/eev-current/eev-mini-steps.el.html
(find-eevfile "eev-mini.el")
(find-eevfile "eev-mini-steps.el")
(but be aware that "eev-mini.el" has not been thoroughly tested!) -,
most of the feedback that I was receiving indicated that the most
important underlying ideas were not getting through... Namely:
(1) "Automating almost everything" - as in the "eev article" at
<http://angg.twu.net/eev-article.html>; mainly, it's hard to
convince people that as they write an e-script to automate
something they should also automate the access to the files and
documents that they looked at and found relevant while writing
the script...
This is related to doing research without ever forgetting that
there is a "me" who is thinking about the problems and
solutions; when I read an e-script after writing it I have
already forgotten half of what I wrote there - a next person
coming after me that will take a peek at this e-script will be
like this "me", but he or she will have "forgotten" even more...
(2) "Every action factors through eval-last-sexp". That `C-x C-f
/tmp/foo' "factors through" having this on a buffer
(find-file "/tmp/foo")
and typing `C-x C-e' (or `M-e' or `M-E', if eev-mode is on)
after it, this is easy to see; but that clicking on the button
pointing to "files.el" in the help for the function find-file
should be the same as evaluating a sexp, this is harder to
grasp, it seems - and producing a sexp hyperlink like
(find-efunction 'find-file)
requires hindsight (hint: `M-h M-f find-file' will show this
sexp and others) - and producing sexps like
(find-efunctiondescr 'find-file)
(find-efunctiondescr 'find-file "/files.")
(find-efunctiondescr 'find-file "/files." '(eek "RET"))
(find-efunctiondescr 'find-file "/files." '(eek "M-h M-k RET"))
is, I guess, mind-blowing for most people...
And something like, say, this, too.
(find-bgprocess "xdvi /tmp/texbook.dvi")
There MUST be a way to express the idea in (2) convincingly in
diagrams... The best that I have at this moment is something like
this:
C-x C-f
+---------+ /tmp/foo +---------+
| State 1 | ------------> | State 2 |
+---------+ +---------+
. .
: :
v (find-file v
+---------+ "/tmp/foo") +---------+
| State 1'| ------------> | State 2'|
+---------+ +---------+
where we can use screenshots to represent these states, and the lower
horizontal arrow means that we're executing the (find-file "/tmp/foo")
in a buffer, with an eval-last-sexp...
So: the upper horizontal arrow is the "usual" way of visiting
/tmp/foo; the lower horizontal arrow is the "e-script-ish" way of
visiting /tmp/foo, in which the find-file action can be redone with
just a `M-e'; in the passage from the upper line to the lower line we
are automating visiting that file. But what does that mean, precisely?
States 2 and 2' are evidently similar (same screenshot) but the
vertical arrow on the left is where all trouble lies -
I give presentations about Emacs and eev from time to time at Free
Software events - half for proselytizing, half for testing ideas - and
the same haunting question always pops up at the end: "how do you
automate making e-scripts?" - or, in other words, "how do you automate
automating tasks?" - and I don't have a good answer for that... I have
10 or 20 usage patterns and I record every step "by hand" as I do it,
using certain commands to help me...
Textual descriptions of these usage patterns don't always work - many
people have short attention spans nowadays (and mine is not very big,
either... 8-\) - so I've been experimenting with several kinds of
"animations":
* "real" animations in SWF (a.k.a. "Flash"), as in
<http://angg.twu.net/eev-current/anim/>,
* demos made with `eesteps', meant to be run from inside Emacs
with eev-mode on; for example, `M-4 M-x eev-demos',
* low-tech "flipbooks", as in
<http://angg.twu.net/flipbooks/> and
<http://angg.twu.net/eev-current/eev-sshot.el.html#find-sshot>
(the support for viewing flipbooks in Emacs is a hurried hack),
Well, let me stop here for now. I started to write this planning to
explain in some detail why I kept the development of eev sort of
underground for so long, and I ended up writing long release notes
instead...
Cheers,
Eduardo Ochs
http://angg.twu.net/
[email protected]