Comments 19
Спасибо, очень интересно!
Пойду заценю редактор.
> Таймер работает 20 милисекунд, потом возвращает управление в main loop для обработки действий пользователя, потом снова вызывается…
А не тормозит от этого интерфейс? Не лучше ли создать для этой цели отдельный поток?
P. S. Указали бы в начале статьи, что ваш компонент называется Qutepart.
А то первый раз название встречается в таблице.
Пойду заценю редактор.
> Таймер работает 20 милисекунд, потом возвращает управление в main loop для обработки действий пользователя, потом снова вызывается…
А не тормозит от этого интерфейс? Не лучше ли создать для этой цели отдельный поток?
P. S. Указали бы в начале статьи, что ваш компонент называется Qutepart.
А то первый раз название встречается в таблице.
Интересно было бы посмотреть сравнение с подсветкой в редакторах от JetBrains (например, WebStorm) и с Visual Studio.
И ещё бы Eclipse.
Добавил в подробную версию таблицы IntelliJ IDEA и Eclipse
Гораздо проще разбить подсветку на уровни вложенности. Например для «черновой» подсветки, можно не идти дальше первого уровня вложенности оавтомата. Таким образом разобъете весь файл на сегменты. После этого можно уже от того сегмента, который сейчас смотрит пользователь углубляться дальше первого уровня автомата.
Хмм. Идея хорошая!
К сожалению в Qutepart реализовать не получится. Как минимум для уже существующих парсеров. Я не стал расписывать в статье, но переходы по контекстам (состояниям) могут быть сложными. Например «подняться на два уровня вверх по стеку, потом перейти в контекст строка».
Так что, их обрабатывать можно только проходя по всем состояниям.
Возможно со всеменем я сделаю другую оптимизацию — парсить текст и размечать блоки сразу, а цвета и шрифты применять лениво, при отображении.
К сожалению в Qutepart реализовать не получится. Как минимум для уже существующих парсеров. Я не стал расписывать в статье, но переходы по контекстам (состояниям) могут быть сложными. Например «подняться на два уровня вверх по стеку, потом перейти в контекст строка».
Так что, их обрабатывать можно только проходя по всем состояниям.
Возможно со всеменем я сделаю другую оптимизацию — парсить текст и размечать блоки сразу, а цвета и шрифты применять лениво, при отображении.
Возможно, я чего-то не понял. Но как можно парсить не углубляясь внутрь блоков? Ведь возможно что закрывающая фигурная скобка без отступа это на самом деле не конец объявления функции, а всего лишь часть строки или блочного комментария, начатого в самой первой функции, но глубоко внутри.
Есть такая тема — инкрементальный парсер. Она, собственно, начинает переразбор по кускам кода (скажем, блокам, функциям, методам, классам) только если в этом кусочке что-то изменилось. И соответственно меняет AST.
Если коротко: штука весьма нетривиальная в реализации. Как правило, так не делают и обходятся регулярками, которые значительно быстрее.
Если коротко: штука весьма нетривиальная в реализации. Как правило, так не делают и обходятся регулярками, которые значительно быстрее.
Посмотрите на QFuture и QFutureWatcher и вообще на всю связку QtConcurent, и второе, если все равно это Qtшный модуль, то что мешает QRegExp взять?
если все равно это Qtшный модуль, то что мешает QRegExp взять?
Есть несколько способов скрестить PyQt и бинарный код.
1. Основной класс пишется на C++ и наследуется от класса Qt. C помощью SIP для него герерируются биндинги. Потом автогенеренные исходники компилируются в модуль расширения Python. Из модуля импортируется класс, доступный в PyQt.
Так работает, например, уже упомянутая QScintilla.
2. Основной класс пишется на Python и наследуется от класса PyQt. Вспомогательный модуль пишется на чистом C, компилируется стандартным для Python образом и экспортирует только функции и классы, не связанные с Qt. Класс на Python импортирует модуль и дергает его для выполнения тяжелых вычислений.
Qutepart собирается так, соответсвенно из модуля расширения Qt не доступна.
в свое время был в восторге
Интересно, насколько flex будет быстрее pcre?
А можете добавить в сравнение производительности IntelliJ IDEA и, по возможности, Sublime Text 3?
В Sublime Text 3 в build 3047 вроде как была улучшена производительность рендеринга.
В Sublime Text 3 в build 3047 вроде как была улучшена производительность рендеринга.
Добавил в подробную версию таблицы.
Разницу в скорости первоначальной подсветки в Sublime можно списать на погрешность моих измерений, а вот обновление подсветки при редактировании определенно стало лучше.
Разницу в скорости первоначальной подсветки в Sublime можно списать на погрешность моих измерений, а вот обновление подсветки при редактировании определенно стало лучше.
Я думаю разработчики kate будут рады если вы сними тоже поделитесь своей success story в их списке рассылки kwrite-devel@kde.org Возможно какие-то идеи со временем портируют назад.
ЗЫ еще бы неплохо добавить сравнение расходов памяти на подсветку (если они заметно отличаются). Те насколько увеличилось потребление памяти после открытия документа.
ЗЫ еще бы неплохо добавить сравнение расходов памяти на подсветку (если они заметно отличаются). Те насколько увеличилось потребление памяти после открытия документа.
Sign up to leave a comment.
Редактор с подсветкой кода. Проблемы и решения