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

Low-level API #1493

Closed
be5invis opened this issue Apr 12, 2017 · 5 comments
Closed

Low-level API #1493

be5invis opened this issue Apr 12, 2017 · 5 comments

Comments

@be5invis
Copy link

Currently I am going to write something similar to Andres Löh’s lhs2TeX, which is a tool that analyzes your source code and, layout them in print-level outputs (using proportional fonts and tables to enforce alignment). The output may look like this:

image

However I found there is no way to extract low-level information about the tokens and ranges parsed by HLJS, which makes it impossible to do further layouting (i.e., analyzing alignments and form <table>s to place them).

@ghost
Copy link

ghost commented Jun 21, 2017

Yes, I would definitely be a proponent of this. It would enable me to write a syntax highlighter for the terminal, which is virtually impossible to do so now (the only package I could find was cli-highlight but it does not support all languages). It would be far more elegant if there was a real API for this.

@fcarreiro
Copy link

I had exactly the same thoughts as you guys, for the same reason as @samvv. I was thinking of looking at the code to see what has to be changed to allow for a more low-level API.

Without yet having looked at it i think that, for terminal highlighting, it would probably be enough to have something like an array of (word, identifier); then identifier (variable, keyword, etc) can be mapped to colors with a theme. Later the HTML rendered would put HTML tags around those, and the terminal renderer would output a text decorated with the colors or chalk packages.

What do you think?

Do you think the three of us could make a team effort out of this?

I also wonder if this is something the community would accept to merge, since it's a change in the architecture, even if we make the default usage non-breaking and falling back to HTML.

@ghost
Copy link

ghost commented Jul 15, 2017

@fcarreiro Looks like a good idea. Performance-wise it will be very fast. I'd be definitely willing to help, but I am already quite occupied with a lot of projects so I'm not sure I will be of much use. As for the merging, this would indeed mean severe changes that the maintainers might not be willing to accept.

@fcarreiro
Copy link

Thanks. Maybe we should ping @Sannis (the only maintainer I've seen around) to comment on this?

@joshgoebel
Copy link
Member

Closing this as a duplicate of #1086 which has more discussion in the thread there.

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

No branches or pull requests

3 participants