Lisp Development Tools
roadmap

DONE

Understand the basics of eclipse pluggin and syntax highlighting programming.

DONE

Split the code between "comment" and "code" and make a comment syntax colorizer.

DONE

Make a symple syntax highlighter for strings, keywords and suck.

DONE

Start ripping the HyperSpec of all the necessary info to include in a future content assist and code complete, and all the symbol names and their types for use in the syntax highlighter.

DONE

Use the ripped HyperSpec symbols in the syntax highlighter.

DONE

Parenthesis match. Possibilitate more modes than the default.

DONE
DONE

Double click strategy:

• Select the next () block when you double click before a '('
• Allow for selection of keywords (:asd only selects "asd", not ":asd")

DONE

Remaining hyperspec extraction.

Successfully ripped: Functions, Accessors, Variables, Conditions, System Classes, Macros, Types, Special Operators, Declarations, Symbols and Classes.
These are HyperSpec designations.

DONE

Content assistant and code completer.

The code completer is done, the context information is missing.
Code completion means you can put in lisp function names and it will complete them and show relevant HyperSpec documentation.
Lack of Context info means you won't be shown relevant context information after choosing an option in the code completer (you won't be shown some text highlighting which argument in the function you're currently working on, for instance). This feature may or may not exist in the future, depending on feedback (or force of will).

TODO

Syntax coloring of remaining syntax:

• 'quotes
• '(lists)
• `(more ,lists)
• #2A(arrays)
• #S(structures)
• \specialCharacters
• And so on.

TODO

Get a nice coloring scheme. I suck at this, I'll a web designer friend.

TODO

A configuration pannel for colors.

TODO

Auto indentation and it's conf pannel.

TODO
TODO

Insertion of user defined functions into the spec, meaning some special parse of defun or something.
Make sure this definition lives across files in the same project, but not across diferent projects.
Rip the extremely-complicated-to-rip hyperspec (the type of hyperspec that is split trough diferent files, the a_<symbol name>.htm files.

TODO

Better code navigation. Allow to jump () pairs or to the next defun/defstruct/whatever, using some ctrl/alt/shift combination with the arrow keys (or whatever keybind...)

TODO

Finally, start thinking about Steel Bank Common Lisp integration. What's necessary in order to talk to sbcl, to evaluate code, how to parse the output.
Important: What is a good visual interface with a lisp runtime?
Should there be little buttons that would make it easy to evaluate each top-level form? I don't want people to have an "Inferior Lisp" type of interface in order to know wether the function returned t or nil! I want people to hover the mouse somewhere or do some other easy equivalent to get this info. Since lisp is very used in a write-form--get-result sort of way (as well as the usual compile--run-program loop), I want this to be easy and intuitive.
Note that ldt must be revolutionary in this point. Writing code The Lisp Way should be exceptionally facilitated.

TODO

Invent some general-purpose interface that can later be used with other Lisp implementations. Make sure it's easy to use new implementations and that you don't have to have implemented all of the interface for the rest to work; For instance: you can have the evaluate interface coded but the debug interface not coded.
This interface deals only with the comunication between the plugin and the CL implementation, it has nothing to do with the user interface (UI).

TODO

Implement SBCL's evaluation interface.
This obviously includes errors and warnings.

TODO

Build a UI layer around the CL interface.
Make sure it rocks ;)

TODO

Implement SBCL's debug interface.

TODO

Code LDT's debug view.

TODO

Pump up the plugin, refactor code, redo what must be redone.
Make the current features clean, sharp and beautiful.

TODO

Add/fix all minor features/anoyances that might have been sugested by anyone who tried ldt.
Make sure that what exists is solid.

TODO

Version 0.6-t must be ready for academic use.
It must be reliable, solid, reliable and solid.
It's a milestone before new production-quality features.

TODO

Version 0.6-lambda is a polished and entirely reliable version with no new features.
This means that all features any user feels as needed for academic use should have been sugested and implemented by now, and should be rock-solid. This version may or may not be developed at the same time as a more production-quality branch.