[Top][All Lists]

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

Re: Emacs contributions, C and Lisp

From: Perry E. Metzger
Subject: Re: Emacs contributions, C and Lisp
Date: Fri, 9 Jan 2015 13:13:35 -0500

On Fri, 09 Jan 2015 12:39:19 -0500 Richard Stallman <address@hidden>
>   > There are refactorings that are impossible
> We were talking about completion -- you are changing the subject,
> taking my statements out of context to make a false attack.

We are not just talking about completion. We are talking about
allowing Emacs to compete effectively with XCode, IntelliJ, and other
modern integrated development environments. Such systems permit not
only naive code completion (itself very difficult in a language like
C++ without having an AST present) but complicated refactorings, and
they are permitting more and more complicated refactorings with
every passing year.

Note that I'm also not persuaded that the AST is not needed for
code completion in context when the underlying language has operator
overloading and function overloading. I could perhaps be persuaded
that there might be very specialized APIs possible to get around
that, but then the sorts of refactorings you would want to perform
become impossible anyway.

> This is an example of your general approach.  You (this means
> several people) are not trying to help me make the right decision.
> Rather you are trying to pressure me to do what you want, at the
> expense of something I consider important.

I am attempting to persuade. I believe everyone here is convinced
and understands that you find it important to protect the AST, and
we understand why. However, having free development tools that can
compete with proprietary ones is also something many of us also
consider very important.

There is no shame in our explaining quite forcefully that this is
very important and that there are few real alternatives to a real AST.
> I will try to find out more about these refactoring practices --
> privately, with people I have confidence in, that have no axe to
> grind.

I would suggest that you instead attempt to actually use some of the
modern tools out there so that you can intuitively understand, for
yourself, the sorts of things Emacs is currently missing, without
any sort of intermediary at all. You may find it enlightening.

That said, to restrict yourself to *current* refactoring practices
would also be to miss part of the point -- tools of this sort are
constantly improving, and even if a limited API might handle this
week's needs, it may not handle next week's or next year's.

By forbidding the editor from having advanced knowledge of the parse
tree, you are intentionally crippling the ability of smart people to
build better and better free software tools. You are preventing smart
hackers from going in and making the system as good as they can make
it, from expressing their creativity in such a way as to build the
best development environment they know how.

Dare I say there is a freedom issue here? Many people -- you have
heard from the in this thread -- would very much like to have
information that the compiler has available inside their editor. You,
as the software vendor, for purposes that I will admit are well
intentioned, wish to prohibit that. Naturally, people find this
frustrating, for the same reason you might yourself find it

You have asked us to see this from your point of view, and many of us
have tried hard to do that. I beseech you to look at it from the
point of view of other people as well.

Perry E. Metzger                address@hidden

reply via email to

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