Hmm, I am not sure this doesn't regress cases that rely on setDefinition being "cheap" for the nop case.
Is there no other way to trigger re-highlight for the wanted case?

Can't you call rehighlight() yourself after calling setDefinition()?

Btw, tanks for looking into this!

In D25328#563406, @dhaumann wrote:

Can't you call rehighlight() yourself after calling setDefinition()?

Btw, tanks for looking into this!

I have done so in D25323.
But I meant to open this one as well to figure out which way to go, user side fix or lib fix ?
I would favor the lib fix as it seems it might save some users the trouble of adding a workaround because no definition is found just to get highlight like D25323 does.
Kate has such a workaround as well in KateSyntaxHighlight I believe.

Hmm, the use case is that it re-highlights if you set an invalid definition?
Perhaps one should just trigger rehighlight here just for that case, too.

In D25328#563637, @cullmann wrote:

Hmm, the use case is that it re-highlights if you set an invalid definition?

Here it rehighlight if the definition has changed definition() != def.
But since the current definition m_definition has initially the value Definition(), it is the same as the invalid default definition returned by Repository::definitionForFileName (set in RepositoryPrivate::load line 161) and does not call rehighlight.

Perhaps one should just trigger rehighlight here just for that case, too.

So the fix does not really depend on the definition being valid or invalid.

Perhaps there is a better way to fix this.

In D25328#564202, @meven wrote:

In D25328#563637, @cullmann wrote:

Hmm, the use case is that it re-highlights if you set an invalid definition?

Here it rehighlight if the definition has changed definition() != def.
But since the current definition m_definition has initially the value Definition(), it is the same as the invalid default definition returned by Repository::definitionForFileName (set in RepositoryPrivate::load line 161) and does not call rehighlight.

Perhaps one should just trigger rehighlight here just for that case, too.

So the fix does not really depend on the definition being valid or invalid.

Perhaps there is a better way to fix this.

Any thought from a SyntaxHighlighter maintainer ?
I hope I have made the issue clear enough.