Re: New editor/Integrated Development Environment/compiler

HiramEgl <hiramegl@hotmail.com> writes:
> My name is Hiram and I would like to know if somebody is interested in
> joining the development of a new kind of editor/Integrated Development
> Environment/compiler.
>
> I'm not happy with the current free (or open-source) alternatives that
> I've found. I think that all those tools (Eclipse, NetBeans, QtCreator,
> Emacs, Vim, ...) have in the bottom the same problem: they work with
> directories, files and text.
>
> Personally, I like Vim and I love that it has different modes (command,
> insert, visual, ...). The best is that it is fast to open (compared to
> the other heavy IDE:s) and that there are thousands of plugins to boost
> the development. However, it also works with dirs, files and text.
>
> But ... how else could an IDE/Editor/compiler work then? With STRUCTURE.


Indeed. Have a look at the InterLisp environment.


http;//larry.masinter.net/interlisp-ieee.pdf
http://www.ida.liu.se/ext/caisor/archive/1978/001/caisor-1978-001.pdf




And a simple recreation of a structure editor:
http://www.informatimago.com/develop/lisp/small-cl-pgms/sedit/index.html




Basically, while emacs integrates into a unix environment, and therefore
takes its data from text files, it's really a lisp machine, and would
love to run from an image based environment (like most Smalltalk
environments).


Actually, implementing an emacs mode that would be strictly structure
editor like the above sedit example, would be rather easy. But not
strictly necessary: the ability to fall down to the character level is
nice. In any case, you have to edit a lot of random text, either
documentation strings, or if only identifiers.


When you consider things like paredit-mode we already have structural
editing in emacs.




So what's missing? The filing part. One thing you can do to ensure a
clear break of mindset is to store the code into a data base instead of
text files. For a start, you could store it in a postgres database.
There's a pg.el on the web, which let you communicate directly to
postgres. You may store each definition in a different row.


Then, instead of editing whole files at one, load in each buffer only a
single definition, and implement the navigation commands you need to
easily browse the code and skip from one function to another. (Again,
most of all of this is already implemented in emacs).




--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.

Return to the comp.compilers page.
Search the comp.compilers archives again.