Re: alternative gmarkup parser



Paolo Molaro <lupus lettere unipd it> writes: 
> Maybe G_MARKUP_SKIP_WHITE_SPACE could be useful to skip white
> space at the beginning of a tag content to better support tag
> nesting, for example.
>

As far as I can tell the correct behavior is to dump whitespace below
an element <foo> if there is no non-whitespace text below element
<foo>, only other elements. The old non-incremental gmarkup parser did
that, but you can't do it "on the fly" (you only know there was no
non-whitespace text after you end the element <foo>).
 
> Why not expose the GMarkupAttribute GSList here? There is no reason
> to copy things that way all the time.

Copying the strings is easy to avoid, there's a FIXME in there about
it. I don't want to expose the GSList; I think it's a relatively
fragile/inconvenient data structure to export. Creating the array
(g_malloc (sizeof(char*)*n_attributes)) is no big performance hit.

> The order of the attributes should be preserved
> (just do a g_slist_reverse() before calling the handler).
> 

Good point.

> >   /* Called on error, including one set by other
> >    * methods in the vtable. The GError should not be freed.
> >    */
> >   void (*error)          (GMarkupParseContext *context,
> >                           GError              *error,
> >                           gpointer             user_data);
> 
> user_data and error are swapped here, just for consistency.
>

This is a different case, here we're passing in an already-set error,
in the other cases the error is an out param for setting the error.
 
> Also, what about a callback for entities? It could be:
> 
> 	gchar* (*entity)       (GMarkupParseContext *context,
> 	                        gchar               *enitity,
> 							GError              *error,
> 							gpointer             user_data);
> 
> This will be called for non-standard entities and will return the
> text to substitute in the xml stream (the text will need to be g_free()d).
> If the callback is not set, issue an error as you do now.
> 

I don't want to support user-added entities, it complicates things and
isn't really useful for the purpose GMarkup is intended to
serve.

Havoc




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