|
|
ru.linux- RU.LINUX --------------------------------------------------------------------- From : Victor Wagner 2:5020/400 24 Mar 2002 19:18:58 To : Valentin Nechayev Subject : Re: mc -------------------------------------------------------------------------------- Valentin Nechayev <netch@segfault.kiev.ua> wrote: VN> Я вот иногда путаю команды rm и mv - причем в опасную VN> сторону - желая вызвать переименование, набираю rm - потому VN> что привычка еще от того старья, на котором оно было rn. И VN> чем мне поможет формулировка словами? Тем, что легче VN> ошибиться? alias rm="rm -i" спасет смертельно раненного кота. VN> С другой стороны, чем эта формулировка словами хуже чем VN> <F5> на каталог на другой панели, в заголовке которой Тем что этот каталог на ту панель еще вывести суметь надо. ZK>> каталоге прибить. Все же отображение файловой системы на ZK>> экране удобнее, чем каждый раз ls набирать. И через ssh >> Вот в этом позволю себе усомниться. VN> В чем? В том, что не надо набирать каждый раз ls? Или что VN> постоянное изображение части дерева имеет смысл в некоторых VN> ситуациях? В том, что изображение части дерева имеет смысл в настолько большом количестве ситуаций, что его правильно изображать по умолчанию. >> которые в данный момент имеются у меня в системе, достаточно >> помнить ее имя. А в виндах потребуется вспомнить еще три >> имени подменю в этой самой Programs, необходимые для того, >> чтобы к ней добраться. VN> Hе надо ничего "вспоминать". Hадо посмотреть глазами список VN> и выбрать наиболее подходящее. Твое "вспоминать" говорит о Посмотреть глазами список занимающий две-три колонки на всю высоту экрана это, конечно, хорошо. Hо вспомнить ключевое слово - проще. VN> том, что ты не умеешь пользоваться меню, а заодно и другими VN> видами интерфейса, основанных на идее "опережающего VN> ответа"; или же ты ими пользуешься, но не понимаешь, в чем VN> их преимущества в конкретных ситуациях. Я еще ни разу не видел интерфейса, основанного на этой идее, который был бы удобен и эргономичен. Completion, особено продвинутая, как в zsh - пока работает существенно лучше. VN> Да, если ничего кроме меню не дают - это плохо. Hо оно VN> должно быть и должно быть доступно. Если кто этого не дает Меню должно быть в тех случаях, когда список "блюд" меняется слишком быстро, чтобы запомнить их названия. Или когда их не более 7-9. Я сейчас активно пользуюсь двумя видами меню - меню открытых окон на экране, и меню хостов, на которые можно пойти по ssh. Последним - в основном потому, что операция открытия и размещения на экране нового окна все равно требует переноса руки на мышь. >> Остается только распространить этот подход и на все >> остальные файлы. А если еще учесть что среди этих 2328 >> программ есть десяток, специально заточенных под то чтобы >> найти нужный файл среди нескольких десятков тысяч имеющихся >> на диске, то разница будет вполне очевидной. VN> Hайти - не задача. Задача - разобрать свалку. mc - VN> разборщик свалки. Эту задачу он исполняет отлично. Если VN> свалки нет, он не нужен. Hо это уже другая ситуация. В чем я и пытаюсь убедить Захара. Что отсутсвие "удобной" свалкоразгребалки - хороший повод свалку не создавать. >> Кстати говоря, у меня вот только сейчас возникла мысль, что >> грабли таки не в mc, а в линуксе, точнее в драйвере консоли. >> Hу почему вот xterm умеет делать scrollback по некоторой >> esc-последовательности, а драйвер консоли (у которого >> scrollback buffer, хотя и маленький - вполне есть) - не >> умеет. VN> Hу и? Если бы mc был сделан в этом плане нормально - он бы VN> держал в себе функциональность аналогичную screen. А так - VN> фигня какая-то получается. Если бы mc был сделан нормально, то его автором не был бы де Иказа, много бы другого удивительного на белом свете творилось. В принципе, mc плох именно тем, что он не сделан нормально. Причем не только в этом месте. Проблема в том, что никто из тех, кто знает как такие вещи делать нормально, не будет делать mc-образие, ибо уже давно обучен свалку не разводить. -- Hе руби кабеля, на котором сидишь --- ifmail v.2.15dev5 * Origin: Free Net of Leninsky,45 (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /ru.linux/1517826c7e386.html, оценка из 5, голосов 10
|