GNU bug report logs -
#79351
30.2; window-resize-symbollwise
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
> Tested with the latest stable Emacs. Really like that behaviour,
> didn't notice thank you!
It's still not as smooth as I want it. The basic idea is to keep the
mode line as close to the mouse cursor as possible. This is problematic
since the mouse is usually dragged with constant speed while the mode
line jumps (we could have it snap back at the end of dragging but that's
an annoying effect I'd like to avoid). And it's particularly tricky
when a user reverts the dragging direction after overshooting.
One aspect the previous patch did not handle was the residue that
results when you have, for example, a character height of 22 pixels and
a mouse move of 18 or 40 pixels gets reported. In that case I now have
the remaining 18 pixels be handled in the next move. The results look
better here, please try the attached patch.
> However looks like there's another issue unrelated to the window
> splitting: for some reason, during frame resize, despite it going
> line-by-line, the window afterwards is slightly cutted and has
> slightly less than a whole number height.
You mean to say that a new frame has entire lines and the effect gets
visible only after resizing? In either case, please file a new bug
report with the screenshot included. In addition we would have to know:
- The build details as for a standard bug report (Emacs version, toolkit
and so on).
- The window manager you use.
- The frame geometry in the bad state. For this purpose do
M-: (window--dump-frame)
in that state. This should get you a buffer *window--dump-frame*
whose contents might tell what went wrong.
Thanks, martin
[drag-line.diff (text/x-patch, attachment)]
This bug report was last modified 2 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.