Indeed scrolling in the large C source file (3781KB, 110861 lines) is noticeable slower than in my C file (215 KB, 4060 lines). So there is something which can be improved, although I guess that this is surely not a typical C file. I have never seen such a large C source file and as the comment at top describes, it is created by copying the source of different modules (C files) together into a single file. However, I think the delay on scrolling with the vertical scroll bar is not so big that it is really interfering.
Interesting is that scrolling with PgUp/PgDn with maximum key repeat rate is extremly fast and also scrolling with the middle mouse button and using autoscroll
. So the scrolling delay exists only when scrolling with the vertical bar which causes jumps in the file. The vertical scroll bar is based on number of lines and not number of bytes. So on move of the vertical scroll bar the appropriate difference in line number count must calculated and then the file read and searched for line endings to find +X or -X lines to display the new position. Text files have normally not identical line lengths like records in a database file. So simple the forumula
new file position = current file position + X lines * bytes per line
can't be used for text files as used in database files. But I agree the scrolling with the vertical bar could be nevertheless faster. There is something in the code of UltraEdit which results in a delay when the file is larger. I played a little with the file size and it looks like vertical scrolling is fast up to file sizes of 512 KB. It could be that 512 KB is the internal file cache size.
About the issue: "UE can corrupt Windows if uedit32.ini is in Windows dir and using backup/restore feature"
There are definitely more important issues to work on than this one. Since UE v10.20 the default location for the INI file for new installations is %appdata%\IDMComp\UltraEdit\. The numbers of users upgrading from pre v10.20 to latest version is surely very small. Those using the backup/restore user customizations dialog is even smaller and those using it with clicking on button Select All without looking on which files are now added to the archive and later restore the entire archive without looking again on the files is extremly small. So I suppose the number of users affected by this issue can be counted with 10 fingers. Sure, the developers could add code to uncheck and disable option Others
(= all other files in directory of INI) when the directory of the INI file is equal the Windows directory. But the priority for doing that is extremly low because of the extremly low number of users affected by this issue especially because every affected user can manually avoid the problem.
If you are not happy with UltraEdit and you are angry with IDM, why do you use UltraEdit? There are so many other editors. (Of course surely not so many with such a big list of useful features and definitely no one 100% bug free.)