Community
Participate
Working Groups
I like to divide the editor area into side-by-side 80 column editor panels. When I do a file compare, it comes up in an editor pane in either the left or right side. Since there isn't enough width to show the full width of both files in the comparison editor, I find I either need to temporarily make the comparison panel larger by hand and revert it after I am done comparing or else move the comparison editor panel to take up the top or bottom of the editor area. This can be annoying when I want to look at diffs for many files and so I usually resort to using external diff tools in that case. I wish that there was some way to automatically get a wider view for diffs. I could imagine this could be accomplished a number of different ways including: - providing a way to make an editor panel temporarily take up the entire editor area - providing commands to move an editor panel to take up the full width of the top or bottom of the editor area - put text compare (optionally) in its own view outside the editor area Ideally, I would like there to be some way for the text compare results to take up the entire editor area space while it is up and for the editor area to go back to its previous state when the comparison view is closed.
(In reply to comment #0) > - providing a way to make an editor panel temporarily take up the entire editor > area > - providing commands to move an editor panel to take up the full width of the > top or bottom of the editor area > - put text compare (optionally) in its own view outside the editor area There is a keyboard shortcut for maximizing current editor or view, it's Ctrl + M. Personally, I find it quite useful. Have you tried it?
Ctrl-M is not useful in this scenario because it maximizes the entire editor area without changing the layout of subpanels, and in my use case the editor area is already maximized horizontally but divided into side-by-side editor panels. Given my monitor set-up with the monitor taller than wide, I have only enough room for about 90 columns per panel when maximized and that is not enough to view comparison results without having to scroll.
Enough said, I think I get it. In my opinion this is more a question we should ask the UI team. I found a similar request already there, see bug 111958. I think it's up to you Christopher, whether to mark this one as a duplicate, move it to the UI or open a new one.
I think this is a distinct from bug 111958 since a solution for one may not work for the other. However, it obviously makes sense to consider both requests in choosing a solution. I'll move this to UI but does that imply a particular solution, i.e. a way to maximize an editor tab rather than giving compare its own view?
Support for 'internal' management (i.e. operations that take place -within- a sash container) have been under discussion for some time, specifically to address issues such as this one. The best idea so far is to possibly adorn the actual sash splitter with '<' and '>' buttons that force the sash all the way to the left/right.
So if I understand correctly: 1. You normally have the editor area split left-right with two sets of editor tabs visible at the same time (each 80 columns). 2. But when you compare, since its an editor, it shows up in either the left or the right. Since compare in effect is showing two things, you now see three things horizontally: one of your editor stacks (1/2), and the compare editor with a left and right content (1/4, 1/4). Those (1/4) spaces are too narrow to be useful. 3. Instead, you'd really like compare to take over the entire space in (1).
Yes, that is correct.
Thanks. Eric's comment #5 > The best idea so far is to possibly adorn the actual sash splitter with '<' and > '>' buttons that force the sash all the way to the left/right. would it seems address your suggestion in comment #0 > - providing a way to make an editor panel temporarily take up the entire editor > area We just don't have a good model right now for managing the space within an editor area. The split editor area is a bit of a hack. You'll notice there's only one min/max button for the two, so its not two editor stacks, its one area split in two. This is a great example though and the kind of problem we'd like to tackle in e4. That doesn't help you now though.
The '>' button would be little bit better than having to drag the sash. Of course, you would have to figure out what pressing the button means when the editor area is split more than once. Another option would be to have a command that would merge all of the editor tabs but remember the previous configuration so you can toggle back to it (as long as you don't split the editor area again in the meantime). You could then provide some way to register with each perspective whether the editor area should use the merged or split configuration.
To paraphrase...you want a command that effectively says 'Show only the active editor stack (hide any other editor stacks)' correct? One problem with the Editor Area management in general is that it's shared between perspectives; if I do this in one perspective and switch then it'd still be in that state in the newly opened perspective, OK?
Moving to triage...
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
