What IDE features do we need? [Was: Please stop proposing changes in defaults!]

[Alan Mackenzie]

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.

[ .... ]

> This is important to make Emacs attractive to more programmers.
> I was shocked today when I observed as an unskilled novice programmer
> wrote a small library at high speed using an IDE.  I'm usually very fast
> at using a large set of Emacs commands, but could hardly achieve this
> performance because Emacs lacks many useful IDE features that make
> programmers more productive.

My opinion is that things like how to mark regions are not _that_
important in attracting new users.  At least, not the sort of users that
would be staying with Emacs anyway.  I don't think it's that big a deal
for newbies whether they use <shift>+arrows or C-<space> to create a
region.  As long as it works well, of course.

What is important is _features_.  About 3 years ago, I was using
hi-lock-mode to highlight some anomalies in a log file (found by a
regexp).  My boss (an ex-programmer) saw it, asked me what I was doing,
and within an hour had Emacs on his PC and was using hi-lock-mode to
look at other log files.

However, the lack of certain features is critical.  Juri, what were the
features of that IDE that made the "unskilled novice" so productive?

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).

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.

> Juri Linkov

-- 
Alan Mackenzie (Nuremberg, Germany).