[texworks] Improving Syntax Highlighting

[Stefan Löffler]

Hi,

On 2012-05-06 12:50, Chris Jefferson wrote:
> I am planning on having a look at the syntax highlighting code. I
> thought I would see if anyone was currently working on this, or if
> anyone had any major suggestions.

that sounds great, thanks.

> Having had a look at the code, here are my initial thoughts:
>
> The current system uses QSyntaxHighlighter. It seems very silly to
> consider switching to anything else.

I agree. However, I'd like to have some kind of abstract interface in
the long run (see
http://code.google.com/p/texworks/wiki/IdeasAndProjects#Syntax_highlighting_module).
So QSyntaxHighlighter should obviously be used internally, but for the
rest of the program (e.g., for defining syntax highlighting rules),
these internals should be hidden as much as possible (this would also
allow migration to a different highlighting engine, should such a need
arise in the future). I don't know how much time you have to spare for
this project, and how much experience you have with C++, though. So any
improvements to the existing code are very welcome. I just thought I
point out (my) long-term vision.

> This implies a number of limitations. The big one is no multi-line
> user regular expressions, sorry. Specific multi-line things can be
> custom written in C++ obviously.
>
> The things I would most like, in order of preference, are:
>
> 1) Matching of maths ( both $ $ and \( \) ).
> 2) Ability to highlight specific \begin{x} ... \end{x} sections.
> 3) Highlighting of parts of regular expressions (for example, in
> \textbf{XYZ}, make the XYZ bold).

What would be nice here would be some form of delimiter matching. E.g.,
correctly match something like \section{A {B} C}. This doesn't work with
reg-exps alone, but I recently found that Gtk-source-view
(http://projects.gnome.org/gtksourceview/documentation.html) can do it.
As I understand it, it includes the possibility to give two regular
expressions: one for the beginning, and one for the end of the
to-be-matched string. Since I guess something like that will be needed
for \begin/\end section matching anyway, I thought I'd mention this.
To that end, I guess we should think about supporting some more
sophisticated configuration files in the long run (e.g., XML based).

>
> Also, I would like to make the code slightly easier to chain engines
> together, under the restriction that the code still "looks like" and
> understands QSyntaxHighlighter objects. It doesn't seem work wrapping
> the library in another set of functions, which basically do exactly
> the same thing.

Chaining is certainly a good idea. However, the question is if it
wouldn't be easier to have a single highlighter object (per editor
widget) that supports setting chains of highlighting configurations. I
imagine that different such configurations could possibly interfere with
one another, which could best be handled in a single object. But that's
all idle musing from my side...

HTH
Stefan