[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Want split-window-vertically to split *vertically*
From: |
Ludwig, Mark |
Subject: |
RE: Want split-window-vertically to split *vertically* |
Date: |
Mon, 14 Nov 2011 14:51:32 +0000 |
> From: Tassilo Horn
> Sent: Monday, November 14, 2011 8:27 AM
> To: help-gnu-emacs@gnu.org
> Subject: Re: Want split-window-vertically to split *vertically*
>
> "Ludwig, Mark" <ludwig.mark@siemens.com> writes:
>
> Hi Mark,
>
> > I am using Emacs 23.3.1 and want to know how to make
> > split-window-vertically do as documented: split *vertically* no matter
> > how wide the frame is. There clearly is logic that decides to split
> > *horizontally* when the frame is relatively wide. Why does C-x 2 act
> > this way when the other behavior is available (normally) on C-x 3?
>
> C-x 2 and C-x 3 should always do what their name suggests, except when
> such a split would create a window that's smaller than window-min-height
> / window-min-width. But even in that case, I don't get a different
> split but a message is shown telling me that the window is too small to
> be split. (However, I'm testing with emacs 24, but I would be suprised
> if emacs 23.3.1 was that much different.)
>
> Anyway, can you give a recipe for reproducing that wrong split starting
> with "emacs -Q"?
Hi Tassilo,
Thanks for responding. I don't have any .emacs file in this environment
(painful for someone accustomed to lots of custom things, but so far superior
to notepad or wordpad...).
I could have sworn that I tried C-x 2 and it split horizontally, but now I
can't reproduce that (with or without -Q).
Anyway, it turns out that my complaint is with the behavior of
list-matching-lines. It decides to put the *Occur* buffer side-by-side on wide
frames. I reflexively fix that with C-x 0, but then pressing RET on top of an
occurrence invokes occur-mode-goto-occurrence that also decides to split wide
frames horizontally. Neither function documents any way to influence this
behavior. Is there a way?
This has the feel of something someone considered an enhancement, and when I'm
working with source files (usually still in the form of 80-byte-wide punch
cards), I kinda like it too. I think what I'm looking for is smarter logic
that senses the width of the content versus the width of the resulting
window....
Thanks,
Mark