I'm getting No references found message whenever I use "semantic-symref-symbol" (C-c , g) trying to get all the references to any symbol, whether the symbol is a C++ class member variable or a local variable, it just couldn't find any reference. The gtag database are under my project root. In my .emacs file I have the following:
(require 'semanticdb-global)
(semanticdb-enable-gnu-global-databases 'c-mode)
(semanticdb-enable-gnu-global-databases 'c++-mode)
When I type "global -xs symbol" under command line, it shows all the reference to the symbol correctly. But why semantic couldn't find anything? On the other hand, 'semantic-symref' works fine on looking for references of a class or class member function, but it doesn't work for variables.
Is it simply a bug, or am I missing anything that keeps symbol reference from working?
This problem is with how GNU Global is used in Semantic came up on the mailing list the other day. GNU Global lets you find occurances of tags (with -r) or random symbols (-s), and Semantic uses the -r flag, and the variables you mention are not considered tags by
GNU Global.
In the cedet-global.el support file the function cedet-gnu-global-search, it was proposed to use or add the -s flag when searching for a 'symbol. I don't know what the resolution will be at this time, however.
You can see the whole thread on the cedet-devel mailing list:
http://sourceforge.net/mailarchive/forum.php?forum_name=cedet-devel&max_rows=25&style=ultimate&viewmonth=201103
Related
Over the weekend, I had a name clash that was very hard to track down, but I managed to boil it down to a short example - thing is, I thought the package system was supposed to protect me from this, so I'm wondering how it can in future.
If I do this:
(ql:quickload "cl-irc")
(defpackage #:clash-demo
(:use #:cl
#:cl-irc))
(in-package #:clash-demo)
;; This is the name that clashes - I get a warning about this if I compile
;; this interactively (i.e. from slime) but not if I quickload the whole project.
(defun server-name (server)
(format nil "server-name ~a" server))
;; This needs an IRC server to work - if you have docker
;; then this will do the trick:
;;
;; docker run -d --rm --name ircd -p 6667:6667 inspircd/inspircd-docker
(defparameter *connection*
(cl-irc:connect :nickname "clash-demo"
:server "localhost"
:port 6667
:connection-security :none
:username "username"))
After the above, I get the following warning when defining server-name:
WARNING: redefining CL-IRC:SERVER-NAME in DEFUN
And the following error if I try and print *connection* (in my more full-fledged project I got a missing slot in a class that I'd defined - I think the root cause of both the problem I found and the minimal example above is the same though):
Control stack guard page temporarily disabled: proceed with caution
While I get the warning if I define things interactively, in practice I moved a bunch of code into a quickproject:make-project'd and ql:quickload-ed it, which I think silenced the warning as it always loaded cleanly, hence why it took me so long to track down the name clash.
My questions are:
Isn't the package system supposed to protect me from this? I think I can sort of see why the above happens - the reader's already seen the symbol server-name so it thinks I'm referring to the already defined cl-irc:server-name, and re-uses that - but surely the package system should somehow allow me to work around this?
I'm assuming the warning when I quickload-ed the project was silence because quickload assumes I don't want to see warnings from projects, is there a way I can make this more forceful when I load projects I'm making so that it raises an error, or at least warns me of these name clashes? For all I know there are a bunch more that just haven't caused me a problem yet.
I was expecting either (i) the names not to clash (i.e. my file would define the symbol clash-demo:server-name, not re-use cl-irc:server-name and cause it to be redefined) or (ii) this to be an error, or at least a warning when I quickload the project.
Thanks very much in advance for any advice!
Suppose you really like packages A and B and want to :use both of them in your package MINE. They have a hundred external symbols each and you don't want to have to type any package prefixes. However, they both export a symbol with the same name, a:frob and b:frob. If you simply :use them, you will get a symbol conflict.
To resolve the conflict, there are three options to decide what to do when you're in package MINE and you refer to the unqualified symbol frob:
Prefer A so it refers to the the symbol a:frob: (defpackage mine (:use a b) (:shadowing-import-from a frob))
Prefer B so it refers to the symbol b:frob: (defpackage mine (:use a b) (:shadowing-import-from b frob))
Prefer neither so it refers to mine::frob: (defpackage mine (:use a b) (:shadow frob)) - then, to use one from A or B you must write a:frob or b:frob explicitly
Any of these three cases may be preferable depending on your situation. Common Lisp will not automatically choose one for you. I think this is a reasonable design choice.
Briefly, no: the package system is not meant to protect you against this. If you use a package CL-IRC then you're saying that you want, for instance, to get the symbol CL-IRC:SERVER-NAME when you type server-name. What you are not saying is whether you should be allowed to modify the values associated with that symbol in any way, which is an orthogonal question. The package system is just about names, not values.
In the case of functions, then it's very often (but not always! consider loading patches) a mistake to define a function with a given name in multiple contexts. In the case of variables that's slightly less clear: it's probably a mistake if there are multiple def* forms for a given variable in different contexts, but simply assigning to the variable might well be fine.
So what is needed is a way for defining macros (defun etc) to be able to detect this and complain about it.
CL does not provide such a mechanism. Many implementations do however, either by detecting 'different contexts' (which I have been vague about) or by providing a way of saying that certain packages are sacred and redefinitions should not be allowed, or both.
In this case, the implementation has warned you about the redefinition, but Quicklisp may have suppressed that. I am not sure how to desupress warnings like this in Quicklisp.
In summary the answer is that the problem of controlling and limiting redefinition is orthogonal to what the package system does, and unfortunately CL does not provide a standard solution to this second problem.
If you are interested I have a little shim which uses the condition system to make very sure warnings are treated as errors in contexts like this. I could append it to this answer, but not until after Christmas probably.
For various reasons I've been forced to use Emacs git master for development. In this version I'm regularly getting lots of warnings in the form
No docstring slot for tags-lazy-completion-table
No docstring slot for etags--xref-backend
No docstring slot for gnus-intersection
No docstring slot for grep-compute-defaults
...
which often are so many that it slows down my interaction. Is it possible to set the docstring of a an already defined Emacs Lisp function without modifying its existing body definition?
Stefan has addressed your actual problem, but to answer the stated question:
Is it possible to set the docstring of a an already defined Emacs
Lisp function without modifying its existing body definition?
Yes, you can, via the function-documentation symbol property.
(put FUNCTIONSYMBOL 'function-documentation VALUE)
In most cases VALUE would be a string.
See:
C-hig (elisp)Documentation Basics
C-hig (elisp)Accessing Documentation
The No docstring slot for ... warnings are your problem, not the absence of docstrings (which is copmpletely normal). I suggest you try
(setq debug-on-message "\\`No docstring slot for")
and then look at the backtrace you'll (hopefully) get to try and figure out which packages emits this warning and why (and especially why it only does so in Emacs-master: might be a bug in Emacs-master, or an incompatibility ... in either case Emacs maintainers may want to hear about it).
I have read Alex Ott's fantastic guide to CEDET for Emacs, and I think I know how to set up my EDE projects correctly.
However, when I try to jump to a local symbol (e.g. the main() function in C++) using the command semantic-complete-jump-local (C-c , j), I get the error [no match] even though I am calling this command from within the .cpp file where the symbol is defined.
Also, when I try to jump with semantic-complete-jump-global (C-c , J) to a symbol with multiple definitions on different files (e.g. multiple main() functions), CEDET complains with [not unique] but it does not give me a way to choose which symbol I want to see. The only way to find the symbol I am interested in is to cycle through all the options with <TAB> buffer by buffer until I find the one I am interested in. Is there a way to get a list of symbols from where I can choose ? Ideally, it would be great to get an autocomplete list similar to those that Emacs helm (formerly known as Anything) provides.
This is all with Emacs 24.2.1 on Linux with CEDET 1.1.
Had you tried to use semantic-ia-fast-jump command? It uses not only Semantic, but also other data sources, to calculate where to jump. I just tried it, and it correctly jumped to variable, that was declared in the parent class, 3 levels higher in hierarchy.
My emacs version is 23.2.1
Although I used the following to change the backend to use GTAGS.
(require 'semantic/db-global)
(semanticdb-enable-gnu-global-databases 'c-mode)
(semanticdb-enable-gnu-global-databases 'c++-mode)
I tried to generate a GTAGS file to be used as a backend of semantic.
However, everytime when I open a C file, Semantic is still parsing files without using the GTAGS file.
Is it possible to use the GTAGS file instead of the built-in parser of semantic? I found that the built-in parser is not very accurate.
Is it possible to use the GTAGS file without specifying the project scope? In my case, I tried to put GTAGS file in /usr/include which should be the standard include path of emacs. But Semantics is not using it.
Semantic doesn't use the GTAGS file for generating tags that it will use directly for features such as jumping or smart completion. The GNU Global backend to semantic db will use GTAGS instead as a giant name table. Thus if you need to find a symbol by name, GTAGS will tell semantic where it is, and Semantic will then parse those files itself more directly to get the details.
The reason GTAGS is not used directly as a replacement parser is because the information in GTAGS is insufficient for the kinds of operations Semantic needs, as it excludes datatype info, argument parsing, and local context parsing.
Using gtags in /usr/include is an interesting idea, but would probably not get used much. Semantic will only search header files actually used in your code instead of searching all include files. The GNU Global backend is specifically for scanning an entire project for a symbol, or symbol references. If you wanted to search all your includes for a symbol, then it would be useful, but there is no such feature in Semantic at this time.
It is possible to use ebrowse to do what you want, but I found that for C++, the parser was insufficient in subtle ways, and caused some problems.
If you think the Semantic parser is inaccurate, then you should post that as a bug on the cedet-devel mailing list.
I'm currently playing with lispbuilder-sdl on SBCL under Windows.
My source code is as follows:
(asdf:operate 'asdf:load-op :lispbuilder-sdl)
(asdf:operate 'asdf:load-op :lispbuilder-sdl-binaries)
(asdf:operate 'asdf:load-op :lispbuilder-sdl-examples)
(sdl-examples:squashed)
When I compile the file I get the error: package "SDL-EXAMPLES" not found.
If I remove the (sdl-examples:squashed) from the file it compiles ok. I can then type (sdl-examples:squashed) at the repl and the demo game starts fine.
Why is the sdl-examples package found from the repl but not when I compile the file?
All of the compilation of that file happens before executing any of the load-ops. So when Lisp compiles the (sdl-examples:squashed) line, it hasn't run the load-op that defines your package.
You can get around this by not mentioning the sdl-examples package that requires the reader to locate its squashed symbol before the load-op is actually executed:
(funcall (symbol-function (intern (symbol-name '#:squashed)
(find-package (symbol-name '#:sdl-examples)))))
The idea is to calculate the package from its symbolic name, lookup the symbol naming your function, and fetch the function it names - but this way requires that the package exist only when the code is run, not when it is first read. Then your four statements can all be compiled, executed in order, and by the time that last statement is executed, your load-ops will have created the package.
So here's a little more info about what's happening here:
Writing '#:some-name refers to a symbol that's not part of any package. So that way we can make a reference to a symbolic name without either (1) assuming its package exists or (2) mucking up some other package with the name.
Then '(symbol-name #:some-name) extracts the name of the symbol as a string. Why not just write "some-name"? You could, and it will usually work. But this way is a little more robust for the case of running a "modern-mode" case-sensitive Lisp.
The find-package maps a string name to Lisp's representation of a package. Remember, by the time you run this line, your package will exist.
intern returns the symbol with the given name that lives in the given package.
symbol-function returns the function object (a lambda abstraction, or more likely, its compiled representation) associated with the symbol.
And then funcall invokes that function.
It is kind of clunky, but unfortunately there's not really a better way to mix calls which load code to create a package with names living in that package in the same file.