help-gnu-emacs
[Top][All Lists]
Advanced

[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: address@hidden
> Subject: Re: Want split-window-vertically to split *vertically*
> 
> "Ludwig, Mark" <address@hidden> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]