Elm code is an elementary feature that is currently being developed outside the main API. It provides users with a rich experience for viewing and editing code, source control comparisons etc. The aim of elm code is to be "the terminology of code editing". Suggested use cases for elm code are:
- code editing (with syntax highlighting, error inlining and other cool features)
- displaying of source control diffs inline
- text file display with source control status in margin
- log tailing to highlight errors / warnings etc
The above items could also be combined to allow, for example, code highlighting within a diff display.
Elm code has been merged into the main elementary library (as BETA) though it is still only used by Edi and Ecrire; where it provides all the editing and text rendering functionality. It currently only supports files in UTF-8 format but has many built in syntax highlighting features and these are easily extended with simple definitions.
Elm code is composed of two parts:
- Backend that handles all required information about the code to display, any local modifications and markup / status associated with the loaded code.
- Frontend widget that is able to link to one backend. This model will allow multiple views (widgets) of the same content (backend) and all views update to display content changes in real time.
Features of the front end widget:
- All text is monospace like a terminal
- Handle code highlighting from backend metadata ( See Syntax Support )
- Optionally display line numbers and whitespace characters
- Handle line marker such as debug stop point, code warnings from supplied metadata
- Handle object insertion between line (to display compilation errors, context sensitive ui and metadata etc).
Future features we're implementing
- Handle code folding directly inside the widget
- Handle source modifier flags on a per line basis (to see which part of file has not yet been committed to disk)
- Handle code expansion via callback (expansion on a color could then build a widget that will display color palette under the code, or expansion on a function will expand to the code of that said function depending on what the callback decide in fact)
- Handle miniview as an image object with per character pixel
- Use Edje extensively for dividing the view (between miniview and current code view), per line, per block (to be able to animate folding)
The backend features:
- parse files sequentially in the background, firing a callback when each line is complete and the full file is loaded
- run syntax or status plugins to add appropriate metadata to loaded lines - run a callback as each line is updated
- supports multiple syntax / parse plugins for any file so we can, for example, support clang parsing for a C file then use an English grammar one for comments.
- the backend allows multiple front-end widgets to connect so multiple views can be supported for one file
It will also support:
- keep track of the (scope defined) indentation level so it can be referenced to cleanup or guide newline cursors etc
As a helper we intend to provide a parser that will work out of the box with jEdit XML files that describe code syntax (but with less context information than an LLVM backend would have). Those XML files once parsed will be stored in a eet cache for faster and more efficient use. That eet could be part of the package to avoid the need of installing jEdit.
Nice to have
It would also be great to provide, in some way:
- Handle code auto-completion via callback
- Handle side by side diff display in some way or another