Extending to support languages other than CSS?

[krassowski]

A lot of visualisations are created in languages such as JavaScript, Python, Julia, or R. The visualisation libraries usually just use the same color syntax as CSS, often because they do produce CSS (along some HTML or SVG) in the end.

I would be interested in extending this extension to work in strings in these languages. The recognition of a string as colour would happen only if the string contains a valid color, so "#cccccc" and 'red' would pass but "green" in "I like green apples" would not be detected.

This boils down to the enter function which walks the syntax tree to discover colors:

Codemirror-CSS-color-picker/src/index.ts

Lines 39 to 46 in 3b52d67

	function enter(
	syntaxTree: Tree,
	from: number,
	to: number,
	typeName: string,
	doc: Text,
	): WidgetOptions | Array<WidgetOptions> | null {
	switch (typeName) {

There are two ways I see this could happen:

• (a) the enter function could be modified to accept the strings containing only colour; there is a few typeName in the default CodeMirror modes for "string" depending on the languages, but this is a limited set
• (b) a new callable plugin could be created, allowing the user to pass a custom implementation of the enter() function; in that case I would also like to export the utility functions toFullHex, hslToHex, rgbToHex and namedColors which are used in enter()

Are you interested in reviewing a contribution enabling such usage? Do you prefer option (a) or (b) or do you have a completely different idea?

[sergeichestakov]

Oh interesting. So "green" is a valid CSS value but what you're suggesting is for it to pick up entire strings that contain CSS values (e.g. match on "I like green apples")? Can you give me an example of what that would look like in the wild? Just trying to get a better sense of the use case. I'm not convinced that this should be the default behavior for this library as I think we should stick to official CSS values only since that's the common case, but I can see an argument for allowing for a custom enter fn/implementation.

That would solve your use case but potentially also be generalizable to other cases to (e.g. I can imagine someone may want to support a foreign language for example). wdyt @masad-frost?

[sergeichestakov]

Oh think I slightly misunderstood the question - you're asking to support other languages other than CSS which will require a custom "enter" function since the tree parsing logic will differ. I see that being useful but I wonder if that should just be exported as another extension entirely rather than just a custom fn since the tree parsing is the bulk of the extension anyways and each language will have its own complexities to deal with that we may wish to keep internal.

[krassowski]

I see that being useful but I wonder if that should just be exported as another extension entirely rather than just a custom fn since the tree parsing is the bulk of the extension anyways and each language will have its own complexities to deal with that we may wish to keep internal.

Would something like in the pseudocode below work?

interface IFactoryOptions {
   discoverColors: (syntaxTree, from, to, typeName, doc) => Array<WidgetOptions> | null;
}
export const makeColorPicker = (options: IFactoryOptions) => colorPickerViewPlugin;
export const colorPicker = [makeColorPicker({discoverColors: dicoverColorsInCSS}), colorPickerTheme];

where dicoverColorsInCSS is a new name for today's enter function?