| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This mainly takes CppEditorSupport apart.
* Parsing is now invoked by CPPEditorDocument itself by listening to
QTextDocument::contentsChanged().
* Upon construction and destruction CPPEditorDocument creates and
deletes an EditorDocumentHandle for (un)registration in the model
manager. This handle provides everything to generate the working copy
and to access the editor document processor.
* A CPPEditorDocument owns a BaseEditorDocumentProcessor instance that
controls parsing, semantic info recalculation and the semantic
highlighting for the document. This is more or less what is left from
CppEditorSupport and can be considered as the backend of a
CPPEditorDocument. CPPEditorDocument itself is quite small.
* BuiltinEditorDocumentProcessor and ClangEditorDocumentProcessor
derive from BaseEditorDocumentProcessor and implement the gaps.
* Since the semantic info calculation was bound to the widget, it
also calculated the local uses, which depend on the cursor
position. This calculation got moved into the extracted class
UseSeletionsUpdater in the cppeditor plugin, which is run once the
cursor position changes or the semantic info document is updated.
* Some more logic got extracted:
- SemanticInfoUpdater (logic was in CppEditorSupport)
- SemanticHighlighter (logic was in CppEditorSupport)
* The *Parser and *Processor classes can be easily accessed by the
static function get().
* CppHighlightingSupport is gone since it turned out to be useless.
* The editor dependency in CompletionAssistProviders is gone since we
actually only need the file path now.
Change-Id: I49d3a7bd138c5ed9620123e34480772535156508
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
Reviewed-by: Erik Verbruggen <erik.verbruggen@digia.com>
|
| |
|
|
|
|
|
|
|
|
| |
...instead an ITextEditor.
The ITextEditor was only used to access the file path and QTextDocument
via the BaseTextEditorWidget.
Change-Id: Idef2b8162b992fe3718e16e2a046e2ff214846f2
Reviewed-by: Erik Verbruggen <erik.verbruggen@digia.com>
|
| |
|
|
|
|
| |
Change-Id: Ib5423fdd064e4546f848c0b640b0ed0514c26d3a
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@digia.com>
Reviewed-by: Kai Koehne <kai.koehne@digia.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
Both semantic highlighting and code-completion go hand-in-hand, so now
the ModelManagerSupport class acts as a "factory" for the model manager.
Depending on the mime-type of the document in the editor, the model
manager will return the appropriate highlighter or code-completion
engine. If none is registered, the built-in fall-back is used.
Change-Id: I3e5dbb0e3b58e077dd5eda9aecb2ce5d448ac0b8
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@digia.com>
|
| |
|
|
|
| |
Change-Id: Ic6a9ff0359625021ebc061d22db6811814534205
Reviewed-by: Kai Koehne <kai.koehne@digia.com>
|
| |
|
|
|
| |
Change-Id: Ice592c6de9951ee3b2c4cb52ed0bb3b6770e0825
Reviewed-by: Eike Ziller <eike.ziller@digia.com>
|
| |
|
|
|
| |
Change-Id: I7134d7de30bcf9f9dcfad42520dd45ee083a852d
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
|
| |
|
|
|
| |
Change-Id: I990fdf5411153041c6b4c62f31b453342d59de53
Reviewed-by: Eike Ziller <eike.ziller@nokia.com>
|
|
|
This way the editor does not need to know all the details of
instantiating or maintaining classes for highlighting and/or completion,
it can just ask the model manager. The change also enables different
highlighting- or completion-engines without changes to the cppeditor.
Change-Id: I8000d9d9fe446b292defddb2295493cf77d0f14a
Reviewed-by: Leandro Melo <leandro.melo@nokia.com>
|
