Re: GtkSourceView C++ syntax highlighting problem.

[Paolo Maggi <paolo maggi polito it>]

Hi Jeff,

> After my previous reply I checked my GtkSourceview installation, only to 
> discover that for some reason 0.2.1 didn't overwrite the 0.2.0 'lang' 
> files. C++ syntax highlighting does indeed work - what a relief!
> 

Great!
Any idea on why 0.2.1 didn't overwrite your 0.2.0 'lang'  files ?

> Some other quick questions.
> 
> 1. Do you plan to derive GtkSourceMarker from GtkTextMark at some time 
> in the future, or is it likely to remain a typedef. If you do plan to 
> derive it from GtkTextMark wouldn't it be better to do it sooner rather 
> than later (it makes it easier for me to add to an existing C++ class 
> hierarchy).

Yep, we'd like to derive GtkSourceMarker from GtkTextMark in the future,
but ATM this is not possible without an API change in gtk+.
So, we have to wait for the next gtk+ major release.

> 
> 2. I suppose it should be obvious but I'm trying to understand 
> GtkSourceBuffer's can_undo and can_redo signals. When are they actually 
> emitted? Are they emitted when a buffer's undo/redo state changes, and 
> thus does their signal argument tell you 'true or false' whether changes 
> to the buffer can be undone/redone?

Yep, they are emitted when a buffer's undo/redo state changes and their
argument tells you whether changes to the buffer can be undone/redone.
You can use it, for example, to change the sensitivity of the Undo/Redo
menu items or toolbar buttons.

> 
> 3. Every langauge has a name specified in its 'lang' file (C, C++ HTML, 
> Java etc.). I noticed you can explicitly set the source buffer language, 
> but only by mime type. Wouldn't it be reasonable to be able to retreive 
> the list of supported languages as a list names, and to be able to 
> explicitly set the buffer language by name.

Actually gtk_source_buffer_set_language requires a GtkSourceLanguage, so
you can set the language by name if you want (I do it in gedit for
example).
Probably we could add a gtk_source_language_get_by_name utility function
but then we will have to face the problems due to the fact that language
names could be translated.

> 
> 4. GtkSourceTagStyle could be implemented as a boxed type since it has a 
> get_type(), copy() and free() function (being a boxed type would make it 
> easier and cleaner for me to add to my C++ class heirarchy).
> 

It should already be a boxed type. Why do you think it isn't?

Regards,
Paolo