help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: code completion


From: Richard G Riley
Subject: Re: code completion
Date: Wed, 12 Mar 2008 13:29:52 +0100
User-agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux)

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]