Комментарии 172
sublime по мощи уступает vim-у все же.
PS Не пользую Sublime и Vim. Использую иногда vi и то только по необходимости, когда иного не наблюдается.
И, да, по памяти ожидал другой результат увидеть, что vim кушает меньше всего, ан нет!
И интересен вопрос от пользующихся им, насколько круто он выполняет данные функции, как в посте автора?
PS: ввязываться в спор emacs vs vim категорически отказываюсь. Единственное, что наверняка можно сказать про emasc это то, что это отличная операционная система. Жаль только в нем нет нормального текстового редактора ;)
нынче есть очень интересный тред — встраивать средства рефакторинга в тулинг идущий с компилятором/интерпритатором (как это например сделали ребята из TypeScript). В этом есть немало смысла, "не надо ждать пока все IDE добавят новые плюшки", это на руку разработчикам языков. А если все используют одинаковый тулинг для рефакторинга — то спорить кто лучше в этом явно смысла нет.
Кстати интересный проект для emacs — spacemacs.
Какой бы бред вам не пришел в голову Vim это уже умеет.
Да? Хочу, чтобы, когда я жму клавишу "f" в тексте печаталась клавиша f, а когда я зажимаю клавишу "f" и, не отпуская её, зажимаю клавишу "j", редактор делал то, что делается по сочетанию клавиш Ctrl+j .
Или вот, хочу повесить какое-нибудь действие на Ctrl+Shif+j. Как это сделать?
Расскажите про автоматический рефакторинг в Vim (и сколько он с таким обвесом плагинами ест памяти).
У меня есть и Vim и Sublime, и IDE разные, все они выполняют разные задачи.
Лично я использую sublime или nano, по ситуации.
PS: моя основная IDE — Emacs в режиме эмуляции клавиатурных комбинаций Vim (evil-mode) и это реально уберкомбо, соединяющее преимущества обеих сред.
Так что если вы хотите на ЛЮБОЙ машине с ЛЮБОЙ ОС иметь привычный интерфейс среды разработки, альтернативы VIM-у нет.
ЗЫ: и не надо про emacs — не про него тема.
Можно ещё сравнить с полновесными IDE (Visual Studio, Eclipse)… Но это уже будет перебор… Или нет?
Единственное, что навскидку не придумывается (именно не придумывается, не факт, что данную функциональность проблематично реализовать) — это вся и всяческая визуализация, типа тех же ER-диаграмм и прочих связей в БД. А так из vim-a вполне себе лёгкую IDE замастырить, я думаю, не проблема.
Vim — один из самых дебильных редакторов. Более недружелюбного и уродского еще нужно поискать. Но его сила ни в удобстве. И даже ни в его фичах. Его основная сила в том, что на любой Unix и Unix-like системе он будет. И какой бы жидкий канал не был он будет отлично работать.
Его основная сила в том, что на любой Unix и Unix-like системе он будет.
Из коробки — далеко не факт, nano субъективно чаще, а права на установку далеко не всегда есть. И не уверен, что vim можно поставить на самый популярный десктопный Unix её стандартным установщиком.
Ubuntu
Собственно поэтому я и удивился.
Хм… Странно. Регулярно его устанавливаю и основная ОС в компании Ubuntu.
Только что установил свежую Ubuntu 17.04 на новый ноут. Обычный десктопный исошник, не серверный, не сетевой, не минимальный, ни ещё какой:
~$ sudo vim /etc/default/grub
sudo: vim: command not found
~$ sudo apt install vim
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
vim-runtime
Suggested packages:
ctags vim-doc vim-scripts
The following NEW packages will be installed:
vim vim-runtime
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 6.371 kB of archives.
After this operation, 30,8 MB of additional disk space will be used.
Do you want to continue? [Y/n]
Get:1 http://ubuntu.volia.net/ubuntu-archive zesty/main amd64 vim-runtime all 2:8.0.0095-1ubuntu3 [5.299 kB]
Get:2 http://ubuntu.volia.net/ubuntu-archive zesty/main amd64 vim amd64 2:8.0.0095-1ubuntu3 [1.072 kB]
Fetched 6.371 kB in 0s (38,9 MB/s)
Selecting previously unselected package vim-runtime.
(Reading database ... 210651 files and directories currently installed.)
Preparing to unpack .../vim-runtime_2%3a8.0.0095-1ubuntu3_all.deb ...
Adding 'diversion of /usr/share/vim/vim80/doc/help.txt to /usr/share/vim/vim80/doc/help.txt.vim-tiny by vim-runtime'
Adding 'diversion of /usr/share/vim/vim80/doc/tags to /usr/share/vim/vim80/doc/tags.vim-tiny by vim-runtime'
Unpacking vim-runtime (2:8.0.0095-1ubuntu3) ...
Selecting previously unselected package vim.
Preparing to unpack .../vim_2%3a8.0.0095-1ubuntu3_amd64.deb ...
Unpacking vim (2:8.0.0095-1ubuntu3) ...
Processing triggers for man-db (2.7.6.1-2) ...
Setting up vim-runtime (2:8.0.0095-1ubuntu3) ...
Setting up vim (2:8.0.0095-1ubuntu3) ...
update-alternatives: using /usr/bin/vim.basic to provide /usr/bin/vim (vim) in auto mode
update-alternatives: using /usr/bin/vim.basic to provide /usr/bin/vimdiff (vimdiff) in auto mode
update-alternatives: using /usr/bin/vim.basic to provide /usr/bin/rvim (rvim) in auto mode
update-alternatives: using /usr/bin/vim.basic to provide /usr/bin/rview (rview) in auto mode
update-alternatives: using /usr/bin/vim.basic to provide /usr/bin/vi (vi) in auto mode
update-alternatives: using /usr/bin/vim.basic to provide /usr/bin/view (view) in auto mode
update-alternatives: using /usr/bin/vim.basic to provide /usr/bin/ex (ex) in auto mode
~$ Чтобы не было разнотолков. Бо самолично проверял и все было.
$which vi
/usr/bin/vi
Я не знаю что еще сказать.
which vim ?
И прочтите что у него на приветственном экране написано.
ЗЫ Ну и ветка идет от коммента «Сможете вспомнить где «из коробки» не было vi(m)?»
Я знаю, что vi и vim близкие родственники, но я писал исключительно о vim. А запускать после "update-alternatives: using /usr/bin/vim.basic to provide /usr/bin/vi" смысла точно нет, да и не думаю, что в "Need to get 6.371 kB of archives" только новые алиасы для vi из коробки.
При чём тут «близкие родственники»? Во многих дистрибутивах под «vi» понимается «Vim, скомпилированный с минимальным набором возможностей». Возможно, ещё и с порезанным runtime. Понимаете, не новые алиасы, а бинарник с другими флагами при компиляции, плюс runtime файлы.
Я не хочу каждый дистрибутив проверять на то, как он понимает. Или натыкаться на урезанные возможности в привычной вроде бы программе. Да, если приспичит, то буду искать какие редакторы есть в системе, где я не могу установить vim и, вероятно, при обнаружении vi запущу его. Но если именно vim нет, аправа на установку есть, то установлю vim, а не буду копаться.
И к чему это? Здесь опровергали два ваших заявления: сначала «Vi(m) „из коробки“ в системе нет» (https://habrahabr.ru/post/335364/#comment_10355530). Оказывается, есть. Второе, в ответе «Ubuntu» нa «Сможете вспомнить где «из коробки» не было vi(m)?» вы почему‐то имели ввиду только Vim и уж его‐то там нет (https://habrahabr.ru/post/335364/#comment_10367516). Но это тоже не так, там Vim.
Он, конечно, урезанный и мало кто захочет им таким постоянно пользоваться. Но ветка совершенно не об этом.
"Vi(m)" — это ваша самодеятельность, и я говорил, и в комменте на который я отвечал речь исключительно о vim, а не о vi(m)
В комментарии, на который вы ответили «Ubuntu» написано буквально «Сможете вспомнить где «из коробки» не было vi(m)?». Если вас не устроил расширение «Vim» из первого комментария до «vi(m)» (сделанное 9660, а никак не мною), то нужно было так и написать в комментарии с «Ubuntu», тогда он не стал бы неверным. Хотя Vim там всё равно есть.
Первый раз /etc/apt/sources.d/ придется редактировать nano
Я же не утверждаю, что на дебиан нельзя поставить vim стандартными средствами. Глупо было бы утверждать такое.
"самый популярный десктопный Unix" — Макось. Linux не является Unix.
Будем считать что нашли UNIX без vi(m).
Никакой возможности проверить наличие
как жаль что человечество не обладает никакими инструментами для поиска информации...
Будем считать что нашли UNIX без vi(m).
на основании чего? в mac os vim есть.
Из коробки или надо из исходников собирать? :)
сча проверю на новом маке… version 7.4.8056 — из коробки.
это уже не из коробки, да и сам homebrew надо ставить.
Судя по контексту homebrew — пакетный менеджер под MacOS не от Apple, про который надо откуда узнать и как-то установить. По смыслу гораздо ближе к "из исходников собирать", чем к "из коробки".
Сама установка homebrew в систему — буквально одна строчка копипаста.
Вот когда из коробки будет homebrew, тогда будет ближе, а то, что загружается из https://raw.githubusercontent.com/Homebrew/install/master/install вполне может и исходники скачивать, и компилять их, мало чем отличается от строки копипасты типа curl… | tar… && make && make install
Но в любом случае, куча софта (вроде тех же vim/openssl/bash/curl/etc) таки идет из коробки.
А вот по поводу отличий от «make && make install» — позвольте не согласиться :) Сабж — это вполне себе приличный пакетный менеджер со всеми фишечками пакетных менеджеров.
Сама установка homebrew в систему — буквально одна строчка копипаста.
не забудьте поставить xcode build tools.
Прикольно — плюсик к эпплу. Лет через 3-5 может перевесит при выборе очередного ноута :)
я сдался 3 года назад и окончательно перешел в армию людей переплачивающих непонятно за что… в целом именно нежелание выбирать и стало основным доводом (ну и еще желание собирать мелочи под xcode).
Да, за последние дни пару раз был на грани от того, чтобы просто поехать в магазин и взять прошку. Именно из-за проблемы выбора, ну и специфики киевского рынка ноутов — пощупать с десяток моделей ценой 1500+ просто так никто не даст, а макбуки можно.
В итоге выбрал один из Асусов долларов на 200 дешевле приглянувшейся прошки с явным ощущением что перплатил за ненужные мне двд, хдд и игровое видео, но с прошкой были бы риски плохой работы софта с ретиной.
но с прошкой были бы риски плохой работы софта с ретиной.
это если про специфичное что-то говорить, в целом я за 3 года таких проблем не испытывал. Хоть сколько нибудь популярный продукт нормально работает. Да и после ретины работать на обычном дисплее не хочется.
он (точнее, vi) есть в busybox.
91,56384% времени работы в vim использую его как редактор конфигов на серверах, 95,843684% времени для редактирования файлов на диске использую IDE от JetBrains.
А вот умеет ли он в интеграцию с Docker, дебагерами, системами деплоя и тестирования, например? Синхронизацию с удаленными серверами, базами данных, удобная работа с Git? Управление менеджером пакетов? Сомневаюсь.
Добавьте сюда еще 100500 фич современных IDE, о которых уже даже не задумываешься и Vim будет нервно курить в сторонке.
Для разработки большого проекта нужно использовать нормальную IDE. Для редактирования мелких файлов — любой блокното-образный редактор, в том числе Vim.
P.S. Не сравнивайте потребляемую программой память и память, требуемую для открытия файла. Любая IDE без открытых файлов жрет памяти довольно много, но вот открытие файлов в ней — не жрет память практически совсем, как и Vim.
Уж очень категоричный пост. На мой взгляд даже самые прошареные IDE довольно лимитированы во всем, кроме навигации и дебага. Я например категорически не могу пользоваться встроеными средствами, типа git. Мне на парядок удобнее пользоваться консольными программами, поскольку они быстрее и понятнее. А вот навигация по коду в режиме просмотра в Idea мне нравится больше чем в vim.
Про интеграцию с docker не совсем понял. Умеет ли билдить, запускать в докере? Таки да, запускать он может что угодно и где угодно. У вас некореектное представление об этой экосистеме. Для IDE на java верно следущее: есть плагин — есть функциональность. Для vim же вполне достаточно: есть консольная команда — есть функциональность. Плюс интеграция с python, что в пределе позволяет любые манипуляции с любыми объектами (если есть соответствующий модуль в pip), при чем даже repl можно сделать.
Про Docker — просто первое, что пришло в голову. Здесь посыл в том, что IDE из коробки поддерживают популярные инструменты. Хотя интеграция в JetBrains с Docker мне не нравится, честно говоря.
Весь этот спор про Vim vs IDE можно считать некорректным, т.к. Vim консольный, а современные IDE нет. Мне, как и 99% их пользователей, только лишь этой разницы хватит в пользу IDE.
В пользу Vim обычно приводят какие-то сумасшедшие кейсы типа «Я могу с помощью пары нажатий и регулярки заменить какую-то неведомую фигню на другую неведомую фигню». И вроде бы да, это круто. Вот только зачем? Нормального рефакторинга и простого Поиск/Замена хватает в 99.999% случаев.
В общем, статья ни о чем :)
Здесь посыл в том, что IDE из коробки поддерживают популярные инструменты.
Ну а я про то, что обычно вимерам интеграция и не нужна. Большинство vim'еров держат рядом открытый терминал и выполняют в нем все, что нужно, а в vim только правят. Т.е. это типичный разговор слепого с глухим.
Я так прикидываю, что дело здесь даже в консольности, а скорее всего в команности, если так можно сказать (поскольку например mcedit тоже консольный, но не командный). Т.е. когда что-то хочешь сделать в IDE, ты либо знаешь хот кей, либо лезешь в минюшки. А в vim — либо знаешь хот-кей, либо выполняешь команду, в командной строке (не знаешь команду, говоришь :help).
Ну и ещё один фактор популярности vim это эргономика: не зря же в каждой IDE есть vim плагин для редактора (рекомендую попробовать кстати).
А сумасшедшие кейсы не при делах. Их редко делают в самом vim. А тот что вы упомянули совсем уж обыденность, а не дичь.
Большинство vim'еров держат рядом открытый терминал и выполняют в нем все, что нужно, а в vim только правят.
Грубо, я так же работаю и в IDE. git, docker, файловые команды, иногда grep, tail — это всё в консоли, а в IDE — просмотр и правка кода, иногда отладка. Иногда в консоли открытой в IDE запускаю vim даже для правки конфигов :)
Мне, честно говоря, вообще не понятен посыл одно против другого. Зачем? Тем более для таких разных инструментов. По-моему куда лучше смотрится Vim + IDE.
Лично я не вижу ничего зазорного в том, что бы проект писать в IDE, а скажем какие-то файлы открывать в Vim и производить поиск или анализ. Если информации много. Скажем сотни тысяч строк, то выискивать что-то руками или простым поиском- гиблое дело. А если строки очень похожи, то вообще жесть. И при этом даже несложная регулярка поможет вам сэкономить кучу времени и нервов.
Весь этот спор про Vim vs IDE можно считать некорректным, т.к. Vim консольный, а современные IDE нет. Мне, как и 99% их пользователей, только лишь этой разницы хватит в пользу IDE.
Вот как раз TUI или GUI особого значения не имеет. Для меня главное преимущество IDE — полноценная поддержка такой сущности как "проект" и полноценный синтаксический анализатор.
Так же хочу заметить у vim несколько пакетных менеджеров: Vundle.vim, vim-plug, pathogen.
Концепция у вим здоровская: он отлично умеет то для чего создавался: редактирование текстов, и для новичков нужно иметь немного усидчивости и посидеть на голом виме, чтобы понять что он может из коробки, без плагинов.
Кстати редактирование кода через ftp, ssh тоже из коробки (читать netrw)
Эм. Vim умеет в рефакторинг, автокомплит (желательно не совсем глупый) и подсказки аргументов? Наверняка умеет за счет кучи плагинов.
А вот умеет ли он в интеграцию с Docker, дебагерами, системами деплоя и тестирования, например? Синхронизацию с удаленными серверами, базами данных, удобная работа с Git? Управление менеджером пакетов? Сомневаюсь.
Тут скорее наоборот, vim не понимает кода, что вы пишите, потому рефакторинг, автокомплит и подсказки для него гораздо сложнее, чем интеграция со сторонними тулзами. Вывод: первое обычно умеет плохо, а второе замечательно.
Я про pkg install vim в FreeBSD если что. Собирать из исходников — тоже не вариант на сервере по нескольким причинам (не знаю как в Линуксах, но в FreeBSD сборка из исходников обычно натягивает зависимости новее, чем в системе пакетов, отсюда вылазят всякие конфликты иногда, т.е. нужно либо все из портов собирать, либо все из пакетов, миксовать не рекомендуется).
Да не скажите. Вполне себе нормально живется без знаний vi/vim (: Для 99% случаев поправить мелкий скрипт и nano хватает.
— Все остальные описанные операции хорошо делает scp + notepad++ например, при сохранении файла в блокноте, сцп автоматически заливает файл на сервер. Notepad++ довольно неплохо справляется с текстовыми задачами, к нему тоже есть куча плагинов. Да он и без плагинов довольно мощный, поддерживает кучу синтаксисов, макросы и всякое.
— с правами согласен, либо рут открывать по ssh, либо менять права на конфиг, не очень удобно. Но если вы руками правите кучу конфигов на куче серверов, то вы что-то делаете не так. А если один конфиг в качестве исключения, то тогда можно и права ненадолго сменить.
Про все остальные операции — notepad++ не кроссплатформенный. И если вы им пользуетесь, то скорее всего, у вас интерфейс системы не очень подходящ под удобную работу по ssh. А так — он хороший, да. Почти как vim. Только с окошками и мышкой надо побольше тыкать.
Про кучу конфигов и что-то не так — ну это очень голословно. У меня на одной работе постоянная разработка у людей на ажуре. Вот часто бывает, что надо заспавнить новую виртуалку, но что-то подхачить под нужды для тестирования. Вот прямо каждый день такое бывает. Что ж мне, оркестрировать каждую виртуалку, которая и живет-то часто несколько часов всего?
Можно писать в IDE, а потом заливать по sftp. Скорость будет страдать, разумеется. И чем чаще вы будете сохранять, тем больше она будет страдать. Из таких маленьких страданий складывается большая боль.
Слово «автоматически» вам о чем-нибудь говорит? Я каждый день на работе почти целый день именно этим и занимаюсь, IDE настолько быстро сохраняет файл по sftp, что для меня это прозрачно. И даже намеренно попытавшись обогнать процесс сохранения, у меня ничего не получится.
редактирование прямо на удаленной машине ощутимо быстрее, чем копирование целого файла каждый раз на эту машину
Серьезно? Прям таки ощутимо? Мне кажется слепым методом никто и не заметит разницы, включая вас. Но раз уж для вас так ощутимо быстрее, почему бы вам не отказаться от SSH и не править файл через консольник, стоя в датацентре? Нафига все эти пакеты по сети гонять, через многочисленные коммутаторы и маршрутизаторы, ощутимо быстрей будет. НО! Если вдруг у вас диалап, беру все свои слова обратно.
но что-то подхачить под нужды для тестирования
Что-то подфачить — это править сотню конфигов по тысячи строк руками? Где текстовые операции такие сложные, что vi незаменим, и другие редакторы и консольные инструменты не справятся? И такое каждый день? Вы меня заинтриговали, можно пример конфига и текстовых операций, которые вы производите?
Я конечно тоже использую vi, но только там, где нет ничего другого и поправить требуется несколько строк.
Поправить переменную — любой редактор подойдет.
Поправить скрипт — я лучше его скачаю и буду править локально и залью обратно, мне как-то спокойней это делать в удобном окружении настроенной IDE.
Ну и по пунктам:
> Что делать, если надо написать небольшой модуль к Puppet, купить RubyMine?
Не знаю что это такое, простите.
> Как быстро поправить конфиг (выровнять строки, закомментить что-то)?
Я справлялся в nano. Самый сложный конфиг скачивал локально, ибо там было 2000 строк.
> Как быть, в конце концов, если редактируешь файл из nano, а sudo вызвать забыл?
Ну это просто нелепая ситуация.
> Абсолютно все вышеперечисленное можно делать без vi/vim, но когда вы делаете это в нем, вы не думаете обо всех этих сопутствующих проблемах, вы думаете только о том, как решить задачу.
Меня уже лет десять пытаются тыкать носом в консоль и приучить что любое действие в ней удобней. Нет, это не так. Это привычней тем кто учит. С vim точно такая-же история. Вы к нему привыкли, вам в нем удобней — а мне удобней и привычней в nano и я еще не встречался с задачами где-б он меня тормозил. Я не вижу для себя никаких преимуществ, которые я получу овладев данным инструментом.
Вот тут можно было закончить, если бы вы это сразу написали. Я вижу для себя преимущества, овладев любым инструментом.
Вы предлагаете учить инструмент на просто так?
Это уже не совсем актуально. Во многих мейнстримовых дистрах nano по дефолту в качестве EDITOR, хотя и vi там есть.
Консоль — только VIM.
GUI — notepadqq.
Какая целевая аудитория у Atom? По скорости запуска и работы он как большая IDE, а по возможностям как простой текстовый редактор (например, Sublime).
Под виндой notepad++, но только когда нужно открыть мелкий (<200МБ) текстовый файл.
С большими — не очень. Он начинает сильно тормозить на файлах в районе 300-600 метров. Я как-то попробовал открыть в нем sql дамп на что-то в районе гигабайта — он просто упал через минут 5-7 размышлений. К слову, sublime с этим файлом справился быстро и на ура.
Из-за его однопоточности всё может дойти до того, что при большом количестве событий на
печать/перемещения курсора могут возникать подвисания (freeze) редактора на небольшое,
но замечаемое глазом время (0.1-0.3 секунды).
Если честно, всё равно по ощущениям более отзывчивый, чем IntelliJ IDE на достаточно мощных машинах,
а на моём ноутбуке так её лучше не запускать, рискуют на пару с браузером вогнать кого-нибудь в swap.
Но по потреблению памяти, нет, не факт, что будет проигрывать.
Описанный выше «задумчивый» Emacs даже на достаточно большом количестве немаленьких буферов
потребляет примерно 60-80Mb.
tl;dr — да, вы правы, но экстраполировать на абстрактную IDE сложно. Зависит от её кривизны.
Что‐то мне подсказывает, что нет. Слишком простой ЯП: никакого JIT, GC на счётчике ссылок (простой mark&sweep для особых случаев). Даже AST нету, при создании функции просто сохраняется её исходный код. В результате ужасная производительность, но потреблять гигабайтами память здесь нечему: собственного аллокатора, резервирующего много места на будущее, нет, мусор не копится, код хранится в одном представлении, дополнения приходится оптимизировать, либо дёргать внешние программы (у некоторых языков, впрочем, можно запустить код на языке внутри процесса Vim).
Потому что не знаете, как из него выйти? :)
Значит, вы используете Вим, потому что у вас мало памяти?
При использовании Atom или Code у меня часто возникают зависания, бывает они длятся по нескольких минут
может автору просто ноутбук сменить?
у меня на (стационарной правда) машине с 4 гб оперативки открыто несколько очень тяжелых клиентов, файрфокс с несколькими десятками вкладок, несколько жирных екселей, несколько редакторов (саблайм, для еще более быстрого доступа — встроенный в фар редактор)
и ничего не тупит.
никогда даже не задумывался сколько времени загружается редактор или сколько памяти ест. Меня не объест.
как-то больше думаю про то как быстро будет работать код, который пишу в редакторе, а не про сам редактор
в gui — sublime
Поиск и замена в 8мб файле быстрее всего будет выполнена командой sed, например.
Поиск и замена в 8мб файле быстрее всего будет выполнена командой sed, например.
Быстрее — возможно, а вот удобнее ли…
https://stackoverflow.com/questions/12696125/sed-edit-file-in-place
https://stackoverflow.com/questions/7733922/sed-command-creates-randomly-named-files
Т.к. сед создаёт временный файл, куда копирует результат.
Для этого есть такие вещи как тестовый сервер, различные способы автоматической валидации и/или тестирования. Всё равно, если замен много, то всё вы сами не просмотрите, или пропустите что‐то из‐за монотонности работы. А посмотреть первые несколько замен можно и с sed, но без редактора: к примеру, sed -i.bak, затем diff ….
Если-же мне нужно, ну вдруг я в пьяном бреду, заменить подстроку в файле весом в 100 мегабайт на живчике — я возьму sed, ибо во первых я точно знаю что мне надо поменять и на что, во вторых я из тех кто «уже делает бэкап».
— не нужно переключать контекст, т.е. если я уже в редакторе и работаю с определенным файлом — лучше не «рвать поток» и продолжать работать в том же редакторе
— в редакторе будет проще делать замену только определенных частей
— в редакторе перед заменой визуально хорошо видно что будет заменено (можно глазами пробежаться по файлу/минимэпу) и не накосячить (если например допустил ошибку в регулярке, и т.п.)
Хотелось бы услышать аргументы в «противоположном направлении»
Забыли самое главное: в редакторе есть undo, и после поиска/замены в редакторе редактор своё undo не потеряет. В случае с sed — может: например Vim, в зависимости от настроек и размера файла, либо потеряет undo, либо запишет в дерево «а здесь мы потёрли весь файл, а затем вставили вот такое содержимое: {весь файл целиком}» (т.е. в undo окажется неоправданно большой кусок текста, в двух экземплярах, даже если вы sed’ом поправили одну строчку). И это только если файл был открыт в Vim, пока вы ковыряли его sed’ом, если не был — Vim’у неоткуда знать, что там было в файле, соответственно, вычислить разницу и сохранить её в undo дереве он не может.
Частично проблему снимает контроль версий, но я ещё как‐то не видел команд, где приветствуют незавершённые микрокоммиты — следовательно, их придётся чистить. Undo дерево редактора чистить не придётся.
Только в Vim есть что‐то вроде урезанного kio — а именно, возможность определять, как должен считываться/записываться файл. И, соответственно, несколько «стандартных» (в поставке по‐умолчанию) дополнений для работы с архивами, использующих эту возможность. А файловый менеджер (возможно за исключением KDE с KDE’шными редакторами, поддерживающими kio — точно не знаю, но это было бы логичным) распакует файл куда‐то во временный каталог, скорее всего, со случайным именем как минимум каталога, натравит на него редактор, по завершению перепакует. Минусы очевидны: из‐за случайного имени не будет работать сохранение undo файлов, позволяющее не терять undo при перезапуске редактора (правда, оно сейчас также почему‐то не работает, но в справке я причины не вижу, значит должно быть ошибкой), не будет swap файлов (а эти работают), работа с другим zip‐архивом всегда будет происходить либо в новом экземпляре редактора, либо в первом/последнем открытом экземпляре (может быть важно, если у вас по экземпляру Vim на проект и вы их не закрываете, переключаясь на другой проект).
И последнее, из консоли вы редактор с zip‐файлом просто так не откроете: либо вам придётся перепаковывать самостоятельно (можете написать скрипт, но готовых я не знаю), либо нужно поставить специальную ФС на основе FUSE (название не помню, но систему, которая позволяет заходить в архивы как в каталоги когда‐то давно трогал, потом удалил за ненадобностью). (Ну или нужен редактор с поддержкой kio или чего‐то аналогичного.)
Ура!
VSCode — ничего, вроде пошустрее Атома, работа с гитом понравилась, но опять же, после скорости Саблайма — все не то…
Вим так и не осилил, времени не было его плотно изучить и привыкнуть, переодически использую для гита и конфиги иногда в нем правлю, но дальше не пошло. Hе нашел в нем того, что нельзя сделать мультикурсором или другими плюшками Саблайма…
Почему я до сих пор использую Vim?