Re: Emacs contributions, C and Lisp

["Perry E. Metzger" <perry@piermont.com>]

On Sat, 10 Jan 2015 14:29:53 -0500 Richard Stallman <rms@gnu.org>
wrote:
> Here's how all this appears to me.  I am considering choosing a
> course that seems dangerous, and someone asserts that it is
> obligatory, a forced move.  He presents arguments I cannot follow,
> about a feature I have never seen, which he claims is very
> important but I don't know that.  The arguments cite facts about
> whose veracity I have no independent knowledge.

I am happy to provide

1) Detailed explanations of anything you do not understand, regardless
of the number of iterations needed so that you feel you have a
comfortable working knowledge of the topic.
2) Detailed references to commercial products that provide the sorts
of features I'm describing so you may verify for yourself that these
features exist and are useful without needing to trust me on anything
at all.
3) Detailed and patient assistance of any other sort so you may
determine, for yourself, if what I am saying is true.

No one wants you to have to trust other people's opinions blindly.

> Changing the subject -- making arguments about refactoring while I
> am trying to understand about completion -- doesn't impress me
> favorably. It interferes with my effort to understand the issue.

We have, however, a much fuller set of concerns than
completion. Refactoring *is* a real concern.

Here, for example, is a list of the sorts of refactorings that
IntelliJ, a proprietary editor, makes available for Java
programming. You can read them and decide for yourself how many of
these could be done without access to an AST -- I suspect the answer
is "only a few, and with difficulty".

https://www.jetbrains.com/idea/help/refactoring-source-code.html

(If you don't know what any of these things mean, we can help explain.)

Here is a set of refactorings that the commercial DevExpress add-on to
Visual Studio provides:

https://www.devexpress.com/Products/CodeRush/refactor_pro.xml#autolist5

There's quite a lot of them as you can see.

Now, it is my contention that Emacs could provide much more general
sorts of tools, not merely competing with such a proprietary systems
but far surpassing them.

The commercial tools rarely provide the end user with the ability to
reprogram the ways the tools work. They provide only for doing what
the developer imagined the user might want to do. One of the reasons
that the Clang crowd now has libAST is because they found they needed
to write custom code to do many refactorings they wanted to do, and
this provided them with a way to do that.

However, Emacs could get us beyond all of this. Emacs has, after all,
elisp available. In addition to canned refactorings, users could build
their own. They could get access to the AST matching API in elisp
directly, and with some work one could even allow for interactive
development and application of matchers/transformers. The potential
here for really cool developer tools is high.

I recognize that you don't want me to "change the subject" to
refactoring, but I don't see this as a change of subject. The concern
isn't as such code completion, that's just a detail. The underlying
concern is being able to make Emacs the very best programmer's editor
it can possibly be. Modern development environments have astonishing
power, and there is an enormous desire on the part of certain parts of
the Emacs community to have that power or even more available in
Emacs.

If you find that you do not understand any comment being made, I am
happy to expand and restate until you do feel you understand it. I am
sure that others feel the same way. If you wish to be able to verify
anything I claim independently, I can provide references and pointers
to programs so you can check that I am telling you the truth without
having to trust me at all, and I'm sure others will also happily
provide such information.


Perry
-- 
Perry E. Metzger		perry@piermont.com