IDE

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

[Steve Menard]

Here's an idea : how hard would it be to replace emacs's ELISP
interpreter with Python, and translate the "main" ELISP modules to
python?

It would be a long and difficult task, in my opinion. One may also
consider writing an Emacs Lisp interpreter in Python for recycling bulks
of interesting Emacs Lisp modules or packages without translating them,
but this is also fairly daunting, pondering how to do this properly.

Just dream and suppose it was doable to translate things like Gnus (or
Calc) from Emacs Lisp to Python. It would not make them simpler to
learn nor to configure. The heaviness lies in the problem, not in the
language, so a change of language would not eradicate the heaviness.

I would love being able to use something like emacs and custimize it
to my hearts content. ELISP, however, just does not fit in my brain.

I did a great deal of Python customisation of Emacs, and also turned
many existing lines of Emacs Lisp into Python (for easier maintenance),
and finally, I got much more Python than Emacs Lisp customisation. I
used Pymacs for doing so, see http://pymacs.progiciels-bpi.ca (I think
the "official" URL is still http://www.iro.umontreal.ca/~pinard/pymacs).

An unexpected advantage, and I discovered this only later, appeared when
I switched from Emacs to Vim: all that Python code could be recycled
into Vim with a moderate effort. It could have been worse, for example,
if I had not been careful at well segregating, all along in my Python
code, the editor interface from the "algorithmic" parts.

 

[Ville Vainio]

Francois> [Steve Menard]

Francois> It would be a long and difficult task, in my opinion.
Francois> One may also consider writing an Emacs Lisp interpreter
Francois> in Python for recycling bulks of interesting Emacs Lisp
Francois> modules or packages without translating them, but this
Francois> is also fairly daunting, pondering how to do this
Francois> properly.

How about just reusing the elisp interpreter in its C form, wrapping
it as a python library and tweaking it enough to make it store all
objects in the python object space? GC would need to be replaced with
INCRED/DECREF, but other than that, shouldn't the implementation of a
Lisp interpteret be almost trivial?

Francois> Just dream and suppose it was doable to translate things
Francois> like Gnus (or Calc) from Emacs Lisp to Python. It would
Francois> not make them simpler to learn nor to configure. The
Francois> heaviness lies in the problem, not in the language, so a
Francois> change of language would not eradicate the heaviness.

Of course, that's why we would reuse those. New stuff (and hooks /
customization) could be implemented in Python. I imagine *many* more
people would be interested in improving, extending and maintaining
emacs if it was not in elisp; it's just not what kids want to use
anymore. The current slow pace of emacs development kinda makes it
obvious. Even the Common Lisp fans seem to dislike elisp.

Francois> An unexpected advantage, and I discovered this only
Francois> later, appeared when I switched from Emacs to Vim: all
Francois> that Python code could be recycled into Vim with a
Francois> moderate effort. It could have been worse, for example,

You switched from emacs to vim? That borders on blasphemy ;-).

Seriously, is Vim as customizable/programmable in python as emacs is
in elisp? If that is the case, I'm switching too...

 

[Dan Sommers]

... GC would need to be replaced with INCRED/DECREF, but other than
that, shouldn't the implementation of a Lisp interpteret be almost
trivial?

Okay, I can't resist: That looks like the Quote of the Week to me.

Regards,
Dan

 

[G. S. Hayes]

How about just reusing the elisp interpreter in its C form

Given the Deep Magic emacs does during the build process, I'm not sure
how easy that would be. If I recall correctly, it builds a minimal
Lisp interpreter, uses that to run a bunch of Lisp code, and then
coredumps the running image into a new executable. Even if you could
sort that out, you still have the problem of figuring out how to wrap
all the Lisp objects with appropriate Python objects.

 

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

[Ville Vainio]

How about just reusing the elisp interpreter in its C form, wrapping
it as a python library and tweaking it enough to make it store all
objects in the python object space?

Go for it, then!

Seriously, is Vim as customizable/programmable in python as emacs is
in elisp? If that is the case, I'm switching too...

Emacs Lisp is deeply soldered into Emacs internals. Vim has its own
language, which people sometimes call Vimscript, similarly tightened
into Vim. My feeling is that Emacs Lisp allows for a more intimate
handling of edit buffers and external processes than Vimscript does, yet
this intimacy has a price in complexity, so all totalled, they may be
perceived as comparable for most practical purposes.

Pymacs allows customising Emacs with Python instead of Emacs Lisp, and
then runs Python as a process external to Emacs, with a communication
protocol between both processes. Python may be built into Vim, and then
both Python and Vim use a single process. The same as Pymacs gives
access to almost all of Emacs Lisp, Python within Vim gives access to
almost all of Vimscript, but with a smaller overhead than Pymacs.

Pymacs is not Emacs Lisp, and Python in Vim is not Vimscript either,
tweaks are needed in both cases for accessing some of the underlying
scripting facilities. Pymacs is rather elegant, Python in Vim is rather
clean. Python itself is both elegant and clean, but one strong point of
Python for me is the legibility, which builds deeper roots on the clean
side than on the elegant side. All in all, despite I know how debatable
it can be, I guess I now have a prejudice towards Python in Vim.

 

[Paul Rubin]

Given the Deep Magic emacs does during the build process, I'm not sure
how easy that would be. If I recall correctly, it builds a minimal
Lisp interpreter, uses that to run a bunch of Lisp code, and then
coredumps the running image into a new executable.

That step is optional and with current computers, it's not really
necessary. It was intended to avoid making Emacs spend time loading
the Lisp files for the standard editing functions every time you
started Emacs. On the old Vaxes, that could take over a minute,
especially when other users were sharing the cpu. But on a reasonable
workstation these days, it takes less than a second, so you don't
really need the unexec any more.

Even if you could sort that out, you still have the problem of
figuring out how to wrap all the Lisp objects with appropriate
Python objects.

I think writing some Lisp/Python hybrid interpreter is possible but
doing a direct translation of Emacs Lisp to Python isn't really feasible.

 

[Paul Rubin]

Pymacs is not Emacs Lisp, and Python in Vim is not Vimscript either,
tweaks are needed in both cases for accessing some of the underlying
scripting facilities. Pymacs is rather elegant, Python in Vim is rather
clean.

What are these editors? Are they written in Python? How do they
implement the editing buffer? How do they implement searching
backwards for a regexp in the buffer?

 

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

[Paul Rubin]

[François Pinard]

Pymacs is not Emacs Lisp, and Python in Vim is not Vimscript either,
tweaks are needed in both cases for accessing some of the underlying
scripting facilities. Pymacs is rather elegant, Python in Vim is
rather clean.

What are these editors? Are they written in Python? How do they
implement the editing buffer? How do they implement searching
backwards for a regexp in the buffer?

Pymacs is just a add-on over Emacs, it is not an editor in itself, like
Emacs is. Pymacs is written half in Python, half in Emacs Lisp. Pymacs
allows Emacs to externally start a collaborating Python interpreter, and
be extended with Python instead of Emacs Lisp. The Python extension,
executed by the Python interpreter, handles editing by "asking" Emacs to
do the work. For example, it could call `lisp.buffer-substring()' to
get a copy of part of a buffer, massage that string in Python, and then
use both `lisp.delete()' and `lisp.insert()' to replace the original
text by the modified one. One normally writes `from Pymacs import lisp'
first, and the `lisp' object contains a lot of magic, including all
about the communication protocol.

Python in Vim is just a add-on over Vim, it is not an editor in itself,
like Vim is. Python in Vim is the full Python interpreter, written in
C, and linked right into Vim. Python in Vim allows Vim to be extended
with Python instead of Vimscript. The Python extension handles editing
by "directly" acting on `vim.current.buffer', which is a Python list
of buffer lines. One normally write `import vim' first, and the `vim'
module offers a lot of magic, provided by the Vim-Python integration.

Searching backwards for a regexp in the buffer? In both Pymacs and
Python in Vim, I would likely get Python to ask either Emacs, likely
through something like `lisp.regexp_search_backwards("REGEXP")', or Vim,
likely through something like `vim.command("normal ?REGEXP?")'.

 

[G. S. Hayes]

What are these editors?

Emacs and vi are the two most common editors for serious programmers
in the Unix/Linux world; vim is the standard vi implementation used on
most Linux distributions (and is widely available on other platforms,
including other Unixes as well as Windows, Macintosh, Amiga, Vax,
etc). GNU Emacs is the standard emacs implementation used on most
Unix platforms that have any emacs implementation (and is widely
available on other platforms, probably all those listed above but
certainly Windows, Macintosh, and other Unixes). Other common vi
implementations include nvi (used by BSD) and vile, other common emacs
implementations include XEmacs (formerly Lucid Emacs) and jed.

Are they written in Python? How do they implement the editing buffer?

Vim is implemented in C, and supports at least 4 scripting languages
for extensions (vim, python, perl, and tcl); most larger extensions
are written in Perl or Python, though some are in vim's built-in
script.

Emacs is a hybrid C/elisp implementation (elisp being Emacs' dialect
of LISP) and normally extensions are written in elisp. Pymacs allows
writing extensions in python.

How do they implement searching backwards for a regexp in the buffer?

At what level? In vim, at the user or vimscript level:
?some_regex
At the python level, you can use:

import vim
current_buffer=vim.current.buffer

And then use the standard Python re to search current_buffer (a list
of lines) or otherwise edit current_buffer. And you can treat
current_buffer basically as you would expect:

current_buffer[0]="New" # Change first line to "New"
current_buffer[0:0]="New" # insert new first line "New"
del current_buffer[9] # delete 10th line of buffer
current_buffer.append("Last") # Append line "Last" to buffer

Inside of vim, ":help python" has more info on the Python interface.

Alternatively, you could execute a Vim command from the Python
interface:

import vim
vim.command("?some_regex\n") #The search-backward command a user
would run

 

[G. S. Hayes]

You switched from emacs to vim? That borders on blasphemy ;-).

I did that too, after 4-5 years of Emacs. Modal editing works well
with my brain.

Seriously, is Vim as customizable/programmable in python as emacs is
in elisp? If that is the case, I'm switching too...

No, it isn't. Emacs has many more output options; vim basically only
supports text (and some file selectors and menus). So you couldn't
do, for instance, a web browser with inline image support in vim.

But you can access all vim commands, define new user functions and
keymappings, edit the text, set marks, etc.

So basically, it's a fully customizable text environment, and people
have done mail readers and so on in vim/Python. Getting debuggers
running in subshells and such is possible too, but basically only for
line-oriented tasks (no full terminal emulation).

But the general consensus in the Vim community is that Vim should
remain an editor, not an environment, and it should obey the Do One
Thing Well philosophy. The Emacs community often views Emacs as their
OS, doing everything from reading news/mail to playing games to
surfing the web from Emacs (and oh, yeah, editing text too). So don't
expect to find anything as polished as GNUS out of the box for
Vim--but do expect a lot of people who know how to make vim and slrn
work together very well.

Getting anything graphical interacting with Vim in a meaningful way
would be right out, at least until someone convinces Braam to add a
few things (like adding an input fd with callback), and polling
periodically can't happen either (so e.g. mail readers can only check
for new mail when the user hits a key, not every 5 minutes) until that
happens.