Hi David,

Many thanks for pointing out that including the header in the .inl file did the trick. For some reason, when trying completion on a vector, in my prior tests on the standard .cpp, .h combination, I obtained the complete list of available methods for the vector type and I was expecting the same for the .inl. Now it seems, from the .inl, that I have to give a few letters to get the proper completion. Of course, having to comment out the include in the .inl file is very tedious; I usually use include guards in my code but didn't tried on that sample I sent you - nonetheless, your "dirty" function to add an include is much appreciated. Still, this leads me to a new question: I found in semanticdb config menu the following settings for a symbol lookup (semanticdb-find-default-throttle): '(local project unloaded system recursive). If, as I understood it, these are actually different fallbacks for searching references to a symbol, I would assume that the include isn't really required as long as, say, your declarations and the file referring to them are in the same project. Obviously, since my tests have shown otherwise, I must discard these assumptions or perhaps revise my config. So this makes me ask: can't cedet look it the current projet's declarations for proper completion? If so, any thoughts on how to enable it?

- Btw, I tried (without success) to modify ede so that it will let me add a .inl to the current target by modifying the following function (in ede-generic.el):

;;; A list of different targets
(defclass ede-generic-target-c-cpp (ede-generic-target)
  ((shortname :initform "C/C++")
   (extension :initform "\\([ch]\\(pp\\|xx\\|\\+\\+\\)?\\|cc\\|hh\\|CC?\\)|inl"))
  "EDE Generic Project target for C and C++ code.
All directories need at least one target.")

Is this the right place? Any suggestion on how could I achieve this?

Thanks again for your time and responses!

Mathieu

On Tue, Oct 18, 2011 at 8:04 AM, cedet-semantic-request@lists.sourceforge.net <cedet-semantic-request@lists.sourceforge.net> wrote:
Send cedet-semantic mailing list submissions to
       cedet-semantic@lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
       https://lists.sourceforge.net/lists/listinfo/cedet-semantic
or, via email, send a message with subject or body 'help' to
       cedet-semantic-request@lists.sourceforge.net

You can reach the person managing the list at
       cedet-semantic-owner@lists.sourceforge.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of cedet-semantic digest..."


---------- Forwarded message ----------
From: David Engster <deng@randomsample.de>
To: "cedet-semantic@lists.sourceforge.net" <cedet-semantic@lists.sourceforge.net>
Date: Mon, 17 Oct 2011 12:28:02 -0400
Subject: Re: [cedet-semantic] Completion on .inl files
Mathieu Béliveau writes:
> Here's included a small sample project. Note: I also did tried to add a
> temporary #include "Sample.h" in the .inl file but it didn't seemed to help
> the completion (and as it obviously creates a dependency loop, I'd prefer to
> avoid that anyways. Also note that the use of template here is purely
> artificial but I did it to clearly show why I'm using a .inl file (namely to
> have a way enforce the interface and implementation separation idiom when
> using templates.)

Temporarily #includ'ing "Sample.h" did the trick for me. For avoiding
dependency loops I'd just use include guards.

Anyway, if for some reason this doesn't work out, here's a very ugly
solution which will add the proper #include to the tags behind your back
when the cache gets updated:

(defun DE-inl-add-header-file (taglist)
 "Super-ugly function to add appropriate header to C++ .inl file."
 (let ((name (buffer-file-name (current-buffer)))
       old)
   (when (and name taglist
              (eq major-mode 'c++-mode)
              (string-match "\\(.*\\)\\.inl\\'" name))
     (setq old (car taglist))
     (setcar taglist
             (semantic-tag-new-include (concat (match-string 1 name) ".h") nil))
     (setcdr taglist (cons old (cdr taglist))))))

(add-hook 'semantic-after-toplevel-cache-change-hook 'DE-inl-add-header-file)

It depends on the .inl and .h files having the same basename, though.

Cheers,
David




---------- Forwarded message ----------
From: Simon Bin <sbin23435@googlemail.com>
To: "cedet-semantic@lists.sourceforge.net" <cedet-semantic@lists.sourceforge.net>
Date: Tue, 18 Oct 2011 04:21:32 -0400
Subject: Re: [cedet-semantic] Semantic intellisense "cannot find types for..."
First of all, thank you so much for your reply. I updated my config
according to your recommendations.

2011/10/9 David Engster <deng@randomsample.de>
>
> Watch out for preprocessor symbols which may be not be defined. When I
> add
>
>              :spp-table '( ("IPOQUE_PROTOCOL_PPLIVE" . "1") )
>
> completions for ipoque_struct work for me

amazing, that works. What's the proper way around manual spp-table
entries? Adding it to the global semantic-lex-c-preprocessor-
symbol-file works, but why

              :spp-files '(
                         "ipq_protocols_osdpi.h"
                   )

doesn't?

> If you find out which files are causing this, please let us know. So
> far, I didn't see this with opendpi.

There seem to be additional parsing problems in some of the opendpi
files that other people in my surroundings have extended from the
public version. :-( I already found one cause: in one of the header
files, someone used  a construct like this:

    #define CONSTANT 4 /* comment
        comment continued
        comment continued */

I'm not sure if this is legal C (the project apparently compiles...)
but semantic stumbles on this comment, as it is started on a #define.
The decoration-mode allowed me to quickly identify this problem: when
I opened the header file, starting from this comment it was underlined
in red.

Thanks again,
Simon