Обновить

Комментарии 27

"..буфер обмена. В консольных Windows приложениях он просто работает и всё..
Проблема: Эффект «машинистки-призрака»"

Ах если бы..
Забавно, но в Windows 11 что-то улучшили, в результате при вставке большого объёма текста из буфера в редактор Far3/64 призрачных машинисток можно наблюдать не закрывая окон - только звука пишущих машинок не хватает. До кучи сломали отображение в развёрнутом (по умолчанию) виде, благо помню комбинацию Alt+F9..

А это у вас в классической консоли или в Windows Terminal такое? Подскажет, на уровне ConPTY или самого Console API баг.

Far отображается в таскменеджере как
Console Window and PTY Host (OpenSource) + Windows Terminal Host
Как продиагностировать, на каком уровне баг?

Выглядит как обычная консоль. Но на всякий: что показывает, если сделать echo %WT_SESSION% в фаре?

Похоже, не задано, отвечает %WT_SESSION%.

есть функция вставки WT, а есть FAR'a
у меня на ctrl-V (вставка WT - как пищущая машинка типа)
а по shift+ins мгновенная фаровская (надо отвязать хоткей (и) в WT просто)

Ага. Вот вставка WT теперь мгновенная. Попробуйте на мастере :)

Спасибо, попробую.

>До кучи сломали отображение в развёрнутом (по умолчанию) виде, благо помню >комбинацию Alt+F9..

far:config

System.WindowMode │boolean│false

Это про Far3? Потому что у нас такой настройки будто бы нет.

про FAR3

Спасибо, попробую.

вы подключились по SSH к серверу, где X11 Forwarding запрещен админом, и вам нужно вставить конфиг на 500 строк в редактор

В таком сценарии проще редактировать текст на удалённой машине в привычном и настроенном под себя редакторе на локальной системе.

Да, так можно тоже. Причем этим удаленным редактором может быть редактор far2l же (постоянно так делаю). Если подключаться по ssh из локального графического far2l, или скажем из WezTerm или kitty, будут гарантированно работать все сложные хоткеи.

Если редактор запускается в локальном far2l (который под капотом что-то незаметно делает по ssh при открытии/сохранении - так же можно?), какие в принципе могут быть проблемы с хоткеями?

Обычные ESC последовательности терминалов далеко не всё могут передать. Типичный пример Ctrl+Tab.

Но у far2l есть поддержка расширенных протоколов, решающих проблему

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

Ага

У меня Far в Windows 11 в этом WT ведёт себя странно - если переключить раскладку клавиатуры по Alt+Ctrl (неважно, даже если Far неактивный или свёрнутый), то цветовая схема становится сверхяркой. Если в Far запустить любую программу (даже пустышку типа "1") - цветовая схема становится верной.

Кто сталкивался с таким, и знает как это отключить?

Я про такое пока не слышал, но в чате точно есть пользователи с WT, и я считаю его одной из приоритетных платформ, так что можно смело пилить тикет!

Хм, почитал #11522 и соседние. В прошлой статье вы сделали тикет 9-летней давности. Такая относительно серьёзная контора (как Microsoft) баг не исправляет 4 года. Думаю за 9 лет не исправит.

Предложенные решения там мне помогают (блин, я ошибся с комбинацией переключения раскладки! Я использую Alt+Shift для переключения между языковыми группами, и Ctr+Shift для переключения языков в группе. Просто стёрлись надписи на клавишах, да и вообще - мышечная память всё помнит, а найти на клавиатуре где какая клавиша находится - это уже вопрос. Надо набрать слово - пальцы сами набирают).

На build.opensuse.org собирает Maintainer: Victor Krapivin (viklequick)
Far for Linux build package: openSUSE, Debian, Fedora, Ubuntu и plug-ins
На примере far2l-desktop(v2.7.0-1) - установка из реп в разные версии дистров

Всё так! Спасибо за дополнение :)

Там кайф ещё и в том, что можно ставить только конкретно нужные именно тебе части.

Ввнутренее название этой репы Insider preview, думаю о ней отдельный пост сделать

Это не совсем мастер -- там часто ahead of бывают из еще непринятых ПР. В том числе экспериментальные. Но можно пользоваться.

Плюс расширенный набор плагинов, которых тоже еще нет в мастере.

"современный менеджер файлов, и куда ему стоит двигаться"

Если брать мотивацию пользователя far2l, то скорее всего это будет звучать так:

  • первоначальное изучение (осмотр "потрохов") и настройка "непродакшн" проектов, где setup еще не предусмотрен;

  • поправить что-то вручную там где "скрипты" или заточенная под это UI не справляется, сюда в том числе входит поправка систем сборки и исходников;

  • быстрый ручной поиск-просмотр по проекту в том числе на удаленной машине, чтобы не утруждать себя синтаксисом команд find, grep, less, vim и прочих - так сказать решение нештатных ситуаций, когда точно не известна где проблема;

  • естественно любое копирование, работа с "громадными" файлами, смена атрибутов и т.п в том числе по сети;

  • интерактивная работа с архивами;

Где вряд ли будет использоваться (естественно есть гики):

  • просмотр, создание и редактирование медиа-контента, презентаций (я исключу быстрый просмотр из этого списка);

  • пользователи начального уровня скажем так - те которые в основном используют мышь;

  • разработка ПО с графикой и развитой визуальной составляющей.

Т.о. куда стоит двигаться глобально:

  1. Максимум Portable - минимальный набор зависимостей. Минимальный размер и максимальная скорость работы - вообще идеально один файл как в go. Скачал через wget на удаленную машину (или запустил "с флешки") - работаешь.

  2. Плагины отдельно от far2l. Во-первых установка только нужных, может быть какой нибудь менеджер плагинов сделать. Во-вторых иногда плагин больше и сложнее по коду может быть чем сам far2l - поддержка "в куче" сложна. В идеале вообще выделить Far2l SDK отдельно.

  3. Максимальное использование утилит из "никсов" или "макоси", а не свои "протезы" - авторы утилит часто лучше решают задачи - например копирование по rsync и т.п. far2l будет выступать "графической" оболочкой над ними.

Если кому интересна история вопроса, то вот она.

Начнем издалека -- так получилось (с), что в X11 аж три разных клипборд буфера.

Первый знают все -- он так и называется "clipboard". Тот самый, который по шорткатам Copy/Paste.

Второй многие тоже знают -- называется primary и в него автоматом попадает то что выделено мышкой. Чисто "мышиный" такой карман -- выделение автоматом складывает, клик по средней кнопке вставляет.

И есть еще secondary, но им мало кто пользуется.

Фар-отец с windows очевидно умеет только один карман -- в окошках одного хватит всем.

Соответственно, когда мы в far2l стали добавлять поддержку нескольких клипборд буферов, то

  1. в GUI проблем нет, ПР готов и работает для редактора, ком строки, диалогов -- в обе стороны. Именно так как принято в X11. Если композитор поддерживает соответствующий протокол -- то и в Wayland.

  2. С терминалами ад, содом и далее по списку. Некоторые терминалы умеют kitty, некоторые OSC52 -- но каждый со своим видением "секурити".

Так что для терминальной версии реализовано вот что

  • "туда" из фара в буфер -- работает и клипборд и праймари, и выделение мышой и шорткаты и оно не путает. Для этого в настройках интерфейса надо включить поддержку протокола OSC52 Write.

  • "обратно" из буфера в фар -- запрещено в целях безопасности. Протокол OSC52 Read выключен по умолчанию, иногда просто заблокирован (пример - konsole).

  • Так что в терминале far2l не может сам запросить чтение клипборда и тем более не может указать что он хочет. Видеокамера в туалете работает для вашей безопасности (С). Но он может принять из терминала посылку -- которая и называется bracketed paste.

Так что если хотите чтобы работали оба клипборда в терминале -- настраивайте терминал. Типовой способ выглядит так

  • Ctrl+V / Shift+Ins -- вставка из Clipboard buffer

  • Ctrl+Shift+Ins - вставка из Primary buffer.

Но и тут есть ложка дегтя -- терминалы на движке VTE (тот же gnome terminal) Shift+Ins мапят на Primary buffer, и не дают поменять.

Вот такой он, мир терминалов.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации