Гораздо проще разбить подсветку на уровни вложенности. Например для «черновой» подсветки, можно не идти дальше первого уровня вложенности оавтомата. Таким образом разобъете весь файл на сегменты. После этого можно уже от того сегмента, который сейчас смотрит пользователь углубляться дальше первого уровня автомата.
Хмм. Идея хорошая!
К сожалению в Qutepart реализовать не получится. Как минимум для уже существующих парсеров. Я не стал расписывать в статье, но переходы по контекстам (состояниям) могут быть сложными. Например «подняться на два уровня вверх по стеку, потом перейти в контекст строка».
Так что, их обрабатывать можно только проходя по всем состояниям.
Возможно со всеменем я сделаю другую оптимизацию — парсить текст и размечать блоки сразу, а цвета и шрифты применять лениво, при отображении.
Возможно, я чего-то не понял. Но как можно парсить не углубляясь внутрь блоков? Ведь возможно что закрывающая фигурная скобка без отступа это на самом деле не конец объявления функции, а всего лишь часть строки или блочного комментария, начатого в самой первой функции, но глубоко внутри.
Есть такая тема — инкрементальный парсер. Она, собственно, начинает переразбор по кускам кода (скажем, блокам, функциям, методам, классам) только если в этом кусочке что-то изменилось. И соответственно меняет AST.
Если коротко: штука весьма нетривиальная в реализации. Как правило, так не делают и обходятся регулярками, которые значительно быстрее.
Инкрементальный парсер в этой статье и описан. Он же перепарсивает с точки изменения, это в статье указано. Не думаю, что это как-то связано с упомянутым парсингом «по уровням вложенности».
вот я, если честно, перечитал текст и не совсем понял, корректный ли инкрементальный парсинг используется или что-то вроде хака, очень уж там мало об этом.
если все равно это Qtшный модуль, то что мешает QRegExp взять?
Есть несколько способов скрестить PyQt и бинарный код.
1. Основной класс пишется на C++ и наследуется от класса Qt. C помощью SIP для него герерируются биндинги. Потом автогенеренные исходники компилируются в модуль расширения Python. Из модуля импортируется класс, доступный в PyQt.
Так работает, например, уже упомянутая QScintilla.
2. Основной класс пишется на Python и наследуется от класса PyQt. Вспомогательный модуль пишется на чистом C, компилируется стандартным для Python образом и экспортирует только функции и классы, не связанные с Qt. Класс на Python импортирует модуль и дергает его для выполнения тяжелых вычислений.
Qutepart собирается так, соответсвенно из модуля расширения Qt не доступна.
А можете добавить в сравнение производительности IntelliJ IDEA и, по возможности, Sublime Text 3?
В Sublime Text 3 в build 3047 вроде как была улучшена производительность рендеринга.
Разницу в скорости первоначальной подсветки в Sublime можно списать на погрешность моих измерений, а вот обновление подсветки при редактировании определенно стало лучше.
Я думаю разработчики kate будут рады если вы сними тоже поделитесь своей success story в их списке рассылки kwrite-devel@kde.org Возможно какие-то идеи со временем портируют назад.
ЗЫ еще бы неплохо добавить сравнение расходов памяти на подсветку (если они заметно отличаются). Те насколько увеличилось потребление памяти после открытия документа.
Редактор с подсветкой кода. Проблемы и решения