On 11/26/06, Quentin Mathé <[EMAIL PROTECTED]> wrote:
Le 25 nov. 06 à 10:11, Yen-Ju Chen a écrit :
> On 11/25/06, Quentin Mathé <[EMAIL PROTECTED]> wrote:
>> Hi Yen-Ju,
>>
>> I think it's a really good idea to have a really good code editor
>> part of Étoilé. Thanks to take care of this.
>> But did you take a look at Project Manager code before starting? I
>> think PM code is very good and reusable.
>> It's could be better to reuse its editor view than writing a new one
>> from scratch (in PM editor view, I personally really like the
>> horizontal/vertical rulers and the guidelines support).
>> If you prefer to have your own editor view, you may at least reuse
>> the highlighting code which is available in a standalone framework
>> named HighlighterKit.
>
> I did look at the ProjectManager and haven't made my mind yet. :)
> ProjectManager and Smultron both use property list for syntax
> highlighting
> while CodeEditor (old) use a bundle (highlighting programmingly).
> While property list can be easily modified, bundles can take care
> every details.
> A shortage of property list approach is that it basically search all
> the possible
> keyword exhaustedly.
> As far as I understand, the HighlighterKit is basically written
> a regular expression library from scratch.
> It can easily be done with the use of OgreKit.
Yes, but iirc Saso told me this regex engine was tweaked in order to
be a lot faster (at the cost of some regex features/flexibility).
For 'real' explanations, you should get in touch with him directly.
The highlighting code of PM was very fast in my experience even with
huge files like NSWindow.m.
It is fast because it only highlight the visible part, not the whole
document. :P
That is the trick I am going to adapt later.
In this case, any approach should be fine since the amount of text
in the visible part is very limited.
Anyway, I will leave the issue open.
> If we think this problem from another point of view,
> syntax highlight is basically token parsing of a programming language.
> Is it possible to parse a programming language based on a list of
> keywords or regular expression ?
> I am not an expert, but I can hardly think an example.
I'm not an expert at all, but I would say that syntax highlight
requires a limited parser.
I may be wrong but most syntax highlighter doesn't need to match
keywords pairs (like '{ }' in Objc) unless you want to highlight the
background of a method or a whole 'if' statement. This means you
doesn't need a recursive parser, so regex is sufficient.
For code indentation, it's probably different since you need to match
keywords pairs. Well unless you decide to provide only rudimentary
code indentation.
If someone knows the topic well, please correct me or clarify my
feedback :)
I put up a list of features I plan to support or not in README.
> Another issue is the speed.
> In the end, when user press a key,
> CodeEditor has to re-highlight the syntax, indent, recalculate the
> line number,
> find the other part of block symbol, probably try to do the
> auto-completion, etc.
> The property list approach seems to be slower than the bundle approach
> because a bundle can be more smart.
> For example, property list has to match all the keyword with NS-
> prefix or use NS.* regular expression
> while a bundle can just look at the first 2 characters and decide the,
> whole word is a NS- keyword.
But such optimization is critical only if plist approach doesn't
permit to achieve text view updates which are fast enough to be
invisble.
> Anyway, I just put up the skeleton for syntax highlighting
> and haven't gone into the details.
> I am leaning to use the bundle instead of property list
> unless a bundle is not provided.
>
> Another thing is that I tend to keep CodeEditor a text editor,
> not strongly tied with programming.
We can put programming only stuff in plugins not loaded by default.
But can you think of many uses for a text editor outside of
programming, markup languages or system administration?
Well, there are a lot of scientific program still used plain text file
for input and output.
A deeper question is how far the CodeEditor should go before
it becomes a project manager ?
Or do you want Spot to play slide show and imaging editing
and Babbler to support play list ?
In my understanding, for each data type (image, text, sound, etc),
there are two level of applications.
One is the viewer, one is the organizer.
For music and video on mac, QuickTime is a viewer, iTunes is an organizer.
For image, Preview.app is a viewer and iPhoto is an organizer.
You can even say a web browser is a viewer and
and bookmark manager is an organizer.
Of course the boundary is not always clear or one of them is not necessary.
Say Grr.app is a RSS organizer and you probably don't need a RSS viewer.
So my plan is to have CodeEditor a viewer (editor) and
ProjectCenter or Project Manager the organizer.
Syntax highlighter is useful for a viewer but auto-indentation and
auto-completion
could go to the organizer.
We can discuss a feature list we both agree for CodeEditor.
And I am not against the code sharing.
By the way, a minor issue:
HighlighterKit is under GPL and not in Etoile repository.
Yen-Ju
Yen-Ju
> It is called CodeEditor simply because I cannot think a good name.
ok. I'm sure we will find a better name in the end :)
> Actually, Typewriter is a good name for plain-text editor.
> But then we have to come out another name for the rich-text editor. :P
Well, Typewriter isn't so bad for a plain-or-rich-text editor too ;)
Cheers,
Quentin.
--
Quentin Mathé
[EMAIL PROTECTED]
_______________________________________________
Etoile-dev mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-dev
_______________________________________________
Etoile-dev mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-dev
