Oh wait, its the "every file can see every other files symbols even if they are not used" problem isn't it

Yes.

I think this should actually be configurable because the colorization of types is kind of random based on what files you have open (unless you let the tag manager index all project files plus all the dependency files).

It also has a non-zero performance cost because Scintilla goes through the supplied keywords one by one for every word in the document to check whether the word should be colorized. I remember submitting a patch to Scintilla so it at least uses binary search to check whether the word is in the keyword list but Neil wanted to have this optimized for smaller number of keywords where the linear search won so the patch wasn't accepted.

so its the number of open C/C++ files * all C/C++ symbols size

Not all symbols size but only those which define types. And only their names concatenated together into a single string.

Sigh, ok, I guess the wrong way might have to do, and any clashes will be guaranteed to be "unable to reproduce" :-)

Yeah, exactly, that's the approach. Users are just wrong ;-).

PS I don't think the problem is anything to do with Scintilla 5, its just that its the first time anyone noticed, after all who would change filetypes from C to C++?

It is. I tried previous versions and it worked. The problem is now more visible with the new ProjectOrganizer feature that automatically sets header's filetype based on the source file (e.g. for my_header.h and my_source.c in the project it sets C as the header's filetype from the original C++ filetype).

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.