bug#12419: Mouse click changes layout

bug#12419: Mouse click changes layout

[Daniel Pfeiffer]

[-- Attachment #1: Type: text/plain, Size: 1117 bytes --]

I never took note of this as badly as recently with GNU Emacs 24.1.1, so I'm 
not sure if this has gotten worse than before: if I have a multiline message 
display, or a sideways scrolling buffer, and I click somewhere, the layout 
goes back to normal as per that click.  In both situations that's a major 
change of the layout and the click is not registered where I really clicked, 
but at the same position after reorganizing the layout (e.g. I have 20 + 30 
lines of windows + 5 lines of message area, but the message area dissapears 
when I click, shrinking to 1 line, so my click happens a few lines above where 
it was when I clicked, bacause the 20 line window grew to 22 and the 30 line 
window grew to 33, so the position I clicked is 4 lines above what I saw when 
clicking).

It never struck me until some months ago, so maybe there's a regression.  
Anyway it's extremely annoying!

coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn
Daniel Pfeiffer

-- 
lerne / learn / apprends / lär dig / ucz się    Esperanto:
                     http://lernu.net  /  http://ikurso.net


[-- Attachment #2: Type: text/html, Size: 1574 bytes --]

bug#12419: Mouse click changes layout

[Eli Zaretskii]

> Date: Wed, 12 Sep 2012 00:04:13 +0200
> From: Daniel Pfeiffer <occitan@t-online.de>
> 
> I never took note of this as badly as recently with GNU Emacs 24.1.1, so I'm 
> not sure if this has gotten worse than before: if I have a multiline message 
> display, or a sideways scrolling buffer, and I click somewhere, the layout 
> goes back to normal as per that click.  In both situations that's a major 
> change of the layout and the click is not registered where I really clicked, 
> but at the same position after reorganizing the layout (e.g. I have 20 + 30 
> lines of windows + 5 lines of message area, but the message area dissapears 
> when I click, shrinking to 1 line, so my click happens a few lines above where 
> it was when I clicked, bacause the 20 line window grew to 22 and the 30 line 
> window grew to 33, so the position I clicked is 4 lines above what I saw when 
> clicking).

I'm sorry, but I cannot figure out what is it that you describe.
Could you perhaps elaborate, or maybe add a few screenshots, to
clarify the problem?

Thanks.

bug#12419: Mouse click changes layout

[martin rudalics]

 > I never took note of this as badly as recently with GNU Emacs 24.1.1, so
 > I'm not sure if this has gotten worse than before: if I have a multiline
 > message display, or a sideways scrolling buffer, and I click somewhere,
 > the layout goes back to normal as per that click.  In both situations
 > that's a major change of the layout and the click is not registered
 > where I really clicked, but at the same position after reorganizing the
 > layout (e.g. I have 20 + 30 lines of windows + 5 lines of message area,
 > but the message area dissapears when I click, shrinking to 1 line, so my
 > click happens a few lines above where it was when I clicked, bacause the
 > 20 line window grew to 22 and the 30 line window grew to 33, so the
 > position I clicked is 4 lines above what I saw when clicking).
 >
 > It never struck me until some months ago, so maybe there's a
 > regression.  Anyway it's extremely annoying!

Can you improve the behavior by changing the value of
`resize-mini-windows'?

martin

bug#12419: Mouse click changes layout

[Daniel Pfeiffer]

la 09/12/2012 10:09 AM martin rudalics skribis:
> > I never took note of this as badly as recently with GNU Emacs 24.1.1, so
> > I'm not sure if this has gotten worse than before: if I have a multiline
> > message display, or a sideways scrolling buffer, and I click somewhere,
> > the layout goes back to normal as per that click.  In both situations
> > that's a major change of the layout and the click is not registered
> > where I really clicked, but at the same position after reorganizing the
> > layout (e.g. I have 20 + 30 lines of windows + 5 lines of message area,
> > but the message area dissapears when I click, shrinking to 1 line, so my
> > click happens a few lines above where it was when I clicked, bacause the
> > 20 line window grew to 22 and the 30 line window grew to 33, so the
> > position I clicked is 4 lines above what I saw when clicking).
> >
> > It never struck me until some months ago, so maybe there's a
> > regression.  Anyway it's extremely annoying!
>
> Can you improve the behavior by changing the value of
> `resize-mini-windows'?

It has it's default value of grow-only.  I like the feature and wouldn't want 
to turn it off.

I guess the annoying thing is that the resizing happens on mouse-down and 
side-ways scrolling on mouse-drag, i.e. in the middle of my operation.  If it 
were deferred till mouse-up (or till I drag to outside of the window to force 
scrolling), then it would be consistent with regard to where I clicked.

coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn
Daniel Pfeiffer

-- 
lerne / learn / apprends / lär dig / ucz się    Esperanto:
                     http://lernu.net  /  http://ikurso.net

bug#12419: Mouse click changes layout

[martin rudalics]

 >> Can you improve the behavior by changing the value of
 >> `resize-mini-windows'?
 >
 > It has it's default value of grow-only.  I like the feature and wouldn't
 > want to turn it off.

I meant for testing purposes only.

 > I guess the annoying thing is that the resizing happens on mouse-down
 > and side-ways scrolling on mouse-drag, i.e. in the middle of my
 > operation.  If it were deferred till mouse-up (or till I drag to outside
 > of the window to force scrolling), then it would be consistent with
 > regard to where I clicked.

You could try to inject some code at the beginning of
`window--resize-root-window-vertically' that writes a backtrace into a
buffer.  This way we could get some information about the kind of
mouse-event that caused the resizing.

martin

bug#12419: Mouse click changes layout

[Eli Zaretskii]

> Date: Fri, 14 Sep 2012 11:00:50 +0200
> From: martin rudalics <rudalics@gmx.at>
> Cc: 12419@debbugs.gnu.org
> 
>  > I guess the annoying thing is that the resizing happens on mouse-down
>  > and side-ways scrolling on mouse-drag, i.e. in the middle of my
>  > operation.  If it were deferred till mouse-up (or till I drag to outside
>  > of the window to force scrolling), then it would be consistent with
>  > regard to where I clicked.
> 
> You could try to inject some code at the beginning of
> `window--resize-root-window-vertically' that writes a backtrace into a
> buffer.  This way we could get some information about the kind of
> mouse-event that caused the resizing.

There's no need for anything that fancy, AFAICS.  Here's the recipe I
used:

  emacs -Q
  C-x 4 f xdisp.c RET
  C-x o
  M->
  (message (make-string 380 ?a))
  C-x C-e

The "C-x C-e" should be typed with point after the last expression
that calls 'message'.

Note that evaluating that expression raises the mode line of both the
lower and the upper windows.  That didn't happen in Emacs 23.3, where
it would only affect the mode line (and the lower part) of the _lower_
window that shows xdisp.c.

Now move the mouse pointer to some place in the lower window, and
press and hold the left mouse button.  You will see the message in the
echo area disappear, and the mode line of *scratch* move down, thus
causing scroll of the text in the xdisp.c window below it.  Again,
this doesn't happen in Emacs 23.3.

The same effect happens if, instead of clicking the mouse, you press
some key.  IOW, this is not limited to mouse clicks; instead, the
reason is the removal of the message from the echo area, which is
normal and happens upon any input.

My conclusion from the above experiment is that the reason for the
problem is that we somehow redistribute the screen real estate between
the windows when the echo area grows/shrinks.  Any pointers to where
this happens are welcome.

bug#12419: Mouse click changes layout

[martin rudalics]

 > Note that evaluating that expression raises the mode line of both the
 > lower and the upper windows.  That didn't happen in Emacs 23.3, where
 > it would only affect the mode line (and the lower part) of the _lower_
 > window that shows xdisp.c.

This behavior is due to my redesign of the window resize code for Emacs
24.1.  A couple of days ago Juanma told me that he's annoyed by it too.

Emacs 23.3 had three different routines for window resizing - one for
`enlarge-window', another one for `adjust-window-trailing-edge' and a
third one for resizing the minibuffer window.  Emacs 24.1 has one with
an extra argument that triggers either symmetric or asymmetric resizing.
For example, when resizing a frame, windows are resized symmetrically.
That is, all windows shrink or grow proportionally to their normal size.
This also means that, modulo some rounding errors, shrinking a frame and
enlarging it by the same amount will bring back the initial layout.

When dragging a divider, windows are resized asymmetrically, that is we
enlarge only the window we drag away from and shrink the windows on the
other side.  Asymmetric resizing is not reversible, that is, dragging
the divider back by the same amount will not necessarily reproduce the
inital configuration.  This property makes asymmetric resizing
unsuitable for resizing the minibuffer window where we eventually want
to get back the initial configuration.

Emacs 23.3 used a separate set of routines when resizing the minibuffer
window automatically.  I can try to either resurrect that code or move
it to Elisp.  Neither of these is trivial because the parts have to be
integrated into the current resizing framework so this will surely take
some time.

martin

bug#12419: Mouse click changes layout

[Drew Adams]

> For example, when resizing a frame, windows are resized symmetrically.
> That is, all windows shrink or grow proportionally to their 
> normal size.

Sounds reasonable.  But shouldn't it be a user choice (e.g. option)?  What if a
user wants some particular window's height (or width) to stay the same (assuming
there is enough space), while s?he changes the frame height (or width)?

Perhaps something akin to window dedication, to indicate that, as much as
possible, you want to keep the height or width of a particular window.

Or perhaps we could optionally let users keep just the selected window the same
size (as much as possible), when resizing the frame.  That would perhaps be
simpler than the suggestion above.

> This also means that, modulo some rounding errors, shrinking 
> a frame and enlarging it by the same amount will bring back
> the initial layout.

That sounds good.

> When dragging a divider, windows are resized asymmetrically, 
> that is we enlarge only the window we drag away from and
> shrink the windows on the other side.

That sounds normal, but what is the alternative - how could it be otherwise?

> Asymmetric resizing is not reversible, that is, dragging the
> divider back by the same amount will not necessarily reproduce the
> inital configuration.

I don't think that is what I see.  But I guess I don't understand what you're
saying.  Can you give an example, and contrast what happens in earlier Emacs
releases?

> This property makes asymmetric resizing unsuitable for
> resizing the minibuffer window where we eventually want
> to get back the initial configuration.

bug#12419: Mouse click changes layout

[Eli Zaretskii]

> Date: Fri, 14 Sep 2012 15:38:12 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: occitan@esperanto.org, 12419@debbugs.gnu.org
> 
>  > Note that evaluating that expression raises the mode line of both the
>  > lower and the upper windows.  That didn't happen in Emacs 23.3, where
>  > it would only affect the mode line (and the lower part) of the _lower_
>  > window that shows xdisp.c.
> 
> This behavior is due to my redesign of the window resize code for Emacs
> 24.1.  A couple of days ago Juanma told me that he's annoyed by it too.
> [...]
> Emacs 23.3 used a separate set of routines when resizing the minibuffer
> window automatically.  I can try to either resurrect that code or move
> it to Elisp.  Neither of these is trivial because the parts have to be
> integrated into the current resizing framework so this will surely take
> some time.

Wouldn't using the "asymmetric" resizing do the job here?  I don't
think the symmetric variant is ever TRT when triggered by resizing the
minibuffer window.

bug#12419: Mouse click changes layout

[martin rudalics]

 > Sounds reasonable.  But shouldn't it be a user choice (e.g. option)?  What if a
 > user wants some particular window's height (or width) to stay the same (assuming
 > there is enough space), while s?he changes the frame height (or width)?
 >
 > Perhaps something akin to window dedication, to indicate that, as much as
 > possible, you want to keep the height or width of a particular window.

You can set `window-size-fixed' in that buffer.

 > Or perhaps we could optionally let users keep just the selected window the same
 > size (as much as possible), when resizing the frame.  That would perhaps be
 > simpler than the suggestion above.

That's problematic when the same buffer is shown in two different
windows.

 >> When dragging a divider, windows are resized asymmetrically,
 >> that is we enlarge only the window we drag away from and
 >> shrink the windows on the other side.
 >
 > That sounds normal, but what is the alternative - how could it be otherwise?

That all windows on the other side get resized proportionally.

 >> Asymmetric resizing is not reversible, that is, dragging the
 >> divider back by the same amount will not necessarily reproduce the
 >> inital configuration.
 >
 > I don't think that is what I see.  But I guess I don't understand what you're
 > saying.  Can you give an example, and contrast what happens in earlier Emacs
 > releases?

Try with three windows above each other and drag one modeline until both
windows in the direction you drag to are at their minimum height.  Then
drag the divider back.  The outermost window is not sized back.  Now set
`resize-mini-windows' to nil and drag the bottom modeline.  All windows
get resized proportionally in both directions.

In Emacs 23.3 automatically resizing the minibuffer resizes the lowest
window first.  That's what people want.  But IIRC this doesn't work with
`resize-mini-windows' t and `resize-mini-windows' nil doesn't work when
the lowest window is at its minimum height.

martin

bug#12419: Mouse click changes layout

[martin rudalics]

 > Wouldn't using the "asymmetric" resizing do the job here?  I don't
 > think the symmetric variant is ever TRT when triggered by resizing the
 > minibuffer window.

Asymmetric resizing doesn't size back correctly when any window but a
bottommost one gets resized while enlarging the minibuffer window.  the
idea of asymmetric dragging is that in a configuration like this

  ------------
|            |
|            |
  ------------
|            |
|            |
  ------------
|            |
|            |
  ------------

you drag the lower divider up you first get

  ------------
|            |
|            |
  ------------
|            |
  ------------
|            |
|            |
|            |
  ------------

and then

  ------------
|            |
  ------------
|            |
  ------------
|            |
|            |
|            |
|            |
  ------------

because the idea is that you want to show more in the bottom window.
When you now drag the same divider back you get

  ------------
|            |
  ------------
|            |
|            |
  ------------
|            |
|            |
|            |
  ------------

because the idea is to show more of the middle window and then

  ------------
|            |
  ------------
|            |
|            |
|            |
  ------------
|            |
|            |
  ------------

which is not the initial configuration.

martin

bug#12419: Mouse click changes layout

[Stefan Monnier]

> Wouldn't using the "asymmetric" resizing do the job here?  I don't
> think the symmetric variant is ever TRT when triggered by resizing the
> minibuffer window.

I think asymmetric would be a better choice, indeed.

IIUC the difference between "asymmetric" and the old "miniwindow-resize"
behavior is that if the lowest window needs to be shrunk below the
minimum height, the "miniwindow-resize" just gave up, whereas the
"asymmetric" will try to resize further windows.

I think The Right Thing(tm) lies somewhere between the two:
- OT1H it's generally a good idea not to grow the miniwindow larger than
  other windows), hence the old "miniwindow-resize".
- OTOH, if the window just above the minibuffer is a special tiny window
  displaying some auxiliary-info, it sometimes makes sense to treat it
  as a kind of "attachment to the modeline" and to resize the other
  window instead.
So maybe tweaking the asymmetric behavior so it only resizes 1 window
(typically the window immediately above the modeline, but if that one
is marked window-size-fixed, then the one above) would be ideal.

In the mean time, I suggest we try to use asymmetric.


        Stefan


PS: BTW, I've several times wished that when dragging modelines (and
vertical dividers), dragging them back would also bring back the other
dividers.  OTOH, I haven't had the chance to use an Emacs that would
behave like that, so maybe if it did I'd often wish that the dividers
don't move back.

bug#12419: Mouse click changes layout

[Drew Adams]

>  >> When dragging a divider, windows are resized asymmetrically,
>  >> that is we enlarge only the window we drag away from and
>  >> shrink the windows on the other side.
>  >
>  > That sounds normal, but what is the alternative - how 
>  > could it be otherwise?
> 
> That all windows on the other side get resized proportionally.

How is that different from "shrink the windows on the other side"?  I'm guessing
that shrink them, but not proportionately?

>  >> Asymmetric resizing is not reversible, that is, dragging the
>  >> divider back by the same amount will not necessarily reproduce the
>  >> inital configuration.
>  >
>  > I don't think that is what I see.  But I guess I don't 
>  > understand what you're saying.  Can you give an example,
>  > and contrast what happens in earlier Emacs releases?
> 
> Try with three windows above each other and drag one
> modeline until both windows in the direction you drag to
> are at their minimum height.  Then drag the divider back.
> The outermost window is not sized back.

I see.  In previous releases when you drag one mode line, only the adjacent
window shrinks.  And that corresponds exactly (AFAICT) to the opposite action of
dragging the mode line back again.  So previously the opposite drag action was
symmetric to the initial drag action.  Now it is not.

Can we (and then should we) make this change in behavior optional (for the
user)?

> Now set `resize-mini-windows' to nil and drag the bottom modeline.  
> All windows get resized proportionally in both directions.

Not with a standalone minibuffer frame.  At least I see no change in behavior,
whatever the value of `resize-mini-windows'.

> In Emacs 23.3 automatically resizing the minibuffer resizes the lowest
> window first.  That's what people want.  But IIRC this 
> doesn't work with `resize-mini-windows' t and `resize-mini-windows'
> nil doesn't work when the lowest window is at its minimum height.

OK, thanks for the explanation.

Consider proposing something for emacs-devel to discuss.  Was the change in
behavior from Emacs 23 to 24 (the change made so far) ever discussed?

Personally I don't care much, since I don't split windows that much.  But this
sounds like something that affects lots of users, and perhaps there should be
some discussion about it.

bug#12419: Mouse click changes layout

[Drew Adams]

>   ------------
> |            |
> |            |
>   ------------
> |            |
> |            |
>   ------------
> |            |
> |            |
>   ------------
> 
> you drag the lower divider up you first get
> 
>   ------------
> |            |
> |            |
>   ------------
> |            |
>   ------------
> |            |
> |            |
> |            |
>   ------------
> 
> and then
> 
>   ------------
> |            |
>   ------------
> |            |
>   ------------
> |            |
> |            |
> |            |
> |            |
>   ------------

AFAICT, in previous releases, the second change does not occur. Only the first
one does.

> because the idea is that you want to show more in the bottom window.
> When you now drag the same divider back you get
> 
>   ------------
> |            |
>   ------------
> |            |
> |            |
>   ------------
> |            |
> |            |
> |            |
>   ------------
> 
> because the idea is to show more of the middle window and then
> 
>   ------------
> |            |
>   ------------
> |            |
> |            |
> |            |
>   ------------
> |            |
> |            |
>   ------------
> 
> which is not the initial configuration.

AFAICT, in previous releases you get exactly the opposite changes from when you
dragged the divider up: only the middle window is affected in both cases.

That is pretty consistent.  Whether it is generally better or not, I don't know.
But perhap it should be a user choice (option), in case some users prefer the
traditional behavior. 

bug#12419: Mouse click changes layout

[Eli Zaretskii]

> Date: Fri, 14 Sep 2012 17:16:24 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: occitan@esperanto.org, 12419@debbugs.gnu.org
> 
>  > Wouldn't using the "asymmetric" resizing do the job here?  I don't
>  > think the symmetric variant is ever TRT when triggered by resizing the
>  > minibuffer window.
> 
> Asymmetric resizing doesn't size back correctly when any window but a
> bottommost one gets resized while enlarging the minibuffer window.  the
> idea of asymmetric dragging is that in a configuration like this
> 
>   ------------
> |            |
> |            |
>   ------------
> |            |
> |            |
>   ------------
> |            |
> |            |
>   ------------
> 
> you drag the lower divider up you first get
> 
>   ------------
> |            |
> |            |
>   ------------
> |            |
>   ------------
> |            |
> |            |
> |            |
>   ------------
> 
> and then
> 
>   ------------
> |            |
>   ------------
> |            |
>   ------------
> |            |
> |            |
> |            |
> |            |
>   ------------
> 
> because the idea is that you want to show more in the bottom window.
> When you now drag the same divider back you get
> 
>   ------------
> |            |
>   ------------
> |            |
> |            |
>   ------------
> |            |
> |            |
> |            |
>   ------------
> 
> because the idea is to show more of the middle window and then
> 
>   ------------
> |            |
>   ------------
> |            |
> |            |
> |            |
>   ------------
> |            |
> |            |
>   ------------
> 
> which is not the initial configuration.

I was talking about mini-window resize, and that alone.  I was asking
whether using the asymmetric method when the trigger is resize of the
mini-window would do the job.

Situations where mini-window grows so much as to resize windows other
than the one immediately above it are very rare, so I don't think we
should be bothered by them, at least not initially.

bug#12419: Mouse click changes layout

[martin rudalics]

 >> Wouldn't using the "asymmetric" resizing do the job here?  I don't
 >> think the symmetric variant is ever TRT when triggered by resizing the
 >> minibuffer window.
 >
 > I think asymmetric would be a better choice, indeed.
 >
 > IIUC the difference between "asymmetric" and the old "miniwindow-resize"
 > behavior is that if the lowest window needs to be shrunk below the
 > minimum height, the "miniwindow-resize" just gave up, whereas the
 > "asymmetric" will try to resize further windows.

Asymmetric is what shrink_window_lowest_first did in Emacs 23.  It could
shrink all windows down to their safe minimum height.  But there's no
enlarge_window_lowest_first for the obvious reason.  You can't undo the
effect of shrink_window_lowest_first easily.  So Emacs 23 saved the
sizes of windows at the beginning of growing the minibuffer and restored
them, if possible, when shrinking the minibuffer back.  That's also why
the default of `resize-mini-windows' is `grow-only'.  You can't
implement `t' with this method.  And that's also why the echo area
usually gets cleared and sized back immediately.

 > I think The Right Thing(tm) lies somewhere between the two:
 > - OT1H it's generally a good idea not to grow the miniwindow larger than
 >   other windows), hence the old "miniwindow-resize".
 > - OTOH, if the window just above the minibuffer is a special tiny window
 >   displaying some auxiliary-info, it sometimes makes sense to treat it
 >   as a kind of "attachment to the modeline" and to resize the other
 >   window instead.

This is a case that must be handled.  Anything else would be a regression.

 > So maybe tweaking the asymmetric behavior so it only resizes 1 window
 > (typically the window immediately above the modeline, but if that one
 > is marked window-size-fixed, then the one above) would be ideal.
 >
 > In the mean time, I suggest we try to use asymmetric.

This would enlarge a one line window at the bottom of the frame whenever
the minibuffer is shrunk back.  Not a feasible option.  What I have to
do is to save the state (in the window structure to avoid the extra
allocations) before growing the minibuffer and restore it (if the
heights still match) when shrinking the minibuffer back.  This is
cumbersome but I see no other way.

 > PS: BTW, I've several times wished that when dragging modelines (and
 > vertical dividers), dragging them back would also bring back the other
 > dividers.

I had implemented that initially.  It's disconcerting (but I could make
it optional easily).

 > OTOH, I haven't had the chance to use an Emacs that would
 > behave like that, so maybe if it did I'd often wish that the dividers
 > don't move back.

Indeed.

martin

bug#12419: Mouse click changes layout

[martin rudalics]

 >> That all windows on the other side get resized proportionally.
 >
 > How is that different from "shrink the windows on the other side"?  I'm guessing
 > that shrink them, but not proportionately?

Yes.  Shrink (or grow) the ones adjacent to an edge first.

 > I see.  In previous releases when you drag one mode line, only the adjacent
 > window shrinks.  And that corresponds exactly (AFAICT) to the opposite action of
 > dragging the mode line back again.  So previously the opposite drag action was
 > symmetric to the initial drag action.  Now it is not.
 >
 > Can we (and then should we) make this change in behavior optional (for the
 > user)?

If you have a copy of Emacs 19 or 20 around you will notice that other
windows did shrink too.  The "shrink only the adjacent window" behavior
you mention was introduced together with `adjust-window-trailing-edge'.
But this function is not very suitable for the minibuffer.

 >> Now set `resize-mini-windows' to nil and drag the bottom modeline.
 >> All windows get resized proportionally in both directions.
 >
 > Not with a standalone minibuffer frame.  At least I see no change in behavior,
 > whatever the value of `resize-mini-windows'.

You need a "normal" frame with a minibuffer for this.

 > Consider proposing something for emacs-devel to discuss.  Was the change in
 > behavior from Emacs 23 to 24 (the change made so far) ever discussed?

Partially.  Most of them were the results of attempting to fix errors.
But I have to admit that I never understood the old code completely so I
couldn't even tell what has changed and how.

 > Personally I don't care much, since I don't split windows that much.  But this
 > sounds like something that affects lots of users, and perhaps there should be
 > some discussion about it.

There should have been more testing before the release.  But I wasn't
very good at advertising my branch then.

martin

bug#12419: Mouse click changes layout

[martin rudalics]

 > AFAICT, in previous releases you get exactly the opposite changes from when you
 > dragged the divider up: only the middle window is affected in both cases.

As I said in my other mail: Look out for Emacsen before
`adjust-window-trailing-edge'.

 > That is pretty consistent.  Whether it is generally better or not, I don't know.
 > But perhap it should be a user choice (option), in case some users prefer the
 > traditional behavior.

Not so traditional.  And it's useless when the window in the middle has
only one or two lines.

martin

bug#12419: Mouse click changes layout

[martin rudalics]

 > I was talking about mini-window resize, and that alone.  I was asking
 > whether using the asymmetric method when the trigger is resize of the
 > mini-window would do the job.

The example I gave should have told you.  Think of the bottom window as
the minibuffer window.

 > Situations where mini-window grows so much as to resize windows other
 > than the one immediately above it are very rare, so I don't think we
 > should be bothered by them, at least not initially.

I use ediff with the control panel on the bottom of the frame.  How can
I resize the minibuffer in this case?  And it did work in Emacs 23.

martin

bug#12419: Mouse click changes layout

[Drew Adams]

> If you have a copy of Emacs 19 or 20 around you will notice that other
> windows did shrink too.

No, I don't see that in Emacs 20 (I don't have 19).  I not only have a copy of
it hanging around, I use it much of the time!

> The "shrink only the adjacent 
> window" behavior you mention was introduced together with 
> `adjust-window-trailing-edge'.

Maybe, but in Emacs 20 I still see only the adjacent window shrink.  I'm on MS
Windows - dunno whether that make a difference.

GNU Emacs 20.7.3 (i386-*-nt5.1.2600) of Thu Dec 21 2000 on buffy

> But this function is not very suitable for the minibuffer.

>  > Consider proposing something for emacs-devel to discuss.  
>  > Was the change in behavior from Emacs 23 to 24 (the change
>  > made so far) ever discussed?
> 
> Partially.  Most of them were the results of attempting to fix errors.
> But I have to admit that I never understood the old code 
> completely so I couldn't even tell what has changed and how.

It would be good to present the alternative behaviors to people in emacs-devel
(and maybe even help-gnu-emacs), so they can make an informed choice.  And it
might be good to let end users have a choice (e.g., via an option), if that's
feasible.

>  > Personally I don't care much, since I don't split windows 
>  > that much.  But this sounds like something that affects lots
>  > of users, and perhaps there should be some discussion about it.
> 
> There should have been more testing before the release.  But I wasn't
> very good at advertising my branch then.

It's not likely that a branch will be tried by many Windows users who don't
build Emacs themselves.

Before inclusion in a release, a change should be available in a pretest
(prerelease version), and users can test it there.  But perhaps there was not
enough pretest time.  I believe that pretests used to be longer in the old days.

For another thing, users of a pretest should be informed (at least via NEWS, and
preferably on emacs-devel by anyone who wants something specific tested during
pretest) about new features to be tested.

bug#12419: Mouse click changes layout

[Stefan Monnier]

>> - OTOH, if the window just above the minibuffer is a special tiny window
>> displaying some auxiliary-info, it sometimes makes sense to treat it
>> as a kind of "attachment to the modeline" and to resize the other
>> window instead.
> This is a case that must be handled.  Anything else would be a regression.

We're discussing this in the context of fixing another regression, so
I'm willing to trade one regression for another.
Wouldn't `asymmetric' handle it acceptably if the small bottom window has
something like `window-size-fixed' set?


        Stefan

bug#12419: Mouse click changes layout

[Eli Zaretskii]

> Date: Fri, 14 Sep 2012 21:15:44 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: occitan@esperanto.org, 12419@debbugs.gnu.org
> 
>  > I was talking about mini-window resize, and that alone.  I was asking
>  > whether using the asymmetric method when the trigger is resize of the
>  > mini-window would do the job.
> 
> The example I gave should have told you.  Think of the bottom window as
> the minibuffer window.

I did.  And I see no problems with that.

>  > Situations where mini-window grows so much as to resize windows other
>  > than the one immediately above it are very rare, so I don't think we
>  > should be bothered by them, at least not initially.
> 
> I use ediff with the control panel on the bottom of the frame.  How can
> I resize the minibuffer in this case?

Why, by resizing the window above the control panel, of course.  I
didn't say it won't happen, I just said it will be rare, and therefore
not a reason not to have that behavior.

bug#12419: Mouse click changes layout

[martin rudalics]

 > No, I don't see that in Emacs 20 (I don't have 19).  I not only have a copy of
 > it hanging around, I use it much of the time!

According to the ChangeLogs `adjust-window-trailing-edge' was introduced
with Emasc 22 so you should see it even with Emacs 21.

 >> The "shrink only the adjacent
 >> window" behavior you mention was introduced together with
 >> `adjust-window-trailing-edge'.
 >
 > Maybe, but in Emacs 20 I still see only the adjacent window shrink.  I'm on MS
 > Windows - dunno whether that make a difference.
 >
 > GNU Emacs 20.7.3 (i386-*-nt5.1.2600) of Thu Dec 21 2000 on buffy

Strange.  Maybe my memory fails.

 > It would be good to present the alternative behaviors to people in emacs-devel
 > (and maybe even help-gnu-emacs), so they can make an informed choice.  And it
 > might be good to let end users have a choice (e.g., via an option), if that's
 > feasible.

It's not (very) feasible in the case at hand.

 > Before inclusion in a release, a change should be available in a pretest
 > (prerelease version), and users can test it there.  But perhaps there was not
 > enough pretest time.  I believe that pretests used to be longer in the old days.
 >
 > For another thing, users of a pretest should be informed (at least via NEWS, and
 > preferably on emacs-devel by anyone who wants something specific tested during
 > pretest) about new features to be tested.

The routines were installed on 2011-06-10.  There was plenty of time to
test them till the release of Emacs 24.1.

martin

bug#12419: Mouse click changes layout

[martin rudalics]

 > We're discussing this in the context of fixing another regression,

... which is not a regression IMHO ...

 > so
 > I'm willing to trade one regression for another.

I'll come up with a non-regressive fix ;-)

 > Wouldn't `asymmetric' handle it acceptably if the small bottom window has
 > something like `window-size-fixed' set?

For some value of acceptability, yes.

martin

bug#12419: Mouse click changes layout

[martin rudalics]

 >> The example I gave should have told you.  Think of the bottom window as
 >> the minibuffer window.
 >
 > I did.  And I see no problems with that.

You see no problem with minibuffer window resizing not restoring the
initial configuration?

 >> I use ediff with the control panel on the bottom of the frame.  How can
 >> I resize the minibuffer in this case?
 >
 > Why, by resizing the window above the control panel, of course.

And how would you size the minibuffer back?

 > I
 > didn't say it won't happen, I just said it will be rare, and therefore
 > not a reason not to have that behavior.

OK.  Please try the patch below and tell me whether it does what you
want.

Thanks, martin

=== modified file 'lisp/window.el'
--- lisp/window.el	2012-09-09 06:43:47 +0000
+++ lisp/window.el	2012-09-15 09:26:32 +0000
@@ -2413,7 +2413,9 @@
        ;; So, in practice, we'd need a history variable to record how to
        ;; proceed.  But I'm not sure how such a variable could work with
        ;; repeated minibuffer window growing steps.
-      (window--resize-this-window window delta nil ignore t)
+      (window--resize-this-window
+       window delta nil ignore t 'before
+       (+ (window-top-line window) (window-total-size window)))
        delta)))

  (defun adjust-window-trailing-edge (window delta &optional horizontal)

bug#12419: Mouse click changes layout

[Eli Zaretskii]

> Date: Sat, 15 Sep 2012 11:54:17 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: occitan@esperanto.org, 12419@debbugs.gnu.org
> 
>  >> The example I gave should have told you.  Think of the bottom window as
>  >> the minibuffer window.
>  >
>  > I did.  And I see no problems with that.
> 
> You see no problem with minibuffer window resizing not restoring the
> initial configuration?

When the minibuffer window's growth absolutely must resize windows
other than the lowest one, no.  IMO, it's better than Emacs 23's
punting and displaying only a portion of the echo-area message.

>  >> I use ediff with the control panel on the bottom of the frame.  How can
>  >> I resize the minibuffer in this case?
>  >
>  > Why, by resizing the window above the control panel, of course.
> 
> And how would you size the minibuffer back?

I don't understand the problem you obviously have in mind.

>  > I
>  > didn't say it won't happen, I just said it will be rare, and therefore
>  > not a reason not to have that behavior.
> 
> OK.  Please try the patch below and tell me whether it does what you
> want.

It restores the Emacs 23 behavior, AFAICS.  But why can't we do better
than that?  If the lowest window is large enough, why not show more of
the echo-area message, instead of always showing only the last N lines?

Thanks.

bug#12419: Mouse click changes layout

[martin rudalics]

 >  > GNU Emacs 20.7.3 (i386-*-nt5.1.2600) of Thu Dec 21 2000 on buffy
 >
 > Strange.  Maybe my memory fails.

Only partially ;-)  On

GNU Emacs 20.7.1 (i386-*-nt5.1.2600) of Tue Jun 13 2000

with a three-windows-above-each-other frame I can track the uppermost
modeline down as far as I want.  I can't track it up though.  Same
behavior with

GNU Emacs 21.2.1 (i386-msvc-nt5.1.2600) of 2002-03-19

IIRC in the nineties it did work in both directions, but maybe with
XEmacs only.

martin

bug#12419: Mouse click changes layout

[martin rudalics]

 >> You see no problem with minibuffer window resizing not restoring the
 >> initial configuration?
 >
 > When the minibuffer window's growth absolutely must resize windows
 > other than the lowest one, no.  IMO, it's better than Emacs 23's
 > punting and displaying only a portion of the echo-area message.

Where do you see that?  Can you give an example?

 >>  >> I use ediff with the control panel on the bottom of the frame.  How can
 >>  >> I resize the minibuffer in this case?
 >>  >
 >>  > Why, by resizing the window above the control panel, of course.
 >>
 >> And how would you size the minibuffer back?
 >
 > I don't understand the problem you obviously have in mind.

Then put a one-line window at the bottom of your frame and resize the
minibuffer.  At the time it sizes back the one-line window has grown.

 >> OK.  Please try the patch below and tell me whether it does what you
 >> want.
 >
 > It restores the Emacs 23 behavior, AFAICS.

It doesn't :-(

 > But why can't we do better
 > than that?

Second law of thermodynamics?

 > If the lowest window is large enough, why not show more of
 > the echo-area message, instead of always showing only the last N lines?

I don't understand you.  As far as minibuffer resizing is concerned, you
can show any number of lines in the minibuffer as long as you don't try
to delete other windows.  So the N lines restriction you see must come
from somewhere else.

martin

bug#12419: Mouse click changes layout

[Eli Zaretskii]

> Date: Sat, 15 Sep 2012 12:39:29 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: occitan@esperanto.org, 12419@debbugs.gnu.org
> 
>  >> You see no problem with minibuffer window resizing not restoring the
>  >> initial configuration?
>  >
>  > When the minibuffer window's growth absolutely must resize windows
>  > other than the lowest one, no.  IMO, it's better than Emacs 23's
>  > punting and displaying only a portion of the echo-area message.
> 
> Where do you see that?  Can you give an example?

Try the recipe I showed earlier in this thread with Emacs 23.3, but
use 1000 instead of 380, and you will see that only the last part of
the echo-area message is shown.

>  >>  >> I use ediff with the control panel on the bottom of the frame.  How can
>  >>  >> I resize the minibuffer in this case?
>  >>  >
>  >>  > Why, by resizing the window above the control panel, of course.
>  >>
>  >> And how would you size the minibuffer back?
>  >
>  > I don't understand the problem you obviously have in mind.
> 
> Then put a one-line window at the bottom of your frame and resize the
> minibuffer.  At the time it sizes back the one-line window has grown.

OK, but why is that a problem grave enough to be concerned about?
Using Ediff in such a way is non-standard, so won't be a problem for
most users.  And even in this configuration, what is so bad about
this?

>  > If the lowest window is large enough, why not show more of
>  > the echo-area message, instead of always showing only the last N lines?
> 
> I don't understand you.  As far as minibuffer resizing is concerned, you
> can show any number of lines in the minibuffer as long as you don't try
> to delete other windows.  So the N lines restriction you see must come
> from somewhere else.

Maybe it does, but I tried that with "emacs -Q", so the number of such
other places is severely limited ;-)

AFAICS, with your patch the minibuffer is never resized to show more
than 9 lines, with the default size of the frame which can show 33
text lines.  This is so even if I do _not_ split the frame into 2
windows, one below the other, but instead invoke 'message' from the
original window configuration displayed by "emacs -Q", where there's a
single window showing the "*scratch*" buffer.  Try this:

  emacs -Q
  (message (make-string 1000 ?a))
  C-x C-e

How many lines and how many a's do you see in the echo area?

bug#12419: Mouse click changes layout

[martin rudalics]

 >> Where do you see that?  Can you give an example?
 >
 > Try the recipe I showed earlier in this thread with Emacs 23.3, but
 > use 1000 instead of 380, and you will see that only the last part of
 > the echo-area message is shown.

max-mini-window-height is a variable defined in `xdisp.c'.
Its value is 0.25

Documentation:
Maximum height for resizing mini-windows (the minibuffer and the echo area).
If a float, it specifies a fraction of the mini-window frame's height.
If an integer, it specifies a number of lines.

You can customize this variable.

This variable was introduced, or its default value was changed, in
version 23.1 of Emacs.

 >> Then put a one-line window at the bottom of your frame and resize the
 >> minibuffer.  At the time it sizes back the one-line window has grown.
 >
 > OK, but why is that a problem grave enough to be concerned about?
 > Using Ediff in such a way is non-standard, so won't be a problem for
 > most users.  And even in this configuration, what is so bad about
 > this?

 From the number of code lines he spent to handle this problem, I
conclude that it was bad enough for Gerd.

 >>  > If the lowest window is large enough, why not show more of
 >>  > the echo-area message, instead of always showing only the last N lines?
 >>
 >> I don't understand you.  As far as minibuffer resizing is concerned, you
 >> can show any number of lines in the minibuffer as long as you don't try
 >> to delete other windows.  So the N lines restriction you see must come
 >> from somewhere else.
 >
 > Maybe it does, but I tried that with "emacs -Q", so the number of such
 > other places is severely limited ;-)

It is.

 > AFAICS, with your patch the minibuffer is never resized to show more
 > than 9 lines, with the default size of the frame which can show 33
 > text lines.  This is so even if I do _not_ split the frame into 2
 > windows, one below the other, but instead invoke 'message' from the
 > original window configuration displayed by "emacs -Q", where there's a
 > single window showing the "*scratch*" buffer.  Try this:
 >
 >   emacs -Q
 >   (message (make-string 1000 ?a))
 >   C-x C-e
 >
 > How many lines and how many a's do you see in the echo area?

9 lines - so our Emacsen are created equal.  Nothing can beat evolution ;-)

martin

bug#12419: Mouse click changes layout

[Eli Zaretskii]

> Date: Sat, 15 Sep 2012 14:44:53 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: occitan@esperanto.org, 12419@debbugs.gnu.org
> 
>  >> Where do you see that?  Can you give an example?
>  >
>  > Try the recipe I showed earlier in this thread with Emacs 23.3, but
>  > use 1000 instead of 380, and you will see that only the last part of
>  > the echo-area message is shown.
> 
> max-mini-window-height is a variable defined in `xdisp.c'.
> Its value is 0.25

OK, I see the light now.  Thanks.

But why did you say that your proposed change in window.el doesn't
restore the Emacs 23 behavior?  AFAICS, it does: if I set
max-mini-window-height to a large number, like 100, Emacs 23 also
resizes windows other than the lowest one.

bug#12419: Mouse click changes layout

[martin rudalics]

 > But why did you say that your proposed change in window.el doesn't
 > restore the Emacs 23 behavior?  AFAICS, it does: if I set
 > max-mini-window-height to a large number, like 100, Emacs 23 also
 > resizes windows other than the lowest one.

My algorithm growing the minibuffer window emulates Gerd's.  But there
is no algorithm for shrinking the minibuffer window because no reliable
one exists.  Gerd stores all original window heights before growing the
minibuffer window and emulates shrinking to the original line by writing
them back into the height fields of the window structure.  This requires
some care and can fail, for example, when resizing the frame with an
enlarged minibuffer.  And IIUC this is also the reason for the somewhat
strange default value `grow-only' for `resize-mini-windows'.

Look at Gerd's shrinking routine below:

shrink_mini_window (w)
      struct window *w;
{
   struct frame *f = XFRAME (w->frame);
   struct window *root = XWINDOW (FRAME_ROOT_WINDOW (f));

   if (save_restore_orig_size (root, CHECK_ORIG_SIZES))

----> This is taken if heights were stored earlier and the size check
       suceeds.  Note that it just restores the original sizes, there's
       no shrinking from say 3 to 2 lines.

     {
       save_restore_orig_size (root, RESTORE_ORIG_SIZES);
       adjust_glyphs (f);
       FRAME_WINDOW_SIZES_CHANGED (f) = 1;
       windows_or_buffers_changed = 1;
     }
   else if (XFASTINT (w->total_lines) > 1)

----> This is the branch taken in the `resize-mini-windows' t case or
       when the size check above fails.  It does the old enlarge_window
       routine which can shed bad results and in some cases even delete
       the windows it's supposed to enlarge.  This could also shrink a
       minibuffer from 3 to 2 lines; but that feature is not used, likely
       because Gerd trusted that nobody would want it.  So, by force, the
       minibuffer window always shrinks back to one line.

     {
       /* Distribute the additional lines of the mini-window
	 among the other windows.  */
       Lisp_Object window;
       XSETWINDOW (window, w);
       enlarge_window (window, 1 - XFASTINT (w->total_lines), 0);
     }
}

martin

bug#12419: Mouse click changes layout

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 1327 bytes --]

 > Ahem, not so sure what you'd want here.  But playing with your
 >
 >  >   emacs -Q
 >  >   (message (make-string 1000 ?a))
 >  >   C-x C-e
 >
 > example, which btw. give me only 8 lines, whit the initial quote out of
 > sight, you can easily reproduce this:
 >
 > Split *scratch* horizontally

... vertically (the new window is below the old one) ...

 > and then click on the 1 of 1000.

... in the new, lower window.

 > The
 > minibuffer shrinks, the 1 is blinking, but the mouse is no over the n of
 > notes, which slid down.  When letting go, the n blinks and all up to
 > before 1000 is marked.

I can see that.

 > Independently of resizing, something similar happens for sideways
 > scrolling:  Split *scratch* vertically, click on the v of visit,

What is the "v of visit"?

 > nothing
 > happens (that's where it dffers).  But then move the mouse 1 char right,
 > this triggers a sideways scroll.  The mouse is now over the e of file.
 > When letting go, it marks "visit that fil" but worse, it scrolls yet
 > again by the same amount, so that the mouse is now at the end of the
 > line, far from the text it marked.
 >
 > I'd expect both cases to consistently do something only when I release
 > the mouse, or when I drag to outside the window to force scrolling.

Can you try the attached patch?

Thanks, martin

[-- Attachment #2: resize-root-window-vertically.diff --]
[-- Type: text/plain, Size: 2560 bytes --]

=== modified file 'lisp/window.el'
--- lisp/window.el	2012-09-16 04:52:38 +0000
+++ lisp/window.el	2012-09-16 17:38:02 +0000
@@ -2394,27 +2394,32 @@
 This function is only called by the minibuffer window resizing
 routines.  It resizes windows proportionally and never deletes
 any windows."
-  (when (numberp delta)
-    (let (ignore)
-      (cond
-       ((< delta 0)
-	(setq delta (window-sizable window delta)))
-       ((> delta 0)
-	(unless (window-sizable window delta)
-	  (setq ignore t))))
-
-      (window--resize-reset (window-frame window))
-      ;; Ideally, we would resize just the last window in a combination
-      ;; but that's not feasible for the following reason: If we grow
-      ;; the minibuffer window and the last window cannot be shrunk any
-      ;; more, we shrink another window instead.  But if we then shrink
-      ;; the minibuffer window again, the last window might get enlarged
-      ;; and the state after shrinking is not the state before growing.
-      ;; So, in practice, we'd need a history variable to record how to
-      ;; proceed.  But I'm not sure how such a variable could work with
-      ;; repeated minibuffer window growing steps.
-      (window--resize-this-window window delta nil ignore t)
-      delta)))
+  (let (ignore)
+    (cond
+     ((not (numberp delta))
+      (setq delta 0))
+     ((zerop delta))
+     ((< delta 0)
+      (setq delta (window-sizable window delta))
+      (window--resize-reset (window-frame window))
+      ;; When shrinking the root window, emulate an edge drag in order
+      ;; to not resize other windows if we can avoid it (Bug#12419).
+      (window--resize-this-window
+       window delta nil ignore t 'before
+       (+ (window-top-line window) (window-total-size window)))
+      ;; Don't record new normal sizes to make sure that shrinking back
+      ;; proportionally works as intended.
+      (walk-window-tree
+       (lambda (window) (set-window-new-normal window 'ignore))))
+     ((> delta 0)
+      (window--resize-reset (window-frame window))
+      (unless (window-sizable window delta)
+	(setq ignore t))
+      ;; When growing the root window, resize proportionally.  This
+      ;; should give windows back their original sizes (hopefully).
+      (window--resize-this-window window delta nil ignore t)))
+     ;; Return the possibly adjusted DELTA.
+     delta))
 
 (defun adjust-window-trailing-edge (window delta &optional horizontal)
   "Move WINDOW's bottom edge by DELTA lines.

bug#12419: Mouse click changes layout

[Daniel Pfeiffer]

Oops, sorry, I missed this one.

la 09/16/2012 07:45 PM martin rudalics skribis:
> > Ahem, not so sure what you'd want here.  But playing with your
> >
> >  >   emacs -Q
> >  >   (message (make-string 1000 ?a))
> >  >   C-x C-e
> >
> > example, which btw. give me only 8 lines, whit the initial quote out of
> > sight, you can easily reproduce this:
> >
> > Split *scratch* horizontally
>
> ... vertically (the new window is below the old one) ...

Matter of viewpoint, the split is horizontal, the resulting windows are 
stacked vertically.  Apparently the commands are now called ...below and 
...right, to avoid this confusion.

> > and then click on the 1 of 1000.
>
> ... in the new, lower window.
>
> > The
> > minibuffer shrinks, the 1 is blinking, but the mouse is no over the n of
> > notes, which slid down.  When letting go, the n blinks and all up to
> > before 1000 is marked.
>
> I can see that.
>
> > Independently of resizing, something similar happens for sideways
> > scrolling:  Split *scratch* vertically, click on the v of visit,
>
> What is the "v of visit"?

In the default text Emacs puts into that buffer (if you did exactly like I 
wrote), there is the word visit, which obviously contains a v.

> > nothing
> > happens (that's where it dffers).  But then move the mouse 1 char right,
> > this triggers a sideways scroll.  The mouse is now over the e of file.
> > When letting go, it marks "visit that fil" but worse, it scrolls yet
> > again by the same amount, so that the mouse is now at the end of the
> > line, far from the text it marked.
> >
> > I'd expect both cases to consistently do something only when I release
> > the mouse, or when I drag to outside the window to force scrolling.
>
> Can you try the attached patch?

I now did, but in neither split direction anything seems to have changed from 
what I described before.

coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn
Daniel Pfeiffer

-- 
lerne / learn / apprends / lär dig / ucz się    Esperanto:
                     http://lernu.net  /  http://ikurso.net

bug#12419: Mouse click changes layout

[martin rudalics]

 >> Can you try the attached patch?
 >
 > I now did, but in neither split direction anything seems to have changed
 > from what I described before.

Let's look at your first scenario with emacs -Q: Do

C-x 2

C-x o

and in the lower window insert the form

(message (make-string 1000 ?a))

so the buffer *scratch* now contains this text:


;; This buffer is for notes you don't want to save, and for Lisp evaluation.
;; If you want to create a file, visit that file with C-x C-f,
;; then enter the text in that file's own buffer.

(message (make-string 1000 ?a))


Now evaluate the form inserted - the minibuffer window resizes and the
divider line between the upper and lower normal window moves up.  Still
in the lower window press the left mouse button down (but don't release
it) with the mouse pointer on the "1" of the "1000".  Now release the
left mouse button and the region starting with the word "notes" up to
the space before "1000" gets higlighted.

This is the behavior I observe with an unpatched Emacs trunk.  With the
patch, the divider line between the upper and lower window does not move
and there's no region highlighting when I release the mouse button.


The second scenario you sketched is

 > Independently of resizing, something similar happens for sideways
 > scrolling: Split *scratch* vertically, click on the v of visit, nothing
 > happens (that's where it dffers).  But then move the mouse 1 char right,
 > this triggers a sideways scroll.  The mouse is now over the e of file.
 > When letting go, it marks "visit that fil" but worse, it scrolls yet
 > again by the same amount, so that the mouse is now at the end of the
 > line, far from the text it marked.

I suppose what you mean here with emacs -Q is:

C-x 3

Now if I click in any of the two windows on the "v" of the word "visit",
I get the same sideways scroll behavior with my Emacs 23.3, Emacs 24.1
and the current trunk regardless of how long I keep the button pressed.

martin

bug#12419: Mouse click changes layout

[Daniel Pfeiffer]

Hi Martin,

thanks for going into so much detail!

la 09/23/2012 11:21 AM martin rudalics skribis:
> >> Can you try the attached patch?
> >
> > I now did, but in neither split direction anything seems to have changed
> > from what I described before.
>
> Let's look at your first scenario with emacs -Q: Do
>
> C-x 2
>
> C-x o
>
> and in the lower window insert the form
>
> (message (make-string 1000 ?a))
>
> so the buffer *scratch* now contains this text:
>
>
> ;; This buffer is for notes you don't want to save, and for Lisp evaluation.
> ;; If you want to create a file, visit that file with C-x C-f,
> ;; then enter the text in that file's own buffer.
>
> (message (make-string 1000 ?a))
>
>
> Now evaluate the form inserted - the minibuffer window resizes and the
> divider line between the upper and lower normal window moves up. Still
> in the lower window press the left mouse button down (but don't release
> it) with the mouse pointer on the "1" of the "1000".  Now release the
> left mouse button and the region starting with the word "notes" up to
> the space before "1000" gets higlighted.
>
> This is the behavior I observe with an unpatched Emacs trunk. With the
> patch, the divider line between the upper and lower window does not move
> and there's no region highlighting when I release the mouse button.

Well, you have me dumbfounded here.  To be honest I actually tried your patch 
in my configured Emacs.  Since it didn't seem to catch on, I even opened the 
file, and reevaluated the defun you patched. Now however I can no longer 
reproduce it even there :-(  Shame on me, I'm clueless...

However my first informatics lesson the professor told us: the most common bug 
is being off by one.  That is alas still the case with your patch: After C-x 2 
the lower window is one row higher than the upper one.  After our little 
experiment, it's the other way round, with this result:  When letting go of 
the mouse, I still marked to the line above, which is now in the position of 
my mouse-down event.  Sounds like an integer division rounding problem, though 
I don't see such a thing in your patch.  If both windows together have an even 
number of rows (by resizing the frame) it's fine.

If however I split either of the two windows again (even the top one, which is 
out of reach of the resizing echo area) the disturbing new before-your-patch 
behaviour comes back.

> The second scenario you sketched is
>
> > Independently of resizing, something similar happens for sideways
> > scrolling: Split *scratch* vertically, click on the v of visit, nothing
> > happens (that's where it dffers).  But then move the mouse 1 char right,
> > this triggers a sideways scroll.  The mouse is now over the e of file.
> > When letting go, it marks "visit that fil" but worse, it scrolls yet
> > again by the same amount, so that the mouse is now at the end of the
> > line, far from the text it marked.
>
> I suppose what you mean here with emacs -Q is:
>
> C-x 3
>
> Now if I click in any of the two windows on the "v" of the word "visit",
> I get the same sideways scroll behavior with my Emacs 23.3, Emacs 24.1
> and the current trunk regardless of how long I keep the button pressed.

The point is moving the mouse over to the i, which causes the 1st scroll, and 
then letting go, which causes the scrolled region to be marked, plus it causes 
a 2nd scroll by the same amount.  So the point is now far from the highlighted 
part.  I guess this comes from a different code location.  Only the user 
experience feels to me like both cases should be consistent with one another.

coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn
Daniel Pfeiffer

-- 
lerne / learn / apprends / lär dig / ucz się    Esperanto:
                     http://lernu.net  /  http://ikurso.net

bug#12419: Mouse click changes layout

[martin rudalics]

 > However my first informatics lesson the professor told us: the most
 > common bug is being off by one.  That is alas still the case with your
 > patch: After C-x 2 the lower window is one row higher than the upper
 > one.  After our little experiment, it's the other way round, with this
 > result:  When letting go of the mouse, I still marked to the line above,
 > which is now in the position of my mouse-down event.  Sounds like an
 > integer division rounding problem, though I don't see such a thing in
 > your patch.  If both windows together have an even number of rows (by
 > resizing the frame) it's fine.

You should get a similar behavior if you have a root window with an odd
number of lines, split that window via C-x 2, shrink the frame by one
line, and enlarge it again by one line: The upper window has stolen one
line from the lower one.  As a matter of fact, this is not an off-by-one
error but more deeply rooted in the history of Emacs' window handling.
You can skip the following explanation if you want.

   Beginning with Emacs 24.1, windows have a normal height (a floating
   point number) which is the fraction of their ideal height wrt to their
   parent.  When you do C-x 2 the normal height of both emanating windows
   is 0.5.  However, when the original window has an odd number of lines,
   I have to give the lower window the one remaining line in order to be
   consistent with the traditional splitting behavior.  This means that,
   if the original window has 11 lines, the upper window gets 5 and the
   lower window gets 6 lines.

   If I now enlarge the parent window to 22 lines, the upper window gets
   11 (and not 10) lines and the lower window 11 (and not 12 lines).
   Sizing back the parent to 11 lines should restore the initial state
   but it doesn't because I resize windows in the "opposite" direction
   (from top to bottom/from left to right) which preferably gives
   to/steals from the topmost/leftmost window.

So I have to fix this regardless of the topic we're discussing here.

 > If however I split either of the two windows again (even the top one,
 > which is out of reach of the resizing echo area) the disturbing new
 > before-your-patch behaviour comes back.

I suppose you should try again.  If I split the top window, only the
bottom window resizes and I can't observe what you observe here.  If I
make a new bottom window instead, the line where `point' appears in that
window moves to the top of the window and I can observe the behavior.
However, I don't see any difference wrt Emacs 23 which means I do not
see a "disturbing new" before-my-patch behavior.  If you nevertheless
do, please give me a detailed step-by-step scenario I can repeat here.

 >> The second scenario you sketched is
[...]
 > The point is moving the mouse over to the i, which causes the 1st
 > scroll, and then letting go, which causes the scrolled region to be
 > marked, plus it causes a 2nd scroll by the same amount.  So the point is
 > now far from the highlighted part.  I guess this comes from a different
 > code location.  Only the user experience feels to me like both cases
 > should be consistent with one another.

OK.  I see something in this regard.  But Emacs 23 seems to behave in
exactly the same way.  Or do you see a difference?

martin

bug#12419: Mouse click changes layout

[Eli Zaretskii]

> Date: Mon, 24 Sep 2012 10:17:25 +0200
> From: martin rudalics <rudalics@gmx.at>
> Cc: 12419@debbugs.gnu.org
> 
>    Beginning with Emacs 24.1, windows have a normal height (a floating
>    point number) which is the fraction of their ideal height wrt to their
>    parent.  When you do C-x 2 the normal height of both emanating windows
>    is 0.5.  However, when the original window has an odd number of lines,
>    I have to give the lower window the one remaining line in order to be
>    consistent with the traditional splitting behavior.

Where in the code or the infrastructure do we enforce an integral
number of lines in a window?

AFAIK, the only restriction imposed by the display engine is that a
window's first line must be completely visible (unless its height is
larger than the window).  But the last line of a window can be only
partially visible.  That seems to imply that you should be able to
split a window such that each child gets exactly half, in pixels.

What am I missing?

bug#12419: Mouse click changes layout

[Daniel Pfeiffer]

Hi Martin!

la 09/24/2012 10:17 AM martin rudalics skribis:
> > However my first informatics lesson the professor told us: the most
> > common bug is being off by one.  That is alas still the case with your
> > patch: After C-x 2 the lower window is one row higher than the upper
> > one.  After our little experiment, it's the other way round, with this
> > result:  When letting go of the mouse, I still marked to the line above,
> > which is now in the position of my mouse-down event.  Sounds like an
> > integer division rounding problem, though I don't see such a thing in
> > your patch.  If both windows together have an even number of rows (by
> > resizing the frame) it's fine.
>
> You should get a similar behavior if you have a root window with an odd
> number of lines, split that window via C-x 2, shrink the frame by one
> line, and enlarge it again by one line: The upper window has stolen one
> line from the lower one.  As a matter of fact, this is not an off-by-one
> error but more deeply rooted in the history of Emacs' window handling.
> You can skip the following explanation if you want.
>
>   Beginning with Emacs 24.1, windows have a normal height (a floating
>   point number) which is the fraction of their ideal height wrt to their
>   parent.  When you do C-x 2 the normal height of both emanating windows
>   is 0.5.  However, when the original window has an odd number of lines,
>   I have to give the lower window the one remaining line in order to be
>   consistent with the traditional splitting behavior.  This means that,
>   if the original window has 11 lines, the upper window gets 5 and the
>   lower window gets 6 lines.
>
>   If I now enlarge the parent window to 22 lines, the upper window gets
>   11 (and not 10) lines and the lower window 11 (and not 12 lines).
>   Sizing back the parent to 11 lines should restore the initial state
>   but it doesn't because I resize windows in the "opposite" direction
>   (from top to bottom/from left to right) which preferably gives
>   to/steals from the topmost/leftmost window.
>
> So I have to fix this regardless of the topic we're discussing here.

Good!  Though it wouldn't annoy me so much, if it weren't that it slightly 
breaks your patch.  What is important to me, is that when I click and let go, 
the point is where I initially clicked, and since I didn't move the mouse, I 
don't want to mark anything.

As for going the "opposite" direction, I wonder if it's worth while to keep a 
history of the last n implicitly changed window configurations and try to 
revert to them wherever possible.  Might be huge task admittedly...

A somewhat related annoyance is that scrolling looses the point: scrolling 
back to where you were before, doesn't revert that. Whenever I scroll to 
somewhere, the point should go where it was last visible within those lines, 
if it had been visible there before!  This should be quite straightforward.  
Though with sideways scrolling it might be more tricky...

> > If however I split either of the two windows again (even the top one,
> > which is out of reach of the resizing echo area) the disturbing new
> > before-your-patch behaviour comes back.
>
> I suppose you should try again.  If I split the top window, only the
> bottom window resizes and I can't observe what you observe here. If I
> make a new bottom window instead, the line where `point' appears in that
> window moves to the top of the window and I can observe the behavior.
> However, I don't see any difference wrt Emacs 23 which means I do not
> see a "disturbing new" before-my-patch behavior.  If you nevertheless
> do, please give me a detailed step-by-step scenario I can repeat here.

The "disturbing new" is that (in our C-x 2 scenario) by clicking somewhere, 
the point ends up somewhere else, and without moving the mouse I've marked 
some text.  I'm fairly confident that this is a recent degradation.  (Though I 
don't have an old Emacs to try against to be sure.)  Your patch improved it, 
but not quite fixed it.

> >> The second scenario you sketched is
> [...]
> > The point is moving the mouse over to the i, which causes the 1st
> > scroll, and then letting go, which causes the scrolled region to be
> > marked, plus it causes a 2nd scroll by the same amount.  So the point is
> > now far from the highlighted part.  I guess this comes from a different
> > code location.  Only the user experience feels to me like both cases
> > should be consistent with one another.
>
> OK.  I see something in this regard.  But Emacs 23 seems to behave in
> exactly the same way.  Or do you see a difference?

I don't C-x 3 so much, so this might have been there before – I don't remember 
when it first annoyed me.  Just the occasional glitch, which on its own never 
merited heckling anybody about. Actually sideways scrolling is only neat when 
I click near the edge wanting it.  When I don't think about it, it's usually a 
hassle to get things like they were before.  Probably it should only sideways 
scroll when I drag the mouse over the window edge, like vertical scrolling.

coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn
Daniel Pfeiffer

-- 
lerne / learn / apprends / lär dig / ucz się    Esperanto:
                     http://lernu.net  /  http://ikurso.net

bug#12419: Mouse click changes layout

[Eli Zaretskii]

> Date: Tue, 25 Sep 2012 00:20:31 +0200
> From: Daniel Pfeiffer <occitan@t-online.de>
> Cc: occitan@esperanto.org, 12419@debbugs.gnu.org
> 
> A somewhat related annoyance is that scrolling looses the point: scrolling 
> back to where you were before, doesn't revert that. Whenever I scroll to 
> somewhere, the point should go where it was last visible within those lines, 
> if it had been visible there before!  This should be quite straightforward.  

Not straightforward at all, see

   http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12401

The package mentioned there might help you, though.

bug#12419: Mouse click changes layout

[martin rudalics]

 > 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.

 > AFAIK, the only restriction imposed by the display engine is that a
 > window's first line must be completely visible (unless its height is
 > larger than the window).  But the last line of a window can be only
 > partially visible.  That seems to imply that you should be able to
 > split a window such that each child gets exactly half, in pixels.

I'm afraid that many people wouldn't want that.  So even if we manage to
provide really maximized frames, the window handling code will have to
show most windows with fully visible lines.

 > What am I missing?

Not much, I suppose.  After the freeze we can set up a branch for
implementing frame and window sizes in pixels.  The display routines
will then have to be able to handle frame and window sizes specified in
pixels.  And I suppose that we want a function that calculates the
number of pixels between two buffer positions to get rid of the current
post processing mess in `fit-window-to-buffer'.

martin

bug#12419: Mouse click changes layout

[martin rudalics]

 >> So I have to fix this regardless of the topic we're discussing here.
 >
 > Good!  Though it wouldn't annoy me so much, if it weren't that it
 > slightly breaks your patch.  What is important to me, is that when I
 > click and let go, the point is where I initially clicked, and since I
 > didn't move the mouse, I don't want to mark anything.

I installed a fix by now.  Please try it.

 > As for going the "opposite" direction, I wonder if it's worth while to
 > keep a history of the last n implicitly changed window configurations
 > and try to revert to them wherever possible.  Might be huge task
 > admittedly...

Indeed.  And it might not help when the user wants a configuration that
didn't exist yet.  That's why shrinking the minibuffer shrinks it to one
line.  Anything else would require proportional resizing which people
don't like.

 > A somewhat related annoyance is that scrolling looses the point:
 > scrolling back to where you were before, doesn't revert that. Whenever I
 > scroll to somewhere, the point should go where it was last visible
 > within those lines, if it had been visible there before!  This should be
 > quite straightforward.  Though with sideways scrolling it might be more
 > tricky...

Eli already cited a corresponding thread.  As far as sideways scrolling
is concerned do you mean the disabled commands `scroll-left' and
`scroll-right'?  `scroll-restore' doesn't handle these yet but there
should be no problem doing that.

 > The "disturbing new" is that (in our C-x 2 scenario) by clicking
 > somewhere, the point ends up somewhere else, and without moving the
 > mouse I've marked some text.  I'm fairly confident that this is a recent
 > degradation.  (Though I don't have an old Emacs to try against to be
 > sure.)  Your patch improved it, but not quite fixed it.

Please come up with a precise scenario so I can reproduce it.

 > I don't C-x 3 so much, so this might have been there before – I don't
 > remember when it first annoyed me.  Just the occasional glitch, which on
 > its own never merited heckling anybody about. Actually sideways
 > scrolling is only neat when I click near the edge wanting it.  When I
 > don't think about it, it's usually a hassle to get things like they were
 > before.  Probably it should only sideways scroll when I drag the mouse
 > over the window edge, like vertical scrolling.

I suppose the problem with automatic sideways scrolling you see is that
the positions of `point' and the mouse cursor do not coincide after an
autscroll.  But something like this happens all the time.  Start
mouse-marking text somewhere in the middle of a line and move the mouse
down until you encounter an empty line.  `point' will be at the
beginning of the line and the mouse cursor around the column where it
was before.  IIUC, the primary importance here is to keep the mouse
cursor from jumping around.

martin

bug#12419: Mouse click changes layout

[Eli Zaretskii]

> Date: Tue, 25 Sep 2012 11:58:04 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: occitan@esperanto.org, 12419@debbugs.gnu.org
> 
>  > 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?

>  > AFAIK, the only restriction imposed by the display engine is that a
>  > window's first line must be completely visible (unless its height is
>  > larger than the window).  But the last line of a window can be only
>  > partially visible.  That seems to imply that you should be able to
>  > split a window such that each child gets exactly half, in pixels.
> 
> I'm afraid that many people wouldn't want that.

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.

> 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.

>  > What am I missing?
> 
> Not much, I suppose.  After the freeze we can set up a branch for
> implementing frame and window sizes in pixels.

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.

> 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?

bug#12419: Mouse click changes layout

[martin rudalics]

 >>  > 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

[Eli Zaretskii]

> Date: Tue, 25 Sep 2012 16:12:39 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: occitan@esperanto.org, 12419@debbugs.gnu.org
> 
>  >>  > 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.

That's true, but I don't think this is relevant to the issue.  What
_is_ relevant is that these functions divide an odd number N of lines
in the window being split into an ⌈N/2⌉-line window and an ⌊N/2⌋-line
window, like an 11-line window being split into 6 and 5 lines.  _This_
is the self-imposed restriction we need to remove; what should happen
instead is that (in a GUI session) an N-line window is always split
into 2 ⌈N/2⌉-line windows.

The number of lines in a window is needed for the display engine to
allocate glyph matrices required to display the window.  Having the
size of each child window at ⌈N/2⌉ will ensure the right dimensions of
the glyph matrices, because even a partially-visible line needs a row
in the matrix.  There are no other restrictions in the display engine,
AFAIK, that require an integral number of lines to be displayed in a
window.

Note that on a TTY, there are no partially-visible lines, and the
window glyph matrices are just parts of a single frame-based matrix,
so the current way of dividing N lines should be kept for TTY.

>  >> 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.

It happens already today: with some customizations of frame parameters
the last line of a single-window frame is not fully visible already,
albeit only slightly so.  This happens since Emacs 21.1 introduced the
special faces of the mode line, which take a few more pixels than a
normal text line in the default face.  E.g., I have this in my .emacs:

  (add-to-list 'default-frame-alist '(font . "-outline-Courier New-normal-r-normal-normal-15-112-96-96-c-90-iso8859-1"))
  (add-to-list 'default-frame-alist '(height . 50))

With these customizations, Emacs doesn't let me put the cursor on the
last line: it scrolls the window, because the last line is not
fully-visible.  I don't think we've heard any complaints about this.

>  > 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.

Sorry, I don't follow: which mouse code did you have in mind, and why
would it report incongruent results?

> And likely, window resizing will get inconsistent over time.

Again, please elaborate.

>  >> 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.

fit-window-to-buffer tries to avoid partially-visible lines.  That's
not always required, or maybe I don't understand why you need a
function that calculates the number of pixels between two positions.

bug#12419: Mouse click changes layout

[martin rudalics]

 > That's true, but I don't think this is relevant to the issue.  What
 > _is_ relevant is that these functions divide an odd number N of lines
 > in the window being split into an ⌈N/2⌉-line window and an ⌊N/2⌋-line
 > window, like an 11-line window being split into 6 and 5 lines.  _This_
 > is the self-imposed restriction we need to remove;

Agreed.

 > what should happen
 > instead is that (in a GUI session) an N-line window is always split
 > into 2 ⌈N/2⌉-line windows.

... which can be partially truncated so we will have 2 ⌊N/2⌋-full-line
windows.

 > The number of lines in a window is needed for the display engine to
 > allocate glyph matrices required to display the window.  Having the
 > size of each child window at ⌈N/2⌉ will ensure the right dimensions of
 > the glyph matrices, because even a partially-visible line needs a row
 > in the matrix.  There are no other restrictions in the display engine,
 > AFAIK, that require an integral number of lines to be displayed in a
 > window.

I suppose so since otherwise we would have seen bugs earlier.  A silly
question: Does the `display-engine' draw over a previous column/row or
does it clip it?

 > Note that on a TTY, there are no partially-visible lines, and the
 > window glyph matrices are just parts of a single frame-based matrix,
 > so the current way of dividing N lines should be kept for TTY.

OK

 > It happens already today: with some customizations of frame parameters
 > the last line of a single-window frame is not fully visible already,
 > albeit only slightly so.  This happens since Emacs 21.1 introduced the
 > special faces of the mode line, which take a few more pixels than a
 > normal text line in the default face.  E.g., I have this in my .emacs:
 >
 >   (add-to-list 'default-frame-alist '(font . "-outline-Courier New-normal-r-normal-normal-15-112-96-96-c-90-iso8859-1"))
 >   (add-to-list 'default-frame-alist '(height . 50))
 >
 > With these customizations, Emacs doesn't let me put the cursor on the
 > last line: it scrolls the window, because the last line is not
 > fully-visible.  I don't think we've heard any complaints about this.

I have

  '(mode-line ((t (:background "#000040" :foreground "wheat" :box (:line-width 2 :color "#000040") :weight bold :family "Verdana"))))

which does similar things.  In addition I use maximized frames which
sometimes cover my entire display and sometimes don't.  I suppose many
people have learned to live with such shortcomings when they have
customizations.  But what about people who did not customize anything and
expect the old "integral lines" behavior.

 > Sorry, I don't follow: which mouse code did you have in mind, and why
 > would it report incongruent results?

Take make_lispy_position.  It has

       /* Pixel coordinates relative to the window corner.  */
       int wx = XINT (x) - WINDOW_LEFT_EDGE_X (w);
       int wy = XINT (y) - WINDOW_TOP_EDGE_Y (w);

where

#define WINDOW_TOP_EDGE_Y(W) \
   (((WINDOW_MENU_BAR_P (W) || WINDOW_TOOL_BAR_P (W)) \
     ? 0 : FRAME_INTERNAL_BORDER_WIDTH (WINDOW_XFRAME (W))) \
    + WINDOW_TOP_EDGE_LINE (W) * WINDOW_FRAME_LINE_HEIGHT (W))

Now if the lower window of a two windows frame does not start at an
integral number of lines this will not DTRT.  Or am I missing something?

 >> And likely, window resizing will get inconsistent over time.
 >
 > Again, please elaborate.

Consider a two window frame, the upper window has 5 lines the lower
window has 6 lines but in fact both are shown with 5.5 lines.  Now I
enlarge the upper window by one line.  Currently this makes a 6 to 5
lines frame.  Would it make a 6.5 to 4.5 frame with the new code or a 6
to 5 lines frame?

 >> 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.
 >
 > fit-window-to-buffer tries to avoid partially-visible lines.  That's
 > not always required, or maybe I don't understand why you need a
 > function that calculates the number of pixels between two positions.

For implementing something like `count-screen-lines-to-pixels' and get
rid of that crazy loop where we calculate `pos-visible-in-window-p' and
resize the window.

martin

bug#12419: Mouse click changes layout

[Eli Zaretskii]

>  > The number of lines in a window is needed for the display engine to
>  > allocate glyph matrices required to display the window.  Having the
>  > size of each child window at ⌈N/2⌉ will ensure the right dimensions of
>  > the glyph matrices, because even a partially-visible line needs a row
>  > in the matrix.  There are no other restrictions in the display engine,
>  > AFAIK, that require an integral number of lines to be displayed in a
>  > window.
> 
> I suppose so since otherwise we would have seen bugs earlier.  A silly
> question: Does the `display-engine' draw over a previous column/row or
> does it clip it?

Sorry, I don't understand what you mean by "drawing over a previous
column/row".  Which "previous" column/row are we talking about?

>  > Sorry, I don't follow: which mouse code did you have in mind, and why
>  > would it report incongruent results?
> 
> Take make_lispy_position.  It has
> 
>        /* Pixel coordinates relative to the window corner.  */
>        int wx = XINT (x) - WINDOW_LEFT_EDGE_X (w);
>        int wy = XINT (y) - WINDOW_TOP_EDGE_Y (w);
> 
> where
> 
> #define WINDOW_TOP_EDGE_Y(W) \
>    (((WINDOW_MENU_BAR_P (W) || WINDOW_TOOL_BAR_P (W)) \
>      ? 0 : FRAME_INTERNAL_BORDER_WIDTH (WINDOW_XFRAME (W))) \
>     + WINDOW_TOP_EDGE_LINE (W) * WINDOW_FRAME_LINE_HEIGHT (W))
> 
> Now if the lower window of a two windows frame does not start at an
> integral number of lines this will not DTRT.  Or am I missing something?

A window must always start with a fully-visible line (unless it's the
only line), so in that sense a window always starts at an integral
number of lines.  But it doesn't have to _end_ with a fully-visible
line.

Does this explain why the above is not a problem?

>  >> And likely, window resizing will get inconsistent over time.
>  >
>  > Again, please elaborate.
> 
> Consider a two window frame, the upper window has 5 lines the lower
> window has 6 lines but in fact both are shown with 5.5 lines.

Can't happen: a window that displays 5.5 lines must have 6 lines, or
else the glyphs for the last half-line will have no place in the glyph
matrix.

> Now I
> enlarge the upper window by one line.  Currently this makes a 6 to 5
> lines frame.  Would it make a 6.5 to 4.5 frame with the new code or a 6
> to 5 lines frame?

It's up to us.  The easiest (and also the least surprising, IMO) would
be to resize from (5.5, 5.5) to (6.5, 4.5), i.e. by one full line.

>  >> 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.
>  >
>  > fit-window-to-buffer tries to avoid partially-visible lines.  That's
>  > not always required, or maybe I don't understand why you need a
>  > function that calculates the number of pixels between two positions.
> 
> For implementing something like `count-screen-lines-to-pixels' and get
> rid of that crazy loop where we calculate `pos-visible-in-window-p' and
> resize the window.

I think pos-visible-in-window-p is what you need.

bug#12419: Mouse click changes layout

[martin rudalics]

 > Sorry, I don't understand what you mean by "drawing over a previous
 > column/row".  Which "previous" column/row are we talking about?

For example, when we draw the mode-line of a window: Do we first clip
the glyphs on the bottom of the last proper line of the window or do we
draw them unclipped and afterwards draw the mode-line on top of it so it
obscures the lower part of the window line?

 > A window must always start with a fully-visible line (unless it's the
 > only line), so in that sense a window always starts at an integral
 > number of lines.  But it doesn't have to _end_ with a fully-visible
 > line.
 >
 > Does this explain why the above is not a problem?

Yes.  So the event reporting mechanism fully supports windows that
display partially visible lines.

 >> Consider a two window frame, the upper window has 5 lines the lower
 >> window has 6 lines but in fact both are shown with 5.5 lines.
 >
 > Can't happen: a window that displays 5.5 lines must have 6 lines, or
 > else the glyphs for the last half-line will have no place in the glyph
 > matrix.

Let's say the TTY equivalent of the upper window would display 5 lines.

 >> Now I
 >> enlarge the upper window by one line.  Currently this makes a 6 to 5
 >> lines frame.  Would it make a 6.5 to 4.5 frame with the new code or a 6
 >> to 5 lines frame?
 >
 > It's up to us.  The easiest (and also the least surprising, IMO) would
 > be to resize from (5.5, 5.5) to (6.5, 4.5), i.e. by one full line.

In this case the TTY equivalent would display (6, 5) lines.

 >> For implementing something like `count-screen-lines-to-pixels' and get
 >> rid of that crazy loop where we calculate `pos-visible-in-window-p' and
 >> resize the window.
 >
 > I think pos-visible-in-window-p is what you need.

Currently it loops calling `pos-visible-in-window-p' until the position
is visible.  How avoid that loop?

martin

bug#12419: Mouse click changes layout

[Eli Zaretskii]

> Date: Wed, 26 Sep 2012 14:43:22 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: occitan@esperanto.org, 12419@debbugs.gnu.org
> 
>  > Sorry, I don't understand what you mean by "drawing over a previous
>  > column/row".  Which "previous" column/row are we talking about?
> 
> For example, when we draw the mode-line of a window: Do we first clip
> the glyphs on the bottom of the last proper line of the window or do we
> draw them unclipped and afterwards draw the mode-line on top of it so it
> obscures the lower part of the window line?

It's the other way around: first the window is cleared, then we draw
the mode line, and only then the window text.  So the last line is
already drawn only partially to begin with (I believe this is done by
the display back-end, in *term.c, by clipping the drawn glyphs to the
dimensions of the text area, but I'm not an expert on these back-ends).

>  >> Consider a two window frame, the upper window has 5 lines the lower
>  >> window has 6 lines but in fact both are shown with 5.5 lines.
>  >
>  > Can't happen: a window that displays 5.5 lines must have 6 lines, or
>  > else the glyphs for the last half-line will have no place in the glyph
>  > matrix.
> 
> Let's say the TTY equivalent of the upper window would display 5 lines.

And the lower one 6, OK.

>  >> Now I
>  >> enlarge the upper window by one line.  Currently this makes a 6 to 5
>  >> lines frame.  Would it make a 6.5 to 4.5 frame with the new code or a 6
>  >> to 5 lines frame?
>  >
>  > It's up to us.  The easiest (and also the least surprising, IMO) would
>  > be to resize from (5.5, 5.5) to (6.5, 4.5), i.e. by one full line.
> 
> In this case the TTY equivalent would display (6, 5) lines.

Yes.  Is that a problem?  pos-visible-in-window-p can still tell
whether the resize reached its goal of exposing the text you want, no?

>  >> For implementing something like `count-screen-lines-to-pixels' and get
>  >> rid of that crazy loop where we calculate `pos-visible-in-window-p' and
>  >> resize the window.
>  >
>  > I think pos-visible-in-window-p is what you need.
> 
> Currently it loops calling `pos-visible-in-window-p' until the position
> is visible.  How avoid that loop?

I think the loop isn't needed for the application you have in mind.
But if it is, can you show a concrete use case where just using that
function gives bad results for measuring pixel distance between buffer
positions?

bug#12419: Mouse click changes layout

[martin rudalics]

 >> In this case the TTY equivalent would display (6, 5) lines.
 >
 > Yes.  Is that a problem?

Not principally.  At least nothing we should care about initially.

 > pos-visible-in-window-p can still tell
 > whether the resize reached its goal of exposing the text you want, no?

I didn't care about `pos-visible-in-window-p' in this example.

 > I think the loop isn't needed for the application you have in mind.
 > But if it is, can you show a concrete use case where just using that
 > function gives bad results for measuring pixel distance between buffer
 > positions?

I didn't write that loop (IIRC Kenichi Handa wrote it).  The sheer
presence of it however seems to indicate that `pos-visible-in-window-p'
might have given an off-by-one-line answer when `point' is on the last
line of a window, at least back in 2000.  Maybe this a non-issue now.

martin

bug#12419: Mouse click changes layout

[Eli Zaretskii]

> Date: Wed, 26 Sep 2012 15:44:43 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: occitan@esperanto.org, 12419@debbugs.gnu.org
> 
>  > I think the loop isn't needed for the application you have in mind.
>  > But if it is, can you show a concrete use case where just using that
>  > function gives bad results for measuring pixel distance between buffer
>  > positions?
> 
> I didn't write that loop (IIRC Kenichi Handa wrote it).  The sheer
> presence of it however seems to indicate that `pos-visible-in-window-p'
> might have given an off-by-one-line answer when `point' is on the last
> line of a window, at least back in 2000.  Maybe this a non-issue now.

I think that loop wants to make sure the last line is fully visible;
pos-visible-in-window-p does not return nil for partially-visible
lines.  I don't think partial visibility is an issue in the context of
finding pixel distance between two buffer positions.

bug#12419: Mouse click changes layout

[Lars Ingebrigtsen]

martin rudalics <rudalics@gmx.at> writes:

> Let's look at your first scenario with emacs -Q: Do
>
> C-x 2
>
> C-x o
>
> and in the lower window insert the form
>
> (message (make-string 1000 ?a))
>
> so the buffer *scratch* now contains this text:
>
> ;; This buffer is for notes you don't want to save, and for Lisp evaluation.
> ;; If you want to create a file, visit that file with C-x C-f,
> ;; then enter the text in that file's own buffer.
>
> (message (make-string 1000 ?a))
>
> Now evaluate the form inserted - the minibuffer window resizes and the
> divider line between the upper and lower normal window moves up.

This is a very long seven year old bug report, and I've just skimmed it.

But I tried this recipe for reproduction, and it does not reproduce
here, at least.

So has the stuff that's discussed here been fixed over the years?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#12419: Mouse click changes layout

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> But I tried this recipe for reproduction, and it does not reproduce
> here, at least.
>
> So has the stuff that's discussed here been fixed over the years?

More information was requested, but no response was given within a few
months, so I'm closing this bug report.  If the problem still exists,
please respond to this email and we'll reopen the bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no