Version française
Home     About     Download     Resources     Contact us    
Browse thread
Re: [cameleon-list] Extending sourceview to handle extra highlighting
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Maxence Guesdon <maxence.guesdon@i...>
Subject: Re: [cameleon-list] Extending sourceview to handle extra highlighting
le Thu, 28 Jun 2007 11:56:23 -0400, Therapon Skotiniotis écrivait:

> > >    I am trying to extend chamo and deal with error messages. So when I
> > > have an error message with a line and column(s) I would like to alter
> > > the text, i.e. underline it. I've spend time reading ed_sourceview and
> > > specifically ed_sourceview.source_buffer and ed_sourceview.my_buffer.
> > > But everything I tried did not work.
> > >
> > >   I also tried to extend my_buffer and use multiple inheritance with
> > > GText.buffer. It was the only other way I know on how to easily
> > > manipulate any text in the buffer.
> > >
> > >   Is there an easy way to get font manipulation inside chamo? Am I
> > > completely off on this?
> >
> > I think the best way is to get the buffer of the view with the
> > source_buffer method of the sourceview class. You get a my_buffer object.
> > Since the my_buffer class inherits from GSourceView.source_buffer, which
> > inherits from GText.buffer_skel, you can create tags and add them in the
> > buffer for the "error zone", using methods "create_tag" and "apply_tag".
>   Hmm, did you mean to say GText.view_skel instead of
> GText.buffer_skel ? The code in ed_sourceview.mli says:
>  class source_view:  Gtk_sourceview.source_view obj ->
>   object
>     inherit GText.view_skel
>     val obj: Gtk_sourceview.source_view obj

Well, there are two different things: views and buffers.
Each view has an associated buffer. The view displays the contents of the
buffer. Two (or more) views can have the same associated buffer. In this
case, typing text in a view modifies the buffer and the other view(s) also
displays the changes.

Now there are two other classes: GSourceView.source_view and
GSourceView.source_buffer. They work the same way as classes GText.view and

The source_view and view classes have respectively source_buffer and buffer
methods to get the associated (source_)buffer associated to the view.

In fact, the GText.view class inherits from GText.view_skel and
GText.view_signals. The GSourceView.source_view class inherits from
GText.view_skel to share common methods, but not from GText.view_signals
because signals are somewhat different. By the way, the method to retrieve
the source_buffer from a source_view is called source_buffer and not
buffer, because it would override the buffer method of the inherited
GText.view_skel class which returns a GText.buffer, not a

Now, in chamo, we define a Ed_sourceview.sourceview class (note the missing
'_' between "source" and "view") which is used to represent source-code
edition views in the chamo interface. Since these views use the
GSourceView.source_view widget, the Ed_sourceview.sourceview class contains
a GSourceView.source_view widget to display the source code being edited in the chamo sourceview. I hope it's clear, the names may be badly chosen :-)

The Ed_sourceview.sourceview class contains more information, like the
position of the cursor and the buffered_file object corresponding to the
file begin edited. The buffered_file contains a my_buffer object which
inherits from GsourceView.source_buffer. This same buffer is associated to
the GSourceView.source_view contained in the Ed_sourceview.sourceview.
When the buffered_file associated to the sourceview changes (for example
when the user opens a new file in the current sourceview), the
source_buffer is associated to the source_view of the sourceview.

So, when you want to show the location of an error message, you have to get
the Ed_sourceview.sourceview (let's call it edsv), get the associated
source_buffer with 
and use the "*tag*" methods to create and apply tags to the text in the
>   And here is where my knowledge of Object in OCaml gets me intro
> trouble :). I then looked up the mli for view_skel looking for the
> create_tag methods and the rest. But they are not there. (I am pasting
> the view_skel section from gText.mli at the end of my message).
>   On the other hand, if I use view_skel's interface then I can call
> view_skel.buffer, which has type GText.buffer. I think i can use that.
> I'll code it up as soon as I get some time to spare.

You'd rather use the code above to get a source_buffer.
> > This way, you can create a tag named "error" for example, with some
> > properties (different font, colors, ...) and apply this tag on the text
> > corresponding to the line and chars of error.
>   Exactly :) That is what I was aiming for.
> >
> > You must translate these line and characters into GText.iter before, using
> > for exemple the get_iter* methods; beware of the possible use of the
> > to_utf8 and from_utf8 methods of the buffered_file; Since the contents of
> > buffers are in utf8 and ocaml source code is in (extended) ascii most of
> > the time, you should use these functions to convert line and chars in ascii
> > to line and chars in utf8 before getting the iters.
>   Ah, thanks for the pointer. I'll do that.
> > If you don't it can
> > still work, but not if the to_utf8 and from_utf8 methods are set to replace
> > some chars from and to utf8 like I do with my greek letters mode.
> >
>    True, but I would like the extension to be an *extension* so that
> all that works before adding my code, still works afterwards. Besides
> I could never forgive myself for breaking support for greek fonts ;)

Your extension have to use the to_utf8 and from_utf8 methods, even if it is
just an extension. But I agree that you can start by leaving this for later.

> > Hope this helps. Do not hesitate to ask if you encounter problems.
> >
>   Thanks, if i encounter more problems and I get stuck I'll try this
> mailing list. Up to know the list has been *very* helpful.
> > And please tell us when you're code is ready :)
>  Definitely. Actually I am a member of one of the teams working on the
> OCaml summer of code.
>   ( Look for Dromedary )
> Our project is to extend chamo with similar features as other IDEs.

That's good news :)

> Similar in spirit to the support for F# in Visual Studio. As soon as
> we have something usable we'll definitely post on this mailing list.
> Off to code now.