all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Thibaut Verron <thibaut.verron@gmail.com>
Cc: emacs-devel@gnu.org
Subject: Re: Use of dedicated windows in gdb-mi.el
Date: Mon, 09 Feb 2015 17:44:33 +0200	[thread overview]
Message-ID: <83fvaf9jj2.fsf@gnu.org> (raw)
In-Reply-To: <loom.20150209T101105-678@post.gmane.org>

> From: Thibaut Verron <thibaut.verron@gmail.com>
> Date: Mon, 9 Feb 2015 09:19:48 +0000 (UTC)
> 
> > > From: Oleh Krehel <ohwoeowho <at> gmail.com>
> > > Cc: emacs-devel <at> gnu.org
> > > Date: Fri, 06 Feb 2015 20:14:40 +0100
> > > 
> > > 1. `gdb' a C++ program
> > > 2. `gdb-many-windows'
> > > 3. switch to "*input/output of main*"
> > > 4. issue `ido-switch-buffer`
> > > 
> > > => the buffer is switched in the "main.cc" window, although the point was 
> in the
> > > "*input/output of main*" window. I'm guessing that's because
> > > "*input/output of main*" is dedicated. In fact, all of them are, except
> > > the two that I actually want to see always: "main.cc" and "*gud-main*".
> > 
> > I suggest calling ido-switch-buffer in another frame.

> From what I understand, this work-around is an illustration of the point, 
> rather than a solution:

It depends on your POV, I guess.

> when someone presses C-x b, they want to change the buffer displayed
> in the current window. They do not want to have to switch to another
> window/frame before that, and they do not want to see the desired
> buffer appear in a random window.

The dedicated windows are an explicit _feature_ of GDB-MI.  GDB-MI
attempts to provide a faithful emulation of an IDE-like debugging
environment, where the source is browsed and edited in the source
window, I/O is in the input-output window, registers and breakpoints
in their specialized windows, etc.  What you describe above is the
consequence of that feature.

If you don't like this fixed arrangement of dedicated windows, then
why are you using GDB-MI?  Simply either turn off "the other" windows,
or don't turn them on in the first place (they are disabled by
default).  Then you will have full freedom of selecting which buffer
gets displayed in what window, as usual in Emacs.

My suggestion to use another frame was meant to give you the best of
all worlds -- the ability to switch to any buffer you like without
losing the IDE-like behavior of GDB-MI.  I don't really understand the
nature of your objection to it: doesn't it resolve the dilemma?

IOW, I don't understand why would anyone want GDB-MI, but without its
predefined arrangement of windows.  If we lift the dedicated windows
limitation, Emacs will pop the GDB-MI buffers all over the place, as
you well know.  Why does it make sense to "hunt" for a certain GDB-MI
buffer, like the call-stack buffer, when you can't even remember its
name easily?

Can you explain the motivation, and also why using GDB without the
other windows is not an option?



  parent reply	other threads:[~2015-02-09 15:44 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-06 18:02 Use of dedicated windows in gdb-mi.el Oleh Krehel
2015-02-06 19:07 ` Eli Zaretskii
2015-02-06 19:14   ` Oleh Krehel
2015-02-06 21:33     ` Eli Zaretskii
2015-02-09  9:19       ` Thibaut Verron
2015-02-09 14:29         ` Stefan Monnier
2015-02-09 14:50           ` Oleh Krehel
2015-02-09 15:51           ` Eli Zaretskii
2015-02-09 18:42           ` martin rudalics
2015-02-09 15:44         ` Eli Zaretskii [this message]
2015-02-09 15:57           ` Oleh Krehel
2015-02-09 17:05             ` Eli Zaretskii
2015-02-09 17:22               ` Oleh Krehel
2015-02-09 17:56                 ` Eli Zaretskii
2015-02-09 18:11                   ` Oleh Krehel
2015-02-09 18:26                     ` Drew Adams
2015-02-09 18:39                       ` Oleh Krehel
2015-02-09 18:56                         ` Eli Zaretskii
2015-02-09 19:48                           ` Oleh Krehel
2015-02-09 20:00                             ` Eli Zaretskii
2015-02-09 19:44                         ` Drew Adams
2015-02-09 19:50                           ` Oleh Krehel
2015-02-09 20:01                             ` Eli Zaretskii
2015-02-09 20:09                               ` Oleh Krehel
2015-02-09 20:27                                 ` Eli Zaretskii
2015-02-09 20:33                                   ` Oleh Krehel
2015-02-09 20:44                                     ` Eli Zaretskii
2015-02-09 20:46                                       ` Oleh Krehel
2015-02-10 15:42                                         ` Eli Zaretskii
2015-02-10  2:20                             ` Stefan Monnier
2015-02-10  3:48                               ` Eli Zaretskii
2015-02-10  6:39                                 ` Oleh Krehel
2015-02-10 15:54                                   ` Eli Zaretskii
2015-02-09 18:52                     ` Eli Zaretskii
2015-02-09 18:53                       ` Oleh Krehel
2015-02-09 18:58                       ` Oleh Krehel
2015-02-09 19:20                         ` Eli Zaretskii
2015-02-09 19:47                           ` Oleh Krehel
     [not found]                   ` <<8761bb9cq8.fsf@gmail.com>
     [not found]                     ` <<83zj8m9atc.fsf@gnu.org>
2015-02-09 20:42                       ` Drew Adams
  -- strict thread matches above, loose matches on Subject: below --
2015-02-24 17:56 Glenn Brown
2015-02-24 18:02 ` Oleh Krehel
2015-02-24 18:31 ` Eli Zaretskii
2015-02-24 22:23   ` Paul Eggert
2015-02-25  3:46     ` Eli Zaretskii
2015-02-25  3:57     ` Stefan Monnier
2015-02-25  6:09       ` Glenn Brown
2015-02-10  0:49 Barry OReilly
2015-02-10 16:05 ` Eli Zaretskii
     [not found] <<87h9uynckc.fsf@gmail.com>

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83fvaf9jj2.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=thibaut.verron@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.