text editor

[oliver-sanders]

Edit 2023:

This issue has moved on as full editor capability is no longer required. We now only require a file "viewer", see https://github.com/cylc/cylc-ui/issues/144#issuecomment-1505175390 for more details.

The Cylc UI will need a text editor (readonly) for:

Cylc7 Functionality:

• ~Trigger edit-run~ (likely to use an auto-generated form)
• Viewing suite.rc definition
• Viewing suite log files
• Viewing job log files (cylc cat-log)
• Viewing job log files (cylc review)
  • Supports file search.
  • Supports linkable line numbers (really important).
  • Supports some syntax highlighting (e.g. [INFO]).
  • Supports HTML and raw views.

Potential future functionality:

• Editing suite.rc definition / cylc reload
• Editing suite.rc definition / cylc broadcast
• ...

We want an in-browser text editor which:

So here's our shopping list:

1) Syntax highlighting via TextMate grammar.

• Avoids us writing suite.rc grammar just for this editor. 2) Ability to display file "streams" (readonly).
• e.g. job stdout file lines should appear as they are written like in the Cylc7 GUI. 3) Linkable line numbers. 4) Ability to work with large files without falling over.
• We get some pretty huge job output files sometimes, Cylc Review struggles with this.
• Something which can adaptively load text files in chunks would be perfect.

Additional bonus marks for an editor which:

a) Has auto-completion (e.g. for task names). b) ~Has tabbing with lazy load (e.g. open job.* files).~ we will likely rely on lumino for this c) Can elegantly display diffs (e.g. cylc diff). d) Regex search.

[kinow]

Hopefully this one we should be able to find a component that does most of what we need, then just use it with none/little customization.

[wxtim]

Investigation:

Editor	TextMate Grammars	Display File Streams	Linkable Lines	Large File Handling	Auto Completion	Diffs	RE Search
Ace	Yes		No (would have to implement ourselves)			Yes (syntax highlight)	Yes
CodeMirror	No (needs 3rd party package)		No (would have to implement ourselves)			Yes (syntax highlight)	Yes
Monaco	No (needs 3rd party package)		No (would have to implement ourselves)			Yes (rich)	Yes
Prism.js (read-only)	No		Yes (plugin)		N/A	Yes (syntax highlight)	No?

[oliver-sanders]

Jupyterlab uses codemirror, I found this package which converts textmate grammars for codemirror editors, it's pretty small though :(

[hjoliver]

What do you mean by "small" there?

[oliver-sanders]

0-4 weekly downloads, 11 stars.

[oliver-sanders]

Update: trigger edit may use an auto-generated form which reduces the requirements as we no longer require an editor, only a viewer.

[MetRonnie]

Monaco:

• Supports read-only
• Doesn't support TextMate grammars on its own. There is https://github.com/bolinfest/monaco-tm in order to make it support them (it apparently uses WebAssembly to do so).
• Doesn't support linkable line numbers. However I don't think it would be too difficult to implement that ourselves.

[oliver-sanders]

Monaco might be a bit heavy weight for us

Unpacked Size 79.5 MB --- https://www.npmjs.com/package/monaco-editor

[kinow]

I think the editor can be lazy-loaded (i.e. loaded only when used in the UI), and it should also be possible to tree-shake it, loading only what's actually used in the Cylc UI code (some times it works, some times it doesn't — e.g. I never got Vuetify to unload some modules I was sure it was not using, and I think other users reported a similar issue…).

IIRC, the… vue ui? vue inspect? That utility that displays the bundled web application to inspect the Vue app settings… it has a reporting tool to show the size of the artefacts generated, including imported libraries. So someone can import monaco editor (important to import like import { moduleA } from "monaco" or so, to hint to webpack/etc what's actually used :+1:, instead of import "monaco" or import * from monaco as bla", etc)

[kinow]

(or there are other smaller editors if the UI doesn't need a lot of features in the text editor, like Ace editor for instance - https://ace.c9.io/)

[oliver-sanders]

Ace looks pretty good and supports TextMate grammars which is a big win.

Given that we don't need editor functionality we might be better off going with a more light-weight display-only tool for simplicity.

[oliver-sanders]

VitePress uses Shikijs which supports TextMate as well as VSCode colour themes:

https://github.com/shikijs/shiki

[oliver-sanders]

The monaco editor, whilst 85mb in size can be chunked. There is also a vite plugin: https://www.npmjs.com/package/vite-plugin-monaco-editor

One barrier would be that monaco integrates with webkit, but not rollup as it does not support ESM modules, this could interfere with chunking? Would need to try.

[oliver-sanders]

Our requirements are now fairly simplistic (we don't need an editor any more), we could get by with just a syntax highlighter.

I think the main items on the shopping list are:

• Dynamic documents (log files aren't static, they can grow).
• Syntax highlighting (w/ support for TextMate grammars AND dynamic documents [1]).
• Line numbers (with the potential to make them linkable somehow).
• Word wrapping (ideally toggleable).
• Search (ideally plain text and regex).
• Follow (the ability to follow the end of a growing file).

With bonus marks for:

• Large file support or file pagination!
• Diffs.

[1] The TextMate grammar approach does NOT support incremental lexing, so handing a dynamic document involves rendering and re-rendering the same code block over and over. This will need to be handled in an efficient way, and ideally one which doesn't delete the whole component and re-create it from scratch as that would create continuity issues for the user. Note, some systems use WASM code for this which should be a performance win.