Please stop proposing changes in defaults!

Please stop proposing changes in defaults!

[Richard Stallman]

In the past week we have seen two more proposals to change Emacs
defaults: one about C-h in isearch, and one about Delete Selection
mode.

These proposals lead to big discussions and do not really advance
Emacs.  Please stop proposing such changes, and work instead
on implementing new capabilities.

Re: Please stop proposing changes in defaults!

[Paul R]

Richard Stallman <rms@gnu.org> writes:

> In the past week we have seen two more proposals to change Emacs
> defaults: one about C-h in isearch, and one about Delete Selection
> mode.

The thread about C-h in isearch was very productive, and it would be a
waste of effort to ignore what can be derived from it.

> These proposals lead to big discussions and do not really advance
> Emacs.  

You can maybe help this work to be more productive. Default settings
is a topic raised more and more often because people feel some useful
work can be done in this area. Maybe we can attribute this evolution
to the fact that people, in the past, used to discover emacs without
being really accustomed to any consistent behaviour accross other
programs. Now, people come to emacs with some backgrounds in
computing, and expect more from defaults.

> Please stop proposing such changes, and work instead on implementing
> new capabilities.

People work well when they work happily. People work happily on what
they feel important. What would you think about a dedicated project to
improve emacs defaults ? Do you think it would be more productive ?
Would you like it to be more productive ?

-- 
      Paul

Re: Please stop proposing changes in defaults!

[Juri Linkov]

> In the past week we have seen two more proposals to change Emacs
> defaults: one about C-h in isearch, and one about Delete Selection
> mode.
>
> These proposals lead to big discussions and do not really advance
> Emacs.  Please stop proposing such changes, and work instead
> on implementing new capabilities.

I think these discussions are very important to advance Emacs because
when people are not happy with some Emacs behavior, such open discussions
often help to achieve a consensus that satisfies everyone.

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.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Please stop proposing changes in defaults!

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Date: Tue, 22 Apr 2008 00:40:31 +0300
> Cc: emacs-devel@gnu.org
> 
> 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.

Surely, those missing features will not magically come into existence
by changing defaults of existing features.

Re: Please stop proposing changes in defaults!

[Richard Stallman]

    > Please stop proposing such changes, and work instead on implementing
    > new capabilities.

    People work well when they work happily. People work happily on what
    they feel important.

I hope these people recognize that what is important
is to add real capabilities to Emacs, not propose incompatiblen changes.

			 What would you think about a dedicated project to
    improve emacs defaults ? Do you think it would be more productive ?
    Would you like it to be more productive ?

I think that such a project, to be constructive, would require people
with exceedingly good judgment.  Otherwise it would be
counterproductive.

I would rather just rule out further incompatible changes in the basic
Emacs editing commands until after Emacs 23 comes out.

Re: Please stop proposing changes in defaults!

[Richard Stallman]

    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.

Adding the attractive features of IDE is exactly the sort of work I
think we should aim to do.  That is why I ask people to stop proposing
incompatible changes in basic editing commands.  What makes IDEs
convenient is not the details of their editing commands, it is the
other capabilities they have.

Re: Please stop proposing changes in defaults!

[Juri Linkov]

> Adding the attractive features of IDE is exactly the sort of work I
> think we should aim to do.  That is why I ask people to stop proposing
> incompatible changes in basic editing commands.  What makes IDEs
> convenient is not the details of their editing commands, it is the
> other capabilities they have.

If changing some defaults makes Emacs more attractive to IDE users
especially when such change doesn't hurt existing Emacs user, like
your suggestion to enable delete-selection-mode only after
shift-selection and mouse-selection, this would be a good thing.

-- 
Juri Linkov
http://www.jurta.org/emacs/

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

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

[Dan Kruchinin]

Hello, Alan.
Sorry I'm 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 with its like with simple frame. Also as a user I want 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 havn't good API module's programmes.

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.

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

[Dan Kruchinin]

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.

Re: What IDE features do we need? defaults!]

[Eli Zaretskii]

> Date: Tue, 22 Apr 2008 11:52:16 +0000
> From: Alan Mackenzie <acm@muc.de>
> Cc: emacs-devel@gnu.org
> 
> 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.

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.

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

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.

> 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?

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

Re: What IDE features do we need? defaults!]

[joakim]

Eli Zaretskii <eliz@gnu.org> writes:

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

I think  Cedet is the way to go, since it supports a common Emacs
interface to several different tag generating backends, some of which
are written entirely in elisp.

>
-- 
Joakim Verona

RE: What IDE features do we need? defaults!]

[Drew Adams]

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

FWIW, with Icicles this is not a problem. `M-.' gives you all matching tags as
completion candidates. It is a multi-command, so you can visit any of them, in
any order, any number of times. IOW, it rolls `M-.', `C-u M-.', and `M-,' into
one, as a tags browser.

RE: What IDE features do we need?

[Drew Adams]

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

I mentioned it as FYI, since this topic includes possible UI improvements for
accessing multiple tag hits etc. What Icicles does is one possible approach.

Here is a description:
http://www.emacswiki.org/cgi-bin/wiki/Icicles_-_Tags_Enhancements

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

Re: What IDE features do we need?

[Eric Hanchrow]

>>>>> "Alan" == Alan Mackenzie <acm@muc.de> writes:

    Alan> Etags needs improving.  ...  And having a command which would
    Alan> display all matching tags in a *Completions* buffer.

There's already something like this: tags-apropos.  I only found out
about it recently.  It's nice!

-- 
We can say that the universe consists of a substance, and this
substance we will call "atoms," or else we will call it
"monads."  Democritus called it atoms.  Leibniz called it
monads.  Fortunately, the two men never met, or there would have
been a very dull argument.
        -- Woody Allen

RE: What IDE features do we need?

[Drew Adams]

>     Alan> Etags needs improving.  ...  And having a command 
>           which would display all matching tags in a
>           *Completions* buffer.
> 
> There's already something like this: tags-apropos.  I only found out
> about it recently.  It's nice!

The Icicles tags browsing I mentioned (`M-.' in Icicle mode) gives you
`tags-apropos', `list-tags', and `find-tag' rolled into one, with a more dynamic
interface.

You give it an initial regexp (with RET) to get a domain of tag hits, which
includes duplicate tags from the same or different source files. (You can limit
these to the current tags file or use all tags files.)

You can, if you want, filter that domain dynamically by typing input (regexp or
prefix) in the minibuffer. You can filter on the tags or on the file names or on
both. You can visit any number of the matching candidates in any order, any
number of times. You can use additional input patterns (e.g regexps) in
recursive minibuffers to narrow the candidates progressively. You can complement
the current set of candidates (e.g. match all current candidates except those
that match an additional pattern).

Changing your input pattern at any time changes the set of matching tags, within
the domain determined by the initial regexp you entered.

RE: What IDE features do we need? defaults!]

[klaus.berndl]

joakim@verona.se wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
> 
>> 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. 
>> 
>>> 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?
>> 
>> 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).
> 
> I think  Cedet is the way to go, since it supports a common Emacs
> interface to several different tag generating backends, some of which
> are written entirely in elisp.

I 100% second this - Eric (maintainer of CEDET) works really hard to
make CEDET useable even with huge code-bases - AFAIK performance of
CEDET has increased a lot....

Re: What IDE features do we need?

[joakim]

Alan Mackenzie <acm@muc.de> writes:


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

ECB is a client of Cedet, so its cedet who delivers tag info.
Ebrowse can be used as a tag backend for Cedet, among other tag
generators, such as the on the fly elisp one in cedet.

> -- 
> Alan Mackenzie (Nuremberg, Germany).
>
-- 
Joakim Verona

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

[Richard Stallman]

    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.

It could be a good thing to do.  Can someone design what it would look
like?

Re: What IDE features do we need?

[Juri Linkov]

> 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?

Y'know, all these "intellisense", code browsing and refactoring things.

-- 
Juri Linkov
http://www.jurta.org/emacs/

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

[Paul R]

Richard Stallman <rms@gnu.org> writes:

>     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.
>
> It could be a good thing to do.  Can someone design what it would look
> like?

I am not sure what Dan is refering to, to this might be OT. FWIW,
Vim 7 introduced a "smart completion" system called omni-completion. I
have never tried it, but I read on it and I just looked some
screenshot on the web (search for "vim omnicompletion" in the image
section of your search engine).
It seems to work both in text-based and graphic modes, by using text
overlay to prompt user with a list.

-- 
      Paul

Re: What IDE features do we need?

[Richard Stallman]

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

    Y'know,

Alas, I don't know.

	    all these "intellisense", code browsing and refactoring things.

Could you tell us in a way that would be clear
to those of us who don't already know what this refers to?

Re: What IDE features do we need?

[Tassilo Horn]

Richard Stallman <rms@gnu.org> writes:

> 	    all these "intellisense", code browsing and refactoring
> 	    things.
>
> Could you tell us in a way that would be clear to those of us who
> don't already know what this refers to?

Well, *intellisense* is an intelligent completion.  For example, let's
say in Java I have an instance of a class foo, then typing

   myFooInstance.<completion-key>

will complete all field and method names, that are applicable in that
context, e.g. they're defined in the class Foo or one of its super
classes and they have the correct visibility.  The same can be done when
completing function parameters.  For example, if there's a method
doMagic(Bar bar) in class Foo, then

   myFooInstance.doMagic(<completion-key>

will only propose local and global variables of class Bar or
function/method calls that return a reference to a Bar instance.

With *browsing* one means the ability to quickly grasp all informations
of the classes and functions.  For example, if point is on an instance
of Foo, a simple command should take me to its definition.  Some more
advanced queries could be

  - Find all places in subclasses of Foo, where the method
    Foo.doMagic(Bar bar) is overwritten.

  - Find all function calls of Foo.doMagic()

*Refactoring* basically means restructuring the code, so that it's more
clean and maintainable.  Some common refactorings are:

  - Extract method: Mark a region in a long method, say "Extract
    method", the IDE asks for a name and then creates a new method which
    contains the code of the region.  The parameters and the new
    function call replacing the extracted code are figured out
    automagically.

  - Simple renaming: You say rename at any part of the code, may it be a
    variable, a class or a function.  That will rename every occurence
    in a semantic correct manner.  If you rename doMagic(), every call
    in the whole project will be renamed, default or overwriting
    definitions in super/sub classes will be renamed, the JavaDoc source
    documentation will be adapted and so on.  In Java, if you rename a
    class, the file has to be renamed as well.

  - Change the signature of a method, ...

All these features (and much more) work out of the box with the Eclipse
IDE for Java.

Bye,
Tassilo

Re: What IDE features do we need?

[Eli Zaretskii]

> From: Tassilo Horn <tassilo@member.fsf.org>
> Date: Wed, 23 Apr 2008 22:29:04 +0200
> 
> Well, *intellisense* is an intelligent completion.  For example, let's
> say in Java I have an instance of a class foo, then typing
> 
>    myFooInstance.<completion-key>
> 
> will complete all field and method names, that are applicable in that
> context, e.g. they're defined in the class Foo or one of its super
> classes and they have the correct visibility.  The same can be done when
> completing function parameters.  For example, if there's a method
> doMagic(Bar bar) in class Foo, then
> 
>    myFooInstance.doMagic(<completion-key>
> 
> will only propose local and global variables of class Bar or
> function/method calls that return a reference to a Bar instance.
> 
> With *browsing* one means the ability to quickly grasp all informations
> of the classes and functions.  For example, if point is on an instance
> of Foo, a simple command should take me to its definition.  Some more
> advanced queries could be
> 
>   - Find all places in subclasses of Foo, where the method
>     Foo.doMagic(Bar bar) is overwritten.
> 
>   - Find all function calls of Foo.doMagic()
> 
> *Refactoring* basically means restructuring the code, so that it's more
> clean and maintainable.  Some common refactorings are:
> 
>   - Extract method: Mark a region in a long method, say "Extract
>     method", the IDE asks for a name and then creates a new method which
>     contains the code of the region.  The parameters and the new
>     function call replacing the extracted code are figured out
>     automagically.
> 
>   - Simple renaming: You say rename at any part of the code, may it be a
>     variable, a class or a function.  That will rename every occurence
>     in a semantic correct manner.  If you rename doMagic(), every call
>     in the whole project will be renamed, default or overwriting
>     definitions in super/sub classes will be renamed, the JavaDoc source
>     documentation will be adapted and so on.  In Java, if you rename a
>     class, the file has to be renamed as well.
> 
>   - Change the signature of a method, ...
> 
> All these features (and much more) work out of the box with the Eclipse
> IDE for Java.

Emacs already has infrastructure for most of those features (in etags
and in Ebrowse), sometimes even more than one package that offers a
different implementation of the same functionality, but we need better
UI for them and better graphical methods of presenting the output.

Re: What IDE features do we need?

[Richard Stallman]

These sound like good features.  I suppose they depend on parsing the
code more than Emacs does, so far.  Is Cedet sufficient as a platform
to straightforwardly implement these features?  If not, what else is
needed?

Re: What IDE features do we need?

[joakim]

Richard Stallman <rms@gnu.org> writes:

> These sound like good features.  I suppose they depend on parsing the
> code more than Emacs does, so far.  Is Cedet sufficient as a platform
> to straightforwardly implement these features?  If not, what else is
> needed?
>

This is what Cedet, or rather it's component Semantic, is all about.
Cedet implements intellisense for emacs already.

-- 
Joakim Verona

Re: What IDE features do we need?

[Tassilo Horn]

Richard Stallman <rms@gnu.org> writes:

> These sound like good features.  I suppose they depend on parsing the
> code more than Emacs does, so far.

Indeed, but CEDET does.

> Is Cedet sufficient as a platform to straightforwardly implement these
> features?

The part of CEDET that provides the core to such functionality is called
semantic.  Here's the Info description:

,----[ (info "(semantic)Overview") ]
| semantic uses "parsers" to analyze programming language sources.  For
| languages that can be described using a context-free grammar, parsers
| can be based on the grammar of the language.  Or they can be "external
| parsers" implemented using any means.  This allows the use of a
| regular expression parser for non-regular languages, or external
| programs for speed.
| 
| semantic provides extensive tools to help support a new language.  An
| original LL parser, and a Bison-like LALR parser are included.  So,
| for a regular language, all that the developer needs to do is write a
| grammar file along with appropriate semantic rules.
| 
| semantic allows an uniform representation of language components, and
| provides a common API so that programmers can develop applications
| that work for all languages.  The distribution includes good set of
| tools and examples for the application writers, that demonstrate the
| usefulness of semantic.
`----

So I'd say the core functionality is there.

> If not, what else is needed?

Lots of UI features, but the most important things have been addressed
recently, like persectives, dedicated windows, tabs on windows.

Bye,
Tassilo

RE: What IDE features do we need?

[klaus.berndl]

Tassilo Horn wrote:
> Richard Stallman <rms@gnu.org> writes:
> 
>> These sound like good features.  I suppose they depend on parsing the
>> code more than Emacs does, so far.
> 
> Indeed, but CEDET does.
> 
>> Is Cedet sufficient as a platform to straightforwardly implement
>> these features?
> 
> The part of CEDET that provides the core to such functionality is
> called semantic.  Here's the Info description:
> 
> ,----[ (info "(semantic)Overview") ]
>> semantic uses "parsers" to analyze programming language sources.  For
>> languages that can be described using a context-free grammar, parsers
>> can be based on the grammar of the language.  Or they can be
>> "external parsers" implemented using any means.  This allows the use
>> of a regular expression parser for non-regular languages, or
>> external programs for speed. 
>> 
>> semantic provides extensive tools to help support a new language.  An
>> original LL parser, and a Bison-like LALR parser are included.  So,
>> for a regular language, all that the developer needs to do is write a
>> grammar file along with appropriate semantic rules.
>> 
>> semantic allows an uniform representation of language components, and
>> provides a common API so that programmers can develop applications
>> that work for all languages.  The distribution includes good set of
>> tools and examples for the application writers, that demonstrate the
>> usefulness of semantic.
> `----
> 
> So I'd say the core functionality is there.
> 
>> If not, what else is needed?
> 
> Lots of UI features, but the most important things have been addressed
> recently, like persectives, dedicated windows, tabs on windows.

but as already discussed - dedicated windows is not sufficient for 
real IDE-feelings...

Klaus

> 
> Bye,
> Tassilo

Re: What IDE features do we need?

[David Kastrup]

<klaus.berndl@sdm.de> writes:

> Tassilo Horn wrote:
>> So I'd say the core functionality is there.
>> Richard Stallman <rms@gnu.org> writes:
>> 
>>> If not, what else is needed?
>> 
>> Lots of UI features, but the most important things have been addressed
>> recently, like persectives, dedicated windows, tabs on windows.
>
> but as already discussed - dedicated windows is not sufficient for 
> real IDE-feelings...

One thing that I think quite relevant is error navigation visualization:
we have previous/next error already.  However, when viewing the
compilation buffer/log, there are some more features that make error
handling much more handy and also "intuitive".

a) in-scroll-bar marking of errors: the scroll bar contains error
markers where errors have been encountered.  In that way, even when the
full log is shown, you can easily navigate to each error and see what it
is about.

b) error folding: the log file only shows errors/warnings by default,
possibly only the first line of each.

c) marking errors and/or warnings with symbols in the margin.  Can be
combined with b.

-- 
David Kastrup

Re: What IDE features do we need?

[Stefan Monnier]

> Emacs already has infrastructure for most of those features (in etags
> and in Ebrowse), sometimes even more than one package that offers a
> different implementation of the same functionality, but we need better
> UI for them and better graphical methods of presenting the output.

Refactoring requires a lot more infrastructure than what etags and
ebrowse provide.  That's what `semantic' does.


        Stefan

Re: What IDE features do we need?

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Thu, 24 Apr 2008 08:26:52 -0400
> Cc: Tassilo Horn <tassilo@member.fsf.org>, emacs-devel@gnu.org
> 
> > Emacs already has infrastructure for most of those features (in etags
> > and in Ebrowse), sometimes even more than one package that offers a
> > different implementation of the same functionality, but we need better
> > UI for them and better graphical methods of presenting the output.
> 
> Refactoring requires a lot more infrastructure than what etags and
> ebrowse provide.

I'm not convinced, but I won't argue.

Re: What IDE features do we need?

[Thomas Lord]

[-- Attachment #1: Type: text/plain, Size: 1134 bytes --]

Eli Zaretskii wrote:
>>
>> Refactoring requires a lot more infrastructure than what etags and
>> ebrowse provide.
>>     
>
> I'm not convinced, but I won't argue.
>   


The tools that people are excited about differ from etags and ebrowse by 
virtue of their incremental nature (updating the databases as the code 
is modified) and precision.    The precision aspect is mainly a Java 
thing since the simple (enough) scoping rules and absence of syntactic 
abstraction make incremental parsing tractable.  

If you were to argue and you argued that the actual software engineering 
practice of refactoring and other correctness-preserving global 
transforms doesn't need such heavy guns, and is very well-served by more 
simply text based tools like Emacs has, etc:  well, you'd get no 
argument back from me.

But, afaict from watching people in various communities talk about it, 
Eclipse's Java features have basically /taught/ the utility of global 
transforms to many programmers.   So many people tend to be excited 
about the Eclipse approach and to assume that that's how things are 
supposed to work.



-t






>
>
>   


[-- Attachment #2: Type: text/html, Size: 1715 bytes --]

Re: What IDE features do we need?

[Richard M Stallman]

    This is what Cedet, or rather it's component Semantic, is all about.
    Cedet implements intellisense for emacs already.

Intellisense is one of about 6 features described.
Is Cedet sufficient as a parser to serve as the base
for the other features?

Re: What IDE features do we need?

[Richard M Stallman]

    | semantic provides extensive tools to help support a new language.  An
    | original LL parser, and a Bison-like LALR parser are included.  So,
    | for a regular language, all that the developer needs to do is write a
    | grammar file along with appropriate semantic rules.

What languages is there parsing support for?
Which languages need to be implemented?

    Lots of UI features, but the most important things have been addressed
    recently, like persectives, dedicated windows, tabs on windows.

We talked about them, but they have not been implemented yet.

Would someone like to offer to implement, at the C level,
the needed display features?

Re: What IDE features do we need?

[Bruce Stephens]

Eli Zaretskii <eliz@gnu.org> writes:

[...]

> Emacs already has infrastructure for most of those features (in
> etags and in Ebrowse), sometimes even more than one package that
> offers a different implementation of the same functionality, but we
> need better UI for them and better graphical methods of presenting
> the output.

Current IDEs do them better in many cases.

Many classes might offer a "show" method, for example.  If I'm looking
at foo.show() then an IDE that can determine what type "foo" is can
show me the right declaration/definition.  Even if it can't determine
the type it can at least limit the choices to member functions.

Such things are tricky (because you want to make reasonable guesses on
syntactically invalid code---perhaps in a file that's never been
syntactically valid), but it seems to be doable enough for the
features to be useful (IMHO).

When one's using C I guess there's less motivation: you'll have
show_cons, show_string, etc., or cons_show, string_show.  Lots of
nicely distinct symbols.  But in OO languages I think there's
significant benefit in trying to get more context-dependent
information, as cedet's semantic does.

Re: What IDE features do we need?

[Richard M Stallman]

    But, afaict from watching people in various communities talk about it, 
    Eclipse's Java features have basically /taught/ the utility of global 
    transforms to many programmers.   So many people tend to be excited 
    about the Eclipse approach and to assume that that's how things are 
    supposed to work.

Whether or not editing commands for this are _necessary_,
it is indisputable that they are good features.
So let's put aside the argument about them, and work on
implementing them.

Re: What IDE features do we need?

[Mike Mattie]

[-- Attachment #1: Type: text/plain, Size: 1674 bytes --]

On Thu, 24 Apr 2008 19:26:29 +0300
Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Stefan Monnier <monnier@iro.umontreal.ca>
> > Date: Thu, 24 Apr 2008 08:26:52 -0400
> > Cc: Tassilo Horn <tassilo@member.fsf.org>, emacs-devel@gnu.org
> > 
> > > Emacs already has infrastructure for most of those features (in
> > > etags and in Ebrowse), sometimes even more than one package that
> > > offers a different implementation of the same functionality, but
> > > we need better UI for them and better graphical methods of
> > > presenting the output.
> > 
> > Refactoring requires a lot more infrastructure than what etags and
> > ebrowse provide.
> 
> I'm not convinced, but I won't argue.
> 
> 

re-factoring requires structure e.g: graphs. a flat table is not even enough
to compute what's in scope at a given point. Without scoping information a symbol
cannot be accurately renamed with accuracy. 

A trivial example is static symbols in C code. They are invisible at the link layer 
but produce collisions in a etags file. The namespace directive in C++ can declare the 
same symbol with different name-spaces, and within the same file. Combined with
"use" the correct definition/declaration points cannot be determined from a point
without basic scoping. 

CEDET architecturally is spot on. The details are certainly worth examining
but there is a high degree of design convergence when working on this domain.
CEDET is definitely an example of the essential elements required for
static analysis.

I have developed a Emacs parser myself but I would recommend
CEDET as a design complete system without hesitation.

Cheers,
Mike Mattie

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: What IDE features do we need?

[Eli Zaretskii]

> Date: Mon, 28 Apr 2008 10:57:42 -0700
> From: Mike Mattie <codermattie@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>
> 
> re-factoring requires structure e.g: graphs. a flat table is not even enough
> to compute what's in scope at a given point. Without scoping information a symbol
> cannot be accurately renamed with accuracy.

Sure, but Ebrowse knows about scope as well (otherwise, it couldn't
have given you features that refer to methods and members by class, or
show the entire class hierarchy as a tree or graph).

Re: What IDE features do we need?

[Mike Mattie]

[-- Attachment #1: Type: text/plain, Size: 4033 bytes --]

On Thu, 24 Apr 2008 10:21:35 -0700
Thomas Lord <lord@emf.net> wrote:

> Eli Zaretskii wrote:
> >>
> >> Refactoring requires a lot more infrastructure than what etags and
> >> ebrowse provide.
> >>     
> >
> > I'm not convinced, but I won't argue.
> >   
> 
> 
> The tools that people are excited about differ from etags and ebrowse
> by virtue of their incremental nature (updating the databases as the
> code is modified) and precision.    The precision aspect is mainly a
> Java thing since the simple (enough) scoping rules and absence of
> syntactic abstraction make incremental parsing tractable.  
> 
> If you were to argue and you argued that the actual software
> engineering practice of refactoring and other correctness-preserving
> global transforms doesn't need such heavy guns, and is very
> well-served by more simply text based tools like Emacs has, etc:
> well, you'd get no argument back from me.

These are not just issues of simple productivity, likening them to
a useful crutch.

These tools are priceless for the fella that is new to a code-base
and needs to learn how the system works. If you wrote a book on
a scale that could not be bound (like the source for a large system)
a standard back-matter preparation would not scale (e.g the index).

semantic like static analysis tools allow the code to be navigated
structurally. If the architecture is clean both humans and
programs can navigate this structure which is quite exciting with
sufficient imagination.

But the vital need for static analysis is clear with the sophisticated 
linkage of large systems, and the fact that vast amounts of C/C++/java
have entered maintenance mode.

To picture a use case imagine the hero consultant squaring off against
a legacy system of COBOL,pascal,C,C++ (standard industry progression layered),
with a deadline to make a correction in the system.

Examples: Y2k, euro conversion.

etags does not cut the mustard in that scenario. Semantic has the potential
to equal the task.
   
> But, afaict from watching people in various communities talk about
> it, Eclipse's Java features have basically /taught/ the utility of
> global transforms to many programmers.   So many people tend to be
> excited about the Eclipse approach and to assume that that's how
> things are supposed to work.

Characterizing re-engineering as a java feature is tempting due to
the iosomorphism of the byte-code/source-code. However static analysis
is a natural response to the rise of sophisticated scoping and linking
that happened a *while ago*. You can argue that such mechanisms are
a response to "human wave" tactics, but the relics of such efforts
are now vital infrastructure.

The right thing for static analysis as the author of CEDET no doubt
discovered is a surprisingly large system, to large to be called a
feature. The right thing gives birth to a number of vital features
however.

The infrastructure required to complete a symbol correctly is the
same infrastructure required to change the storage of a field
and accurately analyze the propagation of that change throughout the
code-base with a measurable margin of error.

The prior art goes all the way back to SCID (source code in database) AFAIK,
and the design convergence is remarkable. I have a architectural design
for an almost identical system independently developed. A second team,
again independent, attacked the problem again and drew the same diagram 6 months 
later. I can bet with high confidence that the proprietary coverity system has
a similar design as well.

So to wrap up everyone ends up drawing the same architecture. CEDET is
a implementation of that high-level architecture. If you can draw a
different architecture and make it work then you should publish
and claim your fame. Otherwise CEDET is a good idea that everyone has
had and few have had the stamina to implement.

Cheers,
Mike Mattie

> 
> 
> -t
> 
> 
> 
> 
> 
> 
> >
> >
> >   
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]