C Emacs-а на IDE

А что именно? Имхо главный плюс это то что можно хорошо интегрировать емакс с твоими скриптами откладки, а отладка вручную - не чень хорошая вещь...

> - Для Си++ нет нормального браузера классов. ECB не канает, его парсер верх убожества и тормознутости. Даже в KDevelop лучще. сtags неитерактивен, неудобно. Ситуацию от части спасает Xrefactory, но опять таки функционал нормального браузера классов он не предоставляет.

Я этим не пользуюсь, но имхо что я видел вполне так ничего. Хотя вам виднее.

> - Для Си++ нет нормального автокомлита (в следствие отсутствия нормального интерактивного парсера). Хотя идея с M-/ достаточно хороша.

Не надо. В Xrefactory очень хороший.

> - Откровенно неудобный CVS-клиент. Проще пользоваться каким-нибудь отдельным front-end.

А то что стандартная система управления версиями работает одинково со всеми VCS это имхо мегаплюс. Я например работаю с 3 VCS - очень удобно. К тому же для каждой из VCS есть свои более навороченные фронеэнды. Посмотри например на emacs интеграцию с gnu/arch. Да и для CVS есть несколько PCL-CVS например.

> - На практике Emacs очень трудно использовать под Win32 для работы не с GNU-тыми компиляторами. Полноценную поддержку Borland C++ и Visual С++ мне получить не удалось.

гм. учи elisp - и допиши:)

> - Плохая интеграция со средствами разработки GUI

C-x C-f frontend.tcl :) или в худшем случае frontend.xml

> Вот что вспомнил сразу. Думаю переходить с Emacs-а на IDE. Порог входа в эти системы достаточно низкий, использовать можно почти сразу, без кучи дополнительных скриптов и настроек, интерфейс почти стандартный. Да и удобнее.

Самый главный плюс емакс очень хорошая автоматизация, можно сдлеть всё что угодно. И так как тебе удобно. У меня рутинных операций не остаёться почти никогда. Emacs lisp очень гармонично дополняет связку shell + perl/python/ruby, когда нужно заниматься автоматизацией.

Ещё раз посоветую выучить получше elisp. Может тогда не захочеться никуда переходить.

Нда.... последняя новость:

"News

Codeblocks 1.0rc2 released!

by rickg22, date: Oct 25, 2005"

И это --- "Очень перспективный проект, Быстро развивается"? =\

В Emacs-е больше всего раздражает исследование данных при отладке, когда имеется некоторая графовидная структруа данных и при каждом шаге необходимо отследить как она меняется. В Visual Studio это крайне удобно сделано. Именно за счет интеграции среды разработки и отладчика. Единственный аналогичный по функциональности инструмент под Linux который я нашел - DDD.

По поводу скриптов - расскажи по подробнее на примере Си/Си++ где их можно использовать. Как лично ты автоматизируешь отдалку? Я себе это плохо представляю.

>> - Для Си++ нет нормального автокомлита

>Не надо. В Xrefactory очень хороший.

Да. Нагнал. Автокомплит в XRefactory нормальный

> А то что стандартная система управления версиями работает одинково со всеми VCS это имхо мегаплюс.

Не вижу мегаплюса. Как правило, в течение одного проекта используется одна система контроля версий. Какой смысл использовать 3-4 разных системы одновременно ? Мне и моим коллегам возможностей CVS вполне хватает.

>> - На практике Emacs очень трудно использовать под Win32 для работы не с GNU-тыми компиляторами. Полноценную поддержку Borland C++ и Visual С++ мне получить не удалось.

> гм. учи elisp - и допиши:)

На коленке это сделать очень трудно. Проблема не в Emacs-е а в самих компиляторах и средах разработки. Например VC++ и BC++ не умеют генерить список зависимостей для сборки. Поэтому для стабитльного результата пересобирать приходится весь проект после редактирования единственного хидера. О поддержке отладчика я вообще молчу.

Несмотря на то, что Emacs в данном случае "не виноват", выбор все равно не в его пользу. Функционала в любом случае нет, а работать надо.

> C-x C-f frontend.tcl :) или в худшем случае frontend.xml

:) это даже не велосипед. Это ходьба гуськом.

В зависимости от языка и типа платформы буду выбирать специализированную IDE. Под Linux + Си++ возможно KDevelop или Eclipse + CDT. Пока не решил. Буду основательно пробывать.

Да я гоню и плохо себе это представляю... т.к. с сями моя работа не связана. Посмотри в гуле как люди делают скрипты для GDB это будет вернее. Потом интегрируешь это с емаксом и вуаля. А ещё лучше делать системы как можно более ортогональными и писать тесты. Или логировать (имхо грамотная система логирования + всякие автогенраторы логирования часто даже лучше чем дебагер). Я лично в своих проектах пишу тесты + стараюсь не допускать ошибок:))) + логирование. А по работе логированнием (вот здесь как раз очень хорошо проявились возможности емакса). Но только я в основном с динамическими языками работаю.

> :) это даже не велосипед. Это ходьба гуськом.

Ну тады QTDesigner или Glade в руки.

Это понятно. Лучше быть здоровым и богатым, чем бедным и больным. Только не всегда это получается.

> имхо грамотная система логирования + всякие автогенраторы логирования часто даже лучше чем дебагер

Логирование это хорошо, но не всегда. В некоторых случаях отладчик выгоднее использовать.

Вообще спасибо за то что про xref-autocompletion подсказал. А то я видимо не заметил его как-то.