Provide infrastructure for formatting code consisting of embedded languages like JSP, which may embed
I understand that this is critical and I would like to work on this ASAP. It's
necessary to agree on the appropriate SPI first and provide the corresponding
I've created a branch indent_91718 for the new indentation infra.
cvs co editor/indent editor/lib editor/libsrc
are currently branched (I will inform about possible additions).
In addition NbEditorDocument.java is branched so the following may be used:
cvs co -r indent_91718 -f editor/src
I've added FormatterImpl so the original actions should now delegate to the new
API where the new indent/reformat factories impls are registered.
Summary of the things that the new API/SPI attempts to solve:
1) Allow language-embedding specific operation i.e. reuse the formatters for a particular language in an embedded
context. Handle the automatic delegation in the infrastructure. If necessary provide a data transfer between upper-level
and embedded formatters.
2) Separation of providers of
a) fixing of line(s) indents (e.g. pressing Tab in emacs)
b) full code beautification (may change spaces inside the lines; add e.g. extra braces etc.).
If b) is not available it defaults to a)
2) Always operate on document and prefer incremental changes. This should eliminate the problem of moving breakpoints
and bookmarks to the begining of the reformatted area and support lexer.
Reformatting of a newly generated code without its final insertion into the document (aka IndentEngine.createWriter())
can be handled by performing of the insertion and reformatting it in a transaction; storing the reformatted code in a
string; doing of rollback (undo) of all these changes; output the string.
If the reformatters themselves prefer String => reformatted-String processing provide a support for making a diff
between the two and perform the incremental changes in the document.
3) Provide extra pre-(document-write-lock)-locking possibility (currently a usecase for the new java infrastructure that
needs to lock itself before acquiring any document locks).
4) The new API/SPI should coexist with the existing model of org.openide.text.IndentEngine and
org.netbeans.editor.Formatter. If the new SPI providers will be registered they will be preferred but if not the
original infrastructure should continue to work.
Created attachment 43694 [details]
Diff of the added editor/indent module and related changes
Created attachment 43695 [details]
Javadoc of the editor/indent module
I would like to ask for review. IMHO the fasttrack should suffice as the API and SPI is fairly small and simple.
There is a new editor/indent module that covers the usecases mentioned in this issue. The module implements
FormatterOverride for callback from editor/lib formatting legacy infrastructure.
Created attachment 43871 [details]
Commit log of trunk integration
Integrated in trunk.