The mark must not be added to another buffer, and if its name is not %NULL then there must not be another mark in the buffer with the same name.

Emits the [signalGtk.TextBuffer::mark-set] signal as notification of the mark's initial placement.

In most cases, clipboard will be the GdkClipboard returned by [methodGtk.Widget.get_primary_clipboard] for a view of buffer.

The default handler for the signal applies tag to the given range. start and end do not have to be in order.

Calls [methodGtk.TextTagTable.lookup] on the buffer’s tag table to get a GtkTextTag, then calls [methodGtk.TextBuffer.apply_tag].

In the normal case a single character will be deleted, but when combining accents are involved, more than one character can be deleted, and when precomposed character and accent combinations are involved, less than one character will be deleted.

Because the buffer is modified, all outstanding iterators become invalid after calling this function; however, the iter will be re-initialized to point to the location where text was deleted.

This will cause any previous operations in the undo/redo queue to be cleared.

This should be paired with a call to [methodGtk.TextBuffer.end_irreversible_action] after the irreversible action has completed.

You may nest calls to gtk_text_buffer_begin_irreversible_action() and gtk_text_buffer_end_irreversible_action() pairs.

The operations between gtk_text_buffer_begin_user_action() and gtk_text_buffer_end_user_action() can then be grouped when creating an undo stack. GtkTextBuffer maintains a count of calls to gtk_text_buffer_begin_user_action() that have not been closed with a call to gtk_text_buffer_end_user_action(), and emits the “begin-user-action” and “end-user-action” signals only for the outermost pair of calls. This allows you to build user actions from other user actions.

The “interactive” buffer mutation functions, such as [methodGtk.TextBuffer.insert_interactive], automatically call begin/end user action around the buffer operations they perform, so there's no need to add extra calls if you user action consists solely of a single call to one of those functions.

Whenever the source_property is changed the target_property is updated using the same value. For instance:

  g_object_bind_property (action, "active", widget, "sensitive", 0);

Will result in the "sensitive" property of the widget #GObject instance to be updated with the same value of the "active" property of the action #GObject instance.

If flags contains %G_BINDING_BIDIRECTIONAL then the binding will be mutual: if target_property on target changes then the source_property on source will be updated as well.

The binding will automatically be removed when either the source or the target instances are finalized. To remove the binding without affecting the source and the target you can just call g_object_unref() on the returned #GBinding instance.

Removing the binding by calling g_object_unref() on it must only be done if the binding, source and target are only used from a single thread and it is clear that both source and target outlive the binding. Especially it is not safe to rely on this if the binding, source or target can be finalized from different threads. Keep another reference to the binding and use g_binding_unbind() instead to be on the safe side.

A #GObject can have multiple bindings.

This function is the language bindings friendly version of g_object_bind_property_full(), using #GClosures instead of function pointers.

This is a convenience function which simply creates a child anchor with [ctorGtk.TextChildAnchor.new] and inserts it into the buffer with [methodGtk.TextBuffer.insert_child_anchor].

The new anchor is owned by the buffer; no reference count is returned to the caller of this function.

If mark_name is %NULL, the mark is anonymous; otherwise, the mark can be retrieved by name using [methodGtk.TextBuffer.get_mark]. If a mark has left gravity, and text is inserted at the mark’s current location, the mark will be moved to the left of the newly-inserted text. If the mark has right gravity (left_gravity = %FALSE), the mark will end up on the right of newly-inserted text. The standard left-to-right cursor is a mark with right gravity (when you type, the cursor stays on the right side of the text you’re typing).

The caller of this function does not own a reference to the returned GtkTextMark, so you can ignore the return value if you like. Marks are owned by the buffer and go away when the buffer does.

Emits the [signalGtk.TextBuffer::mark-set] signal as notification of the mark's initial placement.

The order of start and end is not actually relevant; gtk_text_buffer_delete() will reorder them.

This function actually emits the “delete-range” signal, and the default handler of that signal deletes the text. Because the buffer is modified, all outstanding iterators become invalid after calling this function; however, the start and end will be re-initialized to point to the location where text was deleted.

Calls [methodGtk.TextBuffer.delete] for each editable sub-range of [start,``end). start and end are revalidated to point to the location of the last deleted range, or left untouched if no text was deleted.

Removes the reference the buffer holds to the mark, so if you haven’t called g_object_ref() on the mark, it will be freed. Even if the mark isn’t freed, most operations on mark become invalid, until it gets added to a buffer again with [methodGtk.TextBuffer.add_mark]. Use [methodGtk.TextMark.get_deleted] to find out if a mark has been removed from its buffer.

The [signalGtk.TextBuffer::mark-deleted] signal will be emitted as notification after the mark is deleted.

See [methodGtk.TextBuffer.delete_mark] for details.

If interactive is %TRUE, the editability of the selection will be considered (users can’t delete uneditable text).

This will cause any previous operations in the undo/redo queue to be cleared.

This should be called after completing modifications to the text buffer after [methodGtk.TextBuffer.begin_irreversible_action] was called.

You may nest calls to gtk_text_buffer_begin_irreversible_action() and gtk_text_buffer_end_irreversible_action() pairs.

Should be paired with a call to [methodGtk.TextBuffer.begin_user_action]. See that function for a full explanation.

This is necessary for accessors that modify multiple properties to prevent premature notification while the object is still being modified.

Note that characters and bytes are not the same, you can’t e.g. expect the contents of the buffer in string form to be this many bytes long.

The character count is cached, so this function is very fast.

See [methodGtk.TextBuffer.begin_irreversible_action] and [methodGtk.TextBuffer.end_irreversible_action] to create changes to the buffer that cannot be undone.

If dereferenced with [methodGtk.TextIter.get_char], the end iterator has a character value of 0. The entire buffer lies in the range from the first position in the buffer (call [methodGtk.TextBuffer.get_start_iter] to get character position 0) to the end iterator.

Equivalent to calling [methodGtk.TextBuffer.get_mark] to get the mark named “insert”, but very slightly more efficient, and involves less typing.

If line_number is greater than or equal to the number of lines in the buffer, the end iterator is returned.

byte_index must be the start of a UTF-8 character. Note bytes, not characters; UTF-8 may encode one character as multiple bytes.

If line_number is greater than or equal to the number of lines in the buffer, the end iterator is returned. And if byte_index is off the end of the line, the iterator at the end of the line is returned.

Note characters, not bytes; UTF-8 may encode one character as multiple bytes.

If line_number is greater than or equal to the number of lines in the buffer, the end iterator is returned. And if char_offset is off the end of the line, the iterator at the end of the line is returned.

If char_offset is -1 or greater than the number of characters in the buffer, iter is initialized to the end iterator, the iterator one past the last valid character in the buffer.

This value is cached, so the function is very fast.

If 0, unlimited undo actions may be performed. Note that this may have a memory usage impact as it requires storing an additional copy of the inserted or removed text within the text buffer.

Used for example to enable a “save” function in a text editor.

The value can be:

• an empty #GValue initialized by %G_VALUE_INIT, which will be automatically initialized with the expected type of the property (since GLib 2.60)
• a #GValue initialized with the expected type of the property
• a #GValue initialized with a type to which the expected type of the property can be transformed

In general, a copy is made of the property contents and the caller is responsible for freeing the memory by calling g_value_unset().

Note that g_object_get_property() is really intended for language bindings, g_object_get() is much more convenient for C programming.

Equivalent to calling [methodGtk.TextBuffer.get_mark] to get the mark named “selection_bound”, but very slightly more efficient, and involves less typing.

The currently-selected text in buffer is the region between the “selection_bound” and “insert” marks. If “selection_bound” and “insert” are in the same place, then there is no current selection. [methodGtk.TextBuffer.get_selection_bounds] is another convenient function for handling the selection, if you just want to know whether there’s a selection and what its bounds are.

If the selection has length 0, then start and end are filled in with the same value. start and end will be in ascending order. If start and end are %NULL, then they are not filled in, but the return value still indicates whether text is selected.

It can be used to make the content of buffer available in a GdkClipboard, see [methodGdk.Clipboard.set_content].

Excludes undisplayed text (text marked with tags that set the invisibility attribute) if include_hidden_chars is %FALSE. The returned string includes a 0xFFFC character whenever the buffer contains embedded images, so byte and character indexes into the returned string do correspond to byte and character indexes into the buffer. Contrast with [methodGtk.TextBuffer.get_text]. Note that 0xFFFC can occur in normal text as well, so it is not a reliable indicator that a paintable or widget is in the buffer.

This is the same as using [methodGtk.TextBuffer.get_iter_at_offset] to get the iter at character offset 0.

Excludes undisplayed text (text marked with tags that set the invisibility attribute) if include_hidden_chars is %FALSE. Does not include characters representing embedded images, so byte and character indexes into the returned string do not correspond to byte and character indexes into the buffer. Contrast with [methodGtk.TextBuffer.get_slice].

If len is -1, text must be nul-terminated and will be inserted in its entirety. Emits the “insert-text” signal; insertion actually occurs in the default handler for the signal. iter is invalidated when insertion occurs (because the buffer contents change), but the default signal handler revalidates it to point to the end of the inserted text.

Simply calls [methodGtk.TextBuffer.insert], using the current cursor position as the insertion point.

The anchor will be counted as one character in character counts, and when obtaining the buffer contents as a string, will be represented by the Unicode “object replacement character” 0xFFFC. Note that the “slice” variants for obtaining portions of the buffer as a string include this character for child anchors, but the “text” variants do not. E.g. see [methodGtk.TextBuffer.get_slice] and [methodGtk.TextBuffer.get_text].

Consider [methodGtk.TextBuffer.create_child_anchor] as a more convenient alternative to this function. The buffer will add a reference to the anchor, so you can unref it after insertion.

Like [methodGtk.TextBuffer.insert], but the insertion will not occur if iter is at a non-editable location in the buffer. Usually you want to prevent insertions at ineditable locations if the insertion results from a user action (is interactive).

default_editable indicates the editability of text that doesn't have a tag affecting editability applied to it. Typically the result of [methodGtk.TextView.get_editable] is appropriate here.

Calls [methodGtk.TextBuffer.insert_interactive] at the cursor position.

default_editable indicates the editability of text that doesn't have a tag affecting editability applied to it. Typically the result of [methodGtk.TextView.get_editable] is appropriate here.

markup will be inserted in its entirety and must be nul-terminated and valid UTF-8. Emits the [signalGtk.TextBuffer::insert-text] signal, possibly multiple times; insertion actually occurs in the default handler for the signal. iter will point to the end of the inserted text on return.

The image will be counted as one character in character counts, and when obtaining the buffer contents as a string, will be represented by the Unicode “object replacement character” 0xFFFC. Note that the “slice” variants for obtaining portions of the buffer as a string include this character for paintable, but the “text” variants do not. e.g. see [methodGtk.TextBuffer.get_slice] and [methodGtk.TextBuffer.get_text].

The order of start and end doesn’t matter.

Used instead of simply getting/inserting text because it preserves images and tags. If start and end are in a different buffer from buffer, the two buffers must share the same tag table.

Implemented via emissions of the ::insert-text and ::apply-tag signals, so expect those.

Same as [methodGtk.TextBuffer.insert_range], but does nothing if the insertion point isn’t editable. The default_editable parameter indicates whether the text is editable at iter if no tags enclosing iter affect editability. Typically the result of [methodGtk.TextView.get_editable] is appropriate here.

Emits the [signalGtk.TextBuffer::mark-set] signal as notification of the move.

See [methodGtk.TextBuffer.move_mark] for details.

When possible, eg. when signaling a property change from within the class that registered the property, you should use g_object_notify_by_pspec() instead.

Note that emission of the notify signal may be blocked with g_object_freeze_notify(). In this case, the signal emissions are queued and will be emitted (in reverse order) when g_object_thaw_notify() is called.

This function omits the property name lookup, hence it is faster than g_object_notify().

One way to avoid using g_object_notify() from within the class that registered the properties, and using g_object_notify_by_pspec() instead, is to store the GParamSpec used with g_object_class_install_property() inside a static array, e.g.:

  enum
  {
    PROP_0,
    PROP_FOO,
    PROP_LAST
  };

  static GParamSpec *properties[PROP_LAST];

  static void
  my_object_class_init (MyObjectClass *klass)
  {
    properties[PROP_FOO] = g_param_spec_int ("foo", "Foo", "The foo",
                                             0, 100,
                                             50,
                                             G_PARAM_READWRITE);
    g_object_class_install_property (gobject_class,
                                     PROP_FOO,
                                     properties[PROP_FOO]);
  }

and then notify a change on the "foo" property with:

  g_object_notify_by_pspec (self, properties[PROP_FOO]);