You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hoist the various kinds of mark widgets (lines, token, gutter) to an evented model. Allow for separate owners by organizing sets of marks as layers.
Motivation
Our current design assumes that one agent (usually our diagnostic feature) controls all the marks on an editor instance. At the end of the day, the implementation would still need to do the same work to ensure that marks are up-to-date, but if we want to support multiple sources of information (#184) without going crazy, we're going to need a better way to organize them.
Design Ideas
CodeEditor
IMarksModel
layers: IMarkLayer[]
title
description
rank
IMark[]
LineMark
TokenMark
GutterMark
With this, we could also offer UI (notionally as a sidebar) for hiding/reordering the mark layers.
Presumably, this could be hoisted to Lab core's CodeEditor... or better still a JEP-level definition of "what is a text editor", with a full JSON Schema model of all of these pieces, such that this could be integrated into a terminal-based editing experience (e.g. ipython) and would be better describable by assistive technologies.
The text was updated successfully, but these errors were encountered:
Looking forward, much of this is supported by the CodeMirror 6 DecorationSet.
Another happy thing I saw was the legacy-modes repo, which should provide not only many of the modes needed to get up to feature parity, but also the blueprint for porting other novel modes.
It'll be a haul, and CM6 is still in beta, and is not going to support LSP directly, but the architecture looks a lot more like something we can build on without having to get fancy. We'll lose direct control via CSS of basically everything, but I think given what we've learned on this project, the path to supporting mobile, screen readers, and LSP features are all pointing at CM6 as the right path forward.
Elevator Pitch
Hoist the various kinds of mark widgets (lines, token, gutter) to an evented model. Allow for separate owners by organizing sets of marks as layers.
Motivation
Our current design assumes that one agent (usually our diagnostic feature) controls all the marks on an editor instance. At the end of the day, the implementation would still need to do the same work to ensure that marks are up-to-date, but if we want to support multiple sources of information (#184) without going crazy, we're going to need a better way to organize them.
Design Ideas
CodeEditor
IMarksModel
IMarkLayer[]
title
description
rank
IMark[]
LineMark
TokenMark
GutterMark
With this, we could also offer UI (notionally as a sidebar) for hiding/reordering the mark layers.
Presumably, this could be hoisted to Lab core's
CodeEditor
... or better still a JEP-level definition of "what is a text editor", with a full JSON Schema model of all of these pieces, such that this could be integrated into a terminal-based editing experience (e.g.ipython
) and would be better describable by assistive technologies.The text was updated successfully, but these errors were encountered: