|
From: Eduardo Ochs <eduardoochs@...>
Subject: Re: So here I am Newsgroups: gmane.emacs.eev.devel Date: 2007-09-05 15:45:28 GMT (35 weeks, 6 days, 2 hours and 51 minutes ago) Hi Xavier, > By the way, I am trying to setup eev-current on my machine but it > fails since I do not have a ~/.bashrc (I try to follow > freedesktop recommendation). sorry for not having answered earlier... eev is a "tool for automating everything"... have you taken a look at the (unfinished) article about it? Here's the url: http://angg.twu.net/eev-article.html And here's something much older, that is mostly about the, hmm, "social implications" of using e-scripts: http://angg.twu.net/eev-manifesto.html I can try to give you a few starting points. One of the things on which I have been working lately is to make eev less dependent on being installed - that is, now it should be possible to use a good part of it - hopefully enough to grasp the main concepts - without patching any rcfiles. Here is how: if you unpack the tarball at some directory, say, with mkdir ~/eev-current/ cd ~/eev-current/ wget http://angg.twu.net/eev-current.tar.gz tar -xvzf eev-current.tar.gz then you can load eev and activate eev-mode with just: (add-to-list 'load-path "~/eev-current/") (require 'eev-all) (eev-mode 1) The effects of the "(require 'eev-all)" are: lots of functions - mainly for elisp hyperlinks - become defined; a few glyphs, like the red star (^O) are set, and some environment variables - $EE, $EEVTMPDIR, etc - are set inside Emacs, and will be inherited by programs that are started from Emacs - for example, the shells in `M-x shell' buffers, and the shells inside xterms launched from Emacs. Try to run this, (find-bgprocess "xterm") and check that $EE is defined in that shell... however, the `ee' shell function described in http://angg.twu.net/eev-article.html#making-progs-receive-cmds will NOT be defined in these shells. Turning eev-mode on does only two things: it activates the `eev-mode-map' keymap, and it sets `pop-up-windows' to nil - when `pop-up-windows' is nil the keys `M-e', `M-E' in `eev-mode-map', that follow elisp hyperlinks, behave better; and the keys `M-k', and `M-K', also from `eev-mode-map', work more consistently as ways to return from elisp hyperlinks (`M-e' is `kill-this-buffer', `M-E' is `bury-buffer'). Turning eev-mode off deactivates the keymap and restores the previous value of `pop-up-windows'. Currently the eev-mode keymap has lots of key bindings. You can inspect them with: (find-efunctiondescr 'eev-mode) (find-ekeymapdescr eev-mode-map) (find-evariable 'eev-mode-map) I have to rewrite some parts of the documentation to convince people to forget about `M-x eev' and `M-x eev-bounded'/<f3> when they are just starting to use eev, as these kinds of things require "prepared shells"... Instead, they should start by `M-e' (obviously), `M-k', `C-q C-o', `<f8>' and the `M-h ___' family. `C-q C-o' generates a red star glyph; `<f8>' and the `M-h ___' commands were the subject of most of the recent posts to this mailing list, and these links are good starting points about them: http://angg.twu.net/eev-article.html#generating-hyperlinks http://angg.twu.net/eev-article.html#eepitch I hope this helps, and more soon, Cheers, Eduardo Ochs eduardoochs@... http://angg.twu.net/ http://angg.twu.net/contact.html P.S.: "eev-all.el" is new, please download the newest tarball from <http://angg.twu.net/eev-current.tar.gz>... P.P.S.: as you mentioned FreeDesktop, let me quote a paragraph from the comments in the file "eev.el", just to scare you a bit... |
|
|