Ответ 1
Инструменты CEDET, которые вы используете, ограничены способностью Emacs отслеживать каждый символ во всем проекте. Хорошей отправной точкой для дросселирования того, что CEDET/Semantic делает через semanticdb-find-default-throttle. Если вы знаете, как организован ваш проект, вы можете отключить некоторые виды поиска, чтобы ускорить процесс.
CEDET проанализирует множество файлов, которые, по вашему мнению, вам понадобятся, которые также заполнят память. В этом случае вы можете настроить semantic-idle-scheduler-max-buffer-size, чтобы отключить синтаксический анализ больших файлов, semantic-idle-work-parse-neighboring-files-flag, чтобы отключить разбор случайного соседнего материала и `semantic-idle-work-update-headers-flag ', чтобы отключить заголовки синтаксического анализа. Обратите внимание, что последние 2 по умолчанию равны нулю, но включены некоторыми функциями автоматической настройки.
CEDET/Semantic будет кэшировать много данных в памяти и создает сортированные таблицы поиска для повышения производительности. Если вы обнаружите, что редактируете файлы заголовков много, эти изменения заставляют кэши устаревать и заставляют их перестраивать. Если вы выходите и перезапускаете Emacs много, то это заставляет Semantic перезагружать большие таблицы базы данных.
Другая возможность - установить semanticdb-persistent-path для перечисления только тех каталогов, о которых вы очень заботитесь. Это сократит сохраненные данные, которые не будут перезагружаться. Если это необходимо, оно будет перерисовываться по мере необходимости, но это поможет сохранить общие данные.
Вы также можете использовать semantic--before-fetch-tags-hook для функции, которая возвращает nil в различных условиях. Найдите файлы, которые занимают много времени для разбора из-за размера, латентности сети или чего-то еще, и настройте их, чтобы никогда не разбираться. Это тоже сэкономит некоторое время.
Использование GNU Global - хороший способ ускорить процесс. Использование его с семантическим symref приведет к тому, что файлы, на которые он находит попадания, будут анализироваться для предоставления требуемых данных для вывода. Это не так много.
Для найденной выше ошибки, если вы можете определить способ ее воспроизведения, поделитесь ею в списке рассылки cedet-devel, чтобы она могла быть исправлена. Этот тип ошибки проявился раньше, обычно, когда тэг GNU Global не удается преобразовать в буферный тег.
Для отладки CEDET, выходящего из-под контроля, используйте semantic-debug-idle-function и semantic-debug-idle-work-function, чтобы сузить все. См. Выше о некоторой конфигурации там.
Вы можете использовать cedet-gnu-global-create/update-database для обновления базы данных или добавить ее к крюку. Я не думаю, что это дошло до документа.
Управление проектами сложно. Большинство встроенных проектов хороши для мелочей. Особенно крупные проекты с пользовательскими системами сборки обычно требуют специального типа проекта EDE. Создание новых проектов не так уж плохо. Если вы посмотрите в ede-linux или ede-emacs, вы сможете поймать основы. В вашем пользовательском проекте вы можете завершить все связанные проекты и переопределить такие функции, как макросы, включить каталоги и команды компиляции. Мне также пришлось написать собственный проект для моей работы. Это было очень похоже на ede-linux с уникальным материалом, где я работаю.