Re: which IDE ?

[Rob Kendrick <rjek@...>]

On Sun, 17 Jan 2010 20:11:33 +0100
Florian Weimer <fw@deneb.enyo.de> wrote:

> * Rob Kendrick:
> 
> > These languages have much more structure to them.  It's easier for
> > them to work out what would be appropriate to offer the user when
> > they start typing.  For example, there's no way before compile time
> > that an editor could offer anything at all for code completion here:
> >
> > 	foo:<tab>
> 
> That's true for C and C++ as well.  To some extent, all those code
> completions are based on heuristics.  I'm not even sure if exact code
> completion based on all statically available information would be
> useful for C++.

It's tricky to think of a way of hiding an identifier's true type and
purpose in such a way that what can be done with it (ie, methods, or
what it is valid to pass it to) cannot be inferred before compile time
with either language (after all, the compilers produce errors for
misuses here).  At least not in any common idiomatic syntax or use.
Which is my point here; many idiomatic approaches in Lua can't be
understood like this.

> 
> > And even for global function calls, there's no way for the editor to
> > know what would be available, or even would constitutes a good
> > guess.
> 
> If the reader can guess easily what's going on, so can the editor.
> The editor's guesses need not be perfect, they just should be relevant
> often enough to be helpful.

But how does one do this even remotely effectively when it's impossible
to know what the contents of the globals table will be at runtime?
Even if you assume that the function you're editing isn't being
setfenv-ed.

> One way to get better data is to have a live VM running the
> application around, and use data from that to support code navigation
> and completions.  Now I don't like large, long-living VMs (which may
> even run multiple applications) that much, but using this approach,
> you can create very rich development environments.  Using Emacs for
> Emacs Lisp development is fun, and even if you don't like the language
> itself, it shows what is possible even with dynamic languages.

This is one solution, yes, but the applications it can be applied to
are especially niche.

B.