[flame] редактор vs vim vs command line [re: посоветуйте free-редакто]

Dimon89

А почему vim ещё не посоветовали?
Ты знаешь, у меня тут вертелась в голове мысль написать простенький тест на основные действия с текстом, которые приходится делать, после чего выдать этот тест многоопытному пользователю vim'а (который убил годы на его освоение) и обычному пользователю npp/jEdit. Что-то мне подсказывает, что первый если и закончит раньше, то очень и очень ненамного...

okis

написать простенький тест на основные действия с текстом
напиши, но хотелось бы, чтобы он был непредвзятым. предлагаю также присоединиться к тесту пользователям emacs.
сравнить сложно, т.к. у участников, например, различается скорость топтания клавиатуры. а считать тычки сложно, т.к., например, РВ есть и в npp и в виме, а опыт использования разный. Сложное РВ на автозамену я вряд ли с первого раза напишу, что там, что там.
Подумал тут, что интересно также рассмотреть несколько юз кейсов работы с файлами, и сравнить затраты на выполнение через некоторый гуй, через OFM (например, far или mc) и шелл.

Dimon89

напиши, но хотелось бы, чтобы он был непредвзятым. предлагаю также присоединиться к тесту пользователям emacs.сравнить сложно, т.к. у участников, например, различается скорость топтания клавиатуры.
Не набора текста, а действий с текстами. Например, такой:
открыть все тексты из конкретной папки, перевести их все в Proper Case, подсчитать все вхождения "and" (case-sensitive) и вернуть всё как было.

tokuchu

открыть все тексты из конкретной папки, перевести их все в Proper Case, подсчитать все вхождения "and" (case-sensitive) и вернуть всё как было.
Для этого не нужен текстовый редактор ведь. :confused:

Dimon89

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

tokuchu

Альтернатива для такого действия - написание regexp-запросов, что потребует всяко больше времени для небольшого числа файлов.
Наверное всё же не больше времени, чем в редакторе елозить?

apl13

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

apl13

перевести их все в Proper Case, подсчитать все вхождения "and" (case-sensitive)
echo 0

apl13

Или ты об этом?
cat $FOLDERNAME/* | sed 's/\<./\u&/g' | awk '{n += gsub("and", "")} END {print n}'

Dimon89

Или ты об этом?
Я, к сожалению, не понимаю синтаксиса той строки, которую ты написал. Задача состояла в том, чтобы посчитать число вхождений "and" в слова, не учитывая слова, которые с него начинаются (например, собственно слово "and").

Dimon89

Наверное всё же не больше времени, чем в редакторе елозить?
Рядовому пользователю придётся потратить часы, если не дни и недели, чтобы банально осознать, что такое regexp и как им пользоваться. Вопрос в том, сколько времени на это надо потратить, чтобы их использование стало настолько выгоднее. С vim ситуация полностью аналогичная.
Визуальный интерфейс осваивается на порядки быстрее консольного, не требует заучивания тысяч сочетаний клавиш и лазания по мануалам для выполнения простейших действий. С этим ты, надеюсь, спорить не будешь?

okis

расскажи, как такая задача решается в визуальном интерфейсе

Dasar

открыть все тексты из конкретной папки, перевести их все в Proper Case, подсчитать все вхождения "and" (case-sensitive) и вернуть всё как было.
(current-directory.file-s.text.word-s.to-lower[and]).count

okis

это на каком языке?

Dasar

q#
ps
но это я пока развлекаюсь сам с собой на досуге

hwh2010

Ты знаешь, у меня тут вертелась в голове мысль написать простенький тест на основные действия с текстом, которые приходится делать, после чего выдать этот тест многоопытному пользователю vim'а
безусловно, всякие автоматизируемые действия юзеры вима (и просто юзеры юникс-подобных систем) сделают быстрее. Именно за счёт знания регекспов и прочих седов/авков. Начиная с 30 строчек исходных данных например.
Поэтому тест должен быть слабо автоматизируемым.
Например, такой: есть текст
необходимо:
1) переставить в каждом предложении слова так, чтобы подлежащее было перед сказуемым,
2) все пары "имя-фамилия" записать именно в таком порядке,
3) в имени и фамилии первую букву сделать большой
4) в конце каждого предложения, описывающего северную природу, поставить слово "однако".
5) если какие-то два предложения стоят рядом и последнее слово первого из них с точностью до формы совпадает с первым словом последнего — заменить его на соответствующее местоимение.
Или что-то более тупое: есть список существительных, разделить его на животных, мебель и одежду.

Dimon89

(current-directory.file-s.text.word-s.to-lower[and]).count
Не сработает. Он же всё в LowerCase переведет, и посчитает в том числе слова, начинающиеся с "and"

Dasar

расскажи, как такая задача решается в визуальном интерфейсе
вот эта штука в визуальном интерфейсе достаточно легко представляется и набирается
(current-directory.file-s.text.word-s.to-lower[and]).count
фиксируем точку отсчета, далее последовательно несколько раз навигируемся по модели, добавляем преобразование, вводим фильтр, и выбираем тип агрегации

Dimon89

расскажи, как такая задача решается в визуальном интерфейсе
1) Открыть файлы в файловом менеджере или через меню редактора.
2) Menu -> Characters -> Proper Case (или любой другой вариант, например "Sentence case" - это как будете решать через regexp-ы?)
3) Menu -> Find -> Count
Новичок сделает за 6 кликов. Продвинутый пользователь за пару сочетаний клавиш. Если вдруг забыл - в меню напротив каждого пункта подписано.

okis

И повторить для каждого файла, и сложить в калькуляторе, либо написать для всего этого макрос, что ничуть не проще отладки пайпа для шелла.

okis

2) Menu -> Characters -> Proper Case (или любой другой вариант, например "Sentence case" - это как будете решать через regexp-ы?)
а как работает этот sentence case?
он хорошо различает сокращения, заголовки, таблицы? там хотя бы РВ поправить можно? если нет, то с высокой вероятностью я никогда не смогу воспользоваться таким пунктом меню, т.к. он мне не подойдёт.

Dasar

Не сработает. Он же всё в LowerCase переведет, и посчитает в том числе слова, начинающиеся с "and"
если нужны слова, которые начинаются с and, то это:
(current-directory.file-s.text.word-s.to-lower[$ =* and]).count
или
(current-directory.file-s.text.word-s.to-lower[and,*]).count

tokuchu

Рядовому пользователю придётся потратить часы, если не дни и недели, чтобы банально осознать, что такое regexp и как им пользоваться. Вопрос в том, сколько времени на это надо потратить, чтобы их использование стало настолько выгоднее. С vim ситуация полностью аналогичная.
Ну ничего подобного. Я когда первый раз увидел книгу про регулярные выражения, я немножко охуел, т.к. я до сих пор не знаю что там можно в таком количестве про них написать. До сих пор не знаю, т.к. боюсь заглядывать в содержание, чтобы не впасть в ещё больший шок. :grin: Описание того, что такое регулярное выражение (в простом случае) занимает одну страничку. И больше ничего не надо для начала. Ну там из сложностей для последующего изучения только всякие наборы символов [[:alnum:]] \d и подобное и всякие граничные случаи — жадность и т.п.
С тем же vim-ом я лично знаю лишь несколько простейших сочетаний клавиш и команд. Настолько мало, что когда я заглядываю в tutorial из нескольких страничек, то узнаю что-то новое. :) Ну правда про применение регекспов в туториале возможно нет. И мне уже достаточно удобно с ним работать. Удобнее, чем с "визуальными" редакторами.
Визуальный интерфейс осваивается на порядки быстрее консольного,
Ну если там есть кнопочка "сделать заебись" для твоего конкретного случая, то да. Консольные утилиты работы с файлами немного сложнее будет выучить для одного раза. Но если такие задачи надо решать не один раз и с вариациями, то профит будет неимоверный.
не требует заучивания тысяч сочетаний клавиш и лазания по мануалам для выполнения простейших действий. С этим ты, надеюсь, спорить не будешь?
Не надо для vim-а никаких тысяч сочетаний. Так же в "визуальном" редакторе надо знать умеет он что-то или нет, в каком меню эта функция.
Ну с мануалами-то уж точно отличий нет. Если что-то сложнее хочешь, то везде читать надо. Тем более что тут ты упрекаешь vim в том, что там надо много мануалов читать, хотя их надо читать, чтобы сложную задачу решить, которые простой реактор не сможет решить или тоже потребует мануалов.

Dimon89

И повторить для каждого файла, и сложить в калькуляторе, либо написать для всего этого макрос, что ничуть не проще отладки пайпа для шелла.
Вообще-то любое действие из диалога Find можно запустить в режиме "для всех открытых файлов", так что ты не прав.

okis

Вим кажется более сложным оттого, что там нету тычек "сделать хорошо" (это я про консольный вим). Управление в нем не менее логичное, чем в каком-то визуальном редакторе.

Dimon89

если нужны слова, которые начинаются с and, то это:(current-directory.file-s.text.word-s.to-lower[$ =* and]).countили(current-directory.file-s.text.word-s.to-lower[and,*]).count
ты невнимательно читаешь. Наоборот, нужны слова, содержащие and, но НЕ начинающиеся с него. Впрочем, я верю, что это тоже можно сделать достаточно просто.

Dimon89

Вим кажется более сложным оттого, что там нету тычек "сделать хорошо" (это я про консольный вим). Управление в нем не менее логичное, чем в каком-то визуальном редакторе.
Вим кажется более сложным, потому что без чтения мануалов там нельзя сделать ни-че-го. Сужу по своему опыту. За те немногие разы, когда я пытался что-то сделать в виме, для меня каждый раз вставала проблема простейших действий: как сохранить файл, как найти/заменить строку, как выйти из редактора, наконец. Без мануала это нереально. Ты смотришь с высоты своего огромного опыта, а я говорю как новичок в консольных редакторах.

tokuchu

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

tokuchu

Вим кажется более сложным, потому что без чтения мануалов там нельзя сделать ни-че-го.
Ну и мануал для того, чтобы сделать что-то не очень большой.
Сужу по своему опыту. За те немногие разы, когда я пытался что-то сделать в виме, для меня каждый раз вставала проблема простейших действий: как сохранить файл, как найти/заменить строку, как выйти из редактора, наконец. Без мануала это нереально.
Так ведь в gvim-е это всё делается мышкой абсолютно так же как и в большинстве других редакторов.

serega1604

>Так ведь в gvim-е это всё делается мышкой абсолютно так же как и в большинстве других редакторов.
причем там ещё и подсказки как это сделать при помощи клавиатуры есть, точно так же, как и в других редакторах. :grin:

Dasar

ты невнимательно читаешь.
согласен. прочитал неправильно.
зы
условие тогда будет [$ *=* and && !($ =* and)] или [char+, and, *]

doublemother

ты невнимательно читаешь. Наоборот, нужны слова, содержащие and, но НЕ начинающиеся с него. Впрочем, я верю, что это тоже можно сделать достаточно просто.
Тему не читал, я правильно понимаю, что требуется
cat *.txt|grep -c '[a-z]and'

?

Dasar

cat *.txt|grep -c '[a-z]and'
такое не найдет µand
и слова вида candiand посчитает два раза

Dasar

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

doublemother

вообще, имхо, одна из самых существенных проблем однострочников - как убедиться, что они выдают именно то, что хотелось?
Либо предусмотреть все варианты, либо как-то верифицировать, либо допустить, что какие-то ситуации не могут возникнуть. При возникновении багов — модифицировать.
Разумеется, однострочники пишут не в тех случаях, когда хочется тратить время на верификацию.
Так, в упомянутых тобой проблемах я сознательно забил на нелатинские буквы, т.к. допустил, что мы работаем с английским языком (а слово µand вообще словом не является). А с candiand будет другой косяк — он посчитается всего один раз, равно как и любые несколько вхождений в одной строке. Поэтому исправленная версия будет выглядеть как:
cat *.txt|sed 's/\s/\n/g'|grep -c '[a-zA-Z]and'

hwh2010

Вим кажется более сложным оттого, что там нету тычек "сделать хорошо" (это я про консольный вим).
нет. Вим кажется более сложным потому что в нём для обычных действий (типа "скопировать в буфер слово справа от курсора") нужно ботать кучу буквенных команд, а не использовать интуитивно понятные, распространённые в любом GUI стрелочные.
Управление в нем не менее логичное, чем в каком-то визуальном редакторе.
ctrl+backspace удаляет слово слева — логично
ctrl+w удаляет слово слева — нелогично, надо запоминать
десяток или два таких примеров привести?
про то что режимы работы это плохо для любой проги — читать Джеффа Раскина
там всё разжёвано

Bibi

ага, еще читать, что такое режим, до просветления.

doublemother

про то что режимы работы это плохо для любой проги — читать Джеффа Раскина
там всё разжёвано
Это меня, кстати, всегда удивляет. Почему авторитетные люди подробно и обстоятельно доказывают, что вим и режимы работы — это плохо и неудобно, когда люди прочитавшие мануал и попробовавшие обнаруживают обратное? Я вижу этому одно объяснение: по той же причине, что и обычный человек покупает себе какую-нибудь обычную инновационную нанодрель с одной кнопкой «засверлиться сверлить», а у того, кто пользуется ей регулярно, дрель в два раза больше, с режимами работы, разными скоростями и набором насадок вплоть до метровых. Иначе говоря — низкий порог вхождения. Но не нужно его путать со «злом», «удобством» или ещё какими-то глупостями.

Dasar

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

apl13

Задача состояла в том, чтобы посчитать число вхождений "and" в слова, не учитывая слова, которые с него начинаются (например, собственно слово "and").
Ну, собственно, ты сам и ответил на свой вопрос.
Потому что в этой задаче нет никакого преобразования в Proper Case. Но поскольку ты не знаешь, как в визуальном редакторе™ сделать это без проперкейса, проперкейс совершенно естественным образом прописался в твоей первоначальной формулировке. Ты как бы приучился мыслить визуальным редактором. А между тем, это лишнее действие. Зря потраченные ресурсы. А команда, которая решит твою задачу, выполнится быстрее, чем ты откроешь в визуальном редакторе первый файл.
awk '{n += gsub("\\Band", "")} END {print n}' $FOLDER_NAME/*

apl13

Рядовому пользователю придётся потратить часы, если не дни и недели, чтобы банально осознать, что такое regexp и как им пользоваться. Вопрос в том, сколько времени на это надо потратить, чтобы их использование стало настолько выгоднее. С vim ситуация полностью аналогичная.
Тут полностью справедливо правило "Лучше день потерять, потом за пять минут долететь".
Если для тебя, конечно, правка текста не есть блажь начальника, ты надеешься, что в твоей жизни последняя.

Bibi

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

doublemother

потому что при этом используются ощущения, а не реальные измерения.
проблема в том, что для человека привычные действия всегда кажутся удобными, в не зависимости от того насколько они эргономичны в действительности
Ну, как бы подразумевается, что человек умеет работать не только в виме. Ещё вопрос: зачем, спрашивается, неудобный вим прикручивают буквально всюду? vimperator в фф, плагины для MSVS, qtcreator'а, эклипса? Я видел даже pdf-просмотрщик с vim-style навигацией.
Я вот fakevim для qtcreator так и не пробовал ещё, но каждый раз, когда в нём правлю код, сижу и мучаюсь, потому что все те основные вимовские операции, которые обычно и нужны — удалить/перенести слово/строку/блок — в обычном редакторе выполняются намного дольше. А простое написание кода везде одинаковое, и для сложных операций тоже везде надо думать, только в виме они легче расширяются, благодаря макросам и встроенному языку.

doublemother

не ведись. режимы в виме возникают только при неправильном использовании.
после приобритения рефлекса стукнуть esc режимы исчезают.
Правильно делать: <esc><c-z>kill %1<cr>

Bibi

неудобный вим прикручивают буквально всюду? vimperator в фф, плагины для MSVS, qtcreator'а, эклипса
про емакс забыл

Bibi

слышь, приобрей рефлекс-то!

doublemother

Приобрил.

Dasar

неудобный вим прикручивают буквально всюду
потому что он привычный для определенной группы людей, они его и продвигают.
выбор удобно/не удобно обычно делают новички, а не те, кто уже на чем-то сидит.
в обычном редакторе выполняются намного дольше.
при этом ты выучил до моторной памяти все клавиатурные комбинации?

Bibi

все клавиатурные комбинации
таки ВСЕ?

Dasar

таки ВСЕ?
имел ввиду, конечно: столько же - сколько выучил для вима

doublemother

при этом ты выучил до моторной памяти все клавиатурные комбинации?
Ещё с далёкого досовского детства.

Dasar

Ещё с далёкого досовского детства.
а что тогда неудобно?

Serab

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

doublemother

а что тогда неудобно?
То, что они более медленные и менее удобные.

Dimon89

Да, срачег развели ужасный, притом ниочем. Я до сих пор на 100% уверен, что если взять произвольное количество незнакомых с компьютером людей и попросить их сделать что-то с текстом в виме и npp, то результат будет нагляден. Я ещё не видел ни одного не-линуксоида новичка в компьютерах, который смог бы сходу сделать в виме то, что он хочет.
PS Напомню: спор был не о скриптах, а об удобстве вима как текстового редактора. Скритом я и сам что хочешь сделаю, правда в силу виндузовости предпочитаю питон.

yroslavasako

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

soroka000

1) Ну вим же вроде умеет 2 вещи: бибикать и все портить.
2) Я вим освоил в 3 подхода с промежутком в годы. Каждый подход по 2-3 часа. Ни разу не жалею.
Очень удобно гененить тестовые файлы для крештеста прог в контесте. Скажем файлик состоящий из 10000 строк в каждой из которых записано от 1! до 10000! можно в 10-20 нажатий.
3) По поводу notepad++ http://www.vim.org/images/0xbabaf000l.png

soroka000

Да, срачег развели ужасный, притом ниочем. Я до сих пор на 100% уверен, что если взять произвольное количество незнакомых с компьютером людей и попросить их сделать что-то с текстом в виме и npp, то результат будет нагляден.
А что это доказывает?
Я вот vim изучил чисто из любопытства и чисто для себя. Много интересных вещей на нем можно делать быстро.
Помимо vim я пользовался textmate, emacs, notepag++ и т.д. Перепробовал кучу IDE. Вывод пока достоин К.О. — Выбирай инструмент по задаче.
Если крутой проект на 100500 строк кода. Сложная структура и т.д. Нужен рефакторинг и пр. Тут поможет только специализированная IDE. Хотя многие vim'еры и emacs'еры со мной не согласятся =)
Если надо конфиги поправить или тестовый файлик сгенерить, да и вообще — я привык использовать vim.
Vim тренирует память, ломает шаблоны и стереотипы.
P/S/ Я до сих пор не привык к H J K L, но жить это не мешает =)

hwh2010

все те основные вимовские операции, которые обычно и нужны — удалить/перенести слово/строку/блок — в обычном редакторе выполняются намного дольше
давай-ка без пиздежа
засекаем по кол-ву нажатых клавиш!
до и после этого действия, разумеется, юзер вводит текст, поэтому переключение режимов считаем

okis

Ну, кстати, при переносе вводить ничего не надо, тут в виме надо всего-то dw5wp, в npp же надо ctrl-shift-arrow-x (2 нажатия ctrl со стрелочкой много раз, ctrl-v итого от четырех нажатий, т.е. вим не отстает, у него случай перемены слов местами тоже 4, но более простых: dwwp.

hwh2010

Ну, кстати, при переносе вводить ничего не надо, тут в виме надо всего-то dw5wp
5 — это кол-во слов? не катит, считать их по экрану пальцем мы не готовы.

okis

Да. Можно сколько надо раз нажать w. Значит здесь нет разницы кроме того, что в npp надо аккорды нажимать, а в виме просто буквы. Собственно, в этом и удобство.

hwh2010

в npp надо аккорды нажимать, а в виме просто буквы. Собственно, в этом и удобство.
в этом НЕудобство
1) аккорды известны с пелёнок и логичны, едины для всех редакторов (кроме исконно консольных) и полей ввода
2) аккорды не конфликтуют со вводом
на деле буквы и хуюквы юзаются в вимах и имаксах потому что в консоли написать приложение, различающее пробел и shift+пробел например невозможно
а не потому что они такие заебатые

okis

Да, со сложным вводом все плохо. Зато легко править файлы на удаленных машинах; для вима даже вики сделали, чего не видел ни в каком гуи редакторе.

tokuchu

1) аккорды известны с пелёнок
Смотря какие у кого пелёнки.
и логичны,
Утверждение, не подкреплённое никакими доказательствами.
едины для всех редакторов (кроме исконно консольных) и полей ввода
2) аккорды не конфликтуют со вводом
Возможно у некоторых вимоненавистников сейчас взорвётся мозг, но Ctrl+стрелки в gvim работают в режиме ввода!
на деле буквы и хуюквы юзаются в вимах и имаксах
Да уж. В имаксах как раз используются не буквы и хуюквы, а всякие комбо-сочетания.
А в виме использование двух режимов позволяет не ломать пальцы. :)
потому что в консоли написать приложение, различающее пробел и shift+пробел например невозможно
Ты очень глубоко не прав. :crazy:
В терминале всё это тоже есть и Имакс тому доказательство.

okis

Он про то, что если шелл настроить неправильно, то все ломается.
Кстати, на мой взгляд с логичностью в виме не хуже. Delete word, (next) word, paste. А вот ctrl-v я не знаю, как расшифровывается, но можно и на shift-ins заменить, при желании.

tokuchu

Возможно у некоторых вимоненавистников сейчас взорвётся мозг, но Ctrl+стрелки в gvim работают в режиме ввода!
Особо нервным дальше советую не читать. :)
Кроме того есть расширение, которое добавляет выделение по shift, ctrl-c,v и прочие "аккорды, известные с пелёнок тов. ". И всё это даже в консоли!

apl13

Я до сих пор на 100% уверен, что если взять произвольное количество незнакомых с компьютером людей и попросить их сделать что-то с текстом в виме и npp, то результат будет нагляден. Я ещё не видел ни одного не-линуксоида новичка в компьютерах, который смог бы сходу сделать в виме то, что он хочет.
        spelling[0] = "zero";
spelling[1] = "one";
spelling[2] = "two";
spelling[3] = "three";
spelling[4] = "four";
spelling[5] = "five";
spelling[6] = "six";
spelling[7] = "seven";
spelling[8] = "eight";
spelling[9] = "nine";
spelling[10] = "ten";
spelling[11] = "eleven";
spelling[12] = "twelve";
spelling[13] = "thirteen";
spelling[14] = "forteen";
spelling[15] = "fifteen";
spelling[16] = "sixteen";
spelling[17] = "seventeen";
spelling[18] = "eighteen";
spelling[19] = "ninteen";
spelling[20] = "twenty";

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

hwh2010

Кроме того есть расширение, которое добавляет выделение по shift, ctrl-c,v и прочие "аккорды, известные с пелёнок тов. ". И всё это даже в консоли!
я не про то что в неправильно настроенной консоли всё ломается
я про то, что распространённые режимы "xterm" и "rxvt" при нажатии различных комбинаций клавиш выдают одинаковые эскейп-последовательности
если у вас там иногда работают контрол-стрелочки — это ещё не повод ликовать
потому что контрол-шифт-стрелочки в консоли не работают, и куча всего тоже не работает и не может даже теоретически

hwh2010

Да уж. В имаксах как раз используются не буквы и хуюквы, а всякие комбо-сочетания.
не всякие, а хуюквы
контрол+буква — ещё не все сочетания

hwh2010

ставлю 5л сока, что ты не сделаешь чтобы в виме в икстерме работали Home, Ctrl+Home, Shift+Home и Ctrl+Shift+Home
работали так как интуитивно должны работать, разумеется

tokuchu

если у вас там иногда работают контрол-стрелочки — это ещё не повод ликовать
Что значит иногда? У меня на компе работают. Где мне ещё надо?
А "ликование" по поводу того, что твои попытки принизить vim из-за того, что там нет любимых сочетаний — беспочвенны.
потому что контрол-шифт-стрелочки в консоли не работают, и куча всего тоже не работает и не может даже теоретически
Почему это?

tokuchu

ставлю 5л сока, что ты не сделаешь чтобы в виме в икстерме работали Home, Ctrl+Home, Shift+Home и Ctrl+Shift+Home
работали так как интуитивно должны работать, разумеется
Поясни подробнее последнее предложение. Т.к. мало ли что ты под этим подразумеваешь.

hwh2010

Home ведёт курсор на начало строки
Shift+Home выделяет блок до начала строки
Ctrl+Home ведёт на начало файла
Ctrl+Shift+Home выделяет блок до начала файла

hwh2010

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

tokuchu

Home ведёт курсор на начало строки
это вообще изкаропки работает
Shift+Home выделяет блок до начала строки
Ctrl+Home ведёт на начало файла
Ctrl+Shift+Home выделяет блок до начала файла
В gvim работает, в xterm у меня не работает.
В xterm точно работает ctrl+стелки, shift-стрелки, ctrl-shift-стрелки.

tokuchu

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

hwh2010

в xterm у меня не работает
предлагаю 3 варианта:
1) настраиваешь, чтобы работало, я тебе 5л сока. Можно ставить расширения и перекомпилировать вим, нельзя перекомпилировать xterm, хачить curses, трогать termcap.
2) ты мне 5л сока
3) ты отказываешься от тех своих утверждений в этом треде, которые очевидно ложные

hwh2010

неужели тебе не очевидно, что "мои" сочетания клавиш — более логичные, что их учить вообще не надо?
ctrl с горизонтальными стрелками, del и bs — по словам
ctrl с home/end — идёт в край файла
shift с чем угодно выделяет блок
shift+del, ctrl+ins, shift+ins — это cut, copy, paste
4 строки знаний для любого неавтоматического редактирования текста
напиши пожалуйста такую же шпаргалку для вима — мне интересно, какой она длины и реально ли её запомнить

tokuchu

неужели тебе не очевидно, что "мои" сочетания клавиш — более логичные, что их учить вообще не надо?
Логика есть в них, конечно, но вот про более тут навряд ли можно что-то доказать.
ctrl с горизонтальными стрелками, del и bs — по словам
ctrl с home/end — идёт в край файла
shift с чем угодно выделяет блок
shift+del, ctrl+ins, shift+ins — это cut, copy, paste
напиши пожалуйста такую же шпаргалку для вима — мне интересно, какой она длины и реально ли её запомнить
w, b - по словам вперёд, назад
gg - начало, G - конец
d - удалить, p - вставить, y - скопировать, v - выделение
Как-то так. Тоже немного получается.

tokuchu

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

dangerr

Очень интересный спор пошёл.
Я, пожалуй, займу позицию сомневающегостя к какой стороне примкнуть. :)
Именно вследствие распространённости и большей очевидности, сам предпочитаю использовать ctrl-стрелочки и прочее. HJKL - это вообще ппц как неудобно и нелогично, особенно в двораке.
С другой стороны, я встречал только одну программу, в которой в рамках данного подхода реализовано например удобное копирование и меняние местами строк - eclipse, в основном же приходится копипастить.
Кроме того, стрелочки, Home, end и прочее расположены вне основного массива клавиатуры, а это значит, что приходится для их нажатия перемещать руку с позиции, удобной для письма. Поэтому, я думал настроить нажатие на стрелки и всякие Home, End через сочетания, скажем, Super + что-то в основном ряду. Но пока не продумал как бы это сделать удобно. :)
Баштанов, скажи какими редакторами ты пользуешься для правки конфигов в графике и в консоли (по ssh, например).

dangerr

А, и ещё момент.
Мне очень нравится vim-style поиск по сравнению со стандарным окошечком, которое закрывает часть текста. И я не встречал CUA-редакторов, где бы было сделано подобным образом.
В дефолтном FF только такой поиск вне концепции вима.

okis

настраиваешь, чтобы работало, я тебе 5л сока. Можно ставить расширения и перекомпилировать вим, нельзя перекомпилировать xterm, хачить curses, трогать termcap.
Actually, if you use xterm, you can get around the terminal emulator limitations by remapping keys in your .Xresources file. Use a key sequence that you do not use anyway, for instance C-M-7 (0x9f):
XTerm*vt100*translations: #override\n\
Ctrl Shift <Key> O: string(0x9f)
Then do an xrdb -merge ~/.Xresources and map C-M-7 to C-i in Vim.
Admittedly it's a hack, but it have helped me a lot. Check out my .Xresources for inspiration.
такой хак подойдёт или нет?

tokuchu

Огласите весь список, пожалуйста.
Ну в целом-то я понял, что терминал вносит некоторые ограничиния. Но этот вопрос ещё дополнительного исследования заслуживает.
Хотя я думал, что какой-нибудь ncurses позволяет полностью обрабатывать клавиатуру. Хотя может быть они просто работают не в таком режиме.
Кроме того про консоль я написал, когда проверил, что shift-стрелки там тоже работают. Но в целом проблемы консоли — это отдельный вопрос и для сравнения "визуальных" редакторов не нужен.

doublemother

Я до сих пор на 100% уверен, что если взять произвольное количество незнакомых с компьютером людей и попросить их сделать что-то с текстом в виме и npp, то результат будет нагляден.
Я тут подотстал от дискуссии, но у меня сложилось ощущение, что GDM и баштанов так и не осилили вышеупомянутую разницу между удобством и порогом вхождения.

Dasar

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

dangerr

Только GDM не осилил.
Они вообще о разных вещах говорят.
GDM сравнивает интерфес менюшек и кнопочек с работой с текстом с клавиатуры. А Баштанов сравнивает разные виды последнего варианта.

okis

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

doublemother

но стоит так же понимать, что порог вхождения - это навсегда, а не разовая штука.
если одна данная программа имеет свое собственное управление мало совместимое с управлением других программ, то с этим барьером человеку придется бороться всегда, даже если он полностью выучит управление данной программы.
все равно будет использование других программ, где управление другое, будет переключение навыка с неизбежным размытием качества усвоения навыка и увеличением кол-ва ошибок
Я умею кататься на велосипеде, а умею на роликах. Могу говорить на русском, а могу — на английском.
Путаница, связанная с попытками использования правил для аналогичного предмета, — это как раз явление начального этапа, когда ты в новом предмете ещё не разобрался и подсознательно пытаешься замещать незнакомые действия знакомыми. Когда ты хорошо знаешь и то, и то, никаких проблем нет. Кроме того, лично из моего опыта у меня сложилось ощущение, что вимовская парадигма настолько отлична от дефолтной, что путаницы не возникает вообще, слишком всё другое.

Dasar

Путаница, связанная с попытками использования правил для аналогичного предмета, — это как раз явление начального этапа, когда ты в новом предмете ещё не разобрался и подсознательно пытаешься замещать незнакомые действия знакомыми. Когда ты хорошо знаешь и то, и то, никаких проблем нет.
путаница возникает, когда во внешне одной и той же ситуации необходимо делать разные вещи.
например, очень тяжело(хотя и возможно) освоить и одновременно ездить на велосипеде с обычным управлением и реверсивным (поворот руля налево поворачивает колесо направо)
и соответственно, ввод текста выглядит почти полностью одинаково:
в браузере,
форум,
блог,
соц.сеть,
в простом текстовом редакторе,
в rich текстовом редакторе,
в ide,
в skype,
в icq,
в почте,
в рабочих программах
документооборот,
управление задачами,
и т.д.
при этом если управление во всех этих случаях разное, то это мешает.
вот и приходится писать плагины(когда это возможно) под каждую штуку, чтобы не потерять навык своей схемы управления.
также да, можно весь функционал затащить в одну программу, как пытается emacs, но это приводит к попытке переписать весь мир, и отказу от множества удобных уже готовых фич.

doublemother

например, очень тяжело(хотя и возможно) освоить и одновременно ездить на велосипеде с обычным управлением и реверсивным (поворот руля налево поворачивает колесо направо)
Велосипед не знаю, самолёт рулём высоты, как нормальным, так и реверсивным управляется одинаково без проблем :)

hwh2010

Я умею кататься на велосипеде, а умею на роликах.
маладэц
а я вот даже не умею пользоваться вимом — а всё равно пару раз нажимал в браузере Ctrl+W вместо Ctrl+Back — получал закрытую вкладку
мама у меня водит время от времени праворульную и леворульную машины — путает поворотники и дворники
а все кто водят какую-то одну — не путают
короче, унификация — добро

hwh2010

Баштанов, скажи какими редакторами ты пользуешься для правки конфигов в графике и в консоли (по ssh, например).
в гуи — geany в основном
по ssh — mcedit или vim (плююсь и от того, и от другого)
или (мышью) копирую в geany, правлю там, копирую обратно

tokuchu

Но Ctrl-W пошло из консоли, а не из vim-а. Выкорчевать его из консоли будет больно для многих. Навязать его в браузер — тоже. Здесь особо не унифицируешь.

hwh2010

Мне очень нравится vim-style поиск по сравнению со стандарным окошечком, которое закрывает часть текста. И я не встречал CUA-редакторов, где бы было сделано подобным образом.
есть вендовый, менее фичастый чем notepad++ или tswebeditor
забыл название
там примерно как у фаерфокса или оперы поиск
только ещё и два многострочных поля ввода
разумеется, тем кто придумал floating windows, нужно выйти (предварительно восстав из гробов, если необходимо) и публично заявить о своей ошибке

tokuchu

мама у меня водит время от времени праворульную и леворульную машины — путает поворотники и дворники
Она время от времени машины водит или время от времени переключается?
Вообще на эту тему есть даже люди, которые педали путают. :)
Но в целом при продолжительной тренировке (использовании) должна выработаться привычка не путать. Т.к. всё-таки мозг видит контекст и действует в соответствии с ним.

hwh2010

Но Ctrl-W пошло из консоли, а не из vim-а. Выкорчевать его из консоли будет больно для многих. Навязать его в браузер — тоже. Здесь особо не унифицируешь.
Достаточно сделать в консоли Ctrl+BackSpace и подождать 10 лет
после этого про Ctrl+W как удалить слово слева помнить будут только олдфаги — ну и пусть юзают
кстати, не все традиции одинаково полезны
ctrl+left в консоли (когда работает) идёт на слово влево, а Ctrl+W — удаляет слово слева
только вот беда: понятие слова очень разное
а в гуйне у всех всё одинаково, в разных редакторах и разных ситуациях

hwh2010

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

tokuchu

а в гуйне у всех всё одинаково, в разных редакторах и разных ситуациях
Что-то я сомневаюсь по этому пункту, что слова одинаково делятся везде.

tokuchu

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

doublemother

И правильно думаешь, потому что в замечательной унифицированной винде без всяких вимов переход по ctrl+стрелка и удаление слов до/после курсора везде работают по-разному. А ctrl+backspace в семерке у меня в половине софта (а может и везде — не помню начиная с системного, типа ноутпада, вместо удаления слов вставляет непечатный символ. Такие дела.

Dimon89

Я тут подотстал от дискуссии, но у меня сложилось ощущение, что GDM и баштанов так и не осилили вышеупомянутую разницу между удобством и порогом вхождения.
Открою тебе страшную тайну: по моему скромному мнению, порог вхождения входит в критерий удобства. Если у программы ЕСТЬ порог вхождения - она априори неудобная. Основная задача разработчика интерфейса состоит в том, чтобы любой мало-мальски разбирающийся в компьютерах человек (а лучше даже просто любой) мог запустить программу и начать с ней работать. Я видел тысячи программ, и в 90% случаев я начинал с ними работать даже не задумываясь, если знал, для чего она предназначена.

doublemother

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

dangerr

geany - это, судя по всему, больше среда разработки, чем текстовый редактор. Он изобилует всякими менюшками и влкадочками, что для простого редактирования файла просто мешает и занимает место.
Удобного перемещения строк там нет (то, что происходит по ctrl-t - совсем не то, как alt-up, alt-down в эклипсе).
И поиск в виде отдельного окна, перекрывающего текст.
Ещё и игнорирует системную тему в поле редактирования текста и настроить можно только инвертированные цвета или нет. У меня из-за этого при выделении не видно что выделено.
В общем, по сути при всём преимуществе CUA, имеем отсутствие хорошо спроектированного и по настоящему удобного CUA-текстового редактора. В то время как vim в рамках своей прадигмы практически достиг совершенства в удобстве использования.
Ну и возможности не переносить руки с основного ряда клавиш, сложно что-либо противопоставить.
Ну а так, конечно я за унификацию и поэтому за CUA-подход. :)

Dasar

в таблицах по ссылке http://en.wikipedia.org/wiki/Table_of_keyboard_shortcuts
не хватает vim-а
зы
а даже emacs есть, следовательно vim - сосёт :)

hwh2010

geany - это, судя по всему, больше среда разработки, чем текстовый редактор.
я юзаю как текстовый редактор. Как среду — более тяжёлые и сложные вещи, эклипс например тот же.
Он изобилует всякими менюшками и влкадочками, что для простого редактирования файла просто мешает и занимает место.
нелюбовь твою ко вкладкам знаю. Тем не менее, даже с одноуровневой структуризацией окон имеющиеся WM не справляются, поэтому второй уровень я поручаю приложениям.
Удобного перемещения строк там нет (то, что происходит по ctrl-t - совсем не то, как alt-up, alt-down в эклипсе)
удобное перемещение строк — это home, shift-down, shift-del, ..., shift+ins. Ничего большего и не надо, т.к. обычно строки перемещают не по одной, а пачками.
И поиск в виде отдельного окна, перекрывающего текст.
да, это отстой
В общем, по сути при всём преимуществе CUA, имеем отсутствие хорошо спроектированного и по настоящему удобного CUA-текстового редактора.
хзхз
то что я не нашёл (или ты не нашёл) — ничего ещё не значит
В то время как vim в рамках своей прадигмы практически достиг совершенства в удобстве использования.
даже в своей парадигме у него очень есть куда стремиться. Хотя бы в сторону уменьшения возможности модальных ошибок.
Ну и возможности не переносить руки с основного ряда клавиш, сложно что-либо противопоставить.
у меня при редактировании скорость упирается в мозг, а не в руки
если нужно не тупо набирать текст, а думать что бы с ним сделать — я успеваю побарабанить пальцами по столу

tokuchu

у меня при редактировании скорость упирается в мозг, а не в руки
если нужно не тупо набирать текст, а думать что бы с ним сделать — я успеваю побарабанить пальцами по столу
От этого все равно не становится удобнее нажимать по очереди: Home, Shift+Down, Shift-Del, Shift-Ins. :)

andrei260280

мне кажется, подавляющая часть целевой аудитории вима юзала баш с дефольтным C-W для удаления слова, так что вопрос еще, что очевиднее.
по сабжу — даже если не считать кучи полезнейших плагинов для чего угодно, одна возможность делать что угодно с текстом без мыши и соотв. писать любые макросы, которые на седе куда дольше бы писались, делает вим самой полезной иде. /* preventing holywar*/ емакс не юзал.
плюс значительно меньше приходится выполнять бессмысленные действия наподобие выделения кусков текста зажатием Ctrl-всякихстрелок или мышой, прости господи. ничего не отвлекает, нужно что-то сделать с текстом — взял и сделал, скорость набора ограничивается только скоростью собственно печатания.
/* fuck it, let's holywar */ по ощущениям, в отношении редактирования текста возможности VS/Eclipse/QtCreator гораздо ближе к возможностям notepad, чем вима, за исключением важных фич неспособности работать без иксов и 4гб оперативки (а эклипсу и они не помогают, лол).

hwh2010

плюс значительно меньше приходится выполнять бессмысленные действия наподобие выделения кусков текста зажатием Ctrl-всякихстрелок
писец, вот то ли осмысленные действия — между режимами переключаться!
перед копированием/удалением блоки обязательно нужно выделять
потому что алгоритм хождения по словам, как уже обсуждалось, глючный
и нужно видеть выделенный блок, прежде чем производить с ним действия

serega1604

>потому что алгоритм хождения по словам, как уже обсуждалось, глючный
по ctrl-стрелочкам-то? да, глючный
>и нужно видеть выделенный блок, прежде чем производить с ним действия
vim тебя не ограничивает в этом - хочешь предварительно выделить - выделяй. с выделенным блоком даже больше можно сделать, чем с невыделенным.

hwh2010

по ctrl-стрелочкам-то? да, глючный
выше уже обсуждалось, что угадать, где текстовый редактор считает что заканчивается слово — проблематично, это зависит как от текстового редактора, так и от используемой команды.
vim тебя не ограничивает в этом - хочешь предварительно выделить - выделяй. с выделенным блоком даже больше можно сделать, чем с невыделенным.
ограничивает: чтобы выделить блок и сделать с ним действие, нужно нажать много разных клавиш, побывать в нескольких режимах — при том клавиши нужно нажимать последовательно, что дольше чем жать "аккорды"

tokuchu

ограничивает: чтобы выделить блок и сделать с ним действие, нужно нажать много разных клавиш,
Как и в случае с аккордами.
побывать в нескольких режимах
Ужас-ужас. Звучит так страшно, что уже не стоит пользоваться? :)
при том клавиши нужно нажимать последовательно, что дольше чем жать "аккорды"
Да ну конечно. Клавиш нужно нажимать примерно столько же. А для того, чтобы нажимать аккорды со стрелочками и прочей навигацией, нужно переносить и изгибать руки, от этого намного медленнее получается. Одновременное нажатие клавиш быстрее, чем последовательное, наверное только в случае shift+буква. :)

hwh2010

Ужас-ужас. Звучит так страшно, что уже не стоит пользоваться?
я не готов пересказывать классиков
Одновременное нажатие клавиш быстрее, чем последовательное, наверное только в случае shift+буква.
одновременное всегда быстрее
чтобы нажать "w q", нужно сделать 4 действия (нажать w, отпустить w, нажать q, отпустить q) строго в этом порядке. Чтобы нажать Alt+F4, нужно сделать 4 действия (нажать Alt, нажать F4, отпустить F4, отпусить Alt но при этом последние 2 действия можно делать в любом порядке, в том числе одновременно. На деле именно на то чтобы нажатия-отпускания произошли в нужном порядке, тратится больше всего времени (человек намеренно делает ма-аленькие паузы между действиями чтобы с запасом сохранить их порядок). Поэтому Alt+F4 — это 3 действия, а "w q" — 4.

tokuchu

Ужас-ужас. Звучит так страшно, что уже не стоит пользоваться?
я не готов пересказывать классиков
Причём тут классики, если в том контексте данное выражение не несло никакой смысловой нагрузки.
одновременное всегда быстрее
чтобы нажать "w q", нужно сделать 4 действия (нажать w, отпустить w, нажать q, отпустить q) строго в этом порядке. Чтобы нажать Alt+F4, нужно сделать 4 действия (нажать Alt, нажать F4, отпустить F4, отпусить Alt но при этом последние 2 действия можно делать в любом порядке, в том числе одновременно. На деле именно на то чтобы нажатия-отпускания произошли в нужном порядке, тратится больше всего времени (человек намеренно делает ма-аленькие паузы между действиями чтобы с запасом сохранить их порядок). Поэтому Alt+F4 — это 3 действия, а "w q" — 4.
Ну это просто ложь.
Из положения набора текста нажать wq гораздо быстрее, чем Alt-F4 и для этого даже действия считать не надо — с этим даже пока спорить не хочется. :)

hwh2010

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

tokuchu

но и не делай голословных утверждений
Так это твоё утверждение голословное. Т.к. у меня wq в несколько раз быстрее получается на практике.

hwh2010

можешь объяснить этот феномен?

tokuchu

несло. Чем плохо переключение между режимами — написано по ссылке.
Нет. Наличие режима само по себе на скорость не влияет. Если бы ты сказал, что нужно переключиться в другой режим и т.п., то ещё можно понять.
Да, у наличия режимов есть недостатки, как и у дргих вещей — например у комбинаций клавиш. Они обладают набором недостатков не меньшим чем режимы, наверное. И тут уже приходится выбирать что в результате лучше. В vim выбрана парадигма режимов с целью упрощения команд и ускорения действий.

tokuchu

можешь объяснить этот феномен?
У тебя не так?
Для wq мне надо: вытянуть пальцы левой руки и стукнуть ими wq.
Для Alt-F4. Я на самом деле привык это делать одной рукой, т.к. когда я привыкал, то другая рука была занята мышкой. :) Поэтому у меня ещё медленее, но даже если в 2 руки делать, то для этого левую руку нужно сильно сместить вверх, а правую — вправо, после этого нажать Alt, F4. У меня вот только на смещение вверх уже уходит больше времени, чем на wq польностью.

doublemother

Для wq мне надо: вытянуть пальцы левой руки и стукнуть ими wq.
Это не считая того момента, что всевозможные методики набора текста, да и просто естественное размещение рук на клаве, предполагают наличие левой руки в регионе qwerasdf. То есть, достаточно просто чуть-чуть шевельнуть пальцами. Впрочем, пример с wq неправильный, потому что требует набора ещё двоеточия, что гораздо дольше, зато есть абсолютно эквивалентная замена — ZZ — которая всяко быстрее.

soroka000

Бля ну чуваки.
Спорить vim vs emacs это я понимаю.
Но спорить vim vs редактор для блондинок — ну ваще не вариант
Даже хвалёный текстмэйт не дотягивает до вима.
А про VS, Eclipse, etc. Это не редакторы. Это среды разработки с редактором. И кстати в обоих есть эмитация vim.

dangerr

нелюбовь твою ко вкладкам знаю.
Я в данном случае имел в виду лишние области слева и снизу. Но потом я нашёл как их убрать и даже как убрать таббар, так что вопрос снимается:)
Тем не менее, даже с одноуровневой структуризацией окон имеющиеся WM не справляются, поэтому второй уровень я поручаю приложениям.
Ну смотря что за WM :) notion отлично справляется. А второй уровень противоречит бритве Окамма и вызывает такие же проблемы, как при разных режимах: я часто ошибаюсь, например в эклипсе, по какому из уровней хочу переключиться и вместо смены вкладки, меняю активное окно или наоборот.
удобное перемещение строк — это home, shift-down, shift-del, ..., shift+ins. Ничего большего и не надо, т.к. обычно строки перемещают не по одной, а пачками.
Вообще-то в том же эклипсе ты выделяешь несколько строк с шифтом, а затем с помощью alt+верх(низ) двигаешь куда тебе надо. Это гораздо удобнее катапаста, я надеюсь ты с этим согласишься?
то что я не нашёл (или ты не нашёл) — ничего ещё не значит
Это говорит о том, что либо мы оба не умеем использовать поисковики, либо о том, что этот редактор используется только его создателем и может ещё парой человек, либо, что этого редактора не существует в природе. Последнее мне кажется наиболее вероятным. Второе - практически невозможным, так как такой редактор под силу создать сильному сообществу, а не одному-двум людям (нет, конечно ничего невозможного, но...)
у меня при редактировании скорость упирается в мозг, а не в руки
если нужно не тупо набирать текст, а думать что бы с ним сделать — я успеваю побарабанить пальцами по столу
Зависит от задачи. Если пишешь программу со сложной логикой, то да. А если надо набрать что-то, что нельзя автоматизировать, но и думать практически не надо, тут будет не так. Как раз сегодня набивал по работе xml-ник и скорость упиралась именно в перенос рук от основного ряда к home-end-стрелочкам.

dangerr

я не готов пересказывать классиков
Прочитал параграф 3.2 Режимы (вообще у меня давно эта книжка в toread валяется). В принципе согласен с автором: режимы - в общем случае зло и их нужно стараться не использовать. Однако, по тому определению, получается, что любая смена фокуса - это смена режима, потому что меняет результат нажатия на некоторые клавиши. Впрочем, ты наверное скажешь, что фокус - это тоже зло и в общем случае я с тобой соглашусь.
Рассмотрим например, браузер. Даже самый минимальный функционал требует как минимум два режима: работа с самим документом (заполнение форм и прочее) и управление браузером (хотя бы ввод url). А есть ещё быстрое обращение к поисковикам, закладки и прочее. И прадигма вима здесь оказывается как нельзя кстати. Мне сложно представить подход, который бы позволял удобнее управлять браузером полностью с клавиатуры.
Когда я пользуюсь вимператором или uzbl, я в общем-то не рассматриваю это как режимы вима. Это просто перенос фокуса между страницей и консолью управления браузером. При этом тут легко разруливаются модальные ошибки. Когда я хочу заполнять форму или ввести урл, я вижу есть ли в данном контроле сейчас курсор или нет.
В lynx-е тоже подобным образом сделано.

Bibi

простите, весь тред по-прежнему про Vимпотенцию пользователя ?

doublemother

простите, весь тред по-прежнему про Vимпотенцию пользователя ?
Нет, про гоморедакторы!
Оставить комментарий
Имя или ник:
Комментарий: