Eduardo Ochs | 21 Mar 09:43 2014

Workarounds for conflicting keys, and very short function names

Hi Alan, I thought you wouldn't mind if I brought this to the list in
a new thread...

On Fri, Mar 21, 2014 at 4:34 AM, Alan Schmitt
<alan.schmitt@...> wrote:
> Eduardo Ochs <eduardoochs@...> writes:
> > Btw, can you tell me what are the worst conflicts of keys between eev
> > and the rest?...
> The one that bothered me most is M-j, which I'm using to join lines.

Here are two very quick workarounds while we don't have anything
better... The first one:

  (defalias 'e 'eev-mode)

`M-x e RET' turns eev-mode on and off, and you can see by the "eev"
lighter in the mode line whether it is on or off...

The second one:

  (defun eejump-7 () (my-join-lines))

supposing that your "join lines" function is in `my-join-lines'...
then while eev-mode is on you can use M-7 M-j to run

By the way I use one-letter function names often, so for me `M-x
(Continue reading)

Alan Schmitt | 20 Mar 16:41 2014

eev without the key bindings


I stopped using eev because it was using too many key bindings I'm very
much used to. There are several feature I very much like in eev, and
I was wondering if it was possible to load it without loading the
key bindings.

Thanks a lot,

Alan Schmitt | 19 Nov 09:06 2013

Re: Problem with M-k

Hi Eduardo,

(I'm putting the mailing list in CC.)

eduardoochs@... writes:

> Hi Alan,
> could you please send to the mailing list an ascii art
> drawing of your window setups for e-mail and agenda -
> with the names of the buffers and major modes?

These are usually fairly simple layout. For email, it's created
automatically when viewing some mail using mu4e. It looks like this
(with the names of the modes):

| mu4e-headers (about 10 line)           |
| mu4e-view (rest of the vertical space) |
|                                        |

Even though it's a simple layout, I cannot simply C-x b to it, as there
are two windows.

For agenda, it's even simpler: it's a single window with the *Org
Agenda* buffer. Sometimes, after a few hours, it becomes slightly more

(Continue reading)

Alan Schmitt | 18 Nov 12:02 2013

Problem with M-k


I'm trying to understand the logic behind M-k. Sometimes I hit by
mistake M-j (it used to be bound to "join-lines" in my configuration),
and I thought that M-k would take me back to the buffer I was in
before. Unfortunately, it is not the case, as it often shows a
completely different buffer.

Digging a little bit into it, it seems that there is an interaction
with elscreen. M-k works as expected on screen 0, but for other screens,
it sometimes returns the buffer that is in the last screen (the exact
behavior is not easy to reproduce). Is M-k supposed to work with


Eduardo Ochs | 16 Nov 06:56 2013



I have just uploaded a version of eev with a new feature that
simplifies usage signficantly. The function `find-here-links', bound
to `M-h M-h', integrates several of the functions that were used to
generate buffers with lists of hyperlinks. Now, if you are in a
manpage, or in an info page, or in a "*(find-xxx-intro)*" buffer, or
visiting a file, etc, etc, and you want to generate a hyperlink to
where you are, just type `M-h M-h', and `find-here-links' will detect
in what kind of "here" you are and will generate links accordingly.

There is some documentation on `find-here-links' here:

Look for a section called (ta-daa!) `find-here-links'.

Also, as the "H" in `M-h M-h' would also be the letter that I would
choose for "help", I did a bit of overloading: the first lines of the
buffers generated by `M-h M-h' are help links.

Note that Org has something that appears to be similar to this:

  (info "(org)Handling links")
  (find-node "(org)Handling links")
  (find-orgnode "Handling links")

I don't know how to use it yet - but I'll have to learn that and write
a comparison (help appreciated, of course!)...

   Eduardo Ochs

eev mailing list
Alan Schmitt | 8 Nov 09:02 2013

What is required to change for the installation


I have downloaded eev from github ( and I
have a small question about installation.

Right now I have a minimal installation of the form (in my .emacs):

#+BEGIN_SRC emacs-lisp
  (add-to-list 'load-path "~/src/eev/")
  (require 'eev2-all)
  (eev-mode 1)

However, when I read the INSTALL file at I see there are many other
changes, such as configuring a default .eev folder. My questions are:

- am I missing anything with the minimal configuration above?
- where can I find what other changes I need to make (I'd rather make
  them manually)?


Alan Schmitt | 6 Nov 09:13 2013

SCM access to eev?


Is there a publicly accessible repository following eev's development? I
can download the tarball, but I'd rather use git or svn to follow the


Eduardo Ochs | 6 Jan 21:38 2013

a video about eepitch

Hi list,

there's a new video - just about eepitch, this time -
available at:

Please upgrade to eev2! =)
    Eduardo Ochs

eev mailing list
Eduardo Ochs | 12 Nov 18:16 2012

a video about eev2

Hello list (and a few other people),

here's is an introductory video about (the new version of) eev:

The thing is: the "center" of eev has changed - completely.
The documentation is now all in the form of sandboxed tutorials;
there are no non-elisp files anymore; eepitch is now considered
basic, while M-x eev and channels are now considered advanced
features; eejump is now one of the first things that I recommend
people to learn; most of the source code has been rewritten;
there are now standard hyperlinks to audio and video files;
etc, etc.

Bad news to changelog lovers: as this is practically a full rewrite
I am not keeping a changelog for the new version (yet); and
bad news for Debian users: I have not debianized eev2 yet.

Several advanced features of eev have been changed and now
need to be invoked differently. I'll be glad to help if anyone has any
difficulties adapting to eev2 (the e-mails and chat logs will help
me into creating a porting guide and other docs).

    Eduardo =)

P.S.: I'm using IRC a lot again. Try #eev at freenode...

P.P.S.: the scripts that I used to produce the video are not all
online yet - but they will, soon.

eev mailing list
Eduardo Ochs | 9 May 14:14 2012

(find-estring "<Put a tutorial here>")

Hello list,

I have been experimenting with another (new?) way of documenting
things: temporary buffers with tutorials, generated by calls like
(find-estring "<Put the tuorial here>"). See:

I haven't been testing the tarball in

much, so some bugs may have crept in - I have been working mostly on
the Debian packages, that are at: ,

especially on the one - "eev-puro" - that has mosts of its docs in
Portuguese =(... I plan to create a version in English of that package
soon, though. As a curiosity, here's a screenshot of Emacs's startup
screen when invoked through the script "emacs-puro" or through its
icon in the desktop menus:

  Eduardo Ochs
Eduardo Ochs | 6 Apr 13:54 2012

Re: Debian package: first real announcement

Hi Xavier,

> Sorry not to have posted an answer to your previous message but my
> mail server just blowned up.

I remember that as being my fault!... You sent this e-mail to the
mailing list,

and as I felt that I only had a very incomplete answer I sent you an
e-mail in private and promised a fuller, public answer soon - which I
never finished, because it depended on fixing some things that looked
trivial - but the fix became eev-template.el, which took me ages to

> > Its dependencies have been reduced almost to a minimum - just emacs
> > and xterm - and now the recommended way to interact with external
> > programs with CLIs is by using eepitch (which has been rewritten):
> Does this mean you will deprecate the /old/ way ?

Sorry, good questions! Let me be clearer about the plan. The other
"ways" besides eepitch will not be deprecated, they will just become
secondary - eepitch will be explained before the other ways in most
docs, and the scripts to invoke eev-rctool, to set up eechannel, and
to test if they work will be rewritten to become eepitch-based.

> > Note that the "eepitch way" does not require any setup at all.
> What do you mean by "setup" ? No need of rc_tool ?

Exactly. 8-)

> Will GNU Eev be only eepitch+eev-template in a near future ?

No, but I would like to rearrange the definitions in files to isolate
the parts that depend on eev-rctool from the other parts. This is a
medium-term goal, though.

  Cheers! =)