Agreed. But here's the thing: every single file that is loaded needs to be:
- Loaded from disk (slow)
- Malloc a C string for whole document
- Copied into scintilla buffer
- Freed whole document string
- Completely lexed by Scintilla lexer (blocking for huge docs)
- Grabbing the raw char* of the buffer from Scintilla.
- ** Does it take a whole other copy here? **
- Passing through CTags and TM (blocking for huge docs).
- Updating the user CTags into Scintilla keywords. (SCI_SETKEYWORDS
with Ctags results) 8) Updating the Symbols tree view with new parsed tags. 9) Focusing the GTK+ notebook page 10) Setting caret pos to 0 which should be the natural position of the caret but who knows what magic Scintilla does when moving caret.
At present, most of these steps can't be delayed, they all kind of depend on the others due to Geany assuming a single thread on a single core and sharing a bunch of the loaded data globally between modules.
I'm talking about bulk file loading. Loading single file is fast enough, it slow when you "Focusing the GTK+ notebook page" for EACH file even if it will not be ever shown (because there are more files in queue).
If you have a single project with 10M files, surely you are doing something wrong :)
Google in Chromium project definitely does something wrong?:)
Indeed we would encourage any contributions here, but just remember it's existing software with certain hardcoded assumptions that have to be lived with. It's easy to bikeshed about how stuff should be, it's a whole different story to actually update the gnarly code to make it a reality and not break everyone's IDE in the process :)
Of course I cannot predict, that simple instruction:
if(pos == sci_get_current_position(sci)) return;
will break something. But if it will, there are _serious_ architecture issues.
But maybe experimenting on beta-testing stage isn't crazy idea?
-- Best regards, Pavel Roschin aka RPG