> Is the TAGS format extensible so a new fields could be added?
You'd need to update the etags program for that, and also the Lisp
commands that access TAGS and operate on it.
> It would useful if the identifiers were tagged (pun intended) with the
> the "type": class, method, static function, constant etc.
> For example find-tag could then support a customized
> find-first/find-next order (eg. class first).
> You could also use it to make the function guess-class-name-at-point. I
> have previously needed this for my tempo expansions for C++ member
> functions.
If you are talking about C++, Emacs already comes with a program
called 'ebrowse' and a matching set of Emacs commands, which I think
are supposed to support all that already. I suggest to read the
ebrowse manual (bundled with Emacs) and see if you can put that to
good use.
On Fri, Oct 05 2012 16:49 (@1349448587), Tom wrote:
> Óscar Fuentes <ofv <at> wanadoo.es> writes:
>> Emacs has partial support for some of those features, with CEDET always
>> shining on the horizon, but instead of catching up with other IDEs as
>> time passes, it is falling behind.
> The Eclipse developers should be persuaded somehow to separate
> the completion/refactoring stuff into a separate library. Is > there a reason why this part is tied to their GUI editor? If it
> were a separate library then any editor could use it, not just > Eclipse.
Eli Zaretskii <e...@gnu.org> writes:
>> It would useful if the identifiers were tagged (pun intended) with the
>> the "type": class, method, static function, constant etc.
>> For example find-tag could then support a customized
>> find-first/find-next order (eg. class first).
>> You could also use it to make the function guess-class-name-at-point. I
>> have previously needed this for my tempo expansions for C++ member
>> functions.
> If you are talking about C++, Emacs already comes with a program
> called 'ebrowse' and a matching set of Emacs commands, which I think
> are supposed to support all that already. I suggest to read the
> ebrowse manual (bundled with Emacs) and see if you can put that to
> good use.
I triede ebrowse when it came out. It is a flop and no one uses/talks
about it anymore. It might as well be removed from Emacs.
CEDET/Semantic is the new hotness. I try it every 2 years for a short
while. It always ends up slowing down my Emacs with various lockups
because of all the parsing it does. Perhaps it works better in 24.3?
I am not specifically talking about C++, that what just an example. I
would like see the TAGS file extended with a "type" field so that my
imagined guess-class-name-at-point function would work for *all*
programming languages. It would be nice if Emacs had a generic API(*)
for semantic information so that for example auto completion system
could be written without specific knowledge of the major-mode (~
programming language).
*) guess-class-name-at-point, find-class-for-identifier-at-point, etc.
Philipp Haselwarter <philipp <at> haselwarter.org> writes:
> > The Eclipse developers should be persuaded somehow to separate
> > the completion/refactoring stuff into a separate library. Is > > there a reason why this part is tied to their GUI editor? If it
> > were a separate library then any editor could use it, not just > > Eclipse.
> That would be Eclipse headless. Check out eclim.
Yes, Eclim is a good workaround, but it's not the same thing
as having a separate library in the official Eclipse tree. As far as I
know Eclim supports only a subset of Eclipse features. If the
completing/refactoring part were officially an independent part of Eclipse then its interface would support all available
features (because the Eclipse IDE would also use this interface),
so it would only be the matter of creating an Emacs interface to
have all the features available in Emacs.
Currently, eclim is an outside effort to gain access to Eclipse
features, therefore it lags behind Eclipse and does not support
all features, probably because of lack of resources which would
not be a problem if separating the language intelligence part
was done within the Eclipse project itself in the first place.
I recently discovered that CYGWIN delivers "Exuberant Ctags" (Yes, etags too.) and it is used instead of emacs' etags. (GPL, available at http://ctags.sourceforge.net.)
Exuberant Ctags can be extended to look for other things via regular expression. It is a wonderful thing!
I can now look for tags in my shell code to by running: etags --langdef=shell --regex-shell='/function [_[:alnum:]]+/[_[:alnum:]]+/' --language-force=shell
(Unfortunate side-effect: That can also pick up comments, so I also have to fix things:
sed -n -e '/#/d' -ep < TAGS > TTT && mv TTT TAGS
Oh, well.)
Shell programming is suddenly almost pleasant!
> -----Original Message-----
> From: help-gnu-emacs-bounces+dougl=shubertticketing....@gnu.org
> [mailto:help-gnu-emacs-bounces+dougl=shubertticketing....@gnu.org] On
> Behalf Of Vagn Johansen
> Sent: Saturday, 2012 October 06 03:57
> To: help-gnu-em...@gnu.org
> Subject: Re: IDE versus emacs
> Is the TAGS format extensible so a new fields could be added?
> It would useful if the identifiers were tagged (pun intended) with the
> the "type": class, method, static function, constant etc.
> For example find-tag could then support a customized
> find-first/find-next order (eg. class first).
> You could also use it to make the function guess-class-name-at-point. I
> have previously needed this for my tempo expansions for C++ member
> functions.
>>>>> Eli Zaretskii <e...@gnu.org>:
> At least in C and C++, tags never miss a definition for me. My only
> problem with tags is that they sometimes show me more definitions
> other than what I had in mind that match the symbol I type, either
> because of case insensitivity or because of partial matches.
Can tags filter out those symbols that would match what you're typing,
but aren't reachable from the point in the code where you are typing?
>> At least in C and C++, tags never miss a definition for me. My only
>> problem with tags is that they sometimes show me more definitions
>> other than what I had in mind that match the symbol I type, either
>> because of case insensitivity or because of partial matches.
> Can tags filter out those symbols that would match what you're typing,
> but aren't reachable from the point in the code where you are typing?
No. tags is mostly horrible. I can only use it for finding definitions and even that, only sometimes. Modern C++ codebases (lots of templates) just do not do well with tags.
> > At least in C and C++, tags never miss a definition for me. My only
> > problem with tags is that they sometimes show me more definitions
> > other than what I had in mind that match the symbol I type, either
> > because of case insensitivity or because of partial matches.
> Can tags filter out those symbols that would match what you're typing,
> but aren't reachable from the point in the code where you are typing?
I don't understand the question. Tags don't "match symbols", they
show you the definition of the symbol. That definition is not related
to scope.
> No. tags is mostly horrible. I can only use it for finding > definition and even that, only sometimes. Modern C++
> codebases (lots of templates) just do not do well with tags.
Not to disagree, but I would just like to point out where (I think) the real
problem is. It is not with the Emacs tags mechanism or with the ability to look
up and navigate among tags. It is with the generation of the TAGS file.
Emacs tags can really be anything at all. The mechanism is quite general. The
term "definition" is appropriate for most existing tags: what is indexed are in
fact definitions of functions, structs, whatever.
But that need not be the case. Really, anything at all can be indexed. And
tags need not even be limited to programming languages - you could tag a
thesaurus or Shakespeare's works in various ways, if you wanted to.
So what's needed (again, just trying to clarify) are programs to generate tags
(i.e. a TAGS file) that are appropriate for your use. No doubt the existing
tag-generating programs (ctags, etags, ...) are too limited at present to index
the kinds of things you and others would like.
That's where I think the problem lies. And guess what? AFAIK, that has very
little to do with Emacs (see below).
Think of that as an opportunity (for Someone(TM)) to write a program that
generates a more useful TAGS file for your context/environment. Once that's
done, I expect that you will find the existing Emacs tags mechanism and
navigation among your (appropriate) tags to be satisfactory.
Yes, there are other limitations, which you hinted at by mentioning wanting to
limit searches based on your current context. There is currently no way AFAIK
to filter a set of candidate tags to those you might consider appropriate based
on where you are currently.
But that could be done, and it probably would not be difficult to do, depending
on precisely what you mean. It is trivial to get hold of all of the tags
matching your input and filter those - you just need to be able to define that
filtering, based on your context and what you mean/want. That, at least, is an
Emacs-Lisp job, unlike the rest of what I expect is needed for you.
(Of course, prefiltering, i.e., limiting the tags to search before matching your
input (presumably for better performance), could be more involved.)
One design limitation of the tags mechanism is that a TAGS file is a static
snapshot, which might not be up-to-date when you use it. Navigating to existing
tag locations is typically not a problem, even if the file is not up-to-date.
But being out of date means that it does not index thingies that were created
after the file was generated, obviously.
This is an inherent limitation, but of course the TAGS file can be regenerated
on demand, provided users have the program to do so.
The Emacs tags mechanism is pretty good, I think. The main thing that's missing
for you is an up-to-date program that generates tags for the kinds of things you
are interested in.
That really has little to do with Emacs itself (depending on one's point of
view), and it just awaits some interested programmer to get 'er done.
To do that requires knowledge of your programming language (syntax, and
semantics to some extent). And it requires general programming knowledge to
write the program (e.g. a program somewhat like etags). And it requires
knowledge of the TAGS file structure. And it requires some time and motivation.
But AFAIK it does not really require any knowledge of Emacs or Emacs Lisp.
That's why I say that it in fact has little to do with Emacs itself.
Of course, Emacs _users_ like yourself will be grateful, once it's done. Since
we see such complaints here from time to time, perhaps this task would make a
good school, or summer of code, project. Dunno.
One part of the task would be deciding just what it is that you would like to
index, for what languages, etc. IOW, specify the requirements.
> One design limitation of the tags mechanism is that a TAGS file is a static
> snapshot, which might not be up-to-date when you use it. Navigating to existing
> tag locations is typically not a problem, even if the file is not up-to-date.
> But being out of date means that it does not index thingies that were created
> after the file was generated, obviously.
I agree with everything you have said and here is what I do to keep my TAGS file up to date:
It requires the use of prosjekt. When the project is opened, TAGS are re-generated and whenever a file is saved, that TAGS file is updated.
Good enough for me most of the time, but yeah, it would be beyond awesome if Someone (TM) would use clang or something that understands C++ better to generate the TAGS files...
> Good enough for me most of the time, but yeah, it would be beyond > awesome if Someone (TM) would use clang or something that understands > C++ better to generate the TAGS files...
As an alternative you can give a try to eclim. It supports the following features for C++:
AFAIK the emacs eclim interface supports only Java currently,
but if you know Elisp then it should not be hard to add
C++ too (the infrastructure is there, you only have to add
the calls for the C++ commands of the eclim interface).
On Sat, Oct 20, 2012 at 2:01 AM, Tom <adatgyu...@gmail.com> wrote:
> Sohail Somani <sohail <at> taggedtype.net> writes:
> > Good enough for me most of the time, but yeah, it would be beyond
> > awesome if Someone (TM) would use clang or something that understands
> > C++ better to generate the TAGS files...
> As an alternative you can give a try to eclim. It supports the
> following features for C++:
> AFAIK the emacs eclim interface supports only Java currently,
> but if you know Elisp then it should not be hard to add
> C++ too (the infrastructure is there, you only have to add
> the calls for the C++ commands of the eclim interface).
It is quite usable, especially for Java, but it does not implement
all the features of eclim, so it can even be better if people
help out.
The emacs-eclim authors welcome contributions, see the bottom of
the page at the above link.
Here are the full list of eclim features from which only the Java-related
things are implemented in emacs and not all of those either, so those who
know elisp can help making emacs-eclim better:
Our group has a set of C "projects", and some of them build off of each
other (for example, there's ffs, atl, genthread, and evpath requires the
previous 3.. something like that). When i come across a struct or
something, I just want to be able to jump to it.. I used to be able to do
it (only within a specific project though.. evpath could only jump to
evpath things), but is there a way via CEDET and semantic to do this? I
feel like I should be able to set it up, I just don't know how...
> It is quite usable, especially for Java, but it does not implement
> all the features of eclim, so it can even be better if people
> help out.
> The emacs-eclim authors welcome contributions, see the bottom of
> the page at the above link.
> Here are the full list of eclim features from which only the Java-related
> things are implemented in emacs and not all of those either, so those who
> know elisp can help making emacs-eclim better:
>>>>> Eli Zaretskii <e...@gnu.org>:
>> From: Steinar Bang <s...@dod.no>
>> Can tags filter out those symbols that would match what you're
>> typing, but aren't reachable from the point in the code where you are
>> typing?
> I don't understand the question. Tags don't "match symbols", they
> show you the definition of the symbol. That definition is not related
> to scope.
I was thinking of something along the lines of what eclipse does with
Java files: when you type, it suggests symbols from what's currently
available (depending on scope and what you are doing) and what matches
what you have typed so far.
I have used tags for navigation only, not for helping create new code.
