[REBOL] Re: IDE
From: tim-johnsons::web::com at: 15-Jun-2006 17:08
* Karim El Founas <karim.elfounas-easybraine.com> [060615 12:51]:
> Hello everybody.
> This discussion interests me a lot because I also thought a lot about a
> REBOL IDE. I even worked a bit on an analysis document about that but
> written in French.
> I'll try to explain the big picture here. I apologies for my poor English.
<grin> Your english is quite clear, and *way* better than my french.
I'm going to wear two hats here: The first hat is the pragmatic one,
the second is the idealistic one.
> First, when talking about IDE, I'm not talking about an editor. An IDE
> contains many more functionalities as compiling, projects management,
> GUI interface building...
To clear up a misunderstanding among many: Emacs/Xemacs are not
editors. They are full-fledged development environments for the elisp
programming language. Which was developend by Richard Stallman and is
based on the lisp style of parenthesized syntax.
Everything that you mention here can by done with emacs.
In fact elisp is a fully mature programming language, but it is
rather archaic in terms of scopes and contexts. Developing an editor
is a very large task.
I sure as hell would prefer to be customizing my development
environment in rebol rather than elisp, so I hope someone builds an
editor as flexible and customizable as emacs using rebol.
*But* I want keystrokes! Must have keystrokes. Much more preferable
than menus, but they are good too.
Example: Control-C f ;; select function
Control-C x ;; bring interpreter into focus, execute
;; function in interpreter
Example: Control-C h ;; submit current word to interpreter for
;; 'help documentation
;; ................ and many, many more!
I 'love' the keyboard.
> I think that creating a Rebol IDE is not copying other IDE. Each
> language has his style of coding that implies a type of IDE. The good
> questions are "What do we need when programming REBOL?" and "How to
> obtain that?".
> I think a REBOL IDE written in REBOL is an excellent advertising.
> 1) GENERAL CONCEPT: modular application
> Of course, an IDE is an environement homogeneous that contains
> development tools. Let's call them "modules". The more basic idea is a
> kind of menu or an icon bar (as MS Office97 ugly bar) that launch
> specific modules (editor, execution, encap,...). Each module of the
> editor is independent and optional.
> It allows:
> * The core IDE is simply a glue between modules and the user.
> * Any developer can build his own module and maybe propose it to the
> community. I can even sell it.
> * Easy evolution of the IDE.
> 2) LET'S GO DEEPER: not just a module launcher
> Accessing a functionality with a single click is powerful but is a quite
> limited. Example, the "Debugging" tools could be launch in many ways :
> * Simply execute the current script
> * Execute the script and stop to the first breakpoint
> * Execute next line
> * ...
> Notice that actions are done on specific objects and may needs specific
> parameters: execute this file; search a word in files of this directory...
> * Each module must have a list of possible action.
> * An action may need some parameters (filename of the current
> This has an implication: the module must declare to the core IDE the
> available actions, their parameters and on which king of objects they
> Practically, the IDE must propose only the possible action. If no
> script selected, no needs to edit something.
> 3) What exactly is a module ?
> All these modules can be written in Rebol but it's convenient to access
> other things than rebol scripts. If your favourite editor is Emacs, you
> need a button (or a menu item or...) that launch Emacs with the current
> filename as parameter.
> Otherwise, sometimes it's useful to write directly his own new action.
> By example a button to delete a specific log file. As developer, I want
> to just clic on "Add new action" and write in a small form the action
> name "Erase the log" and the corresponding rebol code ( delete
> I think there are 3 main kind of modules :
> * simple rebol code (typically one liners)
> * module written in Rebol
> * external software
> 4) What kind of objects can be manipulated by the IDE ?
> Usually, the first use of the IDE is manipulating code which is stored
> in files (ie rebol scripts). But it can be other kinds of text files
> (xml, makedoc,...) and even binary files (images, sounds,...)
> All these files are linked together because they are all parts of the
> same project.
> The IDE help USER to manipulate FILES of a PROJECT.
> The project can be simply a list of files but it can also be a hierarchy
> of files or directories corresponding to physical directory on hard
> drive. But it's convenient to order them in a mode logical hierarchy
> sometimes completely different than directories on disk. The user must
> be able to add or remove files form the project.
> I suppose that the IDE must contain a project browser or at least a
> file browser.
> It can be obvious but I think it's important to make the difference
> with a simple text editor. With an IDE, I manage a project, not simply
> We can already visualize the IDE : An icon bar + a file/directory
> browser. When a click on a file, only some icons are showed as active
> (other are greyed)
> 5) How a module works ?
> A module can be a simple rebol script but structured in a specific way
> and that must contains specifics things. The IDE, analyse it and display
> the icons corresponding to actions of the module. These actions can be
> rebol functions.
> OK but... when I click on an icon, is the module action executed in the
> same Rebol session?
> That's important because if the script is executed by the same rebol
> * The IDE freeze during action execution
> * If the module crash, all the IDE crash also. I don't think about
> usual rebol exception but about memory overflow or infinite loop,...
> It seems more interesting to launch the module in another rebol session
> if it's not a very simple thing.
> OK. It implies that a module can be split in two parts.
> * An interface sub-module, integrated into IDE at runtime.
> * An execution sub-module, executed into another Rebol process
> This is not so simple because sometimes we want avoid simultaneous
> multiple executions of an action ("encap" a script).
> More complicated, the module has to send informations to IDE.
> Example : I'm writing code inside the "Code editor" module and I want
> specific help about a rebol keyword. I just select it and click on
> "rebol dictionary" button which is another module.
> The "Editor" doesn't know about other modules. It just know the IDE.
> You understand that the process is more complicated:
> * The "Dictionnary" module asks to IDE for a keyword
> * The IDE asks to "Editor" module for the current selected word.
> Practically the modules must be able to communicate and the IDE has to
> transmit messages.
> It implies a bidirectional communication between IDE and a module
> It implies a communication protocol.
> With the lack of direct interprocess communication with Rebol, I think
> network protocol is maybe the best solution. Maybe, LNS (aka
> rebol/services) and/or beer protocol are good solutions. I don't know.
> I already think about tons of modules : Text editor, debugger, rebol
> dictionary, anamonitor, multi file search/replace engine, versioning,
> CVS sync, RAMBO search, makedoc, image transformations, vector graphics
> editor wich generate draw dialect scripts, rebol.org search engine,
> database browser,...
> Some remarks:
> * I spoke about modules but it doesn't mean Rebol 3.0 modules as
> discussed on Rebol 3.0 Front Line. Maybe this technology is useful
> for an IDE.
> * What I described is not Rebol Desktop (viewtop) but the interface
> and world-wide-reb file syntax can be a good starting point.
> * I hope that this message will be useful and I still apologies for
> my bad English
> Karim EL FOUNAS
> EasyBraine SA
> Campagne des Rites, 8 - 1421 Ophain Bois-Seigneur-Isaac
> T=E9l : +32 2 387 32 34
> Mobile : +32 495 57 32 34
> Email : karim.elfounas-easybraine.com
> To unsubscribe from the list, just send an email to
> lists at rebol.com with unsubscribe as the subject.
Tim Johnson <tim-johnsons-web.com>