> I have never been fond of this approach because: > 1. Calling external programs is unreliable (having yet another dependency is already problematic)
Ideally we would have yi-plugin-clang depending on libclang and yi, not yi depending on libclang. This way users without libclang installed won't suffer. Also, regarding modularization: I see in git history that there was an attempt to extract GUIs into separate packages. Does anyone remember why that didn't work out? On Friday, November 15, 2013 5:34:11 PM UTC+7, Jean-Philippe Bernardy wrote: > > > > > On Fri, Nov 15, 2013 at 10:21 AM, Dmitry Ivanov > <ethe...@gmail.com<javascript:> > > wrote: > >> >> JP, >> >> I'm sorry if my previous post sounded like an accusation, I understand >> that we all have day jobs and other stuff to do and I'm not good at >> expressing tone in English. >> > > No offense taken! I hope I did not give the wrong impression either. > > >> Regarding pygments example: imagine that user has to edit files in some >> non-trivial language and already has a parser for it. The prime example >> would be C++ and libclang. It's extremely cruel to ask user to write C++ >> grammar just to get highlighting. >> > > 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). > > >> >> 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) > > 2. We'll have to deal with asynchronicity. That's opening a new can of > worms. > > 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". :) > > >> What I'm trying to suggest is that new highlighter should exist on the >> same terms as external highlighters and use the same simple API. >> > > That basically condemns Yi to using external highlighters, as there will > be little to no advantage to internal ones. > > I think this comes down to a major design decision: do we want > syntactical/lexical information handled in the editor or externalised? I > still believe that to make Yi interesting it should be internal. However > I'd respect whatever decision the maintainer will make. If necessary Tobias > will do his work in a branch or fork of Yi. > > Cheers, > JP. > > >> >> On Friday, November 15, 2013 3:12:18 PM UTC+7, Jean-Philippe Bernardy >> wrote: >> >>> >>> >>> >>> On Fri, Nov 15, 2013 at 5:28 AM, Dmitry Ivanov <ethe...@gmail.com>wrote: >>> >>>> Hello JP, >>>> >>>> Will this new highlighting scheme also be more modular? >>>> >>> I think the main flaw of the current scheme is not speed, but >>>> maintainability. >>>> >>> It's so deeply integrated into yi that it's very hard to isolate, >>>> understand and test it. It also uses Alex in non-obvious ways and overall >>>> is virtually unmaintainable without you. >>>> >>> >>> It's a bit hard to argue with such general claims. What I can say is >>> that the new system is much simpler than the current one. It is also based >>> on well-documented ideas: >>> >>> http://blog.sigfpe.com/2009/01/fast-incremental-regular-expression.html >>> http://www.cse.chalmers.se/~bernardy/PP.pdf >>> >>> (Plus upcoming Master theses) >>> >>> I also would like a new highlighting scheme to serve as example and >>>> documentation. It would be great if anyone could look at highlighter<->yi >>>> API, understand it in a half hour and build a highlighter backend using >>>> pygments, for example, in a weekend. >>>> >>> >>> I think that I don't really understand this request. >>> >>> As I recall it, even with the current system, making a new highlighter >>> using regular expressions is a matter of hours one an Alex file with >>> regular expressions has been produced. (Just repeat the pattern of existing >>> highlighters). I am not sure why you bring Pygments in the picture: are you >>> really suggesting to call Python from Yi to get highlighting info? >>> >>> A drawback of the current system is that it is quite hard to go beyond >>> regexps: making a parser suitable for detection of syntax (including >>> paretheses) is quite of a black art. This should be solved with the new >>> system: is will accept any grammar in BNF format). >>> >>> >>> Cheers, >>> JP. >>> >>> >>> >>> >>> >>>> On Tuesday, November 12, 2013 3:42:28 PM UTC+7, Jean-Philippe Bernardy >>>> wrote: >>>> >>>>> I have devised a new syntax highlighting scheme. Benefits: much >>>>> faster, and syntax can be derived directly from an existing context-free >>>>> grammar. >>>>> >>>>> Tobias (cc'ed) is interested in integrating it into Yi as part of his >>>>> Master's thesis. >>>>> >>>>> Cheers, >>>>> JP. >>>>> >>>>> >>>>> On Mon, Nov 11, 2013 at 8:24 PM, Marc Weber <marco-...@gmx.de> wrote: >>>>> >>>>>> Feedback about switching off syntax. >>>>>> >>>>>> I'd say you should evaluate a different design: >>>>>> >>>>>> First first render without syntax, wait for the parser to provide >>>>>> syntax >>>>>> & color info, then redraw with highlighting. >>>>>> >>>>>> Marc Weber >>>>>> >>>>>> -- >>>>>> -- >>>>>> Yi development mailing list >>>>>> yi-d...@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+u...@googlegroups.com. >>>>>> >>>>>> For more options, visit https://groups.google.com/groups/opt_out. >>>>>> >>>>> >>>>> -- >>>> -- >>>> Yi development mailing list >>>> yi-d...@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+u...@googlegroups.com. >>>> For more options, visit https://groups.google.com/groups/opt_out. >>>> >>> >>> -- >> -- >> Yi development mailing list >> yi-d...@googlegroups.com <javascript:> >> 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+u...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/groups/opt_out. >> > > -- -- 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.
