Anyone use ELSE minor-mode in Emacs?

[Christian Seberino]

I am looking at the ELSE home page and trying to figure out if I should
invest the time to learn about the ELSE minor mode for Emacs.

Is there any programmer out there using ELSE that is getting great
benefit from it?

What does ELSE minor-mode for Emacs do that is so great for you?

Chris

 

[Peter Milliken]

I use it - but then I'm the author

I am hopeful that the "time to learn it" is very short. Probably the
quickest way to get to learn it is to use the "tokens" i.e. enable the
else-mode minor mode in a .py file and type in "def" and then run the
else-expand-placeholder command (C-c / e - this key encoding is "forced" on
Emacs minor mode authors by Emacs expansion conventions - I use F3
personally ). and you should get the appropriate code structure.
Similarly, type in "classC-c / e" and you'll get a class structure.

Then just "expand" every "placeholder" until you start to get a feel for
where it leads. If you stick with just the "tokens" at first, then you'll
quickly get an idea of what ELSE can do. Using "placeholders" follows fairly
naturally from token expansions.

If you don't want to handle the menus etc of using placeholders straight off
the bat then that's no problem, just type directly into a placeholder and it
will disappear and get out of your face

Once you have used it for a while and (hopefully ) find it useful, then
perhaps venture into the users manual. I hope I have laid it out reasonably
well, so you can focus in on the areas that interest you.

Please do not stay with the minor mode key-bindings as the idea of ELSE is
to reduce typing - having to type C-c / x all the time where "x" is "e, p,
n, or k" defeats the entire purpose - but those are the "rules" for minor
mode creators in Emacs That is why the ELSE manual recommends that one
of the first priorities is the creating of a convenient key-binding. I use:

F3 - else-expand-placeholder
F4 - else-next-placeholder
F5 - else-previous-placeholder
F6 - else-kill-placeholder

I have a version of else-mode.el that has a command else-show-tokens - this
is useful to quickly see what "tokens" are available for expansion using
this mechanism. At the moment with the current released version of ELSE, you
have to browse the individual language file to see what strings are defined
as tokens. Token definitions are always at the end of the file, BTW Let
me know if you want a copy of that version - I am behind a firewall at work,
so updating the web-site always has to wait for when I have the time to get
on the Internet at home - something that can take weeks to do sometimes

As a general rule, any "keyword" is defined as a token i.e. return, if, def,
try, while etc etc - try them to see what you get It is very easy to
define your own "tokens" (shortcuts for want of a better term), the manual
describes all of this or you could just look at the language template files
for examples.


As for what it does for me - it saves me typing (use it properly and your
main coding experience is the entry of variable names etc) and with more
syntactically strict languages such as C etc it saves me having to type in
{}'s and ;'s If you use ELSE for a language like C then you never get a
compiler error saying you have missed a } or a ; - surely a big time saving


The whole idea behind ELSE is to save typing - which means higher
productivity and allows the programmer to focus on the problem at hand -
writing a program to meet a need. The programmer shouldn't be distracted
from the job at hand worrying about whether they got the language syntax
correct or not

Hope this helps,

Peter

 

[Christian Seberino]

Peter

Hello! Thank you very much for your detailed reply to my
comp.lang.python post about ELSE. I downloaded the
else-mode.el file and was able to load it. I'm having problems
getting the Python template file loaded (Python.lse).

Can I put this in my home directory and/or specify the path
to it instead of placing it somewhere else? Can I load
it from Emacs myself??

Also, Python doesn't have as much junk as C to type.
Is ELSE still useful in Python since Python has no
braces, semicolons, etc. that one needs to automate?

Chris
--
_______________________________________

Christian Seberino, Ph.D.
SPAWAR Systems Center San Diego
_______________________________________

 

[=?iso-8859-1?Q?Fran=E7ois?= Pinard]

[Christian Seberino]

Also, Python doesn't have as much junk as C to type. Is ELSE still
useful in Python since Python has no braces, semicolons, etc. that one
needs to automate?

I used ELSE for Python for prototyping the overall structure of modules
(beginning shebang and comments, an empty doc-string, my usual Main
class, and the usual stanza "if __name__ == 'main', etc." stanza at the
end. ELSE may be useful to start a class, including the skeleton for
"def __init__(self):". And also for a few other tiny own habits. As
far as I am concerned, besides the few things above, Python is so clean
that ELSE was not as useful that it may be for other languages.

P.S. - If I'm using past instead of present, about ELSE, this is because
not so long ago, I switched my habits away from Emacs (towards Vim).

 

[John J. Lee]

P.S. - If I'm using past instead of present, about ELSE, this is because
not so long ago, I switched my habits away from Emacs (towards Vim).

Why?

Interesting to see an emacs 'power user' switch to vi. But maybe you
were originally a vi user, and have just had a long emacs detour?


John

 

[=?iso-8859-1?Q?Fran=E7ois?= Pinard]

[John J. Lee]

Why? [...] But maybe you were originally a vi user, and have just had
a long emacs detour?

No. You cannot imagine how much I could not stand `vi' for myself. On
machines without Emacs or some form of Emacs clone, I was using `ed', or
even `sed', just for avoiding finding myself stuck within `vi'. So, to
see myself using Vim now, represents an astonishing conversion!

The "Why?" is a bit difficult to tell in a few words. Especially since
I still consider Emacs as a wonder. I explained my reasons to a few
friends and saved my notes, and I'll probably turn them into some Web
page if I find some more free time. Let me post the URL here then...

Let me say right away is that I would have never ever considered Vim if
it did not offer proper Python support. Pymacs seems more powerful to
me that Python in Vim, yet Python in Vim is neat and quite usable.

Vim surprisingly has many functionalities, under paradigms which vary
slightly or greatly, which I thought Emacs was alone to offer. This
helped me to "swallow the snake", which admittedly has been rough .

 

[Peter Milliken]

Francois,

I was disappointed when I read of your "defection". However, I can perhaps
understand it. I have participated in "constructive" "my editor is better
than your editor" threads over in comp.editors in the past. Vim has an
impressive array of tricks - the discussion basically came to a "draw" with
the only thing that I use in Emacs that Vim couldn't offer was ELSE - enough
for me to stay with Emacs!

Allow me to summarise it all with the following:

From ``The Zen of Programming'':

Hearing a disturbance, The master programmer went into the novices
cubicle.

``Curse these personal computers!'' cried the novice in anger, ``To
make them do anything I must use three or even four editing
programs. Sometimes I get so confused that I erase entire files.
This is truly intolerable!''

The master programmer stared at the novice. ``And what would you
do to remedy this state of affairs?'' he asked.

The novice thought for a moment. ``I will design a new editing
program,'' he said, ``a program that will replace all these others.''

Suddenly the master struck the novice on the side of his head. It
was not a heavy blow, but the novice was nonetheless surprised.
``What did you do that for?'' exclaimed the novice.

``I have no wish to learn another editing program,'' said the
master.

And suddenly the novice was enlightened.


Emacs did it all at a time when there was no other editor that had the
features and worked across/on all platforms - now that other editors have
"caught up", I see no reason to change

Peter

[John J. Lee]

Why? [...] But maybe you were originally a vi user, and have just had
a long emacs detour?

No. You cannot imagine how much I could not stand `vi' for myself. On
machines without Emacs or some form of Emacs clone, I was using `ed', or
even `sed', just for avoiding finding myself stuck within `vi'. So, to
see myself using Vim now, represents an astonishing conversion!

The "Why?" is a bit difficult to tell in a few words. Especially since
I still consider Emacs as a wonder. I explained my reasons to a few
friends and saved my notes, and I'll probably turn them into some Web
page if I find some more free time. Let me post the URL here then...

Let me say right away is that I would have never ever considered Vim if
it did not offer proper Python support. Pymacs seems more powerful to
me that Python in Vim, yet Python in Vim is neat and quite usable.

Vim surprisingly has many functionalities, under paradigms which vary
slightly or greatly, which I thought Emacs was alone to offer. This
helped me to "swallow the snake", which admittedly has been rough .

 

[=?iso-8859-1?Q?Fran=E7ois?= Pinard]

[François Pinard]

[John J. Lee]

Why? [...] But maybe you were originally a vi user, and have just had
a long emacs detour?

The "Why?" is a bit difficult to tell in a few words. Especially since
I still consider Emacs as a wonder. I explained my reasons to a few
friends and saved my notes, and I'll probably turn them into some Web
page if I find some more free time. Let me post the URL here then...

OK, I started something. The page is not complete yet, but there is
probably enough in it to give an overall idea of my reasons. Better
publish it as it stands, than later or never .

The simplest is to go through my home page from my signature, and select
`Editors' from the left menu. Or else, use the link:

http://pinard.progiciels-bpi.ca/showfile.html?name=opinions/editors.all

My English is approximative, do not hesitate to send me corrections.

P.S. - I was using the Web server for internal use only, it is recent
that I use for outside. I shall tune it for concurrent accesses. It
might appear slow at times, especially when Google robots scan all the
pages, a few thousands of them... (pages, not robots!

 

[John J Lee]

]

OK, I started something. The page is not complete yet, but there is
probably enough in it to give an overall idea of my reasons. Better
publish it as it stands, than later or never .

The simplest is to go through my home page from my signature, and select
`Editors' from the left menu. Or else, use the link:

http://pinard.progiciels-bpi.ca/showfile.html?name=opinions/editors.all

Well worth reading, thanks.

Any good URLs for vim's Python support (scripting vim with Python, I
mean)?


| I use the email paradigm a great deal, even to save notes within
| messages to myself which I then file into thematic folders

Now *there's* an idea, thankyou!

[Except, in a parallel to your world-shaking ;-) editor switch, I'm
currently thinking of ditching pine (for something, like pine, that's
cross-platform, does IMAP well, is free (beer) but also libre, has a
decent disconnected mode, preferably written in a high-level language, and
that doesn't offer remote buffer overflows on its feature list!... except
such a beast doesn't seem to exist).]


| I still have no idea on the Vim capabilities for controlling highlighting

I've always thought the way to do this must be to allow both simple
high-level language (elisp, python) ways of doing this for covering the
broad range of languages &c., and some kind of low-level (C, I guess)
plugin standard for wiring up editors to things like the Python parser.
Who wants to reimplement the Python parser, after all?

My English is approximative, do not hesitate to send me corrections.

[...]

uneasy != difficult


John

 

[=?iso-8859-1?Q?Fran=E7ois?= Pinard]

[John J Lee]

[François Pinard]
Well worth reading, thanks.

Thanks for the appreciation!

Any good URLs for vim's Python support (scripting vim with Python, I
mean)?

URLs, I do not know, but the Linux I use offers:

/usr/share/vim/vim62/doc/if_pyth.txt

which holds the information one needs. Succinct, but complete. You may
have to re-install Vim from sources. The installation recipe I used is
not far from:

wget ftp://ftp.vim.org/pub/vim/unix/vim-6.2.tar.bz2
tar xfj vim-6.2.tar.bz2
pushd vim62
./configure --prefix=/usr \
--enable-pythoninterp --with-features=big --enable-multibyte
make install
popd

To quickly check that it works, once in the new Vim, try:

y print 3 + 5

and you should see `8' in the bottom line.

I'm currently thinking of ditching pine (for something, like pine,
that's cross-platform, does IMAP well, is free (beer) but also libre,
has a decent disconnected mode, preferably written in a high-level
language, and that doesn't offer remote buffer overflows on its
feature list!... except such a beast doesn't seem to exist).

Gnus was really marvelous, nothing can really compare with it. I looked
around a bit for a replacement, and the best I came with is Mutt. I
did not consider Pine for long, but do not remember why I excluded it.
Getting Mutt and some of my Python scripts to really cooperate required
some doing, and a few kludges, and I still feel very far from having a
mail agent offering Python as an extension language. I also saw Python
extensible mail agents, but which had some weakness in the underlying
mail engine, so far that I could judge. Mutt is not perfect overall,
but I'm trying to compromise with it for now, it's still give-and-take.

But at least, I now feel installed in a much more modular design for my
work habits, and if I find something that pleases me more than Mutt, I
could change this aspect without having to change everything else with
it. In my case at least, the big move is now part of the past, the main
suffering is behind.

| I still have no idea on the Vim capabilities for controlling highlighting

I've always thought the way to do this must be to allow both simple
high-level language (elisp, python) ways of doing this for covering the
broad range of languages &c., and some kind of low-level (C, I guess)
plugin standard for wiring up editors to things like the Python parser.
Who wants to reimplement the Python parser, after all?

This is about editing SGML, isn't it? I wrote something for Emacs
called `xxml.el', that those a job at combining colour attributes that I
suspect to be beyond the Vim way of doing such things. But I may be
wrong, as my knowledge of Vim is still very fragmentary.

My associate, who is a linguist more than in computer science, usually
likes to adopt and stick with my work habits, because I can then more
fully support him. He does not object switching to Vim from Emacs as I
did, but _only given_ that Vim has the equivalent of `xxml.el' first.
The fact is that I understand him. How can I politely say it... Euh!
Humph! OK: I am still unsuccessful at learning to enjoy HTML editing
support in Vim, as it currently stands! I pondered a bit about how
I could rewrite `xxml.el' in Python, for later becoming a Vim extension
say, but I guess it would require a fairly good amount of work on the
Python side only, and no doubt that I would also need to learn Vim
advanced usage much more deeply than I know it currently.

 

[John J Lee]

]

To quickly check that it works, once in the new Vim, try:

y print 3 + 5

and you should see `8' in the bottom line.

Thanks.

BTW, one question I forgot to ask, which is maybe the most important from
my point of view: how do your fingers like vi? Mine have never been
completely happy with the standard emacs keys, but I don't like to change
them. I keep meaning to give the vi keys a chance, but it's almost like
learning to type again...

Gnus was really marvelous, nothing can really compare with it. I looked

[some of below is on-topic, promise ;-]

I use it for news (apart from now, since I got this as email, not news).
Does it do good disconnected IMAP, I wonder? Very very few programs seem
to do that *useably* (for my habits, anyway). KMail seems to be growing
support for that, but it's very new.

around a bit for a replacement, and the best I came with is Mutt. I
did not consider Pine for long, but do not remember why I excluded it.

I've used it (pine) for almost ten years (never seriously used anything
else), and it's nice, but:

- weird non-libre-ish licence, pain to install on Debian
- written in C: improvements are slow to arrive (especially given the
weird license and "cathedral-style" development system), and the
usual overflows
- recent remote send-email-to-become-root overflow exploits!
- offline and disconnected-mode support is poor to non-existent (bad if
you use a modem)

Getting Mutt and some of my Python scripts to really cooperate required
some doing, and a few kludges, and I still feel very far from having a
mail agent offering Python as an extension language. I also saw Python

There's Mahogany, but it's GUI-based (dunno if the keyboard support is
good, which my hands regard as essential). I'm also not sure if the
Python support is actually stable.

extensible mail agents, but which had some weakness in the underlying
mail engine, so far that I could judge.

Yes, it seems like it's bound to be one of those things that are messy
enough to take years of bug fixes to get really right. I once
contemplated writing a clone of pine in Python, but I expect it's just too
much work to seriously consider. With Barry Warsaw's email module being
used by Mailman (Barry again, of course), I suppose that takes care of
*some* of the mess, but far from all. And the names "pyne" and "balsa"
are already taken <0.5 wink> ("twig", maybe? "stick"? "needle"? No, of
course, it'd have to be "larch"!-).

[...]

it. In my case at least, the big move is now part of the past, the main
suffering is behind.

You talk like an ex-drug addict ;-)

This is about editing SGML, isn't it? I wrote something for Emacs

[...]

Yes, but not only SGML. python-mode has quirks (I suppose mostly to do
with things other than syntax colouring -- paragraph-fill, for example)
that could be fixed with proper parsing rather than (I presume) the bunch
of regexes that python-mode gets by with. If Mark Hammonds Windows editor
does it, I don't see why Emacs and vi shouldn't.


John

 

[=?iso-8859-1?Q?Fran=E7ois?= Pinard]

[John J Lee]

how do your fingers like vi? Mine have never been completely happy
with the standard emacs keys, but I don't like to change them.

Emacs and Vim key-bindings are pretty different, down to the logical
organisation and structure of commands. One thing which has been
difficult for me is to learn to shift the right hand one position left
on the `HJKL' keys and unshift it on `JKL;' depending on what I want to
do, this detail often slowed me down initially. I'm not as speedy in
Vim that I was in Emacs. More it goes, easier it gets. I expect and
accept that it will require a few more months before the spinal chord
adapts.

I think Vim key-bindings are a bit softer on the hand and fingers than
Emacs, because most usual commands use simple lower case letters, others
use upper case letters, and only rarely you have to resort to the
control key. However, the Escape key is often needed, and a bit remote.
This advantage somewhat vanishes when I type French text, as the `cf'
keyboard uses a mix of dead keys (some shifted). Other combinations
require a full repositioning of the right hand, Python brackets and
braces in particular.

Another thing I observed is that Vim often invites me into using the
mouse (efficiently), while I traditionally dislike it. Strange.

I keep meaning to give the vi keys a chance, but it's almost like
learning to type again...

Granted!

I use [Gnus] for news (apart from now, since I got this as email, not
news). Does it do good disconnected IMAP, I wonder?

I have about no experiences with IMAP, so I do not know.

- offline and disconnected-mode support is poor to non-existent (bad if
you use a modem)

Here at home, `fetchmail' is automatically called each time a modem
connection is established, and it takes care of transferring all my
email over into the local machine spool. I use POP3 because I prefer
the format of the logs it creates, but IMAP is available as well and
works. One or the other does not make much difference.

Then a Python script analyses the received email and pre-sorts it in
many mail-group folders. That script interprets splitting rule trees
which I adapted to Python out of my original "fancy splitting" setup in
Gnus. It then repeatedly calls Mutt on each mail-group having received
new mail, allowing me to read it, reply to it, or do more fine splitting
and saving. At saving time, another Python script tremendously help me
at quickly selecting the proper folder (among more than 4000) for long
term filing, this selection script was also adapted out of a bit complex
setup, originally all written in Emacs Lisp.

I make little use of `procmail' in all this, besides suppression of some
bold, blatant SPAM. Python is much more versatile, legible, and likely
speedier as well. I also avoid many locking problems this way.

With Barry Warsaw's email module being used by Mailman (Barry again,
of course), I suppose that takes care of *some* of the mess, but far
from all.

Spambayes also uses some forgiving tricks over Barry's `email', which I
recycled in my own things. I often use one of my own script to somehow
"repair" mis-formatted folders, or transform Babyl folders. I had
to touch this script recently, as surprisingly, Mutt does not always
properly guarantee proper line termination when it saves a message. Of
course, I adjusted the saving procedure when I realised this, but for
everywhere I priorly saved email after having adopted Mutt, reparation
might be needed.

It's quite demanding on message agents to be at the same time competent
and forgiving.

You talk like an ex-drug addict ;-)

Editors are addictive. That's why so many people have quasi-religious
feeling about them. They feel threatened very deeply whenever they see
criticism. Salvaging their editor is akin to salvaging themselves.

python-mode has quirks

Vim file type for Python has quirks as well. And the other way around
too, I saw nice ideas in Python mode which Vim did not support, and
vice-versa. It seems there is a wall between both universes!

If Mark Hammonds Windows editor does it, I don't see why Emacs and vi
shouldn't.

I know, for having worked at a Python code reformatter (in Python, of
course!), that proper presentation of Python source may be tricky.
If all involved people were able to agree on the same presentation
principles, it would be nice seeking a common solution for many editors.
Could even become part of the standard library, who knows!

 

[John J Lee]

[John J Lee] [...]

If Mark Hammonds Windows editor does it, I don't see why Emacs and vi
shouldn't.

I know, for having worked at a Python code reformatter (in Python, of
course!), that proper presentation of Python source may be tricky.
If all involved people were able to agree on the same presentation
principles, it would be nice seeking a common solution for many editors.
Could even become part of the standard library, who knows!

I had the impression that Mark's thing (Pythonwin, I think it's called --
or is that the MFC wrapper? I can never remember.) used the standard
library, or hooked in at the C level, so that syntax colouring is always
correct -- unlike Emacs (and unlike vi, I guess).


John

 

[=?iso-8859-1?Q?Fran=E7ois?= Pinard]

[John J Lee]

I had the impression that Mark's thing (Pythonwin, I think it's called --
or is that the MFC wrapper? I can never remember.) used the standard
library, or hooked in at the C level, so that syntax colouring is always
correct -- unlike Emacs (and unlike vi, I guess).

You can never be sure to have syntax colouring correct unless you scan
the source from its beginning. Consider for example that you could have
long sections of Python code embedded in triple quotes, turning it all
into a single long string indeed. Most editors try to limit the amount
of text to consider for syntax colouring, as analysing a lot of text may
slow down the editor considerably. They try to limit the analysis to
the currently displayed text, and a bit before, not far.

 

[John J Lee]

[John J Lee]

I had the impression that Mark's thing (Pythonwin, I think it's called --
or is that the MFC wrapper? I can never remember.) used the standard
library, or hooked in at the C level, so that syntax colouring is always
correct -- unlike Emacs (and unlike vi, I guess).

You can never be sure to have syntax colouring correct unless you scan
the source from its beginning. Consider for example that you could have
long sections of Python code embedded in triple quotes, turning it all
into a single long string indeed. Most editors try to limit the amount
of text to consider for syntax colouring, as analysing a lot of text may
slow down the editor considerably. They try to limit the analysis to
the currently displayed text, and a bit before, not far.

No doubt you're better informed than me about what Pythonwin actually
does, but never say never. You could scan the whole thing once, then keep
everything 100% correct subsequently just by watching the edits. No, I
don't claim it would be easy!-)


John

 

[=?iso-8859-1?Q?Fran=E7ois?= Pinard]

[John J Lee]

[François Pinard]

You can never be sure to have syntax colouring correct unless you scan

No doubt you're better informed than me about what Pythonwin actually
does [...]

You may doubt, you may! I tried Pythonwin a bit, but never really
used it; it would be presumptuous for me to assert anything about it.