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

Nestable highlighters #295

Open
ethercrow opened this issue Nov 19, 2012 · 3 comments
Open

Nestable highlighters #295

ethercrow opened this issue Nov 19, 2012 · 3 comments

Comments

@ethercrow
Copy link
Member

Original author: [email protected] (March 16, 2009 14:56:52)

Example of usage:

  • Haddock markup in haskell comments
  • Literate Haskell should just be some composition of Haskell and LaTeX
  • String literals could be better highlighted (escaping characters) if it
    were a sub-lexer.
  • Quasiquotations one day we should be able to nicely display using a
    customizable way things [$sql| SELECT * FROM people |] or
    [$regex|(a|[bc])|] or [$html| <b>Boo</b> |]...

Original issue: http://code.google.com/p/yi-editor/issues/detail?id=252

@ethercrow
Copy link
Member Author

From [email protected] on March 16, 2009 16:03:00

  • Quasiquotations one day we should be able to nicely display using a
    customizable way things [$sql| SELECT * FROM people |] or
    [$regex|(a|[bc])|] or [$html| Boo |]...

I don't really follow this example. Are you trying to give an example of a Haskell
source file which Yi would highlight as Haskell, but within particular fragments (as
specified by the Haskell parser), yi would highlight as a different language?

@ethercrow
Copy link
Member Author

From [email protected] on March 23, 2009 11:55:11
@gwern0
exactly

@noughtmare
Copy link
Member

noughtmare commented Mar 6, 2017

I was just reading "Combinator Parsing: A Short Tutorial" by Doaitse Swierstra and found this:

Usually one is satisfied to have just a single way of scanning the
input, but sometimes one may want to use a parser for one language as sub-
parser in the parser for another language. An example of this is when one has a
Haskell parser and wants to recognise a String value. Of course one could offload
the recognition of string values to the tokeniser, but wouldn’t it be nice if we
could just call the parser for strings as a sub-parser, which uses single characters
as its token type? A second example arises when one extend a language like
Java with a sub-language like AspectJ, which again has Java as a sub-language.
Normally this creates all kind of problems with the scanning process, but if we
are able to switch from scanner type, many problems disappear.

I am now trying to understand the parsers mentioned in that paper and adapting them to make them work with Yi.

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

No branches or pull requests

2 participants