Created attachment 5581 [details]
patch & discussion

On Mon, Sep 10, 2001 at 07:33:06PM -0400, Havoc Pennington wrote:
>   - simply that allowing "treat multiple chars as a single object"
>     should be a tag property? since e.g. you also need to handle
>     this when selecting, you should be able to select only all
>     or none of the email address

Actually, this is a great idea.  With this type of tag property
i wouldn't need to customize delete_interactive.

This sounds like a post-2.0 API addition to me, but I'll
let Havoc decide.

From: Steven Ashe <steve.ashe@minolta-qms.com>
To: gtk-devel-list@gnome.org
Subject: textview virtual function is, or isn't?
Date: Mon, 24 Sep 2001 17:49:04 -0600

When is a function in a class' virtual table truly virtual?
Take a look at gtk_text_view_delete_from_cursor.  Here is
a virtual function (actually the default handler for the
"delete_from_cursor" signal) that also functions as
a bona fide C proc.

Consider this scenario: within a textview I wish to treat
groups of characters as a single entity.  Not so strange,
if for instance I was writing a binary-file editor.  The
groups of characters are hex representations of bytes in the
subject file.  Certainly it would be nice if tags could be
used to bind groups of characters that behave as a signal
character, but since they can't, it seems I have two choices:
1) subclass textwidget, and replace the default handlers
for the basic editing functions with ones that handle
our character-groups appropriately, or
2) put a "before" sort of handler on the delete_from_cursor
and other such signals, do things my way, and then stop
the signal.

However, the way gtk_text_view is coded, it appears that neither
will work.  To the naive code reader, it appears that
gtk_text_view_commit_handler calls
gtk_text_view_delete_from_cursor directly, bypassing the latter's
role as a virtual function and bypassing its role as a signal
handler.  (gtk_text_view_commit_handler is itself a signal
handler that cannot be overridden, but this doesn't seem
particularly relevant to the problem.)

If this is an oversight of some sort, or something that puzzles
someone else, then I will at least be relieved that I'm not the
only one to get muddied tiptoeing through the conceptual
morass of what are true -- and what are ersatz -- signal handlers
and emitters in gtk.  ;-)

i don't need this feature anymore.  i can get by well enough without it.