Re: gtk_text_buffer_delete ?

[Stefan Salewski <mail ssalewski de>]

On Thu, 2015-10-08 at 10:30 +0200, Pierre Wieser wrote:
> Oop's. Sorry ! I've clicked on the bad button !!

Yes, it is sad that this trivial task is so hard, and that no one can
really help.

I was hoping that it could be possible to simple block input when buffer
has a maximum length, but I got that not working.

But deleting works at least.

https://developer.gnome.org/gtk3/stable/GtkTextBuffer.html#GtkTextBuffer
-insert-text

> Note that if your handler runs before the default handler it must not
> invalidate the location iter (or has to revalidate it).

So our callback have to reset the iter!

I did some test in Nim, a change to test my bindings and become some
more comfortable with that language. There we have

discard g_signal_connect_after(buffer, "insert-text", g_callback(clip), nil)

proc clip*(buffer: TextBuffer, iter: TextIter; text: cstring; len: gint; data: gpointer) {.cdecl.} =
  const max = 8
  var i, j: TextIterObj
  var cc = buffer.char_count
  if cc > max:
    buffer.get_iter_at_offset(i, cc)
    j = i # copy iter object
    discard j.backward_chars(cc - max)
    buffer.delete(j, i)
    buffer.get_iter_at_offset(iter[], max) # set iter to valid value again, value seems to be arbitray

So the trick is just the last line, reset the iter callback parameter to
a valid value after deletion. It is strange, I have the feeling that the
callback is executed after the new text was already inserted, but in
spite of that gtk complains about invalid iter. Strange. I guess you can
understand the idea of that Nim code. I connected to "insert-text"
signal, so no danger of recursion. I used g_signal_connect_after here,
seems to make more sense when we delete last char. g_signal_connect
works similar, but we seem to get one char more? Maybe Emmanuele Bassi
can comment on this later...