LexErrorlist fixes

[eranif]

I have been using LexErrorList as the lexer for the CodeLite's terminal emulator. I noticed some problems, mainly because the diff styling assumptions are a bit "aggressive": If a line starts with - then it is probably the output of git diff or diff .. command. This is true for many cases, but there are cases where this can be improved a bit.

Two case that I noticed:

• When running ls -l command and the entry does not has the execute permission, then it will start with -
• When running cmake and the output produces CMake's status message (generated by cmake's message(STATUS "something") calls

I have added 4 screenshots, 2 showing the problems before the fix, and 2 after the fix

1. CMake status messages are styled as "DIFF_DELETE"
2. ls -la output lines starting with -r are styled as "DIFF_DELETE"

After the fix:

[nyamatongwe]

This change is likely to reduce the usefulness of diff detection. "-r" will occur when there is a diff that includes changing or deleting lines that start with "r". "-- " occurs with diffs of diffs and diffs for languages that start lines with "-" like Objective C and Erlang. Diff highlighting is very useful to me and I suspect others.

This is part of the problem with context free styling of arbitrary command line sessions. There could be a property to turn off or deprioritize diff detection.

ls tabular output could be detected with high selectivity. Something like: at start exactly 10 of [-drwx], space, ... .

[eranif]

The same could be said about "line staring with ---... but this was still excluded and assumed as a "diff message", whats the difference here?

One could also claim that: ls -l is much more popular than running git diff or just plain diff, no?

ls tabular output could be detected with high selectivity. Something like: at start exactly 10 of [-drwx], space, ... .

The hyphen at the start means that that it is not a directory (d), otherwise the line would have start with d and not with -, i.e. this can happen only for non directory files. The next bit will always be r (if there is a "read" attribute to the file otherwise it will be --).

We could extend the pattern to something more unique than 2 chars, like -r- or -rw