emacs-devel
[Top][All Lists]
Advanced

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

Re: What IDE features do we need? [Was: Please stop proposing changes in


From: Dan Kruchinin
Subject: Re: What IDE features do we need? [Was: Please stop proposing changes in defaults!]
Date: Tue, 22 Apr 2008 16:28:49 +0400
User-agent: Mozilla-Thunderbird 2.0.0.9 (X11/20080109)

Sorry for my previous letter, some text was broken by my mail client.
Normal text is here:

Hello, Alan.
Sorry I'm breaking into your conversation but there are several things
about IDEs and users that should be mentioned.

Alan Mackenzie wrote:
Hi, Juri and Richard!

On Tue, Apr 22, 2008 at 12:40:31AM +0300, Juri Linkov wrote:
[ Richard Stallman:]
These proposals lead to big discussions and do not really advance
Emacs.  Please stop proposing such changes, and work instead
on implementing new capabilities.
...

Recently, a colleague sitting next to me was using a proprietary editor,
which was basically a code-browser with relatively basic editing stuck
on.  The codebase, of proprietary quality, was many thousands of C
files, scattered over a directory "structure" of many hundreds of
directories.  She had her editor set up so that a second window
instantly displayed the definition of the symbol at point in the main
window.  I don't think Emacs has anything to match this; ECB, possibly?
I tried experimenting with ECB once, but it was just to difficult to get
it installed and working.  (OK, maybe I wasn't in a persevering mood at
the time).

ECB is a very good powerful project. It provides quite convenient
classes and functions browsing. I've been using it for a log time
and only one uncomfortable thing that I met ECB looks very unrelative
to emacs. I mean it looks like additional "global" frame and it is not very convenient to use it. For example it would be very nice to see
more information about given function or class when I put mouse cursor
on its name in ECB, but what should ECB developers to use to display
this information?
Tooltips? Temporary buffer? Both these things are very ugly for such
purpose.

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.  Very often, I'd have to
do C-u M-. many times to actually locate the definition.  Etags needs
improving.  For example, by sorting the TAGS file by symbol name.  And
having a command which would display all matching tags in a
*Completions* buffer.

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.

By the way, etags doesn't make *intellectual* autocompletion.
Just take a look at autocompletion in eclips, it quite smart.
For emacs there exists cedet which makes semantical analysis
of given language, provides good API for accessing to tag-tables
and provides other dandy features as marking semantically invalid
code blocks and so on. But there is a little problem. What will use
cedet developers to output (for example) possible variants of completions?
Temporary buffer as was mentioned earlier is not very comfortable things,
but it is used for this moment. Tooltips are used as well. But it is
real pain
for programmer to use them for described purpose. They was designed for
other aims, they haven't good API module's programmers.

So the main thing I want to say: Is it really needful to reinvent the wheel?
There are many good emacs modules that work well, but all these modules
have one common problem: emacs doesn't provides them any basic atoms
from which module's
developers may build friendly and convenient user interface or just make
good data representation. Emacs doesn't have any structured graphical
primitives
which it would may provide.

So why just don't to make these primitives? If they will be I'm sure ECB
and cedet
will first use them to make users life easier.

W.B.R.
Dan Kruchinin.





reply via email to

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