GNU bug report logs - #5054
23.1.50; buffer-menu truncated fields

Previous Next

Full log

Message #67 received at 5054 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> jurta.org>
Cc: 5054 <at> debbugs.gnu.org
Subject: Re: bug#5054: 23.1.50; buffer-menu truncated fields
Date: Fri, 08 Jan 2010 09:18:46 +0100

> I see there is more serious problem.  With `emacs -Q' in a wide frame,
> `M-x man' displays the truncated page, because the default value of
> `Man-notify-method' is "friendly" (this is a subjective name and I think
> actually this option is not friendly at all!), and `man' runs the
> formatting command with the value of `COLUMNS' equal to the frame's width,
> but later `man' splits the frame horizontally and displays in a half-width
> window the manual formatted to the full frame width.  Perhaps `man' should
> be able to predict the window's width for `COLUMNS' before running the
> formatting command.  Do you know a function in window.el that would
> predict the width that the current window will have after splitting
> horizontally?

Conceptually `split-window-horizontally' when called with a non-nil SIZE
argument should either (1) produce two windows such that either the old
or the new one has this many columns, or (2) fail to split the window.
So all you have to do is to divide the current width of the window by 2
and eventually call `split-window-horizontally' with first argument (or
`split-window' with second argument) assigned the negative of the value
you calculated here.  Meanwhile you can use that precalculated value as
argument for the formatting process.

Does the weird behavior of `man' result from the fact that it doesn't
know what to display in the new window until formatting completes?

martin

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.