Hi Edward,
Well we have gone some of the way in wrapping real Emacs in a python
wrapper in PIDA, http://pida.co.uk/
screenshot: http://pida.co.uk/files/screenshots/pida_0-5-1_16.png
I am not sure this is exactly what you mean, but it is certainly a
viable approach to achieving some of the things you are hinting about.
Ali
Yes, we actually send elisp across the wire for Emacs to execute. In
addition to commands, we found it necessary to be able to respond
asynchronously to Emacs events (e.g. when a new buffer has been opened).
There is a small amount of information here about the hows and whys:
http://pida.co.uk/trac/wiki/EmacsSupport
And you can browse the emacs integration code (which I would guess is
fairly PIDA-independent) at
http://pida.co.uk/trac/browser/trunk/pida/utils/emacs/emacscom.py
Ali
http://www.logilab.org/project/oobrother
has been our attempt at this. It drives a shell, emacs, vi, pylint and
a gtk-based app that includes a class browser, menus with actions,
generated forms, etc.
Code browsable at
http://www.logilab.org/hg/oobrother
--
Nicolas Chauvat
logilab.fr - services en informatique scientifique et gestion de connaissances
Pymacs is really a nice tool. But it has not been maintained in the
last few years. Since ropemacs (rope plugin for emacs) depends on it
and I needed to fix some of its problems I've started a mercurial repo
to make my fixes on it:
* repo: http://rope.sf.net/hg/rpymacs
* snapshot: http://rope.sf.net/hg/rpymacs/tip.tar.gz
I'll be happy if someone maintains pymacs once more (if no one
volunteers, I'll be happy to).
Regards,
-- Ali
edre...@yahoo.com wrote:
> This is intended as reply to Robin Dunn's excellent post:
I loved that post -- it's almost as if he scanned my brain when writing it.
However, in a little of the discussion I've since seen, I think the
problem is that a lot of folks want some pieces of what Emacs gives
them, but we all want different pieces.
> As a thought experiment, I would like to ask, suppose we waved a magic
> wand and produced a complete (whatever that means) Python (swig?)
> wrapper for Emacs: the *real* Emacs. Would that be what Robin wants?
> If not, why not?
hmm -- rather than answer that questions (not for Robin, but for me),
I'll tell you what I want, and you can decide if wrapping emacs is the
way to get it.
> In particular, what is the "25-year-old nearly dead technology" to
> which Robin refers. Is it elisp? Is it the c implementation?
Well, I won't comment in what is or isn't dead technology, but I know I
want to be able to script my editor in python, not lisp, so that needs
to be possible (and convenient, and clean). Can you write a python
wrapper for elisp that will feel like python?
> Something else?
For me, aside from scriptability in Python, the other think I want that
is different from emacs is a UI that conforms to modern GUI conventions
-- I spend much of my day in my code editor, but the rest of it in other
apps that all use the same keystrokes for the basic stuff like copy,
cut, paste, etc -- I want my editor to be the same as that. I also want
to be able to get at things I use less frequently with menus, toolbars,
etc. Somehow it just feels wrong to use Emacs on a Macintosh, so I never
have.
Emacs does support custom key bindings, so there is no real reason one
couldn't do a full re-map to a different paradigm, but I think you'd
break a lot of extensions in the process, and the extensions are the
real reason I use emacs. (actually Xemacs, but the point is the same).
> In other words, suppose we could access all of Emacs *itself* from
> Python. Would that be sufficient?
Maybe -- if there was total access -- but is this really easier than
building something on STC and other existing python modules?
> The biggest win was being able to think in
> terms of Emacs-like commands. I have lost track of the times that
> being able design at the level of do-this, do-that, do-another-thing
> has clarified my thinking.
A agree with this, and I think that's one of the key things I want in an
editor -- frankly, I wish all software was built with a scripting
interface first, and GUI second (or at least a full scripting interface
at some point!). It kind of reminds me of the KDE application
configuration philosophy (I don't know if they still stick to this):
- All configuration will be held in user-readable text files
- All configuration will have a GUI to manipulate it.
You really need BOTH of these. I this case it's:
- All functionality will have a scripting interface
- All functionality will have a GUI accessor (though I could relax
that to "most", or even "much")
Anyway, Robin's post list a bunch of must-have features, most of which I
agree with. However, with a good scripting interface, we can get most
specific features by writing a script, so I'll give a short list:
- Good scripting interface (in python, natch) -- what this means is
that every action one might do to text is some kind of function or method.
- Completely customizable key bindings (and a default set that matches
modern GUI standards)
- multiple views of the same buffer, and multiple top-level windows.
- A concept of "Modes" to support different languages, etc.
- soft-wrapping of text (this is the ONE thing that Emacs doesn't do
well!)
Sound like emacs? yup , expect for the modern UI and python scripting,
so maybe wrapping emacs is the way to get there. However, Peppy, and a
few other python editors are getting really close, so I don't know that
adding the big dependency and the complexity of wrappers really is the
best way to go.
that's my thoughts....
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
http://www.logilab.org/project/logilab-aspects ?
But after trying aspects and coping with their complexity, I am not
so sure they are a good idea in Python, for the language is very
flexible and dynamic already.
Amen, brother. In addition, some IDEs populate the menubar/toolbar
with every possible item and just disable the inapplicable items.
This is much more cluttered than simply leaving out the items that
don't apply to the sort of text file you're editing. Emacs does a
good job by dynamically modifying the menu depending on the major mode
and is what I tried to duplicate.
This was not as easy is I had hoped -- I even tried a constraint
solver to allow plugins to define what menu items they came before or
after. I don't have a great solution to this currently, as the items
insert themselves at some location in one of the menus at a default
position, with the idea that there will be a menu location editor at
some point where the user can reposition everything at will.
> So the goal must be to provide an architecture that
> allows developers to combine efforts.
Indeed, that's the problem. But it's a big one. A flexible
architecture is extremely difficult to write, which is why everyone
(myself included) seems to start out writing a flexible architecture
but ends up constraining themselves and and making choices that limit
the flexibility in order to get something working.
> I'll see if I can go over the interface of a few IDE/editors and give
> concrete examples of the above, that should show whether any of it
> makes sense in practice :)
Every discussion seems to mention Eclipse at some point, although it's
obviously in Java and if all of us here wanted to do that we wouldn't
be here. But I can't help but think that it's something of that
magnitude that we really want. I know how complicated these things
get -- I thought peppy would have a stable architecture long ago, but
the more flexible an architecture you develop, the more it explodes
with interactions among components.
Maybe a pure message passing scheme would result in less coupling, but
I've found message passing systems to be debugging nightmares.
Granted, most of my message passing experience is multiprocessing with
MPI, but it scars you. :)
At any rate, I'd love to see examples and documentation of other
architectures and how they've worked in practice. I'd love to point
to peppy's documentation for comparison purposes, but through all
fault of my own it has lagged far behind the development.
Rob
PyGTK has the ability to modify menus and toolbars on the fly. It merges
snippets of XML from various sources (in this case plugins), and can
unmerge them.
The user interface builder Gazpacho has a facility to edit this XML from
a UI.
Well I have no doubt you could build something easily as good as PIDA,
it has a long way to go. But it would make me very happy if the general
Pyxides direction was towards something PIDA-like, because then I would
use it.
The main problem I have with PIDA fitting into the Pyxides movement is
that its PyGTK, and almost everything else seems wxPython orientated. I
hope that whatever happens will eventually be GUI agnostic.
Ali
You mean like wx.lib.pubsub? I mention it because I've found it to be
quite convenient for plugging things together without needing to know
about widget hierarchy, object relationships, etc. I haven't altered
my editor to use it fully (right now, I'm using the standard wxPython
event system, manually reordered handling, etc.), but newer tools I'm
writing for other projects use it.
- Josiah
Thanks for the pointer to the new version of pubsub; I wasn't aware of
this new version.
> As Rob mentioned, messaging can increase the difficulty of debugging
> but I find that the level of effort required depends a lot on the
> library.
One of the things I would have helped me in my previous dealings with
wx.lib.pubsub would have been the ability to set a breakpoint when a
certain message was sent. I looked through your v3 code a bit --
maybe with some slight modifications the __notifyOnSend could be used
for that purpose? Probably OT for pyxides; I'll post something on
your forum when I've had a better look at pubsub v3.
Rob
well, no. It's a start, but it really means that you have to now and
work with elisp to work with the editor component. I was thinking more
along the lines of how you wrap C++ or ObjC, so that:
(name-of-elisp-function, parameter1, parameter2)
becomes:
name-of-elisp-function(parameter1, parameter2)
(if I remember lisp syntax at all!
A simple example like that looks easy, but I suspect it'll get a lot
harder when you try to do something real.
> Really? I don't know enough about Emacs to say for sure, but does the
> viper (vim) plugin break all other Emacs extensions? That's hard to
> believe.
I don't know, I've never used it. What I'm referring to is that the
extensions have their own key bindings, and so you may have to re-bind
all those too. Though I think the convention is Ctrl-C before the
extension commands, so, though you'd want Ctrl-C for "copy", you may be
able to just re-bind that. I have no idea how viper works.
>> Maybe -- if there was total access -- but is this really easier than
>> building something on STC and other existing python modules?
>
> My experience is that trying to duplicate Emacs's functionality
> requires more than a year of work, regardless of what tools one starts
> with. In particular, Emacs has hundreds of commands to support all
> the items on Robin's list. True, most commands are fairly easy to do,
> but the job remains daunting.
Quite true. However, there is always the trade-off between getting
something functional fast, and getting it right. Unless the code you're
wrapping was really designed to be a library or component (and maybe
emacs was), then you'll always be fighting it (or your users will),
because it will never fit in.
> Furthermore, implementing the minibuffer itself takes a lot of work.
Only because your framework didn't support that idea from the beginning
-- I'm guessing you didn't start with a many-to-many relationship
between buffers and views. But even if I'm right, it doesn't change your
point -- emacs has a lot that's done right, and is incredibly
feature-full, well tested, and debugged. It's a LOT of work to get
anywhere near that stage.
If you can embed emacs in a python IDE and make it not feel like emacs
-- I'll be glad to use it!
--
Don Dwiggins
Advanced Publishing Technology