Re: {Spam?} Window/buffer management in gdb-ui

[Stefan Monnier]

>> - messes up the namespace

> I know that standard practice is to prefix such functions, in general, with
> gdb but this isn't really a gdb-related function. I felt that the occasional
> violation i.e one for the whole of gdb-ui.el, would not cause a problem, in
> practice, and may help prevent duplication with locally defined functions
> performing the same task.

No, that's not how it works.  You should define it as gdb-<something> and/or
lobby on emacs-devel to add it to some global file like subr.el.

>> - it changes the currently selected window and makes it dedicated
>> (because we know that (get-buffer-window (switch-to-buffer name))
>> is always equal to (selected-window))

> Its only used when gdb-ui sets up/restores the windows.

Hmm... I don't understand.
First, there's the problem of using get-buffer-window instead of
selected-window (maybe it's not a problem, but I find to be confusing).
Then there's the problem of using switch-to-buffer which forcefully hides
the previously displayed buffer.  And finally there's the problem of marking
as dedicated a window that already existed as non-dedicated (and had thus
a different purpose).

Are you telling me that you always know for sure that the buffer previously
displayed is of no interest to the user and can safely be hidden and the
window can of course be reused?  Is it because the window was just created
(and thus displays a random buffer)?

>> I understand that maybe my setup is not representative, but maybe if you
>> could describe what behavior you're trying to get, I can help you come up
>> with a way to code it that doesn't plays nicely in my situation.
>> 
>> I.e. what is the behavior you're trying to get.  You can describe it with
>> a mix of description of how *you* want it plus some examples of problematic
>> behaviors you'd like to avoid (i.e. bug-reports).

> I noticed two things. Firstly, when the user displays a gdb-related buffer in
> another window (M-x gdb-display-BUFFERTYPE-buffer or from the menubar,
GUD-> GDB-Windows->...) it can replace an existing buffer that the user wants
> to remain visible. These changes ensure that, in this case, a gdb-related
> buffer is split to provide space for the new buffer. Secondly, if the user
> wants to do something different in between debugging, visit info or list
> buffers, for example, it is best for that buffer to appear in a separate
> frame.

> Its a `work in progress', I haven't thought it through yet. Since the "feature
> freeze" could extend to infinity, I figured I'd have enough time to put it
> right. Also, as its been quiet recently, I thought maybe everyone was using
> "-fullname". I guess this is one way of finding out!

This assumes much too much already.  Please start from the beginning and
describe to me the behavior you (want to) see in general when you use
GDB-UI: where is displayed which buffer (both source buffers and GDB-UI's
own buffers), when, etc...

>> As for my own setup, I use 1 buffer per frame and 1 frame per buffer with
>> a separate dedicated minibuffer.  In my setup, any code that uses
>> `switch-to-buffer' is a pain in the rear.

> You never have split windows?

Very rarely.

> How do you arrange that?

(setq pop-up-frames t)

> What is a "separate dedicated minibuffer"?

A special frame (typically 1-line tall) that has no window other than
a mini-window that displays a minibuffer (i.e. the frame-parameter
`minibuffer' is set to `only').  The other frames have no
mini-window and use that special frame when they need an echo area or
a minibuffer (the frame-parameter `minibuffer' is set to nil).


        Stefan