Семантические окна Emacs несовместимы
На работе у нас достаточно большая кодовая база, и я действительно стараюсь заставить Semantic просто работать. Вчера он, кажется, проанализировал файл, над которым я работал, а также несистемные включает: Отлично. Я мог бы создать экземпляр класса, который определен в другом включаемом файле, и после создания я мог просматривать все функции и т. Д. С помощью ключа, связанного с semantic-ia-complete-symbol-meu.
Во-первых, я использую:
- Emacs 24.3.1 с
- CEDET bzr версия: rev_8678.tar.gz и все это работает на
- Windows 7 (к сожалению).
- MinGW и MSYS установлены
- Microsoft Visual Studio 10
В моем.emacs (связанном с CEDET):
;; MODE: CEDET
(load-file "~/.emacs.d/cedet/cedet-devel-load.el") ;; This is the latest dev' version ~~ 26th Sept 2014
;; Add further minor-modes to be enabled by semantic-mode.
;; See doc-string of `semantic-default-submodes' for other things
;; you can use here.
(add-to-list 'semantic-default-submodes 'global-semantic-idle-summary-mode t)
(add-to-list 'semantic-default-submodes 'global-semantic-idle-completions-mode t)
(add-to-list 'semantic-default-submodes 'global-cedet-m3-minor-mode t)
(semantic-mode 1)
(global-ede-mode 1)
;(global-semantic-decoration-mode)
;(setq semanticdb-default-save-directory "~/.emacs.d/.semanticdb/")
;(add-to-list 'magic-fallback-mode-alist '("^// " . c++-mode))
;(add-to-list 'magic-fallback-mode-alist '("^#include" . c++-mode))
;(semantic-add-system-include "c:/Program Files (x86)/Microsoft Visual Studio 10.0/VC/include" 'c++-mode)
;(semantic-add-system-include "/usr/include/c++/3.4.4")
Поэтому мое местоположение семантической базы данных по умолчанию ~/.emacs.d/semanticdb
Я пришел сегодня и обнаружил, что при загрузке одного и того же файла я продолжаю получать три ошибки (обе из которых я искал, но ничего не соответствует моей проблеме):
Parsing main.cpp (LL)...
Idle Parse Error: "#<buffer main.cpp> - End of buffer"
А также
Save Error: nil: c:/Users/[MY_USER]/.emacs.d/semanticdb/!drive_[STUFF_HERE]!semantic.cache
А также
Idle Service Error semantic-idle-summary-idle-function: "#<buffer main.cpp> - End of buffer"
Как я уже сказал, это работало вчера, так почему бы не сегодня? (PS: Кстати, это происходит только с main.cpp - когда я ищу определения функций с использованием xcscope и открываю определение, файл правильно анализируется с помощью CEDET, а локальные включения анализируются, и я могу выполнить поиск по символам, кажется, что быть main.cpp по некоторым причинам.)
PS: я только что прочитал похожую проблему, которая есть у кого-то с MATLAB. Решением было либо создать каталог, указанный в пути matlab-include, либо изменить список в пути. Но это не имеет смысла для моей ситуации, потому что это работало вчера, и я не касался CEDET со вчерашнего дня вообще.
semantic-c-dependency-system-include-path is a variable defined in `c.el'.
Its value is ("/usr/include")
semantic-dependency-include-path is a variable defined in `dep.el'.
Its value is nil
Local in buffer main.cpp; global value is the same.
Оба они такие же, как вчера.
PS: также, когда семантический режим включен, я больше не использую (imenu-add-to-menubar) - я только получаю возможность повторно сканировать все. Однако, когда у меня не включен семантический режим, то это работает нормально. Я не знал, что семантика перепутана с imenu, если вы не сказали это?
Это все немного раздражает, потому что мне действительно нравится потенциал CEDET/Semantic и я ценю работу, которая была вложена в него. Emacs уже мощен, но с полностью работающим CEDET его мощность превышает 9000!
Я считаю, что разработчики, связанные с CEDET, должны запускать тесты на компьютере с Windows, чтобы можно было обнаружить любые ошибки, связанные с проблемами Windows. Я знаю, что ОС ужасна, но некоторые разработчики вынуждены использовать ее на рабочем месте. Я никогда не сталкивался с проблемой CEDET на своих машинах с Linux, потому что все в стандартных местах! Но это касается Windows.
PS: Если вам нужна помощь, очень простой проект отлично работает с этой настройкой и CEDET. У меня в совершенно другом месте
emacs_test_semantic> ls -l
total 103
-rw-r--r-- 1 [USER] Administrators 43 Oct 2 17:28 Makefile
-rw-r--r-- 1 [USER] Administrators 158 Oct 8 12:04 main.cpp
-rw-r--r-- 1 [USER] Administrators 247 Oct 1 12:51 myClass.cpp
-rw-r--r-- 1 [USER] Administrators 159 Oct 1 12:51 myClass.hpp
-rwxr-xr-x 1 [USER] Administrators 99862 Oct 2 17:28 output.exe
И, в основном:
#include <list>
#include "myClass.hpp"
using namespace std;
int main() {
MC CLASS( 3, 5 );
list<MC> myList;
myList.
return 0;
}
Итак, я могу дополнить символы класса MC, но не список STL. НО, эта тема не о возможности выполнять функции / шаблоны STL, потому что есть много вопросов по этому поводу.
Этот небольшой проект, хотя и с (global-semantic-decoration-mode) включен и красный над #include <vector> не дает те же три ошибки, описанные выше. Кроме того, имя работает!
===
Таким образом, я несколько смущен в отношении несоответствия здесь. Дело в том, что в большой кодовой базе все работало вчера, но теперь у меня есть эти три ошибки, которых я раньше не получал!
===
PS: Сразу после того, как я написал это, я загружаю тот же файл, и на этот раз режим глобального декорирования показывает, что локальные включения на самом деле теперь понятны! Хотя я ничего не изменил. Так что теперь, кажется, снова работает - но это непоследовательность, которая не понятна.
Ну, это работает для одной ветви, а не для другой. Интересно, что в ветке, которая дает мне три ошибки (указано выше), у меня есть файл БД (и imenu не работает, и при этом не отображается режим декорирования:
-rw-r--r-- 1 [USER] Administrators 449 Oct 8 13:42 !drive_d![SOME_STUFF]!semantic.cache
По сравнению с тем, который работает (где виден глобальный-декоративный режим и работает меню):
-rw-r--r-- 1 [USER] Administrators 555184 Oct 8 13:51 !drive_d![SOME_STUFF]!semantic.cache
Вы можете увидеть большую разницу в размерах. И эти две ветви отличаются только в совершенно разных местах в кодовой базе. Итак, просто дополнительная информация.
===
Как пользователь CEDET/semantic (хотя и не очень хороший), я действительно хотел бы знать способ вручную форсировать синтаксический анализ всех файлов в данном списке, который записывается в БД, а не полагаться на семантику, чтобы сделать это., Это было запрошено ранее, и люди создали некоторый взломанный список, но с CEDET, когда-либо изменяющимся с 1.1, код не работает.
===
PS: последнее редактирование: из-за отсутствия ошибок, единственное, что я помню, это сохранение буфера. Вы можете сказать, когда ошибки исчезли, потому что начала показывать глобальная декарация - то есть подчеркнутые и выделенные включаемые файлы. Это потому что я сохранил буфер? Я не уверен. Я не могу вспомнить, сохранял ли я это раньше. Также увеличилось сохранение файла БД, и последняя модификация файла БД была несколько минут назад из этого поста:
Что было раньше:
-rw-r--r-- 1 [USER] Administrators 449 Oct 8 13:42 !drive_d![SOME_STUFF]!semantic.cache
Сейчас:
-rw-r--r-- 1 [USER] Administrators 158327 Oct 8 15:38 !drive_d![SOME_STUFF]!semantic.cache
1 ответ
Просто испортив на работе много глюков, которые я изначально обнаружил, начинает обретать смысл и, похоже, это просто мое непонимание продукта. Нет проблем с синтаксическим анализом включений системы (таких как STL) или локальных включений в Windows, и это в основном сводится к замечательной функции: global-semantic-decoration-mode, Он дает понять, был ли проанализирован исходный файл или нет, и т. Д. И т. Д. Итак, теперь я использую это в моих.emacs.
Проблема несогласованности (которую я обнаружил, это не несоответствие, см. Ниже) - я обнаружил - возникает, когда синтаксический анализатор сталкивается с такой строкой кода:
#if defined(X)
//hundreds of lines of code
#endif /* define(X) */
Я могу наполовину понять это. Если X не был определен, тогда не беспокойтесь о разборе. Но я все еще хочу, чтобы CEDET/Semantic работал со всем кодом. Я все еще могу использовать завершение, если я работаю в функции, которая существует в несуществующей области из-за чего-то неопределенного.
Я наивно говорю, что семантика / cedet должны анализировать код независимо от того, определено ли что-то или нет. Однако, возможно, это была преднамеренная особенность?
Благодарю.