Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 199
а чего там в vim такого, что даже от vs воротит? в двух словах, если можно.
Коротко объяснить у меня не получится. Могу только посоветовать вам попробовать самому. Это — единственный способ почувствовать отличие.
Дело в том, что приемы редактирования текста в vim очень отличаются от редактора Visual Studio.
Популярные в *nix редакторы vim и GNU Emacs имеют множество поклонников. И не зря, т.к. при должном старании и самообучении можно довести скорость написания текста до очень высокой.
Привыкнув к мощи vim или GNU Emacs, очень тяжело пересаживаться на другой текстовый редактор, т.к. продуктивность написания текста резко падает.
В данном случае автора не «воротит» от редактора VS, как вы выразились, а просто он не хочет тратить больше времени на написание кода, т.к. владеет особой магией.
Популярные в *nix редакторы vim и GNU Emacs имеют множество поклонников. И не зря, т.к. при должном старании и самообучении можно довести скорость написания текста до очень высокой.
Привыкнув к мощи vim или GNU Emacs, очень тяжело пересаживаться на другой текстовый редактор, т.к. продуктивность написания текста резко падает.
В данном случае автора не «воротит» от редактора VS, как вы выразились, а просто он не хочет тратить больше времени на написание кода, т.к. владеет особой магией.
Вот сколько читаю «возрастает скорость написания кода», столько и недоумеваю — у программистов что, узкое место в решении задачи — скорость печати?
Ну т.е. я ничего против не имею, конечно, но для меня это какой-то слабый аргумент.
Естественно, скорость правки текста — это не главное.
Ни я, ни автор топика не утверждаем, что редактор Visual Studio плох, а vim в 9000 раз лучше.
Человек просто предпринял попытку создать себе привычный интерфейс, сделал подробный обзор решений и выводы, не начиная никаких холиваров.
По-моему, очень достойно похвалы и плюсов.
Ни я, ни автор топика не утверждаем, что редактор Visual Studio плох, а vim в 9000 раз лучше.
Человек просто предпринял попытку создать себе привычный интерфейс, сделал подробный обзор решений и выводы, не начиная никаких холиваров.
По-моему, очень достойно похвалы и плюсов.
Ну в качестве аргумента можно ещё привести такую вещь как привычка. Принцип работы с кодом в vim'е не такой как в большинстве других редакторов, поэтому разом пересаживаться с него будет не очень удобно в силу сложившихся привычек, ведь «общение в редактором» проиходит уже на автомате…
Может быть уже не актуально, но все же.
Скорость — имеет значение. Лично у меня очень слабые навыки работы с «обычными» редакторами, так что пока я возьмусь за мышку, поставлю курсор в нужное место, промахнусь по клавишам из-за того что они размещены в разных частях клавиатуры — я уже забываю о том, что хотел реализовать. Хочу сказать, что очень сильно падает концентрация, пока редактируешь код «обычным» способом.
Скорость — имеет значение. Лично у меня очень слабые навыки работы с «обычными» редакторами, так что пока я возьмусь за мышку, поставлю курсор в нужное место, промахнусь по клавишам из-за того что они размещены в разных частях клавиатуры — я уже забываю о том, что хотел реализовать. Хочу сказать, что очень сильно падает концентрация, пока редактируешь код «обычным» способом.
То, что скорость написание — это не самое узкое место при решении задачи не значит, что скорость не имеет значения. Кроме того, скорость — не основная причина по которой я использую Vim. Главная причина — удобство.
Объяснять на словах причины этого это бессмысленно. Если вы хотите разобраться, почему многие люди используют Vim и хвалят его — просто попробуйте использовать Vim в течение месяца. Даже если поначалу Vim покажется странным, через некоторое время вы скорее всего просто не захотите использовать что-либо другое.
Объяснять на словах причины этого это бессмысленно. Если вы хотите разобраться, почему многие люди используют Vim и хвалят его — просто попробуйте использовать Vim в течение месяца. Даже если поначалу Vim покажется странным, через некоторое время вы скорее всего просто не захотите использовать что-либо другое.
Да я пробовал. Правда, не месяц, с неделю всего. Я не умаляю достоинств vim'а, наоборот, я ввязываюсь в дискуссии о нём именно потому, что раз им пользуется столько человек, видимо, он стоит того.
Однако я просто в принципе не могу понять привязанности к редактору. Если проекты в студии, я могу писать в студии, если ничего, кроме блокнота нет, я могу и в блокноте. Т.е. одно дело, когда есть возможность использовать свой любимый редактор, то почему бы и нет, но если приходится писать на другом, то я лично дискомфорта не испытывал при смене редакторов.
Повторюсь, я не спорю о достоинствах или недостатках, я просто вставил комментарий :)
Однако я просто в принципе не могу понять привязанности к редактору. Если проекты в студии, я могу писать в студии, если ничего, кроме блокнота нет, я могу и в блокноте. Т.е. одно дело, когда есть возможность использовать свой любимый редактор, то почему бы и нет, но если приходится писать на другом, то я лично дискомфорта не испытывал при смене редакторов.
Повторюсь, я не спорю о достоинствах или недостатках, я просто вставил комментарий :)
Мало сидели, мало ;)
При разовой правке дискомфорта нету, а если работы много — начинаешь на автомате жать привычные хоткеи, а в ответ происходит непонятно что. А это как раз занимает много времени — хочешь что-то сделать как обычно, происходит какая-то лажа, ищешь как вернуть обратно, пробуешь по-другому…
Я лично VS пользуюсь еще с VC6, к его дефолтам и привык, а всякие финты вроде «пересунуть Solution Explorer в правый сайдбар» (началось с 7.0) меня ужасно расстроили… Хорошо хоть начиная с 2005 можно при установке выбрать привычные опции :)
Я лично VS пользуюсь еще с VC6, к его дефолтам и привык, а всякие финты вроде «пересунуть Solution Explorer в правый сайдбар» (началось с 7.0) меня ужасно расстроили… Хорошо хоть начиная с 2005 можно при установке выбрать привычные опции :)
Vim поначалу отпугивает своими режимами (визуальный, редактирования, командный), но это скорее с непривычки после других редакторов. Чтобы привыкнуть и понастоящему прочуствовать vim нужно больше времени, чем одна неделя, зато потом становится очень комфортно в нём работать. Его огромный плюс именно в настраиваемости, всегда можно подстроить его именно под себя, ну и возможностей у него тоже не мало.
Просто многие (я не именно про Вас) используют любые IDE только как текстовый редактор (читай блокнот) + project explorer и не более, т.е. от возможностей самой IDE используется минимум. Но когда долго работаешь в каком-то определённом редакторе/IDE, то начинаешь использовать какие-то его фишки и к ним привыкаешь, редактор/IDE перестаёт быть простым блокнотом, вот с этих пор резкий и полный переход на другой редактор становится некомфортным, при этом разовое редакирование через другой редактор ничего негативного не вызывает ;)
P.S. Не про редактор. Я, например, привык и часто использую буфер обмена в linux, в который текст помещается при простом выделении текста. Когда приходится что-то править под виндой, чаще всего чертыхаюсь именно по этому поводу :) по привычке пытаюсь копировать текст таким же образом…
Просто многие (я не именно про Вас) используют любые IDE только как текстовый редактор (читай блокнот) + project explorer и не более, т.е. от возможностей самой IDE используется минимум. Но когда долго работаешь в каком-то определённом редакторе/IDE, то начинаешь использовать какие-то его фишки и к ним привыкаешь, редактор/IDE перестаёт быть простым блокнотом, вот с этих пор резкий и полный переход на другой редактор становится некомфортным, при этом разовое редакирование через другой редактор ничего негативного не вызывает ;)
P.S. Не про редактор. Я, например, привык и часто использую буфер обмена в linux, в который текст помещается при простом выделении текста. Когда приходится что-то править под виндой, чаще всего чертыхаюсь именно по этому поводу :) по привычке пытаюсь копировать текст таким же образом…
Отчего же вы не поработали в VS месяц? Глядишь, тоже бы понравилось.Я работал в VS долгое время. До того, как начал активно использовать Vim.
Основная моя мысль заключается в том, что, привыкнув к Vim'у другие редакторы использовать неудобно. Это является следствием специфичности интерфейса Vim. Я не собираюсь вам доказывать, что VS — плохо и что только Vim — хорошо. Если вам нужен холивар — вы выбрали неудачное место.
Хотелось бы просто уточнить — в ВИМе с вашей точки зрения есть какие-то возможности, которых нет в ВС или просто привычка?
Человек потрудившийся освоить Vim не задает таких вопросов. Если вам жалко времени на изучение, то почему вы считаете, что кому то не жалко его на пустые диспуты?
По меньшей мере vim можно очень гибко настраивать под себя, менять любые хоткеи, менять/добавлять функции и так же навешивать свои хоткеи. VS точно не обладает такой гибкостью настроек ;)
Ну а возможности для редактирования/разработки в vim очень просто добавляются. Думаю, что легко найти и добавить то, чего нет в VS.
Ну а возможности для редактирования/разработки в vim очень просто добавляются. Думаю, что легко найти и добавить то, чего нет в VS.
Студия также позволяет навешать на себя кучу плагинов и макросов, в которых можно запрограммировать все что угодно. Немного в сторону, но когда в пору былой молодости использовал Borland Delphi, у меня стояло на ней наверное десятка два дополнительных обвесок, расширяющие как возможности просто редактора кода (банальный code folding, code refactoring, умные скобки и т.д.), так и улучшения для редактора форм. Сложно даже представить, что нельзя добавить/изменить в студии, ограничения по сути только в вашей фантазии.
А можно пример того, что можено сделать в ВИМ и нельзя в ВС. Про хоткеи я нашел вот такое ограничение в справке
The following keys cannot be assigned to a command in Global: PRINT SCRN/SYS RQ, SCROLL LOCK, PAUSE/BREAK, TAB, CAPS LOCK, INSERT, HOME, END, PAGE UP, PAGE DOWN, Windows logo keys, Application key, any of the ARROW keys, or ENTER; NUM LOCK, DEL, or CLEAR on the numeric keypad; or CTRL+ALT+DELETE.
The following keys cannot be assigned to a command in Global: PRINT SCRN/SYS RQ, SCROLL LOCK, PAUSE/BREAK, TAB, CAPS LOCK, INSERT, HOME, END, PAGE UP, PAGE DOWN, Windows logo keys, Application key, any of the ARROW keys, or ENTER; NUM LOCK, DEL, or CLEAR on the numeric keypad; or CTRL+ALT+DELETE.
Ну вот только что я без проблем в vim переназначил <Tab>, что, судя по процитированному Вами куску help'а, нельзя сделать в VS :) Надеюсь, я в достаточной мере ответил на Ваш вопрос.
Вообще подобные вопросы напоминают холивар.
Наверное в большинстве редакторов/IDE есть какие-то функции, которых нет в других. Так и здесь — Vim может делать что-то, что не может VS, и VS может делать что-то, что не может Vim. Всё очень просто. Здесь же не сравнение и не заявление, что что-то одно хорошо, а другое плохо.
Если Вы пользуетесь всеми возможностями «своего» редактора/IDE, ну или достаточно большой их частью, то при переходе на другой редактор/IDE первое время в нём работать будет некомфортно.
Вообще подобные вопросы напоминают холивар.
Наверное в большинстве редакторов/IDE есть какие-то функции, которых нет в других. Так и здесь — Vim может делать что-то, что не может VS, и VS может делать что-то, что не может Vim. Всё очень просто. Здесь же не сравнение и не заявление, что что-то одно хорошо, а другое плохо.
Если Вы пользуетесь всеми возможностями «своего» редактора/IDE, ну или достаточно большой их частью, то при переходе на другой редактор/IDE первое время в нём работать будет некомфортно.
Ну я вимом просто не буду пользоваться. И выяснять что лучше мне неинтересно. Мне интересно на ровне концепций.
Пока ничего принципиально крутого народ не показал — ИМХО какие-то мелочи…
Пока ничего принципиально крутого народ не показал — ИМХО какие-то мелочи…
Ну так здесь и не сравнение редакторов ;)
перечитай ветку и убедись что не прав :)
Я не про тред разгвора, а про тему топика.
Даже если и про данный разговор — начало ветки
> а чего там в vim такого, что даже от vs воротит? в двух словах, если можно.
Не вижу сравнения. Это скорее вопрос «а нафига?» :)
Если Вы для себя стали воспринимать это всё как подробное сравнение редакторов, то это лично Ваше дело. Единственное что тянет на сравнение, это просьба конкретного примера, что есть в Vim и нет в VS, я на этот вопрос уже давно ответил. Читайте внимательнее.
Даже если и про данный разговор — начало ветки
> а чего там в vim такого, что даже от vs воротит? в двух словах, если можно.
Не вижу сравнения. Это скорее вопрос «а нафига?» :)
Если Вы для себя стали воспринимать это всё как подробное сравнение редакторов, то это лично Ваше дело. Единственное что тянет на сравнение, это просьба конкретного примера, что есть в Vim и нет в VS, я на этот вопрос уже давно ответил. Читайте внимательнее.
Вот щас перечитал все ваши посты.
в-общем, я вынес что в виме
1. гибче настраиваются хоткеи
2. больше хоткеев для всяких действий
в результате чего несколько меньше нажимать кнопок.
ничего принципиального…
в-общем, я вынес что в виме
1. гибче настраиваются хоткеи
2. больше хоткеев для всяких действий
в результате чего несколько меньше нажимать кнопок.
ничего принципиального…
Повторюсь, я не считаю что здесь сравниваются Vim и VS, здесь не описываются их плюсы и минусы. А мои посты — это по сути ответы на вопросы и ответы простейшие.
Если Вы хотите именно сравнить сабжи, то либо создайте топик на эту тему, либо почитайте документацию и постарайтесь какое-то время попользоваться Vim'ом. Думаю, что иначе действительно сравнить и понять все плюсы и минусы не получится. Ну и не будем забывать что каждый инструмент подходит для выполнения определённой задачи и не обязан подходить для выполнения других задач.
Ну и хотелось бы поправить
> 1. гибче настраиваются хоткеи
> 2. больше хоткеев для всяких действий
Гибче настраиваются не хоткеи, а сам редактор.
Хоткеев не больше, просто тут нет такого определения хоткей-действие, есть действия, а на любой хоткей можно повесить любую цепочку действий, эти действия так же можно обернуть в функцию. Посмотрите тут, не так давно было на главной. Там как раз показан пример «навешивания» своего функционала на стандартную функцию сохранения + присутсвует код .vimrc, в котором вы можете посмотреть каким образом осуществляется назначение хоткеев.
Кстати, Вы пытаетесь сравнить Visual Editor и IDE, что, мягко говоря, немного разные вещи…
Если Вы хотите именно сравнить сабжи, то либо создайте топик на эту тему, либо почитайте документацию и постарайтесь какое-то время попользоваться Vim'ом. Думаю, что иначе действительно сравнить и понять все плюсы и минусы не получится. Ну и не будем забывать что каждый инструмент подходит для выполнения определённой задачи и не обязан подходить для выполнения других задач.
Ну и хотелось бы поправить
> 1. гибче настраиваются хоткеи
> 2. больше хоткеев для всяких действий
Гибче настраиваются не хоткеи, а сам редактор.
Хоткеев не больше, просто тут нет такого определения хоткей-действие, есть действия, а на любой хоткей можно повесить любую цепочку действий, эти действия так же можно обернуть в функцию. Посмотрите тут, не так давно было на главной. Там как раз показан пример «навешивания» своего функционала на стандартную функцию сохранения + присутсвует код .vimrc, в котором вы можете посмотреть каким образом осуществляется назначение хоткеев.
Кстати, Вы пытаетесь сравнить Visual Editor и IDE, что, мягко говоря, немного разные вещи…
а что? что именно?
Спасибо за честность.
В этом вся проблема Vim'a — он не такой как все и он один.
И не смотря на все свои настройки он не покрывает все возможные случаи качественной реализацией.
Сложно сказать, но для себя я решил, что быть не таким как все, можно только в случае когда ты на голову выше других в своей области. Поэтому Vim в качестве IDE — просто удручает :( это не его сфера применения, хотя он и старается.
В этом вся проблема Vim'a — он не такой как все и он один.
И не смотря на все свои настройки он не покрывает все возможные случаи качественной реализацией.
Сложно сказать, но для себя я решил, что быть не таким как все, можно только в случае когда ты на голову выше других в своей области. Поэтому Vim в качестве IDE — просто удручает :( это не его сфера применения, хотя он и старается.
> Поэтому Vim в качестве IDE — просто удручает :( это не
> его сфера применения, хотя он и старается.
Ну так Vim и не является IDE, это тексовый редактор, просто достаточно сильно расширяемый ;)
> его сфера применения, хотя он и старается.
Ну так Vim и не является IDE, это тексовый редактор, просто достаточно сильно расширяемый ;)
Ничего не имею против него в качестве продвинутого не WYSIWYG редактора :)
Но ведь «любители» пытаются преподнести его как универсальный рецепт для всего :) это несколько раздражает :)
Но ведь «любители» пытаются преподнести его как универсальный рецепт для всего :) это несколько раздражает :)
Не, ну тут тоже зависит от способа «преподнесения». Я, например, Vim использую гораздо чаще любого другого редактора. На работе у меня он выполняет роль IDE и меня полностью устраивает. Плюс к этому когда надо работать по ssh — скопировал готовый .vimrc и каталог .vim (с плагинами и прочим) — и работаешь в привычной обстановке. Но это ведь именно меня всё устраивает, у остальных могут быть свои предпочтения. Т.е. для меня и моих задач Vim — это «универсальный рецепт», но я никого не принуждаю и не убеждаю использовать всегда и везде только этот редактор, тем более что это именно редактор, а не IDE. Остальные для себя сами выберут то, что им больше нравится. Так же я не утверждаю, что другие редакторы плохие или хотя бы хуже чем vim, просто для меня это основной редактор, а для остальных он таковым являться не обязан.
три года сижу в виме иногда и плююсь )))
редактор студии или комодо для меня удобнее намного. вы просто их не распробовали. Особенно если не пробовали Решарпер.
редактор студии или комодо для меня удобнее намного. вы просто их не распробовали. Особенно если не пробовали Решарпер.
Просто психологически тяжело на какие-то операции тратить N нажатий на клавиши, когда знаешь, что в любимом редакторе ты бы смог на это потратить в несколько раз меньше нажатий.
Не знаю поможет ли вам но вот blogs.msdn.com/rusaraford/.
В действительности почти на всё что есть в студии можно поставить хоткеи. Довавив туда мощь ReSharper и tt engine можно творить невероятные вещи.
В действительности почти на всё что есть в студии можно поставить хоткеи. Довавив туда мощь ReSharper и tt engine можно творить невероятные вещи.
Представьте что вам каждый день нужно преодолевать пару километров пути на велосипеде или пешком. Да это не узкое место дня, но думаю выбор будет очевиден.
Так же эта тема неплохо раскрыта в книге «Программист-прагматик».
Так же эта тема неплохо раскрыта в книге «Программист-прагматик».
И какой выбор? Я вот пешком хожу.
каждый день до работы три пешком, при этом регулярно накатываю на велосипеде 30, 50, 100 км в день
Представьте что вам нужно перейти улицу до работы и ваш сосед для этого использует квантовый движок с ходулями, а вы по старинке пешком.
Мифическая скорость набора текста не так важна для програмиста, потому что он не секретарь и не набирает гигантские масивы текста и под конец проэкта прыгнуть выше 10 строчек отлаженого кода в час ой как нелегко.
Мифическая скорость набора текста не так важна для програмиста, потому что он не секретарь и не набирает гигантские масивы текста и под конец проэкта прыгнуть выше 10 строчек отлаженого кода в час ой как нелегко.
Не в этом дело. Просто избавление от многих рутинных действий высвобождает время и силы на обдумывание кода и его написание.
Правда, чтобы овладеть всей мощью вима и емакса нужно так же потратить весьма немало времени(или я один такой слоупок).
Правда, чтобы овладеть всей мощью вима и емакса нужно так же потратить весьма немало времени(или я один такой слоупок).
все очень просто — непривычность нового редактора дезориентирует программиста, не дает ему делать привычные операции не задумываясь о том как это делается (т.е. вариант «на автомате» превращается в жесткий контроль действий, а это сильно отвлекает). В итоге производительность труда значительно уменьшается т.к. теряется концентрация на решении задачи из-за того, что нужно еще вспоминать как же та или иная привычная операции делается в этом новом редакторе.
Проверено на себе при поиске альтернативных Zend Studio 5 редакторов. В большинстве нет даже половины привычных операций для работы с кодом.
Проверено на себе при поиске альтернативных Zend Studio 5 редакторов. В большинстве нет даже половины привычных операций для работы с кодом.
Пока «Втупляешь» — нет, но как только «Поперло» — и мысль струится через кончики пальцев, то «да» — скорость и интуитивность печати — узкое место.
Если речь идет исключительно о том, что «непривычно» — то, видимо, придется привыкать, потому что, как видно из поста, заменить VS Vim тяжело.
Ну скорость написания останется не особо высокой, а вот скорость РЕДАКТИРОВАНИЯ будет на высоте.
это идиотизм полагать что скорость написания текста очень важна. особенно для программистов. в среднем мы пишем 50-100 строчек в день. скажите, пожалуйста, нахуй скорость тут?
Чем быстрее будет написан кусок кода, тем меньше шансов отвлечься от мысли. Да и, к тому же, рутинное написание одних и тех же фрагментов сильно надоедает
Извините но я очень давно заметил что в студии скорость написания кода давно не является ограничивающим фактором. И что нормой могут быть те самые 10 строчек в час на финальных этапах проэкта.
Vim хуже наркотика.
Как вариант — еще можно nmake (если память не изменяет) напрямую запускать вроде
извращенец
Не торопитесь называть извращением то, чего не можете понять.
получите много минусов =)
он восхищённо.
это вы не можете отвыкнуть от устаревшей технологии
С чего вы взяли, что Vim — это устаревшая технология? Например, вы в школе теоремой Пифагора пользовались? Вы знаете сколько ей лет? Она же жутко устарела! По-вашему не надо ей пользоваться?
Редактор это таки устаревшая технология в сравнении с IDE, если речь идет о программировании (а не редактировании текста).
И то и другое ездит, а по горным склонам да буеракам будет быстрее на велосипеде (vim), но на шоссе рулит феррари.
И то и другое ездит, а по горным склонам да буеракам будет быстрее на велосипеде (vim), но на шоссе рулит феррари.
То есть текстовые редакторы устарели, так же как велосипеды? Извините, но вы неправы. И, если продолжать ваше сравнение, то Vim — это такой велосипед, из которого легко можно сделать реактивный истребитель, прикрутив пару-тройку деталей.
Гм, а велосипеды разве устарели? :) Я с удовольствием ими пользуюсь :)
Просто скажем для поездки по делам в другой город или чтобы перевезти пару тонн груза — велосипед не мой выбор :)
Вот когда прикрутите и ваш истребитель будет рвать Миг-29, тогда и поговорим :)
Просто скажем для поездки по делам в другой город или чтобы перевезти пару тонн груза — велосипед не мой выбор :)
Вот когда прикрутите и ваш истребитель будет рвать Миг-29, тогда и поговорим :)
А почему Вы это не транслитом написали? Что вобще за новомодная привычка использовать кириллицу? Вон, лет 30 назад все писали и замечательные программы и посты лишь латиницу. Самые свободные OS в мире были написаны, используя английские буквы!
Писать посты по русски — так же вульгарно, как пользоваться мышью или использовать IDE вместо привычного редактора.
продолжать?
Писать посты по русски — так же вульгарно, как пользоваться мышью или использовать IDE вместо привычного редактора.
продолжать?
Интересно было бы посмотреть на список того чего вам особо не хватает в ViEmu. По мне так большую часть функционала от покрывает, а если есть желание пользоваться чем нибудь типа решарпера, так это вообще остается единственным вариантом.
На вскидку:
1) нет возможности исполнять Vim'овские скрипты и, соответственно, использовать дополнения (уже писал)
2) не работают фильтры (не помню правильное название) — когда блок текста пропускается через внешнюю программу (очень важная возможность, мне её сильно не хватает)
3) не работает команда =
4) не работают ctrl-n и ctrl-p при открытом списке автодополнения (очень раздражает)
5) не работает дополнение по tab в строке комманд
6) не открываются директории
Возможно, я что-то ещё забыл. Если знаете, как заставить работать что-нибудь из этого, буду очень благодарен, ведь в целом ViEmu — хорошая штука.
1) нет возможности исполнять Vim'овские скрипты и, соответственно, использовать дополнения (уже писал)
2) не работают фильтры (не помню правильное название) — когда блок текста пропускается через внешнюю программу (очень важная возможность, мне её сильно не хватает)
3) не работает команда =
4) не работают ctrl-n и ctrl-p при открытом списке автодополнения (очень раздражает)
5) не работает дополнение по tab в строке комманд
6) не открываются директории
Возможно, я что-то ещё забыл. Если знаете, как заставить работать что-нибудь из этого, буду очень благодарен, ведь в целом ViEmu — хорошая штука.
1) Какие наиболее критичные? Возможно у студии стоит поискать похожий функционал.
3) Это странно, по крайней мере у C# оно работает использую стандартный студийный форматер.
4) Тут можно по шаманить с autohotkey www.viemu.com/forums/viewtopic.php?id=811
что нибудь типа
^n::Down
^p::Up
5) Для тех десяти команд что там есть думаю это не критично.
6) что за директории?
3) Это странно, по крайней мере у C# оно работает использую стандартный студийный форматер.
4) Тут можно по шаманить с autohotkey www.viemu.com/forums/viewtopic.php?id=811
что нибудь типа
^n::Down
^p::Up
5) Для тех десяти команд что там есть думаю это не критично.
6) что за директории?
6) :e somedir/
Открывает буфер со списком файлов в директории, можно переместиться в строку с нужным файлом, нажать Enter, и он откроется. Можно перемещаться по каталогам. Удобный способ навигации, не выходя из vim в оболочку.
Открывает буфер со списком файлов в директории, можно переместиться в строку с нужным файлом, нажать Enter, и он откроется. Можно перемещаться по каталогам. Удобный способ навигации, не выходя из vim в оболочку.
Некое подобие есть у самой студии. Открывается Command Window набирается open и дальше набор с автокомплитом.
Это не совсем то, что имел в виду iley.
Точно такой же автокомплит есть и у vim.
Имеется в виду вот что:
Точно такой же автокомплит есть и у vim.
Имеется в виду вот что:
Привычка — страшная сила. Я вот знаю некоторых людей которые в Delphi 7 сидят и считают его лучшим IDE.
SlikEdit IDE, советую, поддерживает все известные форматы проектов IDE в том числе и VS, его редактор может эмулировать работу всех известных редакторов, в том числе VIM. Есть версия под Linux и под WIndows, и надо сказать, что в Linux это лучший IDE.
Где можно узнать поддерживается ли InntelliJ IDEA в этом IDE?
www.slickedit.com/images/stories/images/2008/emulations_small.jpg
А вообще про фичи: www.slickedit.com/content/view/353/217
Я уже посмотрел на стоимость и решил остаться на виме :)
А вообще про фичи: www.slickedit.com/content/view/353/217
Я уже посмотрел на стоимость и решил остаться на виме :)
Спасибо, обязательно посмотрю на досуге.
vim-режим там тоже недотягивает до родного
А на каком способе в итоге остановились? Что, так сказать, порекомендуете?
Касательно последнего (радикального) способа «Можно просто редактировать файлы в Vim и запускать VS вместо make только для компиляции проекта». Я думаю, в этом случае помогут консольные утилиты msbuild.exe (для проектов C#, входит в состав Microsoft .NET Framework) и vcbuild.exe (для проектов на С++, входит в состав Microsoft SDK), так как запускать Visual Studio для компиляции проекта более накладно. Кстати, при наличии vcbuild.exe msbuild.exe автоматически перенаправит компиляцию для него, если проект будет на C++.
они весьма глючно работают, особенно если есть несколько скопированных проектов, намного стабильнее запускать devenv.exe в скрытом режиме и компилить им.
вообщем если есть солюшен из 10 и более проектов, который нормально собирается в студии, вовсе не факт, что его соберет msbuild.
вообщем если есть солюшен из 10 и более проектов, который нормально собирается в студии, вовсе не факт, что его соберет msbuild.
Эмм… а студия разве не msbuild-ом собирает?
По крайней мере, солюшен — это скрипт msbuild.
По крайней мере, солюшен — это скрипт msbuild.
ага msbuild'ом, но при этом отправляет милион параметров и уточнений. Вообщем можно собирать msbuild'ом, но задача эта порой нетривиальная, уж точно не CTRL+SHIFT+B :)
Ну дык параметры вообще можно посмотреть в настройках проекта.
Почему спрашиваю — у нас просто рабочий солюшен на 15 проектов, который мы собираем на сервере с помощью msbuild, и на какие-либо проблемы я не натыкался. Вот и думаю, что за фигня.
Почему спрашиваю — у нас просто рабочий солюшен на 15 проектов, который мы собираем на сервере с помощью msbuild, и на какие-либо проблемы я не натыкался. Вот и думаю, что за фигня.
у нас была жестокая проблема с студийными проектами инсталяторов мы сделали инсталятор для x86, и потом этот проект скопировали и сделали из него для x64, так было проще всего. msbuild валился с ошибкой, как потом выяснилось из-за того, что в проект-файлах были одинаковые гуиды, а вот студия собирала это все прекрасно.
Открываете Visual Studio 2008(5) Command Prompt, переходите в папку проекта, набираете команду msbuild, запускаете — всё!
Я сравнивал производительность компиляции с помощью Visual Studio и MSBuild (из поставки Microsoft .NET Framework 3.5 SP1) одного продукта (~200 солюшенов и ~1000 проектов в сумме) — скорость компиляции с помощью MSBuild была более, чем в 1,5 раза быстрее (
к сожалению, реальные цифры привести не могу — не осталось этих данных). Около 25% проектов были с «хитрыми» PostBuild событиями. В итоге сборка проходила успешно, без ошибок. Собранная версия работала так же, как и после сборки с помощью Visual Studio.
к сожалению, реальные цифры привести не могу — не осталось этих данных). Около 25% проектов были с «хитрыми» PostBuild событиями. В итоге сборка проходила успешно, без ошибок. Собранная версия работала так же, как и после сборки с помощью Visual Studio.
Да вы просто не умеете его готовить. Создание proj-файлов — это обычное декларативное программирование на XML. Наворотить можно чего-угодно, тем более MSBuild легко расширяется новыми целями.
Вот мы, например, отправляем письмо разработчикам, что билд готов. С помощью MSBuild, ага:
Вот мы, например, отправляем письмо разработчикам, что билд готов. С помощью MSBuild, ага:
<Target Name="SendBuildMail"
DependsOnTargets="CreateBuildMail">
<!-- Send e-mail notification of the new build -->
<Mail SmtpServer="$(SmtpServer)"
To="@(Developers)"
Priority="High"
IsBodyHtml="true"
From="$(ComputerName)@$(Domain)"
Subject="$(ProductName) Build $(AppVersion) is ready for testing."
Body="@(EmailBody)"
ContinueOnError="true"/>
</Target>
они весьма глючно работают, особенно если есть несколько скопированных проектов, намного стабильнее запускать devenv.exe в скрытом режиме и компилить им.
вообщем если есть солюшен из 10 и более проектов, который нормально собирается в студии, вовсе не факт, что его соберет msbuild.
вообщем если есть солюшен из 10 и более проектов, который нормально собирается в студии, вовсе не факт, что его соберет msbuild.
они весьма глючно работают, особенно если есть несколько скопированных проектов, намного стабильнее запускать devenv.exe в скрытом режиме и компилить им.
вообщем если есть солюшен из 10 и более проектов, который нормально собирается в студии, вовсе не факт, что его соберет msbuild.
вообщем если есть солюшен из 10 и более проектов, который нормально собирается в студии, вовсе не факт, что его соберет msbuild.
Вы не считаете, что вся «мощь» vim проистекает только из привычки пользоваться именно им? Т.е. вы можете эффективно использовать предлагаемый им функционал, и поэтому пользуетесь именно им.
Но при этом, тогда как практически все современные IDE продолжают развиваться в одном русле, вы, являясь жертвой привычки, анально огораживаетесь от них, предпочитая старый инструмент и рискуя остаться без необходимых навыков, когда они, возможно, потребуются.
Т.е. ваша ошибка в том, что садясь за Visual Studio сразу же начинаются поиски старого и знакомого средства (или его замены) вместо изучения нового. В конце концов, даже если студия в итоге окажется менее удобна, вы сможете вернуться обратно на vim, но при этом уже получив опыт разработки в студии. Однако, изначально составлять предвзятое мнение о продукте (и вообще концепции всех современных IDE) — невежественно.
Но при этом, тогда как практически все современные IDE продолжают развиваться в одном русле, вы, являясь жертвой привычки, анально огораживаетесь от них, предпочитая старый инструмент и рискуя остаться без необходимых навыков, когда они, возможно, потребуются.
Т.е. ваша ошибка в том, что садясь за Visual Studio сразу же начинаются поиски старого и знакомого средства (или его замены) вместо изучения нового. В конце концов, даже если студия в итоге окажется менее удобна, вы сможете вернуться обратно на vim, но при этом уже получив опыт разработки в студии. Однако, изначально составлять предвзятое мнение о продукте (и вообще концепции всех современных IDE) — невежественно.
Вы не дочитали пост и решили написать глупость, не стыдно?
Советую вам каждый день менять хоткеи на раскладку клавиатуры, а дальше можно будет поговорить о привычке и невежестве.
Вы пользуетесь всем доступным функционалом vim, openoffice, msoffice?
Вы пользуетесь всем доступным функционалом vim, openoffice, msoffice?
зачем доходить до абсурда? Скажем так: я vim не использую, но если бы пришлось, то я бы освоил работу с ним, а не начал рыть интернеты в поисках полу-кривого плагина, повторяющего работу.
VIM отличается от других редакторов кода концепцией, так сказать.
Как бы объяснить вкратце?
Ну во-первых в редакторах кода и IDE обычно собственно редактируется код. Нажал символ он ввёлся в текст. Нажал стрелочку — курсор подвигал. Держишь шифт — выделяешь. В VIM`е есть несколько режимов: режим вставки, в котором можно вставлять текст, командный режим, в котором текст можно редактировать и перемещаться по нему и режим выделения, в котором текст можно выделить для последующего удаления/вставки.
Во-вторых работа в командном режиме как бы программируемая. Команда удаления — d. К ней добавляются модификаторы, например: d$ — удалить всё от текущего положение курсора до конца строки, d^ — от начала строки до текущего курсора dd — удалить всю строку.
А можно ещё повторить несколько команд в цикле. Написав 4dd (или d4d) удаляешь четыре строки.
В третьих всё до бесконечности автомотизируется, на любой случай жизни можно найти/написать скрипт…
Лично мне нравится работать в VIM`е. Со временем вырабатывается навык работы с редактором как с каким-то программируемым станком.
Звучит дико, не правда ли?)
Как бы объяснить вкратце?
Ну во-первых в редакторах кода и IDE обычно собственно редактируется код. Нажал символ он ввёлся в текст. Нажал стрелочку — курсор подвигал. Держишь шифт — выделяешь. В VIM`е есть несколько режимов: режим вставки, в котором можно вставлять текст, командный режим, в котором текст можно редактировать и перемещаться по нему и режим выделения, в котором текст можно выделить для последующего удаления/вставки.
Во-вторых работа в командном режиме как бы программируемая. Команда удаления — d. К ней добавляются модификаторы, например: d$ — удалить всё от текущего положение курсора до конца строки, d^ — от начала строки до текущего курсора dd — удалить всю строку.
А можно ещё повторить несколько команд в цикле. Написав 4dd (или d4d) удаляешь четыре строки.
В третьих всё до бесконечности автомотизируется, на любой случай жизни можно найти/написать скрипт…
Лично мне нравится работать в VIM`е. Со временем вырабатывается навык работы с редактором как с каким-то программируемым станком.
Звучит дико, не правда ли?)
Правильно! Зачем?..
А второй вопрос, сколько времени вы потратите на изучение среды, я не говорю конкретно о какой либо. Это может быть любая среда разработки.
Но учтите разницу между словами «освоить» и «досконально знать». И второй, немаловажный фактор — «время=деньги». Освоить можно многое, даже то, что в будущем не пригодится. Скажем так: не факт что знание другой среды разработки принесет больше финансовой выгоды нежели правильное инвестирование в «куда надо».
По вопросу о плагинах:
Есть спрос — есть предложение. Есть качественные плагины (тот же адблок к ФФ) и есть полу-кривые (приводите пример сами, что б никого не обидеть).
А второй вопрос, сколько времени вы потратите на изучение среды, я не говорю конкретно о какой либо. Это может быть любая среда разработки.
Но учтите разницу между словами «освоить» и «досконально знать». И второй, немаловажный фактор — «время=деньги». Освоить можно многое, даже то, что в будущем не пригодится. Скажем так: не факт что знание другой среды разработки принесет больше финансовой выгоды нежели правильное инвестирование в «куда надо».
По вопросу о плагинах:
Есть спрос — есть предложение. Есть качественные плагины (тот же адблок к ФФ) и есть полу-кривые (приводите пример сами, что б никого не обидеть).
Ваша ошибка в том, что вы торопитесь с выводами.
С чего вы взяли, что я не осовоил в достаточной мере VS? Я использовал её многие месяцы до того, как перешел на Vim. И ещё много разных редакторов использовал. И переодически интересуюсь новинками. А когда я встречаю какую-нибудь новую многообещающую программу (не обязательно текстовый редактор), я всегда интересуюсь её особенностями. Ну вот не нашёл я до сих пор ничего удобнее лично для меня чем Vim, хотя и не прекращаю поиски. Это по-вашему невежество?
С чего вы взяли, что я не осовоил в достаточной мере VS? Я использовал её многие месяцы до того, как перешел на Vim. И ещё много разных редакторов использовал. И переодически интересуюсь новинками. А когда я встречаю какую-нибудь новую многообещающую программу (не обязательно текстовый редактор), я всегда интересуюсь её особенностями. Ну вот не нашёл я до сих пор ничего удобнее лично для меня чем Vim, хотя и не прекращаю поиски. Это по-вашему невежество?
Держу пари, что любое, действительно нужное в реальной работе программиста действие, которое выполняется в vim за N нажатий клавиш, выполняется в связке Visual Studio 2008\2010+VAssitX\Resharper за M нажатий, где N>=M.
Без мыши? Если так, то вы проиграете пари.
Ну, с мышью, но щелчки мышью тоже считаются.
Давайте ещё пробег мышкой посчитаем ;) И введём коэффициент пересчёта, чтобы знать, скольким нажатиям клавиш соответсвует 1 метр пробега мышкой! А ещё введём дополнительную оценку на время перемещения руки с клавиатуры на мышь!
Ну, в общем, надеюсь, вы меня поняли, это всё ерунда.
Ну, в общем, надеюсь, вы меня поняли, это всё ерунда.
Хм, не понял что именно ерунда, но ок, согласен без мыши. В VS абсолютно всё или уже висит на хоткеях или может быть повешено.
Подобные сравнения — ерунда. Они не дают адекватного сравнения программ. От того, что для выполнения определённых действий нужно нажать на одну-две клавиши меньше далеко не всегда делает программу удобнее.
Впрочем, если вы по-прежнему хотите сравнивать, то пожалуйста, вот вам тривиальные жизненные примеры.
1) Сколько нажатий клавиш вам потребуется чтобы удалить 5 подряд идущих слов произвольной длины в VS? В Vim это делается в 3 нажатия (именно единичных нажатия, без фигни типа «нажать и держать пока не выделится» и без комбинаций)?
2) Сколько нажатий клавиш вам потребуется чтобы вырезать текст от текущей позиции курсора до ближайшей точки с запятой и вставить его после этой точки с запятой? В Vim — 5 единичных нажатий.
Впрочем, если вы по-прежнему хотите сравнивать, то пожалуйста, вот вам тривиальные жизненные примеры.
1) Сколько нажатий клавиш вам потребуется чтобы удалить 5 подряд идущих слов произвольной длины в VS? В Vim это делается в 3 нажатия (именно единичных нажатия, без фигни типа «нажать и держать пока не выделится» и без комбинаций)?
2) Сколько нажатий клавиш вам потребуется чтобы вырезать текст от текущей позиции курсора до ближайшей точки с запятой и вставить его после этой точки с запятой? В Vim — 5 единичных нажатий.
Студия прекращается (в плане комбинаций клавиш) в Emacs одним кликом в диалоге настроек.
Превратите мне Vim в VS… и я поверю, что он гибче чугунной шапалы.
Превратите мне Vim в VS… и я поверю, что он гибче чугунной шапалы.
Вы правы. Программу делает удобнее не это, а визуальный интерфейс, подсказки, настраиваемость и расширяемость. Ах да! Еще открытость и бесплатность, которая к стати, именно в редакторе VS присутствует, и позволяет делать такие глупости как, к примеру, addonstudio.codeplex.com/
Примеры странноватые, мне почему-то при программировании «удалять 5 слов подряд» надо редко, ну да ладно.
С мышью
Первый пример выполняется в 2 щелчка. Второй — в 4. Описать детально, или и так понятно каким образом?
С макросами
Примеры странные, мне такие действия делать не приходиться. А если бы приходилось — написал бы в студии 2 макроса (по 2 строки каждый) и запускал бы их. Каждый — одной кнопкой. И еще одна кнопка в первом для ввода количества слов, во втором — для ввода требуемого символа.
С поиском и регепсами
Делаем выделение с поиском до нужного символа и операциями удаления\вырезания\вставки. С теми же цифрами что и у вас уже можно сделать, с меньшим количеством щелчков — не знаю, надо подумать.
Примеры странноватые, мне почему-то при программировании «удалять 5 слов подряд» надо редко, ну да ладно.
С мышью
Первый пример выполняется в 2 щелчка. Второй — в 4. Описать детально, или и так понятно каким образом?
С макросами
Примеры странные, мне такие действия делать не приходиться. А если бы приходилось — написал бы в студии 2 макроса (по 2 строки каждый) и запускал бы их. Каждый — одной кнопкой. И еще одна кнопка в первом для ввода количества слов, во втором — для ввода требуемого символа.
С поиском и регепсами
Делаем выделение с поиском до нужного символа и операциями удаления\вырезания\вставки. С теми же цифрами что и у вас уже можно сделать, с меньшим количеством щелчков — не знаю, надо подумать.
Но если это рассматривать именно по теме топика, т.е. при переходе с vim на vs (или даже наоборот, неважно), то здесь выиграет по скорости тот редактор, в котором человек привык работать. Допустим в vim мне надо поменять несколько строк местами, например две строки надо сдвинуть вниз на две строки, мне не важно сколько кнопок мне надо нажать в vs, в vim'е я это сделаю в четыре нажатия — d <down> <down> p (или в пять — shift+v <down> d <down> p). Может быть в vs это можно сделать проще и быстрее, но в vim мне не надо задумываться что нажимать, я на автомате выполню нужные действия и всё. Соответственно в vs моя скорость работы будет медленнее. По мне, так нажать пять клавиш на клавиатуре, которые находятся рядом (под рукой), гораздо быстрее, чем переносить руку с клавиатуры на мышь чтобы нажатий клавиш было меньше, мышкой ведь ещё куда-то попасть надо :)
P.S. В примере комбинаций клавиш <down> можно заменить на j — чтобы действительно все клавиши были под рукой.
P.S. В примере комбинаций клавиш <down> можно заменить на j — чтобы действительно все клавиши были под рукой.
Да и вообще, удобство использования программы не заключается в количестве клавиш, которые приходится нажимать. Если вам удобно использовать Visual Studio, используйте её, бог с вами. Я пытался её использовать. Пытался до того, как начал активно использовать Vim, пытался после. Пробовал использовать разные плагины. Пробовал использовать многие другие редакторы и среды разработки помимо Vim и VS. Лично мне всё равно удобнее использовать Vim. Хоть убейте.
Visual Studio 2008\2010+VAssitX\Resharper
без примочек, VS практически не отличается по возможностям редактирования от notepad.
Что же получается? Покупаем за N баксов недешевый пакет, а потом ещё и пару плагинов для того, чтобы им наконец-то можно было пользоваться.
У меня дома стоит 2008 express без всяких томатов — нищета голоштанная а не редактор.
Microsoft Visual Studio 2008 Professional Edition $550 (мы ведь профессионалы, да?)
Visual Assist X $249.00
Resharper ~$200
Vim $0
без примочек, VS практически не отличается по возможностям редактирования от notepad.
Что же получается? Покупаем за N баксов недешевый пакет, а потом ещё и пару плагинов для того, чтобы им наконец-то можно было пользоваться.
У меня дома стоит 2008 express без всяких томатов — нищета голоштанная а не редактор.
Microsoft Visual Studio 2008 Professional Edition $550 (мы ведь профессионалы, да?)
Visual Assist X $249.00
Resharper ~$200
Vim $0
собственно, VA никаких «чудес» для редактирования не доставляет, но зато VS начинает быть похожим на IDE =)
А вы собственно компилятор не забыли? :) VS это не только софтина для редактирования исходных кодов…
Так что с Vim тут сравнение неверное.
Так что с Vim тут сравнение неверное.
ага, +1. Компилятор, дебаггер, линкер, средства разворачивания и регестрирования, всё, что в студии в меню «Tools», Source Safe, Intellisense, средства тестирования, деревья классов, ресурсов и проектов, консоль, всё, из чего состоит Team Edition и еще миллион вещей…
Мы тут сравниваем космическую станцию и велосипед. Причем те, кто умеет и любит ездить на велосипеде, почему-то считают космическую станцию более сложной, чем велосипед и более неудобной, чем велосипед. Они, конечно, правы, но стоит ли из этого делать вывод о её ненужности?
Мы тут сравниваем космическую станцию и велосипед. Причем те, кто умеет и любит ездить на велосипеде, почему-то считают космическую станцию более сложной, чем велосипед и более неудобной, чем велосипед. Они, конечно, правы, но стоит ли из этого делать вывод о её ненужности?
Консольный компилятор можно бесплатно скачать с мелкософта
Я здесь смотрю только с точки зрения редактирования.
Вместо vim можно подставить *ваш любимый редактор*
Мне, кстати, как раз наоборот, из unix тулзов нравится Emacs =))
*зажмурился*
Я здесь смотрю только с точки зрения редактирования.
Вместо vim можно подставить *ваш любимый редактор*
Мне, кстати, как раз наоборот, из unix тулзов нравится Emacs =))
*зажмурился*
Опустим Vim в дистилированную воду, а Visual Studio в серную кислоту? Или к вам опять тётя Ася приехала?
Смешно тыкать людям в лицо доллары, когда в сайта MS можно скачать VS Express. Дешевле выйдет =)
Смешно тыкать людям в лицо доллары, когда в сайта MS можно скачать VS Express. Дешевле выйдет =)
Поинт не в долларах, а в необходимости пичкать плагинами «супер-пупер» IDE чтобы вытянуть его функциональность до приемлемого уровня.
На VS Express они кстати, вроде как и не ставятся.
На VS Express они кстати, вроде как и не ставятся.
Чтобы сделать из VS Emacs надо один клик в настройках и ни одного плагина.
Плагины — это всё-таки не необходимость, а возможность. Я вот юзаю голую студию и горя не знаю. А как насчёт голого ненастроенного Vim? Тот же Emacs, судя по голосистости любителей плагинов, без них, по вашей логике, ничего не может.
Плагины — это всё-таки не необходимость, а возможность. Я вот юзаю голую студию и горя не знаю. А как насчёт голого ненастроенного Vim? Тот же Emacs, судя по голосистости любителей плагинов, без них, по вашей логике, ничего не может.
>>Чтобы сделать из VS Emacs надо один клик в настройках и ни одного плагина.
И что, там можно прямо на Emacs Lisp писать?
>> Я вот юзаю голую студию и горя не знаю.
Сочувствую =)
>>Тот же Emacs, судя по голосистости любителей плагинов, без них, по вашей логике, ничего не может.
А он и не должен что-то «мочь». Это база.
И что, там можно прямо на Emacs Lisp писать?
>> Я вот юзаю голую студию и горя не знаю.
Сочувствую =)
>>Тот же Emacs, судя по голосистости любителей плагинов, без них, по вашей логике, ничего не может.
А он и не должен что-то «мочь». Это база.
Если нет мыши — пари точно проиграете.
Если с мышью — то N и M будет примерно сопоставимо.
Другой вопрос, что двигать мышку проще (для мозга?), чем набирать многочисленные команды, которые нужно все время помнить, и при наборе которых нельзя ошибаться… Ниже я написал более обширный комментарий на эту тему.
Если с мышью — то N и M будет примерно сопоставимо.
Другой вопрос, что двигать мышку проще (для мозга?), чем набирать многочисленные команды, которые нужно все время помнить, и при наборе которых нельзя ошибаться… Ниже я написал более обширный комментарий на эту тему.
спасибо автор
Работал как с Vim, так и с массой других редакторов и IDE. Мое мнение:
1. Неоспоримое преимущество Vim — это его мощность, то есть возможность сделать большой объем работ минимумом действий. Особенно это полезно при работе с удаленным хостом, если трафик не очень…
2. Проблема Vim — он сложен в использовании. То есть, конечно, после некоторой практики (по моему опыту — минимум месяц ежедневной работы) можно довести работу с ним до довольно беглого уровня, но все равно приходится концентрироваться не только на решаемой задаче, но и на самом процессе редактирования, а вот это уже IMHO нехорошо.
Например, мне при редактировании кода намного проще и быстрее сделать не думая на полном автомате 6-7 примитивных действий в редакторе той же Visual Studio, чем 4-5 сложных действий (типа наборов команд) в Vim.
В общем, если есть выбор в чем писать код — всегда предпочитаю «не Vim», если есть такая возможность. Хотя может это только у меня такая привычка выработалась, что-ли.
1. Неоспоримое преимущество Vim — это его мощность, то есть возможность сделать большой объем работ минимумом действий. Особенно это полезно при работе с удаленным хостом, если трафик не очень…
2. Проблема Vim — он сложен в использовании. То есть, конечно, после некоторой практики (по моему опыту — минимум месяц ежедневной работы) можно довести работу с ним до довольно беглого уровня, но все равно приходится концентрироваться не только на решаемой задаче, но и на самом процессе редактирования, а вот это уже IMHO нехорошо.
Например, мне при редактировании кода намного проще и быстрее сделать не думая на полном автомате 6-7 примитивных действий в редакторе той же Visual Studio, чем 4-5 сложных действий (типа наборов команд) в Vim.
В общем, если есть выбор в чем писать код — всегда предпочитаю «не Vim», если есть такая возможность. Хотя может это только у меня такая привычка выработалась, что-ли.
дело привычки, навыков и опыта.
Поработайте на linuxOS после нескольки лет работы за windows-xx системами.
Для большего контраста попытайтесь получить нужную вам информацию (системную) через консоль.
— полная «паника».
Но когда вы привыкните — вы поймете, что будете получать (возможно сложными запросами) именно ту информацию, которая вам будет необходима.
т.е вам все равно нужен опыт работы и навыки работы.
Поработайте на linuxOS после нескольки лет работы за windows-xx системами.
Для большего контраста попытайтесь получить нужную вам информацию (системную) через консоль.
— полная «паника».
Но когда вы привыкните — вы поймете, что будете получать (возможно сложными запросами) именно ту информацию, которая вам будет необходима.
т.е вам все равно нужен опыт работы и навыки работы.
> Например, мне при редактировании кода намного проще и
> быстрее сделать не думая на полном автомате 6-7 примитивных
> действий в редакторе той же Visual Studio, чем 4-5 сложных
> действий (типа наборов команд) в Vim.
После более продолжительного времени работы в vim эти 4-5 сложных действий перестают быть сложными и выполнить их на автомате становится гораздо проще чем 6-7 примитивных в VS. Думаю, что здесь бОльшую роль играет привычка, а не сам редактор :)
P.S. Да и сложными эти действия сперва кажутся только после того, как в другом редакторе подобные «стали» примитивными ;)
> быстрее сделать не думая на полном автомате 6-7 примитивных
> действий в редакторе той же Visual Studio, чем 4-5 сложных
> действий (типа наборов команд) в Vim.
После более продолжительного времени работы в vim эти 4-5 сложных действий перестают быть сложными и выполнить их на автомате становится гораздо проще чем 6-7 примитивных в VS. Думаю, что здесь бОльшую роль играет привычка, а не сам редактор :)
P.S. Да и сложными эти действия сперва кажутся только после того, как в другом редакторе подобные «стали» примитивными ;)
Не-не-не ребята
Не путайтесь. Я в уме переможаю 4хзначные числа быстрее чем многие люди складывают 2хзначные.
Но это не значит что операция умножения стала для меня простой. Это я считаю быстрее.
Вот вам кстати реальный пример. Вспомните историю, какие у нас сейчас процессоры?
Кто-нибудь еще помнит что такое CISC и почему победил RISC?
Простые решения оказались лучше.
Не путайтесь. Я в уме переможаю 4хзначные числа быстрее чем многие люди складывают 2хзначные.
Но это не значит что операция умножения стала для меня простой. Это я считаю быстрее.
Вот вам кстати реальный пример. Вспомните историю, какие у нас сейчас процессоры?
Кто-нибудь еще помнит что такое CISC и почему победил RISC?
Простые решения оказались лучше.
Вспомните историю, какие у нас сейчас процессоры?x86-процессоры, которые мы все сейчас используем, это как раз CISC.
Ага, ага. Ну-ну :) Они были таковыми до пентиумов.
Суперскалярность это не характеристика CISC процессоров
Суперскалярность это не характеристика CISC процессоров
Суперскалярность это не характеристика CISC процессоровЛожь.
Pentium является первым CISC процессором использующим многоконвейерную архитектуру.Цитата из википедии.
Фу. Не пользуйтесь русской версией — она профанирует во многих местах.
Характеристикой CISC является наличие длинных сложных команд, которые распараллеливаются аж никак.
Поэтому, для того чтобы параллелизм работал в современных процессорах, их декодируют в набор простых инструкций (RISC) и выполняют на нескольких конвейерах (суперскалярность)
Вот вам «кошерная» википедия :)
en.wikipedia.org/wiki/Superscalar
en.wikipedia.org/wiki/X86
Current implementations
During execution, current x86 processors employ a few extra decoding steps to split most instructions into smaller pieces (micro-operations). These are then handed to a control unit that buffers and schedules them in compliance with x86-semantics so that they can be executed, partly in parallel, by one of several (more or less specialized) execution units. These modern x86 designs are thus superscalar, and also capable of out of order and speculative execution (via register renaming), which means they may execute multiple (partial or complete) x86 instructions simultaneously, and not necessarily in the same order as given in the instruction stream.
When introduced, this approach was sometimes referred to as a «RISC core» or as «RISC translation», partly for marketing reasons, but also because these micro-operations share some properties with certain types of RISC instructions. However, traditional microcode (used since the 1950s) also inherently shares many of the same properties; the new approach differs mainly in that the translation to micro-operations now occurs asynchronously. Not having to synchronize the execution units with the decode steps opens up possibilities for more analysis of the (buffered) code stream, and therefore permits detection of operations that can be performed in parallel, simultaneously feeding more than one execution unit.
The latest processors also do the opposite when appropriate; they combine certain x86 sequences (such as a compare followed by a conditional jump) into a more complex μop which fits the execution model better and thus can be executed faster or with less machine resources involved.
Another way to try to improve performance is to cache the decoded micro-operations, so the processor can directly access the decoded micro-operations from a special cache, instead of decoding them again. The Execution Trace Cache found in Intel's NetBurst Microarchitecture (Pentium 4) is so far the only widespread example of this technique.
Transmeta use a completely different method in their x86 compatible CPUs. They use just-in-time translation to convert x86 instructions to the CPU's native instructions. Transmeta argues that their approach allows for more power efficient designs since the CPU can forgo the complicated decode step of more traditional x86 implementations.
Характеристикой CISC является наличие длинных сложных команд, которые распараллеливаются аж никак.
Поэтому, для того чтобы параллелизм работал в современных процессорах, их декодируют в набор простых инструкций (RISC) и выполняют на нескольких конвейерах (суперскалярность)
Вот вам «кошерная» википедия :)
en.wikipedia.org/wiki/Superscalar
en.wikipedia.org/wiki/X86
Current implementations
During execution, current x86 processors employ a few extra decoding steps to split most instructions into smaller pieces (micro-operations). These are then handed to a control unit that buffers and schedules them in compliance with x86-semantics so that they can be executed, partly in parallel, by one of several (more or less specialized) execution units. These modern x86 designs are thus superscalar, and also capable of out of order and speculative execution (via register renaming), which means they may execute multiple (partial or complete) x86 instructions simultaneously, and not necessarily in the same order as given in the instruction stream.
When introduced, this approach was sometimes referred to as a «RISC core» or as «RISC translation», partly for marketing reasons, but also because these micro-operations share some properties with certain types of RISC instructions. However, traditional microcode (used since the 1950s) also inherently shares many of the same properties; the new approach differs mainly in that the translation to micro-operations now occurs asynchronously. Not having to synchronize the execution units with the decode steps opens up possibilities for more analysis of the (buffered) code stream, and therefore permits detection of operations that can be performed in parallel, simultaneously feeding more than one execution unit.
The latest processors also do the opposite when appropriate; they combine certain x86 sequences (such as a compare followed by a conditional jump) into a more complex μop which fits the execution model better and thus can be executed faster or with less machine resources involved.
Another way to try to improve performance is to cache the decoded micro-operations, so the processor can directly access the decoded micro-operations from a special cache, instead of decoding them again. The Execution Trace Cache found in Intel's NetBurst Microarchitecture (Pentium 4) is so far the only widespread example of this technique.
Transmeta use a completely different method in their x86 compatible CPUs. They use just-in-time translation to convert x86 instructions to the CPU's native instructions. Transmeta argues that their approach allows for more power efficient designs since the CPU can forgo the complicated decode step of more traditional x86 implementations.
Прохожу по вашей ссылке en.wikipedia.org/wiki/X86
Вижу в самом начале: «Design: CISC». Дальнейшее обсуждение бессмысленно.
Вижу в самом начале: «Design: CISC». Дальнейшее обсуждение бессмысленно.
Я уже не удивлен почему вы пользуетесь vim…
Правда для того чтобы понимать чем CISC отличается от RISC, и почему первый сложно или невозможно распараллелить.
Для всего этого нужны мозги. Видимо изучение команд vim съедает все ваши вычислительные ресурсы. Отвлекитесь немного, я вас очень прошу. И подумайте над текстом ниже.
When introduced, this approach was sometimes referred to as a «RISC core» or as «RISC translation», partly for marketing reasons, but also because these micro-operations share some properties with certain types of RISC instructions. However, traditional microcode (used since the 1950s) also inherently shares many of the same properties; the new approach differs mainly in that the translation to micro-operations now occurs asynchronously. Not having to synchronize the execution units with the decode steps opens up possibilities for more analysis of the (buffered) code stream, and therefore permits detection of operations that can be performed in parallel, simultaneously feeding more than one execution unit.
Правда для того чтобы понимать чем CISC отличается от RISC, и почему первый сложно или невозможно распараллелить.
Для всего этого нужны мозги. Видимо изучение команд vim съедает все ваши вычислительные ресурсы. Отвлекитесь немного, я вас очень прошу. И подумайте над текстом ниже.
When introduced, this approach was sometimes referred to as a «RISC core» or as «RISC translation», partly for marketing reasons, but also because these micro-operations share some properties with certain types of RISC instructions. However, traditional microcode (used since the 1950s) also inherently shares many of the same properties; the new approach differs mainly in that the translation to micro-operations now occurs asynchronously. Not having to synchronize the execution units with the decode steps opens up possibilities for more analysis of the (buffered) code stream, and therefore permits detection of operations that can be performed in parallel, simultaneously feeding more than one execution unit.
Ах, вы уже перешли к личным оскорблениям! Я так и знал, что вы не способны поддерживать нормальную дискуссию.
Признайте уже свою ошибку. Каково бы не было внутреннее устройство процессора, строго говоря x86 являются CISC-процессорами. Ведь что по определению значит RISC? RISC — это Reduced Instruction Set Computing. А любой мало-мальски грамотный программист скажет вам, что набор инструкций 86-го и всех его потомков никак нельзя назвать сокращённым. И совершенно неважно, каким образом происходит исполнение инструкций и транслируются ли они в другой набор команд. С точки зрения программиста и с точки зрения общепринятого определения x86 являются CISC-процессорами.
P.S. Жду извинений.
Признайте уже свою ошибку. Каково бы не было внутреннее устройство процессора, строго говоря x86 являются CISC-процессорами. Ведь что по определению значит RISC? RISC — это Reduced Instruction Set Computing. А любой мало-мальски грамотный программист скажет вам, что набор инструкций 86-го и всех его потомков никак нельзя назвать сокращённым. И совершенно неважно, каким образом происходит исполнение инструкций и транслируются ли они в другой набор команд. С точки зрения программиста и с точки зрения общепринятого определения x86 являются CISC-процессорами.
P.S. Жду извинений.
Извините, есть тип людей которых я на дух не переношу — это узколобые. Поэтому с вами у меня дискуссии не будет вовсе.
Любой мало-мальский грамотный специалист знает, что x86 БЫЛИ CISC.
А так же знает что такое backward compatibility и почему несмотря на внутреннее изменение архитектуры остался все тот же набор инструкций.
Так что, стена там ->
Всего вам наилучшего.
Любой мало-мальский грамотный специалист знает, что x86 БЫЛИ CISC.
А так же знает что такое backward compatibility и почему несмотря на внутреннее изменение архитектуры остался все тот же набор инструкций.
Так что, стена там ->
Всего вам наилучшего.
> Любой мало-мальский грамотный специалист знает, что x86 БЫЛИ CISC.
Все правильно, мы это еще в 1997 году в институте разбирали детально.
Уже начиная со старших четверок стала использоваться RISC архитектура, но для совместимости оставлен командный интерфейс CISC (в комменте ниже я привел ссылку из русской википедии).
Но хочу заметить, что в принципе не будет ошибкой x86 назвать CISC процессорами, так как интерфейс определяет. Более корректно современные x86 называть: CISC процессоры с RISC ядром ))
Все правильно, мы это еще в 1997 году в институте разбирали детально.
Уже начиная со старших четверок стала использоваться RISC архитектура, но для совместимости оставлен командный интерфейс CISC (в комменте ниже я привел ссылку из русской википедии).
Но хочу заметить, что в принципе не будет ошибкой x86 назвать CISC процессорами, так как интерфейс определяет. Более корректно современные x86 называть: CISC процессоры с RISC ядром ))
Да бог с ней с корректностью и справедливостью.
Можно чего-то не знать (я например не знал), что RISC появился в х86 с 486й модели.
Но, будучи «не в теме», кричать «ложь». А потом не удосужиться прочитать подсунутый под нос текст…
Ему не важно RISC или CISC архитектура внутри. Ему важно опровергнуть.
Если человек хочет ничего не знать и быть дураком — пусть будет. Но я таких не перевариваю.
P.S. А насчет «интерфейс определяет» :) я бы с трансвеститами спать не стал бы :) не взирая на «интерфейс» :)
Можно чего-то не знать (я например не знал), что RISC появился в х86 с 486й модели.
Но, будучи «не в теме», кричать «ложь». А потом не удосужиться прочитать подсунутый под нос текст…
Ему не важно RISC или CISC архитектура внутри. Ему важно опровергнуть.
Если человек хочет ничего не знать и быть дураком — пусть будет. Но я таких не перевариваю.
P.S. А насчет «интерфейс определяет» :) я бы с трансвеститами спать не стал бы :) не взирая на «интерфейс» :)
>> Уже начиная со старших четверок стала использоваться RISC архитектура
Вы наверное путаете RISC-овость с конвееризорованностью или суперскалярностью =)
Что 486, что P5 были 100% CISC.
Первый x86 процессор с RISC бэкэндом был AMD K5.
Вы наверное путаете RISC-овость с конвееризорованностью или суперскалярностью =)
Что 486, что P5 были 100% CISC.
Первый x86 процессор с RISC бэкэндом был AMD K5.
x86 были и остаются CISC.
И вы хот тресните но не получите доступ к внутренней машине, которая давно уже и не RISC потому что там есть ещё SIMD инструкции. Что там внутри не ваше дело пока вы не поучите доступа к внутренностям.
Если уж и говорить о победителях то Itanium и Crusoe это вообще VLIW-архитектура, и в свете дивжения к многоядерности скорее всего VLIW или то что придёт на её смену победит.
И вы хот тресните но не получите доступ к внутренней машине, которая давно уже и не RISC потому что там есть ещё SIMD инструкции. Что там внутри не ваше дело пока вы не поучите доступа к внутренностям.
Если уж и говорить о победителях то Itanium и Crusoe это вообще VLIW-архитектура, и в свете дивжения к многоядерности скорее всего VLIW или то что придёт на её смену победит.
Гм. Я не гуру микроэлектроники, но вы уверены, что SIMD и иже с ними, точно так же не транслируются в RISC код? :) Я например, этого не знаю.
Но я точно знаю, что CISC не позволяют нормально распараллеливать задачи.
Весь их цимес в том, что команды сложные и выполняют сложные действия, которые не встречаются в задачах в больших количествах.
А VLIW как раз и занят тем, что распараллеливает задачи еще на этапе «до» процессора. Потому у него и команды длиннее чем у RISC.
Но я точно знаю, что CISC не позволяют нормально распараллеливать задачи.
Весь их цимес в том, что команды сложные и выполняют сложные действия, которые не встречаются в задачах в больших количествах.
А VLIW как раз и занят тем, что распараллеливает задачи еще на этапе «до» процессора. Потому у него и команды длиннее чем у RISC.
Я вообще не об этом. Есть архитектура х86, она представляет вам некоторый интерфейс и он как раз CISC и за влезть внутри него вы не сможете.
Возьмём Crusoe — VLIW-архитектура и что теперь x86 назвём VLIW архитектурой (хотя SSE инструкции имеют некоторую схожесть)?
>Но я точно знаю, что CISC не позволяют нормально распараллеливать задачи.
Core 2 Duo, Pentium как-то это делают? так о чём тогда речь.
А вообще не надо меня учить архитектуре потому что я сам кого хочешь научу. На VHDL и Verilog не одно ядро написано и успешно используется.
Суть такова что чистый RISC сейчас наверное остался у одних PIC-ов в больших машинах нужны более сложные решерния, как только появляются мультимедиа даные, шифровка ака «перемалыватели чисел» тут чистые RISC-и начинают сливать и создаются гибридные решения, добавляют разные «ускорители» (AltiVec и подобные). Но смотреть на баталии людей для которых это интерес чисто теоретический, а тем более если брать Intel-овскую продукцию, то сохраняя х86 систему команд эти товарищи сменили несколько внутренних архитектур и остальным пользователям это по большему счету это пофигу, пока их удовлетворяет скорость исполнения их х86 кода.
Возьмём Crusoe — VLIW-архитектура и что теперь x86 назвём VLIW архитектурой (хотя SSE инструкции имеют некоторую схожесть)?
>Но я точно знаю, что CISC не позволяют нормально распараллеливать задачи.
Core 2 Duo, Pentium как-то это делают? так о чём тогда речь.
А вообще не надо меня учить архитектуре потому что я сам кого хочешь научу. На VHDL и Verilog не одно ядро написано и успешно используется.
Суть такова что чистый RISC сейчас наверное остался у одних PIC-ов в больших машинах нужны более сложные решерния, как только появляются мультимедиа даные, шифровка ака «перемалыватели чисел» тут чистые RISC-и начинают сливать и создаются гибридные решения, добавляют разные «ускорители» (AltiVec и подобные). Но смотреть на баталии людей для которых это интерес чисто теоретический, а тем более если брать Intel-овскую продукцию, то сохраняя х86 систему команд эти товарищи сменили несколько внутренних архитектур и остальным пользователям это по большему счету это пофигу, пока их удовлетворяет скорость исполнения их х86 кода.
Они держат у себя RISC ядро :) которое и занимается параллельным выполнением.
AIX не станет Linux только потому что он POSIX-совместим. У бензинового и дизельного двигателя тоже одинаковый интерфейс :) но вот внутри они разные.
P.S. А VLIW это случайно не дальнейшее развитие идеологии RISC?
P.P.S. А абсолютно «чистые» вещи — это сферические кони в вакууме.
AIX не станет Linux только потому что он POSIX-совместим. У бензинового и дизельного двигателя тоже одинаковый интерфейс :) но вот внутри они разные.
P.S. А VLIW это случайно не дальнейшее развитие идеологии RISC?
P.P.S. А абсолютно «чистые» вещи — это сферические кони в вакууме.
Главное вообще-то я вообще не нашол у Intel указания что то что у них внутри RISC архитектура, если общие слова про декодирование на uOPs(микрооперации) и про Гарвардскую архитектуру. Класичечская RISC-архитектура, которая впрочем была реализирована в одиночных процесорах, предполагает одноцыкловые операции в том числе и ветвления, что в случае с Pentium невозможно. Да там есть все черты RISC но наличие SSE всё ламает, потому что этот блок выгоднее реализировать иначе. Кстати если гуглить по интелу, то RISC можно втретить только в противопоставлении их архитектуре.
Хенесси и Паттерсон которые заслужено считаются чем-то вроде Кнута в мире Компъютерной архитектуры относят большинство современных процесоров к пост-RISC (например IBM Power).
VLIW и RISC это ортогональные решения. Взгяд на проблему с другого угла. RISC пытается исполнить больше за счёт меньших операций, это распаралеливание во времени, VLIW в пространстве.
Есть много успешных VLIW процесоров, но сказать что они суперуспешны пока нельзя. Никто из них не смог взять рынок. Crusoe, Itanium, AD SHARC — заняли ниши, но мэйнстримом не стали.
Хенесси и Паттерсон которые заслужено считаются чем-то вроде Кнута в мире Компъютерной архитектуры относят большинство современных процесоров к пост-RISC (например IBM Power).
VLIW и RISC это ортогональные решения. Взгяд на проблему с другого угла. RISC пытается исполнить больше за счёт меньших операций, это распаралеливание во времени, VLIW в пространстве.
Есть много успешных VLIW процесоров, но сказать что они суперуспешны пока нельзя. Никто из них не смог взять рынок. Crusoe, Itanium, AD SHARC — заняли ниши, но мэйнстримом не стали.
Цитирую ru.wikipedia.org/wiki/CISC
Формально, все х86-процессоры являлись CISC-процессорами, однако новые процессоры, начиная с Intel486DX, являются CISC-процессорами с RISC-ядром. Они непосредственно перед исполнением преобразуют CISC-инструкции процессоров x86 в более простой набор внутренних инструкций RISC.
В микропроцессор встраивается аппаратный транслятор, превращающий команды x86 в команды внутреннего RISC-процессора. При этом одна команда x86 может порождать несколько RISC-команд (в случае процессоров типа P6 — до 4-х RISC команд в большинстве случаев). Исполнение команд происходит на суперскалярном конвейере одновременно по несколько штук.
Формально, все х86-процессоры являлись CISC-процессорами, однако новые процессоры, начиная с Intel486DX, являются CISC-процессорами с RISC-ядром. Они непосредственно перед исполнением преобразуют CISC-инструкции процессоров x86 в более простой набор внутренних инструкций RISC.
В микропроцессор встраивается аппаратный транслятор, превращающий команды x86 в команды внутреннего RISC-процессора. При этом одна команда x86 может порождать несколько RISC-команд (в случае процессоров типа P6 — до 4-х RISC команд в большинстве случаев). Исполнение команд происходит на суперскалярном конвейере одновременно по несколько штук.
> Не путайтесь. Я в уме переможаю 4хзначные числа быстрее чем многие люди
> складывают 2хзначные.
> Но это не значит что операция умножения стала для меня простой. Это я считаю быстрее.
Сравнили опу с пальцем :)
Ну здесь сравнивается немного другое. Под примитивным действием пордразумевается одиночное нажатие хоткея, под сложными — несколько нажатий, т.е. несколько «примитивных» действий. Т.о. действий-то примерно одинаковое количество, просто разное отношение к ним.
> складывают 2хзначные.
> Но это не значит что операция умножения стала для меня простой. Это я считаю быстрее.
Ну здесь сравнивается немного другое. Под примитивным действием пордразумевается одиночное нажатие хоткея, под сложными — несколько нажатий, т.е. несколько «примитивных» действий. Т.о. действий-то примерно одинаковое количество, просто разное отношение к ним.
Нет нет, простите. Вы может и о другом, но я об этом
> но все равно приходится концентрироваться не только на решаемой задаче, но и на самом процессе редактирования
Речь идет о командах вроде 'd4d'. Да это супер удобно. Особенно когда приходится «лопатить» огромный массив текста.
И Search&Replace тоже позволяет делать рефакторинг кода. Причем можно даже немного «извратиться» и написать макрос, который будет по определенным правилам обходить все классы проекта избегая замен в ресурсах например.
Ковырятся в логах, дампах несомннено лучше не в IDE. Но это немного другая работа — это не программирование.
Человек конечно до определенной степени многозадачен, но лишь до определенной степени. (да это тренируется, но у всех по-разному)
Например, жать Shift+Ctrl+Right можно параллельно раздумывая над функцией. Когда я достигну нужного места либо подождать и закончить мысль, либо если я свободен сразу принять решение, что мне теперь делать с выделенным текстом.
В случае команды этот номер не пройдет. Мне надо будет отвлечся, принять решение и ввести команду. Да, это выполнится быстрее.
Но вот делать что-то другое в это время достаточно сложно. Думать две мысли сразу :) это я вам скажу задачка еще та.
> но все равно приходится концентрироваться не только на решаемой задаче, но и на самом процессе редактирования
Речь идет о командах вроде 'd4d'. Да это супер удобно. Особенно когда приходится «лопатить» огромный массив текста.
И Search&Replace тоже позволяет делать рефакторинг кода. Причем можно даже немного «извратиться» и написать макрос, который будет по определенным правилам обходить все классы проекта избегая замен в ресурсах например.
Ковырятся в логах, дампах несомннено лучше не в IDE. Но это немного другая работа — это не программирование.
Человек конечно до определенной степени многозадачен, но лишь до определенной степени. (да это тренируется, но у всех по-разному)
Например, жать Shift+Ctrl+Right можно параллельно раздумывая над функцией. Когда я достигну нужного места либо подождать и закончить мысль, либо если я свободен сразу принять решение, что мне теперь делать с выделенным текстом.
В случае команды этот номер не пройдет. Мне надо будет отвлечся, принять решение и ввести команду. Да, это выполнится быстрее.
Но вот делать что-то другое в это время достаточно сложно. Думать две мысли сразу :) это я вам скажу задачка еще та.
Согласен.
Например переместить блок текста — выделить мышкой, и мышкой же перетащить. Это очень часто используемая в работе операция может делаться вообще без нажатий клавиш на клавиатуре. Что может быть проще, и никакого напряга для мозга, так как все что делается — полностью визуально.
А вот в Vim — действительно придется отвлечься от работы над задачей на ввод команд, в которых помимо всего прочего запросто можно ошибиться, если пытаться это делать на автомате.
Например переместить блок текста — выделить мышкой, и мышкой же перетащить. Это очень часто используемая в работе операция может делаться вообще без нажатий клавиш на клавиатуре. Что может быть проще, и никакого напряга для мозга, так как все что делается — полностью визуально.
А вот в Vim — действительно придется отвлечься от работы над задачей на ввод команд, в которых помимо всего прочего запросто можно ошибиться, если пытаться это делать на автомате.
Не соглашусь. Каждому своё, да и привычка — вещь та ещё. Когда я кодю, то у меня обе руки на клавиатуре и мне гораздо проще нажать пару клавиш, чем переносить руку на мышку, «находить» курсор, целиться, чтобы не выделить ничего лишнего (если переносить не строки целиком) и дальше уже переносить текст. Если Вы постоянно подобное действие выполняете мышью, то Вам так и удобнее. Но тем кто постоянно работает в vim'е, на ввод команд отвлекаться не приходится и ошибки в командах если и допускаются то достаточно редко и никакого вреда не наносят.
Но при этом я и от мыши не отказываюсь. Каждой задаче своё решение — если мне надо скопировать небольшой кусок кода где-то вверху экрана, а курсор в самом низу, то тут быстрее будет мышкой выделить нужный кусок и сразу нажать middleButton, чем вести курсор наверх.
Но при этом я и от мыши не отказываюсь. Каждой задаче своё решение — если мне надо скопировать небольшой кусок кода где-то вверху экрана, а курсор в самом низу, то тут быстрее будет мышкой выделить нужный кусок и сразу нажать middleButton, чем вести курсор наверх.
Позвольте не поверить…
Введение команды требует определенного вычислительного процесса.
В вашем примере с выделением и удалением слов/строк, я должен как минимум сосчитать, скомпоновать нужную команду и ввести ее (3 операции)
В моем случае принимается лишь решение о действии и стоп-точке внимания. (2 операции).
При этом особенность мышления еще и в том, что процесс переключения между операциями достаточно трудоемок.
Есть простой пример, который позволяет увидеть это :)
Когда вы будете программировать алгоритм, попросите кого-то чтобы он каждые 2-3 минуты обращался к вам с простейшими вопросами, ответ на которые у вас в обычном случае занял бы не больше 5 секунд.
Во-первых, вы отвечать будете дольше 5ти секунд :)
Во-вторых, на выполнение вашей основной задачи вам потребуется существенно больше времени, даже за вычетом времени на ответы.
В моем случае это приводило к 1.5-2хкратной потере производительности.
Это достаточно сложно, но если занятся самоанализом вы сможете видеть свои поступки до мелчайших деталей и даже вести «профайлинг» :)
Введение команды требует определенного вычислительного процесса.
В вашем примере с выделением и удалением слов/строк, я должен как минимум сосчитать, скомпоновать нужную команду и ввести ее (3 операции)
В моем случае принимается лишь решение о действии и стоп-точке внимания. (2 операции).
При этом особенность мышления еще и в том, что процесс переключения между операциями достаточно трудоемок.
Есть простой пример, который позволяет увидеть это :)
Когда вы будете программировать алгоритм, попросите кого-то чтобы он каждые 2-3 минуты обращался к вам с простейшими вопросами, ответ на которые у вас в обычном случае занял бы не больше 5 секунд.
Во-первых, вы отвечать будете дольше 5ти секунд :)
Во-вторых, на выполнение вашей основной задачи вам потребуется существенно больше времени, даже за вычетом времени на ответы.
В моем случае это приводило к 1.5-2хкратной потере производительности.
Это достаточно сложно, но если занятся самоанализом вы сможете видеть свои поступки до мелчайших деталей и даже вести «профайлинг» :)
Вы слишком по-разному относитесь к вводу команд в IDE и в Vim. На всякий случай напомню, мы тут не сравниваем никакие редакторы и среды разработки.
> В вашем примере с выделением и удалением слов/строк, я должен как
> минимум сосчитать, скомпоновать нужную команду и ввести ее (3 операции)
> В моем случае принимается лишь решение о действии и стоп-точке
> внимания. (2 операции).
Посадите за компьютер человека, мало знакомого с компьютерами, и предложите ему поработать с текстом, попереносить строки/слова, записать под диктовку небольшой текст — Вы сразу увидите сколько на самом деле действий приходится выполнять для этих вроде бы простых действий. Точно так же надо нажимать определённые клавиши на клавиатуре и в определённом порядке, просто Вы этим пользуетесь постоянно и выполняете эти действия на автомате, не отвлекаясь на них. В других редакторах тоже надо нажимать определённые клавиши, просто надо нажимать немного другие клавиши и в другом порядке, и к ним так же просто привыкнуть, чтобы выполнять основные действия на автомате.
> В вашем примере с выделением и удалением слов/строк, я должен как
> минимум сосчитать, скомпоновать нужную команду и ввести ее (3 операции)
> В моем случае принимается лишь решение о действии и стоп-точке
> внимания. (2 операции).
Посадите за компьютер человека, мало знакомого с компьютерами, и предложите ему поработать с текстом, попереносить строки/слова, записать под диктовку небольшой текст — Вы сразу увидите сколько на самом деле действий приходится выполнять для этих вроде бы простых действий. Точно так же надо нажимать определённые клавиши на клавиатуре и в определённом порядке, просто Вы этим пользуетесь постоянно и выполняете эти действия на автомате, не отвлекаясь на них. В других редакторах тоже надо нажимать определённые клавиши, просто надо нажимать немного другие клавиши и в другом порядке, и к ним так же просто привыкнуть, чтобы выполнять основные действия на автомате.
Это не я по-разному к ним отношусь, это они (подходы) разные.
Вопрос не в том что надо нажимать клавиши. Вопрос в том, как это организовано.
Мерять вот тут я 15ть раз нажал клавишу, а тут 5 — конечно можно. Но несколько бесполезно.
Мы же не скорость печати хотим сравнить.
Вы заикнулись, что лично вам Vim удобнее для программирования. Не редактирования текста, а именно программирования.
Это важный момент.
Я же вам пытаюсь показать, что он вам удобнее лишь потому, что вы привыкли. Если привычку выбросить, то алгоритм работы с ним менее эффективен.
Опять же повторюсь, для невизуальной обработки больших объемов информации он наверняка будет более эффективен. Но не для длительного процесса программирования.
Уже сам подход в виде нескольких режимов несет некоторый оверхед. Точно также с нынешней многооконностью. (это не имеет отношения к vim, просто чтобы вы поняли о чем я говорю :) )
Да, классно, можно Alt-Tab переключаться между документами, столами и т.д. и т.п., но это переключение внимания в том числе. Когда у тебя все помещается в поле зрения — это намного эффективнее.
Вопрос не в том что надо нажимать клавиши. Вопрос в том, как это организовано.
Мерять вот тут я 15ть раз нажал клавишу, а тут 5 — конечно можно. Но несколько бесполезно.
Мы же не скорость печати хотим сравнить.
Вы заикнулись, что лично вам Vim удобнее для программирования. Не редактирования текста, а именно программирования.
Это важный момент.
Я же вам пытаюсь показать, что он вам удобнее лишь потому, что вы привыкли. Если привычку выбросить, то алгоритм работы с ним менее эффективен.
Опять же повторюсь, для невизуальной обработки больших объемов информации он наверняка будет более эффективен. Но не для длительного процесса программирования.
Уже сам подход в виде нескольких режимов несет некоторый оверхед. Точно также с нынешней многооконностью. (это не имеет отношения к vim, просто чтобы вы поняли о чем я говорю :) )
Да, классно, можно Alt-Tab переключаться между документами, столами и т.д. и т.п., но это переключение внимания в том числе. Когда у тебя все помещается в поле зрения — это намного эффективнее.
>Вы заикнулись, что лично вам Vim удобнее для программирования.
Да, где-то выше писал, что он удобнее лично для меня, я не утверждаю лучше он или хуже других редакторов, просто для меня он наиболее удобный.
>Я же вам пытаюсь показать, что он вам удобнее лишь потому, что вы привыкли.
Я пытаюсь объяснить то же самое :) Принцип работы редакторов очень похож. Vim здесь выделился своим нестандартным подходом :), но основа вся та же. Кто-то в силу привычки не отвлекаясь от задачи и не глядя на клавиатуру жмёт Ctrl+C, Ctrl+V, Ctrl+F, Ctrl+H, я точно так же жму, но Y, P, /, :%s (ну можно ко всем добавить ещё Esc в начало). Переход между режимами для меня не что иное, как то же нажатие хоткеев в определённой последовательности, я совершенно не думаю, что вот сейчас мне надо перейти в командный режим, потом нажать что-то, потом выделить текст, потом опять что-то нажать чтобы скопировать, я просто жму Esc, V, выделяю, Y. Большинство в других неVim-редакторах так же выполнят не задумываясь — зажмут Shift, выделят текст (клавишами-срелками), отпустят Shift, нажмут Ctrl+C. Как видите разница только в нажимаемых клавишах. Подходы-то у редакторов разные, но многое зависит от того как к ним относиться. Вы разделяете их на различные сущности, которые надо обязательно брать в расчёт при выполнении какого-либо действия, а я просто добавляю к хоткеям Esc, если нахожусь в режиме редактирования когда мне надо нажать хоткей.
Я не спроста привёл пример про не особо компьютернограмотного человека — по предыдущим работам достаточно много общался с таковыми. Я уверен, что если любого из них посадить за Vim для редактирования и не забивая голову написать коротенькую инструкцию, как пользоваться, например «для копирования текста нажмите Esc, Y», то через какое-то время они будут использовать этот приём не задумываясь… точно так же как если бы было написано «для копирования текста нажмите Ctrl+C» ;)
Я прекрасно понимаю чего Вы пытаетесь мне объяснить и понимаю Ваше отношение к редакторам, но я ведь не только Vim'ом пользовался, успел много разных редакторов попробовать. В Windows «моим» редактором был EmEditor, нравился за свою легковесность, скорость, поиск с регулярками и т.д. С Vim до нынешнего трудоустройства общался крайне редко — только когда в linux надо было что-то в консоли сделать и по-другому никак, да и не знал я других редакторов :) Но вот появилась необходимость работать в vim'е, т.е. можно было и как-то по-своему, но я никогда не против познакомиться с чем-то новым для меня. Долгое время я пользовался vim'ом с чужими настройками (поделились, чтобы не на голом vim'е мне сидеть), пользовался сперва так больше по необходимости, потом привык к нему, научился так же не глядя выполнять копирование и прочие наиболее распространённые операции. Уже потом стал заглядывать с настройки, разбираться и подстраивать под себя. Сейчас это основной редактор для меня. И на работе я всё делаю им, либо по ssh удалённо, либо монтирую файловую систему и работаю с файлами как бы локально, но всё равно через vim.
Просто я иначе отношусь к его режимам, я знаю что они есть, но я на них не заморачиваюсь, просто использую другие хоткеи, нежели в windows.
Итого «пообщавшись» с разными редакторами для меня наиболее удобным оказался Vim, я не вижу каких-то кардинальных различий в применении хоткеев, просто они другие. Ведь в других редакторах хоткеи нажимаются в паре с Ctrl/Alt/Shift (и их комбинации), а тут вместо функциональных клавиш сперва нажимается Esc, а дальше уже сами «хоткеи». Vim'ом можно пользоваться и как обычным редактором, только хоткеи другие, а можно со временем подружиться и с более продвинутыми его возможностями, ну а дальше использовать их по желанию. Единственный, на мой взгляд, основной минус данного редактора — высокий порог вхождения, так как заимев привычку по другим редакторам подружиться с ним получается не сразу.
В общем если в двух словах, то я выбрал vim после того, как поработал с разными редакторами, поэтому на этот счёт у меня определённое мнение, которое сравнением различий в хоткеях не изменить ;). Я им пользуюсь так же как раньше пользовался другими редакторами, а использую именно его, потому что при том же удобстве использования он имеет больше возможностей. Только вот удобство при работе с ним приходит далеко не сразу :). Если до этого места кто-нибудь дочитает, то поясняю — этим текстом я не пытаюсь доказать чего-то по поводу Vim'а, а просто поясняю своё мнение и отношение к данному редактору, ну и поясняю что он не хуже многих других редакторов.
P.S. Если бы не надобность по работе пользоваться vim'ом, то я бы им и не начал активно пользоваться и не знал бы про его возможности, но научившись им нормально пользоваться я стараюсь пользоваться именно им.
> Да, классно, можно Alt-Tab переключаться между документами,
> столами и т.д. и т.п., но это переключение внимания в том числе
Согласен, гораздо удобнее два монитора, чем один большой, в котором надо постоянно переключаться между окнами :)
Надеюсь, я смог пояснить своё восприятие данного редактора и отношение к нему данным изложением мысли…
Да, где-то выше писал, что он удобнее лично для меня, я не утверждаю лучше он или хуже других редакторов, просто для меня он наиболее удобный.
>Я же вам пытаюсь показать, что он вам удобнее лишь потому, что вы привыкли.
Я пытаюсь объяснить то же самое :) Принцип работы редакторов очень похож. Vim здесь выделился своим нестандартным подходом :), но основа вся та же. Кто-то в силу привычки не отвлекаясь от задачи и не глядя на клавиатуру жмёт Ctrl+C, Ctrl+V, Ctrl+F, Ctrl+H, я точно так же жму, но Y, P, /, :%s (ну можно ко всем добавить ещё Esc в начало). Переход между режимами для меня не что иное, как то же нажатие хоткеев в определённой последовательности, я совершенно не думаю, что вот сейчас мне надо перейти в командный режим, потом нажать что-то, потом выделить текст, потом опять что-то нажать чтобы скопировать, я просто жму Esc, V, выделяю, Y. Большинство в других неVim-редакторах так же выполнят не задумываясь — зажмут Shift, выделят текст (клавишами-срелками), отпустят Shift, нажмут Ctrl+C. Как видите разница только в нажимаемых клавишах. Подходы-то у редакторов разные, но многое зависит от того как к ним относиться. Вы разделяете их на различные сущности, которые надо обязательно брать в расчёт при выполнении какого-либо действия, а я просто добавляю к хоткеям Esc, если нахожусь в режиме редактирования когда мне надо нажать хоткей.
Я не спроста привёл пример про не особо компьютернограмотного человека — по предыдущим работам достаточно много общался с таковыми. Я уверен, что если любого из них посадить за Vim для редактирования и не забивая голову написать коротенькую инструкцию, как пользоваться, например «для копирования текста нажмите Esc, Y», то через какое-то время они будут использовать этот приём не задумываясь… точно так же как если бы было написано «для копирования текста нажмите Ctrl+C» ;)
Я прекрасно понимаю чего Вы пытаетесь мне объяснить и понимаю Ваше отношение к редакторам, но я ведь не только Vim'ом пользовался, успел много разных редакторов попробовать. В Windows «моим» редактором был EmEditor, нравился за свою легковесность, скорость, поиск с регулярками и т.д. С Vim до нынешнего трудоустройства общался крайне редко — только когда в linux надо было что-то в консоли сделать и по-другому никак, да и не знал я других редакторов :) Но вот появилась необходимость работать в vim'е, т.е. можно было и как-то по-своему, но я никогда не против познакомиться с чем-то новым для меня. Долгое время я пользовался vim'ом с чужими настройками (поделились, чтобы не на голом vim'е мне сидеть), пользовался сперва так больше по необходимости, потом привык к нему, научился так же не глядя выполнять копирование и прочие наиболее распространённые операции. Уже потом стал заглядывать с настройки, разбираться и подстраивать под себя. Сейчас это основной редактор для меня. И на работе я всё делаю им, либо по ssh удалённо, либо монтирую файловую систему и работаю с файлами как бы локально, но всё равно через vim.
Просто я иначе отношусь к его режимам, я знаю что они есть, но я на них не заморачиваюсь, просто использую другие хоткеи, нежели в windows.
Итого «пообщавшись» с разными редакторами для меня наиболее удобным оказался Vim, я не вижу каких-то кардинальных различий в применении хоткеев, просто они другие. Ведь в других редакторах хоткеи нажимаются в паре с Ctrl/Alt/Shift (и их комбинации), а тут вместо функциональных клавиш сперва нажимается Esc, а дальше уже сами «хоткеи». Vim'ом можно пользоваться и как обычным редактором, только хоткеи другие, а можно со временем подружиться и с более продвинутыми его возможностями, ну а дальше использовать их по желанию. Единственный, на мой взгляд, основной минус данного редактора — высокий порог вхождения, так как заимев привычку по другим редакторам подружиться с ним получается не сразу.
В общем если в двух словах, то я выбрал vim после того, как поработал с разными редакторами, поэтому на этот счёт у меня определённое мнение, которое сравнением различий в хоткеях не изменить ;). Я им пользуюсь так же как раньше пользовался другими редакторами, а использую именно его, потому что при том же удобстве использования он имеет больше возможностей. Только вот удобство при работе с ним приходит далеко не сразу :). Если до этого места кто-нибудь дочитает, то поясняю — этим текстом я не пытаюсь доказать чего-то по поводу Vim'а, а просто поясняю своё мнение и отношение к данному редактору, ну и поясняю что он не хуже многих других редакторов.
P.S. Если бы не надобность по работе пользоваться vim'ом, то я бы им и не начал активно пользоваться и не знал бы про его возможности, но научившись им нормально пользоваться я стараюсь пользоваться именно им.
> Да, классно, можно Alt-Tab переключаться между документами,
> столами и т.д. и т.п., но это переключение внимания в том числе
Согласен, гораздо удобнее два монитора, чем один большой, в котором надо постоянно переключаться между окнами :)
Надеюсь, я смог пояснить своё восприятие данного редактора и отношение к нему данным изложением мысли…
Дочитал :)
Вы упускали и упускаете важный момент. Речь не просто о других хоткеях, а о примитивизме действий.
Vim требует более вдумчивого подхода даже при условии привычки и автоматизма.
Впрочем, спорить мне просто надоело :) Если вдруг захочу провести исследование и написать статью по эргономике, то vim будет первым кандидатом для разбора :)
Вы упускали и упускаете важный момент. Речь не просто о других хоткеях, а о примитивизме действий.
Vim требует более вдумчивого подхода даже при условии привычки и автоматизма.
Впрочем, спорить мне просто надоело :) Если вдруг захочу провести исследование и написать статью по эргономике, то vim будет первым кандидатом для разбора :)
Не все конечно знают, но в студии есть режим эмуляции Emacs.
www.codeproject.com/KB/tips/VSnetIDETipsAndTricks.aspx
Большой кусок тоже скопировать нет проблем. Например чеще всего мы копируем код функции или целого класа которых находится между скобками. Устанавливаем курсор около скобки зажимае Шифт и жмём комбинацию CTRL + }, вуаля текст к коцу блока выделен. Конечно в Vim можно выделить ровно 43 строки, но в случае с кодом этого как раз не нужно, потому чтобы увидеть что оператор закончится на 43-ей строке нужно пролистать экран, а потом набрать команду для копирования, по моему то же самое с шифтом получится. Но в реальности не настолько эти операции часты.
Но вот в чём начнёт сливать вим это в интеграции среды с возможностями языков с VS. Например для С++, среда автоматически отловит MFC и сможет предлагать подсветку с разворачиванием макросов, вставкой обработчиков, C# тут вообще не место Vim, среда настолько заточена под визуальное проєктирование и рефакториг что Vim как средство редактирования просто безпомощен.
Моё резюме такое что нужно использовать инструмент адекватный задаче. У Vim-а есть сильные стороны, но при работе с технологиями Майкрософт которые заточены именно под разработку з визуальными средствами проэктирования вроде VS, ему не место, более того часто под маской «в Vim-е удобней» скрывается банальное нежелание разобратся с технологией. Я сам не сильный любитель когда приходится отрывать руки от клавиатуры чтобы что-то сделать мышей, но у Майкрософта есть достаточно много мест слабо освещённых документацией и единственный способ это понять, попробовать как раз в студии, так как именно ихние мастера генерят рабочий код, а работать в двох инструментах постоянно пытаясь их синхронизировать это как раз контрпродуктивно.
www.codeproject.com/KB/tips/VSnetIDETipsAndTricks.aspx
Большой кусок тоже скопировать нет проблем. Например чеще всего мы копируем код функции или целого класа которых находится между скобками. Устанавливаем курсор около скобки зажимае Шифт и жмём комбинацию CTRL + }, вуаля текст к коцу блока выделен. Конечно в Vim можно выделить ровно 43 строки, но в случае с кодом этого как раз не нужно, потому чтобы увидеть что оператор закончится на 43-ей строке нужно пролистать экран, а потом набрать команду для копирования, по моему то же самое с шифтом получится. Но в реальности не настолько эти операции часты.
Но вот в чём начнёт сливать вим это в интеграции среды с возможностями языков с VS. Например для С++, среда автоматически отловит MFC и сможет предлагать подсветку с разворачиванием макросов, вставкой обработчиков, C# тут вообще не место Vim, среда настолько заточена под визуальное проєктирование и рефакториг что Vim как средство редактирования просто безпомощен.
Моё резюме такое что нужно использовать инструмент адекватный задаче. У Vim-а есть сильные стороны, но при работе с технологиями Майкрософт которые заточены именно под разработку з визуальными средствами проэктирования вроде VS, ему не место, более того часто под маской «в Vim-е удобней» скрывается банальное нежелание разобратся с технологией. Я сам не сильный любитель когда приходится отрывать руки от клавиатуры чтобы что-то сделать мышей, но у Майкрософта есть достаточно много мест слабо освещённых документацией и единственный способ это понять, попробовать как раз в студии, так как именно ихние мастера генерят рабочий код, а работать в двох инструментах постоянно пытаясь их синхронизировать это как раз контрпродуктивно.
> Например чеще всего мы копируем код функции или целого класа
> которых находится между скобками. Устанавливаем курсор около
> скобки зажимае Шифт и жмём комбинацию CTRL + }, вуаля текст к
> коцу блока выделен. Конечно в Vim можно выделить ровно 43 строки
Я уже выше писал, что мы тут сравнением не занимаемся, но если есть желание что-то сравнить, то желательно изучить оба предмета для сравнения.
По поводу Вашего примера, но в Vim'е: устанавливаем курсор возле скобки, нажимаем V и жмём % (комбинацию Shift+5), вуаля, текст до конца блока выделен.
>Но вот в чём начнёт сливать вим это в интеграции среды с возможностями языков с VS
Вы пытаетесь сравнивать среду разработки, в которую входит свой редактор (а то и несколько), с простым редактором. Прочтите свой текст, Вы сами написали, что понимаете это ;) Если уж так хочется сравнивать, то надо сравнивать именно редакторы.
>а работать в двох инструментах постоянно пытаясь их синхронизировать это
> как раз контрпродуктивно.
С высказыванием согласен, но думаю, что автор топика хотел не работать «в двух инструментах», а просто заменить для себя редактор в IDE, таким образом работая в нужной среде разработки и используя её возможности, но чтобы в качестве редактора использовался привычный и полюбившийся визуальный редактор.
P.S. Так много народа пытаются сравнить IDE и Vim — значит этот народ считает, что vim больше чем простой редактор, что его возможности очень близки к возможностям «их» ide, можно сказать, что они сами же положительно отзываются об этом редакторе ;). Либо народ использует только базовый функционал ide и по сути для них это чуть ли не блокнот, либо народ уверен, что vim составляет серьёзную конкуренцию их любимой среде разработки :)
> которых находится между скобками. Устанавливаем курсор около
> скобки зажимае Шифт и жмём комбинацию CTRL + }, вуаля текст к
> коцу блока выделен. Конечно в Vim можно выделить ровно 43 строки
Я уже выше писал, что мы тут сравнением не занимаемся, но если есть желание что-то сравнить, то желательно изучить оба предмета для сравнения.
По поводу Вашего примера, но в Vim'е: устанавливаем курсор возле скобки, нажимаем V и жмём % (комбинацию Shift+5), вуаля, текст до конца блока выделен.
>Но вот в чём начнёт сливать вим это в интеграции среды с возможностями языков с VS
Вы пытаетесь сравнивать среду разработки, в которую входит свой редактор (а то и несколько), с простым редактором. Прочтите свой текст, Вы сами написали, что понимаете это ;) Если уж так хочется сравнивать, то надо сравнивать именно редакторы.
>а работать в двох инструментах постоянно пытаясь их синхронизировать это
> как раз контрпродуктивно.
С высказыванием согласен, но думаю, что автор топика хотел не работать «в двух инструментах», а просто заменить для себя редактор в IDE, таким образом работая в нужной среде разработки и используя её возможности, но чтобы в качестве редактора использовался привычный и полюбившийся визуальный редактор.
P.S. Так много народа пытаются сравнить IDE и Vim — значит этот народ считает, что vim больше чем простой редактор, что его возможности очень близки к возможностям «их» ide, можно сказать, что они сами же положительно отзываются об этом редакторе ;). Либо народ использует только базовый функционал ide и по сути для них это чуть ли не блокнот, либо народ уверен, что vim составляет серьёзную конкуренцию их любимой среде разработки :)
Использовал vim одно время, но не на работе, а для дома для себя. Так и не смог привыкнуть и проникнуться. Для того чтобы внести изменения в проект с исходниками из одного файла он отлично подходит, но вот если нужно реально работать…
Предположим нужно реализовать новую фичу, для этого нужно работать с пятью проектами студии, разобраться как и что работает, и в три из них внести изменения. Все эти пять проектов COM объекты на ATL. Даже не представляю сколько времени нужно потратить на затачивание Vim'a чтобы все это одновременно отлаживать и серфить по коду не хуже чем в VS+VA.
Думаю если бы человек, привыкший к VS+VA, попробовал поработать в пустом Vim, он бы вообще ничего не смог бы делать, пол часа разбирался бы как файл сохранить :)
Предположим нужно реализовать новую фичу, для этого нужно работать с пятью проектами студии, разобраться как и что работает, и в три из них внести изменения. Все эти пять проектов COM объекты на ATL. Даже не представляю сколько времени нужно потратить на затачивание Vim'a чтобы все это одновременно отлаживать и серфить по коду не хуже чем в VS+VA.
Несколько дней я поработал в «пустой» VS и понял, что долго так продолжаться не может.
Думаю если бы человек, привыкший к VS+VA, попробовал поработать в пустом Vim, он бы вообще ничего не смог бы делать, пол часа разбирался бы как файл сохранить :)
Думаю если бы человек, привыкший к VS+VA, попробовал поработать в пустом Vim, он бы вообще ничего не смог бы делать, пол часа разбирался бы как файл сохранить :)Совершенно правильно говорите. Я уже не раз слышал рассказы, да и сам видел, как люди запускали Vim в первый раз и впадали в панику. Обычно самой сложной задачей для новичка является открыв Vim, закрыть его :)
Сохранить файл… А хотя бы выйти? ))
Я первый раз (лет 14-15 назад) действительно где-то пол часа разбирался, как выйти из этого чудо-редактора.
Тогда только-только пробовал осваивать юниксы, интернета под рукой небыло, знакомых гуру тоже, никакой справочной информации…
Единственное решение, которое тогда нашел, по шагам:
1. перейти в другую консоль
2. ps aux — посмотреть список процессов
3. kill -9 номер_процесса_vi
До сих пор стыдно за такое вопиющее ламерство, но факт есть факт — ни один другой вспомагательный инструмент не доставлял мне тогда столько хлопот.
Я первый раз (лет 14-15 назад) действительно где-то пол часа разбирался, как выйти из этого чудо-редактора.
Тогда только-только пробовал осваивать юниксы, интернета под рукой небыло, знакомых гуру тоже, никакой справочной информации…
Единственное решение, которое тогда нашел, по шагам:
1. перейти в другую консоль
2. ps aux — посмотреть список процессов
3. kill -9 номер_процесса_vi
До сих пор стыдно за такое вопиющее ламерство, но факт есть факт — ни один другой вспомагательный инструмент не доставлял мне тогда столько хлопот.
Поясните, есть ли в виме или его редакциях какие-то преимущества графического режима? Например при редактировании php очень важны всякие пометки слева или справа от окна с текстом — закладки, брейкпоинты, пометки todo или предупреждения валидатора. Это очень удобно смотреть в ide c графическим интерфейсом и это очень помогает. Например в редакторе xml очень удобна полоска, которая показывает границы текущего узла. А также всякие контролы, позволяющие свовачивать куски кода и узлы, чтобы ненужные фрагменты кода не засоряли экран.
В vs я не работал, но приходится постоянно работать с вимом и Zend Studio и невольно сравнивать. Пока что ничья. Но чувствую что у vim'a есть ещё потенциал, т.к. сильно не копался в его кишках и чувствуется что они у него развесистые :)
Пока мое мнение таково:
vim именно что консольный редактор с скриптами и командами. У него все же преимущества, что у консоли — гибкость, настраиваемость, переносимость (зашел по ssh на любой linux сервер и работаешь в vim'e), легкость.
А ZendStudio олицетворяет преимущества/недостатки графического интерфейса — дружественный, информативный. За эти плюсы мы платим тормозами и плохой настраиваемостью — например у Remote Connection даже порт нельзя указать отличный от 22 :) В vim'e же таких проблем просто не возникнет, т.к. в его функционал включена вся функциональность консоли.
Вот еслиб у vim'a можно было настроить то, что я люблю в Zend Studio — всякие графические хинты и пометки, цены б ему не было.
В vs я не работал, но приходится постоянно работать с вимом и Zend Studio и невольно сравнивать. Пока что ничья. Но чувствую что у vim'a есть ещё потенциал, т.к. сильно не копался в его кишках и чувствуется что они у него развесистые :)
Пока мое мнение таково:
vim именно что консольный редактор с скриптами и командами. У него все же преимущества, что у консоли — гибкость, настраиваемость, переносимость (зашел по ssh на любой linux сервер и работаешь в vim'e), легкость.
А ZendStudio олицетворяет преимущества/недостатки графического интерфейса — дружественный, информативный. За эти плюсы мы платим тормозами и плохой настраиваемостью — например у Remote Connection даже порт нельзя указать отличный от 22 :) В vim'e же таких проблем просто не возникнет, т.к. в его функционал включена вся функциональность консоли.
Вот еслиб у vim'a можно было настроить то, что я люблю в Zend Studio — всякие графические хинты и пометки, цены б ему не было.
Как-то вот в таком аксепте) Сворачивание кода есть, валидатор цветом активно ругается, TODO подсвечивается, вбок правда его выносить не пробовал. Между границами текущего узла ходить легко. Хинты вроде расширяются до еще более навороченных даже с выводом документации по функции, я просто никогда этим не заморачивался.
Для php применимо всё то же :)
А вот графическим режимом я в виме никогда не пользовался…
Упс, атрибуты width и height хабр проигнорировал…
Cпасибо за ответ, на скриншоте виден только фолдинг — с ним в виме работал и претензий не имею. Интересует именно информативность интерфейса.
> Сворачивание кода есть, валидатор цветом активно ругается, TODO подсвечивается, вбок правда его выносить не пробовал.
Можете скинуть ссылку или скриншот с демонстрацией этого?
> Между границами текущего узла ходить легко.
Вот по этому мануалу — vimdoc.sourceforge.net/htmldoc/usr_03.html#03.4 — видно, что можно перемещаться между парами символов с помощью команды "%". Но так понял, что это неприменимо к тегам xml — там паттерн сложнее, чем в настройке matchpairs — vimdoc.sourceforge.net/htmldoc/options.html#%27matchpairs%27.
> Сворачивание кода есть, валидатор цветом активно ругается, TODO подсвечивается, вбок правда его выносить не пробовал.
Можете скинуть ссылку или скриншот с демонстрацией этого?
> Между границами текущего узла ходить легко.
Вот по этому мануалу — vimdoc.sourceforge.net/htmldoc/usr_03.html#03.4 — видно, что можно перемещаться между парами символов с помощью команды "%". Но так понял, что это неприменимо к тегам xml — там паттерн сложнее, чем в настройке matchpairs — vimdoc.sourceforge.net/htmldoc/options.html#%27matchpairs%27.
Вот скриншот из Zend Studio c акцентом на «фишки», которые бы хотелось иметь в любом редакторе — img256.imageshack.us/img256/8679/demoz.jpg
вы наверное про автодополнение хотели сказать, а не про фолдинг :)
Фолдинг — это и есть сворачивание:
Ещё на скрине виден выделенный TODO блок (как-то вим умеет производить по ним навигацию, но, хоть убейте, не помню, как), выделенный красным фоном кусок — это активно ругается валидатор, подсвеченные фигурные скобки блока foreach — по ним действительно отлично ходится с помощью '%'. На тему более сложных переходов — надо смотреть файл matchit.vim — у меня он лежит в /usr/share/vim/vimcurrent/macros/.
Кстати, блок документации мне генерит тоже вим, я только текстовые детали указываю :)
Про боковые пометки вот ничего сказать не могу.
Фолдинг — это и есть сворачивание:
Ещё на скрине виден выделенный TODO блок (как-то вим умеет производить по ним навигацию, но, хоть убейте, не помню, как), выделенный красным фоном кусок — это активно ругается валидатор, подсвеченные фигурные скобки блока foreach — по ним действительно отлично ходится с помощью '%'. На тему более сложных переходов — надо смотреть файл matchit.vim — у меня он лежит в /usr/share/vim/vimcurrent/macros/.
Кстати, блок документации мне генерит тоже вим, я только текстовые детали указываю :)
Про боковые пометки вот ничего сказать не могу.
Спасибо. В картинках гугла находятся примеры настроек вима под пхп с боковыми пометками и много-оконностью, например вот — tech-blog.box.net/wp-content/uploads/2007/06/dbgp-client-in-vim.png
Буду разбираться. Дай бог, через месяц что-то выйдет :D Вот сегодня освоил навигацию и поиск, замены кажется полностью :)
Буду разбираться. Дай бог, через месяц что-то выйдет :D Вот сегодня освоил навигацию и поиск, замены кажется полностью :)
Многооконность делается командами :split filename и :vsplit filename
Вот боковые пометки я никогда не терзал, поэтому и не знаю, я даже боковую нумерацию не слишком люблю.
А всё знать один фиг нельзя :) Кто-то умный говорил, что «в линуксе можно знать только один редактор из двух — либо вим, либо емакс. Если кто-то сказал, что знает оба, то дайте ему по лицу, он нагло врёт».
Вот боковые пометки я никогда не терзал, поэтому и не знаю, я даже боковую нумерацию не слишком люблю.
А всё знать один фиг нельзя :) Кто-то умный говорил, что «в линуксе можно знать только один редактор из двух — либо вим, либо емакс. Если кто-то сказал, что знает оба, то дайте ему по лицу, он нагло врёт».
Ну фолдинг в vim'е есть и вполне настраиваемый, попробуйте :help folding. Всякие todo, списки переменных/функций тоже присутствуют, project explorer тоже есть (тот же список файлов/папок, но с корнем в папке проекта)
Спасибо автору, но если бы он скринкасты на работу с каждым вариантом записал — было бы гораздо лучше
Для меня VIM оказался гораздо удобнее тем, что у него гораздо выше экспрессивность: гораздо легче выразить в командах свои намерения по редактированию текста, так как набор текстовых объектов шире (не только буквы, слова и строки, но и предложения, абзацы, содержимое скобок, кавычек и прочее), больше вариантов передвижений, несколько регистров буфера обмена, и макросы.
Это привело к тому, что в обычных редакторах испытываешь раздражение от того, что задуманную мысль не удаётся воплотить также быстро и эффективно.
С VIM слезть также трудно, как и с лиспа.
Это привело к тому, что в обычных редакторах испытываешь раздражение от того, что задуманную мысль не удаётся воплотить также быстро и эффективно.
С VIM слезть также трудно, как и с лиспа.
Для фанатов vim вопос по функционалу.
Если нужно имя метода поменять во всем проекте и связанных с ним проектах — это как сделать? Сколько нажатий кнопок?
В VS — правый клик на метод и rename.
Если нужно имя метода поменять во всем проекте и связанных с ним проектах — это как сделать? Сколько нажатий кнопок?
В VS — правый клик на метод и rename.
Чтобы понять что выбрать нужно знать с какими технологиями вы вообще собираетесь работать.
Visual Studio в первую очередь заточена под собственные библиотеки и технологии, и если работать нужно с ними, то от студии никуда не денетесь, потому что те же визарды которые сгенерят нужные прототипы из Vim не вызовёте. А раз так то придётся держать одновременно и студию и Vim-а, а тогда сэкономленное на редактировании время будете тратить на синхронизацию между средами. По моему так сомнительное удовольствие.
В Vim нет и не предвидится аналогов Visual Assist для С++, Resharper для .NET, а раз так, то и пользы от него будет минимум зато вреда значительно больше, мне эти плагины помогают писать более качественный код, а встроеныые шаблоны экономят время на набирание. Чистое редактирование не так часто нужно, а нужен рефакторинг вроде «Извлечь функцию», «переименовать переменную» где Vim без семантического анализа кода сливает.
Вот где Vim класный, это отладить код на удалённом терминале с каналом 32 Кб\сек, но только вот в таких условиях технологии Майкрософт используются редко.
Visual Studio в первую очередь заточена под собственные библиотеки и технологии, и если работать нужно с ними, то от студии никуда не денетесь, потому что те же визарды которые сгенерят нужные прототипы из Vim не вызовёте. А раз так то придётся держать одновременно и студию и Vim-а, а тогда сэкономленное на редактировании время будете тратить на синхронизацию между средами. По моему так сомнительное удовольствие.
В Vim нет и не предвидится аналогов Visual Assist для С++, Resharper для .NET, а раз так, то и пользы от него будет минимум зато вреда значительно больше, мне эти плагины помогают писать более качественный код, а встроеныые шаблоны экономят время на набирание. Чистое редактирование не так часто нужно, а нужен рефакторинг вроде «Извлечь функцию», «переименовать переменную» где Vim без семантического анализа кода сливает.
Вот где Vim класный, это отладить код на удалённом терминале с каналом 32 Кб\сек, но только вот в таких условиях технологии Майкрософт используются редко.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Vim и Visual Studio