Представим, что юзер открывает файл размером 10гб в редакторе кода и пролистывает хоткеем в конец. Допустим, редактор умеет корректно работать без предварительной подгрузки всего файла в память (под ответственность юзера что файл никто со стороны не испортит в неожиданное время, или пусть вообще он в read-only режиме - просмотрщик кода). Как редактор кода должен себя вести в плане подсветки синтаксиса?
В техническом плане тут всё очевидно: пока редактор не прочтёт и не распарсит все 10гб, сделать гарантированно правильную подсветку в конце он не сможет (ведь где-то в середине может быть открывание комментария, например). Вобщем-то и варианты поведения очевидны (ниже напишу), вопрос именно в том, какой их них наилучший в плане удовлетворения юзера. Допустим даже в конфиге можно выбирать эти варианты, но есть же дефолт - и он должен быть максимально не бесящим насколько это возможно.
Варианты:
1) залагать и парсить подсветку этих 10 гб, и только когда оно доделалось отлагать и нарисовать всё
2) нарисовать конец файла без подсветки, парсить её в фоне (где-нить выводить % готовности) и как закончим - нарисовать с подсветкой
3) нарисовать конец файла с черновой подсветкой, распарсенной без учёта пролистанных мимо страниц (ну, возможно ещё захватить сколько-то кбайт/строк выше верхней границы видимости), в фоне парсить нормально и как дойдёт до конца - перерисовать
4,5) варианты 2,3 но в фоне ничего не парсить и так и оставить (ведь юзер может оказаться недоволен нагрузкой на диск или на проц, из-за которых лагают другие проги)
6) каждый раз в таких случаях спрашивать у юзера хочет ли он фоновый или нефоновый парсинг (в виде попап окна) и надо ли делать предварительную неточную но быструю подсветку
