On Aug 27, 2:13 am, "Jean-Philippe Bernardy" <[EMAIL PROTECTED]> wrote:
> True for "quick and dirty" highlighters. The "clever ones" (for now think of > Yi.Mode.Haskell.cleverMode / Yi.Syntax.Paren) add this syntax-level pass. I think these are good. I'm not able to fully understand much of what is done in these files, especially Yi.Mode.Haskell, but I think they're creating an AST. From what I can make out, the cleverMode is mostly doing this for the purpose of "clever" indentation settings and Yi.Sytnax.Paren just creates a structure based on the parentheses. Both are useful, but neither has a concept of something like a "function", from what I can tell. The cleverMode looks is used for indentation, but is it used for syntax highlighting? I think the themes should have more of an idea of the syntax tree of the file, instead of just colorizing a static list of token names. > That's an interesting point of view, but I'm not sure how to achieve such > a level of customization at the moment. For now all languages are required to > use the same theme (which to me is the right thing to do). Ah. Implementation is a whole other story. :) I'm not sure, yet, how to implement this. I was just throwing my vote in the hat for a neat feature, and suggesting how I thought it should work. If I can help to implement it, I will, but I'm certainly not an expert. Of course, I'm not suggesting that this needs to be implemented immediately --- it's a fairly difficult change --- just that it is probably a good design in the end. I agree that all languages should use the same theme (I just put "haskell" in the hierarchy to demonstrate the flexibility to colorize something differently with the same token name in Haskell vs. other languages, for example; ignore that if it makes no sense :D). > I'm still unsure what you want. Is it any of the following? > 1. One should not be required to give definitions for each specific > field in the UIStyle type. Suitable defaults should be inferred for > unspecified values. That, in my opinion, is a good step towards the above suggestion, in which themes define styles for specific elements in a hierarchy (for example, "function > name"). It makes sense to me to draw using defaultStyle first, and then the other styles on top of that. Alternatively, it may be faster to substitute the defaultStyle in for any undefined styles in a theme when it's originally created, so the rest of the code colorizing at runtime can stay the same. I'm not sure which solution is better (or you might have a better one entirely). > 2. Writers of lexers should not be required to assign a style for > each token. "Broad" highlighting should be possible too. Nope, I rather like the way that currently works. > 3. The UIStyle type is too haskell-specific and should provide more > styles, for usage by other languages. Yes; combined with 1. above, UIStyles would be able to provide as much styles as desired, or stay very minimal. I should, for example, be able to write a longString token type for Perl and Python, and then add that to any UIStyle I like; with 1. above, it would not, though, be necessary to modify every single UIStyle. That's good. :) > Oops, blunder... :p Sorry about the confusion. Corey wrote the Perl > one. (maybe?) No worries. :) Sincerely, Jeff Wheeler --~--~---------~--~----~------------~-------~--~----~ Yi development mailing list [email protected] http://groups.google.com/group/yi-devel -~----------~----~----~----~------~----~------~--~---
