Как стать автором
Обновить

Комментарии 200

Сложно найти более переоценённый программный продукт, чем vim. Реально, он на сегодняшний день не имеет никаких достоинств в сравнении с графическими редакторами. Зато имеет кучу недосататков. Единственное, почему он хоть как-то актуален — это потому, что по-умолчанию установлен во всех *nix системах. В задачах «отредактировать одну строчку в конфиге» его гора дикого легаси только мешает, а для задач типа «писать огромную программу с нуля» всё же лучше и удобнее пользоваться ide с графическим интервейсом. vi (и даже vim) был действительно очень функционален и продвинут в своё время. Сейчас нет причин им пользоваться, кроме ностальгии. Сейчас конечно набежит толпа фанатов и заминусует это комментарий, но это, имхо, только доказывает мою правоту.

Для меня это отличный инструмент, который позволяет через голый терминал удобно редактировать сложные файлы конфигурации и тестировать их прямо через редактор (! systemctlt reload nginx) на удаленных серверах.

Из-за мер безопасности не всегда удобно и возможно копировать текст в ide или другой редактор (на своём компьютере у меня стоят sublime text и vs code). И лишние действия по копированию опять же.

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

НЛО прилетело и опубликовало эту надпись здесь

Извините, но нафталином попахивают предположения, что везде нужно всё самое современное, что без DevSecOps и третьего Питона (минимум 3.9) не прожить, а легаси, мейнфреймы и критичная инфра, где требуется надёжность и контроль (в т.ч. и со стороны бизнеса\государства, и любое изменение проходит через чейндж менеджмент и аппрувится бордой архитекторов) - не существуют.

НЛО прилетело и опубликовало эту надпись здесь

Простите, как сочетаются "надёжность и контроль" с "правим конфиг nginx'а через vim на живом сервере"?

Не знаю, я этого не утверждал :)

Vim - просто удобный и классный инструмент для редактирования конфигураций и скриптов, например, там, где сильно ограничен доступ (ssh+bash, и всё, никаких тебе ci\cd), а не ключ к надежности.

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

Я не пытаюсь сделать из vim венец творения, я просто считаю, что это классный инструмент _для определённых случаев_, и его иногда незаслуженно пытаются выкинуть или называют нафталином :)

То что он «живой», не значит же что он на проде. Тут кмк идея в том, что критики vim обычно сильно недооценивают разнообразие потенциальных мест применения.
Люто плюсую за «убогий bash». Вот уж действительно икона бабкок у подъезда Причем что удивительно виндовый batch оргазмов не вызывает — все спокойно перешли на нормальный powershell. И только «тру» лиупсоиды продолжают с упоением жрать кактус.

IMHO, это для старых юниксоидов. "Нам" не понять :) Мне, как фану DOS'ов, ближе mcedit. Слышал ещё что есть emacs-маньяки, которые его достаточно успешно вместо графических IDE используют.

В том-то и прикол, что не старых юниксоидов. Я в начале 2010-х с удивлением узнал, что vim набирает популярность, появляются эмуляции этого редактора для браузера и проч. Причина этого мне до сих пор не понятна.

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

Для меня скопировать строчку в конфиге - это три нажатия на клавиатуре (yyp, yy - yank, скопировать строку, р вставить), а коллега по цеху мышью копирует строку в mcedit, клавишами стрелок идёт в конец строки, жмёт enter и вставляет правой кнопкой мыши. Сравните что легче,если вам это нужно делать много раз за день на протяжении месяцев :)

и вроде да ... вы правы :-)
но как то давно ... очень давно :-)
мы с колегами провели соревнование ...
я выступал на стороне GUI :-)
так как плохо дружу с незапоминаемыми последовательностями несвязаных букв ;-)
а мой колега наоборот ;-) только консоль только клавиатура

мы взяли одно и тоже задание .... и с секундомером начали его выполнять ...
уже не помню сути задания ... но что то примерно небольшого рефакторинга кода
но через пол часа я его закончил ... а он еще минут 10 возился :-)

и вы не поверите ... через неделю он поднял Иксы на совем линуксе и обзавелся мышкой :-)


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

Да, конечно, туннельный синдром только от мышки бывает, а от клавиатуры вообще не бывает.

Клавиатурой пользоваться с ним значительно проще. А вот мышкой - никак. По крайней мере так было у меня и моих коллег с подобной проблемой. Дело в особенностях движения, насколько понимаю: при использовании мыши так или иначе есть вращательные движения и движения кистью. В то время как для работы на клавиатуре кисть можно вообще зафиксировать

Для этого есть трекболы.

Или можно пользоваться только клавиатурой

Силиконовый коврик для мыши с горбиком для кисти решает проблему синдрома! Проверено!

О, нет, поверьте, не решает. С ним только хуже, потому что горбик давит именно туда, где проблема кроется. Это я на себе лично проверял, а у меня совсем небольшие проблемы с синдромом, к счастью

ИМХО, это не причина, то, что вы перечислили могут достаточно много редакторов кода. Про поправить пару строчек на сервере — это понятно. Не понятно, почему vim стал популярен как замена IDE, причём не только в Линуксе.
Для меня скорее наоборот — не очень понятно, что дают IDE ради чего нужно жертвовать скоростью, возможностью прозрачно работать локально и удаленно, без проблем параллельно держать больше десятка открытых проектов в разных сессия tmux.
Плюс конечно вся магия режимов vim которая позволяет делать много чего, не снимая руки с клавиатуры. Причем эта магия вам доступна, даже если вы пишете не код, а скажем доки в markdown или тикет в jira.

Что критически важного есть в IDE, что недоступно в vim?

Всякий рефакторинг, автокомплиты, автоподсветка ошибок, автоисправления ошибок и прочая магия связанная с семантикой кода ушла в language servers которые могут использоваться как из vim так и из VSCode.

Мне навскидку приходит в голову только интеграция с системами контроля версий. Для вима есть fugitive, но он уж слишком мощен для меня, так что за исключением банальных вещей типа посмотреть изменения, откатить частично, добавить в stage и прочее что легко сделать не выходя из vim, я предпочитаю делать снаружи vim. Подозреваю что в Idea можно делать дикие мержи и разрешать конфликты бодро орудуя мышкой.

Т.е. я соглашусь что наверное что-то какие-то вещи в себе типа C# или энтерпрайза на java лучше писать в идее или VS, но для обычных вещей типа python/php/golan/rust какой-то особенной разницы не будет.

Это вам взгляд с обратной стороны — от человека который лет 20 пользуется vim? но иногда пробует что нового в стане IDE ( плюс иногда вынуженный ими пользоваться как раз для java/c#)
Плюс конечно вся магия режимов vim которая позволяет делать много чего, не снимая руки с клавиатуры.

Мне вот это и непонятно: если в IDE/редакторе нужно тянуться к мышке для операций, которые используются постоянно, то это неудобная IDE/редактор. То чем я пользовался, позволяло обходиться без мыши в большинстве случаев. Почему считается, что только vim избавляет от мыши?

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

Или банально - я пишу комментарий к какой-то функции и в процессе мне понадобилось посмотреть какое-то другое место в этом большом файле. Я сходил посмотрел и теперь мне нужно сказать _верни меня немедленно в то место где я писал комментарий_.

Да и вообще история перемещения курсора это вещь. Когда бродишь по большому файлу с кодом и такой "Так, в какой-то это функции я был минуту назад?"

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

Плюс вим под клавиатурой понимает только буквенно-цифровые клавиши, плюс Ctrl,Shift,Alt. Все клавиши со стрелками, PgUp,PgDn , функциональные клавиши и прочее не существуют. Двойные и тройные сочетания Ctrl-Shift-Alt не существуют. Ну точнее они существуют и вы можете ими пользоваться, но в модальном редакторе вы можете все сделать не снимая рук с центрального блока, поэтому до них таааак далеко тянуться и никому не приходит это в голову.

скопировать весь комментарий к функции

Мне попадались комментарии такие

/*
*/

И такие

//
//

И такие

#
#

И даже такие

;
;

Как это выделять правильно?

Да и вообще история перемещения курсора это вещь.

Вменяемое IDE (предназначенное для работы с кодом) это просто обязано уметь. qtcreator умеет, например. И мышкой, и клавиатурой ;)

Как это выделять правильно?

В виме есть понятие textobject. И сам вим представляет вам какие-то действия которые вы можете сделать с этим textobject. Например удалить, выделить, скопировать. Плюс модификатор внутри/снаружи i/a. А сами textobjects могут представлять кто угодно. Есть встроенные в вим, например слово, или блок, или кавычки. Т.е. вы можете сказать - удалить все внутри кавычек di" Или выдели слово на котором я стою viw. Но textobjects могут предоставляться и сторонними плагинами. Например плагин для работы с языком может предоставить вам textobject комментарий. Как он это делает это другой вопрос. Раньше это делалось регэкспами, сейчас есть современные тулзы типа tree-sitter которые строят дерево синтаксиса. Или вам LSP сервер их может давать.

Или например вим ничего не знает про понятие функция. Но скажем LSP или treesitter представляют textobject функция и я могу использовать стандартные средства вим для работы с ней.

Или скажем плагин для работы с git может представлять вам textobject - чанк кода который вы пока не закоммитили.

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

Вменяемое IDE (предназначенное для работы с кодом) это просто обязано уметь.

Отлично! Значит я отстал от жизни ) Раньше почему-то можно было переходить вперёд-назад, только если вы прыгали пользуясь стандартными методами ide ( скажем кликнули на метод и перешли к его определению). Скажем если вы в произвольном месте нажмёте 5 раз PgDn вернуться было нельзя.

Хорошо что это уже общая фишка.

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

Можно маркдаун редактировать в рабочей Вики, писать большие сообщения к git commit с кусочками кода и прочая. Или писать вот это вот сообщение вам (чего я увы не делаю, потому что пишу с телефона :( )

модификатор внутри/снаружи i/a

Inside/Autside, надо понимать?;)

К сожалению, половина команд vim вызывают удивление. Только запомнить.

В документации вим это описывается как

vab - Select "a block"

vib - Select "inner block"

va' - Select "a single quoted string"

vi' - Select "inner single quoted string"

И так далее.

Соглашусь про неинтуитивность многих команд, но справедливости ради - вим никогда не рекламировался как интуитивный редактор.

Как уже написали выше: inner/a. Но это реально не модификатор и в документации не написано, что это модификатор. Это соглашение о том, как должны выглядеть команды для выбора «текстовых объектов».

Не понятно, почему vim стал популярен как замена IDE

Потому что холиварная тема. Навигацию в стиле vim тянут в IDE, да. А дрессировать vim для полной замены IDE это долго.

НЛО прилетело и опубликовало эту надпись здесь

Если вместо хаскеля взять что-то более мейнстримное, питон или php или c++?

НЛО прилетело и опубликовало эту надпись здесь

Если действительно для хаскеля нет других вариантов кроме vim - штош, выдрессировать vim быстрее, чем дождаться адекватного IDE .

НЛО прилетело и опубликовало эту надпись здесь

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

НЛО прилетело и опубликовало эту надпись здесь
Не сказать, что совсем долго — в репозиториях Fedora есть готовые конфиги, причём, довольно неплохие, но это уже малопонятные монстры, лезть внутрь которых уже просто страшно.
Двойной клик мыши выделяет всё слово, тройной — всю строку, предложение или абзац, в зависимости от настроек. Копипаст — да, удобней через Ctrl. А вот если надо выделить пару сотен строк, то мышью достаточно прокрутить текст в конец и кликнуть в конце с зажатым Shift. А сколько вы будете ждать, пока доедет курсор, пусть даже со скоростью 10...20 строк в секунду?

Поэтому хороши оба способа одновременно, глупо отказываться от мыши в современных ОС…
А сколько вы будете ждать, пока доедет курсор
А куда ему ехать? Это вам надо скроллить куда-то, а пользователям Вима нажать V200j — и 200 строк выделены за 200мс.

Кабы ещё заранее знать точное количество строк...

Для этого используется относительная нумерация строк. Достаточно прыгнуть без переноса курсора на нужный экран, найти глазами искомую строку и вместо 200 набрать то число, которое стоит рядом с этой строкой. И выделится именно так, как вы описали с Shift+Click.

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

Но ведь в GUI-редакторах тоже есть хоткеи. Не вижу большой разницы между yyp и Home-Shift+End-Ctrl+C -Ctrl+V с точки зрения удобства. Ну да, хоткеи вима прямо на буквах и не надо тянуться до Ctrl - но зато надо на каждый чих тянуться до Esc. Получается примерно эквивалентно по скорости, а vim ещё и надо отдельно учить.

разница тут довольно существенная

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

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

в-третьих учить как раз гораздо сложнее горячие клавиши в обычных редакторах, поскольку они из-за пункта 2 не особо связаны между собой( например перемещение на слово/строку/блок выполняется одной комбинацией, а удаление совершенно другой). В вим же выучив команды движения, для выполнения какого либо действия связанного с этим движением тебе надо запомнить только команду для этого действия, а не набор отдельных команд для каждого перемещения. Например: переместиться до конца слова e, удалить до конца слова de, скопировать ye, поменять регистр g~e.

в-четвертых в вим большое количество команд для перемещения и выделения, которые могут комбинироваться с командами действий. и засчет того, что команды выделения также комбинируются из нескольких клавиш( например i", i{, ip, is, a", ap, as) запоминать там надо в разы меньше, чем с обычными горячими клавишами. Запомнив десяток команд, и полтора десятка способов движения/выделения, получаешь около тысячи различных действий, которым бы потребовалась тысяча обычных горячих клавиш. А с учетом того, что большинство команд гораздо мнемоничнее комбиначии управляющих клавиш, то запомнить это на порядок проще.

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

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

Плюсов вима не понимают те, кто не научились в нём работать.

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

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

Хотя в вим эта команда заняла бы ввода 5-10
символов.

В Geany работаю почти исключительно через клавиатуру. Что я делаю не так?

В vim базовая операция вставки выполняется с модификатором, а с наворотом — без. Да, я в курсе, что там заглавная P, но при наборе это получается с модификатор. В итоге, когда что-то правлю в vim, приходится обходиться без копирования и вставки или использовать возможности графической системы, иначе работа встанет колом. Правда, в nedit-е всё ещё хуже, потому там всё ещё более криво и нет подсветки синтаксиса. Буквы, которые надо набирать, почти никак не связаны с названиями команд, которые они обозначают. Ну да, это третья-четвёртая буква команды. И вот попробуй угадать, что «y» — это «copy». Как было в одном анекдоте, «это уму не растяжимо, это запомнить надо».

Кстати, я вполне использовал vim в качестве полноценной замены графической IDE, так что не надо говорить, что мне было лень изучать его. И да, у меня была мощная конфигурация для этого. Только вот… Знаете, стоило ненадолго переключиться на графическую IDE, как все эти загадочные коды инопланетян приходилось изучать заново, тогда как горячие клавиши графических IDE почему-то отлично сохранялись в памяти. Может быть, потому, что буквы, которые нажимались в связке с модификаторами, были первыми буквами названий команд?

И не смотря на то, что mcedit — не самый удобный редактор, когда мне надо что-то делать на сервере, я стараюсь поставить туда mc. Потому что и редактор у него довольно внятный, и разгребать кучи файлов удобнее всё-таки в двухпанельном файловом менеджере, а не в голой командной строке.
И вот попробуй угадать, что «y» — это «copy». Как было в одном анекдоте, «это уму не растяжимо, это запомнить надо».

В документации копирование поименовали глаголом yank. Не видел, чтобы это слово использовалось в данном значении где‐то ещё (и, например, translate.yandex.ru такого значения не знает, хотя в multitran.com оно попало), но в некоторых случаях в документации написано, как команды проще запомнить.

Да, я об этом названии команды регулярно узнаю, когда лезу в документацию по vim, но потом благополучно забываю. Именно потому, что данная функция везде, абсолютно везде, кроме vim, называется «copy».
НЛО прилетело и опубликовало эту надпись здесь

Всмысле где?) Вот же: yyp

Вбивать туда же, куда и Ctrl+..., Shift+...

… не забыв сначала выйти из режима ввода
Я в mcedit прекрасно выделяю стрелками с шифтом. Что я делаю не так?

Кстати, с vim я прекрасно управляюсь, но его команды не интуитивны, буквы очень странно связаны с названиями команд, тогда как Geany, особено, после настройки, горячие клавиши соответствуют названиям. А ещё, к примеру, вставка в vim нормально работает только с шифтом (заглавная P, я в курсе), что дико неудобно: базовая операция требует модификатора, а с дополнением — работает без модификатора. Просто офигеть как удобно.

И при этом я использовал vim как полноценную IDE. Правда, приходилось как-то выкручиваться и обходиться без копирования и вставки, потому что эти операции неудобно реализованы. Да, получалось медленнее, чем в том же Geany. Сильно медленнее. Но сильно быстрее. чем в Eclipse и NetBeans, потому что домашняя директория была на сервере, а связь с ним — через коммутатор на 100 мегабит. Это было в период с 2011 по 2012. Так и прыгал между ними.

Много современных редакторов при Стрл+С без выделения копируют строку, на которой находится курсор.

У каждого своя история. Я всю жизнь программирую под windows (C++). Оказалось, что для всякой мелочёвки (json, yaml, md, asciidoc, txt, bat, python, ...) последний год использую vim. При этом есть лицензия на sublime text и простаивает vscode. Как-то так оказалось удобнее :)

НЛО прилетело и опубликовало эту надпись здесь
А можете все ваши плагины перечислить, в том числе для Agda, Idris (полтора языка это они?)?
НЛО прилетело и опубликовало эту надпись здесь

А на сколько увеличилась производительность Agda, Idris в сравнении с их двухгодичными версиями?

НЛО прилетело и опубликовало эту надпись здесь
О, а не подскажете, как автодополнение в виме сделать? А то я раза два пробовал, но безуспешно.
Они там как-то делаются, но то, что я видел, работало через ctags, то есть автоматически не дополнялось только что набранными словами и надо было периодически запускать вручную. Тот же Geany хотя бы по открытым файлам сам собирает слова. Могу попробовать найти, если у меня это сохранилось и если такой вариант Вас устроит.
НЛО прилетело и опубликовало эту надпись здесь

Я сам пользуюсь емаксом, а не этим вашим новомодным вимом, но тут про общие качества классических редакторов. Итак, классические редакторы лучше тем, что поддерживают 200 языков про которые вы слышали и ещё 500, про которые вы не слышали. Это раз. Дальше, они очень настраиваемые. И при всём при этом, потребляют на 5 порядков меньше памяти, чем эти vscode и idea. Вот прямо сейчас емакс занимает 1,5 Гб VSS с ~1000 открытых файлов, десятком терминалов (неделя аптайма), почтовым и слак клиентами.

Про VS Code ничего хорошего сказать не могу, ибо крив он до невозможности и не умеет элементарных вещей, а вот IntelliJ IDEA память жрёт совсем не зря. Уж поверьте человеку, который работал ещё с её первой версией, а потом тыкался в PHPStorm и PyCharm. Главное, на что уходит память — автодополнения. Причём, не только тупое автодополнение слов, а автоматическое выстраивание структуры кода (набираешь «for», а IDE сразу дорисовывает всю структуру), полей объекта или классов пакета. А так же отслеживает на лету использование переменных, ругаясь, например, на использование переменной до объявления или неиспользование объявленной. И ещё много чего полезного, для чего надо держать в памяти базу данных по проекту. Всё это экономит просто астрономическое количество времени. Если Вам надо только править конфиги, то тут, бесспорно, выигрывают Emacs и vim, но если в работе проект с сотнями или даже тысячами файлов, то картинка резко меняется. Просто во времена, когда сочинялись Emacs и vim, таких проектом как-то почти не водилось. Они были, но не в таких количествах, чтобы кто-то специально занимался созданием отдельных редакторов под это дело. Обходились конфигурациями для уже существующих.
не то чтобы я был любителем, но vscode тоже это умеет, если запущен языковой сервис.
Он много чего другого не умеет. Сейчас уже не вспомню точно, потому что потыкался, потыкался и оказалось, что Geany может куда больше в плане именно редактирования текста, включая простой доступ к регулярным выражениями. Например, у меня постоянно возникает потребность в преобразовании заголовков HTTP, выдранных из браузера, в питоновский словарь и вот тут без регулярных выражений не обойтись. Или аналогичное преобразование данных POST-запроса. Ну да, я обдиранием сайтов занимаюсь.

Да я и сам когда-то писал на Джаве в IDEA. Редактор хороший, но потребление памяти заоблачное

Причём, не только тупое автодополнение слов, а автоматическое выстраивание структуры кода (набираешь «for», а IDE сразу дорисовывает всю структуру)

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

полей объекта или классов пакета

Допустим, в проекте 10к классов, по 20 полей в каждом. Сохранить это всё — 200к строк, допустим, по 64 байта. В сумме 13 мегабайт. Допустим, для автодополнения нужна хитрая сильноразряженная структура, в которой данные занимают 10%. Тогда будет 130 метров. Остальное — нерациональное расходование памяти.

Если Вам надо только править конфиги, то тут, бесспорно, выигрывают Emacs и vim, но если в работе проект с сотнями или даже тысячами файлов, то картинка резко меняется

У меня дистрибутив линукса с ядром и не только. Ещё раз повторюсь, 1000 файлов открыто постоянно. Откройте в IDEA или VSCode 1000 файлов и расскажите, какой будет результат

Боюсь, у Вас сильно упрощённое представление о том, как устроены подобные структуры данных. Да, достраивание синтаксических конструкций требует не особо много ресурсов, а вот работа с содержимым объектов уже начинает потреблять довольно много. Потому что надо не просто один раз всё сохранить, надо постоянно менять эти структуры, исходя из того, что набирает программист, просчитывать, что ему доступно в данном месте кода. В общем, там много чего надо. В целом, Java любит жрать память, тут я согласен. Но она же позволяет экономить время разработки, поэтому и пишут такие инструменты на ней. А открывать 1000 файлов нет необходимости, если можно в любой момент перейти не просто в нужный файл, а к нужному полю или функции любого класса. То есть, по сути, все эти файлы в каком-то смысле открыты и активно обрабатываются по сложным алгоритмам. Которые тоже место занимают.

А комментарий взяли и заплюсовали, что только доказывает вашу неправоту. Шах и мат!

Сейчас нет причин им пользоваться, кроме ностальгии.

Как бы не так. Я смеялся над людьми, использующими Vim, крутил пальцем у виска…
пока не попробовал и не перешёл на него несколько лет назад с убогих виндовых редакторов — Visual Studio и прочих. Сейчас везде где можно использую Vim/Vim режим.
Ценю Vim за удобство и единообразие на трёх платформах (win/mac/linux).
это было бы убедительно, если бы что-то подобное не говорили про vim последние лет 20.
Когда я начинал программировать — в конце 90х, люди в основном сидели в mcedit, far, editplus, в зависимости от платформы, а я решил попробовать vim.

Потом наступила эпоха IDE, в 2001 году вышли Eclipse и Idea и было объявлено что эра просто редакторов закончена, потому что код это не просто текст и понимая код IDE могут предоставлять невиданные ранее Возможности.

Года через 4 стало понятно что потребление памяти растет быстрее, чем предоставляемые Возможности и народ стал подунывать. И тут в 2004 году вышел Ruby on Rail. И люди смотрели скринкасты, где DHH и другие, в пять элегантных строчек поднимали приложение, на которые в, прости господи, EJB и JEE у тебя уходила неделя. И эти люди на скринкастах писали в каком-то магическом прекрасном редакторе который запускался за секунду, а не за две минуты как эклипс. Этим редактором был TextMate. И наступила эра возврата к истокам!

Люди копили на маки и текстмейт, а потом лупили простой код, в простых редакторах и были счастливы. Через пару лет правда авторам TextMate надоело их детище, люди страдали, писали какие-то клоны которые благополучно умирали, пока в 2008 году товарищ скиннер не выпустил Sublime Text, который был OK. И тут же было обьявлено что это The Editor и будущее программирования.

Sublime держался бодрячком лет 7, а потом вдруг оказалось что уровень хипстоты в нем совершенно недостаточен для молодежи. (Плагины на питоне? Никакого веба? Ни капельки javascript? It's sooo 2000s! ). И родился Atom! Electron, нода, плагины на js, все новое — с иголочки, что тут не любить! Новый король под горой.

Параллельно со всем этим память дешевела, закон Мура работал изо всех сил и пользоваться IDE опять стало приемлимо. Idea штамповала плагины для разных языков, захватывала ниши и становилась именем нарицательным. Говорим IDE — подразумеваем Idea.

Пока в 2015 не вышла VSCode и сразу стало понятно — this is it. Вершина ide строения, сочетающая простоту и мощь! Надо срочно переходить.

Я мог бы как и куча моих коллег вокруг, прожить всю эту удивительную историю и попробовать кучу прекрасных редакторов, или как я и сделал, все эти 20+ лет пользоваться vim который развивался, добавлял фичи и предоставлял плюс-минус схожие возможности иногда отставая, иногда нагоняя. Да, раз в 5 лет приходится поправить пару строк в конфиге, чего уж скрывать. Ну или захочется попробовать новый интересный плагин.

Сейчас кстати в виме очередная волна активности, выходит neovim 0.5 с кучей новых плюшек, все воодушевлены и клепают плагины, благо теперь не надо месяц учить vimcode чтобы это сделать.
Спасибо за ретроспективу.
По моим наблюдениям, как раз во второй половине 90-х широко использовались IDE (tc, bc, bp, позже Delphi, CBulider, VS), средний школьник/студент не представлял, что можно вызвать компилятор из командной строки.
И ещё замечание, VSCode — не IDE, это редактор кода.
Спасибо, что напомнили про neovim. Давно хотел попробовать, но как-то всё руки не доходили. А с исходным vim-ом беда: как только перестаёшь им пользоваться, сразу вылетают из головы все команды в стиле «это уму не растяжимо, это запомнить надо» и приходится изучать всё заново. Ну и дополнительно радуют базовые команды копирования и вставки, у которых то используемые буквы никак не сопоставляются с названием команды, то базовая функция делается с модификатором, а без модификатор выполняет какие-то дополнительные не запрощенные действия. Надеюсь, в neovim это починили.

Это правда, единственный способ поддерживать навыки вима в актуальном состоянии - это им пользоваться. Я не очень понял что за проблемы с копированием/вставкой вы имеете в виду.

Neovim своим поведением не особо отличается от обычного вима. Ну разве что встроенная консоль. Основные отличия внутри - человеческие дефолтные настройки, поддержка асинхронных коммуникаций, что дает возможность нормально пользоваться внешними инструментами из vim, возможность писать плагины на lua вместо vimscript. И вот в последнем поддержка treesitter - что решает давние проблемы vim с подсветкой кода, и встроенную поддержку LSP.

Вот как раз с поддержанием навыка и проблема: графические IDE, как, кстати, и FAR и прочие подобные, используют общий набор базовых сочетаний клавиш для копирования, вставки, выделения, перемещения между словами и прочие подобные. Да, свои уникальные сочетания есть в каждой IDE, но основные — общие. Да, переходя, например, с Eclipse-based IDE на Idea-based я испытываю неудобства, потому что сочетания, сильно ускорявшие работу, перестают действовать и приходится тыкать мышкой или лазить по меню в поисках нужной функции, при том, что я и в Eclipse уже не помню, где эти функции находятся, потому что использую их через сочетания клавиш. Но я могу сразу начать писать код и делать это достаточно эффективно, потому что автодополнение запускается одним из 4 сочетаний (Ctrl|Alt)+(Enter|Space), если не автоматически, а те самые копировать, вырезать, вставить — это всего два варианта, которые работаю всегда, а чаще всего работают оба. И тут появляется весь из себя уникальный vim, который сочинялся человеком, у которого на клавиатуре не было отдельных клавиш управления курсором, как и клавиш Ins и Del. То есть проблема именно в том, что этот интерфейс не используется больше нигде. Ну да, его прикручивают к IDE (тоже специализированный инструмент и прикручивается каким-нибудь плагином) и браузерам (отдельным расширением), но по умолчанию его нет нигде, кроме самого vim. То есть надо держать в моторной памяти отдельных набор моторных навыков, не совпадающий ни с какими другими и только для одного редактора.

Что касается копирования, то тут надо помнить, какую именно клавишу автор решил использовать. Почем не C? Возможно, она занята, но как-то сильно не интуитивно использовать последнюю букву названия команды. А проблема со вставкой, то ожидается вставка в позицию курсора, а не после него, но для этого надо нажать Shift+P, а не просто P. Если просто P, то вставка будет после текущего символа. Так же и выделение: выделение захватывает символ под курсором, что не соответствует поведению всех остальных интерфейсов, как графических, так и текстовых. И это как раз очень сильно замедляет работу, потому

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

Что касается сочетаний клавиш, и в особенности Ctrl-C. Программы которые вы перечислили поддерживают это сочетание, потому что это Window/MaсOS сочетание клавиш, а вышеперечисленные программы это Windows/MacOS программы построенные с использованием фреймворка что предоставляют эти OS. vim не является такой программой.

И тут появляется весь из себя уникальный vim

Тоже странное утверждение. К моменту когда это сочетание клавиш впервые попало в мейнстрим (в 1984 году вместе с первым макинтошем) vi c этими сочетаниями существовал уже 8 лет.

И использование Ctrl-C для копирования было достаточно противоречивым изменением, потому что к этому моменту у Ctrl-C уже было давно установившееся значение - abort. Поэтому консольные программы для linux/dos не могли его использовать.

какую именно клавишу автор решил использовать. Почем не C?

y - yank

p - paste.

Совершенно разумные сочетания, для, напомню, 1974 года когда никаких стандартов не существовало.

С другой стороны вас почему-то не смущает то что `cut = Ctrl-X` а `paste = Ctrl-V`

Если посмотреть с другой стороны - то унификация редакторов с точки зрения UNIX это странно, потому что с точки зрения unix иметь одновременно несколько редакторов это дикость. Совершенно не unix-way. Если какой-то программе нужно отредактировать текст, то она должа это делать в вашем любимом редакторе. Например если мне нужно сделать git commit в windows, то я кликну правой кнопкой, выберу коммит и мой git client откроет свой собственный редактор текста (безумие!) чтобы я ввел сообщение для коммита. В linux git client запустит мне в таких случаях vim. Это одна из главных идей, стоящих, скажем, за neovim - позволить его легко встраивать в другие программы,

Сложно спорить с тем что в vim куча мелких неконситентностей, и конечно у него совершенно не интуитивно понятный интерфейс. Но у него и нет такой задачи. Интуитивный интерфейс нужен если вы планируете что вашим продуктом будут пользоваться непрофессионалы. Пилоту формулы 1 не нужен интуитивно понятный интерфейс, пилоту А380 не нужен интуитивно понятный интерфейс.

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

ВСЕ пользователи vim считают что модальный режим это огромное преимущество vim, я вам гарантирую это.

Я пользователь. И я считаю, что это главный недостаток vim. Кажется, Вы где-то ошиблись в построениях.

vim не является такой программой

Как конечному пользователю, мне несколько параллельно, какой он программой является или не является, мне важно, чтобы ради базовых функций мне не приходилось держать в голове отдельный набор моторных навыков для каждой программы и чтобы они не терялись, как только я перестаю использовать эту программу постоянно. В mcedit есть меню и есть подсказка по функциональным клавишам, а вот vim почему-то такой подсказки не даёт. Про Ctrl+C я согласен, для копирования, вставки и вырезания есть ещё комбинации с Ins и Del. А в сочетании с выделением с использованием стрелок и клавиши Shift выделение, копирование/вырезание и вставка оказываются как раз быстрее.

y — yank

Внезапно, я это слово впервые увидел именно в документации к vim и сразу забыл, потому что оно в моём активном словаре отсутствует, а операция во всех остальных случаях называется copy.

С другой стороны вас почему-то не смущает то что `cut = Ctrl-X` а `paste = Ctrl-V`С другой стороны вас почему-то не смущает то что `cut = Ctrl-X` а `paste = Ctrl-V`

Странно. Ну так я ими почти не пользуюсь, я использую Ctrl+Ins, Shift+Ins, Ctrl+Del.

Если посмотреть с другой стороны — то унификация редакторов с точки зрения UNIX это странно, потому что с точки зрения unix иметь одновременно несколько редакторов это дикость. Совершенно не unix-way.

Тут Вы сами себе противоречите, потому что для каждой задачи — свой инструмент, выполняющий её идеально. Только не «свой собственный» редактор, а тот, который в большей степени подходит для редактирования таких комментариев.

У болида F1 вполне интуитивный интерфейс: руль, педали, переключатель передач. Принципиально ничем не отличается от обычного автомобиля. Более того, скорее всего, даже педали расположены так же, как у обычного автомобиля, потому что это не может принципиально увеличить скорость реакции, а вот расположение, отличное от общепринятого, как раз может привести к сбою в моторике, для предотвращения чего придётся тратить время, делая сознательный выбор. Аналогично с самолётами: штурвал с интуитивно понятными направлениями вправо и влево, общепринятое «на себя — занчит вверх» и так далее. Куча специальных кнопочек и рычажков? Ну так они специальные и они не требуют мгновенного задействования, в отличии от штурвала самолёта или руля и педалей автомобиля, хоть гоночного, хоть гражданского.

Внезапоно, если мне нужно раз в полгода вставить формулу, я открою графический редактор и нарисую её. А если чуть чаще, то как раз задействую LaTeX, чтобы не париться с не интуитивным интерфейсом MSO, потому что в LaTeX надо просто писать тэги в соответствии с документацией. Просто потому, что формула — это текст, тэги — это текст и я говорю компьютеру словами через клавиатуру, что хочу получить. А вот когда я редактирую текст, я не говорю, компьютеру слова, я делаю это руками, поэтому это моторный навык, а не коммуникационный. Я не хочу объяснять компьютеру словами, какие элементарные действия я хочу сделать. Я хочу, чтобы это было как жест, как перестановка кубиков.
cut = Ctrl-X а paste = Ctrl-V

Это только мне со школьных времен казалось очевидным? Буква «X» похожа на ножницы (иконка «вырезать»), а V — во-первых, Вставить, а во-вторых, на «галочку», как я на бумаге обозначал, куда надо вставить пропущенное слово (написанное над этой галочкой).

Вы мне лучше объясните, как Ctrl+Ins и Shift+Ins запоминаете? Я понимаю, что один из них — вставить (Insert), но почему тогда не оба?
Вы мне лучше объясните, как Ctrl+Ins и Shift+Ins запоминаете? Я понимаю, что один из них — вставить (Insert), но почему тогда не оба?

Это очень просто: во времена борландовских IDE в DOS там не было сочетаний Ctrl-C, Ctrl-V и прочих, поэтому всё прекрасно запоминалось после нескольких повторений, тем более, что мыши и контекстных меню не было. Это было удобнее, чем Ctrl-K C, Ctrl-K V.
Альтернатива была — с помощью той же клавиатуры лезть верхнее меню и там выбирать нужные пункты, и там шорткаты были написаны, чтоб в следующий раз не лазать.
Ну как сказать, в первых, может, и не было — не помню уже за давностью лет, а вот тех, которые были построены на TurboVision, контекстные меню уже вполне использовались. А мышь вполне использовалась и в первых версиях. Вот лично я использовал. Другое дело, что в то время мышь была устройством необязательными и вполне могла отсутствовать на конкретном компьютере, а потому все помнили, что меню — это F10.
а V — во-первых, Вставить,

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

как Ctrl+Ins и Shift+Ins запоминаете?

Без понятия. Но как-то запомнилось и всё. Главное, что эти сочетания работают, за редким исключением, везде, то есть они не являются исключениями из правил, они являются правилом. В отличии от кодов инопланетян в vim.
Спасибо за этот коммент, ровно все таки и было, и с vim я перешел на TextMate, и точно также охреневал с видосов DHH и скорости разработки на Rails, и вот в итоге сижу в VSCode.
>Сейчас конечно набежит толпа фанатов

Нет, тут много тупых — они тебе плюсиков насували )

>В задачах «отредактировать одну строчку в конфиге» «писать огромную программу с нуля»

Других задач не бывает? ) Я например постоянно редактирую гигантские файлы (10-30 гиг) по ssh сразу на сервере. Ты наверное и слова такого не знаешь, мой графический друг.
Уверен, что есть десятки разных задач где vim разрывает ms word (или что ты там рекламируешь )
Да-да, конечно, кроме вас никто «сакральным» знанием про ssh не обладает.

То, что вы редактируете файлы >10гиб в текстовом редакторе говорит об одном из двух:
1. ваша сфера настолько узкая, что туда и кончик ножа не засунуть
2. вы применяете инструменты не по назначению, и вероятно более эффективно было бы использовать что-нибудь вроде sed с регулярками.

Сравнение с ms word это вообще признак того, что вы не понимаете, о чём говорите. Давайте ещё с photoshop сравним, тогда найдётся ещё больше задач, с которыми vim справляется намного лучше.
Я относительно молодой разработчик, который не застал нафталиновых времен, но перешел с ваших свистящих IDE на (neo)vim+плагины несколько лет назад. И более всего меня удивляет категоричность таких высказываний. Такое ощущуние, что это какой-то комплекс, ибо других причин говорить что инструмент не нужен, что нет причин им пользоваться и что вообще «если вы минусуете, это доказывает мою правоту» — я не вижу (вас не заставляют на нем писать на работе?). Можно посмотреть статистику использования vim плагинов для разного ПО, можно посмотреть как развивается сами vim-like продукты, можно просто посмотреть публикации по теме и активность комьюнити. Кому-то нравятся возможности легкого расширения функционала, кому-то концепция режимов, кому-то удобны hotkey из коробки. Я когда-то перешел с clion, ибо мне не хватало настроек для сложных случаев (и под конкретный проект).

Сейчас пойду в статью про Visual Code и начну им рассказывать, что их инструмент не имеет никаких достоинств, ибо все что у них есть 1000 лет уже есть в vim\emacs и вообще трухакеры пользуются только терминалом, а все эти ваши окна для последних юзеров. Может тоже понаставят "+"-ов.
НЛО прилетело и опубликовало эту надпись здесь

nano это только для тех кто не умеет в vim(меня)

У nano набор команд проще. И нет этой придурочной концепции из двух режимов. И хелп на видном месте, - как минимум, знаешь, что выход - это ^X, а не бип-бип-бип!

Единственно, что vim унифицирован с less. Поэтому знать минимальный набор шоткатов вима полезно.

Вимом пользуюсь исключительно от безысходности. Если надо по ssh что-то существенное поредактировать, то, внезапно, тот же VSCode умеет подключаться по ssh. А всякую мелочёвку, типа git rebase -i, - какой редактор там по умолчанию настроен, тем и редактирую (настраивать гит в общем докере под себя - лень). Поскольку это или nano, или vim, то приходится уметь в оба.

На счёт vscode согласен.

А так если много где нужен, то по моему проще уж vim освоить,чем с nano барахтаться

Ну да, от безысходности и не такому научишься. Это как учиться добывать огонь трением: спички и зажигалки куда удобнее, но если оказался в полной жопе посреди леса с одним ножом и шнурками из ботинок, то лучше уметь, чем не уметь.
Зачем для концептуальной свежести останавливаться на vime, если еще есть ed?

можно оставить привычную IDE, и включить в ней эмулятор Vi в редакторе. Большинство современных редакторов и IDE это умеют.

когда я впервые увидел vi я честно испугался. Сегодня я не понимаю как можно его не любить. Да, для серьезного программинга он не подходит, но у меня часто работа идет через мобильную сеть и вот там все эти кнопки перехода по строке и т.п. прям спасают. Так что как всегда - кому-то хрящик, кому-то поп...

Насчет серьезности я бы поспорил. Кому-то хватает простого набора тегов, перехода по ним и выхлопа компилятора, чтобы писать весьма серьезный софт. Кто к чему привык. У меня вим почти daily driver редактор. Иногда по шорткату проще открыть файлик и изменить его, чем запускать специализированную IDE, ждать пока она прогрузится и откроет весь проект + сожрет 2-3+ Гб памяти. К тому же, все эти IDE как не могли нормально и за вменяемое время открыть файл с логом на 10-15ГБ, так и не могут сейчас. Вим же в легкую это делает.

Многим не нравится vi и vim, и многие утверждают, что nano и ee, и графические редакторы лучше. Но тут идет не понимание довольно базовых концепций. Запускать графический редактор под рутом это плохо для безопасности, и не очень удобно, а как быть с удаленным сервером? Плюс vi и vim это то, что разделен процесс перемещения по файлу и редактирование, чтобы вы случайно при перемещении в конфигурационных файлах не наделали случайных опечаток, не сохранили их и не положили сервер. Плюс хоткеи и еще куча мелких плюшек, которых нет в nano.

тут идет не понимание довольно базовых концепций. 

Тут начинается холивар, а не непонимание.

Vim и nano? Почему не 'супергеройский' Emacs vs vim?

Emacs слишком сложен. vi и vim простые как топор. vimtutor можно изучить очень быстро и он на русском, если правильно локаль настроена. C emacs такого быстрого обучения не будет. nano же проще их обоих и функционал скуднее.
Странно, мне Emacs (точнее jed с emacs mode) зашёл достаточно быстро, а концепция vi с режимами просмотра/редактирования кажется менее удобной.
На мой взгляд они разные и для разных целей, vi и vim это быстрые редакторы, в emacs же можно построить удобную рабочую среду для программирования и отладки, в этом он имеет преимущество и гибче чем vim. Концепция просмотр и редактирование это в первую очередь концепция безопасности при работе с конфигурационными файлами под рутом, это можно сказать админский редактор. Для нормальной разработки все же есть IDE у которых хорошая интеграция с линтерами, статическими анализаторами и т.д.

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

А насчёт концепции безопасности. Что безопаснее, в режиме вставки что-нибудь в тексте понаписать, или в "обычном" режиме нажать какое-нибудь dd и одним махом грохнуть всю строку?

НЛО прилетело и опубликовало эту надпись здесь
Но тут идет не понимание довольно базовых концепций.

И не говорите! графический редактор

Если у вас Linux или Mac OS, откройте терминал и введите ed

Если у вас Unix, откройте терминал и введите ed

Termux/Cyberpunk на Android
пруф
пруф

Никого же не смущает, что современный топор - это то же самое каменное рубило на палке, только стальное, а палка из армированного пластика? И многие, кстати, считают, что в 21 веке топор не нужен ;)

vim тоже представляет старую, но вполне годную концепцию.

И многие, кстати, считают, что в 21 веке топор не нужен
Вы не поверите, но если во времена каменных топоров ими делали всё, то теперь дома строят из кирпича и бетона, мебель покупают в магазине, свинью вообще не все вживую видели… Я не говорю, что топоры в 21 веке не нужны вообще, но их адекватная область применения сократилась на порядки.
А вот vim почему-то «ну знаете, через интернет заказать себе стол — это, конечно круто, но самому, каменнымстальным топором сделать — это ж совсем другое дело!»

Вы не поверите

Поверю ;)

При наличии в 21 веке кучи специализированных инструментов, с электро, бензо, пневмо приводом особой необходимости нет. Но наличие мощного, универсального, простого инструмента ещё никому не повредило.

ЗЫ: вот, к примеру, вынуть кусок таблицы в csv, вставить в середину документа xml, завернуть в правильные теги. Иногда случается такое. Какое IDE умеет одновременно и в xml и в csv?

Если что-то несложное, то та же идея, саблайм тоже полне всё поддерживает. Если что-то более сложное, то очень удобна IDLE, ведь как бы то ни было, но питон мощнее, чем вимовские команды.

Какое IDE умеет одновременно и в xml и в csv?

А IDE ли тут требуется, или проще программу написать?

Можно и программу, конечно. Но в vim это делается за пару минут, а программа (одноразовая!) будет писаться значительно дольше.

Чтобы сделать это в vim за пару минут — надо встречать подобные задачи довольно часто, чтобы нужны плагины уже были установлены, а нужны команды — запомнены. Но в тех же условиях я и программу без проблем за пару минут напишу.


Вот пример:


using var csvFile = File.OpenRead("…");
using var xml = XmlWriter.Create("…");
xml.WriteStartElement("root");

foreach (var line in CsvReader.Read(csvFile, new CsvOptions { … })) {
    xml.WriteStartElement("foo");
    xml.WriteElementString("bar", line[0]);
    xml.WriteElementString("baz", line[1]);
    xml.WriteEndElement();    
}

xml.WriteEndElement();

Вроде в пару минут уложился.

Я не совсем правильно выразился... В существующий xml документ добавить немного тегов ;) В правильное место, конечно же.

Но даже для упрощенной задачи столько букв нажимать не нужно.

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

Конечно можно. 100500 способов есть для решения этой задачи. Просто я, например, тот код на питоне без подглядывания в документацию не напишу. Не помню, какими комнадами packman ест чертика парсить csv и как правильно писать в xml. И его ещё отформатировать надо бы, а то строку в 1Мб редактировать неудобно ;) Свою реализацию я оцениваю минут в 15. А команды vim для выделения/замены внутри выделения помню, они очень простые ;)

Ну, в документацию и я подглядывал, но уложиться в пару минут это не помешало. А ведь ещё есть IDE с контекстными подсказками, которые тоже время прилично экономят.


И его ещё отформатировать надо бы, а то строку в 1Мб редактировать неудобно

А форматирование путём автодобавления отступов в XmlWriter является режимом по умолчанию.


Да и любой XML-редактор это форматирование в случае необходимости без проблем добавит.


PS кстати, когда вы оцениваете время на превращение CSV в XML через выделение/замену в пару минут — вы учитываете что формат CSV допускает многострочные значения?

вы учитываете что формат CSV допускает многострочные значения?

Нет конечно ;) Для совершенно любых входных данных может оказаться очень много тонкостей. Но это же ручная и одноразовая работа. Входные данные один раз можно и проверить. Глазами просмотреть, посчитать число слов/строк, убедиться что аномалий нет.. Тем более что проверять всё равно нужно. Но это совсем другая история.. В vim прогнать выделенный фрагмент через однострочник просто ;)

Ну вот вы проверили, и увидели что аномалия таки есть. Что дальше? :-)

Смотря какая аномалия ;) Если, например, мне нужно импортировать список IP адресов, а в середине таблицы попался email - нужно смотреть что не так. Плохо отформатированные данные (отформатировать хорошо), просто плохие данные (отбросить плохие/запросить хорошие..) ..

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


Программно-то это делается запросто.

Программно-то это делается запросто.

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

Во-первых, я тоже за 5 минут всё сделаю и забуду. Во-вторых, oocalc не vim.

Во-первых, я тоже за 5 минут всё сделаю и забуду.

Не верю ;) Если вы начнете пихать в программу логирование, валидацию, тесты - количество строк уже пойдет на десятки.

Во-вторых, oocalc не vim.

Да. Дополнительного условия "всё делать не выходя из vim" сами себе не будем ставить.

Не вижу ничего невозможного в том чтобы написать одноразовую программу за 5 минут.

НЛО прилетело и опубликовало эту надпись здесь
ЗЫ: вот, к примеру, вынуть кусок таблицы в csv, вставить в середину документа xml, завернуть в правильные теги. Иногда случается такое. Какое IDE умеет одновременно и в xml и в csv?

Geany? Eclipse? В конце концов, это же просто текст.

Да хоть и notepad ;) Vim точно умеет разные операции с выделенным фрагментом. Другие редакторы - возможно умеют.

И всё, что требуется — использовать подходящий инструмент. Внезапно. Поэтому для создания форматированного документа я запускают LibreOffice Write, для написания кода — Geany, для чтения и написания писем — Claws mail, а мелкие правки конфигоф, закопанных в дебрях /etc использую mc и mcedit. И да, иногда использую и vim, но он менее удобен, потому что не интегрирован с файловым менеджером, позволяющим в одном редакторе открывать сразу кучу файлов без запоминания пути, по которому я очередной файл нашёл. Да, mcedit более топорный, но если мне надо массово править код, я делаю это на своей машине в удобной IDE, а изменить пару строк можно и в mcedit. И только в совсем плохих случаях, когда нельзя поставить mc, я работаю из голой командной строки и в vim. Да, его можно настроить, но — внезапно — именно в тех случаях, когда я вынужден в нём работать, у меня нет ни права ни времени возиться с такими настройками на чужом хосте.

не интегрирован с файловым менеджером

Тут вас обманули ;)

И как же мне перейти к панелям mc, в них выбрать файл и открыть в том же редакторе? А, да, надо же ещё и вспомнить, каким заклинанием переключать файлы в самом редакторе и не запутаться в навигации обучалки. А главное, зачем мне весь этот геморрой, если у меня уже есть установленный mc с интегрированным mcedit?

И как же мне перейти к панелям mc

Если вам нужно открыть список файлов

:vsp .

Сам почему то так не делаю, но должно работать.

Если нужно именно mc, тут вам виднее ;)

Мне же нужно открыть файл, находящийся в произвольном, заранее не известном месте, так что да, нужно чтобы был доступен mc и второй, третий и далее файлы открывались в одном и том же редакторе и между ними можно было произвольно переключаться. А vim позволит открыть либо файл, который лежит рядом с первым, либо с помощью введения пути, который, в общем случае, ещё не известен.

Странные задачи требующие странных решений ;)

Если бы мне нужно было что-то подобное - я бы, наверное, построил однострочник из find, grep, xargs и vim. И потратил бы ещё 5 мин на чтение справки, как переключаться между открытыми файлами. Потому что если файлов действительно много, и они действительно разбросаны как попало, то клацать их в mc мне уже не нравится. А если правки однотипные - возможно, запилил бы патч и приложил бы интерактивно через похожий однострочник с vim в diff mode в конце.

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

То есть вы предлагаете в незнакомой системе открывать с помощью mc все файлы подряд. Все 100500. Ну, я то и не возражаю ;). Но я бы так не делал. Мне больше нравится, когда работу за меня делает компьютер.

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

Если я знаю названия файлов - find найдет их моментально. Если результат мне понравится - нажму стрелку вверх, допишу

| xargs vim

и спокойно сделаю что собирался. Возможно, сначала backup сделаю. Тем же однострочником.

А вот при ручном поиске всегда есть шанс что то пропустить.

Хорошо, если Вы знаете эти названия. Если я знаю названия и где эти файлы лежат, то вообще почти никаких проблем нет. А если не знаю? Потрудитесь перечитать описание задачи: незнакомый хост, который просто выдали и сказали что-то сделать. На старте даже неизвестно, как какой там дистрибутив и какой версии, не говоря уже о наборе софта. Думаете, заказчики сами знают, что у них там стоит? Зря так думаете.

Потому что mc — менеджер файлов и позволяет просматривать содержимое директорий не наугад, а видя названия

Вы уж определитесь, знаете вы названия файлов или нет ;) Тем более если вы этим занимаетесь постоянно.

А тут нет никакого противоречия. Я программист и мне ИНОГДА надо самому разворачивать написанные мною парсеры на серверах заказчиков. На домашних компьютерах у меня Fedora, а на серверах чаще всего стоит Ubuntu, которая для меня очень неудобна. Поэтому стараюсь администрированием таких серверов не заниматься. Но иногда приходится. И то, что я что-то знаю про Федору, не сильно спасает, когда надо что-то сделать в Ubuntu, потому что, к примеру, у Apache структура конфигурационных файлов отличается радикально. И таких различий полно. А главное, зачем мне загружать память редко востребованной информацией не по профилю, если её можно просто найти, воспользовавшись подходящим инструментом?

Не загружать память - в моем понимании это 1 раз пройти этот квест и сохранить его шаги в виде скрипта на флешку или в git, у нас же 21 век давно. Но я не настаиваю, mc тоже достаточно подходящий инструмент.

А ничего, что хосты каждый раз разные, с разными ОС и разными их версиями?

Если мне вдруг стало известно, что "на серверах чаще всего стоит Ubuntu", я бы, наверное, ориентировался на эту самую Ubuntu. И ещё мне кажется, что во всех версиях Ubuntu апач настраивается очень похоже. Я бы, возможно, даже оформил свою программу как модуль этого самого апача, и включал бы его по a2enmod. Чтобы, по возможности, избежать правки конфигов.

Но я не настаиваю, что этот способ ковыряния в носу самый лучший :)

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

Знать название файла и узнать его видя название — разные вещи.

НЛО прилетело и опубликовало эту надпись здесь

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

НЛО прилетело и опубликовало эту надпись здесь
А это уже отдельная тема, вроде «шашечки или ехать», результат или процесс. И естественно, что сделать своими руками — это отдельные и очень крутые «шашечки».
Я не хочу сказать, что Vim должен заменить всё, чем вы сейчас пользуетесь, но его изучение и настройка улучшат ваши навыки.

Мне кажется, в пору уже чемпионаты устраивать по «навыкам». Каждая статья про чудодейственный вим полна намеков на то, что я должен забыть свою любимую ИДЕ и начать юзать вим, потому как… А вот дальше авторы не углубляются. Достаточно сказать «навыки улучшатся». Какие такие навыки, зачем они мне нужны, почему я должен отказаться от IDEA в пользу какого-то консольного уродца родом из 70-х, долго пыхтеть над текстовым конфигом сего редактора, чтобы получить хоть сколько-нибудь рабочую среду, с неисправимо мозголомным управлением? Улучшеные навыки должны давать некие преимущества. Преимуществ у вима по сравнению с адекватными современными программами нет, при наличии кучи недостатков доставшихся в наследство от безоконных времен. Дайте хоть какой-нибудь пример, что именно станет лучше. Не абстактные улучшения, а конкретный пример. Вот, например, я могу сказать, что автодополнение кода существенно уменьшает количество ошибок компиляции, ускоряет набор кода и уменьшает количество обращений к документации. Это очевидное преимущество ИДЕшек умеющих в автодополнение, перед теми, которые не умеют. Хотелось бы что-то подобное узнать и про вим, кроме абстрактных восхищений и обещаний увеличения, усиления и улучшения непонятно чего.

Не обязательно отказываться от IDE, чтобы получить плюшки вима. Можно установить плагин(например IdeaVim), и получить лучшее от обоих (ну разве что IDE от установки плагина быстрее в двадцать раз не станет)

Основные киллер-фичи вима это наличие режимов(offtop: не видел ещё ни одного GUI редактора, который умел бы в аналог Visual-block), соответственно все основные хоткеи делаются в одну кнопку

И очень элегантная система этих хоткеев - вместо абстрактных шифтов и альтов есть комбинируемые базовые кирпичики.

Например, я хочу заменить строку-токен внутри кавычек. Я пишу ci" и вставляю из буфера, редактор уже в нужном режиме. Команда расшифровывается довольно просто

Change Inside "

Мне лично очень удобно

И конечно же, её можно интуитивно модифицировать, например если токен нужно просто скопировать, это будет yi" (y = yank)

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

А если это более сложные хоткеи, например вызов функций Lang-server-а (или IDE, если используется плагин), то их можно забиндить в любой режим на любую комбинацию кнопок, какая будет интуитивна лично вам

А вообще, не хотите - не переходите, вим или не вим это вопрос личного удобства каждого.

А если это более сложные хоткеи, например вызов функций Lang-server-а (или IDE, если используется плагин), то их можно забиндить в любой режим на любую комбинацию кнопок, какая будет интуитивна лично вам


да в этом то и есть основная проблема vim/emacs. Подавляющая часть того, что вы навешиваете на сложные хоткеи, используется раз в неделю. Чтобы вызвать функцию какого-то-там сервера гораздо проще на мой взгляд выбрать эту функцию из выпадающего меню. Вот это интуитивно. А не миллион хоткеев на все случаи жизни. Вот например, моя ИДЕ умеет строить диаграмму классов. Очень полезная фича. Пару раз в день я ее использую. Моя производительность труда никак не страдает от того, что я не знаю для нее хоткея. А вот если хоткей будет единственным способом достучаться до этой фичи, то она начнет страдать, потому что я начну непроизводительно тратить время на поиск долбаного хоткея, на что же оно там навешено.

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

И очень элегантная система этих хоткеев — вместо абстрактных шифтов и альтов есть комбинируемые базовые кирпичики.

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

Основные киллер-фичи вима это наличие режимов(offtop: не видел ещё ни одного GUI редактора, который умел бы в аналог Visual-block), соответственно все основные хоткеи делаются в одну кнопку

Нет, вы здесь явно скрываете тот факт, что однокнопочный хоткей, это две операции — переключение режима, и сама функция. CTRL-Z мне кажется сделать не сложнее, чем ESC + u.

Мне лично очень удобно

Да бога ради, так и надо говорить, а не приплетать какие-то навыки, как это в статье было сделано.

вим так же может быть запущен с gui, и также в нем есть меню, где могут быть любые команды.

но вызывать базовые команды редактирования текста из меню это очень неудобно, они используются постоянно. И основная проблема иде имеено в том, что невозможно запомнить эти 100500 хоткеев из ctrl alt shift. В тоже время в вим команды формируются из отдельных кирпичиков, и даже если отдельные команды используются редко, части из которых состоит эта команда используются постоянно, как отдельно, так и в составе других команд, поэтому вспоминать ничего не требуется, нужно просто составить команду из известных частей.

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

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

ни один идиот ни в одном редакторе не вызывает базовые команды редактирования через меню. Есть всем известный десяток комбинаций клавиш, который составляет базовый набор команд и покрывает 99% операций с текстом

невозможно запомнить эти 100500 хоткеев из ctrl alt shift.

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

и не надо нажимать esc перед каждой командой… esc надо нажимать сразу после

не вижу смысла продолжать спор

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

вы назвали основной проблемой vim/emacs, что редко используемые функции навешиваются на хоткеи. В чем тут проблема у вим по сравнению с любой ид? В вим так же все эти команды для сложной функциональности могут быть в меню. Но базовые команды редатирования туда выносить безссмысленно. Вот основная беда иде в том, что запомнить можно пару десятков таких хоткеев, больше или просто нет, или такое число горячих клавиш просто не запомнить. Да это покрывает 99% доступных в иде операций с текстом, но не покрывает и 10% операций доступных в вим. В модели редактирования вим надо запомнить пару десятков команд и пяток правил для их комбинации, и из этого получаются сотни действий для базового редактирования текста.

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

Да что вы такое говорите?
Вот так выглядит вим по дефолту
image
а вот так в нормальных ИДЕ можно получить любую команду, даже такую, которую вы используете раз в пять лет или вообще никогда про такую не слышали
image

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

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

Когда я с ним впервые столкнулся, чтобы узнать, как получить доступ к подсказке, мне пришлось искать подсказку в Сети. Только после этого встроенная подсказка мне уже была не нужна. Когда мне в следующий раз понадобилось работать с vim, мне снова пришлось лезть в Сеть и снова встроенная подсказка не пригодилась. Когда же я попробовал воспользоваться встроенной… В общем, закрыл и больше не пробовал открывать, потому что она дико неудобная. Не абстрактно, а вполне конкретно, потому что набор моторных навыков радикально отличается от того, что мне попадалось раньше. А я с компьютерами общаюсь где-то с середины 80-х. И с Linux работаю с конца 90-х. Но с vim столкнулся только где-то в 2005-2006, не раньше, когда пришлось удалённо устанавливать и настраивать продукт на серверах заказчика, а там была Solaris. И кто бы мне позволил настраивать там все эти красивости? А главное, кто бы дал время на это?

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

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

Неужели вы действительно полагаете, что пользователи вим ни разу не видели и не пользовались иде? Или считаете, что если неудобно вам, то и всем должно быть неудобно? Сейчас на вим именно переходят с обычных редакторов, и именно потому, что его модель редактирования удобнее. И случаев когда "просто привык к вим, и не знает что есть в иде" сейчас найти невозможно.

Кстати, да, интерфейс меню не только позволяет компактно упихать огромное количество функций, про которые пользователь никогда не слышал, но выполняет обучающую функцию, потому что эти самые функции, про которые пользователь не слышал, он может в меню найти. Даже просто подумав, что нужна какая-то функция, можно начать её искать в дереве меню и найти эту функцию, если она есть. А заодно узнать ещё о куче других. Именно по причине отказа от концепции меню в MS Office в 2007 году его интерфейс настолько испортился и не позволяет пользователям изучать функции пакета.

Это не то, чтобы спор на самом деле.

Большинство тех, кто пользуется вимом, так же как и вы сейчас, когда-то испытывали к нему отвращение и помнят себя на вашем месте. Но вы на их месте ещё не были, поэтому очень сложно обьяснить «в чем прикол».

Но я постараюсь поставить вас на место этих людей)

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

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

Я обожаю Идею, без многих ее плюшек было бы совсем грустно, но без вим плагина я обожал бы ее меньше.

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

Но вы на их месте ещё не были

это вы с чего, простите, взяли?
Но когда диаграмму классов приводят как ее конкурентное преимущество

покажите, пожалуйста, пальцем, где я приводил диаграмму классов в качестве преимущества?

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

покажите, пожалуйста, пальцем, где я приводил диаграмму классов в качестве преимущества?
Да вот, показываю:
… Вот например, моя ИДЕ умеет строить диаграмму классов. Очень полезная фича. Пару раз в день я ее использую. ...
Но я понимаю, вы, наверное, что-то другое имели ввиду.
Наверное, что «это не преимущество IDE, а недостаток вима». Или что «это не преимущество, а достоинство».

И причем здесь
пребывать в иллюзиях обладания тайными знаниями, «навыками» и мнить себя крутым хакером
? Вы себе это сами придумали. Знания настолько тайные, что вас
… конкретно заколебали раз в неделю появляющиеся мамкины хакеры, рассказывающие про какие-то чудеса...
Это, я извиняюсь, уже совсем абсурд.

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

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

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

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

offtop: не видел ещё ни одного GUI редактора, который умел бы в аналог Visual-block

Наверно, потому, что плохо искали. Тот же SublimeText это умеет.

Мой пример возможно нерелевантен, но я использую vim для написания литературных текстов. В порядке хобби по вечерам пишу фанфики.

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

Первое время решал эту проблему, делая копии файла перед каждым серьёзным редактированием. Но когда количество старых копий перевалило все мыслимые пределы, так что я начал в них путаться, то пришло понимание, что так дело не пойдёт, и хорошо бы прикрутить к этому делу git. Я больше недели пытался придумать способ прикрутить контроль версий к документам LibreOffice, но не преуспел. Все найденные решения оказывались какими-то кривыми, монстроидальными и неудобными в использовании.

Тогда возникла очевидная идея писать фанфики с использованием чего-то вроде Markdown, чтобы можно было без проблем класть текст в реп и использовать все механизмы git.

И вот тут встал вопрос подходящего редактора. Во-первых, редактор должен нормально работать с русским текстом в utf-8. Вы удивитесь, какое количество редакторов даже в 2021 году на это не способно. Во-вторых, там должна быть возможность прикрутить проверку орфографии для русского языка. В-третьих, редактор должен уметь подсчитывать количество слов в набранном тексте. Я желаю видеть текущий объём текста по мере написания. На самом деле из Plain Text-редакторов даже и число символов-то могут подсчитать очень немногие. Geany, к примеру, считает объём текста в байтах. Далее очень желательно, чтоб редактор был кроссплатформенным (как минимум Windows и Linux) и чтоб все настройки было легко переносить от машины к машине, а в идеале вообще прямо в реп сложить.

А ещё очень хотелось бы, чтоб редактор был пошустрее. Если LibreOffice ещё можно простить его медлительность, то вот когда притормаживает редактор самого простого текста, это раздражает очень и очень сильно.
Я перепробовал множество редакторов, но везде хоть чего-то да не хватало. Или проверки орфографии нет, или после её добавления тормозить начинает.

Какое-то время сидел на reText (ИХМО, единственный более-менее вменяемый редактор Markdown, где всё есть из коробки и нет проблем с кодировкой), но однажды после обновления Python он отказался запускаться из-за каких-то проблем с биндингами PyQt.

Вот тогда я пожаловался в фэндомном треде, где обсуждались инструменты фикрайтера — мол, так и так, редактор сдох, надо опять искать что-то новое, кто чем пользуется? И вот тут мне предложили попробовать vim. Оказывается, в данном фэндоме довольно заметный процент фанфикописателей его использует.

Моя первая реакция: «Да вы прикалываетесь, что ли?» А мне ответили, что оно конечно на любителя, но почему бы не попробовать? Вдруг зайдёт?

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

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

Далее пошли бонусы. Оказывается, навигация по тексту в vim намного удобнее, чем в LibreOffice. Метки позволяют быстро перебегать туда-сюда. Удобный поиск по тексту. Хоткеи на все случаи жизни — удалить текущее слово, прибить всё внутри кавычек, убить текущее предложение, грохнуть абзац, изменить текущую букву со строчной на прописную и наоборот. Больше не нужно ничего выделять мышкой, тщательно целясь. Даже перейти в конец текста можно одним нажатием, а не утопив PgDn в пол до упора.

Приятно удивила высокая кастомизируемость. Можно настроить цвета всего, вплоть до заголовков, комментариев и TODO-вставок в текст.

Из плагинов установил один лишь vim-auto-popmenu, целиком скопировав его код в .vimrc (там менее 200 строчек кода), тем самым получив автодополнение: после набора первых двух символов слова появляется всплывающая подсказка с наиболее используемыми в данном тексте словами, которые с этих символов начинаются, и есть возможность по Tab (сверху) или Shift-Tab (снизу) быстро дополнить до нужного слова:

как-то так

Весьма заметно ускоряется набор текста.
Также на скрине вы можете видеть, как настроено отображение абзацев. Каждый абзац — это ровно одна строка обычного текста. И перенос по словам, и отступы слева по типу красной строки — это просто особенности отображения, никаких Tab'ов или пробелов в начале строк в файлы не попадает, абзацы разделяются только символом разрыва строки. Какой ещё редактор кроме навороченных типа Word/Writer можно так настроить?
Даже перейти в конец текста можно одним нажатием, а не утопив PgDn в пол до упора.

На всякий случай, вдруг пригодится: Ctrl-End работает в большинстве редакторов в Винде и не только.
Спасибо, не знал. Проверил — действительно работает везде, даже в LibreOffice.
Спасибо за замечательную историю, но мне одно непонятно: как вы миритесь с тем что пишете на русском, а команды в vim только на английском? Или вы нечасто используете командный режим и для вас не проблема переключить язык пару раз в час? Или его как-то можно настроить чтобы в командном режиме он не обращал внимание на то что включена нелатинская раскладка? Пробовал писать в нем лонгриды на русском языке, но необходимость переключать раскладку для меня неприемлема.
Особо не парился с этим, сунул в .vimrc
set keymap=russian-jcukenwin
set iminsert=0

После чего в insert mode достаточно один раз нажать Ctrl+6, чтобы при включении insert mode всё автоматически набиралось на русском, и в командах замены вроде r тоже на русском, и в командах поиска вроде / тоже автоматом включался русский, а normal mode, visual mode — работала латинская раскладка.

Если речь только про редактор plain текста, то у меня если винда, то notepad++ для этих целей, если Линукс, то что то типа featherpad. Ничего не тормозит, и мыш работает как надо, и клавишные комбинации тоже.

Если надо артиллерия помощнее - то IDE или VS Code. Практически все "из коробки".

Поэтому не понимаю, для чего нужен вим в 21 веке... ИМХО древний редактор турбо с и тот поудобнее был...

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

Настоящие программисты не используют Паскаль
… Настоящий программист в таких условиях должен выполнять работу с помощью текстового редактора. Большинство систем предлагают на выбор несколько текстовых редакторов, но настоящий программист должен быть очень осторожен в выборе, отражающего его индивидуальность. Многие думают, что наилучшие текстовые редакторы в мире написаны в исследовательском центре фирмы Xerox в Palo Alto для работы с ЭВМ марок Alto и Dorado. К сожалению, ни один настоящий программист не будет работать на ЭВМ с операционной системой под названием Smalltalk (короткий разговор) и конечно же не будет беседовать с ЭВМ с помощью «мышки».
Некоторые из концепций этих редакторов фирмы Xerox были реализованы в редакторах, работающих в операционных системах с более солидными названиями, такими как EMACS и VI. Дело в том, что настоящий программист считает плохим следующий принцип редактора: «То, что вы видите, то вы и получите». Настоящий программист желает редактор с принципом: «Вы это просили, вот вам»; т.е. редактор, который был бы сложным, шифрованным, мощным, непрощающим и опасным. Редактор TECO — чтобы быть точным.
Было замечено, что последовательность команд к TECO более напоминает помехи в линии передачи, чем читаемый текст. Одна из самых развлекательных игр с TECO — напечатать в качестве командной строки свою фамилию и попытаться догадаться, что она сделает. Точно так же любая случайная опечатка при работе с TECO может разрушить вашу программу, или, хуже того, внести неуловимые и мистические ошибки в уже работающую программу.

пользуюсь только вимом без всяких плагинов и настроек.

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

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

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

НЛО прилетело и опубликовало эту надпись здесь

у меня есть он, конечно.

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

Это же относится и к всяким zsh...

Честно пытался перелезть с ломаного phpstorm на vim\neovim.

Перепробовал все плагины и автокомплиты. Досконально изучил хоткеи и команды. Честно пытался перейти, чтоб сделать что-то похожее и такое же удобное. В итоге не смог.
Анализатор кода и автодополнения в IDEA слишком хороши.

В итоге плюнул и купил лицензию.

Но любовь к vim осталась. Использую его для редактирования конфигов и быстрого поиска по гигабайтным (да вообще всем) логам. Работает очень быстро, это его главное достоинство.
У меня к Vim есть только одна серьезная претензия — он не умеет работать с файлами неограниченного размера, под терабайт. То есть у него нету (или я так и не нашел, хотя долго искал) режима, в котором часть супербольшого файла отображается на какую-то область оперативки, и дальше редактор работает с этим «окном», при этом показатель private bytes для процесса не вырастает до каких-то невменяемых значений. Так умеют делать редакторы вроде EditPadLite или HxD, но почему-то не Vim. А очень жалко, хоть самому пиши (иногда с опаской думаю я).

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

Можно и без dd, hex редактор должен уметь любые файлы.

Но всё равно странно; образ диска совсем не текст, зачем хотеть открывать его текстовым редактором?

Терабайт логов разве что.

У логов не должно быть такого размера, они должны резаться на части. Собственно, разного рода log rotate для того и придумали.
В моей практике было, что в середине (условно) очень большого лог-файла была какая-то информация, которую хотелось поанализировать: регулярками потыкать, строки с определенным паттерном вывести сплошным списком, и т. п. И оказалось, что Vim такой файл пытается прочитать до конца в буфер (то есть в свою область оперативы), и только потом дает возможность с ним работать. А на файле такого размера Vim-у становилось плохо, и ничего не работало. Причем совет нажать Ctrl-C во время открытия файла не помогает, это приводит к тому, что в буфере оказывается только та часть, которая успела считаться до нажатия Ctrl-C.

Причем просто посмотреть в середину супербольшого файла умеет много софта (тот же просмотрщик в Far manager), но вот когда там находится информация, которую надо не просто посмотреть глазами на экране, а скопировать оттуда кусок размером ~100 страниц для дальнейшего анализа — надо искать софт, который так умеет. Вот Vim так не умеет, к сожалению.

если оперативки хватает, то помогает ограничение области для подсветки синтаксиса, или его отключение. есть еще несколько настроек, типа отключения своп файла.

есть плагины которые автоматом включают эти настройки для больших файлов.

А так да, вим примитивно грузит весь файл в память, может в neovim это изменят.

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

Ни один ТЕКСТОВЫЙ редактор не умеет, потому что назначение у него другое, потому что он всегда загружает файл в оперативную память и работает с ним там. Потому что иначе он начинает дико тормозить, потому что вставка или удаление одного символа потребует сдвиг всего хвоста файла.
Я по-прежнему предпочитаю vim/gvim. Должен признать, что освоение требует времени несколько большего, чем Atom/Eclipse…
Это недостаток.
Gvim совершенно нормально работает с мышью, что облегчает жизнь новичкам. Но работа с клавиатурой просто быстрее.
Клавиатурные сокращения назвать удобными трудно, но для часто используемых операций вы их либо запомните, либо переназначите в конифиге на более удобный вариант.
Далее, вам придётся приспосабливать редактор под свои привычки и это как раз сильная сторона.
Большой бонус — всё чему вы научились, никуда не исчезнет и пригодится в дальнейшем.
В завершение. Если вы не видите никакой пользы для себя от использования vim, то он вам просто не нужен.
Людей, которые находят довольно эффективные способы использования vim и при этом делятся своим опытом довольно много.Так что пока курилка жив.
А ничего что в статье не сказано про главное преимущество данного редактора? Все операции (все!) можно выполнить вслепую, никогда не выходя за пределы 5 рядов клавиатуры. Вроде как ни один другой редактор с настолько тяжелым функционалом не может похвастаться такой фичей.

Странное какое то "преимущество", честно говоря... Это примерно как вести машину закрыв глаза и без автопилота.

НЛО прилетело и опубликовало эту надпись здесь

ИМХО лбллб IDE и VSCode, но везде стараюсь ставить эмуляцию Vim. Благодаря ему можно очень быстро перемещаться по тексту не используя мышку

Очень полезная вещь когда надо поправить какой-нибудь shell-скрипт на отладочной плате через терминал, например

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

Наверное, Вы сильно удивитесь, но в средах с графическим интерфейсом есть такая вещь как горячие клавиши. Попробуйте, Вам понравится.
Через 20 лет знакомства с редактором vi я наконец решился загуглить и узнал как добавить символы в конец строки, если строка не пустая.
На основе кода em Билл Джой разработал ex, что расшифровывается как «extended ed»

После em (который разработал Джордж Колорис) вообще-то был разработан en. Билл любит шутя говорить “Не помню, были ли там eo или ep, но в конце концов это каким-то образом стало ex”, потому и по расшифровке тоже есть вопрос, не придумана ли она кем угодно из совершенно непричастных к разработке.

Позже в операционных системах появился исполняемый файл vi, но мы по-прежнему можем пользоваться командами ex, вводя: в vi/vim. Редактор ex был выпущен в 1976 году, а исполняемый файл vi — в 1979 году

“Исполняемый файл vi” был всего лишь hardlink'ом ex. То есть vi версии 2.0 (май 1979) — это не новый редактор с возможностью исполнения команд ex, а сам ex и был, просто при запуске по имени vi он сразу оказывался в visual mode.

Очень распространён миф (их много в поддержку гениальности ряда программистов тех лет), будто vi был написан Джоем за неделю. Таки это миф. На создание vi у Джоя ушло несколько месяцев. Дело в том, что разрабатывал он его дома, сидя на “рабочей” PDP-11 через модемный линк 300 бод (в отличие от рожающего тогда emacs Столлмана, в распоряжении которого была мощнейшая (сравнительно) PDP-10 с локальным терминалом). Перерисовка экрана целиком была чудовищно долгой операцией, и Джой основные усилия затратил как раз на предельную минимизацию трафика, чтобы даже при такой скорости соединения экранный режим редактирования оставался комфортным.

А ещё у Джоя не было мышки.

Оценить vi (и влюбиться в него) сложновато большинству тех, из кто начал в фантастических по сравнению с Джоем условиях — персональный компьютер с суперскоростной консолью (даже если это Hercules), поскольку для Джоя даже 1200 бод в терминале были недоступной роскошью, а 9600 (на такой скорости человек уже не успевает читать вывод) — и вовсе фантастикой. Как говорит сам Джой, “vi был создан для мира, который сегодня исчез.”

Тем не менее, в SUS присутствует vi, таким образом любая ОС, претендующая считаться unix, обязана его иметь.

PS: Кстати, то, что Томпсон сделал grep за ночь — не миф :)
Не впадаю из крайности в крайность, для меня лучший вариант — micro.
Это что-то среднее между голыми терминальными редакторами и привычными полноценными ide.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий