bug#9084: 24.0.50; displaying man pages splits the window and formats the text for the full width of the whole frame rather than for the width of the window the text is displayed in, which is only 1/2 the width of the frame

bug#9084: 24.0.50; displaying man pages splits the window and formats the text for the full width of the whole frame rather than for the width of the window the text is displayed in, which is only 1/2 the width of the frame

[lee]

Well, the lengthy subject pretty much says it :)  When I have an emacs
frame the size of the full screen (like 231 characters, 68 lines at
1920x1200 pixels) displaying a single window (buffer) and do "M-x man"
to display a manual page, emacs splits the window horizontally (as in
`split-window-horizontally`) and displays the manual page in one of the
windows within the frame.  That's great, only the man page is then
difficult to read because it's formatted for the width of the whole
frame (231 characters/line) and not for the width of the frame it is
displayed in.

Since emacs automatically splits the frame, wouldn't it make more sense
to format the manual page to the width of the frame it is displayed in
(unless the frame is unreasonably narrow)?  Lines that are 231
characters long aren't so nice for reading, anyway ...

When I first M-x split-window-horizontally and then M-x man, the manual
page is formatted for the width of the window it's displayed in.  So
this might be as simple as reversing the order in which things happen:
first splitting the frame automatically and then formatting the manual
page vs. formatting the manual page first and then splitting the frame.



In GNU Emacs 24.0.50.1 (x86_64-unknown-linux-gnu, X toolkit)
 of 2011-07-13 on yun
Windowing system distributor `The X.Org Foundation', version 11.0.11002000
configured using `configure  '--with-x-toolkit=lucid''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: de_DE.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Man

Minor modes in effect:
  desktop-save-mode: t
  shell-dirtrack-mode: t
  highlight-changes-visible-mode: t
  global-hl-line-mode: t
  show-paren-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  size-indication-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
r d SPC f o r SPC a n SPC e n t r y SPC t e l l i n 
g <backspace> <backspace> <backspace> <backspace> <backspace> 
<backspace> <backspace> <left> <left> <left> <left> 
<left> <left> <left> <backspace> <backspace> s o m 
e <end> <home> <up> f r o m SPC <escape> q <down> <down> 
<left> SPC s p e c i f y i n g SPC w h e t h e r SPC 
t o SPC t r <backspace> u r n SPC o n SPC N u , <backspace> 
m L o c k SPC o r SPC n o t SPC a n d SPC t u r n SPC 
i t SPC o n SPC o r SPC n o t SPC f r o m SPC h t <backspace> 
<backspace> t h e r e SPC . . . <right> <right> <left> 
<left> SPC SPC O r SPC y o u SPC c o u l d SPC m a 
k e SPC y o u r SPC o w n SPC s t a r t u p SPC s c 
r i p t SPC t h a t SPC c h e c k s SPC / e t c / d 
e f a u l t / k e y b o a r d SPC . . . <right> <right> 
<left> <right> <up> <return> <escape> x m a n <return> 
s e t l e d s <return> <C-tab> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <up> 
<left> <right> <f7> <escape> x e m a <tab> b u <tab> 
<tab> <backspace> <backspace> <backspace> <backspace> 
<backspace> <backspace> <backspace> <backspace> r e 
p o <tab> r <tab> <return>

Recent messages:
Note: file is write protected
Setting up indent for shell type sh
setting up indent stuff
Indentation variables are now local.
Indentation setup for shell type sh
Auto-saving...done
Invoking man setleds in the background
Please wait: formatting the setleds man page...
setleds man page formatted
Making completion list...

Load-path shadows:
None found.

Features:
(shadow emacsbug org-colview cal-move cal-iso conf-mode flow-fill
browse-url gnus-dup newcomment gnus-dired desktop org-wl org-w3m org-vm
org-rmail org-mhe org-mew org-irc org-jsinfo org-infojs org-html org-exp
ob-exp org-exp-blocks org-agenda org-info org-gnus org-docview
org-bibtex org-bbdb info gnus-eform skeleton sh-script executable
flyspell ispell bookmark multi-isearch tabify shell mule-util sort
smiley ansi-color gnus-cite gnus-async gnus-bcklg shadowfile ange-ftp
woman man speedbar sb-image ezimage dframe rst compile rcirc proced
hilit-chg hi-lock dired cwarn cc-mode cc-fonts cc-guess cc-menus cc-cmds
cc-styles cc-align cc-engine cc-vars cc-defs ebnf2ps ps-print ps-def lpr
cus-edit help-mode view debug qp gnus-ml nndraft nnmh nndoc nnmaildir
parse-time rot13 disp-table netrc gnutls network-stream auth-source
eieio assoc starttls tls nnfolder bbdb-gnus bbdb-snarf mail-extr
bbdb-com cl nnml gnus-agent gnus-srvr gnus-score score-mode nnvirtual
gnus-msg nntp gnus-cache gnus-diary gnus-art mm-uu mml2015 epg-config
mm-view mml-smime smime password-cache dig mailcap nndiary nnir gnus-sum
gnus-group gnus-undo nnmail mail-source nnoo gnus-start gnus-spec
gnus-int gnus-range message sendmail rfc822 mml mml-sec mm-decode
mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 ietf-drums
mailabbrev gmm-utils mailheader gnus-win gnus gnus-ems nnheader
gnus-util mail-utils mm-util mail-prsvr wid-edit jka-compr server
cal-china lunar solar cal-dst cal-bahai cal-islam cal-hebrew holidays
hol-loaddefs appt diary-lib diary-loaddefs remember org-remember
org-datetree org byte-opt warnings bytecomp byte-compile cconv macroexp
advice help-fns advice-preload ob-emacs-lisp ob-tangle ob-ref ob-lob
ob-table org-footnote org-src ob-comint comint ob-keys ob ob-eval
org-complete pcomplete org-list org-faces org-compat org-entities
org-macs noutline outline easy-mmode cal-menu easymenu calendar
cal-loaddefs ring erc-goodies erc erc-backend erc-compat format-spec
thingatpt pp bbdb-autoloads bbdb regexp-opt timezone hl-line saveplace
time-date paren cus-start cus-load boxquote rect tooltip ediff-hook
vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image
fringe lisp-mode register page menu-bar rfn-eshadow timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese hebrew greek romanian slovak czech european ethiopic
indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple
abbrev minibuffer loaddefs button faces cus-face files text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process dbusbind
dynamic-setting system-font-setting font-render-setting x-toolkit x
multi-tty emacs)

bug#9084: 24.0.50; displaying man pages splits the window and formats the text for the full width of the whole frame rather than for the width of the window the text is displayed in, which is only 1/2 the width of the frame

[Juri Linkov]

> So this might be as simple as reversing the order in which things happen:
> first splitting the frame automatically and then formatting the manual
> page vs. formatting the manual page first and then splitting the frame.

Such reversing the order is implemented in http://debbugs.gnu.org/5054
Maybe we should commit that now?

bug#9084: 24.0.50; displaying man pages splits the window and formats the text for the full width of the whole frame rather than for the width of the window the text is displayed in, which is only 1/2 the width of the frame

[martin rudalics]

>> So this might be as simple as reversing the order in which things happen:
>> first splitting the frame automatically and then formatting the manual
>> page vs. formatting the manual page first and then splitting the frame.
> 
> Such reversing the order is implemented in http://debbugs.gnu.org/5054
> Maybe we should commit that now?

Sounds reasonable, yes.

martin

bug#9084: 24.0.50; displaying man pages splits the window and formats the text for the full width of the whole frame rather than for the width of the window the text is displayed in, which is only 1/2 the width of the frame

[lee]

martin rudalics <rudalics@gmx.at> writes:

>>> So this might be as simple as reversing the order in which things happen:
>>> first splitting the frame automatically and then formatting the manual
>>> page vs. formatting the manual page first and then splitting the frame.
>>
>> Such reversing the order is implemented in http://debbugs.gnu.org/5054
>> Maybe we should commit that now?
>
> Sounds reasonable, yes.

When this is applied and the variable `Man-width' is set to some value,
like 75, will the width of the window to display the manpage in be
adjusted to the width of the text?  Just splitting the current window in
half when it is 230 characters wide gives you two windows each about 115
characters wide while you might rather want the window with the manpage
to be `Man-width' characters wide and the other window as wide as the
rest of the frame.

Then there's the documentation about `Man-frame-parameters':

,---- [ M-x describe-variable Man-frame-parameters ]
| Man-frame-parameters is a variable defined in `man.el'.
| Its value is nil
| 
| Documentation:
| Frame parameter list for creating a new frame for a manual page.
| 
| You can customize this variable.
| 
| [back]
`----

(I had to look at man.el to find out that I can set `Man-width'.)

And when you proceed to customise `Man-frame-parameters', you don't have
any idea what to enter to always get a frame that makes the window
`Man-width' characters wide.  Also, please note the terminology:

,---- [ info (emacs) Frames ]
| When using a graphical display, you can create multiple system-level
| "windows" in a single Emacs session.  We refer to these system-level
| windows as "frames".
`----

,---- [ info (emacs) Multiple Windows ]
| Emacs can split a frame into two or many windows.
`----

My understanding would be that `Man-frame-parameters' must be ignored
when running emacs on the console because there are only windows and no
frames available.

bug#9084: 24.0.50; displaying man pages splits the window and formats the text for the full width of the whole frame rather than for the width of the window the text is displayed in, which is only 1/2 the width of the frame

[Juri Linkov]

>>> So this might be as simple as reversing the order in which things happen:
>>> first splitting the frame automatically and then formatting the manual
>>> page vs. formatting the manual page first and then splitting the frame.
>>
>> Such reversing the order is implemented in http://debbugs.gnu.org/5054
>> Maybe we should commit that now?
>
> Sounds reasonable, yes.

At the moment I'm studying your recent window changes ;)

bug#9084: 24.0.50; displaying man pages splits the window and formats the text for the full width of the whole frame rather than for the width of the window the text is displayed in, which is only 1/2 the width of the frame

[Juri Linkov]

> When this is applied and the variable `Man-width' is set to some value,
> like 75, will the width of the window to display the manpage in be
> adjusted to the width of the text?

When you set `Man-width' to a positive integer, the manpage's text is
formatted to that width.  This variable doesn't affect the window's width.

> Just splitting the current window in half when it is 230 characters
> wide gives you two windows each about 115 characters wide while you
> might rather want the window with the manpage to be `Man-width'
> characters wide and the other window as wide as the rest of the frame.

But what if you have manpage buffers in both of horizontally split
side-by-side windows?

> Then there's the documentation about `Man-frame-parameters':
>
> ,---- [ M-x describe-variable Man-frame-parameters ]
[...]
> `----
>
> (I had to look at man.el to find out that I can set `Man-width'.)

Do you think `Man-width' should be mentioned in the docstring of `man'?

> And when you proceed to customise `Man-frame-parameters', you don't have
> any idea what to enter to always get a frame that makes the window
> `Man-width' characters wide.

Maybe the docstring of `Man-frame-parameters' should provide an example
of using the frame parameter `width'?

> My understanding would be that `Man-frame-parameters' must be ignored
> when running emacs on the console because there are only windows and no
> frames available.

`Man-frame-parameters' is ignored unless `Man-notify-method' is set
to the value `newframe'.  However, I don't know how the users
who prefer to set `pop-up-frames' to a non-nil value
specify the width of the manpage's frame
(when `Man-notify-method' is not `newframe')?

bug#9084: 24.0.50; displaying man pages splits the window and formats the text forthe full width of the whole frame rather than for the width ofthe window the text is displayed in, which is only 1/2 thewidth of the frame

[Drew Adams]

> `Man-frame-parameters' is ignored unless `Man-notify-method' is set
> to the value `newframe'.  However, I don't know how the users
> who prefer to set `pop-up-frames' to a non-nil value
> specify the width of the manpage's frame
> (when `Man-notify-method' is not `newframe')?

Dunno either what they all use, but:

* When `pop-up-frames' is non-nil, other-window commands etc. use another frame.
So a value such as the default `friendly' will anyway use another frame.

* Personally, I use non-nil `pop-up-frames' and `friendly' for
`Man-notify-method', and nil for `Man-frame-parameters'.  But I also
automatically fit the frame (fit-frame.el, autofit-frame.el).
`Man-frame-parameters' is not needed if you automatically fit the frame.

bug#9084: 24.0.50; displaying man pages splits the window and formats the text for the full width of the whole frame rather than for the width of the window the text is displayed in, which is only 1/2 the width of the frame

[lee]

Juri Linkov <juri@jurta.org> writes:

>> When this is applied and the variable `Man-width' is set to some value,
>> like 75, will the width of the window to display the manpage in be
>> adjusted to the width of the text?
>
> When you set `Man-width' to a positive integer, the manpage's text is
> formatted to that width.  This variable doesn't affect the window's width.

To me, it would make sense if it did or if I could make it so that it
does, for example by specifying a negative integer like -75 to have the
page formatted 75 characters wide /and/ the width of the window adjusted
accordingly.  Imho, there isn't much point in making the window wider
than the text it displays when viewing manpages.

>> Just splitting the current window in half when it is 230 characters
>> wide gives you two windows each about 115 characters wide while you
>> might rather want the window with the manpage to be `Man-width'
>> characters wide and the other window as wide as the rest of the frame.
>
> But what if you have manpage buffers in both of horizontally split
> side-by-side windows?

When your window is 230 characters wide, you could set Man-width to 70
and display three pages side by side?

>> Then there's the documentation about `Man-frame-parameters':
>>
>> ,---- [ M-x describe-variable Man-frame-parameters ]
> [...]
>> `----
>>
>> (I had to look at man.el to find out that I can set `Man-width'.)
>
> Do you think `Man-width' should be mentioned in the docstring of `man'?

Yes --- I have been searching through the info documentation of emacs
after reading in the other bug report that there is something like
"Man-width" and couldn't find it.  It seems you need to "M-x
describe-function man" to get at least some documentation about it.

Since there's the usual man command you run from a shell, it's not too
obvious that "M-x man" is something very different.

>> And when you proceed to customise `Man-frame-parameters', you don't have
>> any idea what to enter to always get a frame that makes the window
>> `Man-width' characters wide.
>
> Maybe the docstring of `Man-frame-parameters' should provide an example
> of using the frame parameter `width'?

That would be great :)  When you're more familiar with emacs,
you probably just know how to specify the frame parameters and don't
miss an example there.

>> My understanding would be that `Man-frame-parameters' must be ignored
>> when running emacs on the console because there are only windows and no
>> frames available.
>
> `Man-frame-parameters' is ignored unless `Man-notify-method' is set
> to the value `newframe'.  However, I don't know how the users
> who prefer to set `pop-up-frames' to a non-nil value
> specify the width of the manpage's frame
> (when `Man-notify-method' is not `newframe')?

That's a good question ...  And what do users do who aren't using
frames?

What I've been thinking about is that there is a fundamental difference
between frames and windows in that frames never change their size
automatically while windows change it all the time.  I wish there was a
way to "freeze" the window setup so that I could have a fixed window
setup within a frame or on the console. Within these "window-frames",
windows might change their sizes just as they do now.

Being able to freeze the window layout could have the side effect of
allowing users to specify `Man-window-parameters' ...

bug#9084: 24.0.50; displaying man pages splits the window and formats the text for the full width of the whole frame rather than for the width of the window the text is displayed in, which is only 1/2 the width of the frame

[Juri Linkov]

> To me, it would make sense if it did or if I could make it so that it
> does, for example by specifying a negative integer like -75 to have the
> page formatted 75 characters wide /and/ the width of the window adjusted
> accordingly.  Imho, there isn't much point in making the window wider
> than the text it displays when viewing manpages.

You are asking for functionality that is not specific to manpages.
Typical text width in all buffers that I see is no more than 75 characters:
in Dired buffers, in Info buffers, in source code buffers, etc.
Usually there is no point in making the window wider than the text
displayed in all these buffers.  I think the width of the window
and other parameters of window configurations should be specified
at more general level.

> When your window is 230 characters wide, you could set Man-width to 70
> and display three pages side by side?

There was a plan to implement functionality where you can define
arbitrary window layouts, e.g. you will be able to define a layout
to display three manpage dedicated buffers side by side, etc.

> Since there's the usual man command you run from a shell, it's not too
> obvious that "M-x man" is something very different.

`M-x man' is not much different.  For the usual man command you can
define the width by the environment variable `MANWIDTH' or `COLUMNS'.
And for `M-x man' there is a similar option `Man-width'.

bug#9084: 24.0.50; displaying man pages splits the window and formats the text for the full width of the whole frame rather than for the width of the window the text is displayed in, which is only 1/2 the width of the frame

[lee]

Juri Linkov <juri@jurta.org> writes:

> You are asking for functionality that is not specific to
> manpages. Typical text width in all buffers that I see is no more than
> 75 characters: in Dired buffers, in Info buffers, in source code
> buffers, etc.

Then the manpages as emacs formats them are an exception to that.

> Usually there is no point in making the window wider than the text
> displayed in all these buffers.  I think the width of the window
> and other parameters of window configurations should be specified
> at more general level.

I agree.  Dynamic window layout is one of emacs' strengths, and it would
make sense to give users more control over it.  That would include
functions like `frameify-window-layout' and `frameify-window'.  They
would make the windows currently displayed, or a particular window,
respectively, behave as if these windows were frames.

>> When your window is 230 characters wide, you could set Man-width to 70
>> and display three pages side by side?
>
> There was a plan to implement functionality where you can define
> arbitrary window layouts, e.g. you will be able to define a layout
> to display three manpage dedicated buffers side by side, etc.

Does this plan involve functionality to freeze window layouts or to
"frameify" windows?  There isn't much point in laying out windows in any
particular way when dynamic window layout continues to automatically
destroy an overall layout.  Users shouldn't be expected to specify
window layouts for a potentially huge number of different buffers in
order to always dynamically get the overall window layout they want when
this can be avoided by something as simple (for the user) as
"frameifying" a window.

bug#9084: 24.0.50; displaying man pages splits the window and formats the text for the full width of the whole frame rather than for the width of the window the text is displayed in, which is only 1/2 the width of the frame

[Juri Linkov]

> Then the manpages as emacs formats them are an exception to that.

Manpages are an exception because unlike most other static and
preformatted texts in other modes, `man' can format texts on the fly
taking the width as a parameter.  It would be wiser to employ this
possibility and fill the text of manpages to the window's width.
So it's up to the users to decide what width they want
interactively by creating a window with the desired width,
or by configuring the window auto-splitting or window layouts.

> Does this plan involve functionality to freeze window layouts or to
> "frameify" windows?  There isn't much point in laying out windows in any
> particular way when dynamic window layout continues to automatically
> destroy an overall layout.  Users shouldn't be expected to specify
> window layouts for a potentially huge number of different buffers in
> order to always dynamically get the overall window layout they want when
> this can be avoided by something as simple (for the user) as
> "frameifying" a window.

In the proposed designs such parts of the window layout are called
"window groups" or "framelettes" that can behave as a separate frame.

bug#9084: 24.0.50; displaying man pages splits the window and formats the text for the full width of the whole frame rather than for the width of the window the text is displayed in, which is only 1/2 the width of the frame

[lee]

Juri Linkov <juri@jurta.org> writes:

> Manpages are an exception because unlike most other static and
> preformatted texts in other modes, `man' can format texts on the fly
> taking the width as a parameter.  It would be wiser to employ this
> possibility and fill the text of manpages to the window's width.
> So it's up to the users to decide what width they want
> interactively by creating a window with the desired width,
> or by configuring the window auto-splitting or window layouts.

Ok, and how do users configure emacs to automatically split windows in
such a way that they aren't wider (or narrower) than the text to be
displayed in them while achieving the window layout they want?

>> Does this plan involve functionality to freeze window layouts or to
>> "frameify" windows?
>
> In the proposed designs such parts of the window layout are called
> "window groups" or "framelettes" that can behave as a separate frame.

Hm, sounds good to me.  Is there some more info about this available?
Will this be implemented?

bug#9084: 24.0.50; displaying man pages splits the window and formats the text for the full width of the whole frame rather than for the width of the window the text is displayed in, which is only 1/2 the width of the frame

[Juri Linkov]

> Ok, and how do users configure emacs to automatically split windows in
> such a way that they aren't wider (or narrower) than the text to be
> displayed in them while achieving the window layout they want?

Do you mean an algorithm like implemented in `balance-windows' (`C-x +')
or `shrink-window-if-larger-than-buffer' (`C-x -').  Unfortunately,
it's only for the vertical direction, and I can't find the same for the
horizontal direction, something like `shrink-window-if-<wider>-than-buffer'.

> Hm, sounds good to me.  Is there some more info about this available?
> Will this be implemented?

I hope Martin could answer your questions whether in the new design
is possible to achieve this by using window nests and splits.

bug#9084: 24.0.50; displaying man pages splits the window and formats the text for the full width of the whole frame rather than for the width of the window the text is displayed in, which is only 1/2 the width of the frame

[martin rudalics]

 >> Hm, sounds good to me.  Is there some more info about this available?
 >> Will this be implemented?
 >
 > I hope Martin could answer your questions whether in the new design
 > is possible to achieve this by using window nests and splits.

`display-buffer' allows to specify (1) the minimum height/width for the
popped-up window (the window is not created if this can't be done), and
(2) a desired height/width of the window after it has been created.  If
this fails, the size of the popped-up window remains unchanged after the
split.

For (2) you can either specify the desired size explicitly or call a
function like `fit-window-to-buffer' to adjust the size.  I just noticed
that the latter is broken because I call the function with the old
buffer (that is the one from the split window) instead of the new one.
I'll fix that tomorrow.

I don't know a function to fit the width of a window to the maximum line
length of the buffer it shows, but writing such a function should be
easy provided we have a function that tells us the maximum column within
a buffer.  BTW, is it impossible to use word wrapping for man pages?

martin

bug#9084: 24.0.50; displaying man pages splits the window and formats the text forthe full width of the whole frame rather than for the width ofthe window the text is displayed in, which is only 1/2 thewidth of the frame

[Drew Adams]

 

> -----Original Message-----
> From: bug-gnu-emacs-bounces+drew.adams=oracle.com@gnu.org 
> [mailto:bug-gnu-emacs-bounces+drew.adams=oracle.com@gnu.org] 
> On Behalf Of martin rudalics
> Sent: Wednesday, July 20, 2011 10:37 AM
> To: Juri Linkov
> Cc: 9084@debbugs.gnu.org
> Subject: bug#9084: 24.0.50;displaying man pages splits the 
> window and formats the text forthe full width of the whole 
> frame rather than for the width ofthe window the text is 
> displayed in, which is only 1/2 thewidth of the frame
> 
>  >> Hm, sounds good to me.  Is there some more info about 
> this available?
>  >> Will this be implemented?
>  >
>  > I hope Martin could answer your questions whether in the new design
>  > is possible to achieve this by using window nests and splits.
> 
> `display-buffer' allows to specify (1) the minimum 
> height/width for the
> popped-up window (the window is not created if this can't be 
> done), and
> (2) a desired height/width of the window after it has been 
> created.  If
> this fails, the size of the popped-up window remains 
> unchanged after the
> split.
> 
> For (2) you can either specify the desired size explicitly or call a
> function like `fit-window-to-buffer' to adjust the size.  I 
> just noticed
> that the latter is broken because I call the function with the old
> buffer (that is the one from the split window) instead of the new one.
> I'll fix that tomorrow.
> 
> I don't know a function to fit the width of a window to the 
> maximum line
> length of the buffer it shows, but writing such a function should be
> easy provided we have a function that tells us the maximum 
> column within
> a buffer.  BTW, is it impossible to use word wrapping for man pages?
> 
> martin
> 
> 
> 
> 

bug#9084: 24.0.50; displaying man pages splits the window and formats the text forthe full width of the whole frame rather than for the width ofthe window the text is displayed in, which is only 1/2 thewidth of the frame

[Drew Adams]

> I don't know a function to fit the width of a window to the 
> maximum line length of the buffer it shows, but writing such
> a function should be easy provided we have a function that
> tells us the maximum column within a buffer.

FWIW, this is what I do for frame-fitting, in fit-frame.el.  One thing to keep
in mind, IMO, is to let users skip over "header" lines (in a wide sense that
includes, e.g., the intro directory lines in Dired) when calculating the widest
line.  See function `fit-frame-max-window-size'.
http://www.emacswiki.org/emacs/fit-frame.el

This is the user option I provide for skipping header lines when calculating
width:

(defcustom fit-frame-skip-header-lines-alist
  '((Info-mode . 1) (dired-mode . 2) (compilation-mode . 2))
  "*Alist of major-modes and header lines to ignore.
When `fit-frame' calculates the width of the current buffer, it can
first skip some lines at the buffer beginning, ignoring their
widths.  For example, Info, Dired, and compilation buffers sometimes
have a long header line at the top.  You can use this alist to tell
`fit-frame' to ignore the width of these header lines.

Each item in the alist is of form (MODE . LINES).
 MODE is a major-mode name.
 LINES is the number of lines to skip at the beginning of the buffer."
  :type '(repeat (cons :format "%v" (symbol :tag "Major Mode")
                       (integer :tag "Header Lines to Ignore")))
  :group 'fit-frame)

Obviously, if we always used real `header-line' lines or some other way to
distinguish the lines to skip, then things would be easier and more reliable.
Note too that skipping the header lines in Dired is more important when details
are hidden (dired-details.el), which typically makes the buffer contents much
narrower than the "header" lines.

Finally, the code I use just works off of the `frame-char-width' - it does not
take into account variable pitch or multiple size fonts in the same buffer or
things such as Chinese chars in the buffer.

bug#9084: 24.0.50; displaying man pages splits the window and formats the text for the full width of the whole frame rather than for the width of the window the text is displayed in, which is only 1/2 the width of the frame

[lee]

Juri Linkov <juri@jurta.org> writes:

>> Ok, and how do users configure emacs to automatically split windows in
>> such a way that they aren't wider (or narrower) than the text to be
>> displayed in them while achieving the window layout they want?
>
> Do you mean an algorithm like implemented in `balance-windows' (`C-x +')
> or `shrink-window-if-larger-than-buffer' (`C-x -').  Unfortunately,
> it's only for the vertical direction, and I can't find the same for the
> horizontal direction, something like `shrink-window-if-<wider>-than-buffer'.

What I mean is

a.) ways to decide in advance what size a window should have before the
    window is created and
b.) the problem of keeping an overall window layout (i. e. within a
    frame) when multiple windows are displayed.

For example, when I use gnus[1] and look at the summary of a newsgroup
in a buffer, the summary is displayed full screen.  When I display an
article, the window is split to display the article as well as the
summary.  When I write a reply like this one, the reply is displayed
full screen[2], i. e. 230 characters wide, though `fill-column' is 72.

Now when I "M-x describe-variable fill-column", the window is split in
half, displaying the reply on the left (113 characters wide) and the
description on the right side (112 characters wide).  When I "M-x info",
the window on left is switched to show the *info* buffer instead of the
reply I'm writing --- which is not what I want because in this case, it
would make much more sense if the *info* buffer was displayed in the
window on the right.

What I would want is three windows, side by side and eventually some
vertical splits in some of the windows.  I can somehow[3] get that, but
when I have it, it won't last long because gnus or whatever else will
ignore my window layout and destroy it.

Even if I could specify for all windows that /might/ show up while I'm
using emacs what sizes they should have and where on the screen I want
them displayed in relation to other windows (if those are currently
displayed) to always achieve the overall window layout I want, that's
something I don't want to do because it's way to much work.  It probably
won't make sense, anyway --- and it's actually one of the strengths of
emacs to have dynamic window layout.

The problem would be solved if I could just "freeze" a particular window
layout or "frameify" windows.  Starting with a window the size of the
full screen, I could just split it the way I want to and then keep the
window layout as long as I want.

Having that said, it's probably not so important to have ways to specify
the possible sizes and positions of windows in advance.  It won't be
needed much if we could "frameify" windows.  What might be useful with a
static window layout would be ways to specify exceptions so that users
can decide what buffers can override their static window layout when
displayed.

That we can't "frameify" windows has probably historical reasons: The
feature doesn't make much sense when the display isn't (much) larger
than 80x25.  Nowadays, the displays are much larger.


[1] With gnus, the user can configure the window layout to some extend.
[2] I haven't bothered to find out if that is also configurable with
    gnus.  Even if it is, there's no point in changing it because
    dynamic window layout will do whatever it wants anyway.
[3] I just tried and couldn't find out how to make a window wider.  I
    would have to read the documentation, which would probably destroy
    the window configuration I'm trying to make, so I gave up to get on
    with the reply.

-- 
http://www.asciiribbon.org/
http://tools.ietf.org/html/rfc1855
http://www.caliburn.nl/topposting.html

bug#9084: 24.0.50; displaying man pages splits the window and formats the text for the full width of the whole frame rather than for the width of the window the text is displayed in, which is only 1/2 the width of the frame

[lee]

martin rudalics <rudalics@gmx.at> writes:

>>> Hm, sounds good to me.  Is there some more info about this available?
>>> Will this be implemented?
>>
>> I hope Martin could answer your questions whether in the new design
>> is possible to achieve this by using window nests and splits.
>
> `display-buffer' allows to specify (1) the minimum height/width for the
> popped-up window (the window is not created if this can't be done), and
> (2) a desired height/width of the window after it has been created.  If
> this fails, the size of the popped-up window remains unchanged after the
> split.

Unfortunately, I don't know elisp well enough yet to understand the
docstring of `display-buffer-alist'.  It sounds extremely complicated to
display a buffer in a window that has a particular size and position
with the `display-buffer' function.

Is everyone who's programming something in elisp that involves
displaying buffers expected to implement their own window management to
get buffers displayed the way they want them?  What if the users want
the buffers displayed differently than the programmers or use
features that have their own window layouts that are conflicting with
window layouts of other features?


Perhaps there's something I don't understand ...  A window manager like
fvwm2 does not resize and/or reposition and/or remove all or some of the
windows the user has carefully laid out on the display just because the
user decides to display a manual page or an info document, or starts
writing a reply to an email in one of the windows.  What is the point of
emacs destroying the users window layout all the time?


-- 
http://www.asciiribbon.org/
http://tools.ietf.org/html/rfc1855
http://www.caliburn.nl/topposting.html

bug#9084: 24.0.50; displaying man pages splits the window and formats the text for the full width of the whole frame rather than for the width of the window the text is displayed in, which is only 1/2 the width of the frame

[Juri Linkov]

> BTW, is it impossible to use word wrapping for man pages?

`man' uses its own word wrapping.

Currently I'm testing your window changes.  Do you think
creating an automated test would help?

I tried to run such tests in batch mode.  Both `frame-width' and
`frame-height' return the value 10.  And `window-height' returns 8.
After calling `split-window', the function `window-height' returns
the value 4.  This means that it's possible to create a batch test
for splitting windows.  But calling `make-frame' from the window test
fails with:

  Test window-tests backtrace:
    make-terminal-frame(nil)
    tty-create-frame-with-faces(nil)
    make-frame()
    ...
  Test window-tests condition:
      (error "Unknown terminal type")

How could Ert help testing in interactive mode?

bug#9084: 24.0.50; displaying man pages splits the window and formats the text for the full width of the whole frame rather than for the width of the window the text is displayed in, which is only 1/2 the width of the frame

[Juri Linkov]

> What I would want is three windows, side by side and eventually some
> vertical splits in some of the windows.  I can somehow[3] get that, but
> when I have it, it won't last long because gnus or whatever else will
> ignore my window layout and destroy it.

Gnus uses its own window configuration management.

For instance, I have the following in .emacs:

  (gnus-add-configuration
   '(reply-yank
     (vertical 1.0
               (summary 0.25)
               (horizontal 1.0
                           (article 0.5)
                           (message 1.0 point)))))

It adds a new window configuration to `gnus-buffer-configuration'.
You can create any window layout you want after reading
(info "(gnus) Window Layout")

bug#9084: 24.0.50; displaying man pages splits the window and formats the text for the full width of the whole frame rather than for the width of the window the text is displayed in, which is only 1/2 the width of the frame

[martin rudalics]

 > Currently I'm testing your window changes.  Do you think
 > creating an automated test would help?

Yes.  Just that I didn't get around writing one.

 > But calling `make-frame' from the window test
 > fails with:
 >
 >   Test window-tests backtrace:
 >     make-terminal-frame(nil)
 >     tty-create-frame-with-faces(nil)
 >     make-frame()
 >     ...
 >   Test window-tests condition:
 >       (error "Unknown terminal type")

I don't understand what you tried.  Testing frame creation in batch mode
hardly works if you don't have Emacs wait for the window manager to come
up with a window.  Even then you probably won't be able to check whether
the frame is risen or in the foreground.

 > How could Ert help testing in interactive mode?

I never tried Ert.

martin

bug#9084: 24.0.50; displaying man pages splits the window and formats the text for the full width of the whole frame rather than for the width of the window the text is displayed in, which is only 1/2 the width of the frame

[lee]

Juri Linkov <juri@jurta.org> writes:

>> What I would want is three windows, side by side and eventually some
>> vertical splits in some of the windows.  I can somehow[3] get that, but
>> when I have it, it won't last long because gnus or whatever else will
>> ignore my window layout and destroy it.
>
> Gnus uses its own window configuration management.

Exactly, and it doesn't go along with whatever else you use emacs for
/because/ it has its own window configuration, same as displaying a
manpage or a help buffer has.

Using an overall window layout as I described means to run gnus within
one of the windows I created.  That is not possible because windows
cannot be "frameified".  Setting `gnus-use-full-window' to nil doesn't
help that.

And if it's not gnus destroying the window layout, something else will.


-- 
http://www.asciiribbon.org/
http://tools.ietf.org/html/rfc1855
http://www.caliburn.nl/topposting.html

bug#9084: 24.0.50; displaying man pages splits the window and formats the text for the full width of the whole frame rather than for the width of the window the text is displayed in, which is only 1/2 the width of the frame

[Juri Linkov]

>> But calling `make-frame' from the window test
>> fails with:
>>
>>   Test window-tests backtrace:
>>     make-terminal-frame(nil)
>>     tty-create-frame-with-faces(nil)
>>     make-frame()
>>     ...
>>   Test window-tests condition:
>>       (error "Unknown terminal type")
>
> I don't understand what you tried.  Testing frame creation in batch mode
> hardly works if you don't have Emacs wait for the window manager to come
> up with a window.  Even then you probably won't be able to check whether
> the frame is risen or in the foreground.

I tried to write a test in the subdir `test/automated'
where Makefile runs all tests in `-batch' mode.

>> How could Ert help testing in interactive mode?
>
> I never tried Ert.

ERT supported running tests in batch mode as well as interactively.
So window tests should be placed in some other place than `test/automated'.