Re: xref and displaying locations in appropriate window or frame

[martin rudalics]

>>>    ------------
>>> |   O |   X  |
>>> |     |------|
>>> |     |      |
>>> |     |   T  |
>>>    ------------
>
>> This is no good layout for IDEs.  Source/code windows like O and T
>> should always form a rectangle.  Auxiliary windows like X should be
>> arranged around that rectangle.
>
> FWIW, I love the overall direction of extending Emacs' IDE-related
> facilities, *but* I do not think that it should strive to emulate all
> their behavior, particularly not in this respect.  AFAICT, you have not
> given any argument for *why* these should be guidelines for a window
> layout, except that IDEs do it that way.

I'm no expert in IDEs, I don't use them and I don't advocate their
concepts.  So I'm certainly not qualified to give you an adequate
response.  Anyway.

Years ago proposals were made how to turn Emacs into an IDE.  You will
find a remnant in the

  Perspectives work well even if you do the equivalent of C-x 4 C-f
  because of the distinction between view windows vs file windows.  In
  Emacs this is more or less the "dedicated window" feature, but we have
  never really made it work for this.

entry of etc/TODO.  Now first we have to agree that in our example above
O and T behave as "file windows" and X is a "view window".  ECB calls
view windows "informational windows".  Emacs-IDE IIUC calls file windows
"source window" and subdivides view windows into "menu windows" and
"output windows".  I'm not sure whether X would classify as a menu or
output window, maybe it's both.  In any case X is not a source window.

Keeping file and view windows in a way that file windows form an inner
rectangular area and view windows are arranged around that area has the
following advantages:

- View windows can be easily made persistent (which is what the current
  thread is about).  Creating a file window does not remove them.
  Displaying a buffer in an existing file window does not affect them.

- View windows can be arranged in a predictable way so that the user
  always finds them in a specified part of the frame.  Compare this with
  the placement of X in the horizontal and vertical variations of our
  example.

- Most IDEs implicitly dedicate view windows to their buffers.  So we
  would not have to worry about how to do that with our X window.

- Orthogonally to the before, view windows can be shared by different
  but related buffers in a predictable way.  This means that you can
  switch view windows' buffers en bloc when switching, for example, from
  editing to debugging mode and back.

- It's easy to switch from a navigational mode where you show view
  windows, to an editing mode where you expand the file windows area to
  fill the entire frame and back.  Try that with the layout on the top
  of this reply or your layout below.

- View windows can be easily arranged according to their orientation:
  Vertically oriented windows (like the speedbar, browsers for files,
  buffers, tags and bookmarks) on the left or right, horizontally
  oriented ones (like compilation output or the eshell window) at the
  top or bottom.  This minimizes space and is the reason why I asked
  about the orientation of the *xref* window.

- If you have at most one view window on each side of a frame, you can
  easily fit them to their buffers to additionally minimze space.
  Fitting windows in the file windows area is much more tricky and may
  have unwanted side-effects.

> I regularly curse at the braindead window management of any IDE I have
> had to work with so far.  Emacs shines in the flexibility with which I
> can use all its features the way *I* want, and with the window layout I
> deem suitable.  And for me, that's literally *never* a rectangular area
> for source files.  In the above example, I find the displayed window
> layout not only acceptable, but perfectly fine, just like
>   ------------
> |   T |   X  |
> |     |------|
> |     |      |
> |     |   O  |
>   ------------
> would be fine for me (not as a result of the described workflow, but as
> a layout resulting from any kind of workflow).

Just that such layout is quite tricky to set up.  You have to

(setq X (split-window O nil 'above))

followed by

(setq T (split-window (window-parent O) nil 'left))

Most Emacs developers wouldn't even know that such a possibility exist.

> I think that it would be more useful if the present elaborate window
> management would become more accessible (maybe it's only a matter of
> documentation and a few variable settings) to fix a certain layout (or
> layout-related guidelines like you described) *should the user want
> that*.  Wouldn't this eliminate most of the need to code such decisions
> into very general features like xref?

Personally, I prefer chaos.  So I usually split the selected window to
display a buffer and when my frame is crowded by too many small windows
I kill them off in one rush.  I certainly would not recommed this
practice to anyone.  So all I can do is to refer to layout decisions
that have been made and tested elsewhere.

martin