This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | Language embedding-aware formatting | ||
---|---|---|---|
Product: | editor | Reporter: | Tomasz Slota <tslota> |
Component: | Formatting & Indentation | Assignee: | Miloslav Metelka <mmetelka> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | ludo, mfukala, pjiricka |
Priority: | P2 | Keywords: | API, API_REVIEW_FAST |
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | TASK | Exception Reporter: | |
Bug Depends on: | |||
Bug Blocks: | 89283 | ||
Attachments: |
Diff of the added editor/indent module and related changes
Javadoc of the editor/indent module Commit log of trunk integration |
Description
Tomasz Slota
2007-01-03 10:01:45 UTC
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 infrastructure. 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. |