<rambokid> hp: peeking at the testtext example, it doesn't seem to
hard to add a function to your text widget taht inserts text with
pango markup.
<hp> rambokid: no it shouldn't be hard
<hp> rambokid: the only issue is what you do about the tag table
<hp> rambokid: one way is to require people to use the special "pango
markup tag table"
<hp> rambokid: another is to have
gtk_text_tag_table_create_pango_markup_tags() to modify any existing
tag table to contain the markup tags
<hp> rambokid: another is to have a markup language that's like <tag
name="foo">text</tag> and then work with any tag table
<rambokid> hp: you have tag names, i guess you'd add pango-* tags on
demand (i.e. if such a tag isn't already there) kinda like we use
qdata on widgets along side the user using qdata as well
<hp> rambokid: but that last option wouldn't use the Pango markup format
<hp> rambokid: that might be a good option, yes, to implicitly add the
tags when they are first used

*** Bug 105313 has been marked as a duplicate of this bug. ***

Created attachment 23423 [details]
small test that implements text_buffer_insert_markup() and other convenience functions

Attachement above is a self-contained test program that implements 
this functionality in a simple and crude way. 
 
It has four new functions: 
 
  - text_buffer_insert_markup() 
  - text_buffer_insert_markup_with_tag() 
  - text_buffer_set_markup() 
  - text_buffer_set_markup_with_tag() 
 
The _with_tag functions take an extra GtkTextTag to apply to the 
whole text, for word wrapping and justification parameters etc. 
 
Possibly it would be better to use GMarkupParser here and 
parse the markup ourselves. That would also allow us to 
expand the markup to include stuff like word wrapping and 
text justification, which cannot be set via pango markup. 
Additionally it would allow us to insert pixbufs with markup  
like <img file='foo.png'>. Or is that overkill? 
 
In any case, it would be nice if something like this went into 2.4, 
however crude it is implemented. In the worst case, one could point 
out in the docs that those functions are only suitable for short 
text. 
 
Cheers 
-Tim 
 
 

Created attachment 23451 [details]
Test app with text_buffer_insert_markup() implementation. This version fixes memory leaks of the previous version.

Created attachment 23628 [details] [review]
proposed patch that adds four new functions to the API

First of all, sorry for the flood. I thought it was better to post a  
sample first to see if my approach was right, but I guess it's  
better to just submit a patch. Won't do it again.  
  
  
The above patch introduces four new functions to the API, as  
described in my previous comment, ie:  
  
 - gtk_text_buffer_insert_markup()  
 - gtk_text_buffer_insert_markup_with_tag()  
 - gtk_text_buffer_set_markup()  
 - gtk_text_buffer_set_markup_with_tag()  
  
None of these functions takes a length argument. The markup text is  
expected to be NUL-terminated and will always be inserted fully.  
This is because the alternatives all seem a bit awkward to me.  
  
Any thoughts or comments?  
  
Cheers  
-Tim  
  
PS: maybe someone could change the keywords to API, PATCH ... 
 

Moving to 2.6 API Freeze since we have a patch. Haven't looked
at the patch or proposed API.

I'm adding the BLOCKED_BY_FREEZE keyword.

Created attachment 28723 [details] [review]
same patch, but with 'Since: 2.6' in the description

What about markups which overlap to each others? something like:
  <i><u>2 tags text</i></u>
The real_insert_markup should check if the range of a markup overlaps with the
previous one and accumulate tags before insert.

Also a new tag is created for every markup encountered, that cause tags the same
markup being created. Shouldn't a hashtable of 'markup' -> tag be saved in the
textbuffer, so that tags can be reused by name?

or:
   <i>and <u>underline me </u> to stop it </i>.

I assume you meant  
 
  <i><u>2 tags text</u></i> 
 
? 
 
I would expect pango_parse_markup() to accumulate tags like that (I haven't 
actually checked whether it does though). 
 
I am not sure I understand the purpose of your last example <i>and 
<u>underline me</u> to stop it</i>.  
 
I agree a hash table that maps a certain format to a re-usable tag would be 
nice, but it doesn't seem worth the effort to me. In any case, this kind of 
optimisation could still be added later IMHO. Feel free to modify the patch 
though, or come up with a new one :) 
 
Cheers 
 -Tim 
 
 

About reuse the tag of a given markup, there is a function:

  GtkTextTag* gtk_text_tag_table_lookup (GtkTextTagTable *table, const gchar *name);

A named tag should be checked first and if NULL is returned, a new one can be
created. No hashtable is neccessary.

When I said 'effort' I didn't mean the hashtable lookup or the 
gtk_text_table_lookup(), but rather the problem of 'I have this bunch of 
PangoAttributes with these values; how do I know I already have a tag with 
exactly the same attributes?'. 
 
Maybe this is trivial, but I don't see how to easily do it. Of course one 
could always serialise the attributes into a string again and derive a tag 
name from that, but I have my doubts that that would really be of advantage 
for the common case. Similarly, we could parse the attributes ourselves using 
GMarkupParser instead of pango_parse_markup(), but that seems like unnecessary 
code duplication for hardly any benefit to me. 
 
Cheers 
 -Tim 
 

There are no freezes affecting 2.6

Any chance to get this or something like this into 2.8 now that Rich Text Format
support doesn't seem to be on the roadmap any longer?

Cheers
 -Tim

See bug 324177 for the current effort towards rich text support. 

*** Bug 380533 has been marked as a duplicate of this bug. ***

This is quite a popular request on #pygtk list, I really wish GTK+ made marked up text insertion into a GtkTextView easier.

Based on bug #505478, I can propose a different approach.

We add functions to insert markup that is not Pango markup, but is instead based on buffer's tag table.  E.g. if you have tags 'header' and 'term' in a buffer, you could do sth. like:

        gtk_text_buffer_insert_markup (buffer, "<header>Bla-bla</header>\n<term>Markup</term> stands for...");

Also, there can be a function that injects tags similar (or maybe even identical) to those used in Pango markup into a tag table.  E.g.:

        tag_table = gtk_text_tag_table_new ();
        gtk_text_tag_table_add_pango_markup_tags (tag_table);
        buffer = gtk_text_buffer_new (tag_table);
        gtk_text_buffer_insert_markup (buffer, "<b>Bold and <i>italic</i> text</b>");

Is there any reason this patch wasn't applied? It seems a shame for this functionality to bit-rot in bugzilla forever.

> Is there any reason this patch wasn't applied? It seems a shame for this
> functionality to bit-rot in bugzilla forever.

Surprisingly enough, the patch still applies, even after 8 years :)

Yeah, I had to copy this function into my project as well. It's super disappointing. Is there any reason it can't go in?

( I also cleaned it up a bit: http://git.gnome.org/browse/gnome-initial-setup/tree/gnome-initial-setup/gis-utils.c#n36 )

What needs to happen to get this patch applied and into a release? I'm not averse to getting my hands dirty to make it happen. Let me know.

This program have a memory leak bug:

=====
@@ -153,7 +155,7 @@
         {
           gtk_text_buffer_insert_with_tags(buffer, textiter, text+start, end - start, tag, NULL);
         }
-      g_object_unref(G_OBJECT(tag));
+      g_object_unref(G_OBJECT(tag)); //Memory leak bug fix by kubtek!
 
       /* mark had right gravity, so it should be
        *  at the end of the inserted text now */
=====

See:
http://code.google.com/p/stardict-3/source/browse/dict/src/gtktextviewpango.cpp

Great that this got fixed, but some comment why my original patch wasn't up to scratch or couldn't be used or updated would have been nice...

not that it 'wasn't up ot scratch'. I just started from Jaspers version of your code in gnome-initial-setup. It was a spur-of-the-moment decision to get this taken care of, not something I've been brooding over since you've attached a patch in mid-2004 :-)

I guess what I really meant was that some kind of acknowledgment that I was the original author of the code would've been nice, like a 'Based on patch by:' in the commit message or somesuch. I know it was an old cvs diff and not a git-format patch, but I didn't really expect any sudden progress on this bug after that many years. Anyway, thanks for merging it.

You are right, sorry for not mentioning it in the commit message.