Does this mean that something can no longer be done? Is a const_cast<> necessary
as a workaround? If so, then we should add that to the docs.

Just because a const iterator is not the same as a const_iterator does not mean
that there will never be a const iterator. Of course, I don't think that we have
a  TextBuffer::const_iterator.

Note that signal handler prototypes usually have const Gtk::TextIter& as
parameter. To be able to use that parameter properly, you have to make a dummy
copy as a work-around (that's what you did in regexxer).  A
const_cast<Gtk::TextIter&> would also work.

Right, we don't have const_iterator equivalent for for Gtk::TextIter yet, but
that's a different problem.

We might want to reexamine our current approach of always propagating indirect constness in general.

Btw., I would like that

iterator Gtk::TextBuffer::begin();
iterator Gtk::TextBuffer::end();

would be

iterator Gtk::TextBuffer::begin() const;
iterator Gtk::TextBuffer::end() const;

Created attachment 271447 [details] [review]
patch: Split Gtk::TextIter into TextIter and ConstTextIter

This patch tries to make TextBuffer and related classes more const correct.
It brakes ABI and probably also API. It's not meant to be pushed as is.
It's more of a first draft and a basis for discussion.
I have not made any changes to TextView. I'm sure some of its member functions
can take a const_iterator, a const const_iterator or a const iterator instead
of an iterator.

I have made a small class hierarchy:
  class TreeIterBase
  class TreeIter : public TreeIterBase
  class ConstTreeIter : public TreeIterBase

An alternative would be to let TreeIter and ConstTreeIter be two stand-alone
classes without a common base. That's probably a cleaner solution, but it
would contain a lot of duplicated code. GtkTreeIter contains a lot of
functions, most of which are identical in TreeIter and ConstTreeIter.

(In reply to comment #4)
> iterator Gtk::TextBuffer::begin() const;
> iterator Gtk::TextBuffer::end() const;

To mimic the STL containers (std::vector etc) it should be
  iterator Gtk::TextBuffer::begin();
  iterator Gtk::TextBuffer::end();
  const_iterator Gtk::TextBuffer::begin() const;
  const_iterator Gtk::TextBuffer::end() const;
and to have it like C++11, also
  const_iterator Gtk::TextBuffer::cbegin() const;
  const_iterator Gtk::TextBuffer::cend() const;

In comment 5: s/TreeIter/TextIter/g

https://git.gnome.org/browse/gtkmm/commit/?id=001e714e54b10d8bb3d7417046c6c4605b7a9b2f

gtkmm-4: I have pushed a patch that splits TextIter into a small class hierarchy.
  class TextIterBase
  class TextIter : public TextIterBase
  class TextConstIter : public TextIterBase

There are also aliases,
  TextBuffer::iterator
  TextBuffer::const_iterator

This bug report started with a critique of TextIter::get_marks(). Now there are
  std::vector<Glib::RefPtr<TextMark>> TextIter::get_marks() const
  std::vector<Glib::RefPtr<const TextMark>> TextConstIter::get_marks() const  

I have changed TextBuffer::iterator to TextBuffer::const_iterator where I think
appropriate in TextBuffer, TextView, TextMark and TextTag.

I would not be surprised if someone would prefer const_iterator in more methods.
A const_iterator in STL means "You can't use this iterator for modifying the
element pointed to." But if you have a non-const access to the container, you
can use the const_iterator for other types of modifications of the container,
e.g. for deleting the element that the const_iterator points to. I have
chosen not to change to const_iterator e.g. in TextBuffer::erase().