unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: martin rudalics <rudalics@gmx.at>
To: Doug Morgan <dougrm@sprynet.com>
Cc: 12380@debbugs.gnu.org
Subject: bug#12380: other window related commands broken
Date: Sun, 09 Sep 2012 12:05:50 +0200	[thread overview]
Message-ID: <504C69FE.7000208@gmx.at> (raw)
In-Reply-To: <504BF230.1000805@sprynet.com>

 > First, here is what the debugger says when I try to "Send Bug Report:..."
 > Debugger entered--Lisp error: (wrong-type-argument stringp nil)
 >   file-name-directory(nil)
 >   byte-code("\300\301\302\303\304!!\"\305BC\207" [format "hides
 > \\(%s.*\\)" file-name-directory locate-library "simple.el" (1
 > font-lock-warning-face)] 5)

I don't understand why it doesn't find this.  Does evaluating

(locate-library "simple.el")

always fail on your system?  If so, what is your value of the variable
`load-path'?

 > I did exactly flip my usage of vertical and
 > horizontal splitting from the emacs usage of the term.  I should have
 > said "One of the windows **splits horizontally**(!!) ".

The terms vertically/horizontally have caused lots of confusion in the
past and meanwhile should have been elided from all references to window
splitting.

 > In any case the
 > bad split is into two side-by-side windows. The to-my-taste poor
 > splitting happens when (window-total-width) >= 164.

I see.

 > The problem is fixed by setting split-width-threshold to 500.

nil should be more intuitive.

 > I did try setting it to nil as the variable's documentation
 > suggests and the customization dialog told me the value of the variable
 > needed to be an integer.  Don't know if it accepted nil anyway or
 > rejected it or what, but 500 sure works. Thanks again.

In the dialog you are not allowed to insert nil in the field reserved
for numbers.  You should use the "Value Menu" button and select "nil"
from the choices presented there.  Please try again.

 > I do think split-width-threshold should default to never splitting
 > horizontally (I've got the right word this time), but that's just
 > decades of never have wide windows automatically split horizontally
 > talking.  Maybe it will seem perfectly natural to someone not shocked to
 > see it.

IIRC we made it an integer (albeit a large one) to make people notice
that they can use it.  I can't judge whether that was a good idea.

 > On second thought, I wouldn't so much mind emacs splitting a window
 > horizontally when I just have one window visible at the time.  That
 > might actually be nice.  However, when I already have my screen split in
 > two, but vertically, I think it's a bad idea without redeeming qualities
 > to split one of the windows horizontally instead of just jumping to the
 > "other" already open window.

But that's why `split-width-threshold' is customizable.  More
experienced users can write their own `split-window-sensibly'
substitutes which gives them lots of additional possibilites.

 > So, I'm changing my bug report to say that emacs should never
 > automatically introduce any new split for M-x M-b (and similar commands)
 > when it already has two or more open windows (regardless of how they are
 > arranged).  The problem is just a bit deeper than simply changing the
 > value of split-width-threshold.

Maybe someone has a good idea on how to improve this.

martin





  reply	other threads:[~2012-09-09 10:05 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-07 18:58 bug#12380: other window related commands broken Doug Morgan
2012-09-07 20:26 ` martin rudalics
2012-09-07 22:16   ` Doug Morgan
2012-09-08  1:00     ` Ken Brown
2012-09-08  8:18     ` martin rudalics
2012-09-09  1:34       ` Doug Morgan
2012-09-09 10:05         ` martin rudalics [this message]
2012-09-09 13:45           ` Ken Brown
2012-09-10  8:39             ` martin rudalics
2012-09-10 14:10               ` Ken Brown
2012-09-09 21:19           ` Doug Morgan
2022-02-13  9:30 ` bug#12380: more control over window splitting Lars Ingebrigtsen
2022-03-14 10:34   ` Lars Ingebrigtsen

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=504C69FE.7000208@gmx.at \
    --to=rudalics@gmx.at \
    --cc=12380@debbugs.gnu.org \
    --cc=dougrm@sprynet.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).