на emacs 24 только недавно перешёл, не переходил на package, но возможно попробую на новом компе.
В Gentoo очень хорошая система управления пакетами, там 95% emacs-packages есть, ставяться легко, потому и особой необходимости не назрело.
Да. Нет в той модели UI, что применена в emacs возможности нарисовать вертикальную черту.
Те поделки на Lisp что есть существенно тормозят, сам же engine не предоставляет такого интерфейса. Впрочем я не сильно переживаю, это из разряда фич «было бы неплохо». Сейчас всё равно идёт «общая» проверка синтаксиса в т ч и на long lines так что функционально всё есть, просто по другому, менее визуально.
та да, мне тоже очень нравиться Sublime. денег на лицензию не жалко, жалко будет если что нибудь случиться с автором либо процессом разработки… если бы у него была хотя бы double license, пользовался бы с удовольствием, и допиливал бы на Python plugins тот функционал, к которому привык в emacs. Но, учитывая полное отсутствие сорцов в Sublime меня напрягает тратить свое время на него — я уже несколько раз в жизни обжигался, инвестировав своё время в чужой продукт. По функционалу Sublime мне наверное ближе всего к тому, что здесь описано. Vim правда тоже умеет много чего и местами больше. Остальные редакторы недотягивают. По средам лучшая коммерческая альтернатива emacs/python: PyCharm.
Я большой многолетний фан ноутбуков Dell, и всегда работаю только в Linux. Но Studio для Linux? Явно не самый удачный выбор… начнём с NVIDIA GeForce — последенее время я сильно разочаровался в обоих лидерах рынка — и Nvidia и ATI выпускают не самые лучшие устройства в плане совместимости с Linux. Постоянно из года в год одни и те же проблемы. С Intel проблем в десятки раз меньше. А глянец? По моему глянец или матовое — дело сугубо индивидуальное, тут в основном речь если нужна хорошая передача цветов (а такая бывает на t-n матрице) — лучше глянец. Если надо работать в разных условиях с разной освещенностью — однозначно матовое покрытие. Т е если судить с такой точки зрения то для разработчиков глянец — неудобно. Пару лет проработал на таком ноутбуке и больше никогда в жизни не куплю себе глянец. Некоторые владельцы Mac Book Air у нас честно завидуют моему Dell Vostro с матовым экраном.
Вообщем по моему схалтурили в компании Dell. Я понимаю ситуация происходила как то так: «надо выпустить ноутбук для Linux юзеров». — Какой там у нас недорогой и мощный? Studio?: Ok, Определились. Нет чтобы подобрать hardware для этой цели, а так… Фигня в общем
Я тоже долго не мог понять зачем в Python ограничили длинну строки в 80 символов. Поначалу думал что атавизм какой то, на современных мониторах можно намного больше. А тут недавно читал книжку по психологии дизайна (100 Things Every Designer Needs to Know About People) и там чётко дано разъяснение: по проведенному исследованию большинство людей предпочитают читать текст в 100 символов но при этом воспринимают (т е быстрее понимают) лучше текст в 80 символов. После понимания этого факта полностью поддерживаю разработчиков Python в этом ограничении.
Супер видео! Огромное спасибо! Тут как раз веду борьбу с заказчиком который хочет привязать зарплату к уровню достижения организацией определённых (читай маркетинговых) целей… Плохая идея — я ему уже не первый раз повторяю. Видео очень чётко и ясно даёт это понять ;-) В отместку за видео вот некоторые материалы которые я нарыл по мотивации за последнее время:
извиняюсь если не правильно включил данную статью к этой теме- по сути я занимаюсь web разработкой и применяю emacs именно там (python, javascript, html, css). просто в конкретно в этой статье-введении пока про это почти ни слова. но обязательно напишу в продолжении.
Если коротко — тем что предоставляет простой и понятный способ для расширения функционала, потому дополнения и модули легко дописываются желающими. Само название редактора говорит об этом (Editor MACroS). Прямо с 1х слов так и написано вот тут: en.wikipedia.org/wiki/Emacs.
Мало того, за 20 лет написано столько всяких расширений функционала, что почти в любой сфере находиться уже готовое решение, если эта сфера хоть как то связана с редактированием текста.
> Зачем в нём куча каких-то загадочных отдельных режимов
Если на все файлы один режим — то ни автоподсветки ни проверки кода на корректность, ни других удобных функций редактора не будет.
> Есть ли в нём интеграция с отладчиками (GDB, например)
Есть. Если интересны подробности — простой поиск gdb+emacs в google даёт много ссылок и видео. я лично не пользовался — сказать ничего не могу, но отладку Python делаю в pdb, довольно удобно. Всё управляется с клавиатуры и легко копировать туда-сюда куски кода. Но подход отличается в корне от IDE отладки.
> удобное автодополнение (в одно нажатие + автоматическое для объектов/структур)
могу ответить конкретно по Python- функция rope-lucky-assist, выдаёт первый вариант. Чаще всего это оно. Есть варианты как показать это в командной строке/IDO, или в выпадающем меню, но однажды поняв насколько удобен ido я pull-down менюшки отключил.
> поддержка сборки (Makefile и что-нибудь своё
Да я обычно жму функцию compile. Если возникает ошибка — быстрый переход на номер строки. Если их много — есть функция перехода next-previous, привязанная на удобную клавишу.
> но пока никто не отвечал
:-) Вот стараюсь ответить.
> Когда предлагают изучить новый инструмент, должно быть какое-то обоснование
Те, кто работает рядом сразу видят приемущества — это конечная скорость. Т е некоторые действия, на которые в emacs есть удобно заточенные функции можно делать в другом редакторе _намного_ дольше. Ну опять же — всё зависит от человека. Даже у нас в компании, есть те, кому безразлична скорость, точнее не хочется человеку ради того чтобы раз в месяц что нибудь сделать быстро учить так много :-) А есть те, кто осваивает. Всё что стараюсь я донести — 1) то что не так страшен чёрт, как его малюют. Есть менюха, начинать работать можно с нулевым уровнем, а потом можно улучшать настройки и до-включать всякие удобные модули. 2) в этом есть смысл. Я этот смысл вижу — как по себе, так и смотря на остальных, кто смог освоить.
Но так уж устроен человек, что ему лениво :-) Я это понимаю. Потому постараюсь в следующих статьях показать что именно я имею в виду под «скоростью» и какие фичи есть в emacs, которых не найти в самых модных IDE.
Шустрее — понятие относительное. У меня как раз наоборот — Linux/GTK vim отрисовывает намного медлнее чем emacs (тест — нажать pagedown на большом файле). По открытию файлов и т п — emacs очень быстрый, т е быстрее я редактора не видел. Различия начинаются если открывать действительно большие файлы — я заметил что emacs начинает притормаживать если открыть файл 60Mb размером, у gvim таких проблем не было. Редкое дело — редактироать такие большие файлы, а запустить gvim для такой цели не проблема.
Опа ;-) хоть кто то попробовал реально воспользоваться инструкцией! Извиняюсь, опечатка вышла. Закрыть файл — C-x k. Исправил в тексте. Никто не говорил что будет супер легко, особенно по сравнению с типичным редактором типа notepad2 или Kate. Но оно того стоит.
> открыть текстовый файл с листингом параметрами, изменить несколько параметров и вывести
> изменённые параметры
вот это поподробнее. просто не понял вопроса.
может программы не шибко сложные? я пользуюсь pdb (по одной кнопке ставиться через yasnippet) но он интегрирован с emacs через pdbtrack, так что код отображается по ходу нажатий клавиш. также очень удобно копировать прямо куски кода в выполняемый файл. про pdb и интеграцию с Emacs покажу на отдельном video. конечно можно было бы и лучше, я не спорю что в PyCharm отладчик на уровень приятнее, но пока хватает того что есть в emacs.
О! А можно поподробнее? Я пытался поработать в разных IDE, но по функционалу до Emacs не дотягивает, слабо подстраивается и тормозит. Если с тем, что тормозит смириться можно, но то что многие вещи приходиться тыкать мышой меня совсем не устраивают. Из IDE больше всего мне понравились для Python: PyCharm и WingIDE. Но минусы PyCharm — тормознутость и некоторая ограниченность функционала, а WingIDE слабо расширяется, обе коммерческие потому конечно и сравнивать не имеет смысла. А Eclipse как то совсем не пошёл… А в какой IDE работает автор комментария? Что именно стало продуктивнее по сравнению с emacs?
Если делать сравнения по идеологии клавиатурных нажатий между emacs и vim, то наверное нет особой разницы. Что в emacs что в vim основная задача — привязать тысячи доступных функций к довольно ограниченному набору клавиш, да ещё сделать это так, чтобы это было удобно. Я думаю
что в определённой степени оба редактора решают эту задачу, но соверненно разными способами. Я для себя заметил что мне удобнее пользоваться emacs т к _в основном_ я нахожусь в режиме редактирования при работе с текстом. Командный режим нужен реже. А кроме Vim я прошёл путь от: pe2, me, qedit, потом уже vi, vim, emacs, xemacs, kate. Смотрел на IDE: Komodo, Eclipse, WingIDE (+), PyCharm (+). Conclusion: все *java* IDE мне кажутся тормозами по сравнению с emacs, vim в то время как я им пользовался был не таким уж развесистым как сейчас, да и концепт там немного другой. Плюсики поставил IDEшкам что мне в общем понравились (в общем, не в деталях)
Про плагины был вроде тут пост на хабре: habrahabr.ru/post/126228/ — советую обратиться к нему. А вообще не так уж часто я это всё настраиваю. Система у меня Gentoo, да тут не сильно важно что за система. В самой системе почти все модули, которыми я пользуюсь есть. В общем ставлю пакет и добавяю require (я отключил autoload для _всех_ пакетов т к не всё что стоит с поддержкой emacs реально мной используется).
Хороший package manager был в xemacs, но увы, по скорости разработки и коммунити xemacs сильно отстаёт так что я им сейчас не пользуюсь.
Пробовал. Впечатления двоякие. Вроде как [должно быть] проще, но только стоит привыкнуть, как приходиться переучиваться, сидя за компом у у товарища рядом. Вроде как сконвертироал пару товарищей поменять Ctrl+Alt. Но прошло вот 2 года с момента этих экспериментов, и в результате у всех как обычно, а у двух человек — перевёрнуто. Вот и думай после этого стоит ли так радикально экспериментировать. Если чисто для себя это одно дело, а если иногда приходиться работать на разных клавиатурах или в парном программировании то наверное смысла нет.
Ну что сказать. Честно, картинки я никогда в Emacs не рисовал, а в сугубо практическом значении я пользуюсь таблицами в org-mode, просмотром PDF и картинок. Это очень удобно когда не надо вызывать внешнее приложение чтобы просто глянуть содержимое файла.
> вовне не копируется
Всё копируется. Дело тут наверное в том, что в X-windows существует так называемый Primary и Secondary selection. Попробуйте сделать Paste средней кнопкой мыши. А вообще чтобы эти primary/secondary не путались у меня всегда и в KDE -> Klipper и в Parcellite стоит "[x] Synhornize Primar and Secondary Selections"
В Gentoo очень хорошая система управления пакетами, там 95% emacs-packages есть, ставяться легко, потому и особой необходимости не назрело.
Те поделки на Lisp что есть существенно тормозят, сам же engine не предоставляет такого интерфейса. Впрочем я не сильно переживаю, это из разряда фич «было бы неплохо». Сейчас всё равно идёт «общая» проверка синтаксиса в т ч и на long lines так что функционально всё есть, просто по другому, менее визуально.
customize-group htmlize
а потом в перменной Htmlize Output Type выставить соответственно `font`
Вообщем по моему схалтурили в компании Dell. Я понимаю ситуация происходила как то так: «надо выпустить ноутбук для Linux юзеров». — Какой там у нас недорогой и мощный? Studio?: Ok, Определились. Нет чтобы подобрать hardware для этой цели, а так… Фигня в общем
1. www.cio.com/article/409063/Managing_and_Motivating_Developers_Tips_for_Management_Cluefulness
2. www.giovanniasproni.com/articles/MotivationTeamworkAndAgileDevelopment.pdf
Если коротко — тем что предоставляет простой и понятный способ для расширения функционала, потому дополнения и модули легко дописываются желающими. Само название редактора говорит об этом (Editor MACroS). Прямо с 1х слов так и написано вот тут: en.wikipedia.org/wiki/Emacs.
Мало того, за 20 лет написано столько всяких расширений функционала, что почти в любой сфере находиться уже готовое решение, если эта сфера хоть как то связана с редактированием текста.
> Зачем в нём куча каких-то загадочных отдельных режимов
Если на все файлы один режим — то ни автоподсветки ни проверки кода на корректность, ни других удобных функций редактора не будет.
> Есть ли в нём интеграция с отладчиками (GDB, например)
Есть. Если интересны подробности — простой поиск gdb+emacs в google даёт много ссылок и видео. я лично не пользовался — сказать ничего не могу, но отладку Python делаю в pdb, довольно удобно. Всё управляется с клавиатуры и легко копировать туда-сюда куски кода. Но подход отличается в корне от IDE отладки.
> удобное автодополнение (в одно нажатие + автоматическое для объектов/структур)
могу ответить конкретно по Python- функция rope-lucky-assist, выдаёт первый вариант. Чаще всего это оно. Есть варианты как показать это в командной строке/IDO, или в выпадающем меню, но однажды поняв насколько удобен ido я pull-down менюшки отключил.
> поддержка сборки (Makefile и что-нибудь своё
Да я обычно жму функцию compile. Если возникает ошибка — быстрый переход на номер строки. Если их много — есть функция перехода next-previous, привязанная на удобную клавишу.
> но пока никто не отвечал
:-) Вот стараюсь ответить.
> Когда предлагают изучить новый инструмент, должно быть какое-то обоснование
Те, кто работает рядом сразу видят приемущества — это конечная скорость. Т е некоторые действия, на которые в emacs есть удобно заточенные функции можно делать в другом редакторе _намного_ дольше. Ну опять же — всё зависит от человека. Даже у нас в компании, есть те, кому безразлична скорость, точнее не хочется человеку ради того чтобы раз в месяц что нибудь сделать быстро учить так много :-) А есть те, кто осваивает. Всё что стараюсь я донести — 1) то что не так страшен чёрт, как его малюют. Есть менюха, начинать работать можно с нулевым уровнем, а потом можно улучшать настройки и до-включать всякие удобные модули. 2) в этом есть смысл. Я этот смысл вижу — как по себе, так и смотря на остальных, кто смог освоить.
Но так уж устроен человек, что ему лениво :-) Я это понимаю. Потому постараюсь в следующих статьях показать что именно я имею в виду под «скоростью» и какие фичи есть в emacs, которых не найти в самых модных IDE.
> изменённые параметры
вот это поподробнее. просто не понял вопроса.
что в определённой степени оба редактора решают эту задачу, но соверненно разными способами. Я для себя заметил что мне удобнее пользоваться emacs т к _в основном_ я нахожусь в режиме редактирования при работе с текстом. Командный режим нужен реже. А кроме Vim я прошёл путь от: pe2, me, qedit, потом уже vi, vim, emacs, xemacs, kate. Смотрел на IDE: Komodo, Eclipse, WingIDE (+), PyCharm (+). Conclusion: все *java* IDE мне кажутся тормозами по сравнению с emacs, vim в то время как я им пользовался был не таким уж развесистым как сейчас, да и концепт там немного другой. Плюсики поставил IDEшкам что мне в общем понравились (в общем, не в деталях)
Хороший package manager был в xemacs, но увы, по скорости разработки и коммунити xemacs сильно отстаёт так что я им сейчас не пользуюсь.
Всё копируется. Дело тут наверное в том, что в X-windows существует так называемый Primary и Secondary selection. Попробуйте сделать Paste средней кнопкой мыши. А вообще чтобы эти primary/secondary не путались у меня всегда и в KDE -> Klipper и в Parcellite стоит "[x] Synhornize Primar and Secondary Selections"