Since I wrote Fl_Simple_Terminal, I gave this thread a look.
As I recall, Fl_Simple_Terminal dtor sets the display's buffer(0) so that I can then delete the Fl_Text_Buffer allocated in the ctor. This seems to be the programming pattern used elsewhere (see test/editor.cxx's handling when the window is closed, first setting buffer(0))

Anyway, it does seem odd that Fl_Text_Display::buffer(Fl_Text_Buffer*) should be doing anything to the outgoing text buffer that it doesn't do for the incoming one. For the incoming it just adds its modify+predelete callbacks, does nothing with the text buffer's contents. Yet for the outgoing text buffer, it seems to think it needs to delete all text text from the outgoing text buffer. Why, I'm not sure. Looking at buffer()s implementation, my comments in CAPS:

  if ( mBuffer != 0 ) {     // OUTGOING TEXT BUFFER
    // we must provide a copy of the buffer that we are deleting!
    char *deletedText = mBuffer->text();                                 // ?? NOT SURE WHYTEXT
    buffer_modified_cb( 0, 0, mBuffer->length(), 0, deletedText, this ); // ?? WE NEED TO DELETE
    free(deletedText);                                                   // ?? THE TEXT BUFFER CONTENTS?
    mNBufferLines = 0;
    mBuffer->remove_modify_callback( buffer_modified_cb, this );
    mBuffer->remove_predelete_callback( buffer_predelete_cb, this );
  }

  /* Add the buffer to the display, and attach a callback to the buffer for
   receiving modification information when the buffer contents change */
  mBuffer = buf;
  if (mBuffer) {  // INCOMING TEXT BUFFER
    mBuffer->add_modify_callback( buffer_modified_cb, this );      // ADDS THESE TWO CALLBACKS
    mBuffer->add_predelete_callback( buffer_predelete_cb, this );
    /* Update the display */
    buffer_modified_cb( 0, buf->length(), 0, 0, 0, this );         // LETS MODIFY CALLBACK KNOW ABOUT NEW ADDITION
  }

Since text buffers can be shared across multiple Fl_Text_Display()s, it's not at all clear to me why it should be doing anything to the contents of the buffer; we're just de-associating the text buffer from the display. There might be other Fl_Text_Display's with this same text buffer attached to it; why should it think it should destroy its contents?

In my mind all it should do is remove the callbacks it adds to new text buffers.
Perhaps there's a reason for this, but it's not clear to me.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.