Comments 769
Статья очень понравилась, узнал много нового для себя и полюбил vi еще сильнее.
Для всех сторонников vim рекомендую книгу Drew Neil Practical Vim. В книге собраны советы, позволяющие ускорить редактирование в vim.
Действительно, некоторые примеры в статье — просто шикарны. Но если бы автор не писал так неуважительно в сторону IDE, статья была бы лучше. Сравнивать IDE и Vi некорректно.
Очень хорошая переводить спасибо
Во вселенной, где не изобрели мышь, vi, конечно, рулит.
А вы часто используете мышь в текстовом редакторе? Для чего?
(нет, не сарказм — я использую лишь изредка трекбол, поэтому мне очень интересно)
(нет, не сарказм — я использую лишь изредка трекбол, поэтому мне очень интересно)
Для моментального позиционирования текстового курсора в нужное место.
Я бы не назвал необходимость переносить руки из привычного для слепой печати положения на мышку и потом возвращать назад «моментальным позиционированием». Лично мне это всегда доставляет жуткий дискомфорт и очень сильно выбивает из потока.
А если у меня привычное положение — одна рука на клаве, вторая на мышке?
Если вы печатаете одной рукой, то да.
Тогда вы либо не используете «слепой десятипальцевый», либо занимаетесь не написанием текстов, а чем то еще.
Либо у него три руки.
ну так программирование, администрирование, веб-браузинг != написание текстов
Что есть по вашему «программирование»?
для начала, изучение предметной области и того, как сейчас решается задача, которую нужно автоматизировать
затем рисование схем, всё более детальных, как это работает и как должно рабоать
потом автоматическая кодогенерация по этим схемам, а также разработка UI
и потом наконец ручные правки, отладка
затем рисование схем, всё более детальных, как это работает и как должно рабоать
потом автоматическая кодогенерация по этим схемам, а также разработка UI
и потом наконец ручные правки, отладка
Ручные правки должны выполняться одной рукой?
Могут выполняться одной рукой. Часто они эффективно выполняются мышкой (например, в IDE прокрутить колёсиком среди методов и выбрать другой).
А почему вы игнорируете комментарий об исследованиях Apple на тему «клавиатура или мышка быстрее»?
А почему вы игнорируете комментарий об исследованиях Apple на тему «клавиатура или мышка быстрее»?
например, в IDE прокрутить колёсиком среди методов и выбрать другой
Не скачите с темы на тему.
Я задал конкретный вопрос: ручные правки должны выполняться одной рукой? Вы мне отвечаете что это возможно. Вы правите текст одной рукой?
А почему вы игнорируете комментарий об исследованиях Apple на тему
Потому что много лет назад я работал с исходным кодом аналогично, с помощью мыши и клавиатуры. Как только я отказался от этого подхода в пользу одной лишь клавиатуры, ощутил две важные вещи:
1. Я перестал отвлекаться на аппаратную модальность
2. Я подобрал для набор часто используемых команд, которые ранее выполнял с помощью мыши
We’ve done a cool $50 million of R & D on the Apple Human Interface. We discovered, among other things, two pertinent facts:
* Test subjects consistently report that keyboarding is faster than mousing.
* The stopwatch consistently proves mousing is faster than keyboarding.
This contradiction between user-experience and reality apparently forms the basis for many user/developers’ belief that the keyboard is faster.
Это по вашему называется исследованием? Вынужден вас огорчить, исследование, это когда приводятся предусловия, описывается процесс тестирования, озвучивается статистика, делается вывод. Здесь я вижу только: «мы там у себя протестировали и вот что решили...» — слишком уж похоже на старый добрый подход маркетологов. Не убедительно.
Ваши «а я попробовал и у меня получилось так» ещё менее убедительны. Тут хоть какие-то исследования, претендующие на объективность, которые кстати покрывают и ваш случай — сами субъекты уверены, что стали быстрее, хотя сторонний наблюдатель регистрирует, что это не так.
С чего вы взяли, что вы реально стали быстрее? Аппл утверждает, что вам это только кажется.
Поэтому я и прошу реальных исследований, а не самоощущений. А их что-то нет. А просто так я не согласен несколько месяцев мучиться с этой сейчас для меня совершенно неудобной программой, только для неясной цели, что вдруг она мне понравится или я стану эффективнее. А если не стану, что же получается, несколько месяцев мучений просто зазря, повёлся на слабо?
Ну и сколько я за вимерами не наблюдал, все они в реальности выполняют комплексную зачачу не быстрее меня. Было несколько бывших коллег, которые упорно пытались cd/ls/vim, а я в то же время бегал по директориям в mc и нажимал F4 для редактирования — и был впереди. Все они, как и вы, утверждали, что я ничего не понимаю, и должен, чтобы стать эффективнее, меньше отрывать руки от десятипальцевой клавиатуры и изучить vim.
С чего вы взяли, что вы реально стали быстрее? Аппл утверждает, что вам это только кажется.
Поэтому я и прошу реальных исследований, а не самоощущений. А их что-то нет. А просто так я не согласен несколько месяцев мучиться с этой сейчас для меня совершенно неудобной программой, только для неясной цели, что вдруг она мне понравится или я стану эффективнее. А если не стану, что же получается, несколько месяцев мучений просто зазря, повёлся на слабо?
Ну и сколько я за вимерами не наблюдал, все они в реальности выполняют комплексную зачачу не быстрее меня. Было несколько бывших коллег, которые упорно пытались cd/ls/vim, а я в то же время бегал по директориям в mc и нажимал F4 для редактирования — и был впереди. Все они, как и вы, утверждали, что я ничего не понимаю, и должен, чтобы стать эффективнее, меньше отрывать руки от десятипальцевой клавиатуры и изучить vim.
Ваши «а я попробовал и у меня получилось так» ещё менее убедительны
Поэтому я и не привожу статистики, вы меня вынуждаете своими маркетинговыми статьями.
Тут хоть какие-то исследования, претендующие на объективность
Нету там никаких исследований, претендующих на объективность. Я могу выплюнуть в интернет аналогичное «исследование», это не сделает его объективным.
сами субъекты уверены, что стали быстрее, хотя сторонний наблюдатель регистрирует, что это не так
А кто эти субъекты? Программисты, дизайнеры, бухгалтера? Кого исследовали?
Аппл утверждает, что вам это только кажется
Аппл много чего утверждает, но я стараюсь быть объективным.
С чего вы взяли, что вы реально стали быстрее
Я и не говорил, что стал работать быстрее.
Было несколько бывших коллег, которые упорно пытались cd/ls/vim
Предложите им воспользоваться mc или nerdtree, а не заниматься ерундой.
>Я могу выплюнуть в интернет аналогичное «исследование», это не сделает его объективным.
А вы точно многомиллиардная корпорация с высоким уровнем доверия людей?
А вы точно многомиллиардная корпорация с высоким уровнем доверия людей?
А вы точно многомиллиардная корпорация с высоким уровнем доверия людей?
По вашему мнению любое слово многомиллиардной корпорации с высоким (спорное утверждение) уровнем доверия людей должно восприниматься догматически? Бедный хабр… (
Да к этом огрызку нет доверия, как него его и к апплу в целом. Было бы это статьёй в реферируемом журнале — я бы даже слушать никого не стал. Но к личным ощущениям анонима, пишущему писюльки на хабр, доверия ещё меньше.
Если нет особых альтернатив, то почему бы и нет?
Даже если бы были — доверие мнению, отличному от вашего, пороком не является. Так что не такой уж хабр и бедный
Даже если бы были — доверие мнению, отличному от вашего, пороком не является. Так что не такой уж хабр и бедный
Если нет особых альтернатив, то почему бы и нет?
Потому что это далеко от истинны. Вы либо верьте, либо знайте, но не смешивайте одно с другим.
доверие мнению, отличному от вашего, пороком не является
Не является, как и не является сколько нибудь объективным. Верить вам никто не запрещает, но не нужно выдавать свою веру за истину.
Я ничего не выдаю, больше скажу, мое мнение по вопросу не высказывалось тут нигде в принципе
Поэтому упреки про смешивание и объективность тут не совсем к месту
Поэтому упреки про смешивание и объективность тут не совсем к месту
Поясните, кстати, как может быть объективным любое утверждение, опирающееся на субъективное восприятие людей.
Объективные показатели — это что-нибудь вроде человеко-строк кода в час. Хотя это само по себе вообще не критерий чего бы то ни было (ну разве что программистам платят за количество выданных на-гора строк)
Объективные показатели — это что-нибудь вроде человеко-строк кода в час. Хотя это само по себе вообще не критерий чего бы то ни было (ну разве что программистам платят за количество выданных на-гора строк)
Поясните, кстати, как может быть объективным любое утверждение, опирающееся на субъективное восприятие людей
Никак. Я разве утверждал обратное?
Ваши слова?-
> Тут хоть какие-то исследования, претендующие на объективность, которые кстати покрывают и ваш случай…
Тут сплошь вопросы вкуса, так что у каждого своя правда, и объективности как бы нет и не нужно.
> Тут хоть какие-то исследования, претендующие на объективность, которые кстати покрывают и ваш случай…
Тут сплошь вопросы вкуса, так что у каждого своя правда, и объективности как бы нет и не нужно.
Ваши слова?
Похоже на мой комментарий?
Тут сплошь вопросы вкуса, так что у каждого своя правда, и объективности как бы нет и не нужно
Так я никому не навязываю свою правду.
Это мои слова.
Нет, это не вопросы вкуса. Мне предлагают другой инструмент, да ещё и говорят, что я дурак, что не соглашаюсь, а я не соглашусь пока не будет убедительных доказательств, что мне это могло бы принести пользу и хотя бы кому-то вообще это приносит пользу. Тратить время и учиться я не хочу, я хочу сначала убедиться в том, что есть, ради чего тратить время.
Поэтому я и не привожу статистики, вы меня вынуждаете своими маркетинговыми статьями.
Конкретно моя с вами дискуссия начачась вот с этого вашего комментария. Вы первый предложили мне потратить время на изучение чего-то. И ни вы, ни кто-либо иной не смогли преложить никакого обоснования, что это мне может принести пользу или что оно кому-то принесло эту пользу, хотя я постоянно прошу таких обоснований.
А теперь вы утверждаете, что я вас вынуждаю. Да не вынуждаю, просто если не готовы реально аргументировать свои утверждения про медленность мышки, быстроту десятипальцевой работы без отрыва от клавиатуры и так далее — не вступайте пожалуйста в дискуссию.
И вообще я теперь очень хочу запретить вимерам писать про то, какой вим хороший и как они стали быстро работать, пока в каком-нибудь университете не проведут такое исследование.
А кто эти субъекты? Программисты, дизайнеры, бухгалтера? Кого исследовали?
По умолчанию, в таких случаях — все люди. Все, кто работает с компьютером и у кого есть возможность не использовать мышку. Среднее по больнице. В среднем, мышка всё-таки быстрее.
не смогли преложить никакого обоснования, что это мне может принести пользу
Я и не пытался. Если вы выбрали для себя удобный инструмент, я только рад за вас. Пользуйтесь им и даже не думайте смотреть в сторону других инструментов (я серьезно).
А теперь вы утверждаете, что я вас вынуждаю
Совершенно так, вы вынуждаете меня приводя какие то пустые сообщения из интернета.
готовы реально аргументировать
Думаю под «реальной аргументацией» вы имеете ввиду статистическое исследование? У меня такового нет, и ни у кого нет. Если вы такое найдете, обязательно дайте мне знать, буду благодарен.
И вообще я теперь очень хочу запретить вимерам писать про то, какой вим хороший и как они стали быстро работать, пока в каком-нибудь университете не проведут такое исследование
Нужно не столько запрещать, сколько требовать от заявителя доказательств. Этого достичь проще, нежели пытаться что то запрещать.
Нужно не столько запрещать, сколько требовать от заявителя доказательств. Этого достичь проще, нежели пытаться что то запрещать.
Да! А он отвечает:
Я и не пытался. Если вы выбрали для себя удобный инструмент, я только рад за вас. Пользуйтесь им и даже не думайте смотреть в сторону других инструментов (я серьезно).
Но меня тут назвали дураком и мои инструменты дурацкими, мне обидно.
С чего вы взяли, что вы реально стали быстрее? Аппл утверждает, что вам это только кажется.
Интереснее другое: насколько это важно не машинистке, а программисту.
Вы правите текст одной рукой?
Бывает и такое. Например, когда надо удалить по одному символу в произвольных местах, удобно курсор перемещать мышью, второй рукой нажимать Del. Но это частности, конечно. Само высказывание о трудоемкости переброски руки — сомнительно.
Само высказывание о трудоемкости переброски руки — сомнительно
Ну то что элементарная частица может быть в двух местах одновременно, тоже довольно сомнительное высказывание, но что поделать, не все упирается в наши предпочтения и веру.
Это не вопрос предпочтений и веры, а математическая модель. Никакого сходства, аналогия совершенно неуместная.
Итак, высказывание о переброске руки реально очень сомнительно. Я вчера весь день за собой следил, это не медленнее, чем дотянуться до ctrl+c или esc или смены раскладки (у меня это caps lock)
Итак, высказывание о переброске руки реально очень сомнительно
Повторю еще раз, для особо сомневающихся — ваши сомнения не имеют никакого отношения к объективной реальности. Засеките время переброса руки и тыке по иконке в быстром меню и время нажатия клавиш, на пример, 'gc.
У меня получилось (только на переброс руки с клавиатуры на мышь и обратно) ~ 1.1 секунды
Против ~ 0.5 секунды
Повторю еще раз, для особо сомневающихся — ваши сомнения не имеют никакого отношения к объективной реальности.
Я тоже могу повторить раз 10 для непонятливых: ваше субъективное понятие быстроты или трудоемкости не имеет отношения к реальности. Просто потому что это чисто субъективные понятия. Ваши.
Выше вы некрасиво передернули:
Ну то что элементарная частица может быть в двух местах одновременно, тоже довольно сомнительное высказывание, но что поделать, не все упирается в наши предпочтения и веру.
В то время, как я говорил лишь о том, что высказывание о трудоемкости — сомнительно.
Речь идет об исчезающей значимости разницы во времени, а не о якобы отсутствии разницы, на что упираете вы.
Засеките время переброса руки и тыке по иконке в быстром меню и время нажатия клавиш, на пример, 'gc.
При чем тут это? Макросы обычных редакторов никто не отменял. Весь сыр-бор разгорелся из-за позиционирования курсора, а не тыканья мышкой по иконкам вместо клавиатурных комбинаций.
Просто потому что это чисто субъективные понятия. Ваши
Ну так берите секундомер и меряйте, если сомневаетесь. Я померил, вон мой результат.
В то время, как я говорил лишь о том, что высказывание о трудоемкости — сомнительно.
Речь идет об исчезающей значимости разницы во времени, а не о якобы отсутствии разницы, на что упираете вы
О чем бы не шла там речь, такие вещи нужно оценивать объективно с секундомером в руках, иначе это пустые слова, не более того.
Весь сыр-бор разгорелся из-за позиционирования курсора, а не тыканья мышкой по иконкам вместо клавиатурных комбинаций
А если у меня привычное положение — одна рука на клаве, вторая на мышке?
О чем говорит такое привычное положение? О том что человек чаще пользуется мышью, нежели комбинациями клавиш. Не согласны?
Т.е. вы сначала пишете случайные имена методов, а потом колесиком мышки выбираете из списка другие, более подходящие?
Что это за стиль такой?
Можно еще мышкой по экранной клаве тыкать.
Что это за стиль такой?
Можно еще мышкой по экранной клаве тыкать.
А я бы так ответил
1. изучение предметной области
2. поиск библиотек или проектов, реализующих отдельные аспекты задачи (может быть даже почти всю задачу), и их изучение, включая чтение документции сборку, запуск, небольшую модификацию и отладку примеров
3. соединение этих библиотек вместе и написание необходимого соединительного кода
4. отладка, отладка и еще раз отладка того что получилсь :)
1. изучение предметной области
2. поиск библиотек или проектов, реализующих отдельные аспекты задачи (может быть даже почти всю задачу), и их изучение, включая чтение документции сборку, запуск, небольшую модификацию и отладку примеров
3. соединение этих библиотек вместе и написание необходимого соединительного кода
4. отладка, отладка и еще раз отладка того что получилсь :)
Прекрасно. Из всего вышеперечисленного для чего вы используете редактор или IDE?
2,3,4
Как с помощью редактора/IDE вы ищите проекты и библиотеки?
По 3 и 4 пунктам — вы пишите текст одной рукой?
По 3 и 4 пунктам — вы пишите текст одной рукой?
По пункту 2 — компилирую, провожу эксперименты и отлаживаю в IDE.
Текст набираю двумя руками — но программирование это не та сфера, где нужно набирать много текста. Большая часть времени — это медитация над исходниками, документацией и результатами работы программ.
Пожалуй 50% рабочего времени я руками вообще ничего не делаю. Правая рука просто лежит рядом с мышкой и клавиатурой на столе, левая на левом краю клавиатуры. Где-то 35% кручу колесо и щелкаю мышью и только 15% набираю и исправляю текст.
Текст набираю двумя руками — но программирование это не та сфера, где нужно набирать много текста. Большая часть времени — это медитация над исходниками, документацией и результатами работы программ.
Пожалуй 50% рабочего времени я руками вообще ничего не делаю. Правая рука просто лежит рядом с мышкой и клавиатурой на столе, левая на левом краю клавиатуры. Где-то 35% кручу колесо и щелкаю мышью и только 15% набираю и исправляю текст.
Ну так я веду речь о написании текста. К чему эти аргументы вида — а программирование это не только написание текста — я все никак не могу понять (
Ну так набор текста занимает незначительную часть общего времени, чтобы экономить миллисекунды.
Так вот интересно, какой текст в больших объёмах набирают поклонники Vim. Романы пишут, что ли? Мне правда интересно.
Поставьте себе счетик нажатия на клавиши клавиатуры и мыши. Очень удивитесь — какую огромную долю занимают цифро-буквенные нажатия, то есть как много пишет/исправляет средний программист.
Это надо считать только при наборе кода. Между набором непосредственно кода программы много времени уходит на браузер и прокрастинацию, к сожалению.
Серфинг не считается? Или вы программу простыней набираете?
А как сёрфинг связан с Vim?
Напрямую. Эхх… Очередной хейтер, который знаком с Vim на уровне «двоюродный коллега один раз запускал и ему не понравилось» (
Я уже писал здесь, что использую Vim постоянно для задач, которые в нём выполняются лучше всего. Линуксом пользуюсь чуть более восьми лет, Vim'ом примерно столько же. Зачем вы переходите на личности? Мне по-прежнему неочевидна связь сёрфинга и редактора текста. В Emacs есть встроенный браузер, но он, очевидно, не подходит для современных сайтов, ориентированных под Webkit/ES5/Мышь/Тач. Для Vim я ничего такого не видел. Если вы намекаете на Vimperator и Vimium (для Chrome), то они тоже являются лишь дополнениями, но никак не связаны с редактированием текста.
При чем тут серфинг и браузеры? Я разве говорю об интернет-серфинге? Серфить можно и исходные коды проекта, и документацию, и тесты, и еще много чего.
Впервые встречаю это слово в таком значении. В эклипсе для навигации эффективнее использовать и мышь, и клавиатуру. Чаще всего мне требуется найти вызов метода по проекту и перейти к определению. Как опять же писалось тут, сомнительно, что Vim сможет определить правильную перегрузку функции или выбрать правильный метод для объекта, если есть несколько одинаково названных методов в разных классах (например, run() или start()). Когда происходит вызов такого метода, нужно учитывать тип объекта, для которого он вызывается, чтобы найти определение. Для определения типа нужно как минимум распарсить код и найти определение переменной, иногда вывести её тип (как в случае с ключевым словом auto в C++), иногда отрезолвить цепочку typedef'ов. Eclipse справляется с этим без проблем, а что делать в Vim? И это я ещё не трогаю рефакторинг, без которого в большом проекте будет нелегко.
Вопрос в том, так ли важен быстрый набор текста, если отсутствуют средства удобного и надёжного контроля кода? Я понимаю, что вряд ли смогу вам что-то доказать, но может, хоть заставлю задуматься.
Вопрос в том, так ли важен быстрый набор текста, если отсутствуют средства удобного и надёжного контроля кода? Я понимаю, что вряд ли смогу вам что-то доказать, но может, хоть заставлю задуматься.
Впервые встречаю это слово в таком значении
Но ведь оно для описания действий прекрасно подходить, разве нет?
а что делать в Vim?
Vim не умеет семантику, потому серфинг в Vim больше сводится к другой области управления (более мелкой или более специфичной). Было бы прекрасно, если бы кто нибудь таки включил Vim в качестве основного редактора в какой нибудь Eclips (на пример).
Вопрос в том, так ли важен быстрый набор текста
Набор текста это не только печатание (как многие тут считают), это и микросерфинг и макросерфинг по проекту. Vim с этим прекрасно справляется.
средства удобного и надёжного контроля кода?
О каких средствах идет речь?
>Но ведь оно для описания действий прекрасно подходить, разве нет?
Возможно, я лишь сказал, что не встречал его в таком значении.
>серфинг в Vim больше сводится к другой области управления (более мелкой или более специфичной)
>микросерфинг и макросерфинг по проекту
Непонятно, что же это такое. Открытие разных файлов и переход между ними? По-моему, это не так полезно, как семантическая навигация.
>О каких средствах идет речь?
Рефакторинг и Quick Fix (автоматическая генерация кода и исправление типичных ошибок), в основном, иногда анализ ресурсов на предмет соответствия коду, как в Android Studio проверка соответствия типа view из XML типу в коде и в Eclipse проверка наличия определения контрола в ui.xml, если он определён в аннотации @UiField (это для UiBinder из GWT). Автоматический рефакторинг позволяет не беспокоиться, что где-то что-то не исправилось как ожидалось, либо изменилось что-то, что не должно было. Возможно, он не идеален и тоже может накосячить, но я с таким пока не сталкивался.
Возможно, я лишь сказал, что не встречал его в таком значении.
>серфинг в Vim больше сводится к другой области управления (более мелкой или более специфичной)
>микросерфинг и макросерфинг по проекту
Непонятно, что же это такое. Открытие разных файлов и переход между ними? По-моему, это не так полезно, как семантическая навигация.
>О каких средствах идет речь?
Рефакторинг и Quick Fix (автоматическая генерация кода и исправление типичных ошибок), в основном, иногда анализ ресурсов на предмет соответствия коду, как в Android Studio проверка соответствия типа view из XML типу в коде и в Eclipse проверка наличия определения контрола в ui.xml, если он определён в аннотации @UiField (это для UiBinder из GWT). Автоматический рефакторинг позволяет не беспокоиться, что где-то что-то не исправилось как ожидалось, либо изменилось что-то, что не должно было. Возможно, он не идеален и тоже может накосячить, но я с таким пока не сталкивался.
Непонятно, что же это такое.
Микросерфинг это, к примеру, замена блока кода, переход к аргументам функции, переход к началу слова и т.д. Этих действий в процессе набора исходных кодов выполняется уйма.
Открытие разных файлов и переход между ними? По-моему, это не так полезно, как семантическая навигация
Смотря для каких целей. Я раньше обожал семантическую навигацию, потом полюбил хорошо структурированные проекты и необходимость в ней как то отпала. За последний год я использую ее реже, чем операцию коммита изменений.
Рефакторинг
Я об этом уже много раз писал, потому отвечу коротко — я рефакторю что то настолько редко (если раз в день переименую один метот, то это будет событием), что мне достаточно грепнуть по проекту и за 5 минут все закончить.
Quick Fix
Аналогично с рефакторингом. У меня для генерации кода свои механизмы, и они только облегчают набор шаблонов, а шаблоны рефакторить нет необходимости, да и типичных ошибок в них нет.
Автоматический рефакторинг позволяет не беспокоиться, что где-то что-то не исправилось как ожидалось, либо изменилось что-то, что не должно было
Для этого предпочитаю тесты и онлайн сервисы проверки исходных кодов.
Программы пишут. Не одну функцию в день, а реальный функционал.
Вот хотелось бы посмотреть на процесс. Не исключено, что я просто тугодум и не умею писать простынями, а вместо этого больше думаю, чем печатаю. Поэтому и скорость набора не является для меня критичной, и поэтому интересно увидеть, как работают другие. Видел стрим на twitch, где разработчик Crea исправлял баг, там собственно ввода было минимум, больше навигации по коду.
а вместо этого больше думаю, чем печатаю
А это взаимоисключающая деятельность?
Вот хотелось бы посмотреть на процесс
Где то на хабре я выкладывал ссылку на видео. Можете поискать если интересно.
Вообще-то статья именно о преимуществах vi/vim при редактировании а не наборе текста. В больших объемах набирать plain text вообще безразлично в чем, да хоть в notepad.
Мощь vim проявляется именно при редактировании (изменении, исправлении, форматировании, небольшом дополнении) в командном режиме.
Мощь vim проявляется именно при редактировании (изменении, исправлении, форматировании, небольшом дополнении) в командном режиме.
не используете «слепой десятипальцевый»
Можно подумать, вы программируете код в редакторе со скоростью 500 символов в секунду! Никогда не знал, что в программировании важна скорость ввода текста!
А при чем тут скорость ввода текста? Вы вообще мой комментарий прочитали?
Программист регулярно серфит по исходному тексту, заменяет, ищет и пр.
Так что да — каждое нажатие клавиши имеет значение и оптимизация работы по работе с исходником (не важно vim это или Ctrl+Shift+Right) освобождает больше времени для «чисто подумать» над кодом или почитать Хабр.
Довольно странно вообще видеть человека, позицирующего себя как профессионального программиста, который выделяет куски текста чисто мышью и копирует/вырезает их правой клавишей мыши.
Исключение разве что текстовый редактор acme, который специально заточен на мышетекстовое управление.
https://habrahabr.ru/post/208482/
Так что да — каждое нажатие клавиши имеет значение и оптимизация работы по работе с исходником (не важно vim это или Ctrl+Shift+Right) освобождает больше времени для «чисто подумать» над кодом или почитать Хабр.
Довольно странно вообще видеть человека, позицирующего себя как профессионального программиста, который выделяет куски текста чисто мышью и копирует/вырезает их правой клавишей мыши.
Исключение разве что текстовый редактор acme, который специально заточен на мышетекстовое управление.
https://habrahabr.ru/post/208482/
Дело не в скорости как таковой. Просто после овладевания слепым десятипальцевым методом на приличном уровне меньшая часть мозга задействована на то, чтобы что-то напечатать. Напечатать что-то – это вообще не задача. Вам не нужно переводить взгляд. Не нужно задумываться, где какие кнопки. Не нужно позиционировать руки над клавиатурой. Это куча мелочей, которые выбивают из потока. Вы вообще не отвлекаетесь. Вы просто смотрите в экран, а там сам собой появляется текст, о котором вы думаете. И вот это как раз важно. Полагаю, мастерское владение vi/vim может дать схожий эффект. Не знаю. Не владею :)
Если одна рука на asdw, а вторая на мышке — тогда удобно. Для печати, на мой взгляд, не очень.
Ну если вы писатель, то да. А если программист?
Я вот обычно сижу, думаю над кодом, неспешно прокручиваю его колесом мыши… иногда делаю переходы по дереву классов, или контекстные переходы типа «go to definition» — тоже мышью… время от времени переключаюсь на чтение документации опять-таки ничего не пишу, а только читаю и кручу мышью… иногда переключаюсь на браузер, там да — нужно набить фразу в поисковике, хотя часто можно сделать копи-паст мышью (например имя функции или сообщение об ошибке), а нередко прямо в программе в контекстном меню встроена команда «найти в гугле» (и думаю вскорости эта команда будет во всех ридерах и IDE).
И только иногда, когда вдруг в голове складывается полное понимание того, что нужно написать — откладываю мышь в сторону и пишу какой-нибудь кусок кода. Уже сразу обеими руками на клавиатуре.
Я вот обычно сижу, думаю над кодом, неспешно прокручиваю его колесом мыши… иногда делаю переходы по дереву классов, или контекстные переходы типа «go to definition» — тоже мышью… время от времени переключаюсь на чтение документации опять-таки ничего не пишу, а только читаю и кручу мышью… иногда переключаюсь на браузер, там да — нужно набить фразу в поисковике, хотя часто можно сделать копи-паст мышью (например имя функции или сообщение об ошибке), а нередко прямо в программе в контекстном меню встроена команда «найти в гугле» (и думаю вскорости эта команда будет во всех ридерах и IDE).
И только иногда, когда вдруг в голове складывается полное понимание того, что нужно написать — откладываю мышь в сторону и пишу какой-нибудь кусок кода. Уже сразу обеими руками на клавиатуре.
А как вы позиционируете текстовый курсор в нужное место? Вопрос без сарказма, мне правда интересно. Вот я вижу точку на экране, в которую ткнул бы мышью — что вместо этого я должен сделать в виме/емаксе? Самый быстрый способ, до кторого я пока додумался — вызвать поиск и набрать сочетание символов из этого места, уповая, что оно уникально. Но даже если оно таки уникально, выходит, по-моему, не быстрее тычка мышкой, а если их таких оказалось несколько — так и тем более.
А как вы позиционируете текстовый курсор в нужное место?
В Vim для этого есть normal mode.
Вот я вижу точку на экране, в которую ткнул бы мышью
При работе с текстом, автор оперирует синтаксическими конструкциями, а не точками на экране. Для них в Vim есть множество команд перевода курсора.
Ну ок, и какая команда для «спозиционируй мне курсор на начало четвертого формального параметра пятью строками ниже»?
У меня это ss который дергает easymotion.
Как ни крути — это будут разные комбинации. А позицинирование мышью — универсально.
Позиционирование мышью тоже требует различных сокращений мускулатуры, что с того?
Когда ходите — вообще караул. Это автоматизированное, рефлекторное действие. Одинаковое, универсальное. В отличие от. Есть баланс этих инструментов.
В отличие от
Очередное безосновательное заявление. Вот он я, и у меня работа с easymotion так же рефлекторно.
Клавиши перемещения курсора прямо на буквах — руки не нужно переносить. Можно возразить, что курсором медленно позиционировать. Но учитывая время перемещения рук до мышки, позиционирование курсора и обратно на клавиатуру, перемещение сразу с клавиатуры может быть более быстрым. Ведь если нужно переместить на пять строчек вверх и 30 символов влево достаточно нажать клавиши вверх и влево по одному разу. А можно еще и через слова прыгать! А время нажатия определяет перемещение. Кажется удивительным, но после тренировки точность перемещения за одиночное нажатие клавиши управления курсором достаточно высока.
> Ведь если нужно переместить на пять строчек вверх и 30 символов влево достаточно нажать клавиши вверх и влево по одному разу.
Это как?
Насколько я помню, в Виме можно собрать команду в командном режиме, которая уведёт курсор на пять строчек вверх и на 30 символов влево. Но это точно будет не «вверх и влево по разу». Это будет само по себе уже медленнее, чем дотянуться до мышки и обратно. Плюс к тому еще понадобится время на обдумывание, на сколько именно строк ты хочешь вверх и на сколько именно символов влево. Выше в комментариях товарищи пишут, как их «выкидывает из потока» необходимость тянуться за мышкой — а меня вот, например, начисто вышибает из потока как раз необходимость переключаться с раздумий о коде, который я пишу, на очередную заковыристую команду вима, а потом обратно. Возможно, к этому привыкаешь и, привыкнув, выполняешь на автомате — не знаю, я не смог.
И в этом вообще была моя главная проблема с Вимом, да и с Емаксом, до некоторой степени. Как редакторы-то они мощные и легко уделают любое IDE, без дураков. Более того, ниже товарищ пишет, что-де вот то да сё в Эклипсе удобнее чем в Виме — да, вполне может быть, что конкретное «то» и «се» действительно удобнее в IDE, но это только для каких-то совершенно определенных вещей, которые предусмотрели разработчики данного IDE, а в Виме из стандартного набора можно что хочешь собрать, о чем разработчики, возможно, и в страшном сне не помышляли. Но проблема в том, что эти преимущества Вима проявятся в полной мере только на какой-то нетривиальной задаче редактирования, возникающей раз в месяц, а то и реже. Допустим, я подумал, загуглил, еще подумал и нашёл способ, как сделать это в Виме супер-пупер-эффективно. С учётом времени на раздумья и гугление, я бы давно уже сделал то же самое в IDE, потыкав куда надо мышкой, конечно. Но теперь-то я уже умею в Виме и в следующий раз сразу быстро и эффективно сделаю, да? Нет. Ибо задача нетривиальна и понадобится её решать опять через месяц, за который я благополучно забуду своё нынешнее решение начисто. В результате опять думать, опять гуглить, и опять быстрее было бы потыкать мышкой в иде. Та же картина, кстати, и для ещё одной иконы опенсорса, написанной много лет назад, но до сих пор превосходящей и затмевающей — системы TeX. Всякий знает — ну или хотя бы слышал — что набирать формулы в TeX гораздо быстрее, чем в Word, и это факт. Вот только мало кто сидит и день за днём, час за часом долбит одни и те же формулы — прежде надо эксперименты поставить, расчёты провести, тексты написать, синтаксис формул опять успеешь забыть, опять гугль, опять дотянулся проклятый Кнут… (TeX крут, тем не менее, просто его истинная крутизна в другом.)
Это как?
Насколько я помню, в Виме можно собрать команду в командном режиме, которая уведёт курсор на пять строчек вверх и на 30 символов влево. Но это точно будет не «вверх и влево по разу». Это будет само по себе уже медленнее, чем дотянуться до мышки и обратно. Плюс к тому еще понадобится время на обдумывание, на сколько именно строк ты хочешь вверх и на сколько именно символов влево. Выше в комментариях товарищи пишут, как их «выкидывает из потока» необходимость тянуться за мышкой — а меня вот, например, начисто вышибает из потока как раз необходимость переключаться с раздумий о коде, который я пишу, на очередную заковыристую команду вима, а потом обратно. Возможно, к этому привыкаешь и, привыкнув, выполняешь на автомате — не знаю, я не смог.
И в этом вообще была моя главная проблема с Вимом, да и с Емаксом, до некоторой степени. Как редакторы-то они мощные и легко уделают любое IDE, без дураков. Более того, ниже товарищ пишет, что-де вот то да сё в Эклипсе удобнее чем в Виме — да, вполне может быть, что конкретное «то» и «се» действительно удобнее в IDE, но это только для каких-то совершенно определенных вещей, которые предусмотрели разработчики данного IDE, а в Виме из стандартного набора можно что хочешь собрать, о чем разработчики, возможно, и в страшном сне не помышляли. Но проблема в том, что эти преимущества Вима проявятся в полной мере только на какой-то нетривиальной задаче редактирования, возникающей раз в месяц, а то и реже. Допустим, я подумал, загуглил, еще подумал и нашёл способ, как сделать это в Виме супер-пупер-эффективно. С учётом времени на раздумья и гугление, я бы давно уже сделал то же самое в IDE, потыкав куда надо мышкой, конечно. Но теперь-то я уже умею в Виме и в следующий раз сразу быстро и эффективно сделаю, да? Нет. Ибо задача нетривиальна и понадобится её решать опять через месяц, за который я благополучно забуду своё нынешнее решение начисто. В результате опять думать, опять гуглить, и опять быстрее было бы потыкать мышкой в иде. Та же картина, кстати, и для ещё одной иконы опенсорса, написанной много лет назад, но до сих пор превосходящей и затмевающей — системы TeX. Всякий знает — ну или хотя бы слышал — что набирать формулы в TeX гораздо быстрее, чем в Word, и это факт. Вот только мало кто сидит и день за днём, час за часом долбит одни и те же формулы — прежде надо эксперименты поставить, расчёты провести, тексты написать, синтаксис формул опять успеешь забыть, опять гугль, опять дотянулся проклятый Кнут… (TeX крут, тем не менее, просто его истинная крутизна в другом.)
UFO just landed and posted this here
Ага, мне тоже кажется, что в основном этим он и хорош. Или когда твою статью не принимают в один журнал — пошёл на сайт другого журнала, скачал их стилевой файл, пересобрал документ с ним, послал туда. Теоретически как бы и в Ворде как-то так тоже можно, но на практике потом затрахаешься вручную править форматирование практически везде.
С TeX проблема в том, что не существует вменяемого конвертера из TeX в Word. Именно поэтому я так и не смог перейти ни на TeX, ни на LyX — ведь всюду требуется исключительно Word. Куда я потом этот TeX-документ дену? Да даже среди научных издательств крайне мало таких, которые ещё принимают TeX-документы, и даже они пишут, что предпочтительнее всё же Word.
В этом плане Markdown гораздо юзабельнее — там нет проблем с конвертированием, у него глаже кривая обучения, а благодаря расширениям он крайне богат возможностями.
В этом плане Markdown гораздо юзабельнее — там нет проблем с конвертированием, у него глаже кривая обучения, а благодаря расширениям он крайне богат возможностями.
Клавиши перемещения курсора прямо на буквах появились потому, что давным давно в старых терминалах передавались в основном печатаемые символы, и стрелки не передавались. Так появилось перемещение курсора буквами. Просто исторически сложилось.
Вот я вижу точку на экране, в которую ткнул бы мышью — что вместо этого я должен сделать в виме/емаксе?
В vim можно использовать easymotion
А в emacs или avy или ace-jump-mode.
Все они работают на похожем принципе:
- нажимаете хоткей, затем вводите первую букву слова на которое надо перепрыгнуть
- редактор подсвечивает все слова начинающиеся с выбранной буквы
- выбираете на какое именно слово прыгнуть
Так можно за 3-4 нажатия клавиш переместиться в любое место на экране.
Разумеется можно переходить не только к началу слова, но и в произвольное место.
Я последнее время еще полюбил vim-sneak/evil-snipe
нажимаете хоткей, затем вводите первую букву слова на которое надо перепрыгнуть
Круто. У нас CodeGuide предполагает все формальные параметры начинать с буквы «A», как раз подойдет — скажем, ф.п. штук пять и нужен последний.
Так можно за 3-4 нажатия клавиш переместиться в любое место на экране.
Оно того стоит, если тронуть мышь — пол-секунды?
Ну во-первых можно прыгнуть на вторую букву, во-вторых пока количество формальных параметров на экране меньше чем 26, вы все равно в три keystroke попадете на букву А.
Я не знаю, удобнее ли это чем мышка для тех, кто хорошо владеет мышкой, я мышкой владею плохо, мне EasyMotion намного удобнее.
> все формальные параметры начинать с буквы «A»
Вроде, как раз с этим проблем быть не должно — посмотрите по ссылкам выше avy, у него, по-моему, на картинках понятнее всего объяснено, как это работает. Очень интересный принцип, доберусь до емакса — обязательно попробую.
Вроде, как раз с этим проблем быть не должно — посмотрите по ссылкам выше avy, у него, по-моему, на картинках понятнее всего объяснено, как это работает. Очень интересный принцип, доберусь до емакса — обязательно попробую.
Оно того стоит, если тронуть мышь — пол-секунды?
А это каждый решает сам для себя. Редактор предоставляет возможность перемещаться с помощью мыши и клавиатуры, что больше нравится — то и используйте.
UPD: УПС: опередили выше про avy
В emacs есть https://github.com/abo-abo/avy
Очень удобно. Работает, даже если открыто несколько виртуальных окон
В emacs есть https://github.com/abo-abo/avy
Очень удобно. Работает, даже если открыто несколько виртуальных окон
Вим\Емакс это не какие-то суровые редакторы для перфокарт. Там тоже есть гуй и поддержка мышки. И даже в консоли типа iterm2 есть поддержка мышки.
UFO just landed and posted this here
Ниже уже где-то писали про AceJump (видео демо), добавлю, что есть в IDEA плагинчик. Всё-таки, даже рефлекторное и отработанное движение мышью не моментальное по той только причине, что вы не можете точно сказать где окажется курсор перед движением. Само движение строится на обратной связи текущего положения курсора (то есть вы смотрите как он движется и по ходу корректируете скорость/направление). Что, как бы, очевидно, менее эффективно, чем клавиатурное (даже если не AceJump, то можно просчитать наперёд при ручном перемещении).
И да, я до сих пор позиционирую курсор мышью (трекпадом, если точнее).
Мышь, может, и не моментально, — а вот тачпад (или айбиэмовский прыщик) — очень даже моментально.
Всяко пошустрее, чем комбинации вида «прыгни-ка к первому вхождению символа „f“», если их там много. Да и позиционирование мышью — непосредственное. Это просто удобнее.
Где-то год назад я программировал одну исследовательскую хрень с использованием gaze tracker (прибора, определяющего точку на мониторе, куда смотрит юзер). Была мысль попробовать запилить установку текстового курсора по хоткею прямо в точку взгляда. Напрямую водить указатель мыши взглядом было уныло — точность позиционирования так себе, и из-за шумов в измерениях он еще дрожит, как рука алкоголика. Но поставить где-то в пределах трёх нажатий на стрелки от нужной позиции, возможно, удалось бы. К сожалению, девайс у меня отняли раньше, чем руки дошли попытаться чего-то сделать в данном направлении…
Это вы ThinkPad'ом никогда не пользовались.
Его трекпоинт позволяет делать это, вообще не отрывая руки от клавиатуры.
Я уж молчу о том, что в моем понимании «моментальная навигация» — это прыгнуть к нужному классу/файлу/функции в проекте или исходниках библиотеки (и потом обратно, а лучше — и вовсе в отдельном окне показать), а не в пределах экрана-двух на регулярках ерзать.
Его трекпоинт позволяет делать это, вообще не отрывая руки от клавиатуры.
Я уж молчу о том, что в моем понимании «моментальная навигация» — это прыгнуть к нужному классу/файлу/функции в проекте или исходниках библиотеки (и потом обратно, а лучше — и вовсе в отдельном окне показать), а не в пределах экрана-двух на регулярках ерзать.
:set mouse=a
моментального? рука перемещается на мышь — рука с мышью перемещается в нужное место — рука с мыши возвращается на клавиатуру.
UFO just landed and posted this here
Вы понимаете значение слова «моментально»? Одна-две секунды это не моментально.
1/125 секунды — тоже. И?
И зачем тогда говорить, что это моментально? Для красивого словца?
Зачем тогда саркастически спрашивать «вы понимаете значение млова „моментально“» и сравнивать с 1-2 секундами, если это значение не определено в числах?
Затем, чтобы люди таки научились пользоваться своим лексиконом, а не занимались демагогией, выплевывая в комментарии терминологию, не имеющую никакого отношения к реальности.
Демагогией здесь занимаетесь вы, с претензией на объективность.
Слово «моментально» в контексте разговора, очевидно, означает, что продолжительность промежутка в абсолютных значениях не имеет роли, т.к. пренебрежительно мала по сравнению с другими действиями. Ваши попытки переходить к абсолютным числам выглядят нелепо.
Слово «моментально» в контексте разговора, очевидно, означает, что продолжительность промежутка в абсолютных значениях не имеет роли, т.к. пренебрежительно мала по сравнению с другими действиями. Ваши попытки переходить к абсолютным числам выглядят нелепо.
что продолжительность промежутка в абсолютных значениях не имеет роли
Когда человек привык отвлекаться от основной деятельности на 1-2 секунды, для него это не имеет роли. Мы говорим о Vim, редакторе, который позволяет пользователю писать программы «со скоростью мысли», а в его контексте термин «моментально» играет огромную роль.
Перенос руки с клавиатуры на мишь и обратно — это не моментально.
Когда человек привык отвлекаться от основной деятельности на 1-2 секунды, для него это не имеет роли. Мы говорим о Vim, редакторе, который позволяет пользователю писать программы «со скоростью мысли», а в его контексте термин «моментально» играет огромную роль.
Мы говорим о том, имеет ли значение скорость ввода как таковая.
Перенос руки с клавиатуры на мишь и обратно — это не моментально.
Слово «моментально» в контексте разговора, очевидно, означает, что продолжительность промежутка в абсолютных значениях не имеет роли, т.к. пренебрежительно мала по сравнению с другими действиями. Ваши попытки переходить к абсолютным числам выглядят нелепо.
Мы говорим о том, имеет ли значение скорость ввода как таковая
Не только скорость ввода, но и отвлечение. Естественно, эти микросекунды в результате складываются в секунды и десятки секунд, но что еще более противное, так это то, что эти мелкие действия не дают мозгу полноценно сосредоточиться на задаче. Вместо размышления над задачей, нужно искать переферийным зрением мышь, затем курсор, затем целевую позицию, заниматься перекладыванием ладоней и т.д. Это отвлекает.
Повторюсь, если бы это делалось моментально, то это не имело бы значение, но это не так.
за компом сижу много, но, чтобы найти глазами курсор, зачастую надо пошерудить мышкой. Плюс, позиционирование ее у меня выглядит как затухающее колебание на 1-2 периода. Это я вот сейчас специально попробовал. В виме либо перескоки на несколько строк автоматом руки делают, либо быстрее поиском, он тоже начинает автоматически набираться
В gvim это, к сожалению, есть. Очень хочу научиться эту возможность отключать — бесит, когда переключаешь мышью окно и курсор оказывается в непредсказуемом месте.
:set mouse=cВ этом режиме вставка из системного буфера обмена стала даже удобнее. А вот как скопировать в буфер я так и не понял (по крайней мере в windows ). Видимо придется документацию почитать…
"*yy
"+Y
также см. How can I copy text to the system clipboard from Vim?А что вы делаете, если нужно что-то сделать с текстом с планшета, где мышь отсутствует, ткнуть пальцем можно примерно в 3-5 соседних символов, а клавиатура тачпадовская?
Рекомендую взглянуть на плагин EasyMotion.
В Vim для этого есть EasyMotion, который позволяет прыгать в любое место без того, чтобы убирать руки на мышку.
В Vim для этого есть плагин easymotion. В нём перемещение к тексту состоит из двух-трёх нажатий на клавиши: 's' (перейти в режим поиска), далее символ, к которому нужно переместиться. Эти символы на экране подсвечиваются. После этого надо нажать последнюю клавишу, чтобы переместиться к этому символу. Например, перемещение к первому на экране определению C++-функции: 's{a'. Это быстрее, чем нашарить мышь, спозиционировать курсор и щёлкнуть, вернуть руки на место.
Разработка и набивка текста это разные вещи, продуктивность набивки текста обычно не влияет на скорость разработки, а на качество может повлиять только отрицательно. Посыл изначально не верный, текстовый редактор это не правильный инструмент для программиста, это просто редактор текста.
Вот хотел сказать примерно то же, но не рискнул. Я редко больше 1000 строк редактирую за весь день, а чаще — пару сотен. Моя продуктивность явно не упирается в набор текста.
Это ключевой аргумент, именно поэтому vimеры его старательно игнорируют.
Скорость набора текста вообще не является аргументом. Но вот удобство набора — таки является. Вимом это делать удобнее. Вот как-то так.
Во-первых, это не ключевой аргумент. Ключевой аргумент — комфортность работы. Когда пальцы привыкли делать достаточно сложные действия нажатием 2-3 клавиш, пользоваться другими способами мучительно.
Во-вторых, это смотря у кого какая производительность. Если я пишу новый код, я запросто могу написать этак 1500 строк в день.
Во-вторых, это смотря у кого какая производительность. Если я пишу новый код, я запросто могу написать этак 1500 строк в день.
продуктивность набивки текста обычно не влияет на скорость разработки
Более того, набивка текста вообще не влияет на скорость разработки, так как разработка — это в первую очередь построение абстрактных моделей и схем (для их представления другим разработчикам). Процесс разработки не связан ни с одним редактором или IDE. Не следует путать терминологию
Работать с мышкой ооочень доооооолго, вы попробуйте обходиться без неё. В свое время почти полностью отказался от неё (sublim + vi mod в браузере + awesome wm). Сейчас крайне бесит, что в некоторых программах без мышки никак.
We’ve done a cool $50 million of R & D on the Apple Human Interface. We discovered, among other things, two pertinent facts:
Test subjects consistently report that keyboarding is faster than mousing.
The stopwatch consistently proves mousing is faster than keyboarding.
Test subjects consistently report that keyboarding is faster than mousing.
The stopwatch consistently proves mousing is faster than keyboarding.
Дайте линк, а?
Нашёл тут продолжение: http://www.asktog.com/TOI/toi06KeyboardVMouse1.html
Продолжение
This contradiction between user-experience and reality apparently forms the basis for many user/developers’ belief that the keyboard is faster.
People new to the mouse find the process of acquiring it every time they want to do anything other than type to be incredibly time-wasting. And therein lies the very advantage of the mouse: it is boring to find it because the two-second search does not require high-level cognitive engagement.
It takes two seconds to decide upon which special-function key to press. Deciding among abstract symbols is a high-level cognitive function. Not only is this decision not boring, the user actually experiences amnesia! Real amnesia! The time-slice spent making the decision simply ceases to exist.
While the keyboard users in this case feels as though they have gained two seconds over the mouse users, the opposite is really the case. Because while the keyboard users have been engaged in a process so fascinating that they have experienced amnesia, the mouse users have been so disengaged that they have been able to continue thinking about the task they are trying to accomplish. They have not had to set their task aside to think about or remember abstract symbols.
People new to the mouse find the process of acquiring it every time they want to do anything other than type to be incredibly time-wasting. And therein lies the very advantage of the mouse: it is boring to find it because the two-second search does not require high-level cognitive engagement.
It takes two seconds to decide upon which special-function key to press. Deciding among abstract symbols is a high-level cognitive function. Not only is this decision not boring, the user actually experiences amnesia! Real amnesia! The time-slice spent making the decision simply ceases to exist.
While the keyboard users in this case feels as though they have gained two seconds over the mouse users, the opposite is really the case. Because while the keyboard users have been engaged in a process so fascinating that they have experienced amnesia, the mouse users have been so disengaged that they have been able to continue thinking about the task they are trying to accomplish. They have not had to set their task aside to think about or remember abstract symbols.
Вот мне тоже хотелось бы линк на исследование. То, что кинул Evengard, извините не исследование, а такое же ИМХО автора, нет ни метода исследования, ни характеристики групп, не количества испытуемых, ничего (насколько я понял их контекста, они набирали рандомных людей, так я и так вам скажу, что по-началу мышка интуитивнее и быстрее).
Я вот ни разу вам не поверю, что, например, вам мышкой будет быстрее выделить строчку, нажать пр. кнопку мыши, нажать скопировать, передвинуть на новое место, нажать вставить, чем мне нажать 3 клавиши в виме.
ps. Я не утверждаю, что все должны пользоваться вимом, пользуйтесь чем вам удобнее. Но говорить, что мышка быстрее клавиатуры, это, извините, нонсенс.
Я вот ни разу вам не поверю, что, например, вам мышкой будет быстрее выделить строчку, нажать пр. кнопку мыши, нажать скопировать, передвинуть на новое место, нажать вставить, чем мне нажать 3 клавиши в виме.
ps. Я не утверждаю, что все должны пользоваться вимом, пользуйтесь чем вам удобнее. Но говорить, что мышка быстрее клавиатуры, это, извините, нонсенс.
Пруфы? Пфф… Кому нужны пруфы когда есть вбросы?!
В статье как раз говорится о том, что клавиатура интуитивнее.
Только меня смущает, что статья из тех времён, когда у большинства людей вообще не было мышек?
Только меня смущает, что статья из тех времён, когда у большинства людей вообще не было мышек?
Ну если искать на sciencedirect'е или подобном ресурсе, то исследования вполне находятся. К сожалению, доступ к ним платный (а потом удивляются, почему все только на жёлтую прессу ссылаются).
Вот пример неплохого исследования:
Richard Coll, Khalid Zia, Joan H Coll. A comparison of three computer cursor control devices: pen on horizontal tablet, mouse and keyboard, Information & Management, Volume 27, Issue 6, December 1994, Pages 329-339
Из Abstract'а:
Вот пример неплохого исследования:
Richard Coll, Khalid Zia, Joan H Coll. A comparison of three computer cursor control devices: pen on horizontal tablet, mouse and keyboard, Information & Management, Volume 27, Issue 6, December 1994, Pages 329-339
Из Abstract'а:
The ATT Frame Creation System (FCS) Series 500 was used because it is a graphics system which, conveniently, accommodates the three devices we wished to compare. It consists of a color graphics monitor, an alphanumeric keyboard, a pen, a mouse, and a horizontal tablet used in conjunction with the pen and the mouse.В статье приводятся все необходимые подробности: и количество испытуемых (63 человека), и наборы экспериментов, и используемое оборудование, и выполняемые задачи. Даже определялся прогресс — как сильно люди могут улучшить результаты в ходе тренировок скорости работы с данными девайсами.
In the context of these experiments pen use was never significantly faster than mouse, while both pen and mouse use were always significantly faster than the keyboard.
Конечно не исследование, так, хрень на постном масле. Всем гораздо интереснее было бы узнать, во что вы ни разу не поверите, а во что — поверите :)
И раз уж взялись меряться писькой с мышкой, приведите, пожалуйста, эти три волшебные клавиши, которыми вы в виме скопируете и вставите в произвольное место файла произвольную строку текста. Вот давайте, для определённости, пусть ваш текстовый курсор стоит в позиции 0, 0, скопируйте нажатием трёх клавиш 37-ю строку и вставьте в 12-ю строку между 27-м и 28-м символами. Напоминаю, у вас есть три нажатия по одной клавише, время пошло :)
И раз уж взялись меряться писькой с мышкой, приведите, пожалуйста, эти три волшебные клавиши, которыми вы в виме скопируете и вставите в произвольное место файла произвольную строку текста. Вот давайте, для определённости, пусть ваш текстовый курсор стоит в позиции 0, 0, скопируйте нажатием трёх клавиш 37-ю строку и вставьте в 12-ю строку между 27-м и 28-м символами. Напоминаю, у вас есть три нажатия по одной клавише, время пошло :)
Конечно не исследование, так, хрень на постном масле
Совершенно верно.
эти три волшебные клавиши, которыми вы в виме скопируете
Могу в одну клавишу. Какую вам хочется? Давайте на m. Все, сделал.
вы правы, тремя кнопками (с настройками по-умолчанию) не обойтись. Вот последовательность
:37 enter
v$hy
:12 enter
27lp
Если вы новичок в виме, то да, над каждой командой нужно думать, уйдет много времени. Если все в пальцах, то получается быстрее (тем более, если визуально 28 символ не сильно отделен). Опять же, я не призываю пользоваться вимом, пользуйтесь чем угодно. Но клавиатура в подобных задачах быстрее. Другой вопрос нужны ли эти выигрыши в скорости (вопрос почти как про преждевременную оптимизацию). За себя я могу сказать, что мне просто нравится работать таким образом.
:37 enter
v$hy
:12 enter
27lp
Если вы новичок в виме, то да, над каждой командой нужно думать, уйдет много времени. Если все в пальцах, то получается быстрее (тем более, если визуально 28 символ не сильно отделен). Опять же, я не призываю пользоваться вимом, пользуйтесь чем угодно. Но клавиатура в подобных задачах быстрее. Другой вопрос нужны ли эти выигрыши в скорости (вопрос почти как про преждевременную оптимизацию). За себя я могу сказать, что мне просто нравится работать таким образом.
Вот уже больше похоже на правду. Итого 19 нажатий (это включая три шифта, который тоже кнопка). При этом еще зачастую спецсимволы и знаки препинания, которые на традиционной клавиатуре расположены по-идиотски, из-за чего их не каждый раз удается с первой попытки набрать вслепую. На самом деле, тремя кнопками тут не обойтись с любыми настройками, даже если у нас заранее заготовлен макрос для копирования и вставки строки — его, как минимум, надо вызвать (пусть будет одно нажатие), скормить ему три двузначных числа с разделителями (8 нажатий) и нажать ентер, итого 10. Мышью быстрее будет, другой вопрос, нужен ли этот выигрыш в скорости :) А если еще объединить мышь с хоткеями (к примеру, сделать, что когда ничего не выделено, пусть Ctrl-C копирует целиком текущую строку), операцию можно произвести в четыре нажатия и два тычка. Потратим время на движение мыши, да, но и его можно частично сэкономить, двигая мышь в точку назначения, пока нажимаем Ctrl-C.
Исследование у меня тоже вызывает вопросы. Какие операции они замеряли, какие у них в системе хоткеи, как организован гуй? Я вот думаю, хорошо бы ввести новую дисциплину специальной олимпиады по программированию, типа «бег по тексту с препятствиями». Команда задро… спортсменов может использовать любой редактор/IDE, обмазать его какими угодно модами и расширениями, тренироваться сколько хочет по затаскиванию мыши или запоминанию клавиатурных комбинаций. Потом всем командам раздают набор типовых заданий (заранее им неизвестный, чтобы не могли специально под него хоткеи заточить) и вперёд. Тогда рано или поздно станет понятен выбор чемпионов. А пока получается один субъективизм, кого-то сильнее бесит за мышку тягать, кого-то — клавиатуру топтать.
Исследование у меня тоже вызывает вопросы. Какие операции они замеряли, какие у них в системе хоткеи, как организован гуй? Я вот думаю, хорошо бы ввести новую дисциплину специальной олимпиады по программированию, типа «бег по тексту с препятствиями». Команда задро… спортсменов может использовать любой редактор/IDE, обмазать его какими угодно модами и расширениями, тренироваться сколько хочет по затаскиванию мыши или запоминанию клавиатурных комбинаций. Потом всем командам раздают набор типовых заданий (заранее им неизвестный, чтобы не могли специально под него хоткеи заточить) и вперёд. Тогда рано или поздно станет понятен выбор чемпионов. А пока получается один субъективизм, кого-то сильнее бесит за мышку тягать, кого-то — клавиатуру топтать.
А миллионы мух знаете что выбирают?
Здесь в исследовании дело в другом — насколько людям легко приспособится к интерфейсу.
Разумеется, пока ты не освоишь клавиатуру на хорошем уровне — нельзя ожидать увеличения производительности.
Вопреки исследованию — Apple не собирается горячие клавиши вырезать из своих продуктов. Их там — огромное количество. Горячие клавиши очень активно применяются в MacOS уже много десятилетий.
Здесь в исследовании дело в другом — насколько людям легко приспособится к интерфейсу.
Разумеется, пока ты не освоишь клавиатуру на хорошем уровне — нельзя ожидать увеличения производительности.
Вопреки исследованию — Apple не собирается горячие клавиши вырезать из своих продуктов. Их там — огромное количество. Горячие клавиши очень активно применяются в MacOS уже много десятилетий.
О! Я фактически зашел, чтобы прочесть эту фразу…
Ну, во-первых, набирать мышью текст очень удобно, надо только приделать к ней пять-шесть кнопок, написать простенький спецдрайвер, и вводить двоичные кода символа.
А тут писали что vim как раз позволяет не уподобляясь пианисту-виртуозу выполнять навигацию по тексту, не смещая рук с базовой десятипальцевой посадки. А вы тут про то, чтобы тянуться за мышью длямоментального позиционирования текстового курсора в нужное место.
Во-вторых, если взять устройство где нет ни мыши, ни клавиатуры, в смысле дешёвый android-планшет, выяснится, что Vim Touch — самый удобный редактор для работы с исходными текстами для такого устройства, не требует установки Hacker´s Keyboard, как текстовые редакторы c «традиционным» управлением с клавиатуры, позволяет нормально перемещатся по тексту не занимаясь спортивным попаданием в нужное слово, ну и вообще.
А тут писали что vim как раз позволяет не уподобляясь пианисту-виртуозу выполнять навигацию по тексту, не смещая рук с базовой десятипальцевой посадки. А вы тут про то, чтобы тянуться за мышью для
Во-вторых, если взять устройство где нет ни мыши, ни клавиатуры, в смысле дешёвый android-планшет, выяснится, что Vim Touch — самый удобный редактор для работы с исходными текстами для такого устройства, не требует установки Hacker´s Keyboard, как текстовые редакторы c «традиционным» управлением с клавиатуры, позволяет нормально перемещатся по тексту не занимаясь спортивным попаданием в нужное слово, ну и вообще.
upd. Я не забыл об экранных клавиатурах, но для ввода мышью это, подозреваю, наиболее неудобный способ, поэтому я описал более-менее реалистично реализуемый способ быстрого ввода текста с многокнопочной мыши. Насколько я знаю эксперименты по вводу текста с пятикнопочного устройства были, и показали неплохой результат, хотя конечно, кодировку символов для такого придётся заучить. Вспомнил старую новость о проводившихся в Штатах (или Британии) соревновании по скорости ввода между старичками радистами с морзянкой и тинейджерами с телефонами и T9. Выиграло, предсказуемо, отнюдь не подрастающее поеоление.
Насчёт пяти-шести кнопок это у вас тэг «Сарказм» отвалился или серьёзно опыт использования подобных штук имеете? Я подозреваю, что это была бы удобная приблуда к мобильнику/планшету, но что-то не видать их пока на рынке.
Изначально выше у меня тег сарказм (я бы не сказал, что он отвалился, как по мне он явно между слов и зачёркиваний проглядывает), хотя про реальный опыт использования подобных устройств (правда не совмещённых с мышью) я читал. А насчёт написать подобную «клавиатуру» для android — это идея. Надо будет попробовать.
Хотя нет, не подумал, возможностей мультитача для аккордной клавиатуры явно не хватит, и пяти настоящих кнопок ни на одном моём устройстве нет. Так что только в реальном железе, моего энтузиазма для воплощения такой идеи не хватит.
Да, это очевидно требует физического железа, вероятно, на задней стороне или отдельным гаджетом под вторую руку. Надеялся, что уже сделал кто.
Железная реализация будет убыточной, если только эффект от использования не будет настолько разительным, что подтянутся основные массы смс-писателей. Октодон, например, что-то подобное (хоть и не совсем) в железе сделать пытался, но на кикстартере набрали только 1/15 необходимой суммы. Видимо, мало кто не хочет переучиваться, носить с собой и цеплять к телефону ощутимого размера (и цены) девайс. Да что там девайс — даже сложные клавиатуры вроде основанных на Т9 или Hacker's Keyboard, или MessagEasy особым спросом не пользуются. Для большинства они без надобности, а для остальных они не предоставляют достаточных преимуществ, чтобы на них переходить, и начинать рассматривать мобильный девайс как средство создания контента, а не потребления.
На мой взгляд, ситуация не изменится, пока и если не появится способ вводить и редактировать произвольный (не словарный) текст с приемлемой скоростью вслепую с экранной клавиатуры. Из тех клавиатур, что я видел, слепой ввод и редактирование не обеспечивается ни одной. Попытки делаются обычно в направлении увеличения размера кнопок и применения техник вроде Т9 или жестов (в т.ч. для команд редактирования). У MessagEase есть даже возможность убрать все надписи с кнопок для работы в «слепом» режиме. Но по-настоящему вслепую печатать не получается из-за необходимости отрывать палец от экрана, прицеливаться и попадать даже в эти крупные кнопки: промахи — не редкость. А вот клавиатур, где не было бы необходимости отрывать палец от экрана совсем я ещё не видел. Хотя кажется, что двигаться надо бы в этом направлении.
На мой взгляд, ситуация не изменится, пока и если не появится способ вводить и редактировать произвольный (не словарный) текст с приемлемой скоростью вслепую с экранной клавиатуры. Из тех клавиатур, что я видел, слепой ввод и редактирование не обеспечивается ни одной. Попытки делаются обычно в направлении увеличения размера кнопок и применения техник вроде Т9 или жестов (в т.ч. для команд редактирования). У MessagEase есть даже возможность убрать все надписи с кнопок для работы в «слепом» режиме. Но по-настоящему вслепую печатать не получается из-за необходимости отрывать палец от экрана, прицеливаться и попадать даже в эти крупные кнопки: промахи — не редкость. А вот клавиатур, где не было бы необходимости отрывать палец от экрана совсем я ещё не видел. Хотя кажется, что двигаться надо бы в этом направлении.
Надо понимать, что мыши тогда были несколько похуже.
Мышь — это интуитивный инструмент, в этом его плюс. Но он не быстрый. В любом редакторе нормальные профи (не только в vi/vim) используют «горячие клавишы» и минимизируют использование мыши.
vim очень помогает в случаях когда нужно кодировать, деплоить и тестировать быстрее скорости мысли. А еще там поиск по регуляркам из каробки. И зразу есть консоль. И если у вас linux-server, то там 100% есть vim. И плагинов много. И свои можно писать. Да, использование vim это обычно легаси, но он того стоит. И файлы в 100500 строк сразу открывает.
vim очень помогает в случаях когда нужно кодировать, деплоить и тестировать быстрее скорости мысли.Задеплоить, а потом думать «а что же это я такое задеплоил?!»?
И если у вас linux-server, то там 100% есть vim.ну, не знаю, в десктопной ubuntu я его каждый раз ставлю, может в серверной иначе. По-моему, nano уже потихоньку его вытесняет в качестве дефолтного редактора.
Люди еще и в Far Manager пишут код. Когда проект на столько хорошо знаком, что дальше некуда.
Основной nano проект ушел из GNU (remove the GNU marker from nano's name), и это вносит некоторую неопределенность в его будущее — мейнтейнеры либо будут использовать форкнутый GNU nano, либо новую версию. Более подробная дискуссия: Nano is no longer a GNU project
vi (не vim) есть всегда — он входит в список утилит POSIX: Utilities. Есть очень редкие случаи, когда vi не установлен, но я такое встречал только на специализированных Linux-based firmware (впрочем, там не было и nano тоже).
vi (не vim) есть всегда — он входит в список утилит POSIX: Utilities. Есть очень редкие случаи, когда vi не установлен, но я такое встречал только на специализированных Linux-based firmware (впрочем, там не было и nano тоже).
Я ничего против не имею любителей vi — прекрасные люди и зачастую специалисты.
Вот только не понимаю зачем вы постоянно оправдываетесь в том какой редактор вы используете (а часто еще и заходя дальше на тему — это же не просто редактор это нечто большее)…
Я искренне не понимаю зачем набирать ceHello[ESC] чтобы потом нажать '.' и превратить это просто в Hello — почему сразу не набрать это гребанное хелло?
Вот и в этой статье в очередной раз описывается как вы сами себе создаете проблемы чтобы потом решить их с помощью VI и в очередной раз что то доказать… ну а остальным сказать что их редактор никудышний, как это сделано в выводах статьи
Вот только не понимаю зачем вы постоянно оправдываетесь в том какой редактор вы используете (а часто еще и заходя дальше на тему — это же не просто редактор это нечто большее)…
Я искренне не понимаю зачем набирать ceHello[ESC] чтобы потом нажать '.' и превратить это просто в Hello — почему сразу не набрать это гребанное хелло?
Вот и в этой статье в очередной раз описывается как вы сами себе создаете проблемы чтобы потом решить их с помощью VI и в очередной раз что то доказать… ну а остальным сказать что их редактор никудышний, как это сделано в выводах статьи
>Я искренне не понимаю зачем набирать ceHello[ESC] чтобы потом нажать '.' и превратить это просто в Hello — почему сразу не набрать это гребанное хелло?
Это работает не так. ce значит замена от текущей позиции курсора до конца слова (если курсор в слове. Если курсор на пробеле, то заменится пробел. Если курсор на первом символе слова, то заменится все слово) сразу после ce vim переходит в режим ввода. [ESC] выводит из режима ввода. Т.е. после ceHello[ESC] в тексте слово под курсором будет заменено на Hello. Точка повторяет эти махинации.
Это работает не так. ce значит замена от текущей позиции курсора до конца слова (если курсор в слове. Если курсор на пробеле, то заменится пробел. Если курсор на первом символе слова, то заменится все слово) сразу после ce vim переходит в режим ввода. [ESC] выводит из режима ввода. Т.е. после ceHello[ESC] в тексте слово под курсором будет заменено на Hello. Точка повторяет эти махинации.
Вопрос ведь не в этом. Я даже не буду углубляться — но с помощью ctrl+c ctrl+v и двойного клика мышкой по слову для выделения — это делается не намного дольше (если не быстрее). А если к примеру нужно в большом тексте сделать 100 замен то перемещение с помощью hjkl будет вероятно даже дольше нежели выделение мышкой. А многие сейчас даже приведут примеры как в их редакторе это вообще можно сделать одним кликом по какой нибудь кнопке — «заменить все».
Вопрос ведь был не в этом — а в том что не нужно смотреть свысока только потому что вы используете vi/vim — на результаты работы это влияет мало и те кто используют другие редакторы код часто пишут лучше.
Вопрос ведь был не в этом — а в том что не нужно смотреть свысока только потому что вы используете vi/vim — на результаты работы это влияет мало и те кто используют другие редакторы код часто пишут лучше.
А если к примеру нужно в большом тексте сделать 100 замен то перемещение с помощью hjkl будет вероятно даже дольше нежели выделение мышкой.
Тут уже появляются варианты. Либо "заменить все". Либо мы меняем пять слов на новые пять слов из этой сотни. Тогда вместо hjkl будут использоваться другие кнопки, зависит от ситуации, но по принципу "поиск и замена".
те кто используют другие редакторы код часто пишут лучше.
Где посмотреть статистику?
Если коротко и без всякой мишуры, то суть вима в следующем: вам не надо тянуться к мыши. Вам не надо использовать стрелочки. Даже BS не нужен(зависит от ситуации, конечно), проще допечатать до конца, нажать ESC0fArB, где A,B это неправильный и правильный символы. Даже блок delete, insert, home не нужен. Вам не надо держать руки где-то еще кроме их положения asdf jkl; на клавиатуре и куда-то их двигать.
А с плагинами обычное радактирование текста перерастает в ide'шность (я не знаю чем определяется ide, но все функции, которые я видел в ide я вижу и в вим) и можно переходить от вызова функции к её определению, из файла в файл, сплиты, скомпилить и запустить, вызвать внешнюю программу и вставить её вывод в редактируемый файл или сохранить в буфере обмена и использовать позже.
И все это не двигая руками по клавиатуре. Надо только до ESC дотянуться, но ленивые биндят, например на jj ESC и все, двойное нажатие j заменяет клавишу ESC.
и можно переходить от вызова функции к её определению
Используя ctags? Ну оно ведь не особо удобно, в сравнении с теми же монстрами аля VS/IDEA.
Я хоть и предпочитаю маргинальный редактор вместо студии, но стоит признать, что автокомплиты, переходы к объявлению/определению и т.п. в IDE обычно реализованы удобней, чем в таких редакторах…
Собственно эти IDE'шные фичи — это как раз тот случай, когда не "в этом редакторе все можно настроить", а "в этом редакторе можно смириться с отстутствием этих фич и использовать другие".
Это правда не для всех языков. На С++ не под Windows хорошей среды нет, и в Vim есть плагины, которые делают автокомплит и навигацию через clang, поэтому конкретно для С++ Vim не намного хуже чем альтернативы не на Windows. Эклипсу и QtCreator все равно проигрывает немного по функциональности (например я не нашел хороших плагинов для кодогенерации), но не так значительно, как, например, с Java.
можно переходить от вызова функции к её определению
А вы на каком языке пишете? Я ниже привёл пример с перегрузкой оператора в C++, да и любая перегруженная функция (т.е. группа функций с одним названием, но разными сигнатурами) тоже подойдёт. Как Vim выберет правильную в этой ситуации?
Если переходы на ctags реализованы, то скорей всего поведение будет как в emacs: выплюнет длинный список определений, откуда уже ручками придется находить нужное. Вообще на практике все эти "автопереходы" в Vim/Emacs работают хуже, чем старый добрый grep и совсем хуже, чем в IDE, где переходы семантические...
Ух, понятно, довольно бесполезно получается. Такие вот моменты выбивают из «потока» намного сильнее, чем, якобы, перенос руки на мышку и обратно. grep, кстати, хорошо помогает, когда берёшь чужой проект (на любом языке) и хочешь быстро найти нужное место, чтобы исправить/разобраться/найти отправную точку. Это оказывается быстрее, чем ждать полной индексации в IDE, да и поиск по произвольному тексту там обычно не очень удобен.
Такие вот моменты выбивают из «потока» намного сильнее, чем, якобы, перенос руки на мышку и обратно.
Дело вкуса. Лично я последние несколько лет разрабатываю используя для навигации только find и grep и не ощущаю какого-то дискомфорта. Вот мышкой пользоваться мне просто не очень удобно, хоть это и интуитивно-понятный контроллер.
з.ы. ну и да, постоянное нахождение рук на клавиатуре — это, помимо прочего, прямой путь к тунельному синдрому. Вспоминаем про то, что главный страдалец от этого недуга в ИТ не кто иной, как товарищ Столман, который большой поклонник маргинальных редакторов.
https://github.com/drothlis/clang-ctags кто-нибудь пробовал использовать?
Вот конкретно эту штуку не пробовал. Но пробовал в Emacs подрубать clang для семантического разбора исходников через плагины и последующих умных переходов и автокомплитов, работало оно все не понятно как, требовало кучу телодвижений для того, чтобы пропарсить проект (депенденси тоже автоматом не цепляются разумеется) и потом все это жутко тормозило, т.к. Emacs немного не многопоточный. В итоге отказался от этой идеи… судя по тому, что среди моих знакомых Vim'еров также никто не использует никаких семантических приблуд, там дела обстоят не лучше.
Попробуйте Ctrl+C вместо ESC: и биндить ничего не нужно и всегда под рукой
> А многие сейчас даже приведут примеры как в их редакторе это вообще можно сделать одним кликом по какой нибудь кнопке
Или одной командой в vim.
Или одной командой в vim.
А многие сейчас даже приведут примеры как в их редакторе это вообще можно сделать одним кликом по какой нибудь кнопке — «заменить все».
Такое даже в стандартном виндовом блокноте есть. Я бы скорее удивился текстовым редакторам в которых функции «найти все %text1% и заменить на %text2%» не предусмотрено.
Вот только не понимаю зачем вы постоянно оправдываетесь в том какой редактор вы используете
Мне это тоже постоянно досаждает (
Абсолютно типичная хабровская статья: «я вам хочу рассказать о технологии, которую изучил». Ничем не отличается от тысяч статей про другие технологии, которые здесь публикуются.
Ну да, в статье чувствуется очень легкая ангажированность — «я знаю такие фичи вима, из которого вы даже выйти не сможете». Не более того.
Что именно вас раздражает?
Ну да, в статье чувствуется очень легкая ангажированность — «я знаю такие фичи вима, из которого вы даже выйти не сможете». Не более того.
Что именно вас раздражает?
UFO just landed and posted this here
Если читать дальше заголовка, становится ясно, что это не столько апология vi[m], сколько краткое введение в философию и базовые способы работы с этим семейством редакторов. Это как с unix way. Вполне определённый подход — лет 40 назад — предельно новаторский, сейчас — основательно обросший седеющей бородой, но по-прежнему весьма эффективный, при условии правильного способа использования.
Вот только не понимаю зачем вы постоянно оправдываетесь в том какой редактор вы используете
Да всё очень просто.
Нам надоели. Надоели все эти люди, которые приходят и говорят: «Как ты программируешь на этом старом говне? Вот в моей <IDE_name>...».
Я перестал уже обращать на это внимание. Даже перестал что-то отвечать кроме как: «Да, твоя <IDE_name> очень классная. Пока.».
Это, как и любой холивар, просто непринятие одной из сторон точки зрения другого.
Мне удобно в виме, я уже свои плагинчики написал, настроил как надо всё. Сижу, программирую. ИДЕ пробовал. Лично мне не хватило огромного количество возможностей вима, которые добавляются через плагины.
Что, кстати, интересно все же идут, смотрят на голый вим без плагинов и ужасаются. Я тоже.
Я всю жизнь использовал всякие IDE, одна другой краше, пока 5 лет назад не решил попробовать vim.
Через месяц я понял, как я заблуждался раньше, моя жизнь изменилась. Я поменял работу, и стал зарабатывать в 3 раза больше, женился, купил 2 машины.
Не попробовав — не поймешь. Смысл тут рассказавать, как вы что-то не понимаете?
Через месяц я понял, как я заблуждался раньше, моя жизнь изменилась. Я поменял работу, и стал зарабатывать в 3 раза больше, женился, купил 2 машины.
Не попробовав — не поймешь. Смысл тут рассказавать, как вы что-то не понимаете?
Это был сарказм?
Нет, конечно, ну разве что про женился.
Без вим режима теперь очень трудно, убогость других средств раздражает.
Особенно, когда опять видишь всякий IDE — кал, с кучкой ярких приблуд, а-да дополнения кода, многоярусные туллбары с десятками кнопок, и т.д. Впечатляет, когда по всем четырем сторонам окна открыто по тулбару, куда надо ловко и быстро попадать мышью. Напоминает игру в сапера.
Вим — это аскетизм, наполненный губочайшим смыслом, гениальность.
Конечно, это не для всех. ;-)
Без вим режима теперь очень трудно, убогость других средств раздражает.
Особенно, когда опять видишь всякий IDE — кал, с кучкой ярких приблуд, а-да дополнения кода, многоярусные туллбары с десятками кнопок, и т.д. Впечатляет, когда по всем четырем сторонам окна открыто по тулбару, куда надо ловко и быстро попадать мышью. Напоминает игру в сапера.
Вим — это аскетизм, наполненный губочайшим смыслом, гениальность.
Конечно, это не для всех. ;-)
Сарказм: 19 августа 91 года у меня из стада убежал теленок которого искали потом пару дней. В это же время произошел путч. Уверен, тут тоже есть связь.
Мораль: слишком много притянуто к переходу на вим.
Мораль: слишком много притянуто к переходу на вим.
"A" переводит курсор в конец строки и активирует режим ввода. После завершения набора нажатием [ESC] вы можете нажать '.' где угодно, чтобы повторить ввод в конце строки.
Может быть вы знаете зачем? Чем лучшем, чем нажать Home/End в обычном редакторе?
Вы не поняли о чем речь в этой части статьи. Приведите пример вставки слова «Hello» в конец 20 строк разной длины.
В FAR это делается элементарным макросом.
В notepad одним regexp replace
В статье хорошие примеры, но попытки сказать, что VI во всем круче других современных редакторов и круче IDE — зря.
В notepad одним regexp replace
В статье хорошие примеры, но попытки сказать, что VI во всем круче других современных редакторов и круче IDE — зря.
В FAR это делается элементарным макросом.
В notepad одним regexp replace
А в статье предлагается: AHelloj.j.j.j.j.j. что таки быстрее обоих предложенных вами вариантов.
но попытки сказать
Я о конкретном примере, а не об обидах и расследованиях.
Даже всякие sublime'ы поддерживают multiple cursor, при помощи которого ваша задача решится изящней, чем 20 нажатий j.
Согласен, multiple cursor замечательный инструмент.
Эффектней — да. Изящней-ли? Вопрос. Пробовал и то, и другое, повтор ввода как-то надёжней.
UFO just landed and posted this here
В vim — аналогично.
Ставите под ваш язык соотвествующий плагин. Если плагин хорошего качества (как для Go), то рефакторинг выглядит также: горячая клавиша и ввод нового имени.
Ставите под ваш язык соотвествующий плагин. Если плагин хорошего качества (как для Go), то рефакторинг выглядит также: горячая клавиша и ввод нового имени.
Давайте об определённых действиях. Добавить внутрь if дополнительное условие. Подредактировать выражение. Строчку поправить внутри кавычек.
А с форматированием такое дело — бывает, что из заданного тобой же самим стиля нужно сделать исключение.
UFO just landed and posted this here
В моем случае, скорость ввода и редактирования текста не могут повлиять на продуктивность, совсем.
А как насчёт удобства редактирования?
UFO just landed and posted this here
Я правильно понимаю, что скорость и удобство ввода и редактирования текста не могут повлиять на продуктивность в вашем случае?
UFO just landed and posted this here
Ну, вы представьте себе, что в IDE, вместо обычного редактирования текста вставлен вим и что вам надо с ним работать. Повлияет это на вашу продуктивность?
UFO just landed and posted this here
Я считаю, что если вас посадить за неудобный редактор — ваша продуктивность резко упадёт. Не знаю, как у вас с вимом, но если вы им особенно непользуетесь, то когда в IDE редактирование текста будет доступно только с помощью способа, использующегося в виме — вам первое время будет очень тяжело. Будете раздражаться, ругаться и из-за этого пребывать в ужасном настроении. Потеряете концентрацию, сложно будет думать о задаче, а не о том, как вам неудобно. Потом, может быть, привыкнете. А может и нет. Может ваша продуктивность вообще просядет очень надолго. И всё из-за того, что вам очень неудобно делать 10% работы.
Да, если я внезапно буду вынужден использовать vim, и не иметь альтернатив, то моя продуктивность упадет.
Но, честно, я с трудом представляю задачу или ситуацию, где для работы с C/C++, ну там пусть, условно, PHP, Python у меня не было бы никакой возможности пользоваться при написании кода чем-то кроме vim'а…
Может Вы приведете пример подобной ситуации? Буду благодарен, если это будет приближенный к реальности, а не абстрактно высосанный из пальца.
Естественно, не беру сейчас ранее обсужденный в комментариях вопрос про "правку конфига на удаленном сервере" (или же правки пары строк в скрипте на сервере), речь именно про написание/редактирование(рефакторинг/добавление функционала и тд) кода.
Речь не о том, чтобы использовать вим, речь идёт о том, чтоб использовать вашу любимую IDE и заменить способ редактирования текста на тот, что используется в вим. Это пример для демонстрации того, насколько важно удобство именно редактирования текста при програмиировании.
Возможно, я не совсем точно сформулировал мысль.
Замените в моём предыдущем комментарии vim на vim-style. Т.е. если у меня не будет альтернативы vim-style редактированию, то моя продуктивность упадет.
В целом, с посылом про удобство я полностью согласен. Продуктивность будет выше в том случае, когда используется инструмент, знакомый до такой степени, что работаешь с ним на полном автомате, что позволяет полностью сосредоточиться на написании кода.
UFO just landed and posted this here
«А как насчёт удобства редактирования?»
А это в 99% дело привычки, а не сам редактор. Подавляющее большинство редакторов, встроенных в IDE это не notepad, и позволяют делать практически все вещи, которые необходимы в процессе работы. Редкие исключения — не решают проблемы вообще.
VIM жив по одной причине — у него есть специализированная ниша — работа по удаленному ssh терминалу. Там он изначально появился, там вырос, и оттуда приходят люди, которые им пользуются, и соответственно они приходят уже с навыками. Но если ты изначально работаешь на локальной машине, vi не нужен.
P.S. Это учитывая, что я как раз пришел из сисадминов, и я в vi работал много и успешно. Но для правки текста на локальной машине, мне ближе FAR, а для правки java — встроенный редактор в jetbrains со всеми его наворотами.
А это в 99% дело привычки, а не сам редактор. Подавляющее большинство редакторов, встроенных в IDE это не notepad, и позволяют делать практически все вещи, которые необходимы в процессе работы. Редкие исключения — не решают проблемы вообще.
VIM жив по одной причине — у него есть специализированная ниша — работа по удаленному ssh терминалу. Там он изначально появился, там вырос, и оттуда приходят люди, которые им пользуются, и соответственно они приходят уже с навыками. Но если ты изначально работаешь на локальной машине, vi не нужен.
P.S. Это учитывая, что я как раз пришел из сисадминов, и я в vi работал много и успешно. Но для правки текста на локальной машине, мне ближе FAR, а для правки java — встроенный редактор в jetbrains со всеми его наворотами.
Редактирование исходных кодов очень далеко не всегда сводится к рефакторингу.
Ну типа да, но в Far я при этом могу в 2 нажатия приконнектится по ssh к удаленному серверу и отредактировать там файл, другой файл взять обратно и т.д. Т.е. Far Manager намного больше экономит времени.
Мы о примере редактирования текста говорили.
"Это все есть в Emacs" ©
Этот комикс был просто обязан появиться в этом обсуждении: https://xkcd.com/378/
xkcd: Real Programmers
Проблема в том, что пример в статье слишком искусственный. Если там расположение чуть-чуть изменить, то уже не работает.
А в ФАР макрос может быть сложный, включать в себя поиск и перемещение.
Преобразовать 10 строк из
a[1,2,3]
в какой-нить
Var A{
[1],
[2],
[3]
};
— макрос набирается за несколько секунд и повторяется.
А в ФАР макрос может быть сложный, включать в себя поиск и перемещение.
Преобразовать 10 строк из
a[1,2,3]
в какой-нить
Var A{
[1],
[2],
[3]
};
— макрос набирается за несколько секунд и повторяется.
Более того — макрос может быть с выходом из редактора в панели, поэтому можно аналогичное исправление внести во множество файлов. Например, F2, Esc, Стрелка вниз в панелях, F4, F7, найти что-нибудь, отпозиционироваться, внести изменения — так после каждого выполнения макроса вы будете видеть изменённый, но ещё не сохранённый файл, а следующий вызов макроса сохранит текущий файл и изменит следующий. Причём множество файлов можно заранее сформировать во временной панели с помощью поиска или вручную добавляя/удаляя файлы. Наконец, эти файлы могут находиться в архиве или на удалённом сервере — макрос будет исправно работать.
Я возможно вас удивлю, но в Vim тоже есть макросы, а еще там можно программировать целые функции и биндить их на клавиши.
На убогом языке, для которого никто не берется заново написать интерпретатор или транслятор в нечто более удобноваримое типа Lua, что было бы весьма кстати для проекта neovim, к примеру.
Хотя не спорю, на нем написаны хорошие плагины.
Тем не менее, в последние время — какой плагин (из серьезных) не возьмешь — так все требуют поддержку в vim или Python или Lua… Не хотят авторы плагина реализовывать функционал полностью нативно на чистом vim-скрипте…
Хотя не спорю, на нем написаны хорошие плагины.
Тем не менее, в последние время — какой плагин (из серьезных) не возьмешь — так все требуют поддержку в vim или Python или Lua… Не хотят авторы плагина реализовывать функционал полностью нативно на чистом vim-скрипте…
На убогом языке
С чего эти выводы?
Не хотят авторы плагина реализовывать функционал полностью нативно на чистом vim-скрипте…
Я реализовываю, что то во мне особенное наверно?
У вас мания величия?
Зачем мне ваши самопальные макросы, решающие ваши локальные вопросы?
Один из самых лучших подсказчиков автодополнения исходного кода — требует Lua, другой — требует Python и вообще написан на C.
Зачем мне ваши самопальные макросы, решающие ваши локальные вопросы?
Один из самых лучших подсказчиков автодополнения исходного кода — требует Lua, другой — требует Python и вообще написан на C.
У вас мания величия?
Зачем мне ваши самопальные макросы, решающие ваши локальные вопросы?
Мда… Комьюнити хабра спускается все ниже и ниже с каждым новым комментарием. Печально.
Сначала отвечаете в духе «а у меня все работает», а потом в ответ на справедливое замечание обвиняете все комьюнити хабра. Спускаетесь все ниже и ниже с каждым новым комментарием. Печально.
Зайдите в мой профиль и почитайте статьи, может поймете какие у меня «самописные макросы».
Да не впечатлило.
Может, вы мне продемонстрируете тысячи фолловеров и лайков у ваших плагинов, и я признаю, что мания величия — это не про вас?
Может, вы мне продемонстрируете тысячи фолловеров и лайков у ваших плагинов, и я признаю, что мания величия — это не про вас?
Да не впечатлило
Это не должно впечатлить.
Может, вы мне продемонстрируете
А как связано мое знание языка и мои навыки в области маркетинга?
Я не вижу смысла продолжать в сами диалог, если честно.
Да вы можете быть лучшим в вопросах росписи мусорных ведер, только вот если это никому не нужно, то даже начинать разговор с вами никто не будет (что мы и наблюдаем). Ваши плагины — это как раз "ваши самопальные макросы, решающие ваши локальные вопросы", т.к. пользуетесь ими пока только вы. Но вам-то кажется, что все это задротство с никому не нужным, убогим языком — шедевр технической мысли. Ну-ну, поскромнее немножечко :)
P.S. Я на 100% уверен, что это будет прочитано ;)
P.S. Я на 100% уверен, что это будет прочитано ;)
Запись макроса требует чуть больше нажатий (примерно на 3-4), зато вызов делается одной клавишей, которую можно просто зажать, если требуется внести одинаковое исправление тысячу раз, например. Точно лучше, чем по очереди писать j.j.j.
Если надо по очереди написать j.j.j. раз 6, то я лучше это сделаю, чем буду писать макрос. На то и расчет.
Макрос не нужно писать как программу. Нужно просто выполнять нужные вам действия, предварительно один раз нажав кнопку «начать запись», затем «завершить запись» и указать на что его забиндить.
То есть не сложнее, чем затем жать.
Но при этом в vi точка не может воспроизводить несколько разных действий, тем более включающих навигацию, а в фар можно все это делать. поэтому даже j жать не нужно будет.
Давайте сойдемся на том, что те, кто пользуются vi — могли узнать в статье полезные дополнения к знаниям. Кому vi не нужен — всегда найдут способ сделать это другим инструментом.
Я например в восторге от notepad++ с его работой с поиском и обработкой результатов поиска.
Но ФАР роднее, потому что активно использую консоль, а регулярки там тоже есть.
То есть не сложнее, чем затем жать.
Но при этом в vi точка не может воспроизводить несколько разных действий, тем более включающих навигацию, а в фар можно все это делать. поэтому даже j жать не нужно будет.
Давайте сойдемся на том, что те, кто пользуются vi — могли узнать в статье полезные дополнения к знаниям. Кому vi не нужен — всегда найдут способ сделать это другим инструментом.
Я например в восторге от notepad++ с его работой с поиском и обработкой результатов поиска.
Но ФАР роднее, потому что активно использую консоль, а регулярки там тоже есть.
Макрос не нужно писать как программу. Нужно просто выполнять нужные вам действия, предварительно один раз нажав кнопку «начать запись», затем «завершить запись» и указать на что его забиндить.
Я знаю как пишутся макросы.
То есть не сложнее, чем затем жать
Не сложнее, но зачем? Я лучше 2 лишних раза нажму j. чем сэкономлю 0.0004 секунды.
Но при этом в vi точка не может воспроизводить несколько разных действий, тем более включающих навигацию, а в фар можно все это делать. поэтому даже j жать не нужно будет
Речь о конкретном примере. В этом примере не нужно чего либо, что не может точка.
Нужно что то большее, запишите макрос в vi.
Давайте сойдемся на том, что те, кто пользуются vi — могли узнать в статье полезные дополнения к знаниям. Кому vi не нужен — всегда найдут способ сделать это другим инструментом
Так я выше уже назвал статью глупой. Не знаю о чем вы пытаетесь рассказать.
Вы даже в собственном конкретном примере запутались.:
«Вы не поняли о чем речь в этой части статьи. Приведите пример вставки слова «Hello» в конец 20 строк разной длины. „
“А в статье предлагается: AHelloj.j.j.j.j.j. что таки быстрее обоих предложенных вами вариантов.»
Вставить Hello в конец 20 строк разной длины будет явно не j.j.j.j.j., а нажать эти две клавиши по 20 раз каждую = 40 клавиш.
В фаре макрос пишется примерно столько же, сколько набирается «начать запись», End + Hello + вниз, «завершить запись», забиндить например на Ctrl-R и нажать Ctrl+R нужное количество раз, Ctrl можно не отпускать, то есть 21 клавиша.
«Вы не поняли о чем речь в этой части статьи. Приведите пример вставки слова «Hello» в конец 20 строк разной длины. „
“А в статье предлагается: AHelloj.j.j.j.j.j. что таки быстрее обоих предложенных вами вариантов.»
Вставить Hello в конец 20 строк разной длины будет явно не j.j.j.j.j., а нажать эти две клавиши по 20 раз каждую = 40 клавиш.
В фаре макрос пишется примерно столько же, сколько набирается «начать запись», End + Hello + вниз, «завершить запись», забиндить например на Ctrl-R и нажать Ctrl+R нужное количество раз, Ctrl можно не отпускать, то есть 21 клавиша.
Вы даже в собственном конкретном примере запутались
Может быть вы знаете зачем? Чем лучшем, чем нажать Home/End в обычном редакторе?
Приведите пример вставки слова «Hello» в конец 20 строк разной длины
Интересно, а в far кнопка Home вставляет в конец строки Hello? Нет. Я об этом вам говорил, похоже это вы запутались.
В фаре макрос пишется примерно столько же, сколько набирается «начать запись»
qqAHello[Esc]jq19@q — 15 клавишь, если вам так угодно.
Ну, например, потому, что на моем Lenovo X1 Carbon Home/End эти идиоты разместили там, куда вслепую без ошибки не дотянешься. На другом ноутбуке они в другом месте, на 3-м в третьем.
Дело не только в этом. Это не просто нажатие на кнопку, это — команда, которая может использоваться в комбинации с другими, может использоваться в скриптах и фукциях автоматизации. Командный режим — уникальная фича, его ничем не заменишь.
Не видел ни одного, кто-бы ушел с вима обратно к классическим инструментам.
Дело не только в этом. Это не просто нажатие на кнопку, это — команда, которая может использоваться в комбинации с другими, может использоваться в скриптах и фукциях автоматизации. Командный режим — уникальная фича, его ничем не заменишь.
Не видел ни одного, кто-бы ушел с вима обратно к классическим инструментам.
тем, например, что на ноутбуках, бывает, эти кнопки с ходу не найдёшь )
Или продолжайте использовать никудышный редактор кода своей IDE.
Но, в любом случае, никогда больше не заявляйте, что пользователи vi придурки.
Типа «ваши инструменты отстой, но вы не могите сказать, что мои инструменты отстой!»
Убогий подход.
Тем более, что IDE — это манипулирование с сущностями, рефакторинг по имени поля/класса и т.п. IDE — это работа не только с текстом.
Сам использую nano, но есть товарищ, который аргументирует так: vi (именно он, не vim!) есть везде, на любом огрызке *nix, на любой железке, поэтому если надо где-то в конфиге строчку поправить — vi наше все.
В vi раздражает именно это, а не то, какой он и так далее. Пользуйтесь чем хотите, но мне дайте самому сделать выбор, чем пользоваться.
vi достаточно давно является частью busybox. Именно поэтому он есть практически на любой железке, даже если это роутер с 4Мб флешки.
И это не раздражает, а наоборот, радует — покуда хоть ЧТО-ТО для редактирования текста уже есть.
Установка любого другого редактора возможна; возможность сделать выбор никто не устраняет! И даже можно удалить симлинк /bin/vi -> busybox.
На любом огрызке есть ed, но разве это повод? :)
ЗЫ. Посмотрел на соседней генте — нету там ни vi ни vim. А вот ed почему-то есть. Так что правда повод! Скажите вашему товрищу, чтобы переучивался. Тем более, что ed работает на телетайпе, а vi — нет, поэтому ещё более универсален :)
ЗЗЫ. Задумался, а почему, собственно, там ed стоит…
ЗЫ. Посмотрел на соседней генте — нету там ни vi ни vim. А вот ed почему-то есть. Так что правда повод! Скажите вашему товрищу, чтобы переучивался. Тем более, что ed работает на телетайпе, а vi — нет, поэтому ещё более универсален :)
ЗЗЫ. Задумался, а почему, собственно, там ed стоит…
Насчет vi не уверен, но вот vim хоть и есть на многих машинах, но без уютного конфига он не так уж и удобен… в результате затаскивание конфига на удаленную тачку по трудозатратам сравнимо с установкой редактора… т.ч. Emacs + tramp-mode тут немного выигрывает ;)
Пользуюсь vi. vim но раздражают не режимы/команды а необходимость переключаться между языками (редактирую русский текст).
Может вам это поможет https://habrahabr.ru/post/98393/#comment_3031341
Мне больше понравилось это решение.
https://github.com/lyokha/vim-xkbswitch.git — решит все ваши проблемы.
Первый пример неубедительный. Например, чтобы в Eclipse CDT сгенерировать реализацию методов (в любом количестве) по заголовочному файлу, мне достаточно нажать Alt+Shift+S, Up (Implement Method...), Enter, Enter. При этом, в примере не раскрыта тема C++, где простого копирования мало, надо ещё дописать название класса.
Второй пример также проигрывает эклипсу, выделяем код, который хотим извлечь в переменную, нажимаем
Почему, ну почему, эти #?@! придурки используют vi?