Форк Midnight Commander c поддержкой панельных плагинов

Не открываются архивы

да, нашел, вчера сломал когда дорабатывал добавление внешних архиваторов, починю сегодня.

По всей видимости в виде плагина с таким функционалом. Именно с возможностью описать свой формат, потому что при копании во внутренностях в прошивках всякой микропроцессорной электроники периодически такая надобность возникает в случае если готовой смотрелки для такого под линукс нет.

написал на почту на aol

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

искать не нужно это автор hiew и там язык описания структур неплохой был. идея просмотра структур мне в целом нравится, сам время от времени ковыряюсь в данных сырых.

а какое ожидание?

Это мне напомнило FAR, всегда считал, что комстрока должна быть сверху. Это конечно вкусовщина, кому-то нравится такое поведение. На мой взгляд логичней изначально видеть промпт сверху (в левом вехнем углу), как наверное во всех терминалах (кроме некоторых выпадающих).

На мой взгляд логичней изначально видеть промпт сверху (в левом вехнем углу),

при таком подходе промпт это неотъемлемая часть шела, и это логично но немного не в концепции двух пространств «область панелей», «область комстроки», при этом панели находятся над виджетом который содержит output.

Могу записать видео, как это происходит в SciTE. Годится?

было бы круто

https://postimg.cc/JtNMHS8Y.
Я SciTE редко использую только из-за этого. :)

А, оно скрывает текст, не соответствующий критерию фильтра? Интересный grep :)

не очень понял суть проблемы

Поставить ваш mc6 в систему на штатное место - не могу, у меня там mc 4.8.13 стоит и каждый день используется. Надо разбираться как в /usr/local что ли засунуть. А без правильной установки просто запущенный бинарник упорно режет восьмой бит.

Скоро закончу дрова на зиму заготавливать и займусь разбирательствами.

В новой реализации вывод шелла попадает во внутренний экран виджета, а не на реальный терминал.

И что, потом mc будет сам всё это на терминал выводить, обрабатывая всякие хитрые esc-последовательности которые запущенный софт мог туда напихать? А точно не будет глючить? И настройки в terminfo учитывать?

если я корректно реализовал то глючить не будет. Но давайте будем честными - БУДЕТ! на то он и софт чтобы глючить. Но я полгода вычищал косяки именно с esc-последовательностями, и сейчас их пока не встречаю, скорее проблемы встречаются с OSC-7 или смежными.

Если идея покажется интересной

https://github.com/ilia-maslakov/mcdev/wiki/Mcstruct

если я корректно реализовал то глючить не будет.

Эмулятор терминала с esc-последовательностями и использованием настроек из terminfo, и все это в одно лицо? Да вы монстр! В хорошем смысле.

вычищал косяки именно с esc-последовательностями

В комплекте с ncurses когда-то видел программу специально для тестирования esc-последовательностей. В те времена находила неправильности в линуксовом terminfo, которые я подправлял на своей машине.

https://github.com/ilia-maslakov/mcdev/wiki/Mcstruct

Выглядит симпатично. И судя по представленным картинкам с просмотром DBF-файлов - нормально работает с однобайтными кодировками.

Выглядит симпатично. И судя по представленным картинкам с просмотром DBF-файлов - нормально работает с однобайтными кодировками.

оно конечно не для просмотра dbf, это как раз штука которая аналогична structlook. кстати тут блог автора eugenys.blogspot.com и он оказывается еще живой )

wiki/Mcstruct

А где скачать? :)

оно конечно не для просмотра dbf

Понятно что dbf это просто пример. Но пример как раз удачный. Была бы это таблица соответствия частот и номеров каналов в прошивке какой-нибудь древнеяпонской рации - мало кто оценил бы полезность. А рации эти как раз хорошие, они тогда еще не в Китае делались. Но конфигурационного софта к ним либо нет вообще, либо ему нужен комп с голым ДОСом и железным ком-портом. И то не факт что заработает.

Да, term mode делает вещи :)

Только в нём с прокруткой что-то не то.

Да, хотел дописать, но не успел :) Оно и в форматированном виде (а как мы помним, в стоковом mc состояние, которое меняется по F8 и F9, обратное к тому, что показано – 9 Не форм – и да, тут, ИМХО, есть лишний пробел), вроде бы работает, но я заметил странную штуку. Оно сначала прокручивает файл до конца, потом ты скролишь (стрелками, мышь не реагирует) вверх, доходишь до начала, и, если ты продолжаешь давить UP, файл проматывается снова в конец, и так по кругу. А в Term Mode такого нет.

Картинки в xterm-е и подобном - извращение.

Есть еще один способ извращаться с картинками и xterm - уменьшаем шрифт до минимально возможного, после чего задаем цвета пробелу и этими цветными пробелами рисуем картинку. На старых мониторах «пиксели» крупноваты получались, а на мониторах с высоким достаточно dpi даже вполне приемлимо выглядит. Кроме esc-последовательности задания цвета - ничего не нужно.

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

можно пример, о чем идет речь?

mcterm игнорирует настройку «Пауза после выполнения»? У меня она в «Никогда», но после команды при видимых панелях не происходит автоматического их разворачивания.

@angel_il, спасибо за фильтр в редакторе по Alt-S, просто огнище! :)

Ещё бы хотелось автоподхватывания текущего слова или выделенного фрагмента.

Заметил, что в mcedit при сохранении файла по F2, поверх редактора в 24-ой строке выводится обрезанный путь к файлу.

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

А у некоторых ЭТ, например, у xfce4-terminal, вообще соотношение сторон задаётся в настройках жёстко, и ты не можешь менять размеры окна как тебе заблагорассудится. Но можешь сделать окно полноэкранным.

В том xfce4-terminal, которым я пользуюсь (0.8.10, xfce 4.16), окно вполне себе можно ресайзить. Да и даже если бы было в настройках - ведь их можно менять на лету всё равно. Но это не важно, ресайз окна в любом случае общеупотребительная фича гуи-терминалов сейчас.

Так и у меня тоже можно, но, как говорил, только сохраняя указанное в настройках текстовое разрешение и, как следствие, соотношение сторон. Но это от используемого шрифта может зависеть.

только сохраняя указанное в настройках текстовое разрешение

Это логично, имхо. Для новых окон ориентироваться на геометрию (ряды-колонки), а не на фактические размеры.

Если ресайз то разрешение очевидно меняется (и никаких ограничений на соотношение сторон нет). Или у тебя при ресайзе шрифт масштабируется? Может ты включил где-то что-то, не знаю, у меня такого нет.

Вдруг вспомнил, что просил автора bfs добавить библиотеку с API. А он, оказывается, давно сделал, но пока без инсталляции необходимых файлов.
Ни на что не намекаю, но вдруг пригодится. ;)

Только у меня номер строки другой, но тоже есть такое. И не все блоки кода можно свернуть.

Из опенсорсного в этом направлении есть Kaitai Struct, когда-то активно пиарился на ЛОРе, в последнее время стагнирует – но может, потому, что уже достиг стадии «просто работает»?

Заметил, что в mcedit при сохранении файла по F2, поверх редактора в 24-ой строке выводится обрезанный путь к файлу.

это чисто визуальный баг? а… я похоже не вырубил тестовый lua hook, я гляну чтобы его гасануть. Плохо, плохо, неважно… (с)

Похоже, что да – я никаких изменений в просматриваемых файлах не увидел.

ок, я поковыряюсь с DECAWM / CSI ? 7 h/l есть идея как можно обрабатывать описанный кейс, если упорюсь и не смогу то описанный вами кейс перейдет в особенности реализации а не баг выбора архитектуры.

Ещё бы хотелось автоподхватывания текущего слова или выделенного фрагмента.

при нажатии поиска?

Нормально его никак не обработать, особенно учитывая что ты не можешь знать, по какому конкретно событию вышестоящий терминал может сконвертировать врапнутую строку в две отдельные (а тебе надо быть с ним консистентным, иначе всё равно местами будет плыть геометрия).

Вот пример: курсор на 1,1, выводишь строку длиной в полторы ширины экрана, затем esc-командой ставишь курсор на начало второй строки (там хвост от врапнутой первой) и что-то туда ещё пишешь. Затем юзер ресайзит окно. Точнее, ты даже точно не знаешь когда он его ресайзнул - до второго вывода или после, а ведь только от этого зависит куда попадут эти символы. Будет же терминал после explicit вывода на вторую строку продолжать считать её хвостом первой или сделает отдельной - вообще нигде не специфицировано и полностью на усмотрении его авторов.

да, это косяк сборки, демо скрипт «notify-editor-save» подписывающийся на события редактора попал вместе с продовыми lua скриптами в одну папку. сейчас PR опубликую с правкой этой фигни.

фиксанул вот тут https://github.com/ilia-maslakov/mcdev/pull/196

но наверное можно руками грохнуть эти 2 демо скрипта

/usr/share/mc/lua/scripts/editor/notify-editor-save /usr/share/mc/lua/scripts/mc/demo-panel

А я уже с AUR пакет пересобрал :)

суть проблемы я уловил, но это не значит что надо прекратить писать консольный софт. Да некоторые и иногда существенные неудобства возможны и реврап нужен для потока: cat, логи, компилятор, ls -R, вывод команд, но то, что лежит в истории и что никто больше не трогает. другое дело программы с абсолютным позиционированием (например vim, htop) они сидят в alt-screen, а там реврапа нет, они перерисуются сами по SIGWINCH.

Так что единственная серая зона это readline на живой строке приглашения и прогресс-бары с \r. После реврапа приложение получает SIGWINCH и перерисовывает текущую строку само, а readline это умеет.

В целом аргументация и рассуждение верное но для одной конкретной ситуации: когда ты эмулируешь терминал внутри «чужого» терминала и обязан быть с ним побайтно консистентен. Но для mcterm это совсем не так, поэтому большая часть описанных сложностей не релевантна mcterm-у.

mcterm игнорирует настройку «Пауза после выполнения»? У меня она в «Никогда», но после команды при видимых панелях не происходит автоматического их разворачивания.

пометил себе

В /{,usr}/bin/ непереименованным остался mctree :) Но, в принципе, mc6 больше не конфликтует по файлам с mc, разве что, ИМХО, /usr/lib/mc тоже надо бы переименовать в mc6 – тогда ни у одного ПМ больше не будет поводов для такого:

pacman -Qo /usr/lib/mc
/usr/lib/mc/ принадлежит mc 4.8.33-1
/usr/lib/mc/ принадлежит mc6-git 6.0.3.220.g86f71fe4a-1

другое дело программы с абсолютным позиционированием (например vim, htop) они сидят в alt-screen

А вот и не всегда. top например alt-screen не делает. Более того, многие считают alt-screen неудобным и специально отключают там где он вообще может быть. Например, в фрибсд он отключён для less и screen дефолтно.

Но для mcterm это совсем не так,

Почему? Я может неправильно понял, но мне казалось что ты сделал весь вывод запускаемых внутри mc прог обёрнутым в свой vt100 эмулятор, нет?

Я может неправильно понял, но мне казалось что ты сделал весь вывод запускаемых внутри mc прог обёрнутым в свой vt100 эмулятор, нет?

всё так, и поэтому проблемы консистентности нет. (если я правильно заблуждаюсь)

top например alt-screen не делает. Более того, многие считают alt-screen неудобным и специально отключают там где он вообще может быть.

тут тоже соглашусь, реврап - эвристика, и для потокового вывода в 99% кейсов она точная (но это не точно). Важно тут то что для программ, которые рисуют абсолютно на основном экране, она не особо бесполезна, и они перерисуются сами, но и история от них это скорее мусор/шум или не шум. Вобщем пережить можно если что то съедет немножечко в редких случаях.

всё так, и поэтому проблемы консистентности нет. (если я правильно заблуждаюсь)

Ну как нет, вот прога через mcterm-прослойку вывела что-то на экран, оно в итоге попало в гуи-терминал. Затем гуи-терминал ресайзнули, он сделал (по своим алгоритмам) реврап тому что было в его буфере. mcterm тоже делает реврап в своём буфере. Если консистентность есть, то на этом можно и закончить, больше ничего делать не надо. Если же её на этом этапе нет, то придётся либо мириться с тем что всё куда-то уплывает, либо mcterm должен после каждого ресайза заново всё перерисовывать. Встаёт вопрос, докуда надо делать перерисовку, там где-то начинается скроллбак, но из-за ресайзов его граница может двигаться в обе стороны и это тоже будет сказываться на перерисовках. Кроме того, эти перерисовки будут вносить дополнительные лаги. А ещё надо следить, чтобы перерисовка была в правильном месте и не оставляла за собой всякий мусор в скроллбаке гуи-терминала (не уверен что это всегда возможно кстати, дописать вниз строки то всегда можно а укоротить буфер назад вроде ж нельзя - а это иногда потребуется).

Да, может быть с соответствующей настройкой редактора.
Или по Alt-Shift-S.

Из опенсорсного в этом направлении есть Kaitai Struct

Тоже сразу его вспомнил, но это нужно будет писать свой парсер файлов .ksy.
Зато их уже ~ 200.