On Jun 14, 10:29 am, "Edward K. Ream" <[email protected]> wrote:
> Let's repeat the fundamental problem: Given *only* the starting state > of a line and the line itself, we want to indicate 1) which characters > of the line are to be colored and 2) what the ending state of the line > is. I believe this is actually a straightforward task. We revise all the jeditColorizer pattern matchers so that 1. They never cross a line boundary. Indeed, there is nothing past the line anyway! Note that all "plain" matchers will assume that they are called in the "plain" state. As we shall see soon, **restarters** are jEdit matchers that assume they start in a "non-plain" state. 2. If a plain matcher fully matches at or before the start of the line, the matcher will return success, namely a tuple:: i,j,None i and j indicate the range of characters to be colored (relative to the start of the line!). None is an indication that a) there is no restarter needed and b) that the state at location j of the line is the plain state. 3. if a plain matcher might potentially match past the end of the line, it will return:: i,len(line),new-state Here, new-state is an int representing both a QSyntaxHighlighter state *and* a restarter method. 4. Here is the interesting part. The jEdit matchers will *create* restarter methods based on the arguments that were passed to them. They will cache these methods in a global restarterDict, and states will be keys to this dict. Restarters are essentially lambda bindings of the arguments to the actual jeditColorizer pattern matchers. They become, in essence, new pattern matchers. Whether they will share the same code as the plain pattern matchers remains to be seen, but that does not matter. We can, indeed, associate ints with restarters. To repeat, the ints are keys to restarterDict. The values will be a tuple of information sufficient to determine whether a restarter already exists in the dict. Something like the pattern matcher itself and a list of arguments needed by the restarter. BTW, we might bind a **pattern name** as an arg. This would have been good to do earlier. We would simply have the script that creates the modes/x.py files include a patternName argument to the pattern matchers. That would make debugging considerably simpler. The restarters have to know how to complete there pattern **starting in a non-plain state**. I believe this will be straightforward. Let's consider an example. Suppose we are in the middle of a python triple-quote string. The pattern matcher knows what string started the match, either ''' or """. Thus, the matcher can be told what *ending* string to look for. It's really quite simple. Note that this information is intrinsically part of the lambda bindings mentioned above--it's contained in the arguments to the plain pattern matcher. In short: 1. Plain pattern matchers can easily define restarters. 2. It is straightforward to associate restarters with integer states. Crucially, this scheme is "bounded". It can not suffer a combinatorial explosion of restarters. Indeed, most pattern matchers will create only one or two possible restarters. For example, the plain matchers associated with triple-quoted strings will create at most two restarters: one that looks for ''' characters and one that looks for """ characters. In practice, I expect all other pattern matchers will (for any given language) generate only just a few restarters. This scheme is "bounded" in another sense. It will be straightforward to write the code that creates the restarters. An inner "def" will do. This def *is* the lambda binding. So it appears that a straightforward, testable, approach is indeed feasible. This would eliminate an almost all the confusion in the present code. Edward --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~----------~----~----~----~------~----~------~--~---
