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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#5054: 23.1.50; buffer-menu truncated fields


From: martin rudalics
Subject: bug#5054: 23.1.50; buffer-menu truncated fields
Date: Fri, 08 Jan 2010 09:18:46 +0100
User-agent: Thunderbird 2.0.0.21 (Windows/20090302)

> 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






reply via email to

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