Code reuse could be called the holy grail of programming. The evidence suggests it will never happen, and for perfectly plausible reasons.
Instead, we could hope for *design* reuse. Still, in the spirit of "lightening everything" it's at least amusing to consider the question. Let's take a concrete example as the base of speculation. Leo does a great job (if I do say so myself) at interfacing with QSyntaxHighlighter. It's tricky, as described in the Post Script. Otoh, pygments does a great job of describing, in perhaps the simplest way possible, how to tokenize and scan lots of modern-day languages. So here we have a typical situation: two excellent code bases, each of which does something related to the other. Could we merge the best parts of each? Yes. All it will take is blood sweat and code :-) In this case, however, we may get a bit lucky: all pygments pattern matchers are regex matchers, so perhaps a single, generic, restarter would be needed. Edward P.S. The aha behind the line-oriented jEdit colorizer is that we can define one or more *restarter* methods for each pattern matcher that could possibly match across line boundaries. I say "one or more" because we need a separate restarter method for all combinations of arguments that can be passed to the jEdit pattern matchers. In effect, these restarters are lambda bindings for the generic restarter methods. In actuality, very few restarters are needed. For example, for Python, we need restarters for continued strings, and both flavors of continued triple-quoted strings. For python, these turn out to be three separate lambda bindings for restart_match_span. When a jEdit pattern matcher partially succeeds, it creates the lambda binding for its restarter and calls setRestart to set the ending state of the present line to an integer representing the bound restarter. setRestart calls computeState to create a *string* representing the lambda binding of the restarter. setRestart then calls stateNameToStateNumber to convert that string to an integer state number that then gets passed to Qt's setCurrentBlockState. The string is useful for debugging; Qt only uses the corresponding number. EKR -- 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.
