Семантические окна 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, либо изменить список в пути. Но в моей ситуации это не имеет смысла, потому что вчера это работало, а со вчерашнего дня я вообще не прикасался к 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) - у меня есть только возможность повторно сканировать все. Однако, когда у меня не включен семантический режим, это работает нормально. Я не знал, что семантика испортила имя, если вы не сказали?

Все это немного раздражает, потому что мне очень нравится потенциал 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: Сразу после того, как я написал это, я загружаю тот же файл, и на этот раз global-decoration-mode показывает, что локальные включения теперь действительно понятны! Хотя я ничего не изменил. Так что теперь, похоже, это снова работает - но непонятно именно это несоответствие.

Что ж, это работает для одной ветки, а не для другой. Интересно, что в ветке, которая дает мне три ошибки (указанные выше), у меня есть файл БД (и imenu не работает, и при этом не отображается decoration-mode:

-rw-r--r-- 1 [USER] Administrators    449 Oct  8 13:42 !drive_d![SOME_STUFF]!semantic.cache

По сравнению с тем, который работает (где отображается global-decoration-mode и работает imenu):

-rw-r--r-- 1 [USER] Administrators 555184 Oct  8 13:51 !drive_d![SOME_STUFF]!semantic.cache

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

===

Как пользователь CEDET / семантического (хотя и не очень хорошего) мне бы очень хотелось знать способ вручную ПРИНУДИТЬ анализ всех файлов в данном списке, который записывается в БД, а не полагаться на семантику для этого. . Это было запрошено раньше, и люди создали некоторую хакерскую шепотку, но с CEDET, когда-либо меняющимся с 1.1, код не работает.

===

PS: Последнее редактирование: из-за того, что ошибки исчезли, единственное, что я помню, это сохранение буфера. Вы можете определить, когда ошибки исчезли, по появлению global-decaration, т. Е. Подчеркнутых и выделенных включаемых файлов. Это потому, что я сохранил буфер? Я не уверен. Не могу вспомнить, сохранял ли я это раньше. Кроме того, увеличилось сохранение файла БД, и последняя модификация файла БД была несколько минут назад из этого сообщения:

Что было раньше:

-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

person rjd    schedule 08.10.2014    source источник


Ответы (1)


Когда я только что напортачил на работе, многие глюки, которые я изначально обнаружил, начинают обретать смысл и, похоже, являются просто моим непониманием продукта. В Windows больше нет проблем с включением системы синтаксического анализа (например, STL) или локальных включений, и это в основном связано с замечательной особенностью: global-semantic-decoration-mode. Это дает понять, был ли проанализирован исходный файл или нет и т. Д. Итак, теперь я использую это в своих .emacs.

Проблема несогласованности (которая, как я обнаружил, не является несогласованностью, см. Ниже) - я обнаружил - возникает, когда синтаксический анализатор сталкивается с такой строкой кода:

#if defined(X)

//hundreds of lines of code

#endif /* define(X) */

Я могу наполовину это понять. Если X не был определен, не беспокойтесь о синтаксическом анализе. Но я по-прежнему хочу, чтобы CEDET / Semantic работал со всем кодом. Я все еще могу использовать завершение, если я работаю с функцией, которая существует в несуществующей области из-за чего-то неопределенного.

Я наивно говорю, что semantic / cedet должен анализировать код независимо от того, определено что-то или нет. Однако, возможно, это была преднамеренная особенность?

Спасибо.

person rjd    schedule 15.10.2014