LINUX.ORG.RU

mcedit + tree-sitter

 , , , ,


0

1

Jiri Tyr сделал PR#5067 в Midnight Commander, добавляющий возможность интеграции библиотеки и парсеров tree-sitter в mcedit. Парсеры могут быть прилинкованы как статически, так и динамически (по умолчанию).

Прилагаемый скрипт по умолчанию загружает с репозиториев 63 парсера (без клонирования), но возможна их выборочная интеграция.

Выглядит перспективно для будущего улучшения, если автор на этом не остановится.

Хотя на данный момент и не без проблем. Например, tree-sitter-c очень долго парсил мой sqlite3.c (~10 МБ) и раскраска была сделана обычным методом mcedit регулярными выражениями. И пока нет опции для отключения tree-sitter.

Ну и парсер SQL требует C++ для компиляции, против чего решительно против Юрий Зайцев:

And one final point, requiring a C++ compiler is absolutely a no-go.

На скриншотах пара примеров C++26, но я пока не признаюсь, где какой mcedit. :)

И скриншот с исходником Scala, который не поддерживается в оригинальном mcedit.


Вишенка на торте: автор признался, что использовал «ИИ»:

On AI usage - yes, I used AI assistance for both the implementation and drafting the previous response. The design decisions are mine but the tooling helped enormously with the volume of work. I find the structured format contributes to better readability even if it has that recognizable feel.

★★★★★

Проверено: Dimez ()
Последнее исправление: dataman (всего исправлений: 6)

Вишенка на торте: автор признался, что использовал «ИИ».

Так щас вообще все его используют же.

Zhbert ★★★★★
()
Ответ на: комментарий от Zhbert

Нет, я их теперь щупаю этим mcedit. :)

dataman ★★★★★
() автор топика
Ответ на: комментарий от dataman

Просто использование каких-то медленных парсвров в редакторе, задача которого быть простым и быстрым мне мало понятно

mittorn ★★★★★
()
Ответ на: комментарий от mittorn

Да не медленный tree-sitter, просто «ИИ» тупой. :)

dataman ★★★★★
() автор топика

А как редактировать раскраску? В syntax-файлах можно что-то исправить, или вообще написать свой, а здесь?

dmitry237 ★★★★★
()

пользователи ПК, редактирующие файлы через mcedit всегда вызывали у меня подозрение

gagarin0
()
Ответ на: комментарий от dataman

С подсветкой синтаксиса в mcedit всё ещё есть проблемы, но не знаю, как к ним подступиться. Бывает такое, что она ломается. Вот, например, открыл в mcedit кусок bash-скриптоты от GRUB’а, сначала он нормально раскрашивает, а потом встречает, например, строку с вложенными двойными кавычками и раскраска «едет».

yars068 ★★★★★
()
Ответ на: комментарий от yars068

Вот именно такие подозрение у меня и были, что только слесарь или дворник будет редактировать в линуксе файлы через mcedit

gagarin0
()

На скриншотах пара примеров C++26, но я пока не признаюсь, где какой mcedit. :)

На втором подсветка аргументов #include неправильная, других отличий нет. Зачем нужен какой-то спец. плагин для подсветки синтаксиса когда она и так есть из коробки не понял.

firkax ★★★★★
()
Ответ на: комментарий от dataman

Я попробовал и не смог.

Очень популярная связка имени и фамилии, но все результаты в Google не про него.

IIIypuk ★★★★★
()
Ответ на: комментарий от ox55ff

Неа. Если ты отдельно вынес это имя, то и объясняй зачем нам знать твоего Юру.

Он же это имя даже ссылкой сделал, чтобы те, кому интересно, могли кликнуть и посмотреть. Не понимаю претензии.

CrX ★★★★★
()
Ответ на: комментарий от dataman

так вы и systemd не пользуетесь… тот же аи он совсем не плох при разумном применении. ну а systemd тут и говорить нечего :))

SpaceRaven
()

Вишенка на торте: автор признался, что использовал «ИИ»

он там и комменты нейронкой пишет. Товарищу судя по всему наплевать что мейнтейнерам придется читать сгенеренные ей портянки текста, исходники в его PR наверняка такие же.

Лично я бы на месте товарища Зайцева закрыл такое не читая. Если автор реквеста сам не читал то что он там навайбкодил, то почему я должен?

Lrrr ★★★★★
()
Ответ на: комментарий от gagarin0

всегда вызывали у меня подозрение

и какое оно подозрениЕ ?

x905 ★★★★★
()

Привет. А не знаешь, комментирование сразу пачки строк не завезли? А то кажен раз вспоминать как это в виме делается…

S_Paul ★★★★★
()
Ответ на: комментарий от dataman

Для меня это тоже ноунейм, ничуть не более известный чем любой анон на ЛОР-е. Иные с 2 звёздами и то более известны.

peregrine ★★★★★
()

Автор сего PR находится где-то на уровне мидла по Go. Это достойно для девопса.

Да, автор использовал ИИ, даже весьма черезчур, но не то, чтобы логика клея к tree sitter-у требовала сверхзнаний сишки. Тут скорее самый большой вопрос - это «зачем ты это сделал?». Ruby, Perl, C++ невероятно тяжело парсить, нужно по сути повторять парсер интерпретатора/компилятора — эту проблему никак не избежать. А как распарсить макросы Си? Без анализа проекта целиком (аля clangd) это вообще нельзя сделать.

В mcedit людям не нужен доскональный парсинг, им нужно чтобы парсер не спотыкался на элементарных вложенных конструкциях. То есть, полный Tree Sitter на самом деле не нужен. Нужно что-то вроде https://github.com/lite-xl/lite-xl-plugins/tree/master/plugins , которое эдакие регулярки на стероидах стэковой машине.

Но вот беда: оттранслировать эти правила в свой язык конфигураций и сделать интерпретатор этих правил — это достаточно непрямолинейная задача, её простым нейросетевым клеем не решишь.

byko3y ★★★★★
()
Ответ на: комментарий от byko3y

А как распарсить макросы Си? Без анализа проекта целиком (аля clangd) это вообще нельзя сделать.

Это и с анализом проекта в общем случае сделать нельзя, если у него есть внешние опции компиляции.

firkax ★★★★★
()

использовать far2l с Colrer ??

pfg ★★★★★
()
Ответ на: комментарий от firkax

Это и с анализом проекта в общем случае сделать нельзя, если у него есть внешние опции компиляции.

Можно. Пишешь процесс компиляции в compile_commands.json - и парсишь все макросы успешно.

byko3y ★★★★★
()
Ответ на: комментарий от byko3y

Нельзя. Тебе надо парсить не конкретный конфиг компиляции на твоём компе, а исходник в общем виде. То есть всякие #ifdef HAVE_SPRINTF итд должны парситься универсально - чтобы подходило в обоим вариантам. Чего, очевидно, добиться в общем случае принципиально нельзя. Например, в одной из веток может быть #define printf { (макрос слова на открывающую фигурную скобку).

Если что, я не считаю такие случаи полезными, и считаю достаточным парсинг без анализа исходника вообще, исключительно из общих соображений. То что он сломается на неадекватных макросах - вина программиста, эти макросы написавшего.

firkax ★★★★★
()
Ответ на: комментарий от firkax

То есть всякие #ifdef HAVE_SPRINTF итд должны парситься универсально - чтобы подходило в обоим вариантам. Чего, очевидно, добиться в общем случае принципиально нельзя.

Тебе не приходило в голову, что суперпозиция двух разных конфигураций может просто не подлежать компиляции из-за конфликтов объявлений, потому в принципе не может быть никакой задачи парсинга одного исходника одновременно с двумя конфигами?

В остальном — согласен.

byko3y ★★★★★
()
Ответ на: комментарий от byko3y

Смотри, я пишу:

Чего, очевидно, добиться в общем случае принципиально нельзя.

Ты пишешь

потому в принципе не может быть никакой задачи парсинга одного исходника одновременно с двумя конфигами?

То есть ты согласен но почему-то выдаёшь это за возражение.

firkax ★★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.