Здравствуйте, haba_haba_haba, Вы писали:
__>В студии посчитай сам. Если не использовать копирование — примерно 15000*(37+1). Или поменьше, если его использовать. __>
Подсчитал, в VS2008 получилось поменьше: 39 + набивка самой строки = 77
M>>Пока что примеры таких задач праткически никто не привел (кто привел — можно посмотреть по оценкам от меня в этом топике. Обычно они в первом уровне).
EOH>Я рассказываю исключительно про свое впечатление за последние пять лет плотной работы с VIM. В целом я уже более десяти лет активно использую Visual Studio, много лет использовал emacs, так что есть с чем сравнивать. Продавать вам VIM я не собираюсь, так что специально вспоминать и описывать здесь ситуации сложной замены, когда VIM экономил очень много времени, не буду — достаточно того, что я этими соображениями поделился.
Ну вот. Так — всегда. Никто не способен описать, что такого они делают, в чем vim рулит.ю Все заканчивается на «я дал представление»
Я ни в жизнь не позволю себе запускать автоматическое «сложное преобразование» на проекте какого-либо объема в случае, если это преобразовнаие основывается только лишь на «последовательности действий». Потому что это ничем не отличается от глобального Find Replace. Потому что даже рефакторинг, который основывается на гораздо большей информации, чем просто последовательность действий, иногда дает сбои.
Я могу ошибаться. В этом была вся идея этого топика. Но вот вы отказываетесь рассказать, в чем я ошибаюсь Ну, пустыми заявлениями и я могу воздух посотрясать
Аналогично со «сложными макросами». Сложные макросы для манипуляции текста я перестал писать еще в 95-м ворде, потому что чем макрос сложнее, чем уже сфера его применения и тем он бесполезнее. В какой-то момент легче провести манипуляции заново, чем вспоминать, что именно делает сложный макрос, есть ли он вообще, и можно ли его применить в данной конкретной ситуации.
Опять же. Я могу ошибаться. Но вот вы отказываетесь рассказать, в чем я ошибаюсь Но, извините, «найти следующую открывающую скобку, удалить слово, поместить в буфе первые три символа следующего слова, удалить все до закрывающей скобки, вставить помещенное в буфер» — это не такая уж и часто повторяющаяся последовательность действий, чтобы ради нее заводить макрос явялется банальными манипуляциями с текстом. Некоторые из которых да, могут выполнятся в виме удобнее.
Здравствуйте, Mamut, Вы писали:
M>Аналогично со «сложными макросами». Сложные макросы для манипуляции текста я перестал писать еще в 95-м ворде, потому что чем макрос сложнее, чем уже сфера его применения и тем он бесполезнее. В какой-то момент легче провести манипуляции заново, чем вспоминать, что именно делает сложный макрос, есть ли он вообще, и можно ли его применить в данной конкретной ситуации.
В Виме макросы, как правило, не пишутся и не сохраняются. Просто, когда необходимо несколько раз повторить одну и ту же последовательность действий, то используется режим записи команд в регистр: q{0-9a-zA-Z"}.
M>>Аналогично со «сложными макросами». Сложные макросы для манипуляции текста я перестал писать еще в 95-м ворде, потому что чем макрос сложнее, чем уже сфера его применения и тем он бесполезнее. В какой-то момент легче провести манипуляции заново, чем вспоминать, что именно делает сложный макрос, есть ли он вообще, и можно ли его применить в данной конкретной ситуации.
DR>В Виме макросы, как правило, не пишутся и не сохраняются. Просто, когда необходимо несколько раз повторить одну и ту же последовательность действий, то используется режим записи команд в регистр: q{0-9a-zA-Z"}.
Здравствуйте, Mamut, Вы писали:
M>Основной посыл про vi(m) выглядит так: M>
M>Vim умеет всё, что умеет редактор Студии и вообще традиционные редакторы. А вот обратное неверно.
M>или даже так: M>
M>vim умеет столько всего, что студии(эклипсу, ноутпаду) и не снилось
Не так- Eclipse может такое, что редактору студии не снилось (в плане рефакторинга и поддержки дофига языков), а еще он есть под маком и линухом. Vim хорош, когда надо пролезть через ssh например, или по-быстрому подправить файл. Но в то же время править файлики через sftp в TextWrangler на порядок удобнее вима.
Здравствуйте, genre, Вы писали:
T>>Не пофиг. И по этой причине большие изменения откладываются на потом. Ctrl-R-R — модифицирует хоть сто, хоть тыщу файлов. А руками так никто никогда не делал и делать не будет.
G>можно юзкейс?
Здравствуйте, Tanker, Вы писали:
T>>>Не пофиг. И по этой причине большие изменения откладываются на потом. Ctrl-R-R — модифицирует хоть сто, хоть тыщу файлов. А руками так никто никогда не делал и делать не будет.
G>>можно юзкейс?
T>Refactoring Rename
вот именно что рефакторинг. его и надо делать специальным тулом. а не заменой текста по всему проекту.
Здравствуйте, Denys V., Вы писали:
KP>>>Мне очень нравится VIM и то как в нем построена система редактирования текста. Но отсутствие нормально поддержки автодополнений для C++ (не надо рассказывать по ctags и прочее, я сам про них могу много его рассказать) делает его не очень подходящим для больших проектов. C>>Я прикручивал туда поддержку автодополнения от XRefactory. Докрутил до того, что оно начало работать, но потом бросил у ушёл обратно в Студию. DV>Почему ушли?
Отладчика нормального нет, и даже после всех докручиваний оно не работает нормально.
DV>XRefactory плохо работает?
Ага. Тем более, что он умер. Сейчас рулит clang: http://blogs.gnome.org/jessevdk/2011/09/10/gedit-clang-plugin-progress/
DV>Недокрутили? DV>Не смогли привыкнуть к vim?
Я сейчас vim использую как простой редактор.
C>>Могу поискать код и выложить. DV>был бы очень признателен.
В связи со смертью XRefactory это не особо поможет.
Здравствуйте, Eye of Hell, Вы писали:
M>>Пока что примеры таких задач праткически никто не привел (кто привел — можно посмотреть по оценкам от меня в этом топике. Обычно они в первом уровне).
EOH>Я рассказываю исключительно про свое впечатление за последние пять лет плотной работы с VIM. В целом я уже более десяти лет активно использую Visual Studio, много лет использовал emacs, так что есть с чем сравнивать. Продавать вам VIM я не собираюсь, так что специально вспоминать и описывать здесь ситуации сложной замены, когда VIM экономил очень много времени, не буду — достаточно того, что я этими соображениями поделился.
Это ты с идеей не работал . У нее настолько потрясающие возможности интеллектуальной работы с кодом(т.е. она знает все про твой код, причем на разных языках, даже если они в одном файле вперемешку), что читать про возможности работы с кодом текстового редактора просто смешно. Как текстовый редактор ВИМ отличен, но что он знает про структуру проекта(и связанных с ним), используемые либы, используемые технологии? Он умеет в пару кликов привязаться к серверу приложений(заодно выкачав его, поставив и настроив)? Он умеет перестроить кусок кода с сохранением функционала в другую структуру? И если я начну перечислять все возможности, я сегодня спать не ляжу.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
T>>>Не пофиг. И по этой причине большие изменения откладываются на потом. Ctrl-R-R — модифицирует хоть сто, хоть тыщу файлов. А руками так никто никогда не делал и делать не будет.
G>>можно юзкейс?
T>Refactoring Rename
Прекрасный пример. Если у нас совпадают имена, но не совпадают реальные объекты(т.е. они никак не связаны) вим сможет это определить? А если у нас класс(ну вот будем про джаву говорить, например) обявлен в джава коде, но при этом в другом пакете есть одноименный, но они оба использубтся в скриптлетах jsp(где используется также одноименный js объект, и есть параметры тэга html с таким же именем), и в коде на scala, а также в xml конфигах спринга, сможет ли вим корректно переименовать(одним действием программиста) использования только этого класса, на затронув логически неподходящие, хоть и называющиеся так же сущности в различных забавных местах?
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, gyraboo, Вы писали:
G>Здравствуйте, Mamut, Вы писали:
G>>>При выделении текста мышкой концентрация внимания повышается, при постоянной работе с текстом таким образом приведет к сильному утомлению.
M>>А следить за текущим контекстом не требует дополнительной концентрации внимания?
G>Нет, не требует. Привычка делать двойной Эскейп после выполнения каждой операции — и ты уже не следишь за контекстом. G>Особенно эта привычка актуальна при терминальной работе, когда курсов не меняет свой вид в зависимости от режима )
...
я уже давно это повесил на jj, тогда и руки не надо двигать.
Здравствуйте, Mamut, Вы писали:
M>После чего возникает резонный вопрос — а что именно им не снилось и что именно уметт vi(m) такого, что другие не умеют?
быстро запуститься и быстро выключиться.. остальные т.н. "преимущества" условны и/или имеют аналоги..
Здравствуйте, frogkiller, Вы писали:
M>>Так вот мне стало интересно. О чем же именно не могут даже и мечтать другие редакторы по сравнению с vi(m)'ом?
F>При (почти) всей этой функциональности vim прекрасно работает в консоли через кучу терминалов и с вероятностью 95% "из коробки" живёт в разных мелких девайсов типа домашних роутеров, не говоря уже о больших серверах.
Выделенное тем более применимо 
