[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#12419: Mouse click changes layout
From: |
martin rudalics |
Subject: |
bug#12419: Mouse click changes layout |
Date: |
Tue, 25 Sep 2012 16:12:39 +0200 |
>> > Where in the code or the infrastructure do we enforce an integral
>> > number of lines in a window?
>>
>> All over the window handling code, presently.
>
> Can you humor me with a typical example, please?
The central routine is `window--resize-child-windows'. But
`balance-windows-2' and `fit-window-to-buffer' are typical too. All
these go a long way to meet a self-imposed restriction specified in
lines (and columns) by adding lines one-by-one to some window.
Obviously, we can replace this restriction by a pixel specified one and
things become probably much simpler. In any case, these routines have
to be rewritten. I can't tell how this will affect the remaining code
(large parts of which rely on `window--resize-child-windows').
> Why? Emacs doesn't promise to have the last line visible even now, if
> the window has variable size fonts. What we currently do promise
> (IIUC) is to have each window's height an integral multiple of the
> default face's height. But if the window shows no characters with the
> default face, that contract is irrelevant anyway.
It's not me you have to convince here ;-)
>> So even if we manage to provide really maximized frames, the window
>> handling code will have to show most windows with fully visible
>> lines.
>
> See above: you cannot guarantee that.
My experience tells me that people using the default face and only that
will ask for it. Let's hope I'm wrong.
> Do we really need such a change? What damage could be caused by
> accepting a window size in integral lines, but producing a window that
> is slightly larger or smaller? Again, this happens today already as
> long as non-default faces are displayed in the window.
Probably not much. Parts of the mouse code might report incongruent
results. And likely, window resizing will get inconsistent over time.
Give it a try. Have you ever looked at the routines XEmacs uses for
handling frame/window pixel sizes? There's quite a lot of them.
>> And I suppose that we want a function that calculates the number of
>> pixels between two buffer positions
>
> Doesn't pos-visible-in-window-p fit the bill already?
Have you looked at the loop at the end of `fit-window-to-buffer'? It's
apparently needed because `count-screen-lines' doesn't return a value
that's good enough there.
martin
- bug#12419: Mouse click changes layout, (continued)
- Message not available
- bug#12419: Mouse click changes layout, martin rudalics, 2012/09/16
- bug#12419: Mouse click changes layout, Daniel Pfeiffer, 2012/09/22
- bug#12419: Mouse click changes layout, martin rudalics, 2012/09/23
- bug#12419: Mouse click changes layout, Daniel Pfeiffer, 2012/09/23
- bug#12419: Mouse click changes layout, martin rudalics, 2012/09/24
- bug#12419: Mouse click changes layout, Eli Zaretskii, 2012/09/24
- bug#12419: Mouse click changes layout, martin rudalics, 2012/09/25
- bug#12419: Mouse click changes layout, Eli Zaretskii, 2012/09/25
- bug#12419: Mouse click changes layout,
martin rudalics <=
- bug#12419: Mouse click changes layout, Eli Zaretskii, 2012/09/26
- bug#12419: Mouse click changes layout, martin rudalics, 2012/09/26
- bug#12419: Mouse click changes layout, Eli Zaretskii, 2012/09/26
- bug#12419: Mouse click changes layout, martin rudalics, 2012/09/26
- bug#12419: Mouse click changes layout, Eli Zaretskii, 2012/09/26
- bug#12419: Mouse click changes layout, martin rudalics, 2012/09/26
- bug#12419: Mouse click changes layout, Eli Zaretskii, 2012/09/26
- bug#12419: Mouse click changes layout, Daniel Pfeiffer, 2012/09/24
- bug#12419: Mouse click changes layout, Eli Zaretskii, 2012/09/25
- bug#12419: Mouse click changes layout, martin rudalics, 2012/09/25