Re: [PyCrust] PyAlaMode

[<po...@or...>]

Fernando Perez <fp...@co...> writes:

> Patrick K. O'Brien wrote:
> [snip]
> 
> > Like PyCrust, PyAlaMode has a modular design and is both a library of
> > components that you can use in your own programs as well as a set of
> > standalone applications.  Now that I've started this thing, I'd like
> > it to become the best Python source code editor of all (even though
> > I'm partial to Emacs).  If you've got suggestions or would like to
> > help, please let me know.
> 
> This sounds great.  But as much as I'd like to, so far I've been
> unable to stop using Xemacs.  I've tried a bunch of 'new' editors and
> keep coming back to Xemacs because some basic _editing_ features that
> make 'real life' coding efficient are missing from most other tools
> out there.

I'm using Emacs to create PyAlaMode, so I know exactly how you feel.
In fact, I even use Emacs Gnus as my email client.  ;-)

> So here's my _personal_ laundry list of things any editor needs to
> fill out to compete with (X)Emacs:
> 
> - Fully configurable keyboard bindings.  This one is an absolute
> requirement for me.  If I can't set a  tool to use exactly my bindings
> (so I can uniformize them across tools), I won't use it. Period.

I don't yet know how easy this will be using Scintilla.  I have a
feeling it won't be easy, which is a shame.

> - Fast keyboard-based opening of files and buffers with
> tab-completion. Graphical dialogs are great, but when I know where
> things are in my directory structure, it is far more efficient just to
> type names in the minibuffer.

I'll keep this in mind.  Perhaps a configurable choice between the
native file selector dialog and a more keyboard-friendly file selector.

> - Minibuffer for functional control of the editor.  Emacs, jed and lyx
> (my 3 favorite text editing tools) all have this, and I find it
> essential for real life work.

Sounds good.

> - Incremental search like in Emacs, with instant highlighting of all
> occurrences in the current page.
> 
> - Regexp search/replace without graphical dialogs (again, that minibuffer thingy).

More good stuff.

> - Multiple windows open with the same list of underlying buffers.
> This allows me to view two parts of the same file.

Right now you can open more than one file.  I haven't figured out all
the checks that need to be in place to have more than one buffer over
the same file, but the design should allow it.  You would think
someone would have a design document out there somewhere for a good
object model for a document editor.  I haven't found it.

> - Split one window in two or more parts (vertically/horizontally)
> showing the same buffer or different ones.

Should be possible, but I won't try it for the first release.

> - Grep/diff support (emacs' ediff mode is incredibly useful when doing
> complicated code merges, for example).
> 
> - ChangeLog support built into the editor.  When I fix code, all I
> need to do is type C-x-4-a and I get my changelog entry pre-made with
> all the relevant info.  This is a huge time-saver which I need every
> day.

And I use the CVS features of Emacs every day, but that won't be at
the top of my priority list for a while.

> - Code indent/dedent features and code commenting/uncommenting for
> blocks. Since python doesn't have multi-line comments, emacs' ability
> to comment/uncomment a large section with one command is extremely
> useful.

This needs to be there soon.

> - Syntax highlighting for many languages.  I don't want to think in
> terms of 'python editor', 'C editor', 'shell script editor', etc.
> They are all text files, and I want to edit them all, with proper
> color highlighting and auto-indenting, in one single tool.

This is possible with the Scintilla control, but my initial focus is
on editing Python files, since the introspection capabilities
(autocompletion and calltips) are the main thing that PyAlaMode has
that Emacs (and most other editors) does not.

> So there it is :)
> 
> I know that you are just announcing an early pre-release (well, CVS),
> so I understand that some of this things are probably nowhere close
> yet.  But I've just seen too many 'new editor' projects come out
> which, while promising, end up just feeling like toys for real work.
> 
> I'd love to have a modern editor with a good graphical toolkit (Xemacs
> is horrible there) and robust python support.  So I truly wish you
> success with this, and I'll  be the first to use it.  But for that
> unfortunately it will have to meet a relatively stiff standard for me,
> because I need the tool to help me deal productively and quickly with
> large codebases.
> 
> So I hope this project does indeed succeed, because having a well
> integrated python environment with editing/ python shell interaction
> would be fantastic.
> Best of luck!

Thanks for the feedback and encouragement.  If you (or anyone else
reading this) have any idea how to accomplish any of this, please let
me know.  In particular, I'm looking for information on a good object
design for an editing framework.  I've looked through all my design
patterns and programming books and haven't found anything particularly
good.  But since I'd rather improve a wheel than reinvent one, I'm
still looking.

Does anyone know how Emacs is designed?  And how the design allows for
such configurability?  And how to do something similar in Python?

-- 
Patrick K. O'Brien
Orbtech      http://www.orbtech.com/web/pobrien
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------