SynCustomHighlighter: how to know what editor I'm processing

[Henppy]

Hello, yes it's me again... sorry, but I couldn't find anything about this problem.

How do I know, inside a TSynCustomHighlighter, what is the TSynEdit that I'm parsing at any given time, say in the Next or SetLine methods?

Under normal circumstances I assign the TSynEdit.Highlighter property to a highlighter and that's it, if I have more than one TSynEdit editor component I assign the same instance of the same highlighter to all of them, and it seems to work with no problems, I don't know why, but it works.

But now, I have my custom highlighter that does some things besides coloring, and I need to know somehow what TSynEdit components owns the lines I'm parsing on the Next; method.

I looked at the TSynEdit and SynCustomHighlighter source code trying to see what could be done but I got lost with that "hooks" thingy, too advanced for my knowledge right now.

Any ideas?

I guess I could just create a new instance of a custom highlighter per editor, but I'd like to avoid that for memory usage reasons.

Thanks for the time.

[Martin_fr]

There is a property

Code: [Select]

CurrentLines: TSynEditStringsBase
It is the textbuffer. So you can access lines from the text.

There is no guaranteed way to the SynEdit (and it may be more than one SynEdit)

Currently CurrentLines are of the class TSynEditStringList
Which is the actual textbuffer, and has a

Code: [Select]

    function  AttachedSynEditCount: Integer;
    property  AttachedSynEdits[Index: Integer]: TSynEditBase read GetAttachedSynEdits;

As I said, with 2 or more SynEdits editing the same text, there is more than one SynEdit. But each SynEdit may have a different Highlighter (or have the same), so you would need to search all of them, until you find the one that uses this HL.


Further more: If (for example) you are using a TSynMultySyn, and one of the sub-HL is of your type, then CurrentLines, if of a  different class, and no link to the SynEdit exists.

And the above is not guaranteed. In future CurrentLine can point to other classes, even in normal cases.

------------------------
I guess you want to get your markup? and pass on the error locations?

The correct way, is for the HL to store them, and the Markup (which knows the edit and the HL) to query them.

TIP: if you need per SynEdit space to store: inherit a new class for the Range. The range is stored on the textbuffer, so if you use the HL from multiple edits, there are different instances of the range.


CurrentLines can be used, if you need to peek at the next or previous line fo text. that it will always do, even in future.

[Henppy]

hmmm...

Here's what I'm trying to achieve: when the highlighter is scanning through the code to get the tokens and color them, it is also generating a list of tokens. This list is a class that I wrote to hold all the tokens for further analysis like syntax, semantics, detect declared user variables and perform so other tasks.

Obviously, there's one list per SynEdit editor as it would be, in theory, a logic representation of the code in it.

Now that I think about it, I'll have to do something similar for the markups, so maybe I'll have a highlighter and markups per editor. Is that too much resource intensive? I don't have enough experience with SynEdit, but it looks quite fast and "compact".

[Martin_fr]

Normal SynEdit has many markups. In the IDE, there are around 10 per Edit.

Some of the markup, and other code also does additional calls ta the HL, scanning lines (usually the visible lines) and receive extra results.

One way, is to have a flag (1 bit) in the "range", that indicates, if there is an error in that line. (or starting in that line, continuing in the next.) Then you only scan error lines again.

If you rather maintain a global list of all erro positions (as you nom neem to detect them in the scan), then you can do that.
- Create that list (an object).
- The markup has a method that is called if the HL changes. (see base class)
  Give a reference to the list-object to the HL (or even a ref to the markup
- The HL can store that on the ranges (CurrentRanges) object (needs to subclass)

This works, if you do ont use "shared" synedit (2 edits, one text)


--
Edit:
overwrite
    function GetRangeClass: TSynCustomHighlighterRangeClass; virtual;

to have your own range class, with extra storage, if you want to do that.