The plugin currently provides a useful but limited set of features. Please take a look at it and let us know what suggestions you might have for improvements or additional features. What follows are some technical comments on the plugin that have also been posted on the jedit-devel mailing list.

The plugin is designed to present task comments for more than one buffer at a time, but the feature is not available because the code is not completely realized. Are there any thoughts on how this should be done? Here are mine: the sets could be tied to file set classes used by jEdit's Search and Replace routines, so you could have all open buffers, all files in a directory or directory tree satisfying a file mask, or a single buffer.

This would be a good place to include a project-`type` class containing arbitrary buffers, and it could form the basis of a common project architecture for various plugins. I haven't thought through a GUI for this, but a toolbar of some kind seems like a good idea.

What I have in mind (vaguely, so far) is a class consisting of a list of files (or a file mask specification, including a flag for recusion through subdirectories), name and description attributes, serialization in and out of XML, and perhaps some methods representing basic operations on the project. It might be better to keep this as purely a data model class. Then a ProjectService interface could be used for registering plugins dealing with projects with a ProjectManager plugin for providing a GUI for managing and executing services. The basic idea would be to have a small API that project-oriented plugins could target, so that extensions would be easily integrated and users could pick and choose what they wanted for their projects (or even for individual projects).

Returning to TaskList, there are some features that would be easy to add: re-parsing a buffer on a save, for example. Maybe there are also some other features that people can think of. I would love to hear suggestions and get contributions. What I would be especially interested in are reactions and suggestions about a common Project API. Design will be very important here, and a refined design that reflects ideas from a number of people at the outset and that will be comfortable for plugin developers to work with could do a lot to take jEdit to the "next level".