SynEdit: pointers in TSynCustomHighlighter.GetTokenKind.

[Edson]

I have been problems executing some code in Ubuntu-64bits, where I read TSynCustomHighlighter.GetTokenKind. I think it's because I use GetTokenKind to return a pointer to an object, but in 64 bits, the pointer cannot be allocated entrely in a integer field.

Is it possible to change de definiiton of TSynCustomHighlighter.GetTokenKind, to be a 64 bit integer?

[Martin_fr]

This would break other peoples code, if they use GetTokenKind in their functions.

Why would you try to return an Object?

The kind is by design an enum. Only because each HL class has its own enum, they get cast to int.

You could always add an extra function to your sub class, and then your code can read this new function?

[tk]

It's been quite a while since I worked with synedit last time but shouldn't you return only an enumeration?

Like in synhighlightercpp.pas, returns ordinal value of TtkTokenKind :

Code: Pascal  [Select][+][-]

1. TtkTokenKind = (tkAsm, tkComment, tkDirective, tkIdentifier, tkKey, tkNull,
2.     tkNumber, tkSpace, tkString, tkSymbol, tkUnknown);

[Edson]

This would break other peoples code, if they use GetTokenKind in their functions.

I think it's easy to cast to a int32, when it's needed. Anyway it's almost always converted to an enum.

Why would you try to return an Object?
The kind is by design an enum. Only because each HL class has its own enum, they get cast to int.

My highlighter SynFacilSyn, doesn't use enumerated., because it can creates token types, dinamically.

You could always add an extra function to your sub class, and then your code can read this new function?

FAIK, there is some routines in SynEdit, like Markups, that use GetTokenKind.

[Martin_fr]

I think it's easy to cast to a int32, when it's needed. Anyway it's almost always converted to an enum.

Others still need to fix their code.

My highlighter SynFacilSyn, doesn't use enumerated., because it can creates token types, dinamically.

You could use a counter, and each object can have a unique number. Or indexOf, if they are in a list (storing the index on the object will be faster).

The numbers should be generated in a way that will give the same results on each run.
That is the token kind for e.g. "procedure" should always have the same number. (casting object to int64 does not do this).

If not then code like saving and restoring folded nodes (if you close the editor, and the editor stores current folds in a session info), will not work, because it stores the token kind (IIRC)

IIRC, foldconfig (and other conf on this) is also based an fixed (and also on continuous) integers.

FAIK, there is some routines in SynEdit, like Markups, that use GetTokenKind.

There are lots of them. And they all expect int.

And foldconfig uses it as an index.

(All written from memory / but hopefully  correct)

[Edson]

I don't wan to change the

There are lots of them. And they all expect int.

That's why I can't create mi own function to return the token kind.

I don't pretend to make a big change, just increase the size of the integer returned by GetTokenKind. It will still be an integer.

I have been always working with references in GetTokenKind. and haven't had problems. I thing there will be a solution to manage FoldConfig.

You could use a counter, and each object can have a unique number. Or indexOf, if they are in a list (storing the index on the object will be faster).

This will change, considerably, the code. Making incompatible the new versions with the olds, and will affect the performance of the highlighter.

[Martin_fr]

I have been always working with references in GetTokenKind. and haven't had problems. I thing there will be a solution to manage FoldConfig.

Well yes most parts do not care. So they will work.

Try saving the FoldState, and restoring it.

You could use a counter, and each object can have a unique number. Or indexOf, if they are in a list (storing the index on the object will be faster).

This will change, considerably, the code. Making incompatible the new versions with the olds, and will affect the performance of the highlighter.

It should just be just a change to the constructor. Increase counter, and copy its value.

As for the counter, if you can pas a reference to the HL then have the counter on the HL, so objects in each HL get there own counting. If not, use a global var. (of course it can wrap over, if you have really lots of hl......

in getTokenKind: ord(obj) changes to obj.FValueInitializeFromCounter

But I do not know your code.