[ jEdit-devel ] EditBus messages, folding, and perspectives

[Shlomy R. <sre...@gm...>]

Hi,

There are some jEdit issues I'd like to raise, which I happened to
encountered while working with SideKick.

1. Folding: Recently I implemented a fold handler for CtagsSideKick, since
the SideKick fold handler doesn't work well with the CtagsSideKick parser.
While doing so, I noticed that the SideKick fold handler algorithm, while
simple, is quite a waste of resources: To provide the fold level for each
line, it looks for the tree node corresponding to that line. For languages
such as C/C++/Java, the SideKick tree is typically an order of magnitude
smaller than the buffer size, so there are lots of redundant tree
traversals. I don't know if this leads to performance problems in practice,
but a single tree traversal would be enough to set up the folding for the
entire buffer. For the languages I've mentioned, if the buffer has N lines,
the tree would typically have N/10 nodes, and setting up folds for the
entire buffer takes about N*N/20 operations, instead of just N/10 (a single
tree traversal). I guess the performance hit can be felt when the SideKick
folding mode is used with large source files.
While this problem is specific to SideKick, I think this SideKick algorithm
evolves from the folding interface of jEdit, which is line-based. Of course,
SideKick could make some optimizations, like prepare the folding data the
first time it is called for a buffer, and then using the prepared data for
all subsequent calls for the buffer, but this would require some additional
complexity, which could more elegantly be solved by extending the folding
interface of jEdit. What do you think?
(And again, if this behavior does not cause performance problems in
practice, there is no need at all to handle it, but I find it hard to
believe that's the case)

Having mentioned folding, is there a way to customize the way the folding is
drawn in the gutter? E.g. style "Programmer's Notepad" - screenshot here:
http://www.pnotepad.org/wp-content/uploads/2006/12/207projandfind.png

2. EditBus messages: I think the documentation of these messages is a bit
lacking (in the jEdit reference manual). The meaning of some of these
messages is quite vague in the documentation, so, for example, I can't
figure out which messages I should respond to for handling the event of a
buffer switch. Because of this, I need to either examine the jEdit source
code in order to find which messages are sent when the event I'm interested
in takes place, or alternatively make the event happen and monitor the
activity log for EditBus messages. SideKick currently has a bug, that it
sometimes cannot determine the mode of the current buffer, so it doesn't
know which parser to invoke (in which case it logs an approriate message).
By monitoring the activity log, I found out that SideKick does not always
respond to the right messages, so I can fix it now, but I think this
situation can be greatly improved by making the reference documentation more
elaborate, or, even better, add a section to the plugin development guide
that describes the messages that are sent in various scenarios (e.g. which
messages are sent when the user opens a buffer, which messages are sent when
the user modifies a buffer, etc).

3. Perspectives: Many jEdit users do several types of work, which require
very different settings. E.g. a user may do C++ development some of the
time, work with XML/HTML files some of the time, and do some debugging some
of the time. Each type of work makes use of different plugins, different
dockable windows, different set of actions, maybe even different jEdit
settings (e.g. text area background color). Currently, the Docker plugin
enables quick switching of dockable windows, and the EditorScheme plugin
enables quick switching of color/font properties (both these plugins work by
saving a predefined list of jEdit properties in "perspective" files and then
loading them from these files and applying them). But there's a lot more to
it, e.g. changing the keyboard shortcut mappings, changing the buttons in
the toolbar, etc. I'd like to create a more complete plugin to allow quick
switching between perspectives (or perhaps extend EditorScheme for that).
For this, I need to collect the list of jEdit core properties that would
make up a perspective, and provide some API For plugins to specify their own
perspective-specific properties. What do you think? Any help would be
greatly appreciated.

Thanks,
Shlomy