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.
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 :)
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?
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
