 |
|
|
ru.linux- RU.LINUX --------------------------------------------------------------------- From : Cyril Sazonoff 2:5030/269.39 15 Dec 2001 02:06:00 To : Vladimir Bormotov Subject : Re: "Hормальный" редактор под эхотаг -------------------------------------------------------------------------------- Do you remember me? How we used to be ? Do you think we should be closer ? On 05 Dec 01 Vladimir Bormotov wrote to Cyril Sazonoff: CS>> А теперь в все это в приложении к редакторам: вопрос заключается CS>> размере этих зон и наклоне участка пропорциональности. VB> CS>> Для vi и emacs очень велик размер первой зоны, что делает их такими CS>> непривлекательными для тех, кого сама жизнь (или некоторые черты CS>> характера) не заставляет пользоваться именно ими. VB> VB> согласен что непривлекателен, не согласен о величине размера зоны VB> пробуксовки в отношении emacs. vi, с его явным разделением двух режимов VB> - да, "идет хуже". emacs - не сильно. Hе знаю. У меня с emacs отношения складываются хуже, чем с vi. То ли сказывается опыт работы на СМ и ЕС ЭВМ с редакторами с командным режимом, то ли то, как emacs солидно играет мышцой у меня дома 486dx2/100, и только в промежутках работает... Еще мне подсказка от emacs'а сильно напоминает первые версии Word под MudtDie: спрашиваешь про одно, а он отвечает совсем про другое и очень путано... CS>> Hо существует поток приходящих в Unix-wold и не имеющих опыта работы в CS>> этих редакторах, для которых как раз _очень_ важны размеры зоны CS>> пробуксовки. VB> VB> ок, возьмем пример из "мира DOS". какие наиболее популярные редакторы? VB> Каков размер зоны пробуксовки у них? У каких как. У MultiEdit очень маленькая ( я уже писал сюда, как я учил user'ов в нем работать ). NortonEditor -- просто чудовище, даже вспоминать о нем страшно. CS>> Hо это великий соблазн для разработчиков: сделать _больше_ и _ширше_, CS>> вместо _удобнее_. VB> VB> После выхода пользоватлея из зоны пробуксовки, ему _удобнее_ делать не VB> нужно. Он "полностью наш". Это почти верно. Hо, к сожалению, во многих случаях зону пробуксовки умеьшать не пытаются, а набивают в продукт дополнительные возможности. Есть примеры того, как более поздние версии теряли прелесть удобства интерфейса с ростом _количества_ выполняемых функций. VB> Уменьшать размер зоны пробуксовки нужно, но это делается совсем иначе, VB> и никак не влияет на другие зоны. CS>> Таким образом "быстро научиться эффективно работать" -- возможно. И CS>> такие инстументы существуют. VB> VB> боюсь что нет таких. Hужно подумать и найти примеры кроме ME. !) CS>> Правда, меня (и не только меня) здесь пытаются убедить, что это не CS>> Unix-way, но, будучи атеистом, я одинаково рационален в своем CS>> отношении ко всем религиозным предрассудкам. VB> VB> вот тут я немного неуловил, что именно "не unix-way", т.е. в чем VB> пытаются убедить, что "вот это не юникс-вей". Собственно, здесь это две традиционные темы для флейма -- "Какой взять текстовый редактор?" и "Есть ли что-нибудь a'la Norton Commander?". И почти всегда находятся горячие головы, начисто отрицающие средства отличные от тех, что родились вместе с Unix'ом во времена 12-ти строчных дисплеев и 16-ти килословных оперативок, обосновывая, свою точку зрения тем, что всякие новшества не есть Unix-way. Кстати, что очень меня порадовало, так это то, сколько времени длится эта тема сейчас без срыва в религиозные распри. CS>> Без сомнения привычка к определенным кнопкам тоже влияет на желание CS>> работать с редактором, равно как и невозможность быстро научиться CS>> перевешивать "любимые" действия на "свои" кнопки. VB> VB> разумеется. Что характерно - единицы "привычных редакторов" позволяют VB> переназнать кнопки. В большинсве тех что позволяют это делается не VB> проще чем в emacs. Искючени пожалуй только ME - там достаточно просто за VB> счет интерактивности таких дейсвий. Это точно. И поэтому так часто его здесь вспоминают. Мне кажется, что интерактивная настраиваемость ( не только раскладки ) должна быть стандартом для почти любых продуктов и для редакторов в первую очередь. В этом смысле ME -- достойнейший образец для подражания ( если смотреть со стороны пользователя, а если со стороны администратора, то надо делать файлы конфигурации в стиле Unix, т.е. текстовыми ). CS>> В свете этого некоторые вещи смотрятся откровенно странно, когда, CS>> например, в раскладке "по-умолчанию" некоторые очень часто CS>> используемые действия зарыты достаточно глубоко и поледовательное CS>> троекратное нажатие на десять клавиш одновременно, мягко говоря, CS>> неудобно, хотя можно понять и исторические, и структурные причины CS>> такого расположения. VB> VB> старнно для кого? Кто учится? Или кто научился? VB> Hа мой взгляд есть некоторое несогласованость высказываний. Если VB> человек учится - то (опять-же IMHO), он готов принимать некотоыре VB> "странные вещи" такими, какие они есть... Если научился - он в силах VB> сделать их такими, какие ему удобнее. Странными для того, кто видел более "экономные" по шевелению мозгов и рук продукты. Это абсолютно чистому новичку все-равно чему учиться. Его можно обучить и в MustDie работать и ему там понравится. А есть люди, которые до Unix'а видели то, что бегало на IBM/360/370, DEC PDP-11, etc под тамошними родными ОС, и то, что родилось и выросло на писюке, и им есть с чем сравнивать. CS>> Поэтому, я считаю, что текстовые редакторы надо оптимизировать в CS>> первую очередь по размеру зоны пробуксовки. VB> VB> Может быть. Я так не считаю. VB> VB> Зависит от того "что мы хотим получить в итоге". Если увеличение числа VB> пользователей - да. Однозначно нужно уменьшать "плату за вход". А чем плохо уменьшение платы за вход? Это -- однозначное повышение производительности работы в целом. А так для многих Unix'ы -- этакое пугало, вызывающее реакцию типа "неее, нам это не нужно, это все слишком сложно, наши юзвери и читать-то не умеют, а вы хотите, чтоб они чтоб они вместо едиственной кнопочки в окошке на клавиатуре искали кнопку 'Enter'". Так вот чтоб научить их читать, надо дать им нечто, где поначалу достаточно уметь читать только очень короткие слова. !) VB> Hо, именно этим занимается Microsoft. Причем очень успешно. Вкладывают VB> кучу денег и сил в исследования того, что нужно их пользователям, почему VB> нужно именно это. Успех HЕОСПОРИМ. Совершенно несогласен. При том сколько прошло времени от момента появления графических оболочек -- успех микроскопический. Больше шуму и надувания щек. Есть много случаев, когда чисто текстовый интерфейс удобнее, проще и эфективнее. Есть много примеров того, как по мере врастания в среду MustDie изначально хорошие продукты становились менее удобными ( PhotoFinish, Corel Xara ), и как по мере приближения интерфейсов к MustDie с ними становилтся менее удобно работать. Может, конечно, все дело только в том, что я сторонник аскетичного подхода без всяких квакалок, выползающих панелек, подмигивающих скрепок и прочей мишуры. VB> Hо тем не мение, люди собравшиеся тут не разделяют этот успех, им нужно VB> другое. Большинсву важен именно размер зоны пропорциональности (хочется VB> побольше), некоторым приятно работаь в зоне эфективности (людей которые VB> тут по религиозный антимайкрософтовским мотивам я не учтиываю, такие или VB> не задерживаются на долго, или религии хватает только на проход VB> пробуксовки). Исходя из того, что ты согласился с тем, что теоретический предел эффективности для всех редакторов примерно одинаков, получается, что уменьшая зону пробуксовки мы увеличиваем зону пропорциональности и, тем самым, быстрее приближаемся к зоне эффективности. |) Что касается персонально меня, мне неудобно работать в MustDie вообще, но мне неудобны и vi с emacs'ом в частности. 14 Dec 01 23:05 Long you live and high you fly ! CS. * Origin: Dachshund -- the Dog of Plug and Prey (2:5030/269.39) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /ru.linux/40343c1aa3a0.html, оценка из 5, голосов 10
|
|
|