feat: add APIs, commands and tests for syntax-highlighting in the REPL

[Snehil-Shah]

Description

What is the purpose of this pull request?

This pull request:

- Adds the following REPL commands:

• theme([name]) - Set theme or list current and available themes

• addTheme(name,colors) - add user-defined theme

• deleteTheme(name) - delete a theme

• defaultTheme([name]) - Set/get the default theme

• getTheme([name]) - Get the JSON of the current or a specified theme

- Adds API methods to the REPL instance (like repl.setTheme() etc.) - to programmatically control the syntax-highlighter.

- Adds setting to disable/enable the syntax highlighter

- Add options to load themes and set default theme upon REPL startup

- Fixes failing tests

TODO:

• Tests
• more built-in themes
• document the new API methods

Related Issues

Does this pull request have any related issues?

This pull request:

• is a follow up to feat: add syntax highlighting in the REPL #2254

Questions

Any questions for reviewers of this pull request?

• I have added a long list of API methods to the REPL instance, is that okay or a bit of an overkill?
• I have combined a couple of operations when writing REPL commands as it was getting crowded.
  Like the theme command both prints the current and available themes when no argument is provided and sets the theme when an argument is provided.
  
  Similarly with defaultTheme. Is that okay?

Other

Any other information relevant to this pull request? This may include screenshots, references, and/or implementation notes.

No.

Checklist

Please ensure the following tasks are completed before submitting this pull request.

• Read, understood, and followed the contributing guidelines.

---

@stdlib-js/reviewers

[kgryte]

@Snehil-Shah Another possibility for a couple of the commands which should have corresponding settings:

# Set the default theme:
> settings( 'defaultTheme', 'foo' )

# Set the current theme:
> settings( 'theme', 'foo' )

and then

# Add a theme:
> addTheme( 'bar', {...} );

# Remove a theme: (similar to existing `deleteWorkspace` command)
> deleteTheme( 'bar' );

# List themes: (similar to existing `workspaces()` command)
> themes()
'monaco', 'foo'

# Return the current theme: (similar to existing `currentWorkspace` variable)
> currentTheme

# Rename a theme: (similar to existing `renameWorkspace()` command)
> renameTheme( 'foo', 'beep' );

# Check whether a theme exists: (similar to existing `isWorkspace()` command)
> isTheme( 'beep' )
true

In short, I'd favor consistency with conventions that we already have in terms of naming and the set of workspaces commands is the closest match.

For REPL prototype methods, I think we may be able to combine separate get/set methods into single methods (e.g., defaultTheme( [name] )).

[Snehil-Shah]

@kgryte I don't think we would need a currentTheme if we are going to have a setting for the current theme, as settings already allows us to get the current value of a setting. And what about getThemeConfig?

[kgryte]

Re: currentTheme. Right. Makes sense: settings( 'theme' ) would return the current theme.

Re: getThemeConfig. If you are thinking a command, maybe since addTheme( name, config ), it would be more consistent to have the command name be getTheme( name ) and return a config object. Meaning, getThemeConfig => getTheme. I believe this is what you originally proposed. Or maybe we should just consolidate here and do theme( name[, config] ), where theme( name ) returns a config object and theme( name, config ) adds a theme. This would be slightly different than what you originally proposed.

If you are thinking the prototype method, maybe we should do theme( name[, config] ), which is a get/set method. where the set behavior adds a theme. Then, to programmatically enable the newly added theme, REPL#settings( 'theme', 'foo' ).

[Snehil-Shah]

@kgryte I think having theme command for both getting the config and adding a new theme can be confusing. theme command can be easily confused to something like changing the current theme etc. I feel it's better to be explicit and have two commands addTheme and getTheme both as a command and as REPL prototype methods. What do you think?

[kgryte]

Currently, the main precedent for get/set APIs is settings( [name[, value]] ). It doesn't look like we have other similar commands atm. And we don't have other similar prototype methods.

Looking through the codecase, we don't have many instances of public classes. The closest one which has getters/setters is @stdlib/plot/ctor, but the needs are slightly different there.

While overloaded getter/setter APIs is a fairly common design pattern, I'm also okay with separate commands: getTheme and addTheme.

[Snehil-Shah]

Updated Signatures

- REPL commands

• themes() - List available themes
• addTheme(name,value) - Add user-defined theme
• deleteTheme(name) - Delete a theme
• renameTheme(old,new) - Rename a theme
• getTheme([name]) - Get JSON config of the current or a specified theme
• settings('theme') - Set/get current theme
• settings('defaultTheme') - Set/get default theme

- Prototype methods

• REPL#themes() - Get all themes
• REPL#getTheme(name) - Get a specified theme's JSON config
• REPL#addTheme(name,value) - Add a theme
• REPL#renameTheme(old,new) - Rename a theme
• REPL#deleteTheme(name) - Delete a theme
• REPL#settings('theme') - Set/get current theme
• REPL#settings('defaultTheme') - Set/get default theme

[Snehil-Shah]

Did some changes and fixed some bugs that I encountered while writing the tests as explained in the commit descriptions.

[Snehil-Shah]

I will add more built-in themes in another small PR once this is merged, or should I push it in this PR itself? Also, I was thinking if we should keep the name of the default in-built theme (currently 'default') to something less boring. How about something like 'stdlib'?

[kgryte]

@Snehil-Shah Yes, I'd suggest renaming the default theme to something else (e.g., stdlib-light, as the current theme is better on light backgrounds and is not great on black terminal backgrounds). And for any built-in stdlib themes which don't have well-known names (e.g., monaco, etc), we can use the "stdlib-" naming convention.

[kgryte]

@Snehil-Shah I suggest adding additional themes in one or more follow-up PRs.

[kgryte]

@Snehil-Shah Looks like just a couple of small things remain to get this PR over the finish line. Namely, some docs need updating, some small refactoring, and a question on printed confirmation messages.

[kgryte]

Okay. I think this is ready to merge. Any further updates can be made in follow-up PRs. Thanks, @Snehil-Shah!