emacs-devel
[Top][All Lists]
Advanced

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

Re: 23.0.50; Cannot run calculator on TTY


From: martin rudalics
Subject: Re: 23.0.50; Cannot run calculator on TTY
Date: Sat, 13 Oct 2007 11:02:47 +0200
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

>     Presently, `split-window' has a problem with mode/header lines and small
>     heights (presumably also with scroll-bars and fringes).  To check
>     whether all windows are large enough after splitting it must make an
>     assumption about the presence of these on the new window.  It currently
>     bases its judgments on the appearance of the window that shall be split.
>
> Strictly speaking, that is correct.  Splitting the window shows the
> same buffer in both of the resulting windows, so it is valid if that
> buffer could be displayed in both.  However, in a larger sense, given
> that the aim is to display another window there, this does not really
> DTRT.
>
> One idea that occurs to me is that `window-min-height' could count the
> header line, if any.

Do you mean

"One idea that occurs to me is that the `split-window' could NOT count
the header line, if any."

here?  That is, change

    size = max (window_min_height,
                (MIN_SAFE_WINDOW_HEIGHT
                 + (WINDOW_WANTS_MODELINE_P (w) ? 1 : 0)
                 + (WINDOW_WANTS_HEADER_LINE_P (w) ? 1 : 0 )));

to

    size = max (window_min_height,
                (MIN_SAFE_WINDOW_HEIGHT
                 + (WINDOW_WANTS_MODELINE_P (w) ? 1 : 0)));

in `window_min_size_2'?  If so I think we should do that and maybe add a
short remark in the doc-string of `split-window' and the Elisp manual.
The only drawback I can think of is that splitting may produce a window
showing a header- and a mode-line only.

> That way, the fact that some buffers have header
> lines and others don't will not cause any problems for vertical
> splitting of windows.  In the most usual cases, at least -- but not
> in all cases, perhaps.
>
> Another solution would be to pass a two buffers to `split-window',
> telling it to select those two buffers, and to calculate based
> on the assumption that those buffers will be displayed.

That's what I meant with "provide explicit (optional) parameters for
`split-window-vertically' and `split-window-horizontally'".  This would
also mean that the client of these functions (and `split-window') would
have to set the corresponding (buffer-local) variables _before_ calling
these.





reply via email to

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