Re: gtk_text_buffer_delete_interactive

[vishnu pobox com]

On Mon, Sep 10, 2001 at 07:33:06PM -0400, Havoc Pennington wrote:
> vishnu pobox com writes: 
> > Should my patch virtualize both interactive insert & delete?  (i only
> > need interactive delete.)
> 
> I think both, and also the insert_pixbuf, insert_child_anchor, etc.

Huh?  These are *already* virtualized, even though it doesn't
seem worth the trouble.  After all, these APIs cannot be triggered
directly by the user through GtkTextView (AFAIK), so the application
can customize for the precise behavior even without the virtualization.

The reason i want to customize gtk_text_buffer_delete_interactive
is because otherwise i have to re-implement things starting
from gtk_text_view_delete_from_cursor, which would be fairly complex.

> I hate to have so many extra signals for this though. :-( 
> Seems cluttered.

Then i'll just start with a patch for delete_interactive.

> There must be a more elegant solution... 
> 
> Are we sure this is handling the general issue? (vs. the specific
> thing you are doing) - 
> 
> The general issue might be:
>   - intercepting and modifying specific user actions 
>     (deletions? delete key press?)

Partially ..

>   - 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

i admit that would be a nice addition, but it's just a cosmetic
thing.  It doesn't really change how the GUI works.

i would still need to add a handler to "delete-range" for deleting
the associated data object.  For example, if a hyperlink is deleted
then i need to call g_object_unref on the target of the link.  On
the other hand, a "treat multiple chars as a single object" property
does simplify things somewhat.

> I'm concerned that you will need a lot more hooks than this to do what
> you want, e.g. to handle the selection thing.

i doubt it, but well .. maybe.

> We also need to think through the line between "things the text widget
> supports" and "things that would be too complicated and little-used to
> support"; right now the text widget is already quite complex and
> supports tons of stuff, so my tendency is to let it exist for a
> release and see how it goes before we add more features.

Well, sure.  Coming from that angle, i propose trading INSERT_PIXBUF
and INSERT_CHILD_ANCHOR for DELETE_INTERACTIVE.  ;-)