From: MBR <mbr@arlsoft.com>
To: suvayu ali <fatkasuvayu+linux@gmail.com>
Cc: help-gnu-emacs@gnu.org
Subject: Re: Annoying change in "other window" behavior
Date: Tue, 23 Aug 2011 12:14:33 -0400 [thread overview]
Message-ID: <4E53D1E9.9020403@arlsoft.com> (raw)
In-Reply-To: <CAMXnza2EC19Nnu33=Y1qPK-y7kThWFZh1phfAaXskK=bUw8igg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1796 bytes --]
On 8/23/2011 4:26 AM, suvayu ali wrote:
> In any case these commands have always used the other-window. I will
> have to say you either had some special configuration which is not
> working with Emacs 23 or you remember incorrectly.
>
> I just tested this with Emacs 21.4.1.
>
I'm sure I'm not remembering incorrectly because I still have both
installations. I recently installed Ubuntu in a separate partition on
my laptop. Emacs 21.3.1 runs when I boot Windows XP, and Emacs 23.2.1
runs when I boot Ubuntu. The behavior differences I'm describing should
all be implemented in Lisp, and should therefore not depend in any way
on the OS under which Emacs is running.
I did discover something more about 23.2.1's behavior after I posted.
It seems the behavior depends on the width of the top-level window (what
Emacs calls a "frame"). If I have two vertically-stacked Emacs windows
in a small Emacs frame and type C-x C-b, *Buffer List* is displayed in
the other pre-existing Emacs window. But if I have the same two
vertically-stacked Emacs windows in a large Emacs frame (I frequently
work with one Emacs frame maximized) when I type C-x C-b, instead of
displaying *Buffer List* in the other pre-existing Emacs window, it
behaves as if I'd run M-x split-window-horizontally before running M-x
list-buffers.
Just to be sure, I double-checked 21.3.1's behavior (i.e. the old
version), and it doesn't do this. Unless it's starting with only one
Emacs window and has no choice but to split it into two, it always
reuses a pre-existing Emacs window.
So, there can be no doubt that somebody added a new feature that makes
this window-splitting behavior dependent on the width of the frame,
which it never used to be. I'd really like to turn this feature off.
Mark
[-- Attachment #2: Type: text/html, Size: 2397 bytes --]
next prev parent reply other threads:[~2011-08-23 16:14 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-23 6:55 Annoying change in "other window" behavior MBR
2011-08-23 8:26 ` suvayu ali
2011-08-23 16:14 ` MBR [this message]
2011-08-23 8:30 ` suvayu ali
2011-08-23 11:34 ` Bernardo
2011-08-23 16:34 ` MBR
[not found] ` <mailman.1818.1314117273.939.help-gnu-emacs@gnu.org>
2011-08-24 5:51 ` Jason Rumney
2011-08-24 16:11 ` MBR
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=4E53D1E9.9020403@arlsoft.com \
--to=mbr@arlsoft.com \
--cc=fatkasuvayu+linux@gmail.com \
--cc=help-gnu-emacs@gnu.org \
/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.
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).