Re: Syntax Highlighting Text Widgets




On Wed, 01 Mar 2000 15:00:03 Matthew wrote:

 [snip]

> I've got GtkEditor compiled in now.  It's not what I need, and won't
> be without a fair amount of hacking.  The whole c-scanner business
> is enough to scare small children.  It works great as a straight-up
> replacement for gtktext, but I don't want to impose an fdopen() that
> may or may not work upon my users.

Right.  We use dynamic library loading for configuration of the
editor.  We should probably use gmodule for this though.

You can use the function 'gtk_editor_compile_scanner' to translate a
list of highlight entries into a library.  Such libraries can then be
loaded with the function 'gtk_editor_load_scanner'.  At this time,
this is the only way to create new highlight rules dynamically.  If
you're willing to settle for a static set of highlighters you don't
have to worry about dynamic libraries, though.  You just link with the
scanner libraries (statically).  Then, you just install scanners in
editors with the function 'gtk_editor_install_scanner'.

You can also use 'gtk_editor_install_scanner' to your own scanners,
and use this way to implement your own highlighting.  This way you
could implement dynamic configuration without using dynamic libraries.

 [snip]
 
> >The only requirements for GtkEditor is a vanilla installation of
> >GTK+.  This differs from earlier versions of GtkEditor. We use
> >gtktext as a basis widget[1], but will adopt the new text widget as
> >soon as we get an official replacement.
 
> Not true.  If you want syntax highlighting then you're dependent
> upon the c-scanner lib.  Although it's built at the same time as the
> shared libs, if you don't plan on using it as a library then
> c-scanner becomes a liability.
 
Er...the c-scanner lib is generated by the test application on
runtime.  The editor doesn't require it as such, it is capable of
generating what it needs.  And, as mentioned above, you can also
simply link scanners in statically.

 [snip]
 
> How about GtkEditor Lite that comprises a single .c file, #including
> a single .h file that contains the highlighting rules?

I'm not sure I follow you here.  Do you mean the scanners such as
'c-scanner' or the routines doing the highlighting in the widget?  If
you are referring to the former, it's a matter of creating the scanners
and then linking statically.  If you are referring to the later the
problem is a bit worse.  Or better, if you wish, 'cause it's already
there, but there is a twist.

We need some kind of lexical analysis of the text to do highlighting.
Earlier versions of gtkeditor used the regex library from emacs to
translate regexps into scanners.  With this approach you need to link
in this library, but you get rid of creating dynamic libraries and
loading these.  With the current approach we use flex.  Here we get
rid of the regex library, but we need to handle dynamic libraries.

For most of the editor, the exact way of getting a scanner doesn't
matter.  Anything implementing the 'interface' of a scanner

  typedef struct {
    void (*token_func)(void (*func)(guint16, char *text, guint16));
    void (*char_func)(int (*func)());
    int (*lex)();
  } GtkEditorScanner;

can be used.  So you can implement such a guy anyway you want and
you're set for highlighting.  We create a lexer using flex, and load
it as a dynamic library.  This is just one solution.  Other solutions
would be to implement scanners through different regex libraries or
code them by hand.  After you have installed a scanner, the
highlighting is take care of by the gtkeditor code.

I do not imagine that it should be difficult to implement other ways
of generating scanners, if you work with any of the many regex
libraries floating around.


	  /mailund




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]