(Major) Feature proposals, and some impressions on switching from emacs to jEdit
Submitted by on Saturday, 19 February, 2005 - 05:33
Hello,
I recently gave jEdit a test drive. Some background: I'm an emacs user (5+
years) who is looking to switch editors. My reasons are that (a) hacking on
emacs is hard, I hate lisp, and accomplishing anything serious is just way too
much trouble (b) emacs development has slowed down, to the point that emacs is
now missing some of the features that the newer editors have e.g. folding (c)
the emacs syntax highlighting and indent for the languages I use most is broken
in very annoying ways. On the other hand I love emacs because (a) I can do
everything without using the mouse and (b) I can do everything without opening
any windows or dialogs outside my one editing window. I cannot stress these
two features enough. Not that I don't like having the gui stuff - it is a
great learning tool until you memorize all the shortcuts, and then great to get
the less-often-used stuff. No gui makes emacs very hard to learn. But being
forced to interact with a gui all the time while editing is a deal-breaker. I
edit with the keyboard.
I have now tried out jEdit pretty thoroughly, including configuring it exactly
the way I want, installing a whole bunch of plugins, using it for about half my
editing needs for a week, and writing a simple plugin.
Overall impression: jEdit is a very solid editor. It is a contender for emacs
replacement, and that is saying *a lot*! Superior in some regards (syntax
coloring, text folding, ease of writing extensions). Speed is about the same.
It has a few things which make it less ergonomic for heavy use though, and I
really want to fix those. I consider it to have enough promise that I would
actually spend time to improve it.
Now the problem areas:
major stuff:
* dialogs considered harmful: a lot of functions which can be done in emacs
without opening a modal dialog require one in jedit. examples include
open-file, save-as, find-and-replace, confirm-close. this is bad because (a)
it is slow (b) the dialogs are modal (c) it usually requires switching from
keyboard to mouse which is extremely unergonomic.
* many different text areas: a number of functions seem to have text areas
which are not JEditTextAreas, and in which the regular editing commands do not
work (try C+backspace). this includes the actionbar, search bar, autocomplete,
file browser, and many/most of the plugin interactions (e.g. console). this is
related to the fact that they are displayed in modal dialogs or other
specialized gui components instead of in regular text buffers (as in emacs).
* there is no way to pass parameters to an action in the action bar (other than
repeat count). e.g. C+enter open-file foo.txt or C+enter mode java . As a
result gui dialogs are necessary for each command like this.
* ambivalent about the way autocompletes work. I think I prefer the
completions showing in a temporary split pane (as in emacs). the
scrollable-menu-in-middle-of-screen approach is harder to use since you can't
(for example) page down or search, and a long list means you have to use the
mouse. also, one gets used to reading text that starts at the left margin and
has the regular text colors. using numbers to select choices is a nice touch
though.
minor stuff:
* action-bar history should not record simple keyboard navigation. perhaps
there should be a way to look at the complete history (CS+enter?), but
"prev-char" is not useful most of the time.
* autocomplete completes from the middle, not just start. this is potentially
useful, but only if there is no start-completion. the order of completions is
imperfect, typing "save" in actionbar and hitting tab shows a list in which
"save" itself is the third item.
* tab should always cycle through possible completions. C+b may be better as
C+tab, and should also cycle (and show the selected completion inserted into
the buffer).
* C+b only completes from the same buffer, not all opened buffers.
* buffers cannot be named without being stored on disk (or a vfs?). if buffers
are used for interaction (as in emacs), this would be very useful. also, there
is no command to switch to a named buffer.
* stress test: open 5Mb of text - works reasonably well, memory usage is 12Mb.
replace every 'a' with 'b' in 5Mb of text - works in 4.3pre1 (fast, but 44Mb
memory used), fails in 4.1 (out of memory, over 100Mb used). open 5Mb of
syntax-colored code - can view ok, but getting random exceptions when typing
into it (in 4.3pre1).
* need scratch buffers (not saved to file, not named, and no warning when
closing)
* selections should not go away when switching buffers.
* need to read man pages without leaving jedit. I have written a plugin that
does this (JManpagePlugin, I'll post that in a bit).
I realize that some of the things I would like to see are major changes, and
that many users may not like them
In any case they should be optional.
If you think it is better, I could make them into a plugin (or plugins) instead
of adding them to the core. From looking at the plugin interface, I believe
it is possible to write plugins for actionbar-and-buffer-based (non-dialog)
file open/save, directory and archive browse, search-and-replace, autocomplete,
and console. I can do most of that, but I'm sure I would need some help when I
get stuck, and of course if anyone wants to work with me on these features that
would be great. Passing parameters using the actionbar and a few other
supporting core hooks would be very useful for this. Making the actionbar and
search bar into JEditTextAreas can only happen in the core and looks pretty
major (but very nice, if possible).
Well, there it is, what do you guys think?
-A.
P.S. I imagine you might think that "I just want to turn jedit into emacs". In a sense, I do, I want all the good (in my opinion) aspects of emacs. Using buffers for interaction instead of dialogs is one of the ways in which emacs is better (although I agree it is not for everyone, and so it should be optional). In another sense, no, I want an editor that is the same or better in all regards, not better in some but worse in others.
--------
I'm cross-posting this to jedit-devel and here so more people have a chance to comment. I'd post it under my account but for some reason I can't log in (using drupal.org).
I recently gave jEdit a test drive. Some background: I'm an emacs user (5+
years) who is looking to switch editors. My reasons are that (a) hacking on
emacs is hard, I hate lisp, and accomplishing anything serious is just way too
much trouble (b) emacs development has slowed down, to the point that emacs is
now missing some of the features that the newer editors have e.g. folding (c)
the emacs syntax highlighting and indent for the languages I use most is broken
in very annoying ways. On the other hand I love emacs because (a) I can do
everything without using the mouse and (b) I can do everything without opening
any windows or dialogs outside my one editing window. I cannot stress these
two features enough. Not that I don't like having the gui stuff - it is a
great learning tool until you memorize all the shortcuts, and then great to get
the less-often-used stuff. No gui makes emacs very hard to learn. But being
forced to interact with a gui all the time while editing is a deal-breaker. I
edit with the keyboard.
I have now tried out jEdit pretty thoroughly, including configuring it exactly
the way I want, installing a whole bunch of plugins, using it for about half my
editing needs for a week, and writing a simple plugin.
Overall impression: jEdit is a very solid editor. It is a contender for emacs
replacement, and that is saying *a lot*! Superior in some regards (syntax
coloring, text folding, ease of writing extensions). Speed is about the same.
It has a few things which make it less ergonomic for heavy use though, and I
really want to fix those. I consider it to have enough promise that I would
actually spend time to improve it.
Now the problem areas:
major stuff:
* dialogs considered harmful: a lot of functions which can be done in emacs
without opening a modal dialog require one in jedit. examples include
open-file, save-as, find-and-replace, confirm-close. this is bad because (a)
it is slow (b) the dialogs are modal (c) it usually requires switching from
keyboard to mouse which is extremely unergonomic.
* many different text areas: a number of functions seem to have text areas
which are not JEditTextAreas, and in which the regular editing commands do not
work (try C+backspace). this includes the actionbar, search bar, autocomplete,
file browser, and many/most of the plugin interactions (e.g. console). this is
related to the fact that they are displayed in modal dialogs or other
specialized gui components instead of in regular text buffers (as in emacs).
* there is no way to pass parameters to an action in the action bar (other than
repeat count). e.g. C+enter open-file foo.txt or C+enter mode java . As a
result gui dialogs are necessary for each command like this.
* ambivalent about the way autocompletes work. I think I prefer the
completions showing in a temporary split pane (as in emacs). the
scrollable-menu-in-middle-of-screen approach is harder to use since you can't
(for example) page down or search, and a long list means you have to use the
mouse. also, one gets used to reading text that starts at the left margin and
has the regular text colors. using numbers to select choices is a nice touch
though.
minor stuff:
* action-bar history should not record simple keyboard navigation. perhaps
there should be a way to look at the complete history (CS+enter?), but
"prev-char" is not useful most of the time.
* autocomplete completes from the middle, not just start. this is potentially
useful, but only if there is no start-completion. the order of completions is
imperfect, typing "save" in actionbar and hitting tab shows a list in which
"save" itself is the third item.
* tab should always cycle through possible completions. C+b may be better as
C+tab, and should also cycle (and show the selected completion inserted into
the buffer).
* C+b only completes from the same buffer, not all opened buffers.
* buffers cannot be named without being stored on disk (or a vfs?). if buffers
are used for interaction (as in emacs), this would be very useful. also, there
is no command to switch to a named buffer.
* stress test: open 5Mb of text - works reasonably well, memory usage is 12Mb.
replace every 'a' with 'b' in 5Mb of text - works in 4.3pre1 (fast, but 44Mb
memory used), fails in 4.1 (out of memory, over 100Mb used). open 5Mb of
syntax-colored code - can view ok, but getting random exceptions when typing
into it (in 4.3pre1).
* need scratch buffers (not saved to file, not named, and no warning when
closing)
* selections should not go away when switching buffers.
* need to read man pages without leaving jedit. I have written a plugin that
does this (JManpagePlugin, I'll post that in a bit).
I realize that some of the things I would like to see are major changes, and
that many users may not like them
In any case they should be optional. If you think it is better, I could make them into a plugin (or plugins) instead
of adding them to the core. From looking at the plugin interface, I believe
it is possible to write plugins for actionbar-and-buffer-based (non-dialog)
file open/save, directory and archive browse, search-and-replace, autocomplete,
and console. I can do most of that, but I'm sure I would need some help when I
get stuck, and of course if anyone wants to work with me on these features that
would be great. Passing parameters using the actionbar and a few other
supporting core hooks would be very useful for this. Making the actionbar and
search bar into JEditTextAreas can only happen in the core and looks pretty
major (but very nice, if possible).
Well, there it is, what do you guys think?
-A.
P.S. I imagine you might think that "I just want to turn jedit into emacs". In a sense, I do, I want all the good (in my opinion) aspects of emacs. Using buffers for interaction instead of dialogs is one of the ways in which emacs is better (although I agree it is not for everyone, and so it should be optional). In another sense, no, I want an editor that is the same or better in all regards, not better in some but worse in others.
--------
I'm cross-posting this to jedit-devel and here so more people have a chance to comment. I'd post it under my account but for some reason I can't log in (using drupal.org).
