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

Add support for registerAlias similar to registerLanguage #2523

Closed
wooorm opened this issue May 2, 2020 · 6 comments
Closed

Add support for registerAlias similar to registerLanguage #2523

wooorm opened this issue May 2, 2020 · 6 comments
Labels
enhancement An enhancement or new feature

Comments

@wooorm
Copy link

wooorm commented May 2, 2020

Is your request related to a specific problem you're having?

Aliases are useful for example to support GitHub’s names, and map them to highlightjs names.

The solution you'd prefer / feature you'd like to see added...

Such as like so: https://github.com/wooorm/lowlight#lowregisteraliasname-alias, but anything that allows mapping a new label to an (existing) language name.

Any alternative solutions you considered...

There is no access to languages or aliases, so it’s not possible to do this in userland.

Additional context...

n/a

@joshgoebel
Copy link
Member

joshgoebel commented May 2, 2020

FYI: You can do this now by just getting a languages raw interface and re-registering the language (which will update it's aliases).

I'm not opposed to a simple registerAlias method though:

registerAlias(languageName, alias|list)

Though I wonder if addAlias is better named?

I don't think the second form that you support is necessary at all since it seems an edge case and easy enough to write a loop. And if we added this we'd of course need to add docs for it.

Want to make a PR?

@wooorm
Copy link
Author

wooorm commented May 3, 2020

The reason for registerAlias as opposed to something else is that it aligns with registerLanguage, but I don’t feel strongly about that.

The reason for the other option is so that a module could expose that mapping between highlightjs names and GH aliases as an object, which could be required and then directly passed.

@joshgoebel
Copy link
Member

joshgoebel commented May 3, 2020

I don't love register* but as you say at least it's consistent. :-)

Sure, but you can write 2 lines of code to use forEach to do the same thing... :-) I just think the core library should provide simple APIs and integrators build on top of those. Your library can support the more complex version if you think that's best, and then loop and hook into our simple one-at-a-time method.

@joshgoebel
Copy link
Member

@wooorm You willing to whip up a PR for this one?

@wooorm
Copy link
Author

wooorm commented May 7, 2020

I’m a bit swamped at the moment; if @taufik-nurrohman is interested, I would be grateful!

@joshgoebel
Copy link
Member

Closing as resolved by #2540

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement An enhancement or new feature
Projects
None yet
Development

No branches or pull requests

2 participants