For the past few years we have got a lot of people asking us (the gedit team) why we did not provide a way to split a document and visualize it with several GtkTextViews. In this post I will point out the three problems that stop us from doing it.
- The cursor follows the insert mark from the TextBuffer.
- The selection is managed in relation to the insert mark and the selection-bound mark.
- The invisible tags are managed per document.
Why is this a problem?
- Well right now the invisible tags are not a big problem as we don’t support code folding yet, but probably we will do it soon, although in relation to the inser and the selection it is pointless to split a document and use it from several views if you are editing a document and both views are following the cursor no matter if you are in one view or another.
What would be the way to fix this?
- To manage the insert and selection-bound marks the GtkTextView should a per view-insert and view-selction-bound marks and follow only the ones set by it. The view should also modify the insert and selection-bound marks from the TextBuffer so this ones follow the ones from the view.
- In relation to the invisible tags, I am not totally sure how the best way would be for this. Probably doing something similar as with the marks.
With this post I just wanted to point out these problems in case somebody wants to fix them 🙂
I also take the chance to say it would be cool if someone can implement a useful feature that’s in other text editors, see http://bugs.gnome.org/96436 for details.
[WORDPRESS HASHCASH] The poster sent us ‘0 which is not a hashcash value.
Some discussion from IRC:
nacho: and about textview: I think you could handle invisibility with per-view textmarks, so you end up with a gboolean gtk_text_view_can_see_mark (view, mark)
mmm
nacho: i suppose you need this feature anyway for insert and selection marks (you can be sure that i’ll select a word in view 1 and then start editing that word in view 2, just to annoy you)
so instead of having an invisibility mark
we just have a mark that we just as invisible from the text view
yeah
textbuffer code does not interpret marks i think
the marks that use mainly is the insert and the selection-bound
those are then tracked by the view
and the code that interprets them is textview specific – textlayout etc i tink
see that marks != tags
* Anxiety has quit (Leaving.)
for invisibility we use tags
true
but the same thing applies
pbor, ^^
as I was saying to nacho in #gedit I think ideally all tags would need to be per view
a mark for me is just a tag where the endpoint equals the startpoint
yup
so excuse me when i use those names interchangably 🙂
well, or at least each tag should have a “tagview” object in the view (sorry cannot come up with a good name)
so that for instance style associated with the tag is in the “tagview” object
yeah
you need another indirection
this way we could have a syntax color for a “dark” text in a gedit tab, but a “light” color for the print view of that doc
right
but that’s a question of interpreting the tags
tags should be per-buffer
but interpretation should be per-view
the “tagview” object would also have a flag that says if that particular tag/mark represents the cursor for the given view
yep
so a tag “comment” could be printed light, displayed dark and hidden in emails
or whatever
* ian has quit (ChatZilla 0.9.87 [Firefox 5.0/20110624090022])
yep, there are many use cases that boil down to this separation
I guess this would need an api break?
not sure
at the end of the road probably yes, but some prepatory changes could be done within our current bounds
might be interesting to get done without
but possible
eg. the current tag properties could be overriden by a corresponding “tagview” object
but fall back to current behavior if none is set
i’d probably invent a new GtkTextTagBase class (or interface)
and have GtkTextTag inherit from that
unfortunately tags are not gobjects iirc
and then you could do your own subclasses and have them implement a (* apply) (GtkTextTagBase *, GtkTextView *) function
i think they are
textappearance and whatever aren’t
yep, they are