On Mon, Nov 18, 2013 at 9:38 PM, Dmitry Ivanov <etherc...@gmail.com> wrote:
> > > 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? > IIRC the tooling around cabal made this difficult. Not impossible, but just difficult. To do reasonable development work multiple cabal installs were required. Which was a bit annoying. I'd like to see the core of Yi use Cabal as a library and automate much of this. EG: Define a Yi instance as the core yi package plus several add-on packages. When yi is reloaded instead of a "ghc --make" Yi performs the same steps as cabal + sandboxes with all the add-on packages. Even without the idea of add-on packages: I think Yi needs to use cabal as a library. Using "ghc --make" creates the possibility that reloading yi will use an incompatible set of packages. Somebody who has successfully "installed" yi would be unable to use yi. EG: Suppose yi depended on a package A < 2 but the user had A == 3 installed. If the other packages Yi depends on are also satisfied by A == 3 then "ghc --make" will attempt to use A == 3. Correct me if I'm wrong, but I suspect that is the case. Cheers, Corey > > 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>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 >>> 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-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. > -- -- 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.
