Немного по обсуждениям из предыдущих тем об обновлениях:

• Контроль над файловыми операциями по прежнему несколько ограничен, но улучшения в этом плане есть и будут включены в следующую версию.
• С поддержкой мыши всё таки не вышло, попробую ещё раз, но насколько помню события от мыши как-то странно передавались приложению терминалом либо ncurses. Настолько странно, что затрудняло использование.
• Несколько увеличена скорость работы с каталогами, содержащими большое количество файлов. Это не stat() виноват, а сортировка и фильтрация по именам файлов.

Что для сборки из сырцов доставить надо?

добавились Ctrl-X-сочетания в режиме командной строки для вставки частей имён/путей файлов и значений фильтров (вроде Ctrl-R в Vim);
большинство потенциально длительных операций (:find, :copy и т.д.) теперь могут быть отменены комбинацией Ctrl-C;

Иногда не хватало. Спасибо.

Только пакет с ncursesw-dev. Название пакета для систем, основанных на Debian (так как там чаще всего сложности с поиском нужного пакета): libncursesw5-dev.

Спасибо, попробую. А то бывает собираешь прогу и продираешься через выхлоп configure.

Не нужно, есть ranger.

Спасибо за «авторитетное» мнение. Пусть каждый сам решает, что ему использовать. Я сам какое-то время пользовался ranger'ом, но vifm, как по мне, удобнее.

удобнее

Молодец, ключевое слово. Удобных программ вообще, по-факту, нет. И рулят только те, которые легко и без костылей кастомизируются.

Это лучше уже существующих аналогов?

Хотел написать: Чем это лучше уже существующих аналогов?

Хочу такой же, только графический.

jvifm, вероятно, был попыткой сделать что-то в этом роде. Да и первоначальная версия vifm была графической (Vide), но даже не знаю где можно найти исходный код.

Эх, да что же люди мыслят так как им навязывают маркетологи... Я ведь не продаю товар, мне нет особого смысла его расхваливать. А проводить абсолютно нерелевантные сравнения как-то не хочеться, всё равно с чьей-то точки зрения выводы будут ошибочными.

В итоге говорю своё мнение. vifm это файловый менеджер близкий по духу Vim, и смысл не в том чтобы превзойти кого-то или сделать что-то лучшее, а чтобы предоставить альтернативу для людей, привыкших к подходам, принятым в Vim. Из этого косвенно получается такое преимущество: пользователи Vim могут пользоваться vifm практически без какого-либо обучения. Ещё раз: vifm не является заменой всех существующих файловых менеджеров для всех пользователей, это реализация файлового менеджера для пользователей Vim'а (точнее, одна из).

И вообще, лучше один раз увидеть, чем сто раз услышать. Проще поставить и попробовать. Или, если хочеться сперва именно увидеть, а не попробовать, то есть видео-обзор.

Удалось найти Vide, который на GTK, вот здесь.

Спасибо. А 9999 ebuild в древо пробовали пропихнуть?

Как изменить порядок отображаемых файлов/директорий? Например, не по имени файлов, а по modified date

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

Есть несколько способов:

• Через диалог: :sort
• Группируя каталоги: :set sort=mdate
• Не группируя каталоги: :set sort=mtime,type

Если не сложно поинтересуйтесь. Вроде не-live ебилды обновляются регулярно, а live почему-то не добавиляют. http://packages.gentoo.org/package/app-misc/vifm?arches=prefix

*vifm-0.7.6 (18 Jan 2014)

а чтобы предоставить альтернативу для людей, привыкших к подходам, принятым в Vim

ranger кроет его по всем пунктам, такие дела. Собственно это и отражается в популярности.

Какое мне дело, чем ты пользуешься? Наставить на путь истинный по преуменьшению велосипедов в этом не лучшем из миров.

Жду ответа. А по поводу не-live билдов, может теперь и они не будут обновляться.

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

MiniRoboDancer, больше из разряда «just for fun», но залил на GitHub версию vide, которая собирается и частично работает (падает местами, но какие-то действия всё же делает).

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

Не пробовал

Тогда руки не дошли, а теперь некому его поддерживать. У меня больше нет Gentoo для проверки работоспособности.

А отображение нелатинских имён файлов починили?

Давно уже.

Если имеешь в виду русские буквы в windows. А вот иероглифы до сих пор правильно показывать не умеет, они вылезают на другую панель.

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

Судя по названию, им можно пищать и портить.

Да мне как-то не особо мешало. Доберусь до дома, сообщу подробнее.

Я имею в виду русские буквы в Linux в UTF-8.

Правильно говорить (в более узком смысле): буквы русского алфавита, если не имеется в виду кириллица в целом, т.к. «русских букв» не существует.

С этим проблем быть не должно.

Отвечаю в терминах исходного сообщения.

Да, всё верно, не то чтобы совсем вылазит, но вот разделительную линию портит курсор.

Спасибо, исправил.

Забавная проблема, опишу, вдруг кто-то столкнётся: ncurses и/или терминал не выводит в середину символа, занимающего больше одного знакоместа, а насильно рисует справа, нарушая при этом границы.

Причина, по которой у меня просто так не проявлялось, вот эта настройка:

" default set of view columns
windo set viewcolumns=-{name}..,6{}.

Забавная проблема, опишу, вдруг кто-то столкнётся: ncurses и/или терминал не выводит в середину символа, занимающего больше одного знакоместа, а насильно рисует справа, нарушая при этом границы.

Может, стоит зарепортить это в список рассылки ncurses?

Может, стоит зарепортить это в список рассылки ncurses?

Это не бага ncurses. Это проблема сабжа, который неправильно считает ширину строк.

Собирается и работает. Надеюсь найдется майтейнер.

vifm является двухпанельным консольным файловым менеджером с Vi-подобным модальным управлением

При попытке выйти из ФМ пользователь рискует поудалять некоторое количество ненужных файлов?

В том то и дело, что с длиной строк всё правильно. При этом, если вторая колонка должна начаться посреди широкого символа, то позиция вывода неявно смещается на один символ вправо. Это делает не vifm, все расчитанные позиции вывода правильные.

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

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

В том то и дело, что с длиной строк всё правильно.

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

То есть, не выводить широкий символ программой это не вариант?

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

Тут ещё сильно влияет способ вывода. Если строки целиком выводить, то одно, а частями (для упрощения работы с атрибутами и для того, чтобы избежать задания атрибута для каждого из выводимых символов), выходит другое.

Но это не совсем тот уровень, на котором это удобно делать.

Curses это всего лишь тонкая абстракция над терминалами, легкой жизни никто не обещал.

Раньше была возможность иметь только один пэйн с помощью опции USE_ONE_WINDOW=0. Как это сделать в свежей версии?

Добавлением следующей команды в vifmrc:

:only

" use single pane more for narrow window and two pane mode for wide window
if &columns < 100
    only
else
    vsplit
endif