Robin Dunn wrote:
I've been an Emacs
user for more than two decades,
>... I would like to dump it for something else, iff the RIGHT
something else
came along.
I'm in exactly the same situation!
My must-have list is almost entirely a subset of Robins, but a few
additional comments:
> it is not
just the emacs-style key-bindings that keep me using Emacs
My too -- in fact, I don't like, or want to keep using Emacs bindings --
I want the common stuff to match modern standards, and all the other
apps I use (ctrl+[X,C,V] for cut, copy, paste, for instance).
* Python should be just one of the languages that this editor supports,
key, key key! I spend most of my computing life in a text editor, but
only some of it in Python. I think it's critical that this be the intent
from the beginning of the design process.
Key to this is that (X)Emacs has a very high quality mode for almost
everything you an imagine. IN fact, it's got the best Python mode I"ve
seen in an editor (and the best LaTeX one, and...). Expecting the editor
developers to make all those modes (and make them well) is out of the
question (indeed, one major beef I have with BBEdit on the Mac is that
you can't make your own mode. They have a Python mode, but it just
doesn't handle indentation right -- there was a discussion with the
developers a few years back, and short version of the response was: "you
shouldn't want it to work that way". I don't think any of the developers
are Python users -- so how they heck would they know? -- but I digress)
You don't need to write the modes, just have the infrastructure so that
they can be (easily) written.
So how is this done? it goes a bit beyond plug-ins and lexers. Emacs
uses the the concept of Major and Minor modes. Major modes are things
like Python mode, Plain Text Mode, LaTeX mode, etc. Minor modes are
things like Fill-Paragraph, Word Wrap, etc. Another piece of this is the
key bindings standards -- bindings peculiar to Modes are all proceeded
with a ctrl+C -- that way different modes don't stomp on the core
bindings or each-other. There are also a standardized set for the common
uses: "Comment Text", "Compile", etc.
I'm not sure about the multi-key bindings thing -- but it does have some
nice use in Emacs.
* One key feature that Emacs Does Not have (or I haven't found it) is a
good soft wrap for text -- that is, it wraps in screen, but doesn't
insert and line endings.
* Incremental search, both forward and reverse,
Easily done with very few keystrokes! Emacs has ctrl+s, then you start
typing what you want to search for. If you hit ctrl+s again, you get the
last thing you searched for.
* Multiple top level windows, and able to show any buffer in any TLW,
including those that are already displayed in another TLW.
Yes, Yes, Yes!!!! Multiple views of the same buffer is very useful.
* Able to have selections be either a stream of characters or a
rectangle.
another key feature, though I'm not thrilled with how Emacs does it --
at least not visually -- there isn't a rectangular selection that you
can see. -- I also haven't found "copy rectangle", only "cut rectangle",
but that's probably my lack of effort.
* Similarly, avoid using popup dialogs whenever possible. This includes
things like the file dialog.
yes, yes, yes -- the Emacs standard is that if use a toolbar button or
menu to ask to open a file -- you get a dialog. If you use the keyboard,
you get a mini-buffer.
* Oh, and about opening files -- the file open (and save as) should
always default to the same dir that the file you are currently working
in is in-- that has a very high probability of being near where you want
to open or save something.
I don't mind seeing the file dialog if I
select a menu item,
If the file dialog is completely keyboard controllable -- that's not too
bad.
All editor commands should be named and can be bound to keys by name or
executed by name in this way.
This is key -- an extra level between UI action and actual command -- it
makes for better command line use, customization of key bindings, macro
writing, etc.
Along these lines -- the "tab" key should be able to be bound to "Indent
this line properly", rather than "put a tab here", even if "put a tab
here" is defined to use 4 spaces, or whatever. And hitting the delete
key at the end of an indentation should mean "remove one level of
indentation", not "delete a space".
* If it is a full IDE it would be nice to have a way to start just the
code editor portion for quick edits.
yup -- an IDE should have a "just edit files" mode. For example, as far
as I can tell, you can't do that at all with Eclipse!
* Brace matching -- not as key for Python, but critical for other languages.
* Platform independent -- I work regularly in Windows, Linux and OS-X --
one major productivity sap is that I don't have the same editor on all
three (yes, I know I can run (X) emacs on all three, but it just doesn't
"feel" right on Windows or OS-X)
Dusty Phillips wrote:
To this list: Which of the current Python editors would you say
supports the most of these features already? What about among the
current wxPython editors?
None close enough for me to get far using them -- the multiple top-level
frames is a must-have for me. Peppy is looking great, but isn't quite
been ready for prime time yet.
--
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
[EMAIL PROTECTED]
