gtags-find-tag and gtags-find-rtag in C-code

gtags-find-tag and gtags-find-rtag in C-code

[Peter Münster]

Hi,

I would like to be able to jump do definitions and references of
identifiers in C-code.

Here an example:

--8<---------------cut here---------------start------------->8---
enum my_enum
{
    E_1,
    E_2
};

int my_var;

void my_func1(void)
{
}

void my_func2(void)
{
    my_func1();
    my_var = E_1;
}
--8<---------------cut here---------------end--------------->8---

When ":tc=native:" in gtags.conf:

function                                result
----------------------------------------------------
gtags-find-tag  my_func1                    OK
gtags-find-tag  my_var                  Not OK
gtags-find-tag  E_1                     Not OK
gtags-find-rtag my_func1                    OK
gtags-find-rtag my_var                  Not OK
gtags-find-rtag E_1                     Not OK


And when ":tc=exuberant-ctags:" in gtags.conf:

function                                result
----------------------------------------------------
gtags-find-tag  my_func1                    OK
gtags-find-tag  my_var                      OK
gtags-find-tag  E_1                         OK
gtags-find-rtag my_func1                Not OK
gtags-find-rtag my_var                  Not OK
gtags-find-rtag E_1                     Not OK


Do you know a solution, where all 6 lines are OK?

TIA for any help,
-- 
           Peter

Re: gtags-find-tag and gtags-find-rtag in C-code

[Eli Zaretskii]

> From: Peter Münster <pmlists@free.fr>
> Date: Tue, 02 Jun 2015 15:28:33 +0200
> 
> I would like to be able to jump do definitions and references of
> identifiers in C-code.

I suggest to use GNU ID-Utils and its Emacs front-end idutils.el for
that.  That's exactly what that package is for.

Re: gtags-find-tag and gtags-find-rtag in C-code

[Peter Münster]

On Tue, Jun 02 2015, Eli Zaretskii wrote:

>> I would like to be able to jump do definitions and references of
>> identifiers in C-code.
>
> I suggest to use GNU ID-Utils and its Emacs front-end idutils.el for
> that.  That's exactly what that package is for.

It seems, that it's just a better grep, but I don't see a possibility to
jump to a definition. Is there support for pushing and popping the
locations (for jumping back and forth)?
Shouldn't gtags do the job, just with the right setup, that I am
probably missing?

-- 
           Peter

Re: gtags-find-tag and gtags-find-rtag in C-code

[Eli Zaretskii]

> From: Peter Münster <pmlists@free.fr>
> Date: Tue, 02 Jun 2015 18:01:56 +0200
> 
> On Tue, Jun 02 2015, Eli Zaretskii wrote:
> 
> >> I would like to be able to jump do definitions and references of
> >> identifiers in C-code.
> >
> > I suggest to use GNU ID-Utils and its Emacs front-end idutils.el for
> > that.  That's exactly what that package is for.
> 
> It seems, that it's just a better grep

It's a syntax-sensitive grep, yes.

> but I don't see a possibility to jump to a definition.

ID-Utils don't distinguish between definitions and references, they
just tag places where symbols are used in any capacity.

> Is there support for pushing and popping the locations (for jumping
> back and forth)?

The development sources for Emacs have that via xref, I think.

> Shouldn't gtags do the job, just with the right setup, that I am
> probably missing?

I don't use gtags, but isn't it just for definitions?

Re: gtags-find-tag and gtags-find-rtag in C-code

[Dmitry Gutov]

On 06/02/2015 07:13 PM, Eli Zaretskii wrote:

>> Is there support for pushing and popping the locations (for jumping
>> back and forth)?
>
> The development sources for Emacs have that via xref, I think.

xref doesn't have a bundled backend for id-utils, or gtags, or etc.

So xref-find-definitions will use etags, if available, but 
xref-find-references can use id-utils, or cscope, or gtags, but purely 
as an optimization over grep, which it will fall back to in the absence 
or other tools (or index files generated by them).

>> Shouldn't gtags do the job, just with the right setup, that I am
>> probably missing?
>
> I don't use gtags, but isn't it just for definitions?

gtags can do a lot of things. Users interested in it should try 
https://github.com/leoliu/ggtags, also available via GNU ELPA (no 
integration with xref, though).

Re: gtags-find-tag and gtags-find-rtag in C-code

[Peter Münster]

On Tue, Jun 02 2015, Eli Zaretskii wrote:

> The development sources for Emacs have that via xref, I think.

Yes, etags uses the xref-frontend now.


> I don't use gtags, but isn't it just for definitions?

It's a bit like etags, but it can jump also to the references.
After further investigation, it seems, that there are 2 problems:
- there is a bug that prevents global from finding enumeration values¹
- finding definitions of variables is not yet implemented²

ctags does not have theses problems, but it cannot find references³.
This is just bad luck and it has nothing to do with emacs...

¹: http://article.gmane.org/gmane.comp.gnu.global.bugs/1982
²: http://www.gnu.org/software/global/plans.html
³: http://ctags.sourceforge.net/faq.html#12

-- 
           Peter

understanding backquote

[Olaf Rogalsky]

Hi,

I have problems in understanding the semantics of backquote. Consider
the following function:

(defun test () `,(* (+ 1 2) (+ 3 4)))

Now let's have a look at the defintion of the symbol:

(symbol-function 'test)
=> (lambda nil (* (+ 1 2) (+ 3 4))) 

Huhh??? I was thinking, that the above definition is equivalent to the
following:

(defun test () 21)

Ok, this was unexpected, but perhaps the compiler does it "right":
(disassemble (byte-compile 'test))
=>  byte code:
      args: nil
    0       constant  21
    1       return    

Yes, it does. It is only, that I suspect, that this has nothing to do
with backquotes, but rather with constant folding optimization.

Can anybody explain this to me?

Thanks,
Olaf

Re: understanding backquote

[Nicolas Richard]

Olaf Rogalsky <olaf.rogalsky@aol.de> writes:
> (defun test () `,(* (+ 1 2) (+ 3 4)))
>
> Now let's have a look at the defintion of the symbol:
>
> (symbol-function 'test)
> => (lambda nil (* (+ 1 2) (+ 3 4))) 
> Huhh???

I agree with your surprise.

>         I was thinking, that the above definition is equivalent to the
> following:
>
> (defun test () 21)

But mine goes in the opposite direction :
(defun test () `,(* (+ 1 2) (+ 3 4)))
should yield
(symbol-function 'test)
 => (lambda nil (\` (\, (* (+ 1 2) (+ 3 4)))))

However, evaluating with C-x C-e or C-M-x gives what you mentionned:
(lambda nil (* (+ 1 2) (+ 3 4)))

*But* if you evaluate the defun with M-:, then we get what I expected.

Why is that ? Because of eager macroexpansion (see
http://article.gmane.org/gmane.emacs.help/103223).

As another example, hitting C-x C-e after:
(defun foo (bar)
  (eval-when-compile
    (message "bar")))
will produce "bar" in your *Messages* buffer, but it doesn't happen
using M-:.

HTH,

-- 
Nico

Re: understanding backquote

[Stefan Monnier]

> *But* if you evaluate the defun with M-:, then we get what I expected.

That's a bug.  We should also eagerly macroexpand in that case.
Could you make bug reports for those cases where you find that macros
have not been expanded eagerly?


        Stefan

Re: understanding backquote

[Pascal J. Bourguignon]

Olaf Rogalsky <olaf.rogalsky@aol.de> writes:

> Hi,
>
> I have problems in understanding the semantics of backquote. Consider
> the following function:
>
> (defun test () `,(* (+ 1 2) (+ 3 4)))
>
> Now let's have a look at the defintion of the symbol:
>
> (symbol-function 'test)
> => (lambda nil (* (+ 1 2) (+ 3 4))) 
>
> Huhh??? I was thinking, that the above definition is equivalent to the
> following:
>
> (defun test () 21)
>
> Ok, this was unexpected, but perhaps the compiler does it "right":
> (disassemble (byte-compile 'test))
> =>  byte code:
>       args: nil
>     0       constant  21
>     1       return    
>
> Yes, it does. It is only, that I suspect, that this has nothing to do
> with backquotes, but rather with constant folding optimization.
>
> Can anybody explain this to me?

`,x is equivalent to x.



(info "(elisp) Backquote")

More details are given in the Common Lisp specification of the backquote
reader macro, but it's "extrapolation" relative to emacs lisp:
http://www.lispworks.com/documentation/HyperSpec/Body/02_df.htm



Now, the fact that you obtain a simple constant function is unrelated
to the backquote, but comes from the fact that you have a good and smart
compiler, that notices that the expression is a constant expression, and
therefore it is reduced at compilation time:

    (disassemble (byte-compile (lambda nil (* (+ 1 2) (+ 3 4)))))
    byte code:
      args: nil
    0       constant  21
    1       return    


With variables, it is another matter:

    (disassemble (byte-compile (lambda (a b c d) `,(* (+ a b) (+ c d)))))
    byte code:
      args: (a b c d)
    0       varref    a
    1       varref    b
    2       plus      
    3       varref    c
    4       varref    d
    5       plus      
    6       mult      
    7       return    


-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: understanding backquote

[Olaf Rogalsky]

>> I have problems in understanding the semantics of backquote. Consider
...
> (info "(elisp) Backquote")

Yes, I read that, but the manual does not make it entirly clear, at
which time comma expressions are evaluated: at read or at compile-time:

  9.4 Backquote
  ...
  The special marker ‘,’ inside of the argument to backquote indicates a
  value that isn’t constant. The Emacs Lisp evaluator evaluates the
  argument of ‘,’, and puts the value in the list structure:
  ...

> Now, the fact that you obtain a simple constant function is unrelated
> to the backquote, but comes from the fact that you have a good and smart
> compiler, that notices that the expression is a constant expression, and
> therefore it is reduced at compilation time:
Thanks for the confirmation, I already suspected this.

Olaf

Re: understanding backquote

[Nicolas Richard]

Olaf Rogalsky <olaf.rogalsky@aol.de> writes:

>>> I have problems in understanding the semantics of backquote. Consider
> ...
>> (info "(elisp) Backquote")
>
> Yes, I read that, but the manual does not make it entirly clear, at
> which time comma expressions are evaluated: at read or at
> compile-time:

At expansion time (hence also at compile time), because ` is a macro.

-- 
Nico.

Re: understanding backquote

[Pascal J. Bourguignon]

Olaf Rogalsky <olaf.rogalsky@aol.de> writes:

>>> I have problems in understanding the semantics of backquote. Consider
> ...
>> (info "(elisp) Backquote")
>
> Yes, I read that, but the manual does not make it entirly clear, at
> which time comma expressions are evaluated: at read or at compile-time:
>
>   9.4 Backquote
>   ...
>   The special marker ‘,’ inside of the argument to backquote indicates a
>   value that isn’t constant. The Emacs Lisp evaluator evaluates the
>   argument of ‘,’, and puts the value in the list structure:
>   ...

Also, consider: '`,(+ 1 2) --> (\` (\, (+ 1 2)))
this shows how this backquote is read.  
In emacs lisp \` is a macro.


-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: understanding backquote

[Barry Margolin]

In article <mailman.4175.1433272668.904.help-gnu-emacs@gnu.org>,
 Olaf Rogalsky <olaf.rogalsky@aol.de> wrote:

> Hi,
> 
> I have problems in understanding the semantics of backquote. Consider
> the following function:
> 
> (defun test () `,(* (+ 1 2) (+ 3 4)))
> 
> Now let's have a look at the defintion of the symbol:
> 
> (symbol-function 'test)
> => (lambda nil (* (+ 1 2) (+ 3 4))) 
> 
> Huhh??? I was thinking, that the above definition is equivalent to the
> following:
> 
> (defun test () 21)
> 
> Ok, this was unexpected, but perhaps the compiler does it "right":
> (disassemble (byte-compile 'test))
> =>  byte code:
>       args: nil
>     0       constant  21
>     1       return    
> 
> Yes, it does. It is only, that I suspect, that this has nothing to do
> with backquotes, but rather with constant folding optimization.
> 
> Can anybody explain this to me?

Backquote and comma operate at read time. The comma means "Don't quote 
this part", so it will be evaluated when the code is run. It doesn't get 
evaluated at read time, though, because that would mess up if it has 
variable references, e.g.

(defun test (a) `,(+ 1 a))

If you looked at this function, it would have to be

(lambda (a) (+ 1 a))

It can't be folded at read time.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Re: understanding backquote

[Olaf Rogalsky]

>> I have problems in understanding the semantics of backquote. Consider
>> the following function:
...
> Backquote and comma operate at read time. The comma means "Don't quote 
> this part", so it will be evaluated when the code is run. It doesn't get 
> evaluated at read time, though, because that would mess up if it has 
> variable references, e.g.
Ah, I always thought, that comma expressions are evaluated at read time.

> (defun test (a) `,(+ 1 a))
>
> If you looked at this function, it would have to be
>
> (lambda (a) (+ 1 a))
>
> It can't be folded at read time.
Yes, I thought this will produce an error.

The elisp manual does not make it totally clear, at which time comma
expressions are evaluated:

  Chapter 9.4 Backquote:

  Backquote constructs allow you to quote a list, but selectively
  evaluate elements of that list. In the simplest case, it is identical
  to the special form quote (described in the previous section; see
  Quoting). For example, these two forms yield identical results:

  `(a list of (+ 2 3) elements)
       => (a list of (+ 2 3) elements)

  '(a list of (+ 2 3) elements)
       => (a list of (+ 2 3) elements)

  The special marker ‘,’ inside of the argument to backquote indicates a
  value that isn’t constant. The Emacs Lisp evaluator evaluates the
  argument of ‘,’, and puts the value in the list structure:

Thanks for clarifying thing up for me.

Is there a way to evaluate parts of a defun during read-time or
byte-compile-time?

Olaf

Re: understanding backquote

[Pascal J. Bourguignon]

Olaf Rogalsky <olaf.rogalsky@aol.de> writes:

> Is there a way to evaluate parts of a defun during read-time or
> byte-compile-time?

In emacs lisp, there's no way to evaluate anything at read-time.
In Common Lisp, you can use the #. dispatching reader macro.

In both emacs lisp and Common Lisp, you can use a toplevel eval-when
form to choose when to evaluate something only at compilation time, but
this doesn't work for subforms.  Notice that some operators have an
"evaluate at compilation-time" rule, but again, this is more clearly
defined for Common Lisp than emacs lisp.

For example CL defconstant says:

    If a defconstant form appears as a top level form, the compiler must
    recognize that name names a constant variable. An implementation may
    choose to evaluate the value-form at compile time, load time, or
    both.  Therefore, users must ensure that the initial-value can be
    evaluated at compile time (regardless of whether or not references
    to name appear in the file) and that it always evaluates to the same
    value.

while the documentation for defconst doesn't say anything about this.


-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: understanding backquote

[Olaf Rogalsky]

Pascal J. Bourguignon writes:

>> Is there a way to evaluate parts of a defun during read-time or
>> byte-compile-time?
>
> In emacs lisp, there's no way to evaluate anything at read-time.
In my use case, computing the constant expression at run time has only
very litle performance overhead, so I guess, I will go along this path.
Still sad, that it is not possible to do it at read or compile time.

Olaf

Re: understanding backquote

[Stefan Monnier]

> Still sad, that it is not possible to do it at read or compile time.

If you want to compute it at compile-time, use `eval-when-compile'.  E.g.

   (defun foo (bar)
     (eval-when-compile
       (let ((x "toto"))
         (concat x "titi" x))))


-- Stefan

Re: understanding backquote

[Olaf Rogalsky]

> If you want to compute it at compile-time, use `eval-when-compile'.  E.g.
Another possibility would be, to use a temporary variable with lexical scope

(let ((tmp (* (+ 1 2) (+ 3 4))))
  (defun test () tmp))

or even a global variable:

(setq tmp (* (+ 1 2) (+ 3 4)))
(defun test () tmp))

This is not exactly the same as having a read-time evaluation of the expression, since it adds a variable dereferencing 
at run-time to the code. But it gets pretty close.

Olaf

Re: understanding backquote

[Olaf Rogalsky]

For my amusement, I have written another variation on this subject::

(defun recursive-map (fun expr)
  (funcall fun (if (consp expr)
                   (cons (recursive-map fun (car expr))
                         (recursive-map fun (cdr expr)))
                 expr)))

(defun eval-when-read (expr)
  (if (and (consp expr) (eq (car expr) 'eval-when-read))
      (eval (cadr expr))
    expr))

(defmacro read-wrapper (&rest body)
  (cons 'progn
        (mapcar (apply-partially 'recursive-map 'eval-when-read)
                body)))

(read-wrapper
 (defun test ()
   (eval-when-read (* (+ 1 2) (+ 3 4)))))


Olaf



 

Re: understanding backquote

[Pascal J. Bourguignon]

Olaf Rogalsky <olaf.rogalsky@aol.de> writes:

> Pascal J. Bourguignon writes:
>
>>> Is there a way to evaluate parts of a defun during read-time or
>>> byte-compile-time?
>>
>> In emacs lisp, there's no way to evaluate anything at read-time.
> In my use case, computing the constant expression at run time has only
> very litle performance overhead, so I guess, I will go along this path.
> Still sad, that it is not possible to do it at read or compile time.

You can still do it long before it's needed.

-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk