[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: |
Thu, 8 Jan 2015 10:49:46 -0500 |
On Thu, 08 Jan 2015 17:21:02 +0200 Eli Zaretskii <address@hidden> wrote:
> I agree, but I think we should get back on track discussing the
> technical issues and aspects of building infrastructure for a good
> modern IDE using some help from GCC.
>
> Suppose we did have a way getting the necessary information from GCC
> that is not in the form of an AST: what such an information package
> would need to include to allow the functionality users expect from a
> modern IDE?
Here are several sorts of things I really want to be able to do in a
refactoring editor:
a) Take all instances of a call of the form a(c, d, e) and turn them
into a call of the form b(e, d, NULL, c), regardless of what sort of
syntactic mess may be associated with the calls -- whether they're on
multiple lines or not, whether one of the parameters is a complicated
expression that is impossible for regular expressions to parse, etc.
I also want to only do this for the instances of the call "a" which
are at a particular scope level -- inner definitions of "a" which
mask the outer definition should not be touched. All this can possibly
be done without an AST, but it is harder, especially given how
maddening parsing parameters with regexes can be.
b) To do versions of a), in an environment like C++ where functions
are overloaded, so it is necessary to distinguish not only scope but
also the types of all of the passed parameters so I can know what
overload is in question. The passed parameters might be difficult to
type -- they be embedded inside macros, or they might themselves be
overloaded functions, and pure syntactic analysis cannot distinguish
their types, you need more information. Again, perhaps less than an
AST could help here, but it would be a big pain.
c) To handle something like completing foo.<complete> = complex_call.
This requires knowledge of the return type of complex_call, which in
a language like C++ is a difficult thing to know based merely on
syntax.
d) To handle c) but in a situation where "foo" is replaced by a macro
which has to be expanded and the types of whose return needs
sophisticated evaluation even to know which object or struct is being
discussed. Again, this is very hard to do purely syntactically or
only with object table access.
e) To be able to take every instance where a particular
definition (including overload) of foo() is called without checking
it for a NULL return value and to offer the user the chance to
replace it with the text in which foo() is replaced by a conditional
that checks foo for NULL. This is (again) difficult to do in the
general case without ASTs because it is insufficient just to have
symbol tables, you need to actually know what flavor of foo() this
is, and to be able to judge the context in which foo() is called.
(This is not a theoretical example, I have really wanted to be able
to do this. Yes, it would require a line or two of elisp even with
an AST being available and a proper API, but that's the whole point of
having Emacs!)
I can come up with more and richer examples pretty quickly.
Perry
--
Perry E. Metzger address@hidden
- Re: Emacs contributions, C and Lisp, (continued)
- Re: Emacs contributions, C and Lisp, Karl Fogel, 2015/01/09
- Re: Emacs contributions, C and Lisp, Richard Stallman, 2015/01/10
- Re: Emacs contributions, C and Lisp, Dmitry Gutov, 2015/01/10
- Re: Emacs contributions, C and Lisp, Eric Ludlam, 2015/01/10
- Re: Emacs contributions, C and Lisp, Eli Zaretskii, 2015/01/09
- Re: Emacs contributions, C and Lisp, Perry E. Metzger, 2015/01/08
- Re: Emacs contributions, C and Lisp, Stefan Monnier, 2015/01/08
- Re: Emacs contributions, C and Lisp, Perry E. Metzger, 2015/01/08
- Re: Emacs contributions, C and Lisp, David Kastrup, 2015/01/08
- Re: Emacs contributions, C and Lisp, Eli Zaretskii, 2015/01/08
- Re: Emacs contributions, C and Lisp,
Perry E. Metzger <=
- Re: Emacs contributions, C and Lisp, Eli Zaretskii, 2015/01/08
- Re: Emacs contributions, C and Lisp, Óscar Fuentes, 2015/01/08
- Re: Emacs contributions, C and Lisp, Eli Zaretskii, 2015/01/08
- Re: Emacs contributions, C and Lisp, Richard Stallman, 2015/01/08
- Re: Emacs contributions, C and Lisp, Perry E. Metzger, 2015/01/08
- Re: Emacs contributions, C and Lisp, Eli Zaretskii, 2015/01/09
- Re: Emacs contributions, C and Lisp, David Kastrup, 2015/01/09
- Re: Emacs contributions, C and Lisp, Richard Stallman, 2015/01/08
- Re: Emacs contributions, C and Lisp, Stefan Monnier, 2015/01/08
- Re: Emacs contributions, C and Lisp, Richard Stallman, 2015/01/09