unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
Subject: RE: Buffer listing in multiple frames/ttys
Date: Wed, 7 Dec 2005 16:03:17 -0800	[thread overview]
Message-ID: <DNEMKBNJBGPAOPIJOOICGENNCPAA.drew.adams@oracle.com> (raw)
In-Reply-To: <87r78ooe3s.fsf@jurta.org>

    > I'd repeat, though, that it would make sense for the default
    > value of the option to come from the value of pop-up-frames:
    >
    >         I still believe that most people who use
    >         pop-up-frames = t will want to set this option
    >         to nil (so, they would prefer that that
    >         behavior be the default for non-nil pop-up-frames),
    >         but I don't
    >         mind setting the option to get the old behavior.
    >
    > That way, people who use one-buffer-per-frame-by-default
    > would not need to change anything, beyond setting
    > pop-up-frames = t. I think that covers most
    > (but not all) people who set pop-up-frames = t.

    I still don't understand the need for a new option for
    one-buffer-per-frame
    configuration.  When a new frame is created due to pop-up-frames=t, its
    frame-local buffer-list contains exactly one buffer which is the current
    buffer.  So (buffer-list) is an exact equivalent of (buffer-list t).

I have trouble following this thread, because there are apparently multiple
changes being made now, some of which are bug fixes. The original discussion
that interested me concerned the problem of using the frame-local buffer
list, instead of the global list, for Buffer Menu. One bug involved
inappropriate additions to a frame's local buffer list. I don't know if
fixing that bug takes care of my concern or not - frankly, I'm a bit lost
now.

I believe that Karoly is on top of it all, however. He understands my
original concern, so I'm sure he'll DTRT wrt pop-up-frames. I'm OK with
whatever is done to take my original concern into account. IOW, I don't care
if there is a new option to take care of it, or a bug fix, or whatever it
takes. I just don't want the order of the buffers in the Buffer Menu to
change drastically, depending on which buffer (frame) I call it from. I
would like to be able to treat the Buffer Menu's chronological sort as a
global ordering, which ignores the frame residence of buffers altogether.

WRT one-buffer-per-frame: I mentioned one-buffer-per-frame-_by-default_. I
do change buffers in a given frame, so the local buffer list does change.
The behavior I described is generally one buffer _at a time_ per frame (but
I do occasionally use more than one window (buffer) at a time). In any case,
I never care about the different chronological buffer orderings in different
frames.

  reply	other threads:[~2005-12-08  0:03 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-24 20:25 Buffer listing in multiple frames/ttys Len Trigg
2005-11-24 21:44 ` Károly Lőrentey
2005-11-28 14:37   ` Lőrentey Károly
2005-11-28 17:16     ` Drew Adams
2005-11-28 18:24       ` Lőrentey Károly
2005-11-28 19:23         ` Drew Adams
2005-11-28 20:48           ` Lőrentey Károly
2005-11-28 23:12             ` Drew Adams
2005-11-29  0:15               ` Luc Teirlinck
2005-11-29  0:29                 ` Drew Adams
2005-11-29 10:45               ` Lőrentey Károly
2005-11-29 15:36                 ` Drew Adams
2005-11-29 18:43                   ` Luc Teirlinck
2005-11-29 19:24                     ` Drew Adams
2005-11-30 13:21                   ` Lőrentey Károly
2005-11-29 18:12                 ` Luc Teirlinck
2005-11-29 23:35                 ` Luc Teirlinck
2005-11-29 23:55                   ` Chong Yidong
2005-11-29 23:57                     ` Chong Yidong
2005-11-30  0:20                   ` Drew Adams
2005-12-02 21:09       ` Juri Linkov
2005-12-03 15:58         ` Richard M. Stallman
2005-12-03 17:03         ` Lőrentey Károly
2005-12-03 17:46           ` Juri Linkov
2005-12-04 21:18             ` Richard M. Stallman
2005-12-04 21:56               ` Juri Linkov
2005-12-05  4:33                 ` Eli Zaretskii
2005-12-05  6:03                   ` Juri Linkov
2005-12-05 16:38                 ` Richard M. Stallman
2005-12-05 14:44             ` Károly Lőrentey
2005-12-05 21:32               ` Juri Linkov
2005-12-06 16:42                 ` Richard M. Stallman
2005-12-06  1:43               ` Richard M. Stallman
2005-12-06 12:44                 ` Károly Lőrentey
2005-12-07  0:52                   ` Juri Linkov
2005-12-07 14:51                     ` Károly Lőrentey
2005-12-07 21:29                       ` Juri Linkov
2005-12-08  7:48                       ` Juri Linkov
2005-12-08 14:26                         ` Lőrentey Károly
2005-12-08 19:29                       ` Richard M. Stallman
2005-12-08 21:56                         ` Juri Linkov
2005-12-09 15:04                           ` Richard M. Stallman
2005-12-09 20:04                             ` Lőrentey Károly
2005-12-09 23:54                               ` Juri Linkov
2005-12-10 16:18                                 ` Richard M. Stallman
2005-12-11  0:54                                   ` Juri Linkov
2005-12-11 16:49                                     ` Richard M. Stallman
2005-12-11 16:57                                   ` Károly Lőrentey
2005-12-11 16:53                             ` Károly Lőrentey
2005-12-11 22:57                               ` Richard M. Stallman
2005-12-12 12:56                                 ` Károly Lőrentey
2005-12-12  7:43                               ` Juri Linkov
2005-12-07 17:07                   ` Richard M. Stallman
2005-12-07 17:15                     ` Károly Lőrentey
2005-12-08  4:53                       ` Richard M. Stallman
2005-12-06 16:20               ` Drew Adams
2005-12-06 18:09                 ` Lőrentey Károly
2005-12-07 16:54                   ` Drew Adams
2005-12-07 21:29                     ` Juri Linkov
2005-12-08  0:03                       ` Drew Adams [this message]
     [not found] <lorentey.g.e.devel.87hd9uff0k.elte@walrus.fnord.hu>
2005-11-30 16:33 ` Drew Adams

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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=DNEMKBNJBGPAOPIJOOICGENNCPAA.drew.adams@oracle.com \
    --to=drew.adams@oracle.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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).