GNOME Bugzilla – Bug 141487
double/split view of the same file
Last modified: 2020-11-24 09:59:59 UTC
I would like to have the ability to view the same file in two different positions using two different views as in Emacs when you type C-x 2
I see that there is ongoing discussion on desktop-devel list about this, for reference: http://mail.gnome.org/archives/desktop-devel-list/2004-April/msg00512.html A part of the code infrastructure to have multiple views is already there in gedit, but it's unfinished. Having multiple views of the same files also opens up a whole new set of problems which have probably to be considered together with the (planned, but not high prio) redesign of gedit's internal handling of multiple documents. The shortcomings of the aging bonobo-mdi are tracked in bug #131953. For example *if* it's decided to have multiple views of the same buffer IMHO it would also make sense if the internal mdi would allow, beside tab, also a sort of docking so that it's possible to see the two views side by side.
See also http://mail.gnome.org/archives/desktop-devel-list/2004-April/msg00527.html
I don't know if it's possible but perhaps you could fix the single cursor position problem by saving the cursor position on a focus_out event and restoring it on a focus_in event. This allows the user to copy some text in a view and paste it in the other view, which is (I think) the main use of a double view. About the selection, perhaps it's better to link it to the buffer, as it is now, rather than to the view, for example emacs has a mixed solution that links the start of the selection to the buffer so you can have two different selections but they start at the same point, this is not a good behaviour because it's unexpected.
This seems like a niche feature, for people who know how to install a different editor. Surely gedit isn't meant to be a code editor.
Well, split views is not strictly a code editor feature, it's often useful when you deal with a long file and you want to see two parts at the same time: a latex document where you want to keep an eye on two different sections comes to my mind. Beside *if* the code easily allowed it, the feature could be done as a plugin without hampering the default UI. That said, the one buffer <-> on view architecture is pretty deep in gedit internals (due also to how GtkTextView works), so I don't see multiple-views coming any time soon.
*** Bug 591049 has been marked as a duplicate of this bug. ***
*** Bug 497043 has been marked as a duplicate of this bug. ***
*** Bug 530344 has been marked as a duplicate of this bug. ***
Created attachment 163606 [details] [review] splitview v1 There we go with the first version
Created attachment 163867 [details] [review] splitview v2 Same as before but using GBinding. Needs latest glib git version.
I haven't reviewed the patch yet, but here follow some bugs I could find while testing it out: 1) Splitting a file does not propagate the right language to the new view (it does it in the splitview but not in splitview2). Changing the language does apply to all buffers. Also the language is lost when unsplitting. 2) Print preview acts quite weird. Not sure how or what, but it seems it always takes up only the bottom half of the window. 3) When a view is split, the info bar (for example when doing a print preview of a relatively large file) is positioned at the bottom of the window instead of at the top. 4) Switching tabs (and thus focus) with the mouse and then switching back to a splitted view gives focus to the wrong view. 5) Split view doesn't work very nicely together with completion stuff (try doing a word completion in a splitted view) Also got some warnings in the console: ** (gedit:6300): WARNING **: Modeline handlers not found (gedit:6300): GLib-GIO-CRITICAL **: No GSettings bind handler for type "s". ** (gedit:6300): CRITICAL **: _gedit_cmd_documents_move_to_new_window: assertion `gtk_notebook_get_n_pages (GTK_NOTEBOOK (old_notebook)) > 1' failed ** (gedit:6300): CRITICAL **: _gedit_cmd_documents_move_to_new_window: assertion `gtk_notebook_get_n_pages (GTK_NOTEBOOK (old_notebook)) > 1' failed
Created attachment 164301 [details] [review] splitview v3 Fixes points 2,3,4. Point 1 has a patch for GBinding.
the warnings you got should be fixed in master.
Created attachment 164633 [details] [review] splitview v4 Fixes point 1 and last point.
Created attachment 164969 [details] [review] splitview v5 Different approach to sync the internals of the doc. Use a semi-public and a sync-docs signals emitted when the docs need sync. This was already discussed on irc.
Review of attachment 164969 [details] [review]: Some small comments about preliminary stuff... still need to review the big part (tab.c) Obviously I am not that thrilled about having a copy of the undo manager, though I am not sure how to solve it better ::: gedit/gedit-document.c @@ +175,3 @@ SAVED, SEARCH_HIGHLIGHT_UPDATED, + SYNC_DOCS, maybe sync-documents? @@ +415,3 @@ { case PROP_LOCATION: + { this looks like a bugfix for master @@ +729,2 @@ document_signals[SEARCH_HIGHLIGHT_UPDATED] = + g_signal_new ("search_highlight_updated", white space fixes? let's get them on master, also change signal to use - insetad of _ @@ +738,3 @@ GTK_TYPE_TEXT_ITER | G_SIGNAL_TYPE_STATIC_SCOPE, GTK_TYPE_TEXT_ITER | G_SIGNAL_TYPE_STATIC_SCOPE); let's add a comment explaining what it is for and saying that it is private ::: gedit/gedit-document.h @@ +177,3 @@ GtkTextIter *end); + + void (* sync_docs) (GeditDocument *document); This is a priv signal, and we should not expose it in the vtable ::: gedit/gedit-tab.h @@ +97,3 @@ + GeditView *new_view); + + void (* drop_uris) (GeditView *view, Can we extract this refactoring and commit to master? ::: gedit/gedit-window.c @@ +2656,2 @@ static void +update_statusbar (GeditWindow *window, If it is not too much burden I'd like this refactoring to be committed on master
Created attachment 165299 [details] [review] splitview v6 The things you wanted factored are already in master and I changed what you commented. The patch is rebased against master.
Created attachment 165605 [details] [review] splitview v7 I guess some minor changes in relation to the previous patch.
Created attachment 165606 [details] [review] splitview factor v1 Factor the splitview into a view-holder and view-frame
Created attachment 165611 [details] [review] splitview squashed v1 squashed version of the 2 previous patches.
About the undo manager: Currently the reason for having a copy of the undo manager is the buffer property being construct only instead of construct, which would be easy to fix. And the second reason is: http://git.gnome.org/browse/gtksourceview/tree/gtksourceview/gtksourceundomanagerdefault.c#n240 For splitview views we can't clear the undo manager when changing the buffers, so either we have 2 solution (at least for what we discussed) * having a clear_undo in the iface: This leads us to several problems like, if the buffers are different and you set them without clearing the undo manager, a crash will appear. * exposing the default undo manager and having a set_buffer overridable, the problem of this is exposing the undo manager which would be a problem in case in a future the undo stuff appears in gtk+. Also we would have to subclass it.
What is the status of this feature ?
This seems to be partially implemented as of 3.4.1 ( if chosen is really Idea 1 here: https://live.gnome.org/Gedit/Multiviews ). Tab groups are there. Split views are not.
While gedit may not be intended as a code editor, some of us use it that way. I was spoiled by Sun's textedit which supported this feature. It was extremely handy to be able to see 2-3 things at the same time (variable declaration, header to a method being called, and calling code is a great example). With my workspace set to follow cursor (not click to type) - I could make changes in any "window" (undo rules would be for the file not the window). This feature is spectacular for code and is also valuable for long files. Sorry that I have 3.2.6 and looking forward to seeing what has been done.
*** Bug 674568 has been marked as a duplicate of this bug. ***
I would like to start working on this, if no one did start yet. Would following the path described in https://wiki.gnome.org/Apps/Gedit/Multiviews work for the maintainers (both gedit and gtksourceview)?
The first thing to do is to better support split view in GtkTextView. I suggest that you start with an easier task, like fixing a bug, or adding an easier feature.
You can limit yourself to TWO views with a split view. I was spoiled by Sun's textedit. The number of view ports was not limited (except by screen space). I found having 3 ports normal, 4 occasionally. e.g view 1: data typedef; 2: sub-routine; 3: main routine. This was a great help to me in development but even 2 ports makes life easier. Gedit's multi side-by-side port (one gedit session, multiple files open) can be confusing if you close the window (while looking somewhere else) as ONLY the current file name appears in the toolbar. Having 5-10 development files in their own process open with 2-3 ports in each was super for me. If you can see textedit on a Sun - I would recommend looking as it is a good implementation.
*** Bug 336710 has been marked as a duplicate of this bug. ***
Mass-closing of all gedit bugzilla tickets. Special "code" to find again all those gedit bugzilla tickets that were open before the mass-closing: 2bfe1b0590a78457e1f1a6a90fb975f5878cb60064ccfe1d7db76ca0da52f0f3 By searching the above sha256sum in bugzilla, the gedit contributors can find again the tickets. We may be interested to do so when we work on a specific area of the code, to at least know the known problems and possible enhancements. We do this mass-closing because bugzilla.gnome.org is being replaced by gitlab.gnome.org.