On 2013-11-15 11:34, Jean-Philippe Bernardy wrote: > On Fri, Nov 15, 2013 at 10:21 AM, Dmitry Ivanov <etherc...@gmail.com> wrote: > [--snip--]
(I'm using C++ as an example here, but you could probably insert "any horribly complicated-to-parse language". Not that there are that many of them other than C++ that are popular enough to matter for this discussion.) > It all depends on the level of detail we want to offer. To get basic > highlighting we can merely use lexical syntax (which is not that hard to > produce). Even this is pretty horrendous for the specific case of C++. For C++ the only really viable option for complete and correct highlighting seems to be to use what an already existing compiler uses to parse. (Parsing C++ is so context-sensitive and complicated that (I believe) the Clang folks actually decided to write a parser by hand instead of using some sort of generator.) >> >> On the other hand, if yi provided an external highlighter API >> (oversimplified one would be just :: String -> IO [(Char, Color)]), user >> would be facing much simpler task of writing a function that would call his >> existing parser and do some conversions. Pygments is just one example of >> such existing parsers. >> > > I have never been fond of this approach because: > 1. Calling external programs is unreliable (having yet another dependency > is already problematic) > Unreliable? > 2. We'll have to deal with asynchronicity. That's opening a new can of > worms. > Indeed, but don't we want highlighting to be asynchronous anyway? Will the performance of the incremental highlighting really be good enough to handle huge files and/or extremely complex languages at a speed that's in the "interactive" time range? There's also the special case of the first time a file is opened to consider. > 3. For Yi to gain any traction it needs "killer" features. Syntax > highlighting could be one of them. In particular I envision an editor which > has full-knowledge of the syntax tree, updated on the fly (and not some > seconds later after some external program has run). Doing the same as any > other editor? "meh". :) Clang is actually usable as an (embeddable) library, so there's really no need to call into an external process. I believe you can also get the full AST if you really want it. Is being available as a dynamic library (or embeddable as a static library) sufficient to make it possible to write a Yi highlighting "adapter" in the new scheme of things? This would of course require FFI, and so would require the IO monad. > That basically condemns Yi to using external highlighters, as there will be > little to no advantage to internal ones. OTOH, it would be prohibitively expensive (time-wise) to implement a C++ highlighter from scratch rather than just using libclang's implementation which is already debugged and working. Cheers, -- -- Yi development mailing list yi-devel@googlegroups.com http://groups.google.com/group/yi-devel --- You received this message because you are subscribed to the Google Groups "yi.devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to yi-devel+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
