Re: What IDE features do we need?

[Alan Mackenzie]

Hi, Eli!

On Tue, Apr 22, 2008 at 04:28:05PM +0300, Eli Zaretskii wrote:

> > By contrast, using etags, it could easily take me over a minute to
> > locate a definition; firstly, M-. took about 4 seconds (on a 2.8 GHz
> > processor), because the TAGS file was so big.

Sorry, I got confused.  It was running on a Unix (Solaris) server.  But
not heavily loaded.

> This is a one-time penalty, so it can be alleviated by visiting the
> TAGS table automatically at startup, or when the (yet non-existent)
> ``project file'' is read in preparation for working on a project.

No.  It's was taking ~4 seconds average on each M-.  It took a lot longer to
load the tags file (~50 Mb) to start off with.

> > Very often, I'd have to do C-u M-. many times to actually locate the
> > definition.

> This is indeed a much more serious problem.

Drew suggested Icicles for this.  I'm going to try that.

> In addition, etags does not really grok C++ and Java style
> object-oriented languages, so it cannot, for example, let you complete
> on class members, or show signatures of class methods, whether in
> tooltips or elsewhere.

It's a tool for source code up to a certain size.  It's fine for emacs
(probably), but wasn't up to the job for the system I was working on
(even though, in the abstract, it was no more complicated than Emacs).

> > Improving etags this way would be more of a stop-gap than a solution.
> > It just isn't powerful enough for that sort of proprietary
> > environment.

> I don't see why not; could you explain?

Hmm.  I can't do much better than repeat your paragraph above, the one
beginning "In addition, etags does not really grok C++ ...."  :-)

> OTOH, we could also base an Emacs solution on something like ID-Utils,
> but that would require to develop parsers for popular languages such
> as C++, Java, Python, etc.  As yet another alternative, we could use
> Ebrowse, although it, too, needs some work to catch up with current
> C++ standards (from a few blatant bugs I recently uncovered in
> Ebrowse, I conclude that it is almost unused).

Yes.  I fixed a bug in Ebrowse some while ago, which would have been a
show stopper each time.  It looks like a gorgeous program though, in that
it purports to offer full browsing capability with a single C file for
the analysis program, and a single elisp file for the Emacs bit.

But we've got ECB.  Or at least, ECB is available.

-- 
Alan Mackenzie (Nuremberg, Germany).