Re: Code completion

Re: Code completion

[Boof]

Jorge Peixoto de Morais Neto wrote:
> How can I get code completion in Emacs? I got used to it by programming in
> Python's IDLE (althoug I'm more insterested in C now).
>
> Also, under Eclipse, I put the mouse over a variable and Eclipse tells me
> where did the variable came from. I like it. How can I do something like it
> in Emacs?
>
> I can't find it in Google or the documentation.
>
> Thanks.

Is M-/ what you're looking for? That does some completion.

etags will tell you where a variable came from, but I'm not a super
expert on it.

M-x info and drill down into the Emacs section. I'm pretty sure there's
more info there on it than you could ever use.

Re: Code completion

[Thorsten Bonow]

>>>>> "Boof" == Boof  <mckay.marston@gmail.com> writes:

    Boof> Jorge Peixoto de Morais Neto wrote:
    >> How can I get code completion in Emacs? I got used to it by programming
    >> in Python's IDLE (althoug I'm more insterested in C now).
    >>
    >> Also, under Eclipse, I put the mouse over a variable and Eclipse tells me
    >> where did the variable came from. I like it. How can I do something like
    >> it in Emacs?

This is a FAQ. Google for infos about CEDET, semantic and ecb:

     http://cedet.sourceforge.net/intellisense.shtml

Hope this helps.

Toto


-- 
Contact information and PGP key at
http://www-users.rwth-aachen.de/thorsten.bonow

Golf is the only opportunity that middle-aged Wasps have to dress up
like a pimp.

Friedman, Kinky (1993), When the cat's away. New York (Wings Books),
477

Re: Code completion

[Jorge Peixoto de Morais Neto]

[-- Attachment #1.1: Type: text/plain, Size: 309 bytes --]

>
> This is a FAQ. Google for infos about CEDET, sematic and ecb:
>
>      http://cedet.sourceforge.net/intellisense.shtml
>
> Thanks, I'm already using M-/ and c-eldoc. I'll take a look at etags (from
emacs' info) and later I may take a look at CEDET.
-- 
Software is like sex: it is better when it is free.

[-- Attachment #1.2: Type: text/html, Size: 553 bytes --]

[-- Attachment #2: Type: text/plain, Size: 152 bytes --]

_______________________________________________
help-gnu-emacs mailing list
help-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnu-emacs

Re: code completion

[Richard G Riley]

Alain Muls <alain.muls@gmail.com> writes:

> Hi
>
> I checked and tried several possibilities to have code completion in
> c++ but none is working as I would like. I tried etags, global,
> xrefactory. Which one can give me the possible (correct) completions
> of a method in c++, eg.
>
> 3Dpoint.get
>
> if I press <tab> (preferably), I would like it to suggest
>
> getCartesian()
> getGeodetic()
>
> Tx/Alain
>
> PS: it would be something similar to the completion you have in
> SlickEdit or kdevelop

It's a commonly asked question and frequently goes without an answer. I
tried semantic but couldn't really get it to work. You might ask on
their mailing list as I think thats the only route. I have a nasty
feeling that using emacs as a C/C++ IDE might be coming to the end of
the road as it falls behind in many of the features (code completion,
refactoring for an example) that more modern IDEs like Eclipse
provides. The maintainer of ecb as good as said the same. A shame.

Re: code completion

[Eli Zaretskii]

> From: Richard G Riley <rileyrgdev@gmail.com>
> Date: Tue, 11 Mar 2008 16:56:11 +0100
> 
> I have a nasty
> feeling that using emacs as a C/C++ IDE might be coming to the end of
> the road as it falls behind in many of the features (code completion,
> refactoring for an example) that more modern IDEs like Eclipse
> provides. The maintainer of ecb as good as said the same. A shame.

It's indeed a shame that no one of you young programmers who need this
``modern IDE'' stuff steps forward to add such features to Emacs.
Don't just rely on us old farts!

Every useful feature in Emacs (and elsewhere in Free Software) started
as a programmer's itch.  There's nothing particularly hard about
adding this, much of the infrastructure is already there.  All you
need is a little time and some will power.

TIA

Re: code completion

[Lennart Borgman (gmail)]

Eli Zaretskii wrote:
>> From: Richard G Riley <rileyrgdev@gmail.com>
>> Date: Tue, 11 Mar 2008 16:56:11 +0100
>>
>> I have a nasty
>> feeling that using emacs as a C/C++ IDE might be coming to the end of
>> the road as it falls behind in many of the features (code completion,
>> refactoring for an example) that more modern IDEs like Eclipse
>> provides. The maintainer of ecb as good as said the same. A shame.
> 
> It's indeed a shame that no one of you young programmers who need this
> ``modern IDE'' stuff steps forward to add such features to Emacs.
> Don't just rely on us old farts!
> 
> Every useful feature in Emacs (and elsewhere in Free Software) started
> as a programmer's itch.  There's nothing particularly hard about
> adding this, much of the infrastructure is already there.  All you
> need is a little time and some will power.


It looks to me like Eric Ludlam is very actively developing 
CEDET/Semantic/EDE right now.

I do not understand these things very well at all, but is not that a 
very promising framework?

Re: code completion

[Eli Zaretskii]

> Date: Tue, 11 Mar 2008 22:07:54 +0100
> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
> CC: help-gnu-emacs@gnu.org
> 
> It looks to me like Eric Ludlam is very actively developing 
> CEDET/Semantic/EDE right now.
> 
> I do not understand these things very well at all, but is not that a 
> very promising framework?

To me, CEDET is too heavyweight.  But that's me.

Re: code completion

[Richard G Riley]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

> Eli Zaretskii wrote:
>>> From: Richard G Riley <rileyrgdev@gmail.com>
>>> Date: Tue, 11 Mar 2008 16:56:11 +0100
>>>
>>> I have a nasty
>>> feeling that using emacs as a C/C++ IDE might be coming to the end of
>>> the road as it falls behind in many of the features (code completion,
>>> refactoring for an example) that more modern IDEs like Eclipse
>>> provides. The maintainer of ecb as good as said the same. A shame.
>>
>> It's indeed a shame that no one of you young programmers who need this
>> ``modern IDE'' stuff steps forward to add such features to Emacs.
>> Don't just rely on us old farts!
>>
>> Every useful feature in Emacs (and elsewhere in Free Software) started
>> as a programmer's itch.  There's nothing particularly hard about
>> adding this, much of the infrastructure is already there.  All you
>> need is a little time and some will power.
>
>
> It looks to me like Eric Ludlam is very actively developing
> CEDET/Semantic/EDE right now.

Thats good news. I had had the impression it was a bit on the back
burner. My mistake if not. It was the programmer of the ecb framework
who seemed a little more reluctant to see everything as rosy.

The last release of the cedet collection was June 2007. Semantic 2003,
speedbar 2002, cogre 2001, ede 2001.

> I do not understand these things very well at all, but is not that a
> very promising framework?

Be sure these are wonderful tools. And in freely given time and effort
one can not in any way criticise these tools. However at the end of the
day when compares feature, if one were honest, newer IDEs like Eclipse
do a whole lot more.

Re: code completion

[Arne Schmitz]

Lennart Borgman (gmail) wrote:

>> Every useful feature in Emacs (and elsewhere in Free Software) started
>> as a programmer's itch.  There's nothing particularly hard about
>> adding this, much of the infrastructure is already there.  All you
>> need is a little time and some will power.
> 
> 
> It looks to me like Eric Ludlam is very actively developing
> CEDET/Semantic/EDE right now.
> 
> I do not understand these things very well at all, but is not that a
> very promising framework?

I think it is! So everyone, try it out and help improve it! Even if it is by
commenting on it, reporting bugs etc. What could be better in Semantic /
CEDET is e.g.:

1) Parsing speed -- Parsing in elisp is sloooow for large files. Maybe we
need a real semantic-parser written in C or some other fast language.

2) Refactoring -- given the capabilities it should be possible to refactor a
variable. This is one tool, I am really impressed with in Eclipse, and
would like to see in Emacs.

Arne

-- 
[--- PGP key FD05BED7 --- http://www.root42.de/ ---]

Re: code completion

[Óscar Fuentes]

Arne Schmitz <arne.schmitz@gmx.net> writes:

[snip]

> 1) Parsing speed -- Parsing in elisp is sloooow for large files. Maybe we
> need a real semantic-parser written in C or some other fast language.

This looks like a good candidate:

http://www.gccxml.org/

[snip]

-- 
Oscar

Re: code completion

[Pascal Bourguignon]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Arne Schmitz <arne.schmitz@gmx.net> writes:
>
> [snip]
>
>> 1) Parsing speed -- Parsing in elisp is sloooow for large files. Maybe we
>> need a real semantic-parser written in C or some other fast language.
>
> This looks like a good candidate:
>
> http://www.gccxml.org/

Will parsing of xml be faster in elisp than parsing C?

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

"This machine is a piece of GAGH!  I need dual Opteron 850
processors if I am to do battle with this code!"

Re: code completion

[Tom Tromey]

>>>>> "Pascal" == Pascal Bourguignon <pjb@informatimago.com> writes:

>> http://www.gccxml.org/

Pascal> Will parsing of xml be faster in elisp than parsing C?

You could always make it emit sexps :-)

Tom

Re: code completion

[Lennart Borgman (gmail)]

Tom Tromey wrote:
>>>>>> "Pascal" == Pascal Bourguignon <pjb@informatimago.com> writes:
> 
>>> http://www.gccxml.org/
> 
> Pascal> Will parsing of xml be faster in elisp than parsing C?
> 
> You could always make it emit sexps :-)


Yes, seriously. Maybe those writing gcc-xml could accept it as an 
option. I guess it should be a very simple change to spit out elisp/lisp 
instead of xml, or?

Is gcc some kind of generic compiler that can handle other languages too?

If I do not misremember/misunderstand I think that Eric Ludlam wrote 
that different parsers could be used by the CEDET/Semantic framework.

Re: code completion

[Tom Tromey]

>>>>> "Lennart" == Lennart Borgman (gmail) <lennart.borgman@gmail.com> writes:

>>>> http://www.gccxml.org/
>> 
Pascal> Will parsing of xml be faster in elisp than parsing C?
>> 
>> You could always make it emit sexps :-)

Lennart> Yes, seriously. Maybe those writing gcc-xml could accept it
Lennart> as an option. I guess it should be a very simple change to
Lennart> spit out elisp/lisp instead of xml, or?

Yeah.  Though... XML is important enough nowadays that Emacs really
ought to be able to parse it with good performance.  If this means
linking to an XML library written in C, then IMO it would be a good
idea.

Lennart> Is gcc some kind of generic compiler that can handle other
Lennart> languages too?

GCC has multiple front ends, but AFAIK gccxml is only for C++.

Tom

Re: code completion

[Lennart Borgman (gmail)]

Tom Tromey wrote:
>>>>>> "Lennart" == Lennart Borgman (gmail) <lennart.borgman@gmail.com> writes:
> 
>>>>> http://www.gccxml.org/
> Pascal> Will parsing of xml be faster in elisp than parsing C?
>>> You could always make it emit sexps :-)
> 
> Lennart> Yes, seriously. Maybe those writing gcc-xml could accept it
> Lennart> as an option. I guess it should be a very simple change to
> Lennart> spit out elisp/lisp instead of xml, or?
> 
> Yeah.  Though... XML is important enough nowadays that Emacs really
> ought to be able to parse it with good performance.  If this means
> linking to an XML library written in C, then IMO it would be a good
> idea.

But parsing xml can't be as fast as just reading elisp code, or? But 
maybe the speed difference would be negligable, I do not know.

Re: code completion

[Jason Rumney]

Lennart Borgman (gmail) wrote:
> But parsing xml can't be as fast as just reading elisp code, or? But 
> maybe the speed difference would be negligable, I do not know.

I just did some unscientific testing, and the lisp xml parser we have 
now seems to parse at about 700kB/s on my machine. How large is the 
output that would need to be parsed?

Re: code completion

[Óscar Fuentes]

Jason Rumney <jasonr@gnu.org> writes:

> Lennart Borgman (gmail) wrote:
>> But parsing xml can't be as fast as just reading elisp code, or? But
>> maybe the speed difference would be negligable, I do not know.
>
> I just did some unscientific testing, and the lisp xml parser we have
> now seems to parse at about 700kB/s on my machine. How large is the
> output that would need to be parsed?

IIRC, parsing the headers of Qt 3.x spitted approx. 8 MB of XML when I
played with gccxml some years ago.

-- 
Oscar

Re: code completion

[Óscar Fuentes]

Pascal Bourguignon <pjb@informatimago.com> writes:

>>> 1) Parsing speed -- Parsing in elisp is sloooow for large files. Maybe we
>>> need a real semantic-parser written in C or some other fast language.
>>
>> This looks like a good candidate:
>>
>> http://www.gccxml.org/
>
> Will parsing of xml be faster in elisp than parsing C?

Last time I checked, gccxml didn't need a full XML parser.

Anyways, parsing XML is faster and *simpler* than parsing C++ (and
parsing gccxml output may be faster and simpler than parsing C too).

-- 
Oscar

Re: code completion

[Richard G Riley]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Richard G Riley <rileyrgdev@gmail.com>
>> Date: Tue, 11 Mar 2008 16:56:11 +0100
>> 
>> I have a nasty
>> feeling that using emacs as a C/C++ IDE might be coming to the end of
>> the road as it falls behind in many of the features (code completion,
>> refactoring for an example) that more modern IDEs like Eclipse
>> provides. The maintainer of ecb as good as said the same. A shame.
>
> It's indeed a shame that no one of you young programmers who need this
> ``modern IDE'' stuff steps forward to add such features to Emacs.
> Don't just rely on us old farts!

I'm not a young programmer. And certainly not an elisp programmer. As
for "need" we dont really "need" more than a text editor, but like all
productivity tools sometimes additions like code completion make life a
lot easier.

>
> Every useful feature in Emacs (and elsewhere in Free Software) started
> as a programmer's itch.  There's nothing particularly hard about
> adding this, much of the infrastructure is already there.  All you
> need is a little time and some will power.

A lot more than a little. If adding real code completion was so easy I
think it would be working a lot better - better programmers than me have
attempted it in things like ebrowse, hippy-complete, and senator. I can
only take the somewhat selfish view and hope someone else implements it
:-;

I use solely emacs, but if you're honest you know that something like
Eclipse is a lot better as a Java/C/C++ IDE in many ways. Not all. But
many ways. The things that keep me with emacs are such tools as org-mode
and nxhtml. As well as Gnus of course:-; It's certainly not "dead in the
water" and is a marvellous IDE in many, many ways.

Re: code completion

[Eli Zaretskii]

> From: Richard G Riley <rileyrgdev@gmail.com>
> Date: Tue, 11 Mar 2008 22:05:03 +0100
> 
> > Every useful feature in Emacs (and elsewhere in Free Software) started
> > as a programmer's itch.  There's nothing particularly hard about
> > adding this, much of the infrastructure is already there.  All you
> > need is a little time and some will power.
> 
> A lot more than a little. If adding real code completion was so easy I
> think it would be working a lot better - better programmers than me have
> attempted it in things like ebrowse, hippy-complete, and senator.

Trust me: it's not hard.  And don't let the fact that others didn't do
that yet distract you.  I'm old enough to know that this happens quite
a lot: what bothers you does not necessarily bothers a genius near you.

> I can only take the somewhat selfish view and hope someone else
> implements it :-;

Too bad.

Re: code completion

[Richard G Riley]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Richard G Riley <rileyrgdev@gmail.com>
>> Date: Tue, 11 Mar 2008 22:05:03 +0100
>> 
>> > Every useful feature in Emacs (and elsewhere in Free Software) started
>> > as a programmer's itch.  There's nothing particularly hard about
>> > adding this, much of the infrastructure is already there.  All you
>> > need is a little time and some will power.
>> 
>> A lot more than a little. If adding real code completion was so easy I
>> think it would be working a lot better - better programmers than me have
>> attempted it in things like ebrowse, hippy-complete, and senator.
>
> Trust me: it's not hard.  And don't let the fact that others didn't do
> that yet distract you.  I'm old enough to know that this happens quite
> a lot: what bothers you does not necessarily bothers a genius near you.
>
>> I can only take the somewhat selfish view and hope someone else
>> implements it :-;
>
> Too bad.

There are only so many hours in a day for all of us Eli. And
unfortunately writing Emacs packages isn't on my time table :(

Re: code completion

[Bastien Guerry]

Richard G Riley <rileyrgdev@gmail.com> writes:

>> It's indeed a shame that no one of you young programmers who need this
>> ``modern IDE'' stuff steps forward to add such features to Emacs.
>> Don't just rely on us old farts!
>
> I'm not a young programmer. And certainly not an elisp programmer. As
> for "need" we dont really "need" more than a text editor, but like all
> productivity tools sometimes additions like code completion make life a
> lot easier.

The OP posted the question on an emacs mailing list, so I assume he
wants to use Emacs.  With this in mind, it looks more useful to tell 
him about possible solutions or other ways to get answers, rather than
proposing him to cancel his request.

-- 
Bastien

Re: code completion

[Richard G Riley]

Bastien Guerry <bzg@altern.org> writes:

> Richard G Riley <rileyrgdev@gmail.com> writes:
>
>>> It's indeed a shame that no one of you young programmers who need this
>>> ``modern IDE'' stuff steps forward to add such features to Emacs.
>>> Don't just rely on us old farts!
>>
>> I'm not a young programmer. And certainly not an elisp programmer. As
>> for "need" we dont really "need" more than a text editor, but like all
>> productivity tools sometimes additions like code completion make life a
>> lot easier.
>
> The OP posted the question on an emacs mailing list, so I assume he
> wants to use Emacs.  With this in mind, it looks more useful to tell 
> him about possible solutions or other ways to get answers, rather than
> proposing him to cancel his request.

This is true to a degree. But it is also worth being honest about the
state of certain tools - and the code completion side of emacs is not
overly strong. I applaud the efforts of emacs developers and give
feedback and/or suggestions for fixes back where I can. This does not
mean one should be overly optimistic about certain features. Code
completion, refactoring and so forth are not strong and relatively hard,
and can be confusing to configure and to use in my opinion. And I use
emacs a lot.

FWIW, I'm in the process of re-evaluating CEDET and so far its working
reasonably well.

However, it would be wrong to say all is flowers and sunshine. It is not
and an honest answer (from my perspective) is more respectful at times.

Re: code completion

[Bastien]

Richard G Riley <rileyrgdev@googlemail.com> writes:

> However, it would be wrong to say all is flowers and sunshine. It is not
> and an honest answer (from my perspective) is more respectful at times.

If someone requests improvements for a feature in Emacs (e.g. code
refactoring) it is honest to tell about the shortcomings of its current
implementation.  It is depressing to recommand the OP to have a look at
other editors, not because it is dishonest, but because such an advice
won't help make the Emacs implementation better.

And the more constructive way is to give directions on how to help
improving the feature.

Imagine this: you create a new tool (say bzr) that aims at being better
than others (say CVS, RCS) wrt some features.  When you start coding the
tool, it is still behind the other ones.  Now imagine that someone likes
your tool and asks about a feature.  What if someone else recommends the
OP to switch to another tool, just because your tool (the one he uses)
doesn't have this feature ?

I guess you woudn't find this constructive...

-- 
Bastien

Re: code completion

[Richard G Riley]

Bastien <bzg@altern.org> writes:

> Richard G Riley <rileyrgdev@googlemail.com> writes:
>
>> However, it would be wrong to say all is flowers and sunshine. It is not
>> and an honest answer (from my perspective) is more respectful at times.
>
> If someone requests improvements for a feature in Emacs (e.g. code
> refactoring) it is honest to tell about the shortcomings of its current
> implementation.  It is depressing to recommand the OP to have a look
> at

It is also honest to state ones opinion as to the current state. And I
have requoted my original statements below in case they are further
misrepresented however unintentionally.

> other editors, not because it is dishonest, but because such an advice
> won't help make the Emacs implementation better.

And neither will "come on in, it all works perfectly."

>
> And the more constructive way is to give directions on how to help
> improving the feature.

I agree. What makes you think this has not happened? I get the feeling
you take my words as some sort of attack? They are not and I am mildly
surprised at your reaction here. Possibly a late night maintaining the
(excellent) org-mode? :-;

In addition, not every programmer has the luxury of the time needed to
negotiate new or fixed features in a tool he needs working
yesterday. These things take a lot of familiarisation and effort.

>
> Imagine this: you create a new tool (say bzr) that aims at being better
> than others (say CVS, RCS) wrt some features.  When you start coding the
> tool, it is still behind the other ones.  Now imagine that someone likes
> your tool and asks about a feature.  What if someone else recommends the
> OP to switch to another tool, just because your tool (the one he uses)
> doesn't have this feature ?

He didn't ask about a specific tool. He asked about code
completion. This could be one of many things in emacs. I mentioned
semantic.

What is your experience of code completion? Have you used CEDET and ecb
etc? 

As for suggesting the op switches to another tool, I would remind you of
what I actually said (including redirecting him to the semantic mailing
list):

,----
| It's a commonly asked question and frequently goes without an answer. I
| tried semantic but couldn't really get it to work. You might ask on
| their mailing list as I think thats the only route. I have a nasty
| feeling that using emacs as a C/C++ IDE might be coming to the end of
| the road as it falls behind in many of the features (code completion,
| refactoring for an example) that more modern IDEs like Eclipse
| provides. The maintainer of ecb as good as said the same. A shame.
`----

What parts of this are wrong or misleading? As i stated, the ecb
developer HIMSELF has voiced his concerns at emacs falling behind too.

>
> I guess you woudn't find this constructive...

I don't really know what you are getting at. I have worked a fair bit
with these tools and given constructive feedback when necessary. As well
as numerous other tools.

You seem to take my honest opinion on the status of emacs code
completion as some sort of attack on the editor itself and the tools. It
is not. It is an honest opinion on its suitability and its ability to
compete with other tools for a professional C/C++ programmer.

The bottom line is that where emacs excels in some places, it is lagging
in others. Not all of us have the time or the ability to "do it
ourselves" and sometimes it saves people a lot of time and hassle to
forewarn them of possible pitfalls.

Using emacs is an obsession with some of us. I still do ALL my
coding in emacs. Why? Because the positives outweigh the negatives. And
believe me, org-mode is one of the better positives as is the wonderful
nxhtml from Lennart.

YASnippets is cool too.

Re: code completion

[Bastien Guerry]

Hi Richard,

Richard G Riley <rileyrgdev@googlemail.com> writes:

> It is also honest to state ones opinion as to the current state. And I
> have requoted my original statements below in case they are further
> misrepresented however unintentionally.
>
>> other editors, not because it is dishonest, but because such an advice
>> won't help make the Emacs implementation better.
>
> And neither will "come on in, it all works perfectly."

Well, I did not say that...

>> And the more constructive way is to give directions on how to help
>> improving the feature.
>
> I agree. What makes you think this has not happened? 

I'm not saying that you don't agree with the above: but your first reply
to the OP was not as helpful as the last ones, was it?

> I get the feeling you take my words as some sort of attack? They are
> not and I am mildly surprised at your reaction here. Possibly a late
> night maintaining the (excellent) org-mode? :-;

:)

Believe me, no angriness/bitterness in my reaction, and sorry if I gave
the impression that I wanted to lecture you about the good and bad ways
of answering such requests... not my style.  Sometimes my answers are
too shorts, and as english is not my first language it might sounds a
bit "rigid".

> He didn't ask about a specific tool. He asked about code
> completion. 

Well, he asked about code completion in Emacs.  He mentionned SlickEdit
and Kdevelop, so I deduced he wanted to use Emacs, not one of the many
other possibilities. 

> What is your experience of code completion? Have you used CEDET and
> ecb etc?

I tried CEDET Ecb etc. long time ago but thought it was not that
straightforward to install.  And I don't really need code completion 
as I mainly speak elisp (yes, I'm a hobbist, not a programmer.)

> As for suggesting the op switches to another tool, I would remind you of
> what I actually said (including redirecting him to the semantic mailing
> list):
>
> ,----
> | It's a commonly asked question and frequently goes without an answer. I
> | tried semantic but couldn't really get it to work. You might ask on
> | their mailing list as I think thats the only route. I have a nasty
> | feeling that using emacs as a C/C++ IDE might be coming to the end of
> | the road as it falls behind in many of the features (code completion,
> | refactoring for an example) that more modern IDEs like Eclipse
> | provides. The maintainer of ecb as good as said the same. A shame.
> `----
>
> What parts of this are wrong or misleading? 

Nothing wrong or misleading.  I just said: "depressing".

You said:

  I have a nasty feeling that using emacs as a C/C++ IDE might be coming
  to the end of the road as it falls behind in many of the features
  (code completion, refactoring for an example) that more modern IDEs
  like Eclipse provides.

So what reaction do you expect from the OP?  If I were him, I would
think of giving up Emacs for coding in C/C++.  This is what I found
depressing.  

> As i stated, the ecb developer HIMSELF has voiced his concerns at
> emacs falling behind too.

So what? 

> The bottom line is that where emacs excels in some places, it is
> lagging in others. Not all of us have the time or the ability to "do
> it ourselves" and sometimes it saves people a lot of time and hassle
> to forewarn them of possible pitfalls.

Okay, but my bottom line was that it is more helpful to give directions
on how to improve the feature (and you did somehow, telling him to ask
the question on the semantic mailing list) rather than letting him that
"emacs as a C/C++ IDE might be coming to the end of the road"...  

You don't know, maybe the itch is strong enough for him that he will try
his best to follow his direction.  If we all assume that nobody has the
time to improve the features, then maybe we should close this mailing
list?  I generally prefer to assume people at the end will be able to
help !  

> Using emacs is an obsession with some of us. 

I know what you mean!  And sometimes, just people feel ashamed of this
and they find a relief in "telling the truth" about modern editors.

Don't feel ashamed!  Don't surrender!

:)

-- 
Bastien

Re: code completion

[Richard G Riley]

Bastien Guerry <bzg@altern.org> writes:

> Hi Richard,
>
> Richard G Riley <rileyrgdev@googlemail.com> writes:
>
>> It is also honest to state ones opinion as to the current state. And I
>> have requoted my original statements below in case they are further
>> misrepresented however unintentionally.
>>
>>> other editors, not because it is dishonest, but because such an advice
>>> won't help make the Emacs implementation better.
>>
>> And neither will "come on in, it all works perfectly."
>
> Well, I did not say that...

No, but it seemed that was what you meant ... All I did was suggest that
code completion in emacs is not very good compared to some other
tools.

>
>>> And the more constructive way is to give directions on how to help
>>> improving the feature.
>>
>> I agree. What makes you think this has not happened? 
>
> I'm not saying that you don't agree with the above: but your first reply
> to the OP was not as helpful as the last ones, was it?

It was a general comment. And like I said, I did point him to
Semantic. You know, where he can read the docs etc? Other replies were
more helpful as the thread beefed out a bit more.

>
>> I get the feeling you take my words as some sort of attack? They are
>> not and I am mildly surprised at your reaction here. Possibly a late
>> night maintaining the (excellent) org-mode? :-;
>
> :)
>
> Believe me, no angriness/bitterness in my reaction, and sorry if I gave
> the impression that I wanted to lecture you about the good and bad ways
> of answering such requests... not my style.  Sometimes my answers are
> too shorts, and as english is not my first language it might sounds a
> bit "rigid".

No problemo.

>
>> He didn't ask about a specific tool. He asked about code
>> completion. 
>
> Well, he asked about code completion in Emacs.  He mentionned
> SlickEdit

Which is why I commented on my experiences with emacs and pointed him to
the semantic mailing list ....

> and Kdevelop, so I deduced he wanted to use Emacs, not one of the many
> other possibilities. 

You have me lost. I never pointed him to other editors. I merely
compared certain features. There is a big difference.

>
>> What is your experience of code completion? Have you used CEDET and
>> ecb etc?
>
> I tried CEDET Ecb etc. long time ago but thought it was not that
> straightforward to install.  And I don't really need code completion 

Me neither (re: installation). Difficult for a nOOb. It is very hard to
figure out what does what IMO. And another reason for my initial words
of caution. But I suspect my familiarity with it is better than yours.

> as I mainly speak elisp (yes, I'm a hobbist, not a programmer.)
>
>> As for suggesting the op switches to another tool, I would remind you of
>> what I actually said (including redirecting him to the semantic mailing
>> list):
>>
>> ,----
>> | It's a commonly asked question and frequently goes without an answer. I
>> | tried semantic but couldn't really get it to work. You might ask on
>> | their mailing list as I think thats the only route. I have a nasty
>> | feeling that using emacs as a C/C++ IDE might be coming to the end of
>> | the road as it falls behind in many of the features (code completion,
>> | refactoring for an example) that more modern IDEs like Eclipse
>> | provides. The maintainer of ecb as good as said the same. A shame.
>> `----
>>
>> What parts of this are wrong or misleading? 
>
> Nothing wrong or misleading.  I just said: "depressing".
>
> You said:
>
>   I have a nasty feeling that using emacs as a C/C++ IDE might be coming
>   to the end of the road as it falls behind in many of the features
>   (code completion, refactoring for an example) that more modern IDEs
>   like Eclipse provides.
>
> So what reaction do you expect from the OP?  If I were him, I would
> think of giving up Emacs for coding in C/C++.  This is what I found
> depressing.  

It might be depressing for you. But its also true. I have spent ages
getting emacs to work just right for my programming needs. But its a
trade off.

I dont think telling lies to keep him with emacs is good either. if you
keep the expectancy resonable then people wont be disappointed. I *am*
disappointed at the state of some of the tools in emacs - unfortunately
I'm not in a position (currently) to improve them although I have given
feedback where appropriate even some code snippets at times.


>
>> As i stated, the ecb developer HIMSELF has voiced his concerns at
>> emacs falling behind too.
>
> So what? 

I would think that was obvious. It was reaffirming my comments. From
someone who has put a lot of time and effort into developing IDE like
qualities in emacs. It doesnt mean we mean "drop emacs". It just means
"be prepared not to be at the leading edge of c editors in terms of
certain development tools".

>
>> The bottom line is that where emacs excels in some places, it is
>> lagging in others. Not all of us have the time or the ability to "do
>> it ourselves" and sometimes it saves people a lot of time and hassle
>> to forewarn them of possible pitfalls.
>
> Okay, but my bottom line was that it is more helpful to give directions
> on how to improve the feature (and you did somehow, telling him to ask
> the question on the semantic mailing list) rather than letting him that
> "emacs as a C/C++ IDE might be coming to the end of the road"...  

I did point him that way didn't I? And I also pointed out that emacs is
NOT so good at certain things which it isn't good at. It was letting him
know some facts. I am sorry you think that is not a good thing to do.

>
> You don't know, maybe the itch is strong enough for him that he will try
> his best to follow his direction.  If we all assume that nobody has the
> time to improve the features, then maybe we should close this mailing
> list?  I generally prefer to assume people at the end will be able to
> help !  

You are going ridiculously overboard on this. When someone asks about a
certain feature its best to be honest. Not everyone is a elisp
programmer and not everyone will implement what is missing.

I really am at a loss to understand your reaction to my comments.

People with a far better knowledge of these tools have said similar to
me.

But to reiterate : it is a trade off. I continue to use emacs and
hopefully improve emacs despite the short comings in certain areas. It
is not up to me to second guess the OP - I just cautioned him as to the
state of two major "utilities" which are much better implemented
elsewhere. And also informed him of some other tools.

>
>> Using emacs is an obsession with some of us. 
>
> I know what you mean!  And sometimes, just people feel ashamed of this
> and they find a relief in "telling the truth" about modern editors.

I'm not ashamed. And I get no relief from telling the truth as I see it.

>
> Don't feel ashamed!  Don't surrender!
>
> :)

I really haven't. Emacs is the best thing I ever used. And it gets
better every day.

code completion

[Alain Muls]

[-- Attachment #1: Type: text/plain, Size: 434 bytes --]

Hi

I checked and tried several possibilities to have code completion in c++ 
but none is working as I would like. I tried etags, global, xrefactory. 
Which one can give me the possible (correct) completions of a method in 
c++, eg.

3Dpoint.get

if I press <tab> (preferably), I would like it to suggest

getCartesian()
getGeodetic()

Tx/Alain

PS: it would be something similar to the completion you have in 
SlickEdit or kdevelop


[-- Attachment #2: alain_muls.vcf --]
[-- Type: text/x-vcard, Size: 242 bytes --]

begin:vcard
fn:Alain Muls
n:Muls;Alain
org:RMA;CISS
adr:;;Renaissance Avenue 30;Brussems;;1000;Belgium
email;internet:alain.muls@telenet.be
title:Prof
tel;work:+32.2.7376340
tel;cell:+32.477.675091
x-mozilla-html:FALSE
version:2.1
end:vcard

Re: code completion

[Eli Zaretskii]

> Date: Tue, 11 Mar 2008 15:08:16 +0100
> From: Alain Muls <alain.muls@gmail.com>
> 
> I checked and tried several possibilities to have code completion in c++ 
> but none is working as I would like. I tried etags, global, xrefactory. 
> Which one can give me the possible (correct) completions of a method in 
> c++, eg.
> 
> 3Dpoint.get
> 
> if I press <tab> (preferably), I would like it to suggest
> 
> getCartesian()
> getGeodetic()

You may wish to try Ebrowse (comes with Emacs).  It has tags-like
completion facilities that are C++-aware.  I think.

Re: code completion

[Bastien]

Alain Muls <alain.muls@gmail.com> writes:

> I checked and tried several possibilities to have code completion in
> c++ but none is working as I would like. I tried etags, global,
> xrefactory. Which one can give me the possible (correct) completions
> of a method in c++, eg.

Maybe you can contact the developers/maintainers directly and ask them
about the missing feature:

     etags: Roland McGrath <roland@gnu.org>
Xrefactory: vittek@xref-tech.com

(I don't know global.)

> if I press <tab> (preferably), I would like it to suggest
>
> getCartesian()
> getGeodetic()

Shouldn't be that hard to add this.

-- 
Bastien

Re: code completion

[Richard G Riley]

Bastien <bzg@altern.org> writes:

> Alain Muls <alain.muls@gmail.com> writes:
>
>> I checked and tried several possibilities to have code completion in
>> c++ but none is working as I would like. I tried etags, global,
>> xrefactory. Which one can give me the possible (correct) completions
>> of a method in c++, eg.
>
> Maybe you can contact the developers/maintainers directly and ask them
> about the missing feature:
>
>      etags: Roland McGrath <roland@gnu.org>
> Xrefactory: vittek@xref-tech.com
>
> (I don't know global.)
>
>> if I press <tab> (preferably), I would like it to suggest
>>
>> getCartesian()
>> getGeodetic()
>
> Shouldn't be that hard to add this.

Have you tried? I would be interested in your solutions and the toolsets
you have tried for C/C++ code navigation as I'm still humming and
harring myself.

Last night a I spent a few hours downloading and installing and
configuring the latest cedet. After setting up project paths, c-paths
and turning on the semantic idle completion scheduler it works
reasonably well for C. Only things that did not complete were fields
protected by guard flags (to be expected), structs represented by
typedefs and structs defined in the c file as opposed to an h file - I'm
not sure if by design or not - but this is quite a subset.

I prepared a post yesterday that got "drafted" in a system reset but it
pretty much also recommended cscope as a wonderful C tool for emacs code
navigation - the linux kernel also comes with a cscope target in its
Makefile which is handy.

Re: code completion

[Bastien Guerry]

Richard G Riley <rileyrgdev@gmail.com> writes:

> Last night a I spent a few hours downloading and installing and
> configuring the latest cedet. After setting up project paths, c-paths
> and turning on the semantic idle completion scheduler it works
> reasonably well for C. Only things that did not complete were fields
> protected by guard flags (to be expected), structs represented by
> typedefs and structs defined in the c file as opposed to an h file - I'm
> not sure if by design or not - but this is quite a subset.

I guess the OP will find this useful.

-- 
Bastien

Re: code completion

[Richard G Riley]

Bastien Guerry <bzg@altern.org> writes:

> Richard G Riley <rileyrgdev@gmail.com> writes:
>
>> Last night a I spent a few hours downloading and installing and
>> configuring the latest cedet. After setting up project paths, c-paths
>> and turning on the semantic idle completion scheduler it works
>> reasonably well for C. Only things that did not complete were fields
>> protected by guard flags (to be expected), structs represented by
>> typedefs and structs defined in the c file as opposed to an h file - I'm
>> not sure if by design or not - but this is quite a subset.
>
> I guess the OP will find this useful.

It is nice to have your approval Bastien.

Re: code completion

[Bastien Guerry]

Richard G Riley <rileyrgdev@googlemail.com> writes:

> Bastien Guerry <bzg@altern.org> writes:
>
>> Richard G Riley <rileyrgdev@gmail.com> writes:
>>
>>> Last night a I spent a few hours downloading and installing and
>>> configuring the latest cedet. After setting up project paths, c-paths
>>> and turning on the semantic idle completion scheduler it works
>>> reasonably well for C. Only things that did not complete were fields
>>> protected by guard flags (to be expected), structs represented by
>>> typedefs and structs defined in the c file as opposed to an h file - I'm
>>> not sure if by design or not - but this is quite a subset.
>>
>> I guess the OP will find this useful.
>
> It is nice to have your approval Bastien.

Hey! I was not blessing you, just thought the OP might get lost and
wanted to his attention back...  anyway, hope my last email clarify 
that I didn't intend to answer agressively by feeling "attacked".  
I didn't feel like that and hope my answers are ok!

-- 
Bastien

Code completion

[Jorge Peixoto de Morais Neto]

[-- Attachment #1.1: Type: text/plain, Size: 423 bytes --]

How can I get code completion in Emacs? I got used to it by programming in
Python's IDLE (althoug I'm more insterested in C now).

Also, under Eclipse, I put the mouse over a variable and Eclipse tells me
where did the variable came from. I like it. How can I do something like it
in Emacs?

I can't find it in Google or the documentation.

Thanks.

-- 
Software is like sex: it is better when it is free. - Linus Torvalds

[-- Attachment #1.2: Type: text/html, Size: 468 bytes --]

[-- Attachment #2: Type: text/plain, Size: 152 bytes --]

_______________________________________________
help-gnu-emacs mailing list
help-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnu-emacs

Re: Code completion

[Noah Slater]

Try putting the following in your ~/.emacs file (customise project
specific details):

;;; Tags

;; When revisiting the tag file, do not prompt to reload.
(setq tags-revert-without-query t)

(defun rebuild-tags (project-name directory-name tags-file)
  "Rebuild tags-file for directory-name."
  (eshell-command (format "find %s -type f -name '*.py' | etags -o %s -"
              directory-name tags-file))
  (message "Rebuilt %s tags file." project-name))

(defun remember-find-tag (tagname)
  "Call `find-tag' and remember `last-tag'."
  (interactive
   (if (bound-and-true-p last-tag)
       (list nil)
       (list (find-tag-tag "Find tag: "))))
  (find-tag tagname t))

(defun indent-or-complete ()
  "Complete if point is at the end of a word, otherwise indent line."
  (interactive)
  (if (looking-at "\\>")
      (dabbrev-expand nil)
    (indent-for-tab-command)))

;; Key more commonly bound to `indent-for-tab-command' command.
(global-set-key (kbd "TAB") 'indent-or-complete)

;; Key more commonly bound to `forward-char' command.
(global-set-key (kbd "C-f") 'remember-find-tag)
;; Key more commonly bound to `backward-char' command.
(global-set-key (kbd "C-b") 'pop-tag-mark)
; ;; Key more commonly bound to `next-line' command.
(global-set-key (kbd "C-n") 'find-tag-other-window)
;; Key more commonly bound to `previous-line' command.
(global-set-key (kbd "C-p") 'tags-apropos)

(defvar my-project-tags-file
    "/path/to/my/project/etags_file"
    "My project tags file.")

(defun my-project-build-tags ()
  "Build my project tags file."
  (interactive)
  (rebuild-tags "My Project"
                "/path/to/my/project"
                hyperbind-tags-file))

;; Visit tags table and rebuild after every save.
(visit-tags-table my-project-tags-file)
(add-hook 'after-save-hook 'my-project-build-tags)

-- 
"Creativity can be a social contribution, but only in so
far as society is free to use the results." - R. Stallman