Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 34
Озадачен. Тогда и Виндоус — IDE. Просто там для редактирования текста другие редакторы используются.
наверное я не просветленный. Вот тут то же самое, но другими словами: habrahabr.ru/post/151128/#comment_5128122
Возможно кому-то пригодится github.com/amix/vimrc
Частенько представлял себя в фантазиях эдаким брутальными девелопером, который хардкорит на стареньком ноуте в чем-то вимоподобном. А потом просыпаюсь и занимаюсь скучной работой в IDE, где меня возможности нумерации строк, подсветки и почти все из данной статьи интересует меньше всего. Все-таки в акрониме Integrated Development Environment гораздо больше смысла и я снова увидел все то же самое, что в туторах вроде vim.wikia.com/wiki/Use_Vim_like_an_IDE, которые делают из vim'а продвинутый редактор, но не IDE.
Давно переехал на емакс, но всё ещё использую vimdiff для сравнения файлов. Очень уж он хорош.
Где структуры классов? Где code complete? Где отладка? Где рефакторинг? Где многое другое необходимое для современной IDE?
Я считаю что хоть как настраивай vim — IDE из него не получить, и прежде всего потому что это — редактор (пусть и с подсветкой и прочим), а не интегрированная среда разработки, мне кажется у статьи просто неверный заголовок.
А по содержанию 'Консоль *nix как средство разработки' — очень даже хорошо и интересно.
Я считаю что хоть как настраивай vim — IDE из него не получить, и прежде всего потому что это — редактор (пусть и с подсветкой и прочим), а не интегрированная среда разработки, мне кажется у статьи просто неверный заголовок.
А по содержанию 'Консоль *nix как средство разработки' — очень даже хорошо и интересно.
Если же читать первый пост и представить что vim-редактор, а добавление остальных программ превращает все это в IDE, то тоже не получается. IDE — _интегрированная_ среда разработки, а в представленном виде это набор несвязанных инструментов.
Это зависит от языка программирования, для Ruby например автодополнение довольно бессмысленно. Отладка есть, рефакторинг — а под этим каждый что-то свое понимает? Все что нужно, можно прикрутить.
Почему это бессмысленно? В RubyMine постоянно пользуюсь автодополнением, можно посмотреть подходящие методы и документацию к ним прямо из окошка дополнения, впоследствии, если есть сомнения, как он работает, можно и к исходнику перейти по Ctrl-click, не только своему, но в использованном gem'e.
Также можно быстро перейти к перекрытому методу в суперклассе, быстро перемещаться между соответствующими контроллером, тестами, моделью и вьюхами, запустить только тот тест, в котором находится курсор, по щелчку мыши в логе теста или сервера сразу перейти к нужному месту в коде, да много чего… Слабо представляю, как это всё можно сделать в виме, да ещё чтобы было удобно пользоваться. Жаль только vim плагин глючный.
Также можно быстро перейти к перекрытому методу в суперклассе, быстро перемещаться между соответствующими контроллером, тестами, моделью и вьюхами, запустить только тот тест, в котором находится курсор, по щелчку мыши в логе теста или сервера сразу перейти к нужному месту в коде, да много чего… Слабо представляю, как это всё можно сделать в виме, да ещё чтобы было удобно пользоваться. Жаль только vim плагин глючный.
RubyMine отличная IDE, но у нее есть и свои проблемы. Запускается более «неспешно», идеальное автодополнение имхо просто невозможно с метапрограммированием, динамическими методами, манки патчингом… Не работает без иксов (это я не к тому, что на продакшене код в живую нужно править, но через ssh хочется подключаться к вагрант виртуалке). Быстро перемещаться по проекту между экшенами-моделями-вьюхами и в виме можно, был какой-то плагин (вроде в сборке от Akita). То есть, вим не IDE, но в большинстве случаев это и не требуется, и огромный плюс — быстрый набор текста, большая скорость работы, работает и стоит везде на *nix'ах. Имхо, конечно. Кстати, а зачем запускать «только тот тест, что нужно»? У меня висит запущенный Guard в консоли постоянно, тест исправил — он его сразу прогнал.
>Запускается более «неспешно»
извините, к IDE такие требования слышать смешно ) Да и зачем закрывать? Нет, если писать на Ruby время от времени, то IDE просто не нужна и дальше спорить не о чем.
>идеальное автодополнение имхо просто невозможно с метапрограммированием, динамическими методами, манки патчингом…
Идеального не будет, да, в мире вообще мало идеальных вещей, но то что есть, работает гораздо лучше, чем ничего. То, что вы перечислили, — это весьма мощные средства, у вас что, большая часть кода таким образом написана?
>Не работает без иксов (это я не к тому, что на продакшене код в живую нужно править, но через ssh хочется подключаться к вагрант виртуалке)
можно добавить сервер в deployment и включить ему автоаплоад. Заодно получите локальную историю правок и отсутствие тормозов, если связь плохая. Кстати, удалённый дебаг тоже есть, для любителей )
А вообще я как-то отвык в обход vcs работать.
>Кстати, а зачем запускать «только тот тест, что нужно»? У меня висит запущенный Guard в консоли постоянно, тест исправил — он его сразу прогнал.
тесты я запускаю в RubyMine, потому что там удобно прямо из консоли в исходник переходить на нужную строку. Там есть аналог guard, но поскольку RM сохраняет файл постоянно, я его отключил. В общем, можете не учитывать как плюс.
Вообще, у меня сложилось впечатление, что вы больше говорите о работе с большим количеством мелких проектов или скриптов, чем с небольших количеством больших. Тут да, командной строки и вима с небольшим количеством плагинов будет достаточно. Но навешивать на последний кучу плагинов (им же ещё хоткеи придумывать, да и текстовый режим не резиновый), пытаясь сделать ультра-IDE имхо не стоит того.
извините, к IDE такие требования слышать смешно ) Да и зачем закрывать? Нет, если писать на Ruby время от времени, то IDE просто не нужна и дальше спорить не о чем.
>идеальное автодополнение имхо просто невозможно с метапрограммированием, динамическими методами, манки патчингом…
Идеального не будет, да, в мире вообще мало идеальных вещей, но то что есть, работает гораздо лучше, чем ничего. То, что вы перечислили, — это весьма мощные средства, у вас что, большая часть кода таким образом написана?
>Не работает без иксов (это я не к тому, что на продакшене код в живую нужно править, но через ssh хочется подключаться к вагрант виртуалке)
можно добавить сервер в deployment и включить ему автоаплоад. Заодно получите локальную историю правок и отсутствие тормозов, если связь плохая. Кстати, удалённый дебаг тоже есть, для любителей )
А вообще я как-то отвык в обход vcs работать.
>Кстати, а зачем запускать «только тот тест, что нужно»? У меня висит запущенный Guard в консоли постоянно, тест исправил — он его сразу прогнал.
тесты я запускаю в RubyMine, потому что там удобно прямо из консоли в исходник переходить на нужную строку. Там есть аналог guard, но поскольку RM сохраняет файл постоянно, я его отключил. В общем, можете не учитывать как плюс.
Вообще, у меня сложилось впечатление, что вы больше говорите о работе с большим количеством мелких проектов или скриптов, чем с небольших количеством больших. Тут да, командной строки и вима с небольшим количеством плагинов будет достаточно. Но навешивать на последний кучу плагинов (им же ещё хоткеи придумывать, да и текстовый режим не резиновый), пытаясь сделать ультра-IDE имхо не стоит того.
извините, к IDE такие требования слышать смешно ) Да и зачем закрывать? Нет, если писать на Ruby время от времени, то IDE просто не нужна и дальше спорить не о чем.
Скорее я неправильно выразился. Не только медленней запускается, но и работает также более медленно, часто что-то обновляет, индексирует. Это немного раздражает.
То, что вы перечислили, — это весьма мощные средства, у вас что, большая часть кода таким образом написана?
Рельсы именно так и написаны, а я работаю с ними. Да и вообще, руби и метапрограммирование — это как одно целое.
можно добавить сервер в deployment и включить ему автоаплоад. Заодно получите локальную историю правок и отсутствие тормозов, если связь плохая. Кстати, удалённый дебаг тоже есть, для любителей )
А вообще я как-то отвык в обход vcs работать.
Я немного не о том говорил, работали с вагрантом? Рубимайн не дружит с ним (пока, обещали добавить). vcs при этом никуда не девается.
ообще, у меня сложилось впечатление, что вы больше говорите о работе с большим количеством мелких проектов или скриптов, чем с небольших количеством больших. Тут да, командной строки и вима с небольшим количеством плагинов будет достаточно.
Почему же в сообществе снискали такую популярность саблайм, вим, тексмейт? Райан Бейтс тоже над мелкими скриптами работает?)) Ничего не имею против RubyMine, вещь просто потрясающая. Просто хотел обратить внимание на то, что у вима есть свои неоспоримые достоинства.
>Скорее я неправильно выразился. Не только медленней запускается, но и работает также более медленно, часто что-то обновляет, индексирует. Это немного раздражает.
Меня как-то не раздражает, может потому что оперативки 3 гига выделил, или проекты меньше… Зато поиск работает очень быстро, как и навигация по кодовой базе.
>Рельсы именно так и написаны, а я работаю с ними. Да и вообще, руби и метапрограммирование — это как одно целое.
Я тоже работаю с рельсами, и автодополнение там замечательно работает )
>Я немного не о том говорил, работали с вагрантом? Рубимайн не дружит с ним (пока, обещали добавить). vcs при этом никуда не девается.
Не работал. То есть у вас код прямо на виртуалке и хранится? Или я что-то не понимаю? В принципе можно замапить в папке через SSH и работать как с локальным проектом, я думаю.
>Почему же в сообществе снискали такую популярность саблайм, вим, тексмейт? Райан Бейтс тоже над мелкими скриптами работает?))
Я и не говорил, что в вим и других редакторах нельзя писать сложные программы. Я лишь говорю, что у IDE есть преимущества, которых нет у простых редакторов, если их постоянно использовать, обратно вернуться будет крайне сложно, я, например, не представляю как вернуться опять на вим. Евангелистом RubyMine я не являюсь, просто высказал своё мнение, буду совсем не против, если вы останетесь при своём )
Меня как-то не раздражает, может потому что оперативки 3 гига выделил, или проекты меньше… Зато поиск работает очень быстро, как и навигация по кодовой базе.
>Рельсы именно так и написаны, а я работаю с ними. Да и вообще, руби и метапрограммирование — это как одно целое.
Я тоже работаю с рельсами, и автодополнение там замечательно работает )
>Я немного не о том говорил, работали с вагрантом? Рубимайн не дружит с ним (пока, обещали добавить). vcs при этом никуда не девается.
Не работал. То есть у вас код прямо на виртуалке и хранится? Или я что-то не понимаю? В принципе можно замапить в папке через SSH и работать как с локальным проектом, я думаю.
>Почему же в сообществе снискали такую популярность саблайм, вим, тексмейт? Райан Бейтс тоже над мелкими скриптами работает?))
Я и не говорил, что в вим и других редакторах нельзя писать сложные программы. Я лишь говорю, что у IDE есть преимущества, которых нет у простых редакторов, если их постоянно использовать, обратно вернуться будет крайне сложно, я, например, не представляю как вернуться опять на вим. Евангелистом RubyMine я не являюсь, просто высказал своё мнение, буду совсем не против, если вы останетесь при своём )
>Я немного не о том говорил, работали с вагрантом? Рубимайн не дружит с ним (пока, обещали добавить). vcs при этом никуда не девается.
Не работал. То есть у вас код прямо на виртуалке и хранится? Или я что-то не понимаю? В принципе можно замапить в папке через SSH и работать как с локальным проектом, я думаю.
Да, прямо на виртуалке. Мапить нет нужды, это происходит автоматом… Но команды-то все рубимайн должен исполнять на виртуалке (запуск рейк тасков, установка гемов, все остальное). А он пытается это делать на хост машине. Посмотрите скринкаст, офигительно удобная штука: railscasts.com/episodes/292-virtual-machines-with-vagrant
Евангелистом RubyMine я не являюсь, просто высказал своё мнение, буду совсем не против, если вы останетесь при своём )
Само собой, сколько людей — столько мнений :)
Самая банальная возможность рефакторинга — изменить название переменной/метода. Это не то же, что и ручное Find/Replace, поскольку стандартные средства той же VS не переименовывают такие же переменные из других методов (т.е. в одном методе Method1 есть переменная var1 и в методе Method2 есть переменная var1. После рефакторинга имени var1 на var2 в методе Method1 есть переменная var2, а в Method2 — var1). Преимущества рефакторинга — тратится меньше времени, нет ошибок связанных с переименованием не той переменной и т.д.
Т.е. работа введется на уровне кода, а не текста.
Т.е. работа введется на уровне кода, а не текста.
Это есть и в виме.
Да, вы правы, очень многое зависит именно от языка. Я нашел любопытную статью, в которой автор сравнивает необходимость использования IDE в Java и Scala.
linexp.ru/forum/ide-ne-nuzhna
По большей части он прав, и IDE часто лишь обертка для не слишком удачного языка.
linexp.ru/forum/ide-ne-nuzhna
По большей части он прав, и IDE часто лишь обертка для не слишком удачного языка.
Кстати, а как сейчас ctags умеет распознать шаблонные конструкции? Т.е. например я напишу что-то вроде:
Как дела с поддержкой С++11? Наиболее важное конечно с точки зрения редактора новое ключевое слово auto вместо явного определения типов.
Как насчет семантической подсветки кода — поля класса, локальные, глобальные, статические переменные, параметры функции можно ли отдельным цветом раскрасить? А неактивные участки кода закрасить (#if 0, #ifndef SOME_DEFINE, etc), в зависимости от установленных значений макросов где-нибудь в конфигурации?
Еще вот сейчас очень модно стало использовать статические аналазиторы, что насчет их интеграции?
typedef boost::ptr_vector<foo> FooVector;
FooVector::iterator it;
it->?
typedef std::shared_ptr<foo> fooPtr;
fooPtr f;
f->?
Как дела с поддержкой С++11? Наиболее важное конечно с точки зрения редактора новое ключевое слово auto вместо явного определения типов.
Как насчет семантической подсветки кода — поля класса, локальные, глобальные, статические переменные, параметры функции можно ли отдельным цветом раскрасить? А неактивные участки кода закрасить (#if 0, #ifndef SOME_DEFINE, etc), в зависимости от установленных значений макросов где-нибудь в конфигурации?
Еще вот сейчас очень модно стало использовать статические аналазиторы, что насчет их интеграции?
ctags поможет виму подсказать, что здесь должны методы и переменные класса foo?
Вроде нет и наврятли когда-то сможет. Но не всё так плохо и ctags всё ещё удобно использовать для навигации, а для автодополнения есть плагины использующие clang/libclang, ещё был где-то плагин использующий gcc sence. Аналогичный ответ насчёт C++11, разве что надо сказать, что ctags не поддерживает C++11 и может не видеть некоторые методы.
Как насчет семантической подсветки кода — поля класса, локальные, глобальные, статические переменные, параметры функции можно ли отдельным цветом раскрасить?
Можно, используя ctags генерируются синтаксические файлы, которые затем грузятся. Вроде есть несколько таких плагинов (называется TagHighlight или как-то близко к этому).
А неактивные участки кода закрасить (#if 0, #ifndef SOME_DEFINE, etc), в зависимости от установленных значений макросов где-нибудь в конфигурации?
И для этого есть плагин (ifdef.vim), правда он не поддерживает сложные условия (с логическими операторами).
Еще вот сейчас очень модно стало использовать статические аналазиторы, что насчет их интеграции?
Об этом же было в тексте статьи, где про проверку синтаксиса. Или имеется в виду анализ сразу всего с просмотром результатов? Если да, то для большинства анализаторов должна быть возможность разгрузить файл с результатами в Vim с помощью ключа -q, если такой возможности нет (формат отчёта не стандартные файл: строка: сообщение), то можно написать конвертер.
Его встроенные инструменты так хорошо совмещаются с внешними Unix-командами, что нередко способны удивить даже опытных пользователей"
Ага, включение подсветки синтаксиса и нумерации строк это прям то, чем сейчас можно удивить. Особенно после статьи с WebStorm 5 и их LiveEdit (не говоря о куче других вещей, которые vim и не снились, просто потому что это редактор, а не IDE).
я не очень то люблю vim, но просто не пойму о каких вещах вы говорите, какие именно вещей нет в вим. Подозреваю что они там точно есть просто вы о них не знаете. )
Да я не говорю что vim плохой редактор, просто функции IDE и редактора сильно отличаются.
Хорошо, для примера, у vim есть контекстный автокомплит показывающий классы/методы/функции не только языка, но и всех подключаемых файлов в проекте?
Хорошо, для примера, у vim есть контекстный автокомплит показывающий классы/методы/функции не только языка, но и всех подключаемых файлов в проекте?
конечно есть
вы про это?
vim.wikia.com/wiki/Folding
vim.wikia.com/wiki/Folding
Vim снилось многое, что не снилось вам.
Например, что там есть такого действительно полезного, чего нет у других? Я к примеру обычно имею дело с большими SQL-файлами, поэтому у меня тест редактора (не IDE) весьма простой, открываю файлик гигов на 6-8. Vim на нем загнулся. долго тупил, пока не вылетел. Тот же файл EmEditor (который я использую как быстрый всеядный редактор) открывает не поперхнувшись за секунды, с подсветкой, и не пытаясь его весь в память загрузить.
Я даже выйду из режима read-only, только лишь чтобы спросить: помилуйте, зачем вам открывать в редакторе SQL-файл на 8 гигов?! Это штатный режим работы?
Нет, но это показатель того, насколько хорошо устроен редактор. У Vim отличный UI и множество дополнений, из‐за чего (особенно первого) я его и использую, но VimL и архитектура очень далеки от идеальных. Про VimL вы можете почитать мою статью, а архитектура — это общее впечатление от того, что вы
Собственно, VimL, система подсветки и система ввода — то, что нуждается в улучшениях, причём второе можно сделать без нарушения обратной совместимости, третье тоже (хотя если вы попросите меня это сделать или дождётесь пока сам созрею, то часть обратной совместимости будет намеренно нарушена, могу объяснить какая и почему). Вместо первого лучше иметь C API с доступом ко всем возможностям редактора и соответствующие интерфейсы: для того, чтобы всё использование VimL сводилось к чему‐то вроде
. Впрочем это не отменит того, что я считаю необходимым сделать VM для VimL, но это имеет мало смысла без потери малой части обратной совместимости: скажите, как Vim может воспринять вторую строку в следующем коде:
? Я знаю как минимум три варианта. Если запретить незавершённые блоки :if/:for/:try/:while/:function и принудительно завершать :append/:insert по окончании :execute то всё сведётся к двум вариантам (никак и как создание привязки) и при том возможно будет построить синтаксическое дерево.
- не видите C API, для улучшения интерфейсов с другими языками зачастую приходится экспортировать существующую static функцию или выделять существующий код в отдельную функцию. Единственная документация — комментарии и их далеко не всегда достаточно;
- видите отсутствие нормального поддержки клавиатурных сочетаний. Обсуждениям на эту тему уже невесть сколько лет, но у Брама нет времени, а у остальных, видимо, пороха на такую задачу;
- видите множество запросов вида «а как сделать подсветку строки там где нет символов/подсветить N’ю колонку» Второе уже решено, но если бы вместо :syn было внятное C API, используемое первой, и соответствующие функции на Python/…, то вопрос бы не требовал создания целой новой настройки;
- видите до сих пор не исправленные неровности в скрытии символов вроде некрасивой табуляции, невозможности получить видимую позицию курсора, необходимости нажимать l/h столько раз, сколько символов сокрыто, …;
- видите вопросы «а почему я не могу сделать
nnoremap d smth, не получая задержку при вводе d»
Собственно, VimL, система подсветки и система ввода — то, что нуждается в улучшениях, причём второе можно сделать без нарушения обратной совместимости, третье тоже (хотя если вы попросите меня это сделать или дождётесь пока сам созрею, то часть обратной совместимости будет намеренно нарушена, могу объяснить какая и почему). Вместо первого лучше иметь C API с доступом ко всем возможностям редактора и соответствующие интерфейсы: для того, чтобы всё использование VimL сводилось к чему‐то вроде
nnoremap some-key :<C-u>python module.method()<CR>
. Впрочем это не отменит того, что я считаю необходимым сделать VM для VimL, но это имеет мало смысла без потери малой части обратной совместимости: скажите, как Vim может воспринять вторую строку в следующем коде:
execute variable
nnoremap a b
? Я знаю как минимум три варианта. Если запретить незавершённые блоки :if/:for/:try/:while/:function и принудительно завершать :append/:insert по окончании :execute то всё сведётся к двум вариантам (никак и как создание привязки) и при том возможно будет построить синтаксическое дерево.
Бывают косяки в подобных файлах, которые вполне обнаруживаются при беглом просмотре (нужно потыкать в несколько мест этого самого файла). Но для этого редактор должен нормально скроллить файл, а не тупить по 10 минут при открытии, а потом вываливаться, или на каждую попытку прокрутить хоть чуть файл подвисать на пару минут.
В общем с EmEditor'ом я уже много раз удостоверился, что он откроет абсолютно любой файл, причем очень быстро, потому он у меня уже много лет вместо выпиленного блокнота.
В общем с EmEditor'ом я уже много раз удостоверился, что он откроет абсолютно любой файл, причем очень быстро, потому он у меня уже много лет вместо выпиленного блокнота.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Unix как IDE: Работа с текстом