Здравствуйте, Marty, Вы писали:
M>Да. Но в большинстве случаев это не нужно. Например, у меня в перспективе маячит раскраска кода листингов в документации, того, который в маркдауне ограничен тремя бэктиками, а на кывте обрамляется тэгом code.
Ну, тогда я не совсем понимаю, чего вы хотите. В начале вы сослались на Гвидо, который объясняет причины, по которым он предпочёл бы переехать на PEG. Но PEG — это не лексер, это безлексерный парсер.
M>Часто большее и не нужно
Я ж не спорю — если ваши планы заканчиваются на лексической раскраске, то ваше решение прекрасно.
M>Есть токенизатор, есть ручки, которые можно дергать. К токенизатору можно прикрутить надстройки, и да, он становится не совсем честным. И что?
То, что теряется смысл выделять отдельно токенизатор, т.к. это затрудняет разработку полного решения.
M>Да, я до возможностей IDE сильно не дотягиваю, но у меня уже гораздо лучше, чем том же notepad++.
M>Когда я на говне запилил свой первый DSL, который локально хорошо взлетел (но не первый мой DSL вообще), то был вопрос, а где его редактировать, чтобы красиво. Получилось в NPPP и Кейле. В NPPP — через его настройки кстомной раскраски, в Кейле — через правки конфигов какого-то движка, который я перепутал с тем, что наша местная терраинформатика делает. И там и там всё было на пределе возможностей, приходилось извращаться. А сейчас у меня уже гораздо лучше.
Стандарт де-факто сейчас — это VS Code, а точнее — протокол LSP.

M>Моё решение предлагает задание операторов оптом, задание различных типов скобок, и наборы фильтров. Всё это можно варьировать при настройке и получать результат лучше, чем в NPP. Уже годно для тупого лексера.
Ну так и замечательно. Просто если вы хотите что-то куда-то развивать, то тупой лексер, с моей точки зрения — тупик.

M>Мой "токенизатор" писался с упором на то, чтобы можно было в первую очередь распарсить существующие языки. Что может придумать воспалённый мозг, я не знаю.
А что тут не знать?
M>Например, что a--b, это не полная хрень, а a минус b с унарным минусом. Если нужно такое — это не ко мне. У меня жадный алгоритм токенизации. И он выплюнет a, --, b, для примитивной раскраски этого достаточно, как в прочем, и для дальнейшего разбора.
Ну, интерполированные строки он сможет разобрать?

M>Не очень понятно, что ты хотел сказать.
Что поддерживать парсер языка, в котором собственно грамматика размазана по токенизатору, парсеру, и пачке "фильтров", которые меняют поведение токенизатора и парсера — то ещё занятие.

M>Мне до этого ещё далеко. Но не вижу особых проблем. Не уверен, что на каждое нажатие клавиши надо делать вставки в единственный глобальный string с текстом. На вскидку — будет глобальный текст, и список строк, которые ссылаются индексами на глобальный текст. Если пошло редактирование строки, то глобальный текст не перестраивается при каждом вводе, просто для строки выделяется отдельный буфер и строка маркируется признаком своего буфера. Потом вставляем, пробегаем и обновляем индексы после нашей строки, переделываем раскарску. Раскраску при вводе/удалении можно сдвигать/удалять по месту, на базе старой, без перескана, при паузах и в фоне можно всё перестраивать/пересканивать как угодно. В общем, что-то не вижу особых проблем. Мои варианты решений конечно далеки от дедовских, которые шуршали даже на XT, но, как минимум не хуже того, что сейчас в тренде.

Очень хорошо.