Комментарии 191
Камрад, Вы — герой. У меня мизинец чуть не отвалился, когда осваивая Emacs, я жал на control. Потом пришло озарение и вот уже 8 лет, на моей клаве нет Caps Locka :)
НЛО прилетело и опубликовало эту надпись здесь
«у меня всегда был подобного рода файл открыт, правда проблема была в том, что этот файл всегда сохранялся, хотя мне это нужно не было. В какой IDE есть подобная штука? „
Ага, в IDEA есть такое окно. Там даже джаву писать можно. blog.jetbrains.com/idea/2014/09/intellij-idea-14-eap-138-2210-brings-scratch-files-and-better-mercurial-integration/
“Так вот, в Емаксе достаточно выделить кусок кода, и нажать на таб — и он выравняется независимо от того, какие ошибки в коде нашел»
Так это же тоже есть везде.
Ага, в IDEA есть такое окно. Там даже джаву писать можно. blog.jetbrains.com/idea/2014/09/intellij-idea-14-eap-138-2210-brings-scratch-files-and-better-mercurial-integration/
“Так вот, в Емаксе достаточно выделить кусок кода, и нажать на таб — и он выравняется независимо от того, какие ошибки в коде нашел»
Так это же тоже есть везде.
Больше похоже на «Я еще не говорил, что Visual Studio в сравнении с Emacs идет лесом? А, ну вот, сказал.»
Раз уж мы говорим про Visual Studio и плагины, то почему все еще не упомянута магия Resharper?
>> Другая незаменимая комбинация — «Ctrl+x b», она переносит курсор в поле для ввода имени буфера (aka открытого файла), в который вы хотите перейти.
>> Скажу так: я не так давно кодил в Visual Studio, и, чтобы перейти на вкладку, мне приходилось использовать комбинации VsVim типа «Пред. вкладка», «След. вкладка», «Вкладка №n».
Ctrl-Shift-T — и все то же самое, только не важно, открыт файл, или нет (любой файл из проекта).
>> я приведу пример, очень близкий сердцам IDE'шников: представьте, что вам надо переименовать локальную переменную под курсором.
>> Итак, вы можете
>> α) Вывести контекстное меню, и ввести новое имя
>> β) Написать простенькую регулярку вида «\bmy_var\b», и проследить, чтобы замены были только в пределах функции.
Ctrl-Shift-R, ввести новое имя (с семантическими подсказками), Enter.
>> она запускает функцию «ido-menu», и я просто не представляю, как люди, пользующиеся IDE живут без нее.
>> выводит список функций в текущем файле.
>> Это невероятно удобно: вы нажали гор. клавишу, ввели часть функции, какая вам навскидку пришла в голову, и нажали ввод.
Alt+\
>> Вернуться к предыдущему месту можно на «Ctrl-u Ctrl-space».
Ctrl+-
>> Прыг к провозглашению функции? «gd»
F12
>> Возвратиться на предыдущее, следующее место в коде? «Ctrl-o» и «Ctrl-i» соответственно.
Ctrl+-, Ctrl+Shift+-
И да, три последних пункта — без решарпера. И семантическая навигация все больше работает без решарпера тоже. И магические Ctrl+Q, Ctrl+' и Ctrl+;
>> Другая незаменимая комбинация — «Ctrl+x b», она переносит курсор в поле для ввода имени буфера (aka открытого файла), в который вы хотите перейти.
>> Скажу так: я не так давно кодил в Visual Studio, и, чтобы перейти на вкладку, мне приходилось использовать комбинации VsVim типа «Пред. вкладка», «След. вкладка», «Вкладка №n».
Ctrl-Shift-T — и все то же самое, только не важно, открыт файл, или нет (любой файл из проекта).
>> я приведу пример, очень близкий сердцам IDE'шников: представьте, что вам надо переименовать локальную переменную под курсором.
>> Итак, вы можете
>> α) Вывести контекстное меню, и ввести новое имя
>> β) Написать простенькую регулярку вида «\bmy_var\b», и проследить, чтобы замены были только в пределах функции.
Ctrl-Shift-R, ввести новое имя (с семантическими подсказками), Enter.
>> она запускает функцию «ido-menu», и я просто не представляю, как люди, пользующиеся IDE живут без нее.
>> выводит список функций в текущем файле.
>> Это невероятно удобно: вы нажали гор. клавишу, ввели часть функции, какая вам навскидку пришла в голову, и нажали ввод.
Alt+\
>> Вернуться к предыдущему месту можно на «Ctrl-u Ctrl-space».
Ctrl+-
>> Прыг к провозглашению функции? «gd»
F12
>> Возвратиться на предыдущее, следующее место в коде? «Ctrl-o» и «Ctrl-i» соответственно.
Ctrl+-, Ctrl+Shift+-
И да, три последних пункта — без решарпера. И семантическая навигация все больше работает без решарпера тоже. И магические Ctrl+Q, Ctrl+' и Ctrl+;
А в решарпере можно перед всеми заданными строками добавить два пробела, символ * и еще один пробел?
(term «заданные» not defined, falling back)
Для любого последовательного блока строк можно добавить произвольные символы в начало.
Для любого последовательного блока строк можно добавить произвольные символы в начало.
Приведу пример. Есть блок такого вида:
— A
— B
— C
… еще 200 таких
Надо из него сделать блок вида:
* A
* B
* C
…
Добавить несомненно можно все, вопрос в том, как это просто?
— A
— B
— C
… еще 200 таких
Надо из него сделать блок вида:
* A
* B
* C
…
Добавить несомненно можно все, вопрос в том, как это просто?
Да, можно, причем даже в ванильной студии.
Встать в начало первой (или последней) строки блока
Нажать Alt+Shift
Встать в начало последней (или первой) строки блока
(Если в начале строк есть ненужные символы — например, у вас это "- ", — то сдвинуться вправо, захватив их)
Отпустить Alt+Shift
Набрать пробел-пробел-*-пробел
Все. Я описывал в разы дольше, чем это делать, и самая долгая операция — это выбор нужных строк.
Встать в начало первой (или последней) строки блока
Нажать Alt+Shift
Встать в начало последней (или первой) строки блока
(Если в начале строк есть ненужные символы — например, у вас это "- ", — то сдвинуться вправо, захватив их)
Отпустить Alt+Shift
Набрать пробел-пробел-*-пробел
Все. Я описывал в разы дольше, чем это делать, и самая долгая операция — это выбор нужных строк.
А как на счет — удалить все между открывающей и закрывающей круглыми скобками?
Точно не помню, скорее всего именно так не получится, придется выделить (одним нажатием клавиш) все, включая скобки, а затем набрать скобки заново (тоже одним нажатием).
(Я пока еще сдерживаюсь и не спрашиваю «а как в emacs/vim насчет...»)
(Я пока еще сдерживаюсь и не спрашиваю «а как в emacs/vim насчет...»)
Хорошо сдерживаетесь, ибо я не туда клоню. Разница тут в том, что в Vim (не знаю про Emacs) эти же операции делаются проще и быстрее. Попробуйте плагин для вашей любимой IDE, который реализует Vim-режимы и вы не сможете больше жить без него, уверяю вас.
>> Попробуйте плагин для вашей любимой IDE, который реализует Vim-режимы
… и при этом конфликтует с уже существующей *и удобной мне* функциональностью, ага.
>> эти же операции делаются проще и быстрее
А мне не надо делать эти операции быстрее (я вообще считаю, что если мне надо сделать операцию «сделать из блока вида Х блок вида У» — я что-то не то делаю в норме). То, о чем вы пишете в разделе «а можно?» не является чем-то, что отнимает хоть сколько-нибудь заметное время от моей работы; а то, о чем пишу я в своем первом комментарии, вряд ли делается в Vim проще и быстрее (потому что я не могу себе представить, куда быстрее).
(а еще, правда же, фраза «IDE в сравнении с IDE с vim-режимом идут лесом» звучит уже совсем не так громко, как «IDE в сравнении с Emacs идут лесом»?)
… и при этом конфликтует с уже существующей *и удобной мне* функциональностью, ага.
>> эти же операции делаются проще и быстрее
А мне не надо делать эти операции быстрее (я вообще считаю, что если мне надо сделать операцию «сделать из блока вида Х блок вида У» — я что-то не то делаю в норме). То, о чем вы пишете в разделе «а можно?» не является чем-то, что отнимает хоть сколько-нибудь заметное время от моей работы; а то, о чем пишу я в своем первом комментарии, вряд ли делается в Vim проще и быстрее (потому что я не могу себе представить, куда быстрее).
(а еще, правда же, фраза «IDE в сравнении с IDE с vim-режимом идут лесом» звучит уже совсем не так громко, как «IDE в сравнении с Emacs идут лесом»?)
А что у вас отнимает заметное время в вашей работе (имеется в виду именно использование редактора)?
Рефакторинг.
Тогда понятно. К слову, я эту проблему решил не использованием современных IDE, а продумыванием архитектуры и TDD.
Нельзя решить использованием TDD то, что является составной частью TDD.
(и да, именно при TDD у меня наибольшее количество затрат на рефакторинг)
(и да, именно при TDD у меня наибольшее количество затрат на рефакторинг)
Что то вы не то делаете, на мой взгляд. Все ведь элементарно, обдумывается интерфейс, описывается интерфейс, еще раз обдумывается и упрощается. Затем пишутся несколько тестов, они реализуются и пишуются другие. Для такой работы рефакторить нужно не более чем имена аргументов в методах класса, а так как хороший метод класса много строк не занимает, вполне хватает поиска с заменой.
Вопросы, связанные с именами методов и их отношениями к классам решаются еще до написания тестов и тут для косметического рефакторинга не нужна IDE.
Вопросы, связанные с именами методов и их отношениями к классам решаются еще до написания тестов и тут для косметического рефакторинга не нужна IDE.
О, так это вы не TDD описываете. Мантра TDD — red/green/refactor. И интерфейс — реальный — формируется как раз в ходе написания тестов, а не до того. Так что ход событий «во время написания очередного теста на класс выяснилось, что у класса есть еще одна зависимость» — он совершенно типовой, и, как следствие, изменения «а теперь давайте прокинем в класс новую зависимость» случается весьма и весьма часто.
(я помню, что формально это не рефакторинг, но по типу деятельности активность та же самая)
(я помню, что формально это не рефакторинг, но по типу деятельности активность та же самая)
Не встречал еще таких программистов, которые пишут класс не зная, какие у него зависимости. Мантра TDD хоть и включает это заветное слово (refactor), но оно далеко от тех задач, которые решаются средствами рефакторинга в IDE.
На практике я нашел лишь два применения рефакторинга, который есть в современных IDE:
1. Переименование методов — автоматически переименовываются все вызовы этих методов. На деле это настолько редкая операция, что я воспользовался ею ниразу;
2. Переименование классов — автоматически переименовываются все точки инстанциации или использования. Операция еще более редкая, нежели предыдущая.
Все другие типы рефакторинга в IDE реализуются путем:
1. Поиска вхождений руками или с помощью списка, который показывает все возможные вхождения и, опять таки, ручной правки или выбора нужного решения;
2. Изменения имени чего то в 5 строчках кода (как изменение имени аргумента метода).
Как раз благодаря TDD и продумывания архитектуры мы избавляемся от этого сложного рефакторинга и делаем его тривиально простым, что даже IDE не нужна.
Можете привести реальный пример рефакторинга с TDD, который требует использования IDE?
На практике я нашел лишь два применения рефакторинга, который есть в современных IDE:
1. Переименование методов — автоматически переименовываются все вызовы этих методов. На деле это настолько редкая операция, что я воспользовался ею ниразу;
2. Переименование классов — автоматически переименовываются все точки инстанциации или использования. Операция еще более редкая, нежели предыдущая.
Все другие типы рефакторинга в IDE реализуются путем:
1. Поиска вхождений руками или с помощью списка, который показывает все возможные вхождения и, опять таки, ручной правки или выбора нужного решения;
2. Изменения имени чего то в 5 строчках кода (как изменение имени аргумента метода).
Как раз благодаря TDD и продумывания архитектуры мы избавляемся от этого сложного рефакторинга и делаем его тривиально простым, что даже IDE не нужна.
Можете привести реальный пример рефакторинга с TDD, который требует использования IDE?
Extract method, extract property, extract field.
Черновой вариант всегда пишу портянкой. Потом рефакторится до приличного вида.
Черновой вариант всегда пишу портянкой. Потом рефакторится до приличного вида.
Неужели ченовой вариант рефакторится на поздних стадиях проекта?
Не пробовали продумывать архитектуру и интерфейс заранее (начать с пользовательской документации)?
Не пробовали продумывать архитектуру и интерфейс заранее (начать с пользовательской документации)?
Обычный TDD цикл. Написал тест, написал функционал, отрефакторил (выделение методов, свойств и т.д.). При чем тут поздние стадии? Вы просили пример сложных рефакторингов в TDD, я вам их привел. В Vim/Emacs я так делать не умею, хотя очень люблю Vim и каждый день его использую.
В обычном TDD цикле переименование метода влечет за собой замену его имени в одной строчке теста. Если бы пришлось переименовывать метод в 3-5 или более строчках теста, то это уже поздняя стадия, на мой взгляд.
Разве для переименования метода в одной строчке теста нужна IDE?
Разве для переименования метода в одной строчке теста нужна IDE?
Где вы прочитали слово «переименование»? Я говорю о Extract. Я пишу, скажем, класс, у него есть одна единсвенная обязанность, делать пироги. Так вот для того, чтобы сосредоточиться на самом функционале изготовления пирогов, я пишу всю логику в одном длинном методе. На стадии рефакторинга в TDD цикле я начинаю выделять приватные методы из моей портянки, чтобы логически разделить части кода и привести все в читаемый через месяц-год вид.
Ознакомтесь
Ознакомтесь
Прошу прощения. Не заметил вашего:
Каким образом вы этом помогает рефакторинг IDE? То есть для вынесения блока кода из метода в новый метод использутется некая функциональность IDE, отличная от «выделить текст + комбинация клавишь + ввел имя нового метода»?
Extract method, extract property, extract field.
Каким образом вы этом помогает рефакторинг IDE? То есть для вынесения блока кода из метода в новый метод использутется некая функциональность IDE, отличная от «выделить текст + комбинация клавишь + ввел имя нового метода»?
Очень просто, IDE сама создает новый метод с указанным мной именем, сама определяет необходимые параметры и возвращаемое значение, сама заменяет выделенный мной кусок кода на вызов нового метода с передачей всех параметров.
… в процессе этого в методе может быть упрощен control flow, если там есть для этого возможность (например, поставлен ранний return).
Более того, потом можно в этом методе произвольное значение, которое во всех предыдущих использованиях было k, а в добавляемом новом стало n, вынести в параметр, и в этот момент во всех предыдущих местах вызовов подставится k, а в новом можно с чистой совестью написать n.
Более того, потом можно в этом методе произвольное значение, которое во всех предыдущих использованиях было k, а в добавляемом новом стало n, вынести в параметр, и в этот момент во всех предыдущих местах вызовов подставится k, а в новом можно с чистой совестью написать n.
Скажу честно, с такой задачей если и встречался, то пару раз за мой практику, и то приходилось поработать руками секунд 15.
Может я и ошибаюсь, но пока остаюсь при своем мнении — рефакторинг в IDE это функция, которая нужна для проектов с плохой архитектурой.
Пора отойти ко сну. Спасибо за беседу.
Может я и ошибаюсь, но пока остаюсь при своем мнении — рефакторинг в IDE это функция, которая нужна для проектов с плохой архитектурой.
Пора отойти ко сну. Спасибо за беседу.
>> Скажу честно, с такой задачей если и встречался, то пару раз за мой практику, и то приходилось поработать руками секунд 15.
Вот у меня такая же ситуация с вашими «заменить на *» и «удалить все внутри скобок».
>> рефакторинг в IDE это функция, которая нужна для проектов с плохой архитектурой.
У вас в проектах всегда хорошая архитектура? Вы никогда не беретесь за legacy? Завидую по обоим пунктам
(Вообще же, не бывает «плохой» или «хорошей» архитектуры, бывает архитектура, которая решает задачу или не решает. А еще бывает, что сначала нужно написать быстро, поэтому написано «плохо», а потом есть время на переписать «хорошо», и вот тогда польза от автоматических средств рефакторинга встает в полный рост.)
Вот у меня такая же ситуация с вашими «заменить на *» и «удалить все внутри скобок».
>> рефакторинг в IDE это функция, которая нужна для проектов с плохой архитектурой.
У вас в проектах всегда хорошая архитектура? Вы никогда не беретесь за legacy? Завидую по обоим пунктам
(Вообще же, не бывает «плохой» или «хорошей» архитектуры, бывает архитектура, которая решает задачу или не решает. А еще бывает, что сначала нужно написать быстро, поэтому написано «плохо», а потом есть время на переписать «хорошо», и вот тогда польза от автоматических средств рефакторинга встает в полный рост.)
Насколько я понял, мы не сходимся в другом: у меня объектное мышление, я сначала размышляю над объектами и группирую их в классы, а затем реализую логику, вы же наоборот, мыслите с точки зрения логики и сначала реализуется один метод длиной в 200 строк, а затем разделяете его на классы и методы. Естественно у меня задачи в выделении (extract) классов, методов и свойств не возникает, так как все уже выделено на момент написания тестов. Видимо именно на такой подход, который используете вы, и рассчитаны современные IDE.
Что же касается функциональности и аргумента вида «почему за 40 лет...», я реализую это в Vim, вы готовы будите перейти на него?
Что же касается функциональности и аргумента вида «почему за 40 лет...», я реализую это в Vim, вы готовы будите перейти на него?
Подход, который вы описываете, называется не TDD, а BDUF (big design upfront). У него есть недостатки (которые то же TDD и призвано решать).
И прошу вас, не надо мне приписывать те утверждения (про метод в 200 строк и аргументов «почему за 40 лет»), которых я не делал.
И прошу вас, не надо мне приписывать те утверждения (про метод в 200 строк и аргументов «почему за 40 лет»), которых я не делал.
Подход, который вы описываете...
Я тоже об этом думал, затем пришел к выводу, что я все же не пользую BDUF, так как не продумываю архитектуру системы полностью, а обдумываю только классы. Разрабатываю через тесты, потому не считаю, что я далек от TDD, просто подход у меня другой. Я начинаю с классов, затем перехожу к методам и их тестированию. Вы же наоборот, сначала методы, затем классы. Я считаю это процедурным программированием через тестирование с появлением классов в результате. Именно отсюда и возникает необходимость всех этих рефакторингов в будущем. Честно говоря, даже не представляю, какие классы у вас в результате получаются.
И прошу вас, не надо мне приписывать...
Так вы с этим не согласны? Это радует. Но все же, если я реализую такой рефакторинг в Vim, вы на него перейдете?
Нет, я не пишу «сначала методы, а потом классы», это очередное приписанное мне утверждение. Но я на горьком опыте выяснил подвижность системы в ходе разработки.
Мне искренне интесно, вы действительно никогда не работаете с чужим кодом? С legacy-кодом? Даже если так, то неужели у вас никогда не бывает, что к уже обрабатываемой системе сущности через три месяца добавляется новая, и у них нужно выделять общее поведение?
И да, если вы реализуете в vim все, что мне удобно в visual studio, и при этом он (а) будет работать не медленнее и (б) будет бесплатным, я на него перейду.
Мне искренне интесно, вы действительно никогда не работаете с чужим кодом? С legacy-кодом? Даже если так, то неужели у вас никогда не бывает, что к уже обрабатываемой системе сущности через три месяца добавляется новая, и у них нужно выделять общее поведение?
И да, если вы реализуете в vim все, что мне удобно в visual studio, и при этом он (а) будет работать не медленнее и (б) будет бесплатным, я на него перейду.
это очередное приписанное мне утверждение
Общаясь одновременно на одну тему с 4 собеседниками, не мудрено запутаться, извиняюсь.
С legacy-кодом?
На работе никогда, а вот в свободное время приходится. Решается изучением legacy перед использованием. Чаще я выкидываю большую часть этого кода и переписываю под себя, благо такие проекты не большие.
выделять общее поведение
Такого не бывает у меня.
мне удобно в visual studio
Ну как я понял, это рефакторинг?
>> Решается изучением legacy перед использованием.
>> Чаще я выкидываю большую часть этого кода и переписываю под себя, благо такие проекты не большие.
Ну то есть в ситуации «вот тебе, деточка, работающая enterprise-система, в ней нужно докрутить то и то, тесты? какие тесты?» вы никогда не оказывались?
>> Такого не бывает у меня.
Не бывает общего поведения? Не бывает добавления новых сущностей?
>> Ну как я понял, это рефакторинг?
Далеко не только. Вам правда надо перечислить все возможности, которыми я пользуюсь в повседневной разработке?
>> Чаще я выкидываю большую часть этого кода и переписываю под себя, благо такие проекты не большие.
Ну то есть в ситуации «вот тебе, деточка, работающая enterprise-система, в ней нужно докрутить то и то, тесты? какие тесты?» вы никогда не оказывались?
>> Такого не бывает у меня.
Не бывает общего поведения? Не бывает добавления новых сущностей?
>> Ну как я понял, это рефакторинг?
Далеко не только. Вам правда надо перечислить все возможности, которыми я пользуюсь в повседневной разработке?
вот тебе, деточка
Нет, с таким я не работаю. В личных проектах приходилось, но IDE не использовал, ибо все решалось дописанием, а не вынесением, переименованием и другим рефакторингом.
Не бывает общего поведения?
В том смысле, к которому клоните вы, нет, не бывает. Если у меня есть два схожих класса, то все их общее поведение уже вынесено в абстрактного родителя. Я это делаю как то машинально.
Не бывает добавления новых сущностей?
Бывает, но здесь функции рефакторинга IDE не нужны. Даже не представляю, как они здесь могут использоваться?
Вам правда надо перечислить все возможности...
Я в свободное время занимаюсь допиливанием Vim, а такая творческая работа всегда упирается в вопрос — что надо реализовать? Сейчас я реализую собственные хотелки, но хочу реализовать и часто используемые другими программистами функции.
>> Нет, с таким я не работаю.
У меня чем дальше, тем больше создается ощущение, что вы работаете не в той же отрасли, что и я. Legacy-проектов у вас нет. Проектов с плохой архитектурой у вас нет. С чужим кодом вы не взаимодействуете. Покрытие TDD у вас полное. Зависть, что тут еще сказать?
>> Если у меня есть два схожих класса, то все их общее поведение уже вынесено в абстрактного родителя.
>> [Добавление новых сущностей] Бывает, но здесь функции рефакторинга IDE не нужны
Повторю ситуацию еще раз: у вас есть проект, в котором (в рамках определенного модуля) есть сущность с неким поведением. Поскольку эта сущность с таким поведением одна, никакого абстрактного родителя у нее нет (YAGNI). В ходе развития проекта в него добавляется новая функциональность, благодаря чему появляется новая сущность со поведением, которое частично дублирует поведение существующей сущности (и вообще относится к той же группе). Я в такой ситуации выделяю базовый класс и выношу общую функциональность в него. А вы?
>> такая творческая работа всегда упирается в вопрос — что надо реализовать?
В моем случае: начните с полного feature list Resharper + dotCover, добавьте туда же прозрачную интеграцию с VCS и CI, пакетный менеджер (nuget) и статический анализ, семантическую навигацию по коду, декомпиляцию, отладку и поддержку source server — а потом можно будет возвращаться к этому разговору.
У меня чем дальше, тем больше создается ощущение, что вы работаете не в той же отрасли, что и я. Legacy-проектов у вас нет. Проектов с плохой архитектурой у вас нет. С чужим кодом вы не взаимодействуете. Покрытие TDD у вас полное. Зависть, что тут еще сказать?
>> Если у меня есть два схожих класса, то все их общее поведение уже вынесено в абстрактного родителя.
>> [Добавление новых сущностей] Бывает, но здесь функции рефакторинга IDE не нужны
Повторю ситуацию еще раз: у вас есть проект, в котором (в рамках определенного модуля) есть сущность с неким поведением. Поскольку эта сущность с таким поведением одна, никакого абстрактного родителя у нее нет (YAGNI). В ходе развития проекта в него добавляется новая функциональность, благодаря чему появляется новая сущность со поведением, которое частично дублирует поведение существующей сущности (и вообще относится к той же группе). Я в такой ситуации выделяю базовый класс и выношу общую функциональность в него. А вы?
>> такая творческая работа всегда упирается в вопрос — что надо реализовать?
В моем случае: начните с полного feature list Resharper + dotCover, добавьте туда же прозрачную интеграцию с VCS и CI, пакетный менеджер (nuget) и статический анализ, семантическую навигацию по коду, декомпиляцию, отладку и поддержку source server — а потом можно будет возвращаться к этому разговору.
У меня чем дальше, тем больше создается ощущение, что вы работаете не в той же отрасли, что и я.
По порядку:
— Legacy нет, так как наша работа заключается в написании приложений под конкретные требования, а не работа с чужими приложениями. Приложения мы пишем так, чтобы всем все было ясно даже после нескольких месяцев
— Не то что с плохой, скорее с непонятной. Если и есть плохая архитектура, то это от моей перфекционисской природы доводить код до совершенства
— С чужим кодом не взаимодействуем. Обмениваемся данными либо по API, либо по заранее оговоренным текстовым форматам
— Покрытие тестами быть полным не может, это слишком сложная задача, но у нас оно достаточное для быстрого и хорошего тестирования с выявлением всех неоднозначностей в случае изменений. Тем более изменяя структуру проекта, я знаю, покроет ли мой тест эти изменения или нет. Если нет, я дописываю тест.
Повторю ситуацию еще раз...
Я заранее продумываю структуру так, что те «плавающие» классы или пакеты, которые могут поменяться или дополниться в будущем, сопровождались родителями, в которые весь повторяющийся функционал можно будет выносить.
которое частично дублирует поведение существующей сущности...
Никогда не встречался с этим. Если в системе есть такая функциональность, которая может быть расширена в будущем (новый справочник, новый документ, новый API), все это реализуется с заделом на будущее, то есть так, чтобы эти расширения вносились без необходимости переписывания существующего кода (по возможности).
>> По порядку:
Я и говорю — другая отрасль. Сплошной идеальный brown field. Завидую.
>> Я заранее продумываю структуру так, что те «плавающие» классы или пакеты, которые могут поменяться или дополниться в будущем,
А откуда вы знаете, может класс поменяться или дополниться в будущем?
>> Если в системе есть такая функциональность, которая может быть расширена в будущем (новый справочник, новый документ, новый API), все это реализуется с заделом на будущее
А как же YAGNI?
(по моему опыту, любая функциональность может быть расширена в будущем, но почти всегда та, для которой точки расширения были написаны заранее, расширяться не будет)
Я и говорю — другая отрасль. Сплошной идеальный brown field. Завидую.
>> Я заранее продумываю структуру так, что те «плавающие» классы или пакеты, которые могут поменяться или дополниться в будущем,
А откуда вы знаете, может класс поменяться или дополниться в будущем?
>> Если в системе есть такая функциональность, которая может быть расширена в будущем (новый справочник, новый документ, новый API), все это реализуется с заделом на будущее
А как же YAGNI?
(по моему опыту, любая функциональность может быть расширена в будущем, но почти всегда та, для которой точки расширения были написаны заранее, расширяться не будет)
Все вопросы сводятся к
К примеру, при разработке системы для учета деятельности, скажем, ГИБДД, расширяться могут следующие элементы системы:
— Новые справочники — реализуется через добавление новой сущности (Entity), а в них нет логики
— Новые документы — реализуется так же, как справочник, но так как родителем всех документов является класс Doc, в него же можно вынести всю логику простой копипастой, но это редко происходит
— Новые загрузки/выгрузки данных — рефакторинг здесь не нужен, это совершенно новый функционал
— Новые отчеты и печатные формы — рефакторинг так же не нужен, там все автоматизировано
— Новые экраны — реализована возможность наследования экранов (xml), но эта возможность частная и возможности IDE на нее не распространяются
Все эти компоненты реализуются достаточно гибко, менять их легко. На практике исключений из этого правила еще не было.
А откуда вы знаете, может класс поменяться или дополниться в будущем?
К примеру, при разработке системы для учета деятельности, скажем, ГИБДД, расширяться могут следующие элементы системы:
— Новые справочники — реализуется через добавление новой сущности (Entity), а в них нет логики
— Новые документы — реализуется так же, как справочник, но так как родителем всех документов является класс Doc, в него же можно вынести всю логику простой копипастой, но это редко происходит
— Новые загрузки/выгрузки данных — рефакторинг здесь не нужен, это совершенно новый функционал
— Новые отчеты и печатные формы — рефакторинг так же не нужен, там все автоматизировано
— Новые экраны — реализована возможность наследования экранов (xml), но эта возможность частная и возможности IDE на нее не распространяются
Все эти компоненты реализуются достаточно гибко, менять их легко. На практике исключений из этого правила еще не было.
Я смотрю, у вас нигде нет «новый бизнес-процесс». Ну-ну.
Ну и да, два вида сущностей — справочники и документы — это, конечно, круто, но вот у нас в учетной системе только в одной функциональной зоне их больше десятка только учитываемых, а еще есть вспомогательные. Я уж не говорю о том, что у вас вообще не описана инфраструктурная часть системы, где все еще любопытнее.
Ну и да, два вида сущностей — справочники и документы — это, конечно, круто, но вот у нас в учетной системе только в одной функциональной зоне их больше десятка только учитываемых, а еще есть вспомогательные. Я уж не говорю о том, что у вас вообще не описана инфраструктурная часть системы, где все еще любопытнее.
Я смотрю, у вас нигде нет «новый бизнес-процесс».
Да, забыл сказать, бизнес-процессы у нас реализуются с помощью механизма, называемого «Дизайнером процессов». Программирование мышкой по большей части. Расширяется так же мышкой. Даже если на этом этапе появится потребность в вынесении общей логики в некий общий процесс, то IDE не поможет, так как «Дизайнер процессов» имеет свой GUI.
Можете привести пару примеров ваших сущностей?
>> Даже если на этом этапе появится потребность в вынесении общей логики в некий общий процесс, то IDE не поможет, так как «Дизайнер процессов» имеет свой GUI.
На этом моменте зависть закончилась и перешла в сочувствие.
>> Можете привести пару примеров ваших сущностей?
Легко. Сначала некий механизм работал только со зданиями, а потом потребовалось добавить обработку долей тех же зданий.
Но в общем уже более-менее понятно, что у вас весьма конкретная ситуация, практически не пересекающаяся по потребностям с теми методами разработки, которые используем мы (ну и многие другие программисты в мире).
На этом моменте зависть закончилась и перешла в сочувствие.
>> Можете привести пару примеров ваших сущностей?
Легко. Сначала некий механизм работал только со зданиями, а потом потребовалось добавить обработку долей тех же зданий.
Но в общем уже более-менее понятно, что у вас весьма конкретная ситуация, практически не пересекающаяся по потребностям с теми методами разработки, которые используем мы (ну и многие другие программисты в мире).
у вас весьма конкретная ситуация, практически не пересекающаяся по потребностям с теми методами разработки, которые используем мы
Об этом я и говорю )
Это не означает, что другие методы разработки — плохо или свидетельствуют о плохой архитектуре (как вы выше писали о рефакторинге).
Я не писал о других методах разработки, я писал следующее:
Другими словами, я не вижу необходимости в этой функциональности для проектов с хорошей архитектурой и тестами.
Было дело я писал довольно крупную систему на PHPStorm и восхищался функциями рефакторинга от JetBrains, но после перехода на Vim я понял, что я этими функциями практически не пользовался. Приходилось и выносить логику, и изменять семантику, но я делал это достаточно быстро и легко без использования функций рефакторинга. На практике я заметил прирост в производительности моего труда именно благодаря возможностями Vim, так как они используются ежесекундно при разработке. Рефакторинг IDE же, я использовал пару раз в месяц и это экономило мне минут 5 от силы.
рефакторинг в IDE это функция, которая нужна для проектов с плохой архитектурой
Другими словами, я не вижу необходимости в этой функциональности для проектов с хорошей архитектурой и тестами.
Было дело я писал довольно крупную систему на PHPStorm и восхищался функциями рефакторинга от JetBrains, но после перехода на Vim я понял, что я этими функциями практически не пользовался. Приходилось и выносить логику, и изменять семантику, но я делал это достаточно быстро и легко без использования функций рефакторинга. На практике я заметил прирост в производительности моего труда именно благодаря возможностями Vim, так как они используются ежесекундно при разработке. Рефакторинг IDE же, я использовал пару раз в месяц и это экономило мне минут 5 от силы.
>> я не вижу необходимости в этой функциональности для проектов с хорошей архитектурой и тестами.
… вот только для того, чтобы получилась хорошая архитектура, в ряде случаев нужен рефакторинг. Для кода без ошибок тоже тесты не нужны, только мы же их пишем?
(не говоря уже о том, что контрпример вам привели как минимум один)
>> Рефакторинг IDE же, я использовал пару раз в месяц
А я использую десятки раз в неделю.
… вот только для того, чтобы получилась хорошая архитектура, в ряде случаев нужен рефакторинг. Для кода без ошибок тоже тесты не нужны, только мы же их пишем?
(не говоря уже о том, что контрпример вам привели как минимум один)
>> Рефакторинг IDE же, я использовал пару раз в месяц
А я использую десятки раз в неделю.
Другими словами, я не вижу необходимости в этой функциональности для проектов с хорошей архитектурой и тестами
Либо у вас архитектура сделана «на вырост» то есть избыточно сложна для текущей задачи, либо вы просто не видите какого-то дублирования кода (а скорее всего, и то и другое).
Как только появляется новое требование, заранее не предусмотренное (а оно появляется практически всегда) есть шанс что захочется сделать какой то код более общим — вынести функции, базовые классы и т.д.
Модно это переноса ручками, надеясь на тесты, но зачем, если есть инструменты, которые обеспечат это за счет последовательности гарантированно корректных трансформаций
«Новые справочники — реализуется через добавление новой сущности (Entity), а в них нет логики»
А если при расширении списка entity выяснилось, что новая похожа на старую, но отличается?
В общем, как мне кажется вы просто какое-то дублирование кода не видите и принимаете как должное
А если при расширении списка entity выяснилось, что новая похожа на старую, но отличается?
В общем, как мне кажется вы просто какое-то дублирование кода не видите и принимаете как должное
В общем, как мне кажется вы просто какое-то дублирование кода не видите и принимаете как должное
Если в двух сущностях есть 2-3 одинаковых поля (на пример ФИО), мы естественно ничего никуда не выносим, а дублируем эти поля. Чтобы было понятнее приведу такой пример: если у нас есть сущность Правонарушитель с полями ФИО и появляется сущность Участковый с полями ФИО, мы эти ФИО не выносим в новую сущность Физлицо. Методы в сущностях дублировать не могут, там кроме геттеров и сеттеров нет методов.
если есть инструменты, которые обеспечат это за счет последовательности гарантированно корректных трансформаций
Не гарантированно-корректных. Были уже случаи, когда эти гарантированные механизмы ломали код так, что найти ошибку было крайне сложно.
>> если у нас есть сущность Правонарушитель с полями ФИО и появляется сущность Участковый с полями ФИО, мы эти ФИО не выносим в новую сущность Физлицо
А если полей не два, а пять? А если к ним привязаны сложные валидационные правила?
>>Методы в сущностях дублировать не могут, там кроме геттеров и сеттеров нет методов.
А где вся логика тогда?
А если полей не два, а пять? А если к ним привязаны сложные валидационные правила?
>>Методы в сущностях дублировать не могут, там кроме геттеров и сеттеров нет методов.
А где вся логика тогда?
А если полей не два, а пять? А если к ним привязаны сложные валидационные правила?
Так не бывает. Мы не создаем системы учета всего, предметная область достаточно узкая. Даже если появится необходимость вынести поля из двух классов в один, то это дело 10 минут, да и операция столь редкая, что не требует автоматизации.
А где вся логика тогда?
Часть в иерархии Карточка <|- Документ, часть в службах (регистрируемые модули), часть в модулях ядра системы (права доступа, отчеты, процессы).
Так не бывает.
Как не бывает? Не бывает пяти общих полей? Не бывает сложных валидационных правил?
Часть в иерархии Карточка <|- Документ, часть в службах (регистрируемые модули), часть в модулях ядра системы (права доступа, отчеты, процессы).
Карточки — не сущности? В сервисах и модулях не бывает описанной ситуации (при появлении новой сущности появляется дублирующаяся функциональность)?
Как не бывает?
Да, у наших сущностей не бывает более 2-3 общих полей. Не бывает сложных валидационных правил.
Карточки — не сущности?
Абстрактный класс. Конечно можно считать ее сущность, так как наследование и прочее, но все уже давно вынесено и повторного вынесения не будет, потому логика этого класса не важна.
В сервисах и модулях не бывает описанной ситуации?
Как я уже говорил выше, если и бывает, то крайне редко, а значить автоматизации не требует. Другими словари мы не выносим общую логику и не создаем общие классы по нескольку раз в день, это редкое событие.
Описанное вами означает, что у вас нет эволюционного развития системы (что, впрочем, видно и по вашему отношению к легаси).
1. то есть принимаете как должное
Угу, когда вы обнаружите, что участковые и правонарушители могут выти замуж и поменять фамилию, придется изменять все места использования для обращения к истории. То есть у этих «сущностей» не отделен интерфейс от реализации.
2. Я сам с таким не сталкивался в решарпере. Возможно, в каких-то случаях это и так.
Методы в сущностях дублировать не могут, там кроме геттеров и сеттеров нет методов.
Угу, когда вы обнаружите, что участковые и правонарушители могут выти замуж и поменять фамилию, придется изменять все места использования для обращения к истории. То есть у этих «сущностей» не отделен интерфейс от реализации.
2. Я сам с таким не сталкивался в решарпере. Возможно, в каких-то случаях это и так.
Угу, когда вы обнаружите...
Не обнаружим, так как пользователь никогда не будет заниматься сменой фамилий и тому подобным для истории, он просто создаст нового участкового и правонарушителя с тем же именем, но другой фамилией. Только прошу не предлагать рубить нам руки, уж такие люди работают с программой и их ни уволить, ни переучить нельзя (пробовали). Все учтено, система функционирует три года, пережила 2 модернизации (довольно крупные) и гарантированно-корректных механизмов не потребовалось.
он просто создаст нового участкового и правонарушителя с тем же именем, но другой фамилией.
Жесть. А как они их идентифицируют? Отличают от однофамильцев.
Все учтено, система функционирует три года, пережила 2 модернизации (довольно крупные) и гарантированно-корректных механизмов не потребовалось.
Ок. Тут не поспоришь, просто потому, что я не могу проверить помог бы вам рефакторинг или нет. По-моему опыту — скорее всего что-то типа парадокса блаба мешает вам увидеть выгоды.
Жесть. А как они их идентифицируют? Отличают от однофамильцев.
У правонарушителя есть паспортные данные, а участковых-однофамильцев не дублируют, это не важно, кто именно создал дело на правонарушителя.
А если паспорт меняется, заводят еще одного правонарушителя?
Понятно. Но в целом — проблем нет, потребности в рефакторинге нет :)
Понятно. Но в целом — проблем нет, потребности в рефакторинге нет :)
Зачем же заводить нового, когда есть старый и можно поменять паспорт там?
Потребность в рефакторинге то есть, только далеко не ежедневная. Все изменения заранее обдумываются, а не делаются на абум по первому требованию.
Потребность в рефакторинге то есть, только далеко не ежедневная. Все изменения заранее обдумываются, а не делаются на абум по первому требованию.
>>Зачем же заводить нового, когда есть старый и можно поменять паспорт там?
А как вы его идентифицируете, если потенциально, он может поменять и фамилию?
И как у вас реализуется запрос типа «показать все правонарушения данного правонарушителя»?
Раскажите вообще о юзкейзах системы.
>>Потребность в рефакторинге то есть, только далеко не ежедневная. Все изменения заранее обдумываются, а не делаются на абум по первому требованию.
Если рефакторинг дешевый, то можно получать от этого выгоду. Вплоть до переименования класса, когда уточнилось обозначение термина просто чтобы согласовать UI и код.
Если так не делать, надо где-то держать модель предметной области, пока дизайн не устоится — то есть код будет дублировать какие-то дизайн документы.
А как вы его идентифицируете, если потенциально, он может поменять и фамилию?
И как у вас реализуется запрос типа «показать все правонарушения данного правонарушителя»?
Раскажите вообще о юзкейзах системы.
>>Потребность в рефакторинге то есть, только далеко не ежедневная. Все изменения заранее обдумываются, а не делаются на абум по первому требованию.
Если рефакторинг дешевый, то можно получать от этого выгоду. Вплоть до переименования класса, когда уточнилось обозначение термина просто чтобы согласовать UI и код.
Если так не делать, надо где-то держать модель предметной области, пока дизайн не устоится — то есть код будет дублировать какие-то дизайн документы.
И как у вас реализуется запрос типа «показать все правонарушения данного правонарушителя»?
Ну естественно, если мы изменим правонарушителю паспорт, то и его искать будем по новым данным паспорта. Зачем нам в базе данные о его прежнем паспорте или девичья фамилия?
В частности эта система служит для учета правонарушений, получения печатных и отчетных форм. Думаю отчетные формы вам наиболее интересны. Как правило это информация о правонарушениях за последний квартал с разноской по статьям, исполняемости и так далее. Информация трехлетней давности никого не интересует. Если заинтересует, получить ее не проблема, даже с изменением паспортных данных (писал выше).
Если рефакторинг дешевый...
Все термины и подобное изучаются и описываются еще на этапе анализа предметной области, ошибок в этом не бывает (хорошие у нас аналитики).
Почему код должен дубливать что то?
Зачем нам в базе данные о его прежнем паспорте или девичья фамилия?
Я не знаю специфики вашей задачи. Может быть тупо сверка с бумажкой которая была неделю назад до перемены фамилии.
Может вы хотите отличить злостных рецидивистов от новичков.
Все термины и подобное изучаются и описываются еще на этапе анализа предметной области, ошибок в этом не бывает (хорошие у нас аналитики).
К сожалению проверить не могу, но модель предметной области где нету сущности нарушитель, а где есть нечто, что потенциально может являться нарушителем, но его может быть один или два мне кажется, мягко говоря, неидеальной.
Почему код должен дубливать что то?
Потому, что аналитики пишут бумажку, допустим, где написано что у
Нарушителя может быть атрибут фамилия, потом эта бумажка уточняется и дополняется потом пишут по ней код в котором написано
class CriminalBastard{ string Surname }
что дублирует эту бумажку. То есть это те же сведения, но в другой форме. Потом это начинает модифицироваться и бумажка синхронизируется программистом с кодом ручную, в результате, как правило, детали разъезжаются.
Это есть или можно реализовать в Vim довольно просто (UltiSnips).
А в emacs/vim много чего «или есть», но окаывается, что нет, но «можно довольно просто реализовать». А когда оказывается, что «довольно просто» требует немалого количества человеко-часов для реализации, то включается мантра «да это просто не нужно, в emacs/vim есть <перечисления аналогов, которые не выполняют всех требований, но можно смириться при большой любви к редактору>, которые даже удобней» ;)
Вообще, если продвинутый рефакторинг и intellisense так просто реализуются на emacs/vim, то удивляет, почему за 40/25 лет никто добрый не сел и не написал этих инструментов.
Вообще, если продвинутый рефакторинг и intellisense так просто реализуются на emacs/vim, то удивляет, почему за 40/25 лет никто добрый не сел и не написал этих инструментов.
>> Не встречал еще таких программистов, которые пишут класс не зная, какие у него зависимости.
Поздравляю вас, встретили.
>> 1. Переименование методов — автоматически переименовываются все вызовы этих методов. На деле это настолько редкая операция, что я воспользовался ею ниразу;
>> 2. Переименование классов — автоматически переименовываются все точки инстанциации или использования. Операция еще более редкая, нежели предыдущая.
То есть еще реже, чем «ни разу»? Любопытно.
У меня и те, и другие переименования — это совершенно типовой процесс, происходящй несколько раз за задачу.
>> Все другие типы рефакторинга в IDE реализуются путем:
Вообще-то, есть все операции с иерархиями (Extract base class / Interface, Push / pull member), да и тот же Extract method.
>> Как раз благодаря TDD и продумывания архитектуры мы избавляемся от этого сложного рефакторинга
Если вы способны так продумать архитектуру, что у вас потом не происходит ее изменения, то либо вы гений, которых не знает современное SE, либо у вас очень простые задачи. Итеративную разработку (включая то же TDD) не на пустом месте придумали.
(заметим, мы еще не коснулись изменений требований, причем прямо в процессе реализации)
Поздравляю вас, встретили.
>> 1. Переименование методов — автоматически переименовываются все вызовы этих методов. На деле это настолько редкая операция, что я воспользовался ею ниразу;
>> 2. Переименование классов — автоматически переименовываются все точки инстанциации или использования. Операция еще более редкая, нежели предыдущая.
То есть еще реже, чем «ни разу»? Любопытно.
У меня и те, и другие переименования — это совершенно типовой процесс, происходящй несколько раз за задачу.
>> Все другие типы рефакторинга в IDE реализуются путем:
Вообще-то, есть все операции с иерархиями (Extract base class / Interface, Push / pull member), да и тот же Extract method.
>> Как раз благодаря TDD и продумывания архитектуры мы избавляемся от этого сложного рефакторинга
Если вы способны так продумать архитектуру, что у вас потом не происходит ее изменения, то либо вы гений, которых не знает современное SE, либо у вас очень простые задачи. Итеративную разработку (включая то же TDD) не на пустом месте придумали.
(заметим, мы еще не коснулись изменений требований, причем прямо в процессе реализации)
Все операции с иерархиями легко реализуются в Vim с помощью тех же snippets и некоторой логики на Python. Я не считаю это рефакторингом с помощью IDE. Для меня рефакторинг через IDE это поиск вхождений и их правильная замена на изменившуюся архитектуру. Для Extract base class / Interface, Push / pull member IDE без помощи программиста сделать ничего не может, а с помощью программиста может и Vim.
По поводу продумывания архитектуры, возможно у меня очень простые задачи, не могу оценить.
Изменения требований никак не касаются хорошо слаженного кода. Изменения требований либо заставит вас полностью переписать проект, и тут никакая IDE не спасет, либо изменить логику некоторых методов, тут так же нужны руки программиста, а не редактор.
По поводу продумывания архитектуры, возможно у меня очень простые задачи, не могу оценить.
Изменения требований никак не касаются хорошо слаженного кода. Изменения требований либо заставит вас полностью переписать проект, и тут никакая IDE не спасет, либо изменить логику некоторых методов, тут так же нужны руки программиста, а не редактор.
>> некоторой логики на Python.
Я помню, кто-то что-то говорил о простоте? Так вот, в решарпере это сделать быстрее и проще.
>> Для Extract base class / Interface, Push / pull member IDE без помощи программиста сделать ничего не может
Ээээ, я не понимаю вашу логику. Все, что делает программист — это говорит «выдели вот эти методы (галочка, галочка, галочка) в новый базовый класс», а дальше IDE все делает сама. Не понимаю, чем это отличается от «переименуй этот метод» или «измени порядок параметров», которые IDE тоже без помощи программиста сделать не может.
>> либо изменить логику некоторых методов, тут так же нужны руки программиста, а не редактор.
Неплохо бы при изменении логики видеть, что поплывет — вот вам и работа для IDE. А еще изменение логики ведет к изменению набора зависимостей (привет моему примеру выше) и сигнатур, что тоже прекрасно делается современными средствами рефакторинга.
Я помню, кто-то что-то говорил о простоте? Так вот, в решарпере это сделать быстрее и проще.
>> Для Extract base class / Interface, Push / pull member IDE без помощи программиста сделать ничего не может
Ээээ, я не понимаю вашу логику. Все, что делает программист — это говорит «выдели вот эти методы (галочка, галочка, галочка) в новый базовый класс», а дальше IDE все делает сама. Не понимаю, чем это отличается от «переименуй этот метод» или «измени порядок параметров», которые IDE тоже без помощи программиста сделать не может.
>> либо изменить логику некоторых методов, тут так же нужны руки программиста, а не редактор.
Неплохо бы при изменении логики видеть, что поплывет — вот вам и работа для IDE. А еще изменение логики ведет к изменению набора зависимостей (привет моему примеру выше) и сигнатур, что тоже прекрасно делается современными средствами рефакторинга.
Я помню, кто-то что-то говорил о простоте? Так вот, в решарпере это сделать быстрее и проще.
Если что то есть из коробки, это совсем не значит, что оно быстрее и проще. Под простотой я подразумиваю минимальное число действий и удобный интерфейс в конечном счете, возможно за это придется заплатить предварительной настройкой, но какого программиста это пугает?
Ээээ, я не понимаю вашу логику.
Объясню проще — это можно сделать с помощью Vim без помощи прославленного рефакторинга современных IDE. Если речь идет о таких операциях, как перенос чего либо куда либо, для этого не нужна IDE весом в 1Гб.
Неплохо бы при изменении логики видеть, что поплывет — вот вам и работа для IDE.
Я вижу что поплыло запуская тесты.
>> Под простотой я подразумиваю минимальное число действий и удобный интерфейс в конечном счете
Вот «удобный интерфейс» в vim — это для меня новость.
>> возможно за это придется заплатить предварительной настройкой, но какого программиста это пугает?
Меня пугает. Я не хочу тратить время на настройку чего-то, я хочу просто работать.
>> Если речь идет о таких операциях, как перенос чего либо куда либо, для этого не нужна IDE весом в 1Гб.
vim для этого тоже не нужен, достаточно вообще любого редактора. Но мы же говорим о простоте и удобстве? IDE с рефакторингом сделает это быстрее и гарантированно правильно. Программист руками — медленнее и с потенциальными ошибками. Зачем тратить на это его ресурсы?
>> Я вижу что поплыло запуская тесты.
При условии, что у вас гарантированное стопроцентное тестовое покрытие, причем быстрыми тестами. Аналогично, в этом случае я вам искренне завидую. У меня (ни в одной команде) так никогда не было, и не думаю, что когда-либо будет.
Вот «удобный интерфейс» в vim — это для меня новость.
>> возможно за это придется заплатить предварительной настройкой, но какого программиста это пугает?
Меня пугает. Я не хочу тратить время на настройку чего-то, я хочу просто работать.
>> Если речь идет о таких операциях, как перенос чего либо куда либо, для этого не нужна IDE весом в 1Гб.
vim для этого тоже не нужен, достаточно вообще любого редактора. Но мы же говорим о простоте и удобстве? IDE с рефакторингом сделает это быстрее и гарантированно правильно. Программист руками — медленнее и с потенциальными ошибками. Зачем тратить на это его ресурсы?
>> Я вижу что поплыло запуская тесты.
При условии, что у вас гарантированное стопроцентное тестовое покрытие, причем быстрыми тестами. Аналогично, в этом случае я вам искренне завидую. У меня (ни в одной команде) так никогда не было, и не думаю, что когда-либо будет.
Вот «удобный интерфейс» в vim — это для меня новость.
Ну это субъективно, для меня GUI менее удобен, проще хоткеи.
Меня пугает.
Меня нет. Когда нужен некий функционал прямо сейчас, я пользую IDE, а в свободное время дописываю Vim. Интересное занятие.
vim для этого тоже не нужен, достаточно вообще любого редактора. Но мы же говорим о простоте и удобстве?
Как же не нужен, результат будет такой же, как в современных IDE (абсолютно такой же), а вес и время работы в десяток раз ниже.
Программист руками — медленнее и с потенциальными ошибками.
Зачем же руками? Я же говорю, выделить блок кода в отдельный метод в Vim можно командно.
При условии, что у вас...
Если уж вы используете TDD, то как же вы не доверяете своим тестам? Если вы не доверяете тестам, то логике IDE не стоит доверять тем более.
>> выделить блок кода в отдельный метод в Vim можно командно
Дело в том, что выделение блока кода в отдельный метод не сводится в Copy/Paste, и в общем случае требует разбора логики и синтаксиса текущиего ЯП.
Подозреваю, что самостоятельно писать «почти-компилятор» будет несколько трудоемко, а скопировать, да, можно быстро.
Дело в том, что выделение блока кода в отдельный метод не сводится в Copy/Paste, и в общем случае требует разбора логики и синтаксиса текущиего ЯП.
Подозреваю, что самостоятельно писать «почти-компилятор» будет несколько трудоемко, а скопировать, да, можно быстро.
не сводится в Copy/Paste...
А можно здесь подробнее? Как я уже говорил раньше, с такой задачей не сталкивался на практике, потому интересно, что нынче используется в IDE.
самостоятельно писать...
К этому сейчас и движусь, позже опишу, насколько это трудоемко было )
Вот пример из очень старой версии того же решарпера.
Сложность в том, что вы должны проанализировать используемые переменные в блоке кода и сформировать из них сигнатуру нового метода + возвращаемое значение, которое может быть как в return, так и через out/ref (в случае с C#).
А еще бывают не только локальные переменные, но и поля класса и тп.
В общем, это трудоемко…
Сложность в том, что вы должны проанализировать используемые переменные в блоке кода и сформировать из них сигнатуру нового метода + возвращаемое значение, которое может быть как в return, так и через out/ref (в случае с C#).
А еще бывают не только локальные переменные, но и поля класса и тп.
В общем, это трудоемко…
В данном конкретном примере это просто, но я не сомневаюсь, что есть более запутанные варианты. Я с таким в работе сталкиваюсь не часто, а если сталкиваюсь, то анализирует за меня юнит-тест, а компилятор сообщает, чего не хватает. С другой стороны я не доверяю IDE большие и сложные блоки кода, были случае когда она мне корявила их.
Я понял, в моей работе перемещение по проекту и размышления о нем встречаются чаще, потому в такой функциональности нет необходимости.
Благодарен за разъяснение.
Я понял, в моей работе перемещение по проекту и размышления о нем встречаются чаще, потому в такой функциональности нет необходимости.
Благодарен за разъяснение.
Вот только речь шла не о выделении кода в метод (хотя и и тут будут проблемы с правильным выделением его параметров), а о работе с иерархиями. И я даже не сомневаюсь, что это тоже можно рано или поздно реализовать в vim, я просто не хочу тратить свое время на эту реализацию.
TDD в реальных проектах не может дать полного покрытия быстрыми тестами. А в тех проектах, на которых я работаю, TDD есть далеко не везде (не говоря уже о том, что я предпочитая сначала анализировать последствия своих изменений, нежели потом разбираться с неочевидными ошибками в тестах совсем не на это).
TDD в реальных проектах не может дать полного покрытия быстрыми тестами. А в тех проектах, на которых я работаю, TDD есть далеко не везде (не говоря уже о том, что я предпочитая сначала анализировать последствия своих изменений, нежели потом разбираться с неочевидными ошибками в тестах совсем не на это).
в конечном счете, возможно за это придется заплатить предварительной настройкой, но какого программиста это пугает?
Т.е. получаем, что «цель существования системы — это существование системы»?
Все удобство Vim в данном случае нивелируется необходимостью постоянной настройки.
lair, у меня вот в емаксе и Extract Method, и умное переименование и семантическая fuzzy-навигация по солюшну есть, и даже анализ кода с быстрыми фиксами аля решарпер. И к виму это все прикручивается элементарно.
Delphinum, у меня вот в Visual Studio, если покопаться легко находится ряд команд, которые прямо начинаются со слова Emacs. А до 2010 студии прям из коробки была схема управления под емакс — msdn.microsoft.com/en-us/library/ms165509(v=vs.90).aspx
Пользуюсь часто и тем и другим, смысла вашего спора не понимаю.
Delphinum, у меня вот в Visual Studio, если покопаться легко находится ряд команд, которые прямо начинаются со слова Emacs. А до 2010 студии прям из коробки была схема управления под емакс — msdn.microsoft.com/en-us/library/ms165509(v=vs.90).aspx
Пользуюсь часто и тем и другим, смысла вашего спора не понимаю.
Спор — из-за позиции «если чего в студии нет, то это значит, что студия плохая, а если чего в емаксе нет, то это либо можно доделать, либо не нужно».
Перечитал ветку, и ни разу не встретил слов — студия плохая. Спор из-за позиции — emacs/vim древняя, никому не нужная секта, с ограниченным функционалом.
Пост:
Вы:
Ну и до кучи, вы же:
Я еще не говорил, что IDE в сравнении с Emacs идут лесом? А, ну вот, сказал.
Вы:
Разница тут в том, что в Vim (не знаю про Emacs) эти же операции делаются проще и быстрее.
Ну и до кучи, вы же:
рефакторинг в IDE это функция, которая нужна для проектов с плохой архитектурой.
Фанаты вима в каждом подобном посте хвастаются возможностями перейти «на 3 слова влево», «на 5 символов вправо», «на 6 строк вниз». Представьте себе кусок кода на любом языке — функции, условия, циклы, классы. Когда вам там надо переходить «на 3 слова влево» или «на 5 символов вправо»? И вы их как — сначала считаете, а потом набираете?
Да и вообще именно набор кода должно занимать примерно 10-20% от общего времени у программиста
Все проще. Есть такое понятие, как относительная нумерация строк. Это как обычная нумерация, только она привязана к текущей строке (в которой курсор). Текущая строка имеет номер 0, строки выше и ниже нумеруются итеративно. Следовательно сразу видно сколько раз надо повторить переход вверх или вниз.
Так же есть команды для перенода к началу объявления функции, условия, цикла и так далее.
Так же есть команды для перенода к началу объявления функции, условия, цикла и так далее.
Во-первых все намного проще: в Vim «одним словом» будет, собственно, слово, либо набор символов, находящихся рядом (например «>=» будет словом). Во-вторых никто их специально не считает, они оцениваются навскидку, «на глаз». Конечно, как наберетесь опыта, будете промахиваться очень редко, а до тех пор иногда придется доводить курсор вручную. Но даже в этих случаях вы будете в выигрыше, как правило.
Как уже упоминали, есть
set relativenumber. Но если хочется попадать сразу куда-то, то есть плагины вроде Easy Motion (в том числе и для Sublime Text). В этом случае скорость зависит только от знания раскладки клавиатуры.
именно из-за этих возможностей Вим очень хорош, когда нужно быстренько зайти на удаленный сервер в условиях ужасной связи и что-нибудь там поправить.
>Это очень круто, потому что если ваш слепой набор базируется не на отличной ориентации в пространстве — когда вы можете держа пальцы, где угодно, попасть не глядя на любую клавишу — а на расположении указательных пальцев на засечках кнопок «f,j»
Это вариант слепого набора, созданный, чтобы машинистку на курсах можно было быстро обучить печатать 200 символов в минуту и быстро отправить работать. Плохой он по причине здоровья, руки сохнут, приходится покупать эргономичные клавы, но проблему неподвижности рук это не решает. Кто у нас известный страдалец от туннельного синдрома? Столлман. Привет, C-n/C-p.
Руки должны двигаться, никакой причины воспитывать в себе двигательную лень нет, ничего общего со производительностью труда программиста нет тоже.
Это вариант слепого набора, созданный, чтобы машинистку на курсах можно было быстро обучить печатать 200 символов в минуту и быстро отправить работать. Плохой он по причине здоровья, руки сохнут, приходится покупать эргономичные клавы, но проблему неподвижности рук это не решает. Кто у нас известный страдалец от туннельного синдрома? Столлман. Привет, C-n/C-p.
Руки должны двигаться, никакой причины воспитывать в себе двигательную лень нет, ничего общего со производительностью труда программиста нет тоже.
То есть вы предлагаете намерено снижать производительность из за боязни тунельного синдрома? Может проще вспомнить детскую игру «Наши пальчики писали»?
Как вы решаете проблему с ухудшением зрения?
Как вы решаете проблему с ухудшением зрения?
SLOC — это не производительность программиста, хотя это очень обидно для современного индуса.
Вы ушли от темы. Используя совершенно любой редактор программист может заработать тунельный синдром, если он будет 8 рабочих часов клацать по клавишам без перерыва. Как мы знаем, такого на практике нет, если и есть, то это не проблема конкретного редактора, а проблема работодателя.
Что же касается реального положения дел, а именно 10 минут написания кода — 30 минут размышлей, то тунельный синдром вам не грозит, а вот гонять руку между клавиатурой и мышкой не приятно. Еще более не приятно, это думать, что без такого непродуктивного действия вы следите за своим здоровьем.
Так я получу ответ на свой вопрос касательно ухудшения зрения? Может стоит каждые 2 секунды автоматически отключать монитор, дабы глаза не расслаблялись?
Что же касается реального положения дел, а именно 10 минут написания кода — 30 минут размышлей, то тунельный синдром вам не грозит, а вот гонять руку между клавиатурой и мышкой не приятно. Еще более не приятно, это думать, что без такого непродуктивного действия вы следите за своим здоровьем.
Так я получу ответ на свой вопрос касательно ухудшения зрения? Может стоит каждые 2 секунды автоматически отключать монитор, дабы глаза не расслаблялись?
Получайте ответы от megalol. Ведь можно и геморрой заработать, или даже умереть.
Гонять руку между клавиатурой и мышкой мне не сложно, тем более, что это то же усилие, что и shift+f6 для рефакторинга.
Я не вижу ухудшения производительности (на самом деле, вижу даже увеличение — если верить доступным мне метрикам) из-за того:
— что у меня за все мои 14 лет за компьютерами до сих пор полуслепой набор
— что я люблю и уважаю мышку
— что я автоматизирую свои действия с помощью IDE, регулярок и вдумчивого подхода к задаче
— что я ношу очки с антибликовым покрытием
— что я раз в час-два хожу курить или пройтись по коридору подумать
— что я хожу на обед не торопясь вернуться
У каждого свой подход и влияние на производительность (кроме того, зависит от языка, отрасли, предметной области и выбранного подхода к архитектре). Смысл первого коммента был в том, что в случае слепого набора руки остаются в относительной неподвижности дольше, чем в других случаях.
Гонять руку между клавиатурой и мышкой мне не сложно, тем более, что это то же усилие, что и shift+f6 для рефакторинга.
Я не вижу ухудшения производительности (на самом деле, вижу даже увеличение — если верить доступным мне метрикам) из-за того:
— что у меня за все мои 14 лет за компьютерами до сих пор полуслепой набор
— что я люблю и уважаю мышку
— что я автоматизирую свои действия с помощью IDE, регулярок и вдумчивого подхода к задаче
— что я ношу очки с антибликовым покрытием
— что я раз в час-два хожу курить или пройтись по коридору подумать
— что я хожу на обед не торопясь вернуться
У каждого свой подход и влияние на производительность (кроме того, зависит от языка, отрасли, предметной области и выбранного подхода к архитектре). Смысл первого коммента был в том, что в случае слепого набора руки остаются в относительной неподвижности дольше, чем в других случаях.
Дольше, но не настолько, чтобы заработать тунельный синдром. Не стоит оправдывать свое нежелание постигать слепой метод печати.
Слушайте, ну восторженность фанов вима понятна. Я так же фанатею от многих вещей.
Проблема в том — что у меня нет нежелания постигать такое великое изобретение человечества, как слепой метод печати. Наверное, потому что я прагматичный человек, и меня (и мою производительность) скорость устраивает (единственное, когда не хватает — при написании литературных текстов, когда, действительно, могу забыть придуманный третий абзац). Я лучше подниму свои 400 слов в минуту скорочтения, или еще чем дельным займусь.
Повторюсь, моя претензий к вашему комментарию была всего одна — вам почему-то кажется, что отсутствие скоропечатания машинистки и умения удалить каждое третье выражение в скобках, как-то снижает производительность современного программиста. Исследования говорят, что это не так. Иследования еще говорят, что SLOC/день — это не производительность программиста
Проблема в том — что у меня нет нежелания постигать такое великое изобретение человечества, как слепой метод печати. Наверное, потому что я прагматичный человек, и меня (и мою производительность) скорость устраивает (единственное, когда не хватает — при написании литературных текстов, когда, действительно, могу забыть придуманный третий абзац). Я лучше подниму свои 400 слов в минуту скорочтения, или еще чем дельным займусь.
Повторюсь, моя претензий к вашему комментарию была всего одна — вам почему-то кажется, что отсутствие скоропечатания машинистки и умения удалить каждое третье выражение в скобках, как-то снижает производительность современного программиста. Исследования говорят, что это не так. Иследования еще говорят, что SLOC/день — это не производительность программиста
Слушайте, ну восторженность фанов вима понятна.
А при чем здесь Вим? Мы говорим о применении слепого метода печати. megalol указал, что слепой метод печати плох тем, что может вызвать тунельный синднорм. Я возразил, что тунельный синром появляется от непрерывного пользования клавиатуры руками и отказываться от столь производительного инструмента, как слепой метод печати, ради ошибочного предположения, глупо.
Когда вы программируете глядя на свой код, оцениваете то, что уже написано и думаете о том, что следует написать в дальнейшем, а не смотрите на клавиатуру в поисках очередной буквы и не гоняете правую руку между клавиатурой и мышью, ваша производительность возростает в разы.
О каких исследованиях речь, можно ссылки?
Не люблю авторитетов, но давайте обсудим классические книги Макконела и «Мифический человеко-месяц» тогда уж. Что вы вкладываете в слово «производительность»? Что будем использовать метрикой для производительности программиста (или для измерения качества программы)? Как будем сравнивать полуслепой метод и слепое скоропечатание с правильным положением рук? А если сравнивать скоропечатание с рутинными операциями рефакторинга и интеллисенс IDE (и, например, использование регулярок, best praсtices, паттернов и прочих инструментов для увеличения скорости разработки)?
Не люблю я и вики в качестве примеров, но копаться в мед исследованиях о туннельных не вижу возможности, но:
Судя по тому, что я вижу, важную роль в формировании проблем с запястьем играет монотонность операций, повторяемые одинаковые нагрузки и определенное положение рук. Исходя уже из этого, можно предположить, что слепой набор, требующий определенного положения рук, освобождая их от лишних движений, может вызывать подобное с большей вероятностью. Особенно на подавляющем количестве неэргономичных клавиатур. Но это субъективно.
Не люблю я и вики в качестве примеров, но копаться в мед исследованиях о туннельных не вижу возможности, но:
Синдро́м запя́стного кана́ла (карпальный туннельный синдром, англ. carpal tunnel syndrome, CTS) — неврологическое заболевание, проявляющееся длительной болью и онемением пальцев кисти. Относится к группе туннельных невропатий. Причиной заболевания является сдавление срединного нерва между костями и сухожилиями мышц запястья.
Синдром запястного канала наиболее часто встречается у женщин старшего возраста. Это заболевание считается профессиональным у работников, выполняющих монотонные сгибательно-разгибательные движения кисти (например, при сборке машин). Также этим заболеванием страдают сурдопереводчики и мотогонщики, пианисты, а также боулеры, барабанщики и нередко художники со стажем.
Широко распространено представление, что длительная ежедневная работа на компьютере, требующая постоянного использования клавиатуры, является фактором риска развития синдрома запястного канала.[1] Существует исследование, в котором синдром запястного канала выявлено у каждого шестого обследованного, работающего на компьютере.[2] Большему риску подвергаются те пользователи, у которых при работе с клавиатурой кисть разогнута на 20° и более по отношению к предплечью. В то же время другие научные исследования указывают на отсутствие достоверных различий в частоте возникновения этого синдрома в группе постоянно работающих с клавиатурой при сравнении с общим населением.[3]
Судя по тому, что я вижу, важную роль в формировании проблем с запястьем играет монотонность операций, повторяемые одинаковые нагрузки и определенное положение рук. Исходя уже из этого, можно предположить, что слепой набор, требующий определенного положения рук, освобождая их от лишних движений, может вызывать подобное с большей вероятностью. Особенно на подавляющем количестве неэргономичных клавиатур. Но это субъективно.
Вы меня не хотите слушать.
По поводу производительности:
Я уже писал выше, но перефразирую. Под производительностью я здесь понимаю число операций, которые способен выполнить программист за заданный промежуток времени. При слепом методе печати, действия автоматизируются на столько, что ваши мысли печатаются без вашего сознания. При полуслепом методе и использовании мыши, вам необходимо периодически подключать свое сознания, что влечет за собой необходимость временно отвлекаться от вашей текущей работы (мысли).
По поводу тунельного синдрома:
Современный программист это не наборщица текстов 30х годов. Вы не сможете использовать клавиатуру не отрываясь в течении всего рабочего дня, чтоб заработать себе этот синдром. Я бы понял отказ от профессии программиста из за ухудшения зрения, но тунельный синдром для меня за рамками понимания.
По поводу производительности:
Я уже писал выше, но перефразирую. Под производительностью я здесь понимаю число операций, которые способен выполнить программист за заданный промежуток времени. При слепом методе печати, действия автоматизируются на столько, что ваши мысли печатаются без вашего сознания. При полуслепом методе и использовании мыши, вам необходимо периодически подключать свое сознания, что влечет за собой необходимость временно отвлекаться от вашей текущей работы (мысли).
По поводу тунельного синдрома:
Современный программист это не наборщица текстов 30х годов. Вы не сможете использовать клавиатуру не отрываясь в течении всего рабочего дня, чтоб заработать себе этот синдром. Я бы понял отказ от профессии программиста из за ухудшения зрения, но тунельный синдром для меня за рамками понимания.
1. Сферический конь в вакууме.
2. Отказ от вещи, от которой не зависит чуть более, чем ничего — свободный выбор свободного программиста.
2. Отказ от вещи, от которой не зависит чуть более, чем ничего — свободный выбор свободного программиста.
Ну право ваше, не буду спорить.
Черт. Это вы не хотите слушать меня, просто хотели в чем-то убедить/поспорить.
Я вам привел аргументы, вы мне ответили «сферическим конем в вакууме». Какой смысл в дальнейшей дискуссии?
Нет корреляции между «число операций, которые способен выполнить программист за заданный промежуток времени», а также «действия автоматизируются на столько, что ваши мысли печатаются без вашего сознания» с любой реальной метрикой, которой можно измерить производительность программиста, увязывая хоть с бизнес-задачами, хоть с уровнем зарплаты программиста, хоть с качеством кода (она субъективна, но можно выделить хоть какие-то метрики), да даже с выполнением сроков. К т.н. «потоку» скорость набора текста также относится мало — в отличие от тех же литературных текстов, с искусственными языками проще запоминать, что надо писать дальше, т.к. программист при наборе мыслит не конструкциями языка (циклы, условия), а абстракциями (чем выше квалификация программиста — тем выше абстракция), а конструкции вылетают из него автоматически.
Все это рассосано текстами, которые служат гайдами программистам уже не первое десятилетие. Простите.
Я правда желал от вас аргументов.
Все это рассосано текстами, которые служат гайдами программистам уже не первое десятилетие. Простите.
Я правда желал от вас аргументов.
Я вам эти аргументы привел. Вы оцениваете работу программиста в масштабе всего проекта, а мы говорим о написании кода в частности. Другими словами, у вас появилась идея реализовать некий метод, которого нет в вашем классе, но который ему очень нужен. Вы садитесь за компьютер и держа в голове идею, начинаете реализовывать этот метод параллельно изменяя идею для решения возникающих в процессе реализации задач. Вы не задумываетесь о поиске клавишь или мыши на столе, а быстро переносите вашу идею в реализованый код.
Повторю мой основной аргумент еще раз, когда вы используете слепой метод печати, вы не отвекаетесь на решение задач набора текста, так как эти задачи решает подсознание. Если же вы не пользуете слепой метод, вам приходится периодически, хоть и не на долго, прерывать свой ход мыслей и направлять мыслительную деятельность в другое русло. Речь не о программировании в контексте оценки структуры, изучения связей, проектировании и так далее, я говорю о моменте начала и окончания написания кода в редакторе руками.
Повторю мой основной аргумент еще раз, когда вы используете слепой метод печати, вы не отвекаетесь на решение задач набора текста, так как эти задачи решает подсознание. Если же вы не пользуете слепой метод, вам приходится периодически, хоть и не на долго, прерывать свой ход мыслей и направлять мыслительную деятельность в другое русло. Речь не о программировании в контексте оценки структуры, изучения связей, проектировании и так далее, я говорю о моменте начала и окончания написания кода в редакторе руками.
Ок. Слепой набор увеличивает скорость ввода символов предельно до скорости мысли, который этот код придумывает (иф-наше условие-делаем то-то-елс-не делаем плохого). Спасибо, очень полезно.
Более того, если управление редактором осуществляется с помощью клавишь с буквами, то управлять редактором так же становится намного быстрее.
>megalol указал, что слепой метод печати плох тем, что может вызвать тунельный синднорм.
Я этого не говорил. Вслепую можно печатать и без десятипальцевого метода. Я говорил о том, что гордиться тем, что руки прилипли к f/j не стоит.
Я этого не говорил. Вслепую можно печатать и без десятипальцевого метода. Я говорил о том, что гордиться тем, что руки прилипли к f/j не стоит.
Те, кто говорят, что полноценная IDE круче, просто не в курсе, что все их фичи в Емакс либо есть, либо могут быть доустановлены.
Ну да, но при этом нету ни одной инструкции, в которой бы давались советы, как начиная от «лысого» Emacs получить что-то, что реализует функционал хотя-бы упомянутого QtCreator'а. И когда дело касается конкретных, типичных, юзкейсов, которые необходимы при работе с кодом, а не только общих слов аля «в emacs можно все настроить», оказывается, что за 40 лет существования редактора никто этого не сделал и неплохо бы самому сесть и написать на elisp себе IDE.
И тут возникает диллема: либо сидеть и писать себе IDE на elisp, либо брать и использовать готовую (хоть тотже QtCreator).
Чего не хватает до QtCreator? Для автодополнения устанавливается «company-mode», у него есть набор бэкендов, с которых он может брать дополнения. Из них для семантического дополнения С++ приходят в голову «company-clang» и «company-gtags»(последний берет дополнения из GTAGS, которыми надо предварительно пропарсить проект). Проверка синтаксиса реализуется с помощью «flycheck-mode».
Как я уже упомянул, Емакс действительно предварительно надо настраивать, по-умолчанию там ничего нет. Зато его можно применять для разработки на любом языке, чего не скажешь о большинстве IDE, которые, в основном, узкоспециализированы. И, как результат, сегодня вы, скажем, писали на С++ в VS, а завтра будете писать на Perl, разумеется в другой IDE, с другими шорткатами, другим интерфейсом, и, возможно, отличающимся функционалом.
Как я уже упомянул, Емакс действительно предварительно надо настраивать, по-умолчанию там ничего нет. Зато его можно применять для разработки на любом языке, чего не скажешь о большинстве IDE, которые, в основном, узкоспециализированы. И, как результат, сегодня вы, скажем, писали на С++ в VS, а завтра будете писать на Perl, разумеется в другой IDE, с другими шорткатами, другим интерфейсом, и, возможно, отличающимся функционалом.
Большинство кода у меня пишется на связке C++ и CMake для автоматизации сборки, ну и плюс еще внешние библиотеки(которые подключаются через CMake'овский find_package(...) ). QtCreator из коробки понимает проекты основанные на CMake. Т.е. просто открывая такой проект у меня автоматически индексируются все указанные в CMakeLists.txt библиотеки, дерево проекта, и по умолчанию сразу работает автодополнение и переходы к объявлениям функций/классов.
В Emacs я сколько не пытался настроить редактор под этот кейс (вообщемто я нуб в этом деле, emacs пробуй недавно), у меня так и не получилось настроить такое же поведение. Автодополнение через yasnippet — это просто убожество, autocomplete-clang не умеет автоматически подтягивать нужные пути из cmake'а, cmake-mode и cmake-ide делают явно что-то отличное от индексирования дерева проекты, Ctags — не умеет делать семантический анализ, да и каждый раз подгружать нужные ctag-файлы тот еще геморой.
Сколько я не искал информацию по тому, как собрать себе IDE для такого юзкейса — не нашел ничего дельного. И я сильно сомневаюсь, что я первый, кому необходим подобный функционал…
И сомнительное преимущество, мириться с довольно серьезными неудобствами редактора, ради возможности использовать его при программировании на других языках.
В Emacs я сколько не пытался настроить редактор под этот кейс (вообщемто я нуб в этом деле, emacs пробуй недавно), у меня так и не получилось настроить такое же поведение. Автодополнение через yasnippet — это просто убожество, autocomplete-clang не умеет автоматически подтягивать нужные пути из cmake'а, cmake-mode и cmake-ide делают явно что-то отличное от индексирования дерева проекты, Ctags — не умеет делать семантический анализ, да и каждый раз подгружать нужные ctag-файлы тот еще геморой.
Сколько я не искал информацию по тому, как собрать себе IDE для такого юзкейса — не нашел ничего дельного. И я сильно сомневаюсь, что я первый, кому необходим подобный функционал…
И сомнительное преимущество, мириться с довольно серьезными неудобствами редактора, ради возможности использовать его при программировании на других языках.
Вы меня заинтриговали. Ничего не могу ответить на этот счет сразу, но я на выходных попробую настроить свой Emacs под такой случай; о результатах отпишусь.
И, если получится, желательно отдельным постом… Ибо я тоже несколько раз неудачно пытался настроить семантическое автодополнение в Emacs… Если это возможно, хотелось бы посмотреть, как именно…
Чисто теоретически есть autocomplete-clang, который умеет делать семантические автодополнения. Но ему нужно явно прописывать откуда и какие хедера брать, а это не удобно тогда, когда от проекта к проекту исопльзуются различные библиотеки.
Сразу оговорюсь, что буду толковать про «company-mode», а не про «autocomplete-mode», потому что предположительно он проще в конфигурации, ну и я привык его использовать. Впрочем для «autocomplete-mode» принцип должен быть схожим. На всякий случай добавлю, что «company-mode» имеется
в Elpa и Melpa, т.е. для установки достаточно ввести «package-list-packages», и выбрать его для установки(только ссылки на сайты должны быть настроены).
В принципе, я нашел только два варианта, и в обоих случаях пути к инклудам вам придется добавлять вручную. Первый — использование, собственно, clang. Это backend «company-clang». Пути к хедерам можно прописать в переменной «company-clang-arguments». Она хранит список аргументов, которые будут переданы в clang. Делается это приблизительно следующим образом:
Для тех, кто не знает: «list» создает список из последующих аргументов, коих может быть сколько угодно. Для «company-irony»(альтернатива к «company-clang». Так же использует «clang», плюс «irony-mode». Работает асинхронно), вероятно, надо использовать «irony-additional-clang-options». Хотя вообще в описании переменной стоит просьба этого не делать — я полагаю, что пути настраиваются в самом «irony-mode»; на его страничке упоминаются какие-то базы данных, но из краткого описания не понятно, как их использовать, а в подробности я вдаваться не стал.
Второй вариант — использование «company-semantic». Для этого предварительно надо включить «semantic-mode». Пути инклудов добавляются командой
Рекомендую так же включить «global-semanticdb-minor-mode» для кэширования, и «global-semantic-idle-scheduler-mode», чтобы semantic периодически заново парсил буферы, если были внесены изменения.
Вручную упомянутые бэкенды в переменную «company-backends» добавлять не надо, они там уже есть — если только не доустанавливаете что-то новое, вроде «company-irony». «company-mode» спрашивает поочередно со всех бэкендов, есть ли у него дополнение для кода, и, если какой-то бэкенд их возвращает, остальные спрашиваться не будут.
Так же упомяну переменную «company-idle-delay», которая означает время прежде, чем появятся дополнения. У меня в «.emacs» файле есть код
Так же добавлю, что по туториалам не так уж все и печально. Например вот тут имеется один просто восхитительный о том, как настроить Емакс для программирования с С/С++. Achtung — очень много текста и GIF-анимаций.
в Elpa и Melpa, т.е. для установки достаточно ввести «package-list-packages», и выбрать его для установки(только ссылки на сайты должны быть настроены).
В принципе, я нашел только два варианта, и в обоих случаях пути к инклудам вам придется добавлять вручную. Первый — использование, собственно, clang. Это backend «company-clang». Пути к хедерам можно прописать в переменной «company-clang-arguments». Она хранит список аргументов, которые будут переданы в clang. Делается это приблизительно следующим образом:
(setq company-clang-arguments (list "-I/path/number/one/" "-I/path/number/two/"))
Для тех, кто не знает: «list» создает список из последующих аргументов, коих может быть сколько угодно. Для «company-irony»(альтернатива к «company-clang». Так же использует «clang», плюс «irony-mode». Работает асинхронно), вероятно, надо использовать «irony-additional-clang-options». Хотя вообще в описании переменной стоит просьба этого не делать — я полагаю, что пути настраиваются в самом «irony-mode»; на его страничке упоминаются какие-то базы данных, но из краткого описания не понятно, как их использовать, а в подробности я вдаваться не стал.
Второй вариант — использование «company-semantic». Для этого предварительно надо включить «semantic-mode». Пути инклудов добавляются командой
(semantic-add-system-include "/my/path/")
Рекомендую так же включить «global-semanticdb-minor-mode» для кэширования, и «global-semantic-idle-scheduler-mode», чтобы semantic периодически заново парсил буферы, если были внесены изменения.
Вручную упомянутые бэкенды в переменную «company-backends» добавлять не надо, они там уже есть — если только не доустанавливаете что-то новое, вроде «company-irony». «company-mode» спрашивает поочередно со всех бэкендов, есть ли у него дополнение для кода, и, если какой-то бэкенд их возвращает, остальные спрашиваться не будут.
Так же упомяну переменную «company-idle-delay», которая означает время прежде, чем появятся дополнения. У меня в «.emacs» файле есть код
(setq-default company-idle-delay 0.5)
Так же добавлю, что по туториалам не так уж все и печально. Например вот тут имеется один просто восхитительный о том, как настроить Емакс для программирования с С/С++. Achtung — очень много текста и GIF-анимаций.
Плюсую, как фанат вима даже готов попробовать емакс.
В качестве тестового проекта можете попробовать LLVM :)
В качестве тестового проекта можете попробовать LLVM :)
Будет инетерсно посмотреть на ваши результаты.
Видел несколько различных инструкций по настройке emacs под мой кейс, но на практике они были сильно неудобными.
Видел несколько различных инструкций по настройке emacs под мой кейс, но на практике они были сильно неудобными.
Это все равно что из Tex делать Word. Не нужно, у них разные специализации. Писать диплом в Word не очень комфортно, но и WYSIWYG для Tex штука довольно убогая.
Редактор — это универсальная лошадка, которая работает везде и одинаково (sudo apt-get install emacs && ln -s ~/Dropbox/.emacs.d ~/.emacs.d, в Windows чуть подольше, и у тебя он полностью настроен как ты хочешь — причем все пакеты будут обновляться одновременно), ведь по сути это всего лишь интерпретатор. Редактор умеет работать по ssh весьма прозрачным образом, то есть граница между удаленной и локальной отладкой размывается, причем задержки уже не играют такой роли, как в случае vnc. Автодополнение? Автодополнение по словарю в текущем файлы по C-/ работает в 90% случаев, особенно когда файл уже достаточно большой это становится вообще очень удобнее того, что смотрит на AST. И это работает везде, и в python, и в Tex. Системы сборки? Я создаю в корне проекта run.sh и запускаю его по F5. И не важно, maven там, cmake, или быстро набросанный вызов g++ hello.cpp.
Из emacs сделать IDE не получится. Во-первых, emacs до сих пор однопоточный, и та самая работа по ssh блокирует интерфейс пока не сделает автосейв, что говорить о всяких идешных фоновых штучках? Во-вторых, elisp — не самая производительная вещь. В третьих — не нужно. Если редактор превратить в IDE — это получить все минусы плохой IDE типа «проектов» и прочей тяжести, а редактор должен быть легким. По-моему созданием IDE из emacs увлекается тот же красноглазый народ, который готов часами пересобирать ведро вместо работы и гордиться тем, как дико у него повысилась производительность от экономии движения рук в десять сантиметров.
IDE — штука специализированная. Один язык поддерживается хорошо, остальные — плохо или запускай другую в другом окне. Отсюда IDE не очень дружит с мультиязычными проектами, особенно отличными от html/css/js. В итоге вместо выбора языка под задачу, появляется соблазн сделать монолит из С++ с такой привычной и удобной IDE. Хотя если действительно имеешь дело с С++/JVM/.NET монолитом, лучше взять IDE. А редактор брать, когда уже понадобится поддерживать код. Такое мое мнение. Я, например, так и не понял дзен gdb в emacs и отлаживаю в QtCreator — благо, совместно они нормально работают.
Редактор — это универсальная лошадка, которая работает везде и одинаково (sudo apt-get install emacs && ln -s ~/Dropbox/.emacs.d ~/.emacs.d, в Windows чуть подольше, и у тебя он полностью настроен как ты хочешь — причем все пакеты будут обновляться одновременно), ведь по сути это всего лишь интерпретатор. Редактор умеет работать по ssh весьма прозрачным образом, то есть граница между удаленной и локальной отладкой размывается, причем задержки уже не играют такой роли, как в случае vnc. Автодополнение? Автодополнение по словарю в текущем файлы по C-/ работает в 90% случаев, особенно когда файл уже достаточно большой это становится вообще очень удобнее того, что смотрит на AST. И это работает везде, и в python, и в Tex. Системы сборки? Я создаю в корне проекта run.sh и запускаю его по F5. И не важно, maven там, cmake, или быстро набросанный вызов g++ hello.cpp.
Из emacs сделать IDE не получится. Во-первых, emacs до сих пор однопоточный, и та самая работа по ssh блокирует интерфейс пока не сделает автосейв, что говорить о всяких идешных фоновых штучках? Во-вторых, elisp — не самая производительная вещь. В третьих — не нужно. Если редактор превратить в IDE — это получить все минусы плохой IDE типа «проектов» и прочей тяжести, а редактор должен быть легким. По-моему созданием IDE из emacs увлекается тот же красноглазый народ, который готов часами пересобирать ведро вместо работы и гордиться тем, как дико у него повысилась производительность от экономии движения рук в десять сантиметров.
IDE — штука специализированная. Один язык поддерживается хорошо, остальные — плохо или запускай другую в другом окне. Отсюда IDE не очень дружит с мультиязычными проектами, особенно отличными от html/css/js. В итоге вместо выбора языка под задачу, появляется соблазн сделать монолит из С++ с такой привычной и удобной IDE. Хотя если действительно имеешь дело с С++/JVM/.NET монолитом, лучше взять IDE. А редактор брать, когда уже понадобится поддерживать код. Такое мое мнение. Я, например, так и не понял дзен gdb в emacs и отлаживаю в QtCreator — благо, совместно они нормально работают.
Полностью с вами согласен. Когда я правлю документацию, работаю с небольшими по размеру скриптами и т.п. то я использую emacs т.к. это удобно. Но когда дело касается болших проектов на C/C++ я все равно перехожу в QtCreator.
Кстати, кажется я встречал под emacs реализацию асинхронного autocomplete-clang, не уверен правда в том, что он исопльзует многопоточность.
А насчет gdb, советую посмотреть в сторону cgdb. Это консольный GUI для gdb, по моему очень удобная штука. Ну и в QtCreator кажется не весь функционал gdb проброшен.
Кстати, кажется я встречал под emacs реализацию асинхронного autocomplete-clang, не уверен правда в том, что он исопльзует многопоточность.
А насчет gdb, советую посмотреть в сторону cgdb. Это консольный GUI для gdb, по моему очень удобная штука. Ну и в QtCreator кажется не весь функционал gdb проброшен.
И когда дело касается конкретных, типичных, юзкейсов, которые необходимы при работе с кодом
При работе с кодом нет «необходимого», есть желательное, а оно субъективно. С переходом на Vim я понял, что большенство того, от чего я оргазмировал в IDE мне не нужно.
Вполне может быть, что вы просто привыкли обходится без многих фич «полноценных IDE», перейдя на Vim. При наличии этих фич в Vim вы вряд ли бы не стали ими пользоваться;)
Ну и популярность тогоже intellisense говорит о том, что это не моя индивидуальная прихоть, а он действительно необходим для комфортной работы с кодом для большого количества людей.
Ну и популярность тогоже intellisense говорит о том, что это не моя индивидуальная прихоть, а он действительно необходим для комфортной работы с кодом для большого количества людей.
При наличии этих фич в Vim вы вряд ли бы не стали ими пользоваться;)
Я уже писал выше, что сам использую IDE в своей работе (продукция JetBrains) и единственной фичей, которой я в ней пользуюсь, это переход к объявлению класса или метода с точки использования этого самого класса или метода (это есть в Vim).
Никогда не понимал людей, которые использую hot key по умолчанию в vim/emasc. Оба редактора становятся действительно удобными только тогда, когда начинаешь тонко настраивать их под себя. Уже давно пользуюсь Vim с конфигом основных, часто используемых функций через Alt. Жутко удобно и не так пальцевыламывательно как с Ctrl. Фокусы с Capsом не признаю по причине давней привычки вешать на него переключение раскладки.
НЛО прилетело и опубликовало эту надпись здесь
Да все подряд. Хотя в основном распространенные языки: C/C++/Java… Для Web бывает верстаю в нем же, соответственно добавляется JavaScript/PHP/CSS (подсветка синтаксиса работает из коробки). Сейчас вот еще потихоньку Python изучаю в свободное время. Стоит оговориться, что ни для одного из этих языков я не использую автодополнение. Как-то так повелось, что не особо в нем нуждаюсь. Если случается открыть какую-нибудь IDE и там оно есть то здорово (да и то не всегда использую, если честно), если нет, то совершенно не напрягает.
НЛО прилетело и опубликовало эту надпись здесь
Открыл для себя vim только после того как начал пользоваться расширением vimium в браузере, до этого ролики о том как хорош vim или emasc считал призывом присоединения к секте.
представьте, что вам надо переименовать локальную переменную под курсором
Есть ещё варианты:
γ) multiple cursors: последовательно выделяем переменную в нескольких местах, вводим новое имя, оно меняется везде (vim-multiple-cursors).
Demo
δ) если боитесь порезаться регуляркой, есть preview (vim-over).
Demo
А ещё у меня вопрос по поводу `hjkl`. Дело в том, что я являюсь гордым пользователем раскладки Colemak, на которой все эти клавиши приходятся на правый указательный палец, что неудобно. Ремаппинг на соответствующие `neio` я не делал и привык к тому, что было. Из-за этого теперь очень неудобно пользоваться `hjkl`. Понимаю, что я сам себе злобный буратино, но была ли у кого-нибудь похожая ситуация и кто что делал в таком случае?
Есть ещё варианты
Никогда не пойму 10 типов людей: тех, кто парсит html регэкспами и тех, кто регулярками рефакторит.
Благодаря clang есть свет в конце тоннеля: github.com/bbchung/clighter помимо семантической подсветки умеет семантическое преобразование. К сожалению, пока работает не всегда корректно + чтобы переименовать сивол во всем проекте, нужно открыть все требуемые файлы. Но есть надежда, что дальше будет лучше.
Мультикурсоры есть и в Sublime, и в VS, а с недавнего времени и во всех продуктах JetBrains. Плюс Text Replace регуляркой в IDEA-like IDE сделан, на мой взгляд, на порядок удобнее замены в консольных редакторах.
Более того, довольно недавно появилась такая мощная фича, как Structural Search and Replace.
Более того, довольно недавно появилась такая мощная фича, как Structural Search and Replace.
Не знаю какая у вас система, но под мак есть чудесная утилита «karabiner», которой можно перебиндить кнопки достаточно гибко. В частности там есть такой пресет (который можно подправить под neio):
Причем эта настройка действует по всей системе (что очень удобно). Возможно под другие ОС есть аналоги.
Причем эта настройка действует по всей системе (что очень удобно). Возможно под другие ОС есть аналоги.
Вместо multiple cursors рекомендую попробовать вот этот плагин
Долго пытался использовать стандатные комбинации emacs. Сейчас перешел на сильно кастомизированный ergoemacs.
Если кратко: очень много позиционных Meta-комбинаций, на левой руке модификация текста, на правой навигация, активно используется Shift. Навигация по тексу, например, M-j/k/l/i и S-M-j/k/l/i. Все это дело умеет автоматически переназначать позиционные клавиши в зависимости от раскладки (использую Colemak). Ну и стандартные C-c, C-x никуда не деваются (влючается в настройках ergoemacs'а).
Если кратко: очень много позиционных Meta-комбинаций, на левой руке модификация текста, на правой навигация, активно используется Shift. Навигация по тексу, например, M-j/k/l/i и S-M-j/k/l/i. Все это дело умеет автоматически переназначать позиционные клавиши в зависимости от раскладки (использую Colemak). Ну и стандартные C-c, C-x никуда не деваются (влючается в настройках ergoemacs'а).
моя раскладка
Забыт аргумент, который лично я всегда привожу против использования навороченных IDE. Если исходники в проекте измеряются гигабайтами, количество файлов сотнями тысяч, а время сборки часами, то очень быстро начинаешь люто ненавидеть все умные семантические автодополнения и прочие фичи полноценных IDE, потому что, не справляясь с объемами кода, они начинают сильно тормозить даже на топовых компах.
Вам не говорили про модули?
А Вы не хотите показать мастер-класс по модулям? chromium.googlesource.com/chromium/src/+/master
Держите открытым те модули, в которых что-то меняете. Для билда автодополнения не нужны. Единственный раз когда сталкивался с такой проблемой, это когда искал что-то в исходниках javascript'a в WebSphere Portal, но это крайность.
Да в том и дело, что открытыми держится несколько файлов, а навороченные ide индексируют весь проект, чтобы работали всякие автодополнения и прочее.
Так речь же шла про модули, а не файлы. Полностью индексируются только открытые модули (исходя из опыта с Eclipse и продуктами от Jetbrains)
А где комментарий про два режима работы, всё портить и пищать?
«Почему кнопка «n» на месте кнопки «b»? И какого хрена я только что нажал на кнопку «р», а эффект, как будто я нажал на клавишу "["?». Но поверьте, это пройдет.
Являясь счастливым обладателем вот такой клавиатуры
Скрытый текст
(простите, фотографировал на утюг)
(простите, фотографировал на утюг)
каждый раз, когда в нежно любимом мною vim нужно что-то скопировать (латинская y), а я промахиваюсь и нажимаю u, что приводит к переводу всего выделенного текста в lowercase, я испытываю прямо-таки нечеловеческий ангст, и это уже очень давно не проходит. Автор, что я делаю не так?
Это клавиатура для тренировки слепого набор по «бразильской системе»?:)
Ух, мышка с крылышками ε:
Я тоже раньше частенько путал «y» c «u». Дело опыта, не больше не меньше. Обычно я каждый раз, когда промахиваюсь, хотя по ощущениям не должен был, я всегда кладу пальцы, как они были только что на клавиатуре, и пытаюсь понять, как вышло, что расстояние до одной клавиши я спутал с расстоянием до соседней клавиши; давлю их еще раз, сначала одну, потом другую (что бы за клавиши это не были, всегда можно потом сделать undo). Это полезно, т.к. в конце-концов привыкаешь чувствовать это небольшое расстояние, и промахи становятся все реже и реже.
Еще один момент: доверяйте своей памяти. Если вы чувствуете, что это правильное расположение, но боитесь промахнуться, просто жмите — а там уже, если все плохо, действуйте, как я описал выше.
Я тоже раньше частенько путал «y» c «u». Дело опыта, не больше не меньше. Обычно я каждый раз, когда промахиваюсь, хотя по ощущениям не должен был, я всегда кладу пальцы, как они были только что на клавиатуре, и пытаюсь понять, как вышло, что расстояние до одной клавиши я спутал с расстоянием до соседней клавиши; давлю их еще раз, сначала одну, потом другую (что бы за клавиши это не были, всегда можно потом сделать undo). Это полезно, т.к. в конце-концов привыкаешь чувствовать это небольшое расстояние, и промахи становятся все реже и реже.
Еще один момент: доверяйте своей памяти. Если вы чувствуете, что это правильное расположение, но боитесь промахнуться, просто жмите — а там уже, если все плохо, действуйте, как я описал выше.
Еще в Емакс есть буфер «*scratch*». Это черновик, автоматически создается каждый раз, когда вы запускаете его. Там стоит предупреждение о его предназначении. Суть, что он по-умолчанию не сохраняется. Его можно применять для написания кратких мыслей, например, о том, как будет выглядеть ваша архитектура — просто, чтобы быть уверенным, что ничего не упущено. Или для тестирования регулярок, а может для краткой заметки, что доделать, как вы вернетесь с выходных (это, если вы, как я, не выключаете ПК — я его просто кидаю в гибернацию).
В чем ценность именно стирания при выключении, а не в произвольный момент времени?
Я использую для заметок OneNote — Win+N N и у меня новая заметка (куда можно вставлать картинки ссылки, чекбоксы для TODO и прочее)
Для тестирования регулярок — спец утилиту, которая представляет результат семантически с разбиениями на группы на вхождения и подсвечивая текст.
Для тестиро
Я использую для заметок OneNote
Как то попробовал его использовать (еще когда он только появился, это было вроде в 2007 офисе), но 20-ти секундная загрузка заметки лишила эту программу права на жизнь.
Во-первых лично у меня упомянутые мной заметки выглядят очень мусорно. Я могу просто оставить, скажем, пару ключевых слов в буфере «*scratch*», чтобы возвратившись с обеда что-то вспомнить и доделать. Создавать ради таких мелочей целую отдельную заметку как-то… Может быть, конечно, иногда и правильно, но мне лично не по душе. Впрочем, это субъективно.
Во-вторых, что более важно, мне не надо переключаться в отдельную программу для заметок, или тестирования регулярок. Нужно оттестировать регулярное выражение? Пожалуйста, скинуть в тот же черновик пример ключевых слов, затем «M-x re-builder» — он так же покажет результат, семантически, с отдельной подсветкой каждой группы. Справедливости ради, впрочем, его можно включить в любом буфере, но иногда так удобней.
Во-вторых, что более важно, мне не надо переключаться в отдельную программу для заметок, или тестирования регулярок. Нужно оттестировать регулярное выражение? Пожалуйста, скинуть в тот же черновик пример ключевых слов, затем «M-x re-builder» — он так же покажет результат, семантически, с отдельной подсветкой каждой группы. Справедливости ради, впрочем, его можно включить в любом буфере, но иногда так удобней.
А вы можете забывать на время что создаете новую заметку, а просто считать, что эта комбинация очищает буфер. Но если вдруг вспомните, можно включить м машину времени и посмотреть на созданное?
В vs gallery полно плагинов которые встраиваются прямо в среду.
— в простом случае не надо ничего набирать — дефолтный пример сразу при запуске
— совпадения видно сразу при наборе — не надо набрать run
— сразу видно разбиение на матчи и группы
Кстати, как у emacs с поддержкой нескольких мониторов?
В vs gallery полно плагинов которые встраиваются прямо в среду.
— в простом случае не надо ничего набирать — дефолтный пример сразу при запуске
— совпадения видно сразу при наборе — не надо набрать run
— сразу видно разбиение на матчи и группы
Кстати, как у emacs с поддержкой нескольких мониторов?
Кстати, как у emacs с поддержкой нескольких мониторов?
Не уверен, что правильно понял вопрос, но можно открыть несколько отдельных окон одной инстанции Емакса. Еще можно запускать Емакс сервер, и проассоциировать файлы с «emacsclient» → в этом случае каждый раз при двойном щелчке по файлу будет запускаться клиент, и подсоединяться к уже запущенному Емаксу.
>Кстати, как у emacs с поддержкой нескольких мониторов?
В emacs можно раздвоить любое окно по вертикали или по горизонтали. Поэтому я бы предложил растянуть окно на два монитора и создать вертикальную границу между ними. «Несколько системных окон одной инстанции» — не очень, потому что у меня на alt+стрелки висит переключение между окнами внутри системного окна, а с двумя окнами придется уже системный alt-tab использовать скорее всего.
А так из-за минималистичности интерфейса (по сути не относится к редактируемому тексту только статусная строка буфера), накогда не задумывался о втором мониторе, у меня обычно там браузер.
В emacs можно раздвоить любое окно по вертикали или по горизонтали. Поэтому я бы предложил растянуть окно на два монитора и создать вертикальную границу между ними. «Несколько системных окон одной инстанции» — не очень, потому что у меня на alt+стрелки висит переключение между окнами внутри системного окна, а с двумя окнами придется уже системный alt-tab использовать скорее всего.
А так из-за минималистичности интерфейса (по сути не относится к редактируемому тексту только статусная строка буфера), накогда не задумывался о втором мониторе, у меня обычно там браузер.
Иногда одними сплит-скринами сыт не будешь. Например, дома у меня стоит монитор «1920×1080», а рядом ноутбучный дисплей «1366×768». Растянуть программу на два экрана, конечно, можно (у меня так против моего желания поступает Xonotic, в который я изредка играюсь), но ничего хорошего из этого не выйдет.
А на работе у меня один монитор, и браузер обычно растянут на полный экран на отдельном рабочем столе.
А на работе у меня один монитор, и браузер обычно растянут на полный экран на отдельном рабочем столе.
Почему не выйдет? На слепую зону можно вывести пустое окно и забыть о нем. Ну то есть тупо расширить на весь экран на оба монитора, а далее через C-x 2 и C-x 2 создать нужное число окон, спрятав невидимые. Мне это нравится по причине того, что на alt-стрелки я могу переключаться между окнами внутри окна и одно большое окно позволяет не заморачиваться с мониторами.
Если интересует менее кустарный способ, через C-x 5 2 можно создать второй фрейм (системное окно), далее поместить его куда нужно, и через C-x 5 o переключаться между ними. Естественно, перебиндив переключение на что-то менее длинное.
Другой вопрос, зачем больше чем 1920х1080 редактора, если при 80 колонках минимум 6 окон можно открыть. В emacs комфортно работается даже на 800х600 (хотя для нетбучной клавиатуры наверное лучше vim).
Если интересует менее кустарный способ, через C-x 5 2 можно создать второй фрейм (системное окно), далее поместить его куда нужно, и через C-x 5 o переключаться между ними. Естественно, перебиндив переключение на что-то менее длинное.
Другой вопрос, зачем больше чем 1920х1080 редактора, если при 80 колонках минимум 6 окон можно открыть. В emacs комфортно работается даже на 800х600 (хотя для нетбучной клавиатуры наверное лучше vim).
Дык я ж менее кустарный способ выше и предлагал, вы сказали, что это не комильфо.
Лично мне больше, чем на «1920×1080» редактора не нужно, просто ответил к вопросу о мультимониторной конфигурации.
Лично мне больше, чем на «1920×1080» редактора не нужно, просто ответил к вопросу о мультимониторной конфигурации.
Я не говорил, что это не комильфо, просто упомянул способ, который мне нравится, а вы его не упомянули. Отвечал-то я вообще AppCoder. А так тут чистая вкусовщина. У меня на самом деле по F5 выполняется заданный compile-command, и поэтому я использую разные инстансы имакса под разные воркспейсы, так сказать. Можно было бы повесить больше функциональных клавиш (типа F5 компилирует С++, F7 — Java, F9 — запускает тесты), но этого нет, поэтому у меня бывал emacs на двух разных мониторах, но это были разные инстансы с соответствующим системным переключением между ними.
Что касается самого способа, я больше для себя написал, потому что предложение создать новое окно я увидел, а вот конкретный способ нет. Может AppCoder заинтересуется.
Что касается самого способа, я больше для себя написал, потому что предложение создать новое окно я увидел, а вот конкретный способ нет. Может AppCoder заинтересуется.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как я полюбил vim, Emacs и клавиатуру