On Fri, Nov 15, 2013 at 1:01 PM, Bardur Arantsson <[email protected]>wrote:
> On 2013-11-15 11:34, Jean-Philippe Bernardy wrote: > > On Fri, Nov 15, 2013 at 10:21 AM, Dmitry Ivanov <[email protected]> > 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++. Isn't this what Emacs and Vim do? > >> > >> 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? > You need to make sure that the dependencies are installed on the user's computer, and so in a specific way that is callable by Yi. Not as trivial as one might think given that multiple OSes should be supported, etc. > > > 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? Current experiments give a millisecond response time on 10000-line long C program. > There's also the special case of the > first time a file is opened to consider. > Some options have been put forward earlier; e.g. parsing only the 1st 10000 lines when opening the file. > > > 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. > There is a non-trivial amount of work to lift the API to Haskell, I would imagine... And even more so if full access to the AST is desired. > > 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. > This matters only if somebody is willing to invest time in implementing either of those options. Cheers, -- JP > > Cheers, > > -- > -- > Yi development mailing list > [email protected] > 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 [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > -- -- Yi development mailing list [email protected] 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
