Re: [FR-devel] Scintilla replacement for Freeride? (was Newbie to FreeRIDE).

[Euan Mee]

On 8 May 2002, Baptiste Lepilleur wrote (more or less):
> From: "Yohanes Santoso" <address@hidden>
> > "Baptiste Lepilleur" <address@hidden> writes:
> > rectangle is a rectangle-shaped selection over some
> >content. region is almost like a selection.which follows the
> > topography of the content). 
> >
> > typically, selections can only be cut, copied, and pasted.
> > region can apply many additional operations to its contents -
> > you can apply special indentation, sort, count words, count
> > lines, etc. Sorting within the region is especially useful for
> > rearranging a collection of methods. 
> 
> Ahah, that sounds a lot like an 'abstraction layer' on top
> of Scintilla - being able to manipulate text with a 'high'
> level function (e.g. a function to change a line indent, but
> keep the caret on the same letter). Word-count is fairly
> specific, but a generic sort or reorder line could make sense. 
>
> The abstraction layer should provide abstractions for:
> Document:
> - text (each line of text)
> - style (syntax coloring for each character and indicator (red
> underline like in MS Word for bad spelling)) - fold data: line
> that are fold point, blank lines and fold level - markers
> (bookmark/debug/... symbols in the margin)
> 
> View:
> - folding:
>     - visible lines
>     - folder status for a line (is the folder expanded ?)
> - caret movement
> - selection
> 
> Etc:
>
> With an abstraction layer of that kind, we could easily write
> a lexer that styles the text using the document layer. We
> could implement the layer one way for Scintilla, and another
> for text mode (which would need to manage its one buffer for
> text and styling). 
> 
> > I propose putting a decent UI on top of something with the
> > flexibility of an emacs. A UI that a beginner can use
> > without being overwhelmed, (e.g. one with a simple 
> > keybinding that a beginner can understand, another 
> > keybinding aimed at people moving over from emacs, etc)
> > similiar to the way MacOS X provides a straightforward UI 
> > for Unix that even my mom can use, yet it also allows you
> > to drop in to the shell level if you want to. 
>
> Beyond keybinding, there is also customization: 
>
> 1) you need a good UI to help the user customize the tools. I
> can see something were command would be categorized, could be
> filtered (adds a set of keywords to each command)... 
>
> 2) you may want to different keybindings for different tasks,
> e.g. I decide to do some heavy refactoring => I switch to the
> 'refactoring' profile... Some profile switching may be
> automatic (depends on the document type for example). They
> would also probably have a common base (unless you like
> headache you likely want the same keybindings to move the
> caret around, copy/cut/paste...) 

Quick question - do you currently envisage other aspects 
being customised in these profiles, or just keybindings?

> > I think Scintilla is great! But it's hard to imagine users
> > extending it easily. 
>
> What extension are you talking about ? I found few limitations
> (see below)
> 
> > It has has a lexer for many languages, but written in C++,
> > so it can't be extended from within FreeRIDE. User extensibility
> > is a great and important feature. 
> 
> Styling can be done by the container (the ruby part): Scintilla
> send a styleNeeded event and you are supposed to style the
> specified text. You can also completly disable styling. I did
> this for a console output and I colorize the text as I print it!

Another quick question: are the styles Scintilla applies after a 
styleNeeded event configurable?

How straightforward is it then to use Scintilla as a document 
processor, and configure it to recognise a <begin Rubycode> 
and <end Rubycode> pairing, so that we can have an 
automated process which brings together all the program code 
from all the various parts of the system documents in which it 
is written and scattered for testing or production use?  i.e. an 
'UNTANGLE' function

How straightforward would it be to use placeholders to refer to 
more detailed refinements of code structures (both in the 
document and between <code> </code> - type markers), 
without affecting our ability to UNTANGLE the program code 
from the system documents?
 
> The main limitation I run into was the marker symbols: there is
> little choice (a lot of symbol for folding/tree, but few for
> other purpose). But It's fairly easy to add other symbols to
> Scintilla (a few line of C++), with enough diversity, it would
> not be a problem anymore.

Is this to add to Scintilla's processing of the edited code?  Or 
just to make the marker symbols available to typists using the 
Scintilla GUI?

> > Curt is right in saying that attempting to replace Scintilla
> > could be a waste of time or it could be a wonderful thing.
> > I'd go do parallel devel but there are two problems:  
> >
> > 1. I have never done extensive UI programming much less 
> > UI designing. 
> >
> > 2. I can't do the engine by myself (not enough skill, time,
> > etc). 
> >
> > 3. I'm afraid that this'll be a waste of time because perhaps
> > in reality there are better ways to have a sane UI and
> > capabilities of emacs without this much work. 
>
> The abstraction layer could probably done incrementally,
> starting with an implementation for Scintilla (basically very
> little work, mainly forward to one or more Scintilla
> function). That layer would also help for testing (You can
> have a mock implementation). 
>
> It could be as simple as:
> def setTextStyles( position, styles )   # styles is an
>                                                       # integer array 
> def textStyles( position, length )        # return an integer array 
> def setTextIndicators( position, indicators )  
>                                             #idem, but for special
>                                           # marking of the text 
> (underline...) 
> def textIndicators( position, length )
> 
> Those abstractions could be later used for higher level functions,
> such addStyledText... Implementation of those methods for
> Scintilla is simple (a combination of StartStyling and
> SetStyling). Text manipulation could probably be abstracted with
> a few methods too...

This sounds good.  My only indecision is whether the 
additional layer of abstraction on top of Scintilla using such 
style markers might be more inconvenient to use when 
developing than 'wiki'- style markup commands.

Then again, maybe there is no conflict between abstracted 
style-markers and a wiki-syntax approach to 'mixed' 
documents - i.e. ones which are text documents ready for 
richly-formatted publication to screen (e.g. WWW, PDF) or 
page, and which also contain all the program code for the 
system under development, in a form which allows automatic 
extraction for use.




Cheers,
     Euan
address@hidden

'I would live all my life in nonchalance and insouciance,
Were it not for making a living, which is rather a nouciance'
 - Ogden Nash