Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hoist CodeMirror Mark Widgets to a Layer-based model #500

Open
bollwyvl opened this issue Feb 1, 2021 · 1 comment
Open

Hoist CodeMirror Mark Widgets to a Layer-based model #500

bollwyvl opened this issue Feb 1, 2021 · 1 comment

Comments

@bollwyvl
Copy link
Collaborator

bollwyvl commented Feb 1, 2021

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
      • 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.

@bollwyvl
Copy link
Collaborator Author

bollwyvl commented Feb 7, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant