[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: What IDE features do we need?
From: |
Alan Mackenzie |
Subject: |
Re: What IDE features do we need? |
Date: |
Tue, 22 Apr 2008 15:44:12 +0000 |
User-agent: |
Mutt/1.5.9i |
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).
- Re: Please stop proposing changes in defaults!, (continued)
- Re: What IDE features do we need? defaults!], Eli Zaretskii, 2008/04/22
- Re: What IDE features do we need? defaults!], joakim, 2008/04/22
- RE: What IDE features do we need? defaults!], klaus.berndl, 2008/04/22
- RE: What IDE features do we need? defaults!], Drew Adams, 2008/04/22
- Re: What IDE features do we need?,
Alan Mackenzie <=
- RE: What IDE features do we need?, Drew Adams, 2008/04/22
- Re: What IDE features do we need?, joakim, 2008/04/22
- Re: What IDE features do we need?, Eric Hanchrow, 2008/04/22
- RE: What IDE features do we need?, Drew Adams, 2008/04/22
- Re: What IDE features do we need?, Juri Linkov, 2008/04/22
- Re: What IDE features do we need?, Richard Stallman, 2008/04/23
- Re: What IDE features do we need?, Tassilo Horn, 2008/04/23
- Re: What IDE features do we need?, Eli Zaretskii, 2008/04/23
- Re: What IDE features do we need?, Stefan Monnier, 2008/04/24
- Re: What IDE features do we need?, Eli Zaretskii, 2008/04/24