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

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

У меня у одного диссонанс: графики выглядят как реклама Sublime, а в заголовке Vim?

sublime по мощи уступает vim-у все же.

в 3 из 4 графиков Vim лучше чем Sublime. Вряд ли это может быть хорошим результатом для Sublime
Заметно, а не на уровне стат. погрешности, Sublime уступает только на первых двух графиках. Но и они не совсем понятны, т.к. по ним получается, что он при открытии 60-байтного кода сожрал в 1,5 раза больше памяти, чем при открытии 6-мегабайтного XML-файла. Похоже, что эксперимент не блещет чистотой.

PS Не пользую Sublime и Vim. Использую иногда vi и то только по необходимости, когда иного не наблюдается.
У графиков разная цена деления: на 60 байт Sublime потребовалось 50Мб, на 6 мегабайт — 75Мб.
Да. Вы совершенно правы и это отбрасывает предположения о некорректности эксперимента конкретно по данному пункту. Однако «читабельности» графикам, к сожалению, не добавляет.
«Как вы думаете, сколько памяти нужно редактору, чтобы открыть следующий C файл?» — who cares?
Редакторам под DOS вообще хватало 640кбайт на всё!
nano, по графикам-то он рулит (почти везде).

И, да, по памяти ожидал другой результат увидеть, что vim кушает меньше всего, ан нет!
Честность, она такая :)

Ну, если быть честным и при это считать, что графики рекламируют sublime, то в заголовоке статьи нужно написать "Sublime перемещает курсор в конец шестимегабайтного файла быстрее, чем Vim!!!!!"

Память нынче очень дешевый ресурс, а вот время — дорогой (автокомплиты, рефакторинги и прочие плюшки). Нормальная IDE может окупить отожранную память за несколько дней.
Вряд ли это можно как то противопоставить виму, время обучения и привыкания к нему — да, а вот про недостаток функционала всё чушь — vim'у вряд ли есть равные.
а как же emacs? функциональности и расширяемости там тьма :)

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

PS: ввязываться в спор emacs vs vim категорически отказываюсь. Единственное, что наверняка можно сказать про emasc это то, что это отличная операционная система. Жаль только в нем нет нормального текстового редактора ;)
Менять сигнатуру метода умеет?

нынче есть очень интересный тред — встраивать средства рефакторинга в тулинг идущий с компилятором/интерпритатором (как это например сделали ребята из TypeScript). В этом есть немало смысла, "не надо ждать пока все IDE добавят новые плюшки", это на руку разработчикам языков. А если все используют одинаковый тулинг для рефакторинга — то спорить кто лучше в этом явно смысла нет.

Плюсую, особенно если у языка маленькое комьюнити — эти тулзы очень сильно помогают
Идут года, проходят десятилетия, а аргументы всё те же.
В emacs есть evil-mode, режим, в котором он мимикрирует под vim. Так что есть там нормальный текстовый редактор (-:
«Какой бы бред вам не пришел в голову Vim это уже умеет» — ребята из JetBrains ехидно в сторонке улыбаются :)
к большому сожалению при включении VimMode в CLion нет ремапинга остальных шоткатов — они просто перестают работать. Да и в отличии от vim и emacs продукты JetBrain не работают по ssh (кроме как примонтировать раздел по sftp).
Кстати интересный проект для emacs — spacemacs.
JetBrains не текстовый редактор. Зачем вы его привели, не понятно
Какой бы бред вам не пришел в голову Vim это уже умеет.

Да? Хочу, чтобы, когда я жму клавишу "f" в тексте печаталась клавиша f, а когда я зажимаю клавишу "f" и, не отпуская её, зажимаю клавишу "j", редактор делал то, что делается по сочетанию клавиш Ctrl+j .


Или вот, хочу повесить какое-нибудь действие на Ctrl+Shif+j. Как это сделать?

Emacs работает круто и быстро! Перешел с vim и не жалею

Расскажите про автоматический рефакторинг в Vim (и сколько он с таким обвесом плагинами ест памяти).

Там все это решается плагинами.
Вроде бы в статье и не говорится, что vim надо использовать, как IDE.
У меня есть и Vim и Sublime, и IDE разные, все они выполняют разные задачи.
Тут про редактор кода речь, если я правильно понял.

Я тоже использую все это, и тоже для разных задач — конфиги на серверах в виме, локальные логи смотрю в саблайме, код в IDE.
У vi/vim есть одна маленькая особенность: с самого начала это крайне недружелюбный интерфейс, недаром же один из самых популярных вопросов на stackoverflow это как выйти из vim. В nano с этим все проще: открываешь редактор и сразу есть подсказки по хоткеям, из коробки.
Лично я использую sublime или nano, по ситуации.
В сравнении остро не хватает mcedit. :)
Интересно было бы узнать какие версии редакторов использовались, а то вон atom с каждой новой версией содержит какие-то улучшения по производительности.
Статья вообще ни о чём. Из перечисленных трёх метрик (memory footprint, время запуска, скорость) первые 2 никому не важны. Скорость важна, но она далеко не единственное преимущество vim. Про основные фичи (удобство навигации, command/insert mode, text objects, расширяемость плагинами) скромно промолчали.

PS: моя основная IDE — Emacs в режиме эмуляции клавиатурных комбинаций Vim (evil-mode) и это реально уберкомбо, соединяющее преимущества обеих сред.
>>Из перечисленных трёх метрик (memory footprint, время запуска, скорость) первые 2 никому

Кому как. У меня вот 2GB памяти. Можно поставить 4, но нужно перепаивать чипы, что я делать разумеется не буду.
Редактор должен запускаться за 0 секунд. Не существует никаких причин чтобы было иначе.
nano нельзя рассматривать как среду разработки. Это ж notepad.
Так что если вы хотите на ЛЮБОЙ машине с ЛЮБОЙ ОС иметь привычный интерфейс среды разработки, альтернативы VIM-у нет.

ЗЫ: и не надо про emacs — не про него тема.
Пользуюсь продуктами JetBrains — в любой ОС получаю привычный интерфейс.
Раз пошла такая пьянка, почему бы не добавить сюда Notepad++?
Можно ещё сравнить с полновесными IDE (Visual Studio, Eclipse)… Но это уже будет перебор… Или нет?
Про ed ещё забыли!

Единственное, что навскидку не придумывается (именно не придумывается, не факт, что данную функциональность проблематично реализовать) — это вся и всяческая визуализация, типа тех же ER-диаграмм и прочих связей в БД. А так из vim-a вполне себе лёгкую IDE замастырить, я думаю, не проблема.

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

По мотивам недавних трех холиваров: угадайте на чем написаны Atom и Code?
+gitkraken +ещё хренова куча всего.
И с прилагающимся браузером, который всё это и исполняет…
НЛО прилетело и опубликовало эту надпись здесь
vim никуда не уходит и не уйдет. Сегодня это самый адекватный редактор для терминалов (ssh сервера) со слабым connection (ping > 100 ms). Так что пусть vim развивается, а люди его изучают.
НЛО прилетело и опубликовало эту надпись здесь
Я все понимаю, но меня слегка смущают цифры. Я только что запустил AndroidStudio и ей потребовались 600М. Странно? Вот и я так думаю.

Vim — один из самых дебильных редакторов. Более недружелюбного и уродского еще нужно поискать. Но его сила ни в удобстве. И даже ни в его фичах. Его основная сила в том, что на любой Unix и Unix-like системе он будет. И какой бы жидкий канал не был он будет отлично работать.
Его основная сила в том, что на любой Unix и Unix-like системе он будет.

Из коробки — далеко не факт, nano субъективно чаще, а права на установку далеко не всегда есть. И не уверен, что vim можно поставить на самый популярный десктопный Unix её стандартным установщиком.

Сможете вспомнить где «из коробки» не было vi(m)?

Ubuntu

У меня почему-то присутствует. И присутствовал всегда. Именно при стандартной установке.
Собственно поэтому я и удивился.

Хм… Странно. Регулярно его устанавливаю и основная ОС в компании Ubuntu.

Именно vim может отсутствовать, но вот vi будет везде и всегда, в любой Unix-like ОС.
Я обратил внимание, что стоит именно Vim. А vi к нему прилинкован.

Только что установил свежую 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
~$ 
Дайте прямую ссылку если нетрудно на iso.
Чтобы не было разнотолков. Бо самолично проверял и все было.
Установил по вашей ссылке.
$which vi
/usr/bin/vi

Я не знаю что еще сказать.

which vim ?

Если вам не трудно, запустите вы этот vi.
И прочтите что у него на приветственном экране написано.
ЗЫ Ну и ветка идет от коммента «Сможете вспомнить где «из коробки» не было 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 там всё равно есть.

В серверных версиях нет точно, всегда ставлю допом.
Парни. Вот только что скачал ubuntu server 14.04. Поставил в виртуалке, выбрав опцию ssh-server.
Vim в наличии.
CentOS (Core)
http://mirror.yandex.ru/centos/7/isos/x86_64/CentOS-7-x86_64-Minimal-1611.iso
Vi присутствует.
В минимальном дебиане его нет (по крайней мере в девятом).
Первый раз /etc/apt/sources.d/ придется редактировать nano
Что есть минимальный debian?
У меня смутное чувство что нетинстал все же не очень обычное «И не уверен, что vim можно поставить на самый популярный десктопный Unix её стандартным установщиком»
Ты же пишешь «из коробки». Вот в коробке нетинстала дебиана его нет. Учитывая, что в большинстве серверных конфигураций адреса зеркал приходится править, то первый раз их придется править нано.
Я же не утверждаю, что на дебиан нельзя поставить vim стандартными средствами. Глупо было бы утверждать такое.
Установил debian-netinst. https://www.debian.org/CD/netinst/
Vi присутствует.

"самый популярный десктопный Unix" — Макось. Linux не является Unix.

Вот тут я пас. Никакой возможности проверить наличие vi(m) в этой ОС у меня нет.
Будем считать что нашли UNIX без vi(m).
Никакой возможности проверить наличие

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


Будем считать что нашли UNIX без vi(m).

на основании чего? в mac os vim есть.

Из коробки или надо из исходников собирать? :)

сча проверю на новом маке… version 7.4.8056 — из коробки.

Еще есть, например, в homebrew — 8.0.0893 в данный момент.

это уже не из коробки, да и сам homebrew надо ставить.

Ну не из исходников же собирать, как написано выше :)

Судя по контексту homebrew — пакетный менеджер под MacOS не от Apple, про который надо откуда узнать и как-то установить. По смыслу гораздо ближе к "из исходников собирать", чем к "из коробки".

На мой взгляд, по смыслу таки ближе к чему-то вроде aptitude install vim.
Сама установка homebrew в систему — буквально одна строчка копипаста.

Вот когда из коробки будет homebrew, тогда будет ближе, а то, что загружается из https://raw.githubusercontent.com/Homebrew/install/master/install вполне может и исходники скачивать, и компилять их, мало чем отличается от строки копипасты типа curl… | tar… && make && make install

Из коробки третьесторонний пакетный менеджер врядли будет, по известным причинам.
Но в любом случае, куча софта (вроде тех же vim/openssl/bash/curl/etc) таки идет из коробки.

А вот по поводу отличий от «make && make install» — позвольте не согласиться :) Сабж — это вполне себе приличный пакетный менеджер со всеми фишечками пакетных менеджеров.
НЛО прилетело и опубликовало эту надпись здесь
Ну в генту же можно (если мне память не изменяет, ибо зело давно я его ковырял) и бинарные пакеты ставить, не? И с другой стороны — в deb-based при желании тоже можно из исходников средствами пакетного менеджера пакеты ставить. Об чем вопрос то? :)
Сама установка homebrew в систему — буквально одна строчка копипаста.

не забудьте поставить xcode build tools.

Прикольно — плюсик к эпплу. Лет через 3-5 может перевесит при выборе очередного ноута :)

я сдался 3 года назад и окончательно перешел в армию людей переплачивающих непонятно за что… в целом именно нежелание выбирать и стало основным доводом (ну и еще желание собирать мелочи под xcode).

Да, за последние дни пару раз был на грани от того, чтобы просто поехать в магазин и взять прошку. Именно из-за проблемы выбора, ну и специфики киевского рынка ноутов — пощупать с десяток моделей ценой 1500+ просто так никто не даст, а макбуки можно.


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

но с прошкой были бы риски плохой работы софта с ретиной.

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

Ну не знаю можно ли назвать специфичными Windows и Linux :) А у них с высокими дпи проблемы не решены толком. То есть вроде оси поддерживают, но даже у популярного и современного софта проблемы с сотношением физических и логических единиц измерения.

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

он (точнее, vi) есть в busybox.

Если вы имеете ввиду MacOS, то Vim туда нормально заходит. Я себе поставил без проблем.

91,56384% времени работы в vim использую его как редактор конфигов на серверах, 95,843684% времени для редактирования файлов на диске использую IDE от JetBrains.

Эм. Vim умеет в рефакторинг, автокомплит (желательно не совсем глупый) и подсказки аргументов? Наверняка умеет за счет кучи плагинов.

А вот умеет ли он в интеграцию с 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? Вам ответили — умеет.

Мне, честно говоря, вообще не понятен посыл одно против другого. Зачем? Тем более для таких разных инструментов. По-моему куда лучше смотрится Vim + IDE.

Лично я не вижу ничего зазорного в том, что бы проект писать в IDE, а скажем какие-то файлы открывать в Vim и производить поиск или анализ. Если информации много. Скажем сотни тысяч строк, то выискивать что-то руками или простым поиском- гиблое дело. А если строки очень похожи, то вообще жесть. И при этом даже несложная регулярка поможет вам сэкономить кучу времени и нервов.
Весь этот спор про Vim vs IDE можно считать некорректным, т.к. Vim консольный, а современные IDE нет. Мне, как и 99% их пользователей, только лишь этой разницы хватит в пользу IDE.

Вот как раз TUI или GUI особого значения не имеет. Для меня главное преимущество IDE — полноценная поддержка такой сущности как "проект" и полноценный синтаксический анализатор.

Попользовался плагином Fugitive (поддержка git в vim), теперь почти не использую git с консоли.
Так же хочу заметить у vim несколько пакетных менеджеров: Vundle.vim, vim-plug, pathogen.
Концепция у вим здоровская: он отлично умеет то для чего создавался: редактирование текстов, и для новичков нужно иметь немного усидчивости и посидеть на голом виме, чтобы понять что он может из коробки, без плагинов.
Кстати редактирование кода через ftp, ssh тоже из коробки (читать netrw)
Эм. Vim умеет в рефакторинг, автокомплит (желательно не совсем глупый) и подсказки аргументов? Наверняка умеет за счет кучи плагинов.

А вот умеет ли он в интеграцию с Docker, дебагерами, системами деплоя и тестирования, например? Синхронизацию с удаленными серверами, базами данных, удобная работа с Git? Управление менеджером пакетов? Сомневаюсь.

Тут скорее наоборот, vim не понимает кода, что вы пишите, потому рефакторинг, автокомплит и подсказки для него гораздо сложнее, чем интеграция со сторонними тулзами. Вывод: первое обычно умеет плохо, а второе замечательно.
При установке vim-a на headless сервере он тянет под 200 мб зависимостей, это единственное, что в нем раздражает.
НЛО прилетело и опубликовало эту надпись здесь
ебилд — это система сборки в каком-то дистрибутиве линукса или что?
Я про pkg install vim в FreeBSD если что. Собирать из исходников — тоже не вариант на сервере по нескольким причинам (не знаю как в Линуксах, но в FreeBSD сборка из исходников обычно натягивает зависимости новее, чем в системе пакетов, отсюда вылазят всякие конфликты иногда, т.е. нужно либо все из портов собирать, либо все из пакетов, миксовать не рекомендуется).
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
У некоторых комментаторов наблюдается «гороховый эффект» лишь при одном упоминании vi/viM :) На мой взгляд, vi/viM — стандарт «де-факто» для использования в UNIX-like OS и без хотя бы базовых знаний команд vi/viM в Linux, не говоря уже о UNIX и коммерческих UNIX, комфортно и эффективно работать работать вряд ли получится. Однако вышесказанное не умоляет достоинств других текстовых редакторов — речь идёт исключительно о сложившейся традиции или «выборе сообщества», «выборе аудитории пользователей» — как это не назови.
> На мой взгляд, vi/viM — стандарт «де-факто» для использования в UNIX-like OS и без хотя бы базовых знаний команд vi/viM в Linux, не говоря уже о UNIX и коммерческих UNIX, комфортно и эффективно работать работать вряд ли получится.

Да не скажите. Вполне себе нормально живется без знаний vi/vim (: Для 99% случаев поправить мелкий скрипт и nano хватает.
Скорее всего у вас достаточно узкая специализация. Первые 10 лет работы в unix-like операционных системах я тоже думал, что мне нормально живется без знаний vi/vim.
Думаю, на этом ресурсе приветствуются аргументы, а не пафос.
На этом ресурсе большинство уведет карму в глубочайший минус просто за то, что им кажется, что выдвинутое мнение не совпадает с их собственным — поэтому нет никакой разницы, что именно здесь приветствуется.
Я средней руки программист-сисадмин-эникейщик, у меня 32 сервера под юниксом (от фряхи до qnx) и я не представляю зачем мне нужен vi/vim. Если мне надо поправить мелкий скрипт я сделаю это при помощи nano. Если мне надо поправить большой или написать новый — я не буду это делать на живчике, а скачаю на свой компьютер и запущу нормальную IDE. Хотя такой необходимости у меня просто нет, ибо на компьютере где я работаю есть точные копии того что лежат на сервере и я могу поменять у себя и залить все одной кнопкой.
Ну вот есть задача потестить новый фреймворк. Можно для этого запускать IDE, конечно. Но как быть в случае с пайтоном, например, если машина для разработки удаленная? Как подебажить опенстек на удаленном сервере? Можно, конечно, ковырять скрипты в тысячи строк с nano, но это просто не так удобно, как с vim, да и не везде есть nano (как и права на его установку), а vi 100% есть везде. Что делать, если надо написать небольшой модуль к Puppet, купить RubyMine? Как быстро поправить конфиг (выровнять строки, закомментить что-то)? Как быть, в конце концов, если редактируешь файл из nano, а sudo вызвать забыл? Абсолютно все вышеперечисленное можно делать без vi/vim, но когда вы делаете это в нем, вы не думаете обо всех этих сопутствующих проблемах, вы думаете только о том, как решить задачу. Может, такое сравнение понравится не всем, но это как печатать 10 пальцами — вы не думаете о кнопках, вы думаете только о том что вы хотите напечатать. Это позволяет концентрироваться и выполнять поставленную задачу лучше.
— я каждый день как раз пишу на питоне на удаленном сервере, IDE автоматически заливает файлы по sftp по нажатию ctrl + s
— Все остальные описанные операции хорошо делает scp + notepad++ например, при сохранении файла в блокноте, сцп автоматически заливает файл на сервер. Notepad++ довольно неплохо справляется с текстовыми задачами, к нему тоже есть куча плагинов. Да он и без плагинов довольно мощный, поддерживает кучу синтаксисов, макросы и всякое.
— с правами согласен, либо рут открывать по ssh, либо менять права на конфиг, не очень удобно. Но если вы руками правите кучу конфигов на куче серверов, то вы что-то делаете не так. А если один конфиг в качестве исключения, то тогда можно и права ненадолго сменить.
Можно писать в IDE, а потом заливать по sftp. Скорость будет страдать, разумеется. И чем чаще вы будете сохранять, тем больше она будет страдать. Из таких маленьких страданий складывается большая боль. Но это кому что нравится — я часто вижу у людей желание делать вещи каким-то конкретным способом и не хочу им продавать свой подход. Но как мне кажется, спорить, что редактирование прямо на удаленной машине ощутимо быстрее, чем копирование целого файла каждый раз на эту машину, бессмысленно. Я в IDE занимаюсь только разработкой, например и почти никогда — тестированием новых вещей.

Про все остальные операции — notepad++ не кроссплатформенный. И если вы им пользуетесь, то скорее всего, у вас интерфейс системы не очень подходящ под удобную работу по ssh. А так — он хороший, да. Почти как vim. Только с окошками и мышкой надо побольше тыкать.

Про кучу конфигов и что-то не так — ну это очень голословно. У меня на одной работе постоянная разработка у людей на ажуре. Вот часто бывает, что надо заспавнить новую виртуалку, но что-то подхачить под нужды для тестирования. Вот прямо каждый день такое бывает. Что ж мне, оркестрировать каждую виртуалку, которая и живет-то часто несколько часов всего?
Можно писать в IDE, а потом заливать по sftp. Скорость будет страдать, разумеется. И чем чаще вы будете сохранять, тем больше она будет страдать. Из таких маленьких страданий складывается большая боль.

Слово «автоматически» вам о чем-нибудь говорит? Я каждый день на работе почти целый день именно этим и занимаюсь, IDE настолько быстро сохраняет файл по sftp, что для меня это прозрачно. И даже намеренно попытавшись обогнать процесс сохранения, у меня ничего не получится.

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

Серьезно? Прям таки ощутимо? Мне кажется слепым методом никто и не заметит разницы, включая вас. Но раз уж для вас так ощутимо быстрее, почему бы вам не отказаться от SSH и не править файл через консольник, стоя в датацентре? Нафига все эти пакеты по сети гонять, через многочисленные коммутаторы и маршрутизаторы, ощутимо быстрей будет. НО! Если вдруг у вас диалап, беру все свои слова обратно.

но что-то подхачить под нужды для тестирования

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

Я конечно тоже использую vi, но только там, где нет ничего другого и поправить требуется несколько строк.
Если вы зашли на удаленку для того чтоб там «ковырять скрипты в тысячи строк с nano» — вы делаете что-то не так.
Поправить переменную — любой редактор подойдет.
Поправить скрипт — я лучше его скачаю и буду править локально и залью обратно, мне как-то спокойней это делать в удобном окружении настроенной IDE.

Ну и по пунктам:
> Что делать, если надо написать небольшой модуль к Puppet, купить RubyMine?

Не знаю что это такое, простите.

> Как быстро поправить конфиг (выровнять строки, закомментить что-то)?

Я справлялся в nano. Самый сложный конфиг скачивал локально, ибо там было 2000 строк.

> Как быть, в конце концов, если редактируешь файл из nano, а sudo вызвать забыл?

Ну это просто нелепая ситуация.

> Абсолютно все вышеперечисленное можно делать без vi/vim, но когда вы делаете это в нем, вы не думаете обо всех этих сопутствующих проблемах, вы думаете только о том, как решить задачу.

Меня уже лет десять пытаются тыкать носом в консоль и приучить что любое действие в ней удобней. Нет, это не так. Это привычней тем кто учит. С vim точно такая-же история. Вы к нему привыкли, вам в нем удобней — а мне удобней и привычней в nano и я еще не встречался с задачами где-б он меня тормозил. Я не вижу для себя никаких преимуществ, которые я получу овладев данным инструментом.
>Я не вижу для себя никаких преимуществ, которые я получу овладев данным инструментом.
Вот тут можно было закончить, если бы вы это сразу написали. Я вижу для себя преимущества, овладев любым инструментом.
Вы лукавите. Человек всегда ограничивает свой кругозор в выборе. Я сделал ставку на IDE от Jetbrains, этот инструмент покрывает 400% моих требований. До этого я делал ставку на Qt. Зачем мне может понадобиться vim? Чтоб в беседе упомянуть «А я знаю vim»? Я им пользоваться не буду, у меня есть полноценная IDE, с подсветкой, отладкой, системой контроля версий и удобным для меня внешним видом, удобными хоткеями наконец, загрузкой на сервер одной кнопкой, подсказками.

Вы предлагаете учить инструмент на просто так?
«Я пользуюсь тупым инструментом, потому что не могу запомнить три функции. Я не хочу, чтобы надо мной кто-то имел преимущество, поэтому пусть у всех вырастут руки из ..., чего им быть лучше меня» — типичный пользователь, привыкший к мышкиным интерфейсам. То, что что-то получается лучше, не говорит об общей продуктивности — только о том, что на одном из этапов экономится 0.004 секунды.

Это уже не совсем актуально. Во многих мейнстримовых дистрах nano по дефолту в качестве EDITOR, хотя и vi там есть.

Консоль — только VIM.
GUI — notepadqq.

Не знал про такой, спасибо!

Какая целевая аудитория у Atom? По скорости запуска и работы он как большая IDE, а по возможностям как простой текстовый редактор (например, Sublime).

А куда делся notepad++?
Во, и TextWrangler?
sed, vi
Под виндой notepad++, но только когда нужно открыть мелкий (<200МБ) текстовый файл.
НЛО прилетело и опубликовало эту надпись здесь
> Еще им удобно работать с большими файлами

С большими — не очень. Он начинает сильно тормозить на файлах в районе 300-600 метров. Я как-то попробовал открыть в нем sql дамп на что-то в районе гигабайта — он просто упал через минут 5-7 размышлений. К слову, sublime с этим файлом справился быстро и на ура.

Большие файлы как раз проблема: Vim грузит в память весь файл разом. Ещё больше проблема файлы с длинными строками: здесь одна строка — один C’шный unsigned char * и с длинной строкой реально не готовы работать ни подсветка синтаксиса, ни код для её редактирования.

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

Из-за его однопоточности всё может дойти до того, что при большом количестве событий на
печать/перемещения курсора могут возникать подвисания (freeze) редактора на небольшое,
но замечаемое глазом время (0.1-0.3 секунды).
Если честно, всё равно по ощущениям более отзывчивый, чем IntelliJ IDE на достаточно мощных машинах,
а на моём ноутбуке так её лучше не запускать, рискуют на пару с браузером вогнать кого-нибудь в swap.

Но по потреблению памяти, нет, не факт, что будет проигрывать.
Описанный выше «задумчивый» Emacs даже на достаточно большом количестве немаленьких буферов
потребляет примерно 60-80Mb.

tl;dr — да, вы правы, но экстраполировать на абстрактную IDE сложно. Зависит от её кривизны.

Что‐то мне подсказывает, что нет. Слишком простой ЯП: никакого JIT, GC на счётчике ссылок (простой mark&sweep для особых случаев). Даже AST нету, при создании функции просто сохраняется её исходный код. В результате ужасная производительность, но потреблять гигабайтами память здесь нечему: собственного аллокатора, резервирующего много места на будущее, нет, мусор не копится, код хранится в одном представлении, дополнения приходится оптимизировать, либо дёргать внешние программы (у некоторых языков, впрочем, можно запустить код на языке внутри процесса Vim).

>> Почему я до сих пор использую Vim?

Потому что не знаете, как из него выйти? :)

Значит, вы используете Вим, потому что у вас мало памяти?

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

может автору просто ноутбук сменить?
у меня на (стационарной правда) машине с 4 гб оперативки открыто несколько очень тяжелых клиентов, файрфокс с несколькими десятками вкладок, несколько жирных екселей, несколько редакторов (саблайм, для еще более быстрого доступа — встроенный в фар редактор)
и ничего не тупит.
никогда даже не задумывался сколько времени загружается редактор или сколько памяти ест. Меня не объест.
как-то больше думаю про то как быстро будет работать код, который пишу в редакторе, а не про сам редактор
Я пытался использовать Vim. Но столкнулся с большим количеством гемора с его настройкой и т.д.. В итоге пользуюсь IDE от jetbrains с Vim плагином. Лично для меня это самый лучший вариант.
НЛО прилетело и опубликовало эту надпись здесь
в консоле — micro
в gui — sublime
Никогда такого не было и вот опять. Подсчет мегабайтиков и милисекундочек при каких-то нелепых начальных условиях.
Поиск и замена в 8мб файле быстрее всего будет выполнена командой sed, например.
Поиск и замена в 8мб файле быстрее всего будет выполнена командой sed, например.

Быстрее — возможно, а вот удобнее ли…
При всей моей нелюбви к консоли — замена sed'ом достаточно удобна и быстра. Намного лучше чем замена нормальным редактором.
И, как оказалось, может приводить к подобным вещам:
https://stackoverflow.com/questions/12696125/sed-edit-file-in-place
https://stackoverflow.com/questions/7733922/sed-command-creates-randomly-named-files

Т.к. сед создаёт временный файл, куда копирует результат.
НЛО прилетело и опубликовало эту надпись здесь
Для этого у вас должен быть открыт файл в редакторе. Sed юзается в случае замены без открытия, например когда у вас есть большой дамп SQL и вам надо не глядя заменить что-либо. Например дамп моей БД сейчас это 22 таблицы, в одной из которых 440к строк. Открывать его редактором я побоюсь.
НЛО прилетело и опубликовало эту надпись здесь

Для этого есть такие вещи как тестовый сервер, различные способы автоматической валидации и/или тестирования. Всё равно, если замен много, то всё вы сами не просмотрите, или пропустите что‐то из‐за монотонности работы. А посмотреть первые несколько замен можно и с sed, но без редактора: к примеру, sed -i.bak, затем diff ….

Мы с вами по разному смотрим на проблему. Я никогда на живом сервере не буду редактировать скрипты, дампы или т.п. Даже когда я работал в МВД у меня была возможность копировать файлы (не данные) на компьютер и редактировать их в удобном мне IDE. Правка-же конфигов отлично идет _у меня_ в редакторе nano, где я вижу и заменяю.

Если-же мне нужно, ну вдруг я в пьяном бреду, заменить подстроку в файле весом в 100 мегабайт на живчике — я возьму sed, ибо во первых я точно знаю что мне надо поменять и на что, во вторых я из тех кто «уже делает бэкап».
Раз «минусят», давайте попробую добавить аргументов. Почему считаю что пользоваться седом менее удобно чем встроенным в редактор функцией поиска/замены:
— не нужно переключать контекст, т.е. если я уже в редакторе и работаю с определенным файлом — лучше не «рвать поток» и продолжать работать в том же редакторе
— в редакторе будет проще делать замену только определенных частей
— в редакторе перед заменой визуально хорошо видно что будет заменено (можно глазами пробежаться по файлу/минимэпу) и не накосячить (если например допустил ошибку в регулярке, и т.п.)

Хотелось бы услышать аргументы в «противоположном направлении»

Забыли самое главное: в редакторе есть undo, и после поиска/замены в редакторе редактор своё undo не потеряет. В случае с sed — может: например Vim, в зависимости от настроек и размера файла, либо потеряет undo, либо запишет в дерево «а здесь мы потёрли весь файл, а затем вставили вот такое содержимое: {весь файл целиком}» (т.е. в undo окажется неоправданно большой кусок текста, в двух экземплярах, даже если вы sed’ом поправили одну строчку). И это только если файл был открыт в Vim, пока вы ковыряли его sed’ом, если не был — Vim’у неоткуда знать, что там было в файле, соответственно, вычислить разницу и сохранить её в undo дереве он не может.


Частично проблему снимает контроль версий, но я ещё как‐то не видел команд, где приветствуют незавершённые микрокоммиты — следовательно, их придётся чистить. Undo дерево редактора чистить не придётся.

НЛО прилетело и опубликовало эту надпись здесь
Знаете почему я до сих пор разогреваю суп в металлической тарелке на газу? Потому что тарелка занимает на кухне значительно меньше места, чем микроволновка. Кроме того, использование тарелки намного дешевле, ибо стоимость газа ниже стоимости электричества. Видимо потому, что я живу в дупле на дереве, где беда с электричеством и свободным местом.
какой же газ в дупле, только примус, только хардкор.
как говорится — любого можно вывезти из дупла, но дупло — не из каждого.
Чем же надо загрузить Visual Studio Code чтобы он подвис на минуту?
Открыть большой файл. Может и не отвиснуть или вообще вырубится. Atom так же. Пришлось отказаться от них и вернуться на Sublime. Впрочем, профита в их использовании по сравнению с Sublime, так и не нашёл. Одни только тормоза и повышенный жор ресурсов системы.
НЛО прилетело и опубликовало эту надпись здесь
псс, jar это зип, apk это зип. перепаковывать зипы на лету умеет любой вменяемый файловый менеджер

Только в Vim есть что‐то вроде урезанного kio — а именно, возможность определять, как должен считываться/записываться файл. И, соответственно, несколько «стандартных» (в поставке по‐умолчанию) дополнений для работы с архивами, использующих эту возможность. А файловый менеджер (возможно за исключением KDE с KDE’шными редакторами, поддерживающими kio — точно не знаю, но это было бы логичным) распакует файл куда‐то во временный каталог, скорее всего, со случайным именем как минимум каталога, натравит на него редактор, по завершению перепакует. Минусы очевидны: из‐за случайного имени не будет работать сохранение undo файлов, позволяющее не терять undo при перезапуске редактора (правда, оно сейчас также почему‐то не работает, но в справке я причины не вижу, значит должно быть ошибкой), не будет swap файлов (а эти работают), работа с другим zip‐архивом всегда будет происходить либо в новом экземпляре редактора, либо в первом/последнем открытом экземпляре (может быть важно, если у вас по экземпляру Vim на проект и вы их не закрываете, переключаясь на другой проект).


И последнее, из консоли вы редактор с zip‐файлом просто так не откроете: либо вам придётся перепаковывать самостоятельно (можете написать скрипт, но готовых я не знаю), либо нужно поставить специальную ФС на основе FUSE (название не помню, но систему, которая позволяет заходить в архивы как в каталоги когда‐то давно трогал, потом удалил за ненадобностью). (Ну или нужен редактор с поддержкой kio или чего‐то аналогичного.)

Опрос в посте из хаба vim показал, что большинство подписчиков пользуется vim.
Ура!
Как привык пользоваться мультикурсором в Саблайме — так и не могу с него ни на что перелезть, пробовал Атом — но после моментальной реакции Саблайма — это ад и израиль.
VSCode — ничего, вроде пошустрее Атома, работа с гитом понравилась, но опять же, после скорости Саблайма — все не то…
Вим так и не осилил, времени не было его плотно изучить и привыкнуть, переодически использую для гита и конфиги иногда в нем правлю, но дальше не пошло. Hе нашел в нем того, что нельзя сделать мультикурсором или другими плюшками Саблайма…
Готов платить 800 МБ, что б не жать :wq )
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории