С++ vim IDE. Что вам нужно от этого

Ответ 1

• отладчик
• Инструменты навигации исходного кода (теперь я использую http://www.vim.org/scripts/script.php?script_id=1638 плагин и ctags)
• скомпилировать lib/project/один исходный файл из ide
• Навигация по файлам в проекте
• работа с системой управления версиями
• простой доступ к истории изменений файла
• переименование файлов/переменных/методов
• легкий доступ к справке С++
• параметры простого изменения проекта (Makefiles, jam и т.д.)
• быстрая автозаполнение для путей/переменных/методов/параметров
• интеллектуальная идентификация для новых областей (также будет хорошо, если разработчик будет иметь возможность устанавливать правила идентификации)
• выделение неправильным идентификатором кода (вкладки вместо пробелов, пробелы после ";", пробелы рядом "(" или ")" и т.д.)
• переформатирование выбранного блока с помощью convstion

Ответ 2

Существует несколько проблем. Большинство из них уже решены с помощью независимых и общих плагинов.

Что касается определения того, что представляет собой проект.

Учитывая набор файлов в одном каталоге, каждый файл может быть уникальным файлом проекта - у меня всегда есть каталог tests/, где я размещаю проекты домашних животных или где я тестирую поведение компилятора. Наоборот, файлы из набора каталогов могут быть частью одного и того же и очень большого проекта.

В конце концов, то, что действительно определяет проект, является (листом) "makefile" - и зачем ограничивать себя make файлами, как насчет scons, autotools, ant, (b) jam, aap? И BTW, Sun-Makefiles или GNU-Makefiles?

Кроме того, я не вижу смысла указывать точные файлы в текущем проекте. И даже в этом случае хорошо известный project.vim плагин уже выполняет эту работу. Лично я использую local_vimrc plugin (я поддерживаю один, и я видел двух других в SF). С этим плагином мне просто нужно отбросить файл _vimrc_local.vim в каталог, и то, что определено в нем (: сопоставления,: функции, переменные,: команды,: настройки,...), будет применяться к каждому файлу под каталог - я работаю над большим проектом, имеющим дюжину подкомпонентов, каждый компонент живет в своем собственном каталоге, имеет свой собственный makefile (даже не названный Makefile, ни с именем каталога)

Что касается понимания кода на С++

Каждый раз, когда мы хотим сделать что-то сложное (рефакторинг, такой как rename-function, rename-variable, generate-switch-from-current-variable-which-an-enum,...), нам нужно, чтобы vim понимание С++. Большинство существующих плагинов полагаются на ctags. К сожалению, ctags понимание С++ довольно ограничено - я уже написал несколько продвинутых вещей, но меня часто останавливают из-за плохой информации предоставляемые ctags. cscope не лучше. В конце концов, я думаю, нам придется интегрировать расширенный инструмент, например, elsa/pork/ionk/deshydrata/....

NB: То, где, сейчас, я концентрирую большинство своих усилий.

Что касается Doxygen

Я не знаю, как трудно перейти к определению doxygen, связанному с текущим токеном. Первая трудность заключается в том, чтобы понять, на что курсор включен (я думаю, omnicppcomplete уже проделал большую работу в этом направлении). Вторая трудность заключается в том, чтобы понять, как doxygen генерирует имя страницы для каждого символа из кода.

Открытие vim в правой строке кода с доксигенной страницы должно быть простым с помощью плагина greasemonkey.

Относительно отладчика

Существует проект pyclewn для тех, кто запускает vim под linux, и с gdb в качестве отладчика. К сожалению, он не поддерживает другие отладчики, такие как dbx.

Ответы на другие требования:

• Когда я запускаю или отлаживаю мою скомпилированную программу, мне бы хотелось, чтобы появилось диалоговое окно, которое запрашивает параметры командной строки. Он должен помнить последние 20 или около того параметров, которые я использовал для проекта. Я не хочу редактировать свойства проекта для этого.

My Плагин BuildToolsWrapper имеет параметр g:BTW_run_parameters (легко переопределяется с помощью решений project/local_vimrc). Добавление сопоставления для использования аргументов очень просто. (см.: h inputdialog())

• работа с системой управления версиями

Уже существует несколько плагинов, которые решают эту проблему. Это не имеет ничего общего с С++, и это не должно решаться пакетом С++.

Ответ 3

Вещи, которые я хотел бы в среде IDE, чтобы те, которые я использую, не предоставляют:

• Когда я запускаю или отлаживаю мою скомпилированную программу, мне бы хотелось, чтобы появилось диалоговое окно, которое запрашивает параметры командной строки. Он должен помнить последние 20 или около того параметров, которые я использовал для проекта. Я не хочу редактировать свойства проекта для этого.

• Меню "Инструменты", которое настраивается для каждого проекта

• Возможность переназначения сопоставлений клавиатуры для каждой возможной команды.

• Возможность создания списков конфигураций проекта в текстовой форме

• Интеллектуальные плавающие (не закрепленные) окна для отладчика и т.д., которые появляются только тогда, когда они мне нужны, остаются на вершине, а затем исчезают, когда они больше не нужны.

• Встроенный анализ метрик кода, поэтому я получаю список самых сложных функций в проекте и могу нажимать на них, чтобы перейти к коду

• Встроенная поддержка Doxygen или аналогичная, поэтому я могу щелкнуть документ Doxygen и перейти непосредственно к коду. Sjould также может отменить переход от кода к Doxygen.

Без сомнения, кто-то теперь скажет, что Eclipse может делать то или это, но он слишком медленный и раздутый для меня.

Ответ 4

Добавление в Нейл ответ:

• интеграция с gdb как в emacs. Я знаю clewn, но мне не нравится, что мне нужно перезапустить vim, чтобы перезапустить отладчик. С чистым vim интегрируется в отладчик, но не наоборот.

Ответ 5

Не уверен, что вы работаете в Windows, но если вы предлагаете вам проверить Viemu. Это довольно хорошее расширение VIM для Visual Studio. Мне очень нравится Visual Studio в качестве IDE (хотя я все еще думаю, что VC6 трудно превзойти), поэтому расширение Vim для VS было идеально для меня. Функции, которые я предпочел бы лучше работать в среде Vim IDE, следующие:

• Макросъемка немного подвержена ошибкам, особенно с отступом. Я нахожу, что могу легко и часто записывать макросы в Vim, пока я редактирую код (например, беру enum defn из заголовка и выкручивая соответствующий оператор switch), но обнаружил, что Viemu немного ошибочен в этом департаменте.
• Выполнение кода VIM подбирает слова в текущем буфере, где Viemu подключается к материалам завершения кода VS. Это означает, что если я только что создал имя метода, и я хочу, чтобы ctrl] автоматически завершил, Vim заберет его, но Viemu не будет.

Ответ 6

Для меня это просто к потребностям

• хорошая интеграция с ctags, поэтому вы можете перейти к определению
• интеллектуальное завершение, которое также даст вам прототип функции
• простой способ переключения между кодом и заголовками
• интерактивная отладка с брейк-точками, но, возможно,
• возможно складывание
• дополнительные бонусные баллы для инструментов рефакторинга, таких как метод переименования или извлечения.

Я бы сказал, держаться подальше от определения проектов - просто обработайте всю ветвь файла как часть "проекта" и пусть у пользователей есть файл настроек, чтобы переопределить этот стандартный

99% разницы в скорости, которую я вижу между пользователями IDE и vim, - это поиск кода и навигация. Вы должны иметь возможность grep вашего исходного дерева для фразы (или разумно искать правильный символ с помощью ctags), показывать все хиты и переключаться на этот файл в виде двух или трех нажатий клавиш.

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

На самом деле, есть ли какие-либо плагины для vim, которые уже достигают этого?