Могу с уверенностью сказать, что Vim не плохой редактор и очень расширяемый, но это не повод говорить о том, что Vim подходит всем, так как это вопрос вкуса. При использовании Atom или Code у меня часто возникают зависания, бывает они длятся по нескольких минут.
Как вы думаете, сколько памяти нужно редактору, чтобы открыть следующий C файл?
#include <stdio.h>
int main() {
printf("Hello, world!\n");
}Использование памяти
А вот и ответ:
Редактору Code для открытия 60-байтного кода потребуется 349 мегабайт! Atom потребуется 256 мегабайт. А вот Vim нуждается всего в 5 мегабайтах.Я также включил Nano, чтобы сравнить его с Vim и результат получился меньше чем 1 мегабайт.
Как насчет больших файлов? Открытие 6-мегабайтного XML-файла в Vim потребляет около 12 мегабайт. Nano практически на ровне с Vim. Code нуждается в 392 мегабайтах, а Atom в 845 мегабайтах!
Время запуска
Давайте рассмотрим сколько времени требуется редакторам для открытия того же файла XML, а после открытия перемести курсор в конец файла. Atom и Code потребуется почти 20 секунд. Vim выполнит задачу за 4 секунды. Sublime меня приятно удивил, открыв всего лишь за секунду. Быстрее всех был Nano.
Выполнение поиска и замена 100 000 слов, в том же XML файле показали достаточно неожиданные результаты. Nano и Atom потерпели неудачу, так как для выполнения задачи потребуется почти 10 минут. Atom завис несколько раз, перед тем как получить результат. Code выполнил задачу за 80 секунд, Sublime за 6 секунд. Vim справился за 4 секунды.
Печально смотреть на то, когда редактор потребляет всю вычислительную мощность и память, которые доступны на «современном» дорогостоящем ноутбуке.Библиотека видеоматериалов по Vim, здесь вы можете познакомиться с программистами работающими на VIM и посмотреть как он работает.
Комментарии (166)
asmrnv777
10.08.2017 18:31+26Память нынче очень дешевый ресурс, а вот время — дорогой (автокомплиты, рефакторинги и прочие плюшки). Нормальная IDE может окупить отожранную память за несколько дней.
alltiptop
10.08.2017 18:45-5Вряд ли это можно как то противопоставить виму, время обучения и привыкания к нему — да, а вот про недостаток функционала всё чушь — vim'у вряд ли есть равные.
bustEXZ
10.08.2017 18:58+2а как же emacs? функциональности и расширяемости там тьма :)
И интересен вопрос от пользующихся им, насколько круто он выполняет данные функции, как в посте автора?evseev
10.08.2017 22:01+6Я много работаю с текстом во всех его проявлениях. По своему опыту могу сказать следующее. Какой бы бред вам не пришел в голову Vim это уже умеет.
PS: ввязываться в спор emacs vs vim категорически отказываюсь. Единственное, что наверняка можно сказать про emasc это то, что это отличная операционная система. Жаль только в нем нет нормального текстового редактора ;)yarric
10.08.2017 23:29+1Менять сигнатуру метода умеет?
Fesor
10.08.2017 23:47+2нынче есть очень интересный тред — встраивать средства рефакторинга в тулинг идущий с компилятором/интерпритатором (как это например сделали ребята из TypeScript). В этом есть немало смысла, "не надо ждать пока все IDE добавят новые плюшки", это на руку разработчикам языков. А если все используют одинаковый тулинг для рефакторинга — то спорить кто лучше в этом явно смысла нет.
Tiberiumk
11.08.2017 13:04Плюсую, особенно если у языка маленькое комьюнити — эти тулзы очень сильно помогают
marsianin
11.08.2017 11:52+2В emacs есть evil-mode, режим, в котором он мимикрирует под vim. Так что есть там нормальный текстовый редактор (-:
prudis
11.08.2017 12:02+9«Какой бы бред вам не пришел в голову Vim это уже умеет» — ребята из JetBrains ехидно в сторонке улыбаются :)
Myrgy
12.08.2017 08:39к большому сожалению при включении VimMode в CLion нет ремапинга остальных шоткатов — они просто перестают работать. Да и в отличии от vim и emacs продукты JetBrain не работают по ssh (кроме как примонтировать раздел по sftp).
Кстати интересный проект для emacs — spacemacs.
weirded
12.08.2017 12:25Расскажите про автоматический рефакторинг в Vim (и сколько он с таким обвесом плагинами ест памяти).
Sheriff_Light
10.08.2017 18:52Вроде бы в статье и не говорится, что vim надо использовать, как IDE.
У меня есть и Vim и Sublime, и IDE разные, все они выполняют разные задачи.asmrnv777
10.08.2017 18:58Тут про редактор кода речь, если я правильно понял.
Я тоже использую все это, и тоже для разных задач — конфиги на серверах в виме, локальные логи смотрю в саблайме, код в IDE.
nick_gabpe
10.08.2017 18:37+7У vi/vim есть одна маленькая особенность: с самого начала это крайне недружелюбный интерфейс, недаром же один из самых популярных вопросов на stackoverflow это как выйти из vim. В nano с этим все проще: открываешь редактор и сразу есть подсказки по хоткеям, из коробки.
Лично я использую sublime или nano, по ситуации.
mistergonza
10.08.2017 18:53Интересно было бы узнать какие версии редакторов использовались, а то вон atom с каждой новой версией содержит какие-то улучшения по производительности.
Cheater
10.08.2017 20:07+4Статья вообще ни о чём. Из перечисленных трёх метрик (memory footprint, время запуска, скорость) первые 2 никому не важны. Скорость важна, но она далеко не единственное преимущество vim. Про основные фичи (удобство навигации, command/insert mode, text objects, расширяемость плагинами) скромно промолчали.
PS: моя основная IDE — Emacs в режиме эмуляции клавиатурных комбинаций Vim (evil-mode) и это реально уберкомбо, соединяющее преимущества обеих сред.
beeruser
11.08.2017 23:29-2>>Из перечисленных трёх метрик (memory footprint, время запуска, скорость) первые 2 никому
Кому как. У меня вот 2GB памяти. Можно поставить 4, но нужно перепаивать чипы, что я делать разумеется не буду.
Редактор должен запускаться за 0 секунд. Не существует никаких причин чтобы было иначе.
copyhold
10.08.2017 20:18-11nano нельзя рассматривать как среду разработки. Это ж notepad.
Так что если вы хотите на ЛЮБОЙ машине с ЛЮБОЙ ОС иметь привычный интерфейс среды разработки, альтернативы VIM-у нет.
ЗЫ: и не надо про emacs — не про него тема.
Fox_exe
10.08.2017 21:23+9Раз пошла такая пьянка, почему бы не добавить сюда Notepad++?
Можно ещё сравнить с полновесными IDE (Visual Studio, Eclipse)… Но это уже будет перебор… Или нет?
shurutov
11.08.2017 14:23Единственное, что навскидку не придумывается (именно не придумывается, не факт, что данную функциональность проблематично реализовать) — это вся и всяческая визуализация, типа тех же ER-диаграмм и прочих связей в БД. А так из vim-a вполне себе лёгкую IDE замастырить, я думаю, не проблема.
VolCh
11.08.2017 14:26Проблема, судя по имеющимся модулям, сделать на нём полноценный синтаксический анализатор, особенно работающий на уровне проекта.
izzholtik
10.08.2017 21:47+10Статья из разряда "Hello world на Java занимает в 100 раз больше памяти, чем на С, и запускается в 20 раз дольше". У vi(m) та же самая проблема, что и у JS: его пользователи становятся фанатиками, кричащими, зачатую невпопад, о достоинствах и замалчивающими недостатки.
vics001
11.08.2017 15:00+1vim никуда не уходит и не уйдет. Сегодня это самый адекватный редактор для терминалов (ssh сервера) со слабым connection (ping > 100 ms). Так что пусть vim развивается, а люди его изучают.
izzholtik
12.08.2017 00:35+1Я второй день настраиваю фиговину через канал с пингом в ~5 секунд и потерями 70% D:
Простое — через sed, сложное — в nano. Больше всего боюсь сделать cat какого-нибудь большого файла.
Вроде пока жив.
evseev
10.08.2017 22:12-3Я все понимаю, но меня слегка смущают цифры. Я только что запустил AndroidStudio и ей потребовались 600М. Странно? Вот и я так думаю.
Vim — один из самых дебильных редакторов. Более недружелюбного и уродского еще нужно поискать. Но его сила ни в удобстве. И даже ни в его фичах. Его основная сила в том, что на любой Unix и Unix-like системе он будет. И какой бы жидкий канал не был он будет отлично работать.VolCh
10.08.2017 22:17+1Его основная сила в том, что на любой Unix и Unix-like системе он будет.
Из коробки — далеко не факт, nano субъективно чаще, а права на установку далеко не всегда есть. И не уверен, что vim можно поставить на самый популярный десктопный Unix её стандартным установщиком.
9660
11.08.2017 08:02+1Сможете вспомнить где «из коробки» не было vi(m)?
dovg
11.08.2017 19:09В минимальном дебиане его нет (по крайней мере в девятом).
Первый раз /etc/apt/sources.d/ придется редактировать nano9660
11.08.2017 19:11Что есть минимальный debian?
dovg
11.08.2017 19:129660
11.08.2017 19:26У меня смутное чувство что нетинстал все же не очень обычное «И не уверен, что vim можно поставить на самый популярный десктопный Unix её стандартным установщиком»
dovg
11.08.2017 19:28Ты же пишешь «из коробки». Вот в коробке нетинстала дебиана его нет. Учитывая, что в большинстве серверных конфигураций адреса зеркал приходится править, то первый раз их придется править нано.
Я же не утверждаю, что на дебиан нельзя поставить vim стандартными средствами. Глупо было бы утверждать такое.
VolCh
13.08.2017 16:47"самый популярный десктопный Unix" — Макось. Linux не является Unix.
9660
13.08.2017 17:00Вот тут я пас. Никакой возможности проверить наличие vi(m) в этой ОС у меня нет.
Будем считать что нашли UNIX без vi(m).Fesor
13.08.2017 17:14Никакой возможности проверить наличие
как жаль что человечество не обладает никакими инструментами для поиска информации...
Будем считать что нашли UNIX без vi(m).
на основании чего? в mac os vim есть.
evseev
11.08.2017 12:00Если вы имеете ввиду MacOS, то Vim туда нормально заходит. Я себе поставил без проблем.
VolCh
10.08.2017 22:14+891,56384% времени работы в vim использую его как редактор конфигов на серверах, 95,843684% времени для редактирования файлов на диске использую IDE от JetBrains.
Akuma
10.08.2017 23:06+5Эм. Vim умеет в рефакторинг, автокомплит (желательно не совсем глупый) и подсказки аргументов? Наверняка умеет за счет кучи плагинов.
А вот умеет ли он в интеграцию с Docker, дебагерами, системами деплоя и тестирования, например? Синхронизацию с удаленными серверами, базами данных, удобная работа с Git? Управление менеджером пакетов? Сомневаюсь.
Добавьте сюда еще 100500 фич современных IDE, о которых уже даже не задумываешься и Vim будет нервно курить в сторонке.
Для разработки большого проекта нужно использовать нормальную IDE. Для редактирования мелких файлов — любой блокното-образный редактор, в том числе Vim.
P.S. Не сравнивайте потребляемую программой память и память, требуемую для открытия файла. Любая IDE без открытых файлов жрет памяти довольно много, но вот открытие файлов в ней — не жрет память практически совсем, как и Vim.
acmnu
11.08.2017 11:28+2Уж очень категоричный пост. На мой взгляд даже самые прошареные IDE довольно лимитированы во всем, кроме навигации и дебага. Я например категорически не могу пользоваться встроеными средствами, типа git. Мне на парядок удобнее пользоваться консольными программами, поскольку они быстрее и понятнее. А вот навигация по коду в режиме просмотра в Idea мне нравится больше чем в vim.
Про интеграцию с docker не совсем понял. Умеет ли билдить, запускать в докере? Таки да, запускать он может что угодно и где угодно. У вас некореектное представление об этой экосистеме. Для IDE на java верно следущее: есть плагин — есть функциональность. Для vim же вполне достаточно: есть консольная команда — есть функциональность. Плюс интеграция с python, что в пределе позволяет любые манипуляции с любыми объектами (если есть соответствующий модуль в pip), при чем даже repl можно сделать.
Akuma
11.08.2017 11:38Для рутиных задач вполне хватает встроенных средств. Для всего остального, да, есть консоль, только вот нужна она довольно редко.
Про Docker — просто первое, что пришло в голову. Здесь посыл в том, что IDE из коробки поддерживают популярные инструменты. Хотя интеграция в JetBrains с Docker мне не нравится, честно говоря.
Весь этот спор про Vim vs IDE можно считать некорректным, т.к. Vim консольный, а современные IDE нет. Мне, как и 99% их пользователей, только лишь этой разницы хватит в пользу IDE.
В пользу Vim обычно приводят какие-то сумасшедшие кейсы типа «Я могу с помощью пары нажатий и регулярки заменить какую-то неведомую фигню на другую неведомую фигню». И вроде бы да, это круто. Вот только зачем? Нормального рефакторинга и простого Поиск/Замена хватает в 99.999% случаев.
В общем, статья ни о чем :)acmnu
11.08.2017 12:12+3Здесь посыл в том, что IDE из коробки поддерживают популярные инструменты.
Ну а я про то, что обычно вимерам интеграция и не нужна. Большинство vim'еров держат рядом открытый терминал и выполняют в нем все, что нужно, а в vim только правят. Т.е. это типичный разговор слепого с глухим.
Я так прикидываю, что дело здесь даже в консольности, а скорее всего в команности, если так можно сказать (поскольку например mcedit тоже консольный, но не командный). Т.е. когда что-то хочешь сделать в IDE, ты либо знаешь хот кей, либо лезешь в минюшки. А в vim — либо знаешь хот-кей, либо выполняешь команду, в командной строке (не знаешь команду, говоришь :help).
Ну и ещё один фактор популярности vim это эргономика: не зря же в каждой IDE есть vim плагин для редактора (рекомендую попробовать кстати).
А сумасшедшие кейсы не при делах. Их редко делают в самом vim. А тот что вы упомянули совсем уж обыденность, а не дичь.
VolCh
11.08.2017 12:42Большинство vim'еров держат рядом открытый терминал и выполняют в нем все, что нужно, а в vim только правят.
Грубо, я так же работаю и в IDE. git, docker, файловые команды, иногда grep, tail — это всё в консоли, а в IDE — просмотр и правка кода, иногда отладка. Иногда в консоли открытой в IDE запускаю vim даже для правки конфигов :)
evseev
11.08.2017 12:35Разве с вами кто-то спорил? Вы спросили умеет-ли Vim? Вам ответили — умеет.
Мне, честно говоря, вообще не понятен посыл одно против другого. Зачем? Тем более для таких разных инструментов. По-моему куда лучше смотрится Vim + IDE.
Лично я не вижу ничего зазорного в том, что бы проект писать в IDE, а скажем какие-то файлы открывать в Vim и производить поиск или анализ. Если информации много. Скажем сотни тысяч строк, то выискивать что-то руками или простым поиском- гиблое дело. А если строки очень похожи, то вообще жесть. И при этом даже несложная регулярка поможет вам сэкономить кучу времени и нервов.
VolCh
11.08.2017 12:40Весь этот спор про Vim vs IDE можно считать некорректным, т.к. Vim консольный, а современные IDE нет. Мне, как и 99% их пользователей, только лишь этой разницы хватит в пользу IDE.
Вот как раз TUI или GUI особого значения не имеет. Для меня главное преимущество IDE — полноценная поддержка такой сущности как "проект" и полноценный синтаксический анализатор.
PlatinumThinker
14.08.2017 13:17Попользовался плагином Fugitive (поддержка git в vim), теперь почти не использую git с консоли.
Так же хочу заметить у vim несколько пакетных менеджеров: Vundle.vim, vim-plug, pathogen.
Концепция у вим здоровская: он отлично умеет то для чего создавался: редактирование текстов, и для новичков нужно иметь немного усидчивости и посидеть на голом виме, чтобы понять что он может из коробки, без плагинов.
Кстати редактирование кода через ftp, ssh тоже из коробки (читать netrw)
Delphinum
11.08.2017 13:54+2Эм. Vim умеет в рефакторинг, автокомплит (желательно не совсем глупый) и подсказки аргументов? Наверняка умеет за счет кучи плагинов.
А вот умеет ли он в интеграцию с Docker, дебагерами, системами деплоя и тестирования, например? Синхронизацию с удаленными серверами, базами данных, удобная работа с Git? Управление менеджером пакетов? Сомневаюсь.
Тут скорее наоборот, vim не понимает кода, что вы пишите, потому рефакторинг, автокомплит и подсказки для него гораздо сложнее, чем интеграция со сторонними тулзами. Вывод: первое обычно умеет плохо, а второе замечательно.
robert_ayrapetyan
10.08.2017 23:06При установке vim-a на headless сервере он тянет под 200 мб зависимостей, это единственное, что в нем раздражает.
0xd34df00d
11.08.2017 03:51+4Так надо ебилд с -X мержить!
robert_ayrapetyan
11.08.2017 18:10ебилд — это система сборки в каком-то дистрибутиве линукса или что?
Я про pkg install vim в FreeBSD если что. Собирать из исходников — тоже не вариант на сервере по нескольким причинам (не знаю как в Линуксах, но в FreeBSD сборка из исходников обычно натягивает зависимости новее, чем в системе пакетов, отсюда вылазят всякие конфликты иногда, т.е. нужно либо все из портов собирать, либо все из пакетов, миксовать не рекомендуется).
whitedruid
10.08.2017 23:45-1У некоторых комментаторов наблюдается «гороховый эффект» лишь при одном упоминании vi/viM :) На мой взгляд, vi/viM — стандарт «де-факто» для использования в UNIX-like OS и без хотя бы базовых знаний команд vi/viM в Linux, не говоря уже о UNIX и коммерческих UNIX, комфортно и эффективно работать работать вряд ли получится. Однако вышесказанное не умоляет достоинств других текстовых редакторов — речь идёт исключительно о сложившейся традиции или «выборе сообщества», «выборе аудитории пользователей» — как это не назови.
daggert
11.08.2017 00:28+3> На мой взгляд, vi/viM — стандарт «де-факто» для использования в UNIX-like OS и без хотя бы базовых знаний команд vi/viM в Linux, не говоря уже о UNIX и коммерческих UNIX, комфортно и эффективно работать работать вряд ли получится.
Да не скажите. Вполне себе нормально живется без знаний vi/vim (: Для 99% случаев поправить мелкий скрипт и nano хватает.
raskal
12.08.2017 08:39-1Скорее всего у вас достаточно узкая специализация. Первые 10 лет работы в unix-like операционных системах я тоже думал, что мне нормально живется без знаний vi/vim.
AlexBin
12.08.2017 11:50Думаю, на этом ресурсе приветствуются аргументы, а не пафос.
raskal
14.08.2017 23:49На этом ресурсе большинство уведет карму в глубочайший минус просто за то, что им кажется, что выдвинутое мнение не совпадает с их собственным — поэтому нет никакой разницы, что именно здесь приветствуется.
daggert
12.08.2017 12:15+2Я средней руки программист-сисадмин-эникейщик, у меня 32 сервера под юниксом (от фряхи до qnx) и я не представляю зачем мне нужен vi/vim. Если мне надо поправить мелкий скрипт я сделаю это при помощи nano. Если мне надо поправить большой или написать новый — я не буду это делать на живчике, а скачаю на свой компьютер и запущу нормальную IDE. Хотя такой необходимости у меня просто нет, ибо на компьютере где я работаю есть точные копии того что лежат на сервере и я могу поменять у себя и залить все одной кнопкой.
raskal
14.08.2017 23:55Ну вот есть задача потестить новый фреймворк. Можно для этого запускать IDE, конечно. Но как быть в случае с пайтоном, например, если машина для разработки удаленная? Как подебажить опенстек на удаленном сервере? Можно, конечно, ковырять скрипты в тысячи строк с nano, но это просто не так удобно, как с vim, да и не везде есть nano (как и права на его установку), а vi 100% есть везде. Что делать, если надо написать небольшой модуль к Puppet, купить RubyMine? Как быстро поправить конфиг (выровнять строки, закомментить что-то)? Как быть, в конце концов, если редактируешь файл из nano, а sudo вызвать забыл? Абсолютно все вышеперечисленное можно делать без vi/vim, но когда вы делаете это в нем, вы не думаете обо всех этих сопутствующих проблемах, вы думаете только о том, как решить задачу. Может, такое сравнение понравится не всем, но это как печатать 10 пальцами — вы не думаете о кнопках, вы думаете только о том что вы хотите напечатать. Это позволяет концентрироваться и выполнять поставленную задачу лучше.
AlexBin
15.08.2017 00:27— я каждый день как раз пишу на питоне на удаленном сервере, IDE автоматически заливает файлы по sftp по нажатию ctrl + s
— Все остальные описанные операции хорошо делает scp + notepad++ например, при сохранении файла в блокноте, сцп автоматически заливает файл на сервер. Notepad++ довольно неплохо справляется с текстовыми задачами, к нему тоже есть куча плагинов. Да он и без плагинов довольно мощный, поддерживает кучу синтаксисов, макросы и всякое.
— с правами согласен, либо рут открывать по ssh, либо менять права на конфиг, не очень удобно. Но если вы руками правите кучу конфигов на куче серверов, то вы что-то делаете не так. А если один конфиг в качестве исключения, то тогда можно и права ненадолго сменить.raskal
15.08.2017 00:47Можно писать в IDE, а потом заливать по sftp. Скорость будет страдать, разумеется. И чем чаще вы будете сохранять, тем больше она будет страдать. Из таких маленьких страданий складывается большая боль. Но это кому что нравится — я часто вижу у людей желание делать вещи каким-то конкретным способом и не хочу им продавать свой подход. Но как мне кажется, спорить, что редактирование прямо на удаленной машине ощутимо быстрее, чем копирование целого файла каждый раз на эту машину, бессмысленно. Я в IDE занимаюсь только разработкой, например и почти никогда — тестированием новых вещей.
Про все остальные операции — notepad++ не кроссплатформенный. И если вы им пользуетесь, то скорее всего, у вас интерфейс системы не очень подходящ под удобную работу по ssh. А так — он хороший, да. Почти как vim. Только с окошками и мышкой надо побольше тыкать.
Про кучу конфигов и что-то не так — ну это очень голословно. У меня на одной работе постоянная разработка у людей на ажуре. Вот часто бывает, что надо заспавнить новую виртуалку, но что-то подхачить под нужды для тестирования. Вот прямо каждый день такое бывает. Что ж мне, оркестрировать каждую виртуалку, которая и живет-то часто несколько часов всего?
daggert
15.08.2017 00:55Если вы зашли на удаленку для того чтоб там «ковырять скрипты в тысячи строк с nano» — вы делаете что-то не так.
Поправить переменную — любой редактор подойдет.
Поправить скрипт — я лучше его скачаю и буду править локально и залью обратно, мне как-то спокойней это делать в удобном окружении настроенной IDE.
Ну и по пунктам:
> Что делать, если надо написать небольшой модуль к Puppet, купить RubyMine?
Не знаю что это такое, простите.
> Как быстро поправить конфиг (выровнять строки, закомментить что-то)?
Я справлялся в nano. Самый сложный конфиг скачивал локально, ибо там было 2000 строк.
> Как быть, в конце концов, если редактируешь файл из nano, а sudo вызвать забыл?
Ну это просто нелепая ситуация.
> Абсолютно все вышеперечисленное можно делать без vi/vim, но когда вы делаете это в нем, вы не думаете обо всех этих сопутствующих проблемах, вы думаете только о том, как решить задачу.
Меня уже лет десять пытаются тыкать носом в консоль и приучить что любое действие в ней удобней. Нет, это не так. Это привычней тем кто учит. С vim точно такая-же история. Вы к нему привыкли, вам в нем удобней — а мне удобней и привычней в nano и я еще не встречался с задачами где-б он меня тормозил. Я не вижу для себя никаких преимуществ, которые я получу овладев данным инструментом.raskal
15.08.2017 01:09>Я не вижу для себя никаких преимуществ, которые я получу овладев данным инструментом.
Вот тут можно было закончить, если бы вы это сразу написали. Я вижу для себя преимущества, овладев любым инструментом.daggert
15.08.2017 09:51Вы лукавите. Человек всегда ограничивает свой кругозор в выборе. Я сделал ставку на IDE от Jetbrains, этот инструмент покрывает 400% моих требований. До этого я делал ставку на Qt. Зачем мне может понадобиться vim? Чтоб в беседе упомянуть «А я знаю vim»? Я им пользоваться не буду, у меня есть полноценная IDE, с подсветкой, отладкой, системой контроля версий и удобным для меня внешним видом, удобными хоткеями наконец, загрузкой на сервер одной кнопкой, подсказками.
Вы предлагаете учить инструмент на просто так?
acmnu
11.08.2017 11:30Это уже не совсем актуально. Во многих мейнстримовых дистрах nano по дефолту в качестве EDITOR, хотя и vi там есть.
Finesse
11.08.2017 02:09+3Какая целевая аудитория у Atom? По скорости запуска и работы он как большая IDE, а по возможностям как простой текстовый редактор (например, Sublime).
susnake
11.08.2017 03:55sed, vi
Под виндой notepad++, но только когда нужно открыть мелкий (<200МБ) текстовый файл.
pmcode
11.08.2017 07:18+1Я честно, долго и упорно пытался приспособить Vim как средство для web-разработки. Но даже с кучей плагинов он умеет меньше чем VSCode из коробки. Потом для Markdown. Но опять, отсутствие превью склонило выбор в пользу VSCode. В итоге, сейчас он прижился в основном как консольный редактор. Еще им удобно работать с большими файлами или если требуется большой объем, особенно нестандартного, редактирования текста. Все-таки история команд иногда очень сильно выручает.
Из основных недостатков я бы назвал уникальный и неповторимый синтаксис регулярных выражений. Отсутствие вменяемого поиска/замены по каталогу. И, с тех пор как в GNOME сломали xkb, неудобство переключения раскаладок.
Надеюсь неовимовцы все-таки осилят LSP и тогда можно будет снова подумать о конкуренции Neo(Vim) с современными редакторами для разработчкиов. Потому что сейчас Vim ее полностью проиграл, что косвенно показывает количество и качество плагинов.
Мой конфиг можно посмотреть и покритиковать на гитхабе.isden
11.08.2017 09:24> Еще им удобно работать с большими файлами
С большими — не очень. Он начинает сильно тормозить на файлах в районе 300-600 метров. Я как-то попробовал открыть в нем sql дамп на что-то в районе гигабайта — он просто упал через минут 5-7 размышлений. К слову, sublime с этим файлом справился быстро и на ура.ZyXI
11.08.2017 09:43+1Большие файлы как раз проблема: Vim грузит в память весь файл разом. Ещё больше проблема файлы с длинными строками: здесь одна строка — один C’шный
unsigned char *и с длинной строкой реально не готовы работать ни подсветка синтаксиса, ни код для её редактирования.
OnYourLips
11.08.2017 07:51+3А если обвесить vim плагинами до такой степени, чтобы он стал IDE, и сравнить?
Что-то мне подсказывает, что он начнет проигрывать.
quasilyte
11.08.2017 09:32Вы, конечно, не про vim спрашивали, но я могу описать как происходит в моей конфигурации Emacs.
Из-за его однопоточности всё может дойти до того, что при большом количестве событий на
печать/перемещения курсора могут возникать подвисания (freeze) редактора на небольшое,
но замечаемое глазом время (0.1-0.3 секунды).
Если честно, всё равно по ощущениям более отзывчивый, чем IntelliJ IDE на достаточно мощных машинах,
а на моём ноутбуке так её лучше не запускать, рискуют на пару с браузером вогнать кого-нибудь в swap.
Но по потреблению памяти, нет, не факт, что будет проигрывать.
Описанный выше «задумчивый» Emacs даже на достаточно большом количестве немаленьких буферов
потребляет примерно 60-80Mb.
tl;dr — да, вы правы, но экстраполировать на абстрактную IDE сложно. Зависит от её кривизны.
ZyXI
11.08.2017 09:37Что?то мне подсказывает, что нет. Слишком простой ЯП: никакого JIT, GC на счётчике ссылок (простой mark&sweep для особых случаев). Даже AST нету, при создании функции просто сохраняется её исходный код. В результате ужасная производительность, но потреблять гигабайтами память здесь нечему: собственного аллокатора, резервирующего много места на будущее, нет, мусор не копится, код хранится в одном представлении, дополнения приходится оптимизировать, либо дёргать внешние программы (у некоторых языков, впрочем, можно запустить код на языке внутри процесса Vim).
fireSparrow
11.08.2017 10:16+14>> Почему я до сих пор использую Vim?
Потому что не знаете, как из него выйти? :)
Vlad_fox
11.08.2017 11:14-1При использовании Atom или Code у меня часто возникают зависания, бывает они длятся по нескольких минут
может автору просто ноутбук сменить?
у меня на (стационарной правда) машине с 4 гб оперативки открыто несколько очень тяжелых клиентов, файрфокс с несколькими десятками вкладок, несколько жирных екселей, несколько редакторов (саблайм, для еще более быстрого доступа — встроенный в фар редактор)
и ничего не тупит.
никогда даже не задумывался сколько времени загружается редактор или сколько памяти ест. Меня не объест.
как-то больше думаю про то как быстро будет работать код, который пишу в редакторе, а не про сам редактор
iogurt89
11.08.2017 14:24+1Я пытался использовать Vim. Но столкнулся с большим количеством гемора с его настройкой и т.д.. В итоге пользуюсь IDE от jetbrains с Vim плагином. Лично для меня это самый лучший вариант.
grieverrr
11.08.2017 15:24+3Никогда такого не было и вот опять. Подсчет мегабайтиков и милисекундочек при каких-то нелепых начальных условиях.
Поиск и замена в 8мб файле быстрее всего будет выполнена командой sed, например.
YemSalat
13.08.2017 19:35-1Поиск и замена в 8мб файле быстрее всего будет выполнена командой sed, например.
Быстрее — возможно, а вот удобнее ли…daggert
13.08.2017 22:57При всей моей нелюбви к консоли — замена sed'ом достаточно удобна и быстра. Намного лучше чем замена нормальным редактором.
YemSalat
14.08.2017 23:14И, как оказалось, может приводить к подобным вещам:
https://stackoverflow.com/questions/12696125/sed-edit-file-in-place
https://stackoverflow.com/questions/7733922/sed-command-creates-randomly-named-files
Т.к. сед создаёт временный файл, куда копирует результат.
YemSalat
13.08.2017 23:10-1Раз «минусят», давайте попробую добавить аргументов. Почему считаю что пользоваться седом менее удобно чем встроенным в редактор функцией поиска/замены:
— не нужно переключать контекст, т.е. если я уже в редакторе и работаю с определенным файлом — лучше не «рвать поток» и продолжать работать в том же редакторе
— в редакторе будет проще делать замену только определенных частей
— в редакторе перед заменой визуально хорошо видно что будет заменено (можно глазами пробежаться по файлу/минимэпу) и не накосячить (если например допустил ошибку в регулярке, и т.п.)
Хотелось бы услышать аргументы в «противоположном направлении»ZyXI
13.08.2017 23:47+2Забыли самое главное: в редакторе есть undo, и после поиска/замены в редакторе редактор своё undo не потеряет. В случае с sed — может: например Vim, в зависимости от настроек и размера файла, либо потеряет undo, либо запишет в дерево «а здесь мы потёрли весь файл, а затем вставили вот такое содержимое: {весь файл целиком}» (т.е. в undo окажется неоправданно большой кусок текста, в двух экземплярах, даже если вы sed’ом поправили одну строчку). И это только если файл был открыт в Vim, пока вы ковыряли его sed’ом, если не был — Vim’у неоткуда знать, что там было в файле, соответственно, вычислить разницу и сохранить её в undo дереве он не может.
Частично проблему снимает контроль версий, но я ещё как?то не видел команд, где приветствуют незавершённые микрокоммиты — следовательно, их придётся чистить. Undo дерево редактора чистить не придётся.
guai
11.08.2017 15:27на винде notepad2 для мелких файлов — самое то.
С кучей подсветок.
Умеет всё то же самое, из наиболее часто нужного, что и notepad++, но ощутимо быстрее стартует.
Сколько памяти ест — не знаю, пофигу как-то.
AlexBin
11.08.2017 17:20+1Знаете почему я до сих пор разогреваю суп в металлической тарелке на газу? Потому что тарелка занимает на кухне значительно меньше места, чем микроволновка. Кроме того, использование тарелки намного дешевле, ибо стоимость газа ниже стоимости электричества. Видимо потому, что я живу в дупле на дереве, где беда с электричеством и свободным местом.
grieverrr
13.08.2017 11:06какой же газ в дупле, только примус, только хардкор.
как говорится — любого можно вывезти из дупла, но дупло — не из каждого.
Legion21
12.08.2017 00:44-1Чем же надо загрузить Visual Studio Code чтобы он подвис на минуту?
ZoomLS
13.08.2017 12:50Открыть большой файл. Может и не отвиснуть или вообще вырубится. Atom так же. Пришлось отказаться от них и вернуться на Sublime. Впрочем, профита в их использовании по сравнению с Sublime, так и не нашёл. Одни только тормоза и повышенный жор ресурсов системы.
PaulD
12.08.2017 08:40Vim помогает быстро внести правки в конфигурационные файлы внутри jar архива. Очень удобно реализовано, в других редакторах такое не встречал.
vovka667
12.08.2017 08:40+3Опрос в посте из хаба vim показал, что большинство подписчиков пользуется vim.
Ура!
YemSalat
13.08.2017 20:40-1Как привык пользоваться мультикурсором в Саблайме — так и не могу с него ни на что перелезть, пробовал Атом — но после моментальной реакции Саблайма — это ад и израиль.
VSCode — ничего, вроде пошустрее Атома, работа с гитом понравилась, но опять же, после скорости Саблайма — все не то…
Вим так и не осилил, времени не было его плотно изучить и привыкнуть, переодически использую для гита и конфиги иногда в нем правлю, но дальше не пошло. Hе нашел в нем того, что нельзя сделать мультикурсором или другими плюшками Саблайма…
eisaev
У меня у одного диссонанс: графики выглядят как реклама Sublime, а в заголовке Vim?
Fesor
sublime по мощи уступает vim-у все же.
eisaev
del
mushamib
в 3 из 4 графиков Vim лучше чем Sublime. Вряд ли это может быть хорошим результатом для Sublime
eisaev
Заметно, а не на уровне стат. погрешности, Sublime уступает только на первых двух графиках. Но и они не совсем понятны, т.к. по ним получается, что он при открытии 60-байтного кода сожрал в 1,5 раза больше памяти, чем при открытии 6-мегабайтного XML-файла. Похоже, что эксперимент не блещет чистотой.
PS Не пользую Sublime и Vim. Использую иногда vi и то только по необходимости, когда иного не наблюдается.
SlavniyTeo
У графиков разная цена деления: на 60 байт Sublime потребовалось 50Мб, на 6 мегабайт — 75Мб.
eisaev
Да. Вы совершенно правы и это отбрасывает предположения о некорректности эксперимента конкретно по данному пункту. Однако «читабельности» графикам, к сожалению, не добавляет.
prudis
«Как вы думаете, сколько памяти нужно редактору, чтобы открыть следующий C файл?» — who cares?
Massacre
Редакторам под DOS вообще хватало 640кбайт на всё!
dmitry_ch
nano, по графикам-то он рулит (почти везде).
И, да, по памяти ожидал другой результат увидеть, что vim кушает меньше всего, ан нет!