» Плагины и настройки FAR часть 2

aar

Сам с таким возился, только иначе поступал - ls -R > ../ls.txt тогда в листинг не попадает сам ls.txt.

aar

Цитата:

Сколько же я мучился копированием по-одиночке: Ctrl+F, Alt+Ins, Ctrl+Ins...

Настоящие индейцы не читают help'ов
А ведь там русским/английским по синему про это написано...

naPmu3aH

Цитата:

Настоящие индейцы не читают help'ов

Это мне? Если так, то хэлп фара я прочитал давно, и всего мог не упомнить или чего-то забыть.

Ты же не станешь утверждать, что если закончил школу, то любой вопрос из школьной программы тебе по зубам?

Привет, всем!

У меня такой вопрос использую FAR v1.75 RC0 build 2479 из сторонних плагинов тока 7-zip v4.65 и Right Click Menu Activator v0.62 от 05.05.2005

Система Windows Vista SP1

Суть проблемы: при запуске ФАРа, появляются файловые панели, но всё как-бы подвисшее, работать нельзя, секунд через 5 всё проходит и ФАР нормально работает. Так происходит при каждом запуске ФАРа. Что это может быть?

С уважением...

bavb

Для начала стоит попробовать всё настроить и нажать Shift+F9 для сохранения настроек. Они похоже каждый раз заново применяются.

Far Manager 2.0.767 (SVN 2561): наконец-то баг в редакторе прибит (changlog) -


Цитата:

svs 08.02.2009 17:33:52 +0300 - build 767

1. Mantis#0000716: Один из режимов работает неправильно
(from DiRTy_GaRRy)

Осталось только прибить иной, более экзотический баг: при попытке просмотра хинта для файлов Оpen Office процесс far.exe завершается аварийно. Баг наблюдается на любой сборке для Win32 при просмотре хинта для шаблонов и самих документов Open Office. Расширения Open Office такой ошибки не вызывают. Последней подвергалась проверке официальная сборка 2.0.765. Которая работала только с одним плугином FarHints. Иные плугины для проверки специально не ставились.

Патч для ProcList взятый с Mantis#0000729 сбоит. Протестировал все возможные варианты, на сборках Far Manager от 2.0.757 до 2.0.768. Сбой воспроизводится устойчиво. Тестовый плугин в виде GCC/MS VC++ 2008 сборок, исходники, скрин с сообщение об ошибке, анализ ошибки прилагается: ProcList.rar. Данная ошибка во всех вариантах сборок использованных для тестирования воспроизводится устойчиво, возможно где-то ошибся, возможно ошибка в патче. Прошу кто по опытней глянуть... Для проверки использовалась простая структура - только сам Far.exe + *.lng + *.hlf + тестируемый плугин. Больше ничего не подключалось для чистоты эксперимента. ОС WinXP SP3.

Проверил снова плугин FarHints (взял FarHints_dll_child.rar) на сборках 2.0.765 - 2.0.769 (в т.ч. новейшей - 2.0.769.2565 скомпилированной с SVN в 18:12:56 11.0.2008 Msk) - ошибка аварийного завершения Far при попытке считывания хинта документов Open Office сохраняется и с данной версией DLL. Методика проверки стандартная Far запускается только с одним проверяемым плугином, остальные физически удалены, пользовательские плугины не используются.

народ, подскажите немного с макросами.
Как в макросе выполнить перебор выделенных файлов на файловой панели или временной панели? Пробовал с помощью selmacro - с обычной панелью работает, а с временной нет. В SDK похоже нет возможности работы с выделенными файлами?

kondrik
а что именно тебе с ними надо сделать?
может, удобнее и проще будет это через Ctrl+G (Apply command) реализовать?

sabio
это вряд ли поможет, т.к. список необходимо обработать. Хотя этот способ запомню. Спасибо.

всем знающим
Лучше подскажите можно как-то через пользовательское меню (которое вызывается по F2) вызвать файл на редактирование и в этом файле выполнить макрос. Файл для редактирования удается открыть, но макрос не вызывается

Ну вот, одно чиним, другое ломаем. Far SVN 2570 в gcc не собирается с ошибкой:

Цитата:

clipboard.cpp:236: warning: suggest explicit braces to avoid ambiguous 'else'
compiling cmdline.cpp
compiling cmem.cpp
compiling config.cpp
compiling constitle.cpp
compiling copy.cpp
compiling ctrlobj.cpp
compiling cvtname.cpp
compiling delete.cpp
compiling dialog.cpp
compiling dizlist.cpp
compiling dlgedit.cpp
compiling edit.cpp
compiling editor.cpp
compiling eject.cpp
compiling execute.cpp
execute.cpp: In function 'int Execute(const wchar_t*, int, int, int, int)':
execute.cpp:752: error: 'SEE_MASK_NOZONECHECKS' was not declared in this scope
make[1]: *** [Release.32.gcc/obj/execute.o] Error 1
make[1]: Leaving directory `/с/Temp/fardev/unicode_far'
make: *** [all] Error 2

Придётся искать где ошибка.

СПАСИБО DrKnS выручил!

Исправлено в сборке 772 (SVN 2572), огромное спасибо за это DrKnS. А я уже было стал DVD с VC++ 2008 у ребят просить - компиллер от Микрософт курочить. Полезно иногда смотреть Агату Кристи - пока смотришь кино - проблемы решаются.

kondrik

Думаю, что можно использовать сценарий в котором вызывать макродвижок. Но, это просто сырая идея. Мне кажется, что проще использовать ту же связку cygwin + bash и в ней отрабатывать любые sh скрипты.

kondrik

Цитата:

список необходимо обработать

тогда в этот самый Ctrl+G можно добавить echo в начало команды и >>x.bat в конец
получится что-то вроде:
echo ren "!.!" "!.old">>x.bat

после запуска будет создан файл x.bat со строчками вида:
ren "file1.txt" "file1.old"
ren "file2.txt" "file2.old"

дальше делаем с ним, что заблагорассудится (та самая "обработка списка") и запускаем на выполнение

sabio

Или использовать тот же плугин FileList с его настраиваемым выводом. В общем решений масса, только надо поискать.

Протестировал собранные из новых исходников плугины align, proclist и network - всё работает, Process Explorer показывает факт освобождения ОЗУ (уменьшается размер занятого Far ОЗУ) после завершения операций в плугинах. ProcList более не "валит" Far.exe - проверялось просто - открывали любой процесс на просмотр на панели ProcLis, смотрели его "начинку" по F3 и при выходе из плугина, например переходом cd ../ процесс Far.exe завершался аварийно. Сейчас данное явление не наблюдается.

Для тестирования вновь собрал целиком всю сборку Far 2.0.778.2588 + 16 стандартных плугинов. Вроде пока проблем не вылезло, и что-то подсказывает мне что они устранены.

Victor_VG
А где можно скачать твое творение (778 билд)? На mylivepage ничего нет.

Barabashka
для x86: http://www.farmanager.com/nightly.php
для x64: http://xvidvideo.ru/

Victor_VG
Какие-то экзотические глюки Вы ищите. Например, меня больше напрягает, что при просмотре файла в UTF-8 комбинация Ctrl-PgDown (переход в конец текста) не корректно работает. Или, что автораспознавание кодировок cp866/cp1251/UTF8/Unicode не предусмотрено. Или некорректная работа с BOM в UTF-8 файлах и т.д. В общем, Фар 2 еще сырая-пресырая альфа.

Barabashka

Здесь, через Анонсы, как обычно. Мелкий баг пришлось подправить - как выяснилось, если в качестве пути на панели мы даём букву диска, то начиная с версии 2.0.775 надо давать её в виде пути к корневому каталогу, иначе посредине верхней рамки панели будет "дырка", которая исчезнет после перехода на любой диск или в каталог. Т.е. в настройках путей в блоке параметров [HKCU\Software\Far2\Layout] запись вида C: не допустима, там надо писать C:\. А у меня в параметрах раньше (до сборки 2.0.773) стоял путь в виде C: в качестве стандартного пути после установки для левой и правой панелей. Ну, теперь я с этим разобрался, и объяснил где может возникать ошибка - этом ведь и моя вина есть, и не малая.

Код: Ошибка выглядит примерно так:

||====== C:\ =========|====== =========||

вместо:

||====== C:\ ========|======= C:\ =========||

Victor_VG

Цитата:

да и переход в конец текста по Ctrl+End меня как-то вообще не напрягает - пальцы сами кнопки нажимают.

Так в том-то и дело, что он не переходит ни по Ctrl+End ни по End ни по Ctrl+PgDn. Проверяется элеметнарно - открыть файл по F3, нажать Shift-F8 - выбрать UTF-8 (кстати, замахивает каждый раз это делать - это по поводу автоопределения кодировок, даже блокнот умеет отличать ANSI/UTF8/Unicode), в режиме Unwrap (F2) при нажатии Ctrl+End или End или Ctrl+PgDn переходит совсем не в конец файла.


Цитата:

И насчёт "сырая-пресырая" не соглашусь абсолютно - во многом, несмотря на частые изменения кода, и ряд пожеланий по появлению новых функций версия alpha 2.0 намного опередила RC 1.75, и ябы пожалуй их статус даже поменял на статусы 2.0 RC0 и 1.75 Beta, а вот та во многих отношениях несмотря на усилия ребят 1.75 просто "не успевает за временем". Альтернативы?

Альтернатива и есть v1.75. На ней, в основном, и сижу. Пока что, реально работать в v2 не удобно - в основном из-за низкой функциональности и забагованности viewer-а. Например, мне часто приходится работать с файлами в украинской кодировке RUSCII (это ГОСТ украинский) ее в винде нет - и поэтому в v2 с ней вообще нельзя работать, в отличии от 1.75. Тот же viewer в v2 до сих пор не знает что у файлов в кодировке UTF-8 может быть BOM и карячит первые символы. И это, вместе с глючащим переходом в конец файла и отсутствием автоопределения кодировки, только те лежащие на на поверхности проблемы, на которые я наткнулся в течении получаса работы в v2 (повторюсь, сижу в 1.75 потому дальше не копал).

Ajaja

Насчёт забагованности не согласен, пользуюсь именно 2.0. По функциональности лично меня она устраивает. А вот что мне не по душе, так это ошибка в плугине FarHints - только что пробовал новый вариант. На шаблонах OOo 3.0.1 из-за него Far.exe по прежнему завершается аварийно. Обидно.

Ajaja

Цитата:

Тот же viewer в v2 до сих пор не знает что у файлов в кодировке UTF-8 может быть BOM и карячит первые символы

Да, может. Но тут надо сказать, что BOM в случае UTF-8 никак не влияет на порядок байт, потому часто и не добавляется. Но обрабатывать этот случай, конечно, необходимо.

А так да, пока что вьювер и редактор имеют кучу проблем с юникодом вдобавок к косметическим глюкам. Например редактор открывает файл из одной строчки:
language=arc.english.txt
в виде строки китайских иероглифов Что интересно, вьювер отрабатывает нормально.

Плюс при просмотре юникодных текстовых файлов "сбивается" кодировка и вместо "нестандартных" букв получаем квадратики (F3 -> стрелка курсора "вправо" -> видим баг).

При редактировании кодировка сбивается на квадратики при удалении первого же юникодного символа.

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

В общем, там еще править и править.

Баг с плугином FarHints требует вмешательства разработчика плугина - его исходники закрыты, и кроме автора ошибку никто не исправит, даже с учётом обновления FarHints для FAR2 756+ и последних ConEmu (новая FarHints.dll V2 выложенная 21.02.2009) - всё равно, при попытке получить хинт документов OpenOffice на секунду видна иконка OOo, и далее процесс Far.exe завершается аварийно, даже отладчик не успевает среагировать, хотя причина сбоя в том, что именно плугин FarHints записывает в одной из своих процедур адрес перехода 0x00000000 и осуществляет по нему переход с возвратом в процесс Far.exe по тому же адресу 0x0000000. Данный неверный переход формирует код FarHins.dll. Ещё раз напоминаю ему об этом явлении. Готов помочь в его проверке.

P.S.

Данный баг уже достал, а автор на него ноль внимания. Автора его "аналога" по степени глючности для Total Commader просто забыли, идею плугина реализовали десятки других людей, а он сам сейчас всех просит попробовать его новые разработки и напоминает о своих заслугах.

DrKnS

Цитата:

drkns 21.02.2009 14:56:50 +0200 - build 779

1. Автоопределение кодовой страницы во вьювере, аналогичное редакторному.

2. В PrepareDiskPath криво обрабатывались отностительные пути вида c: или d:dir

3. параметр Layout\PassiveFolder удалён, т.к. есть Panel\<Left|Right>\<Folder|Focus>

СПАСИБО! Ещё бы Максим свои ошибки исправил. - было бы прекрасно. Всегда рад тебе помочь чем могу. Сейчас буду проверять что у тебя получилось, но зная тебя уверен что всё будет работать отлично.

Цитата:

1. Автоопределение кодовой страницы во вьювере, аналогичное редакторному

Учитывае написанное мной чуть выше:

Цитата:

Например редактор открывает файл из одной строчки:
language=arc.english.txt
в виде строки китайских иероглифов Что интересно, вьювер отрабатывает нормально

не уверен, радоваться или пока подождать.

Benchmark

А мы с тобой посмотрим тот 2.0.779.2590.1 что скомпилировал сейчас. Выложил отдельно gcc вариант, используем его как тестовый. Надо бы заодно и FarHinst на нём лишний раз проверить. Не нравятся мне эти ошибки с переходом по адресу 0х00000000. Как будто где-то ошибка не в плугине, а в библиотеках самого компилятора которые он линкует. Тут серьёзно надо копаться. Чувствую один Максим эту задачу вряд ли вытянет, помочь надо парню всем вместе.

Цитата:

drkns 21.02.2009 14:56:50 +0200 - build 779
1. Автоопределение кодовой страницы во вьювере, аналогичное редакторному.

Спасибо. Собрал, немного потестировал. Как я понял, работает как раз по BOM метке. Заодно и UTF-8 сигнатуру стал понимать.
Но просмотрщик продолжает глючить с этой злосчастной UTF-8. Как оказалось, End - это еще цветочки. Например, совсем криво работает Up (стрелка вверх) - текст превращает в мустор. PgUp/PgDn тоже глючит. Немного покопал, в общем, похоже там с функцией Viewer::Up() что-то не то.

Ajaja

А ты в чём собираешь, коли не секрет? Просто у меня и VC++ 9 и gcc есть. Да и голове идея крутится - попробовать собрать в gcc с заданием опций формирования многопроцессорного кода, хотя и прекрасно понимаю что с одно процессорным алгоритмом этот опыт - пустая трата времени и сил. Заодно и новый ConMan 2.34.2 глянул - как при попытке сравнения собранный в gcc плугин Advanced Compare "ронял" Far из-за ошибки ConMan в блоке управления памятью дочернего процесса, так и на Far 2.0.779.2590 + ConMan 2.34.2 ничего не изменилось. А жаль, похоже Макс увлечён только собственной новой "игрушкой", а исправлять ошибки которые уже найдены даже не собирается.

Victor_VG

Цитата:

А ты в чём собираешь, коли не секрет?

VS 2008 SP1 полная (Team System).
Собираю стандартно (только для x86, т.к. x64 мне ни к чему):
nmake -f makefile_vc USE_VC9=1
и плагины:
nmake -f makefile_all_vc WIDE=1


Добавлено:
Покопался немного студийным дебагером по коду viewer.cpp. В общем, для нормальной поддержки проосмотрщиком UTF-8, у которой переменное количество байтов на символ, там надо кучу всего править. Так что, это даже не глюк, просто вьювер еще сильно недоработан. Остается только ждать, когда у разработчиков дойдут до него руки.

Ajaja

Понял. А я комбинацией - всё кроме EMenu в gcc-4.3.2-tdm2, а его в студии 9 про, вернее от неё у меня один с++ стоит - остальное я в BSD делаю - привычнее. Для сборки одного плугина "огрызка" хватает.

Могу порадовать - вроде ребята смогли сделать нечто интересное:

Цитата:

drkns 22.02.2009 02:41:43 +0200 - build 782

1. Дополним vc-проект и починим мейки.

warp 22.02.2009 02:11:00 +0300 - build 781

1. Бонус-тайм. Если повезет может определяться все, что умеет определять автодетектор кодировок от
Mozilla. Побочные эффекты в наличии.

До починки make-ов собрать можно будет только проектом!

2. Ну и диалог сохранения файла поправим в размерах.

drkns 21.02.2009 22:13:13 +0200 - build 780

1. UTF8 может определяться и без наличия сигнатуры (если повезёт

2. В диалог сохранения добавлена опция, определяющая, надо ли писать в файл сигнатуру.

3. Mantis#0000706: opening very short file gives messed up encoding
Ужесточён алгоритм определения UTF16 LE/BE. Пусть уж лучше будет ложный ascii, чем ложный уникод.

Сейчас EMenu соберу и буду пробовать. А Максим - увлёкся игрушкой и на всё плевать.

Цитата:

warp 22.02.2009 02:11:00 +0300 - build 781
1. Бонус-тайм. Если повезет может определяться все, что умеет определять автодетектор кодировок от Mozilla. Побочные эффекты в наличии.

Работает! Причем и в редакторе и в просмотрщике. Честь и хвала разработчикам - реактивные ребята (и когда только успели!?) . Неприятных побочных эффектов пока не нашел. Только, почему-то, автодетектор не работает при переходе на другой файл уже из самого просмотрщика (numpad-овским плюсом/минусом) - кодировка автоматом не переключается.

Ajaja

Этот алгоритм - он и в Gecko - ядре Mozilla если кодировка "скинута", т.е. тэг <meta http-equiv="Content-Type" content="text/html; charset= ... "> отсутствует иногда в такой ситуации не точно сработает. Остальное и я поглядел - работает, вот теперь можно сказать что общий труд увенчался успехом. А как я и сказал, Maximus5 увлёкся новой игрушкой в виде ConEmu, а к сбойному FarHints охладел. А ведь кроме него его исправить больше некому. Да похоже ему это и не нужно - написал и забросил.

О... уже 2.0.784.2603

Цитата:

t-rex 22.02.2009 12:12:26 +0200 - build 784

1. Добавил в nsUniversalDetectorEx.h конвертацию имён в nCodePage для всех поддерживаемых фаром таблиц которые может вернуть мозиловский детектор.

2. Удалил prmem.c из корня ибо он есть и в UCD. Надо проект обновить.

drkns 22.02.2009 11:39:41 +0200 - build 783

1. Криво работала вставка вертикальных блоков из буфера обмена.

Компилим. Во всяком случае заодно уже и NSIS обновил до 2.44 - ночью письмо пришло с sf.net.

А в одном месте баг-то имеется, и любопытный - в структуре VERSION_INFO имена полей выводятся "кракозябрами" если интерфейс Far переключён на русский язык:

Данная ошибка появилась после 2.0.778. Видимо надо копать в связке "враппер-мозиловский детектор" - там неверно передаётся кодировка, во всяком случае у меня на подозрении /unicode_far/wrap.cpp - предполагаю, что ошибка в нём. Во всяком случае, при переключении на английский язык интерфейса Far данное явление исчезает. Проявление ошибки не зависит от языка справочной системы Far - на её проявление влияет исключительно только язык интерфейса (панелей).