Emacs / CEDET. Несколько проектов и автозавершение кода

Я установил emacs 23.1.50.1 с CEDET 1.0 и ECB 2.40 (во многом вдохновленный установкой Алекса Оттса на http://github.com/alexott/emacs-configs/blob/master/rc/emacs-rc-cedet.el и его нежное введение в Cedet ( http://alexott.net/en/writings/emacs-devenv/EmacsCedet.html), спасибо Алекс). Он работает довольно хорошо, но мне нужно больше понимания того, как обрабатываются автозавершение кода и ссылки на символы при работе с несколькими проектами.

Я создал такой простой проект ede:

(ede-cpp-root-project "test"
                      :file "~/src/sw/anchor"
                      :include-path '("/Common")
                      :system-include-path '("~/include"))

Когда этот проект загружен, Semantic будет искать завершения только в различных каталогах, указанных в конфигурациях проекта?

Я подписался на http://mmmyddd.freeshell.net/blog/Computer/Emacs/usecscopesemanticdbbackend, чтобы использовать cscope в качестве бэкэнда для semanticdb. Я могу запустить semanticdb-enable-cscope-in-buffer без того, чтобы emacs выдавал какие-либо ошибки, но я понятия не имею, использует ли семантика мою базу данных. Могу ли я добавить ссылку на cscope.out в определение моего проекта, чтобы иметь больший контроль над тем, какие файлы искать для ссылок в моем текущем контексте?

Пара странностей:

Когда я пытаюсь открыть новый исходный файл, я получаю сообщение об ошибке «применить: поиск программы: нет такого файла или каталога, глобального», и ничего не происходит. Если я попытаюсь открыть его снова, все в порядке.

Когда я пытаюсь загрузить проект, указывая на файл привязки, я получаю следующую ошибку: «if: Неверный тип аргумента: class-p, ede-cpp-root»


person anr78    schedule 20.10.2010    source источник
comment
Для заявки: поиск программы: нет такого файла или каталога, глобальная ошибка, вы скопировали часть настройки Алекса Отта, которая использовалась (semanticdb-enable-gnu-global-databases ...)?   -  person Dingo    schedule 21.10.2010
comment
Я это сделал, но подозреваю, что мне это не нужно. Тот факт, что там говорится о глобальной поддержке GNU, должен был заставить меня подозревать, что проблема именно там :). Спасибо.   -  person anr78    schedule 21.10.2010


Ответы (1)


Когда вы получаете ошибки в конфигурации, лучше всего сделать следующее:

M-x toggle-debug-on-error RET

и получите трассировку стека, которая укажет на проблемную область. Часто это помогает определить проблему конфигурации.

CEDET попытается связать каждый файл с одним проектом, и все команды, работающие в этом буфере, будут ограничены рамками этого проекта. Для поддержки CScope он также будет использовать EDE для идентификации корневого каталога, что поможет найти файл cscope.out, связанный как с инструментами завершения, так и со справочными инструментами.

Исключением, конечно же, является системный путь включения, обычно это / usr / include или что-то еще. Это дополнение к пути включения системы по умолчанию, который рассчитывается с поддержкой GCC. В одном из ваших файлов C вы можете:

M-x semantic-c-describe-environment RET

и это должно показать, что Semantic попытается использовать.

Чтобы дважды проверить, используется ли CScope для завершения кода, вы можете проверить:

M-x semanticdb-find-test-translate-path RET

и проверьте конец списка на предмет CScope.

person Eric    schedule 21.10.2010
comment
Спасибо, Эрик, и за ответ, и за программное обеспечение. Эти команды действительно очень полезны. В настоящее время в semantic-c-describe-environment ничего не говорится о cscope, а в semanticdb-find-test-translate-path говорится: * # ‹semanticdb-table-cscope Таблица поиска Cscope (0 тегов)› - person anr78; 21.10.2010
comment
Правильно, поддержка cscope не заботится о подсчете количества тегов, о которых знает CScope, и на самом деле это не часть проекта, поскольку внутренние компоненты абстрагированы, поэтому среда C не знает об этом. - person Eric; 22.10.2010