Inform parser for JEdit's SideKick plugin
Jesse
that I have created a JEdit plugin that provides an Inform parser for
the SideKick plugin.
If you are unfamiliar with SideKick, one of the really useful things it
allows you to do is see a tree representation of the file being edited,
and by clicking on any node in the tree, you are brought instantly to
the part of the file associated with that node. However, due to the
domain-specific nature of parsing a file into a tree, SideKick provides
no parsers of its own, leaving it to other plugins to provide parsers
for specific file formats. The object structure of an Inform game is
very tree-like in nature, so I decided to write a parser to help me
navigate through my source files, and I think it turned out rather
well. I suppose that eventually I will be submitting it to JEdit's
plugin archive, but I thought I'd post about it here first in hopes of
getting a few people to try it out, get a little feedback, and maybe
even catch some hideous bugs that escaped my testing process.
If you want to try it, I've made the plugin temporarily available at
http://www.urban-survival.com/InformSideKick/InformSideKick.jar. It is
a very small file, and all you need to do to install it is to put
InformSideKick.jar in the "jars" subdirectory of your JEdit profile
directory. Naturally, you need to have the SideKick plugin installed
as well, which is easy enough to do with JEdit's plugin manager.
Any constructive feedback is welcome.
Notes/Limitations:
-Has only been tested using JEdit 4.2.
-By default, your profile directory is called ".jedit" and is located
in your home directory. *nix users probably know where this is. In
Windows, you'll typically find your home directory at "c:\documents and
settings\your username".
-When everything is installed, select the Plugins->SideKick->Structure
Browser menu item to open a window for SideKick to use to display the
tree representation of your file. This window can be docked.
-The parser examines each line individually, so even though as far as
Inform is concerned it's perfectly legal to break up the "header"
portion of your object definitions into multiple lines, the
<object-class> <arrows> <identifier> "textual description"
<parent-object> sequence needs to all be on the same line, or the
parser will not give you an accurate tree.
-Although both the identifier and textual description are optional, the
parser expects to find at least one of them. If both are present, the
identifier is used for the name of the corresponding item in the tree.
If only a textual description is given, that is used. If neither is
present, the object will not be added to the tree, which could result
in an inaccurate tree representation of your file if you have given
this nameless object any children.
-Items in the tree with a golden icon next to them are objects that
have an identifier. Objects that have no identifier but do have a
textual description are represented by a blue icon. Objects that the
parser as determined to be malformed have a red icon. Malformed
objects are always placed in the top level of the tree to make them
easy to spot.
-There are currently 3 conditions under which an object is considered
to be malformed:
-If both arrows and a parent are given.
-If a parent is given that has not been defined earlier in the file.
-If arrows are used to indicate parentage, but no previously defined
object has enough arrows to be the object's parent.
-Currently, only objects are represented in the tree, but I have
thought about including verbs and functions in the tree as well, or at
least making their inclusion optional.
-You may be annoyed to find that every time the tree is rebuilt, any
nodes you may have expanded are collapsed. As far as I can tell, this
is not something I can fix at the parser level and is a limitation of
the current version of the SideKick plugin. I further convinced myself
of this by going into the source code for SideKick and finding a way to
modify it so that the expand state of the tree nodes is preserved. I'm
going to try contacting the author about fixing this in future releases
of the SideKick plugin, but if anyone is really interested, I could
also make my custom version of SideKick available for download.