Вышла версия 25.2.11 файлового менеджера Yazi

Этот saahriktu испортился

Оргинального saahriktu уже давно подменили

У меня есть несколько приложений, которые я периодически собираю из апстрима. Не вижу разницы после git pull написать cargo -p deb, а не make package.

Erlang
emojis

Трындец. В голове не укладывается. Для полноты картины не хватает Cobol и Pascal с эмодзями.

Так это уже не тот саахрикту? :(

Да, саахрикту уже не торт :(

Pascal с эмодзями

program sigmab1;

begin
        writeln(#$ce#$a3#$f0#$9f#$91#$a6);
end.

$ ./sigmab1
Σ👦
$

А был??

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

Я больше 3х часов вручную ковырял 10к файлов, но жаль, что не съэкономил 5 секунд на открытие директории 🤦🏽‍♂️

Ну все, капец, приплыли!

1. Да. Они всё равно точно так же неприятны, даже если потом ковыряться час. Дело не столько в том, что это время можно было потратить с пользой, а в том, что это доставляет дискомфорт.
2. 5 секунд было не надо 10к файлов, а намного меньше. Там оно от количества зависит, может наверное и минуту быть.
3. Это может делаться не за один раз, и каждый раз придётся ждать 5 секунд.
4. Опять же, в vifm или mc оно открывается моментально сразу раскрашенным — почему «невероятно быстрый терминальный файловый менеджер», как его представляют разработчики, не может хотя бы так же? Да, я понимаю, что от там какие-то превьюшки генерит, то во-первых, эти превьюшки вообще не факт, что будут нужны, а во-вторых, можно было бы раскрасить имена файлов так же моментально, а потом уже спокойно себе генерить свои превьюшки.

Предполагаю, что mc раскрашивает по расширению файла, а yazi проверяет mime-тип файла, что явно дольше. Ну и никто не мешает ограничить или отключить генерацию превью.

Предполагаю, что mc раскрашивает по расширению файла

Еще шебанг

Предполагаю, что mc раскрашивает по расширению файла, а yazi проверяет mime-тип файла, что явно дольше.

Похоже на то. Странное решение, потому что в 99.999% случаев по расширению всё нормально раскрашивается.

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

Ну и никто не мешает ограничить или отключить генерацию превью.

Но раскраска по расширению от этого не появится.

Т.е. в ДОСовский нортон коммандер оно не могёт - де панели не существуют, я так понимаю?

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

Переходишь в новый каталог, и все файлы без раскраски по типам показываются, через секунды две-три (в зависимости от количества файлов, иногда быстрее) — раскрашиваются.

Это потому что «Полная поддержка асинхронности» :)

Еще шебанг

Я перепутал с подсветкой синтаксиса.

Для панелей ~/.config/mc/filehighlight.ini с группами файлов, а сам цвет определяется в скине ~/.local/share/mc/skins/скин.ini в секции filehighlight

А как же «F6 - Enter - Tab ай лайк ту мув ит мув ит»? :)

Ну все, капец, приплыли!

Так теперь много где можно.

       IDENTIFICATION DIVISION.
       PROGRAM-ID. SIGMAB2.

       ENVIRONMENT DIVISION.

       DATA DIVISION.

       PROCEDURE DIVISION.
           DISPLAY 'Σ👦'.
           STOP RUN.

$ ./sigmab2
Σ👦
$

возьму просмотрщик фоток/медиа и обработаю. бужет лучше эффективнее и удобнее…
зачем в консольном менегере просмотр фоток. ты предложи еще кофеварку прикрутить. :)
под консолью я понимаю работу на удаленной машине по ssh.
на локальном десктопе можно и вышеуказанный просмотрщик запустить.

Чем это лучше rangerlf?

Да речь же не про обработку, а про предпросмотр.

Чем rangerlf

Удачи через просмотрщик фоток/медиа отправить некоторые из них через ssh на другую машину.

монтирую удаленную фс через sshfs и отправляю фотки любой обычной прогой :)
мусье, мы не в винде :) в линухе мульен и маленькая тележка методов работы с файлами.
а если курнуть план9…

FishHook, тем более надобно использовать удобну спец.программу и не пркручивать ужа (медиа) к ежу (консольный фм)
вы же поддерживаете TrueUnixWay или нет ??

Большинство разработчиков (С, С++) известных приложений осилили пакеты, PPA, и многие даже AppImage. Но, подозреваю, предлагают собирать ручками пакеты мне те, кто топит за Rust.

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

Потому, что софтина написанная на Расте. При каждой операции оно проверяет, а не лоханулся ли разработчик в коде что позволит выйти за пределы массива?… И что, о боги, вызовет сегфолт. Разработчик софтины, который выбрал этот ЯП, якобы из-за безопасности которая здесь не к месту, облегчил себе тем самым процесс разработки (если сравнивать с разработкой на Сишке). В итоге, ты платишь тактами своего проца, своими деньгами за электричество и самым ценным – временем своей жизни, когда ты ждешь пока эта софтина пошевелится.

Ты б хоть почитал, как на самом деле достигается эта безопасность, чтоб не позориться…

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

Еще раз, как ты выберешь нужные фотки без превью их содержания? Ну и обратно, у тебя на удалённом сервере миллион фоток, как без превью их перекинуть себе?

Вы когда-нибудь слышали о Dired? Это файловый менеджер внутри GNU Emacs. Принцип работы очень простой: вы можете открыть сколько угодно каталогов и переключаться между ними как между файлами. При необходимости можно настроить копирование и перемещение файлов из активного буфера в предыдущий. Судя по всему, здесь та же самая идея, только на Rust.

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

Раскраску можно включить напрямую по расширению и в превью будет сразу работать. Просто нужно в файле .config/yazi/theme.toml

rules = [
    # Videos
    { mime = "video/*", fg = "magenta" }
]

заменить на

rules = [
    # Videos
    { name = "*{mkv,avi}", fg = "magenta" }
]

И так дописать все расширения по вкусу и цвету.

Вот только на современных ноутбуках Ф-кнопки жмутся через Фн

Конечно же, как настроишь. Режим зажимания Fn есть, наверное, на всех популярных брендах.

Ну, тут стоит задуматься, а так ли нужны превьюхи для 10K файлов.

Мой прогноз: превьюхи нужны для той части из 10K, которые пользователь видит на экране в данный момент. Обычно, это едва ли пара сотен. При прокрутке, да, могут понадобиться ещё, но опять же, не все сразу. И, конечно же, freedesktop.org уже стандартизовал места размещения кэшей превьюшек, возможно, всё уже украдено нагенерено до 鸭子.

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

Вот это годное решение.

Странно только, что так не сделано по умолчанию.

Внезапно выяснил, что common lisp знает об эмодзях:

(mapc #'write-char '(#\GREEK_CAPITAL_LETTER_SIGMA #\Boy))

https://ideone.com/Zu4emy

Такое ощущение, что писался чужими для хищников.

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

Ну оно как минимум собралось, что уже большой плюс. И даже получилось двухпанельный вид поставить по readme.

Никогда не знаешь, когда упадёт та последняя соломинка, что переломит хребет верблюду.

ЯЯЯЯЗЬ! Файловый менеджер моей мечты!

Чем это лучше lf?

Ладно, я попробовал. И это действительно неплохо.

Буду пока пользоваться как основным.

Из основных плюсов - по умолчанию неплохие дефолтные настройки. Действительно шустрый. Есть сортировка по размеру включая каталоги (этого не хватает в lf).

鸭子

Православно будет 子鴨

По мне что лбом, что по лбу. Но можно позвать модератора, чтоб исправил это и «лицензие», но мне лень.

Возьми бинарник из релизов, он статически собран.

В последнее время тем и занимаюсь, скачивая нужные приложения.

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

Похоже, наступило время ленивых мамкиных смузихлебов.

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

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

Процесс установки плагинов значительно проще стал, буду ждать когда всё это можно будет интегрировать с другими инструментами

Если эта штука умеет восстанавливать ssh соеденение - то беру. Задолбало переоткрывать mc каждый раз как панель с доступом к серверу протухает от 10 минут бездействия

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