GNU bug report logs -
#28605
26.0.60; Part of leftmost character hidden
Previous Next
Reported by: Ola Nilsson <ola.nilsson <at> gmail.com>
Date: Tue, 26 Sep 2017 09:54:02 UTC
Severity: normal
Found in version 26.0.60
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 28605 in the body.
You can then email your comments to 28605 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Tue, 26 Sep 2017 09:54:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Ola Nilsson <ola.nilsson <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Tue, 26 Sep 2017 09:54:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Whenever I'm using two side-by-side windows, part of the leftmost
character in the right-side window is hidden.
This is when I use the Gnome HiDPI window scaling set to 2 to make text
readable on my 4K screen.
The problem is visible with emacs -Q --no-x-resources.
Turing on display-line-numbers-mode hides the problem, at least with the
default settings.
To reproduce:
emacs -Q --no-x-resources
M-x split-window-right
toggle the hidpi window scaling between 1 and 2.
I'm trying to attach a screenshot.
/Ola
[Screenshot from 2017-09-26 11-50-13.png (image/png, attachment)]
[Message part 3 (text/plain, inline)]
In GNU Emacs 26.0.60 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.14.5)
of 2017-09-22 built on lnxolani1
Repository revision: d24ec5854098841388dfecf2c668e7f48f348af0
Windowing system distributor 'The X.Org Foundation', version 11.0.11604000
System Description: Debian GNU/Linux 8.9 (jessie)
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Quit
Making completion list...
Configured using:
'configure --prefix=/opt/emacs/26'
Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS NOTIFY
ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 LCMS2
Important settings:
value of $LC_CTYPE: en_US.UTF-8
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Load-path shadows:
None found.
Features:
(shadow sort mail-extr emacsbug message subr-x puny seq byte-opt gv
bytecomp byte-compile cconv cl-loaddefs cl-lib dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg
epg-config gnus-util rmail rmail-loaddefs mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils elec-pair time-date
mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode elisp-mode lisp-mode prog-mode register page menu-bar
rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core term/tty-colors frame cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting move-toolbar gtk
x-toolkit x multi-tty make-network-process emacs)
Memory information:
((conses 16 94980 7152)
(symbols 48 20380 1)
(miscs 40 42 118)
(strings 32 28398 1362)
(string-bytes 1 735822)
(vectors 16 14036)
(vector-slots 8 490291 11606)
(floats 8 53 90)
(intervals 56 216 0)
(buffers 992 12)
(heap 1024 29846 1215))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Wed, 27 Sep 2017 08:13:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 28605 <at> debbugs.gnu.org (full text, mbox):
> Whenever I'm using two side-by-side windows, part of the leftmost
> character in the right-side window is hidden.
>
> This is when I use the Gnome HiDPI window scaling set to 2 to make text
> readable on my 4K screen.
>
> The problem is visible with emacs -Q --no-x-resources.
> Turing on display-line-numbers-mode hides the problem, at least with the
> default settings.
>
> To reproduce:
> emacs -Q --no-x-resources
> M-x split-window-right
> toggle the hidpi window scaling between 1 and 2.
>
> I'm trying to attach a screenshot.
This could be bug#27830 reported by Kaushal Modi. IIUC the left fringe
is completely missing in the window on the right. Correct?
Please play around a bit with some settings: Turning on/off scroll bars,
moving them to the left, and reducing/enlarging the size of the left
fringe. Also yet another C-x 3 to see whether only the last window on
the right is affected. Maybe this could get us some insight.
And please also try with two variable settings: ‘frame-resize-pixelwise’
and ‘window-resize-pixelwise’ changed to non-nil, independently and
simultaneously.
Thanks in advance, martin
PS: Do you observe any strange positioning when popping up menus? Some
people using window scaling of 2 have reported such behavior.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Fri, 29 Sep 2017 07:46:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 28605 <at> debbugs.gnu.org (full text, mbox):
On Wed, Sep 27, 2017 at 10:12 AM, martin rudalics <rudalics <at> gmx.at> wrote:
>> Whenever I'm using two side-by-side windows, part of the leftmost
>> character in the right-side window is hidden.
>>
>> This is when I use the Gnome HiDPI window scaling set to 2 to make text
>> readable on my 4K screen.
>>
>> The problem is visible with emacs -Q --no-x-resources.
>> Turing on display-line-numbers-mode hides the problem, at least with the
>> default settings.
>>
>> To reproduce:
>> emacs -Q --no-x-resources
>> M-x split-window-right
>> toggle the hidpi window scaling between 1 and 2.
>>
>> I'm trying to attach a screenshot.
>
> This could be bug#27830 reported by Kaushal Modi. IIUC the left fringe
> is completely missing in the window on the right. Correct?
It does seem the fringe is missing, but there is some other vertical bar
of empty space present.
> Please play around a bit with some settings: Turning on/off scroll bars,
> moving them to the left, and reducing/enlarging the size of the left
> fringe. Also yet another C-x 3 to see whether only the last window on
> the right is affected. Maybe this could get us some insight.
Turning off the scroll bar (scrollbar-mode nil) makes the fringe appear,
and the characters are fully visible.
Switching scroll bars off and from left to right with several
side-by-side windows
shows that it is all window edges that are next to a scroll bar that
are affected.
The fringe is hidden, and the character at the edge is partially hidden.
The hidden character is a lot less obvious on the right side of a window.
> And please also try with two variable settings: ‘frame-resize-pixelwise’
> and ‘window-resize-pixelwise’ changed to non-nil, independently and
> simultaneously.
I'm not sure I did this right; I set the variables with customize and then
moved window and frame edges around a bit.
Made no difference as far as I can tell.
> Thanks in advance, martin
>
> PS: Do you observe any strange positioning when popping up menus? Some
> people using window scaling of 2 have reported such behavior.
I hadn't noticed anything, so I tested
* mouse-1 on the size-indicator on the mode line, no problem
* clicking on the menus of the menu bar, no problem.
if there is something else you want me to try, please let me know.
I have noticed that the first menu i click in the menu bar does not
open, but if I then
use F10 to open the menu and step to it it will open fine after that.
Maybe it is
positioned somewhere I cannot see it?
--
Ola Nilsson
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Fri, 29 Sep 2017 08:37:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 28605 <at> debbugs.gnu.org (full text, mbox):
> It does seem the fringe is missing, but there is some other vertical bar
> of empty space present.
In fact, it appears so from the screenshot you sent.
> Turning off the scroll bar (scrollbar-mode nil) makes the fringe appear,
> and the characters are fully visible.
From earlier reports, this seems to connect the problem to scaling. To
make sure: You do not observe anything the like with scaling turned off?
> Switching scroll bars off and from left to right with several
> side-by-side windows
> shows that it is all window edges that are next to a scroll bar that
> are affected.
You mean that the scroll bar from the window on the left affects the
things displayed in the window on the right? We clear the background of
the scroll bars here and there. Can you build Emacs yourself? I could
try to make up a (non-sensical) patch which would turn these clearings
off to find out whether this is indeed the culprit.
> I'm not sure I did this right; I set the variables with customize and then
> moved window and frame edges around a bit.
> Made no difference as far as I can tell.
OK. I'm afraid that we sometimes don't draw things correctly on screen
with scaling turned on. Maybe it's just x_fill_rectangle and/or
x_clear_area which are incompatible with GTK's ideas of scaling.
Two additional things you could try in this context: Can your turn on
window dividers and, independently, horizontal scroll bars (both from
the Options Show/Hide menu) and look whether they cause additional
problems?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Fri, 29 Sep 2017 10:47:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 28605 <at> debbugs.gnu.org (full text, mbox):
On Fri, Sep 29, 2017 at 10:36 AM, martin rudalics <rudalics <at> gmx.at> wrote:
>> It does seem the fringe is missing, but there is some other vertical bar
>> of empty space present.
>
> In fact, it appears so from the screenshot you sent.
>
>> Turning off the scroll bar (scrollbar-mode nil) makes the fringe appear,
>> and the characters are fully visible.
>
> From earlier reports, this seems to connect the problem to scaling. To
> make sure: You do not observe anything the like with scaling turned off?
I've only seen this on my work system with Debian 8 and the hidpi monitor.
I tried on my home system with debian 9 and an old non-hidpi monitor and
did not see the problem. Remoting to my work machine and exporting the
emacs window through X, and then using the scaling on my home system
did not show the problem.
>> Switching scroll bars off and from left to right with several
>> side-by-side windows
>> shows that it is all window edges that are next to a scroll bar that
>> are affected.
>
> You mean that the scroll bar from the window on the left affects the
> things displayed in the window on the right?
Yes, the scroll bar affects the window on both sides. It's only the frame edge
with no scroll bar that shows a fringe.
> We clear the background of
> the scroll bars here and there. Can you build Emacs yourself? I could
> try to make up a (non-sensical) patch which would turn these clearings
> off to find out whether this is indeed the culprit.
I do build emacs myself, this is all on the emacs-26 branch. I can
rebuild with a patch.
>> I'm not sure I did this right; I set the variables with customize and then
>> moved window and frame edges around a bit.
>> Made no difference as far as I can tell.
>
> OK. I'm afraid that we sometimes don't draw things correctly on screen
> with scaling turned on. Maybe it's just x_fill_rectangle and/or
> x_clear_area which are incompatible with GTK's ideas of scaling.
The hidpi scaling in gnome works only so far, and I'm not sure all of gtk
is aware of the setting. But then I know next to nothing about gtk.
The menu-bar and scroll-bars get decent size, but I select a larger font
for emacs using X resources (turned off for the report). I noticed
yesterday that the fringes are dis-proportionally narrow and the fringe
symbols almost unreadable.
> Two additional things you could try in this context: Can your turn on
> window dividers and, independently, horizontal scroll bars (both from
> the Options Show/Hide menu) and look whether they cause additional
> problems?
I've had horizontal scroll bars disabled the entire time. I'll try the dividers
when I'm back at my machine again.
--
Ola Nilsson
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Fri, 29 Sep 2017 18:19:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 28605 <at> debbugs.gnu.org (full text, mbox):
>> You mean that the scroll bar from the window on the left affects the
>> things displayed in the window on the right?
>
> Yes, the scroll bar affects the window on both sides. It's only the frame edge
> with no scroll bar that shows a fringe.
Can you please be a bit more precise: How would the scroll bar affect
the window on _both_ sides? Does the scroll bar also affect the
contents of the window it belongs to?
> The hidpi scaling in gnome works only so far, and I'm not sure all of gtk
> is aware of the setting. But then I know next to nothing about gtk.
> The menu-bar and scroll-bars get decent size, but I select a larger font
> for emacs using X resources (turned off for the report). I noticed
> yesterday that the fringes are dis-proportionally narrow and the fringe
> symbols almost unreadable.
On a frame with such bad fringes please do
M-: (window--dump-frame) RET
This should get you a buffer with the name *window-frame-dump*. Please
post the contents of that buffer here.
Thanks, martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Mon, 02 Oct 2017 09:19:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 28605 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Fri, Sep 29, 2017 at 8:18 PM, martin rudalics <rudalics <at> gmx.at> wrote:
>>> You mean that the scroll bar from the window on the left affects the
>>> things displayed in the window on the right?
>>
>> Yes, the scroll bar affects the window on both sides. It's only the frame
>> edge
>> with no scroll bar that shows a fringe.
>
> Can you please be a bit more precise: How would the scroll bar affect
> the window on _both_ sides? Does the scroll bar also affect the
> contents of the window it belongs to?
If the frame contains three side-by-side windows and scroll bars on
the right I expect to see (from left to right):
frame border
left fringe for window one
window one
right fringe for window one
scroll bar for window one
right fringe for window two
window two
left fringe for window two
scroll bar for window two
right fringe for window three
window three
left fringe for window three
scroll bar for window three
frame border
Of all the fringes, only the left fringe of window one is visible.
Using scroll bars on the left, only the right fringe of window three
is visible.
In both cases, characters that are next to non-visible/hidden fringes
are partially hidden.
I'm attaching two screenshots that should show this.
I bit the bullet and did a git bisect:
36cf0791ba75ee16dfbedfe437567ec6dd945b8a is the first bad commit
commit 36cf0791ba75ee16dfbedfe437567ec6dd945b8a
Author: Lars Ingebrigtsen <larsi <at> gnus.org>
Date: Sun Jul 16 16:50:57 2017 +0200
Remove usage of the GDK_SCALE variable
* src/gtkutil.c (xg_get_gdk_scale): Remove.
(xg_get_default_scrollbar_height)
(xg_get_default_scrollbar_width): Pass in a frame to check for
scaling.
(xg_frame_set_char_size): Use the API for querying scale
instead of looking at the GDK_SCALE variable.
(xg_get_default_scrollbar_width): Ditto.
(xg_get_default_scrollbar_height): Ditto.
(xg_update_scrollbar_pos): Ditto.
* src/xfns.c (x_set_scroll_bar_default_height): Pass in the
frame to get the width.
I also played with the dividers and horizontal scroll bars.
The horizontal scroll bars are not visibla at all with scaling on.
Dividers on the right fixed the hidden character problem but not the
hidden fringes,
I attach some screenshots of this as well.
>> The hidpi scaling in gnome works only so far, and I'm not sure all of gtk
>> is aware of the setting. But then I know next to nothing about gtk.
>> The menu-bar and scroll-bars get decent size, but I select a larger font
>> for emacs using X resources (turned off for the report). I noticed
>> yesterday that the fringes are dis-proportionally narrow and the fringe
>> symbols almost unreadable.
>
> On a frame with such bad fringes please do
>
> M-: (window--dump-frame) RET
This is with emacs -Q --no-x-resources, dividers off, horizontal scrollbars off.
frame pixel: 2034 x 466 cols/lines: 226 x 25 units: 9 x 18
frame text pixel: 1992 x 466 cols/lines: 221 x 25
tool: 0 scroll: 26/0 fringe: 16 border: 0 right: 0 bottom: 0
#<window 5> parent: nil
pixel left: 0 top: 0 size: 2034 x 448 new: 448
char left: 0 top: 0 size: 226 x 25 new: 25
normal: 1.0 x 1.0 new: nil
#<window 3 on *scratch*> parent: #<window 5>
pixel left: 0 top: 0 size: 1020 x 448 new: 448
char left: 0 top: 0 size: 113 x 25 new: 25
normal: 0.5 x 1.0 new: nil
body pixel: 978 x 430 char: 108 x 23
width left fringe: 8 left margin: 0 right margin: 0
width right fringe: 8 scroll-bar: 26 divider: 0
height header-line: 0 mode-line: 18 divider: 0
#<window 6 on *scratch*> parent: #<window 5>
pixel left: 1020 top: 0 size: 1014 x 448 new: 448
char left: 113 top: 0 size: 113 x 25 new: 25
normal: 0.5 x 1.0 new: nil
body pixel: 972 x 430 char: 108 x 23
width left fringe: 8 left margin: 0 right margin: 0
width right fringe: 8 scroll-bar: 26 divider: 0
height header-line: 0 mode-line: 18 divider: 0
#<window 4 on *Minibuf-0*> parent: nil
pixel left: 0 top: 448 size: 2034 x 18 new: 0
char left: 0 top: 25 size: 226 x 1 new: 1
normal: 1.0 x 1.0 new: 0
body pixel: 1992 x 18 char: 221 x 1
width left fringe: 8 left margin: 0 right margin: 0
width right fringe: 8 scroll-bar: 26 divider: 0
height header-line: 0 mode-line: 0 divider: 0
--
Ola Nilsson
[with-hidpi-scaling.png (image/png, attachment)]
[without-hidpi-scaling.png (image/png, attachment)]
[horizontal-scrollbars-no-dividers.png (image/png, attachment)]
[horizontal-scrollbars-right-dividers.png (image/png, attachment)]
[no-horizontal-scrollbars-right-dividers.png (image/png, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Tue, 03 Oct 2017 09:17:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 28605 <at> debbugs.gnu.org (full text, mbox):
> If the frame contains three side-by-side windows and scroll bars on
> the right I expect to see (from left to right):
>
> frame border
> left fringe for window one
> window one
> right fringe for window one
> scroll bar for window one
> right fringe for window two
> window two
> left fringe for window two
> scroll bar for window two
> right fringe for window three
> window three
> left fringe for window three
> scroll bar for window three
> frame border
>
> Of all the fringes, only the left fringe of window one is visible.
> Using scroll bars on the left, only the right fringe of window three
> is visible.
> In both cases, characters that are next to non-visible/hidden fringes
> are partially hidden.
> I'm attaching two screenshots that should show this.
Thanks for the details. From your initial screenshot it was not clear
to me that the effect is really that bad.
> I bit the bullet and did a git bisect:
>
> 36cf0791ba75ee16dfbedfe437567ec6dd945b8a is the first bad commit
> commit 36cf0791ba75ee16dfbedfe437567ec6dd945b8a
> Author: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Sun Jul 16 16:50:57 2017 +0200
> Remove usage of the GDK_SCALE variable
>
> * src/gtkutil.c (xg_get_gdk_scale): Remove.
> (xg_get_default_scrollbar_height)
> (xg_get_default_scrollbar_width): Pass in a frame to check for
> scaling.
> (xg_frame_set_char_size): Use the API for querying scale
> instead of looking at the GDK_SCALE variable.
> (xg_get_default_scrollbar_width): Ditto.
> (xg_get_default_scrollbar_height): Ditto.
> (xg_update_scrollbar_pos): Ditto.
>
> * src/xfns.c (x_set_scroll_bar_default_height): Pass in the
> frame to get the width.
Great. Lars, how should we proceed from here?
(1) Revert that commit.
(2) Revert the call of gtk_widget_get_scale_factor only.
(3) Try to fix the build with your change in place.
(4) Provide some option so that users can either use your approach or
Jan's. The default should prefer Jan's setup to avoid that users
like Ola have to go through this again.
> I also played with the dividers and horizontal scroll bars.
>
> The horizontal scroll bars are not visibla at all with scaling on.
Apparently, the horizontal scroll bar code does not handle scaling. If
we fix the current problem, maybe you could help me fix that one too.
> Dividers on the right fixed the hidden character problem but not the
> hidden fringes,
Yes. IMHO it's because the scroll bar clearing code hides the dividers
instead of the text. If you customize dividers to a sufficiently large
width you should be able to make the entire text visible and even parts
of the dividers (on the left side of a window, only - the right sides
will remain obscured as before).
> I attach some screenshots of this as well.
Very informative, thanks. One thing that stupefies me about these
screenshots is that the menu and toolbar items are smaller in
horizontal-scrollbars-no-dividers.png than in with-hidpi-scaling.png.
> This is with emacs -Q --no-x-resources, dividers off, horizontal scrollbars off.
>
> frame pixel: 2034 x 466 cols/lines: 226 x 25 units: 9 x 18
[...]
> height header-line: 0 mode-line: 0 divider: 0
All these values are completely as expected so the problem must be
confined to this x_clear_area call in xg_update_scrollbar_pos in
gtkutil.c
/* Clear under old scroll bar position. */
oldw += (scale - 1) * oldw;
oldx -= (scale - 1) * oldw;
x_clear_area (f, oldx, oldy, oldw, oldh);
where the value of scale is now obtained via
int scale = xg_get_scale (f);
If you replace the latter by the old
int scale = xg_get_gdk_scale ();
does your problem go away? If so, then it would be interesting how the
values returned by xg_get_scale differ with gtk_widget_get_scale_factor
and xg_get_gdk_scale called.
Thanks, martin
CC-ing Kaushal Modi: Is this the same problem as the one you posted in
Bug#27830?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Tue, 03 Oct 2017 09:29:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 28605 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
> Great. Lars, how should we proceed from here?
>
> (1) Revert that commit.
Rather not, because it makes using Emacs on Ubuntu 17.04 with a hiDPI
display very awkward.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Tue, 03 Oct 2017 12:13:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 28605 <at> debbugs.gnu.org (full text, mbox):
On Tue, Oct 3, 2017 at 11:15 AM, martin rudalics <rudalics <at> gmx.at> wrote:
>> If the frame contains three side-by-side windows and scroll bars on
>> the right I expect to see (from left to right):
>>
>> frame border
>> left fringe for window one
>> window one
>> right fringe for window one
>> scroll bar for window one
>> right fringe for window two
>> window two
>> left fringe for window two
>> scroll bar for window two
>> right fringe for window three
>> window three
>> left fringe for window three
>> scroll bar for window three
>> frame border
>>
>> Of all the fringes, only the left fringe of window one is visible.
>> Using scroll bars on the left, only the right fringe of window three
>> is visible.
>> In both cases, characters that are next to non-visible/hidden fringes
>> are partially hidden.
>> I'm attaching two screenshots that should show this.
>
> Thanks for the details. From your initial screenshot it was not clear
> to me that the effect is really that bad.
>
>> I bit the bullet and did a git bisect:
>>
>> 36cf0791ba75ee16dfbedfe437567ec6dd945b8a is the first bad commit
>> commit 36cf0791ba75ee16dfbedfe437567ec6dd945b8a
>> Author: Lars Ingebrigtsen <larsi <at> gnus.org>
>> Date: Sun Jul 16 16:50:57 2017 +0200
>> Remove usage of the GDK_SCALE variable
>>
>> * src/gtkutil.c (xg_get_gdk_scale): Remove.
>> (xg_get_default_scrollbar_height)
>> (xg_get_default_scrollbar_width): Pass in a frame to check for
>> scaling.
>> (xg_frame_set_char_size): Use the API for querying scale
>> instead of looking at the GDK_SCALE variable.
>> (xg_get_default_scrollbar_width): Ditto.
>> (xg_get_default_scrollbar_height): Ditto.
>> (xg_update_scrollbar_pos): Ditto.
>>
>> * src/xfns.c (x_set_scroll_bar_default_height): Pass in the
>> frame to get the width.
>
> Great. Lars, how should we proceed from here?
>
> (1) Revert that commit.
>
> (2) Revert the call of gtk_widget_get_scale_factor only.
>
> (3) Try to fix the build with your change in place.
>
> (4) Provide some option so that users can either use your approach or
> Jan's. The default should prefer Jan's setup to avoid that users
> like Ola have to go through this again.
>
>> I also played with the dividers and horizontal scroll bars.
>>
>> The horizontal scroll bars are not visibla at all with scaling on.
>
> Apparently, the horizontal scroll bar code does not handle scaling. If
> we fix the current problem, maybe you could help me fix that one too.
>
>> Dividers on the right fixed the hidden character problem but not the
>> hidden fringes,
>
> Yes. IMHO it's because the scroll bar clearing code hides the dividers
> instead of the text. If you customize dividers to a sufficiently large
> width you should be able to make the entire text visible and even parts
> of the dividers (on the left side of a window, only - the right sides
> will remain obscured as before).
>
>> I attach some screenshots of this as well.
>
> Very informative, thanks. One thing that stupefies me about these
> screenshots is that the menu and toolbar items are smaller in
> horizontal-scrollbars-no-dividers.png than in with-hidpi-scaling.png.
>
>> This is with emacs -Q --no-x-resources, dividers off, horizontal
>> scrollbars off.
>>
>> frame pixel: 2034 x 466 cols/lines: 226 x 25 units: 9 x 18
> [...]
>> height header-line: 0 mode-line: 0 divider: 0
>
> All these values are completely as expected so the problem must be
> confined to this x_clear_area call in xg_update_scrollbar_pos in
> gtkutil.c
>
> /* Clear under old scroll bar position. */
> oldw += (scale - 1) * oldw;
> oldx -= (scale - 1) * oldw;
> x_clear_area (f, oldx, oldy, oldw, oldh);
>
> where the value of scale is now obtained via
>
> int scale = xg_get_scale (f);
>
> If you replace the latter by the old
>
> int scale = xg_get_gdk_scale ();
>
> does your problem go away? If so, then it would be interesting how the
> values returned by xg_get_scale differ with gtk_widget_get_scale_factor
> and xg_get_gdk_scale called.
Made no difference what I can see, except a lot of messages :
(emacs:2302): Gtk-CRITICAL **: gtk_distribute_natural_allocation:
assertion 'extra_space >= 0' failed
I tested with dividers and horizontal scrollbars with the same results
as before.
--
Ola Nilsson
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Tue, 03 Oct 2017 13:10:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 28605 <at> debbugs.gnu.org (full text, mbox):
Ola Nilsson <ola.nilsson <at> gmail.com> writes:
>> does your problem go away? If so, then it would be interesting how the
>> values returned by xg_get_scale differ with gtk_widget_get_scale_factor
>> and xg_get_gdk_scale called.
>
> Made no difference what I can see, except a lot of messages :
>
> (emacs:2302): Gtk-CRITICAL **: gtk_distribute_natural_allocation:
> assertion 'extra_space >= 0' failed
Through inspection I noticed we're not adjusting the width of the
scrollbar for the scale. Does the following help?
diff --git a/src/gtkutil.c b/src/gtkutil.c
index 0da7039..60ba627 100644
--- a/src/gtkutil.c
+++ b/src/gtkutil.c
@@ -3879,6 +3879,7 @@ xg_update_scrollbar_pos (struct frame *f,
top /= scale;
left /= scale;
height /= scale;
+ width /= scale;
left -= (scale - 1) * ((width / scale) >> 1);
/* Clear out old position. */
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Tue, 03 Oct 2017 15:27:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 28605 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Tue, Oct 3, 2017 at 5:16 AM martin rudalics <rudalics <at> gmx.at> wrote:
> Thanks for the details. From your initial screenshot it was not clear
> to me that the effect is really that bad.
>
I don't see that bad of an effect. I only see, may be a pixel of the left
side of the fringe getting truncated.
> CC-ing Kaushal Modi: Is this the same problem as the one you posted in
> Bug#27830?
>
Thanks for looping me in. Here's a little gif that shows the problem. Looks
like the problem shows up only when disabling both scroll bars AND window
dividers (I have them off by default).
https://i.imgur.com/cqJHTzU.gifv
It might be difficult to see even in this gif.. but we are looking for a
green bracket covering all the newly added lines after the last git commit
(diff-hl package). Notice that the vertical part of the green bracket in
the fringe hides when both scroll-bar and window dividers are hidden.
@martin Apologies for not being able to follow up in my debbugs thread
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27830 I'll find some time
today to provide you with more debug info in that thread. In the meanwhile,
see if this gif provides you any hints.
-----
--
Kaushal Modi
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Tue, 03 Oct 2017 15:50:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 28605 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Tue, Oct 3, 2017 at 3:08 PM, Robert Pluim <rpluim <at> gmail.com> wrote:
> Ola Nilsson <ola.nilsson <at> gmail.com> writes:
>
>>> does your problem go away? If so, then it would be interesting how the
>>> values returned by xg_get_scale differ with gtk_widget_get_scale_factor
>>> and xg_get_gdk_scale called.
>>
>> Made no difference what I can see, except a lot of messages :
>>
>> (emacs:2302): Gtk-CRITICAL **: gtk_distribute_natural_allocation:
>> assertion 'extra_space >= 0' failed
>
> Through inspection I noticed we're not adjusting the width of the
> scrollbar for the scale. Does the following help?
>
> diff --git a/src/gtkutil.c b/src/gtkutil.c
> index 0da7039..60ba627 100644
> --- a/src/gtkutil.c
> +++ b/src/gtkutil.c
> @@ -3879,6 +3879,7 @@ xg_update_scrollbar_pos (struct frame *f,
> top /= scale;
> left /= scale;
> height /= scale;
> + width /= scale;
> left -= (scale - 1) * ((width / scale) >> 1);
>
> /* Clear out old position. */
This works for me:
@@ -3883,7 +3883,7 @@ xg_update_scrollbar_pos (struct frame *f,
top /= scale;
left /= scale;
height /= scale;
- left -= (scale - 1) * ((width / scale) >> 1);
+ width /= scale;
/* Clear out old position. */
int oldx = -1, oldy = -1, oldw, oldh;
Screenshots included.
The horizontal scroll bars are still no-show.
As a funny side effect, each time I turn vertical scrollbars on or off
(not switching sides) the frame shrinks with about two lines.
--
Ola Nilsson
[ok.png (image/png, attachment)]
[ok-dividers.png (image/png, attachment)]
[horizontal-still-not-ok.png (image/png, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Tue, 03 Oct 2017 16:59:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 28605 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Oct 3, 2017 17:49, "Ola Nilsson" <ola.nilsson <at> gmail.com> wrote:
On Tue, Oct 3, 2017 at 3:08 PM, Robert Pluim <rpluim <at> gmail.com> wrote:
> Ola Nilsson <ola.nilsson <at> gmail.com> writes:
>
>>> does your problem go away? If so, then it would be interesting how the
>>> values returned by xg_get_scale differ with gtk_widget_get_scale_factor
>>> and xg_get_gdk_scale called.
>>
>> Made no difference what I can see, except a lot of messages :
>>
>> (emacs:2302): Gtk-CRITICAL **: gtk_distribute_natural_allocation:
>> assertion 'extra_space >= 0' failed
>
> Through inspection I noticed we're not adjusting the width of the
> scrollbar for the scale. Does the following help?
>
> diff --git a/src/gtkutil.c b/src/gtkutil.c
> index 0da7039..60ba627 100644
> --- a/src/gtkutil.c
> +++ b/src/gtkutil.c
> @@ -3879,6 +3879,7 @@ xg_update_scrollbar_pos (struct frame *f,
> top /= scale;
> left /= scale;
> height /= scale;
> + width /= scale;
> left -= (scale - 1) * ((width / scale) >> 1);
>
> /* Clear out old position. */
This works for me:
@@ -3883,7 +3883,7 @@ xg_update_scrollbar_pos (struct frame *f,
top /= scale;
left /= scale;
height /= scale;
- left -= (scale - 1) * ((width / scale) >> 1);
+ width /= scale;
/* Clear out old position. */
int oldx = -1, oldy = -1, oldw, oldh;
I just realized that I never tested with scaling off.
/Ola Nilsson
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Wed, 04 Oct 2017 06:49:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 28605 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Tue, Oct 3, 2017 at 6:58 PM, Ola Nilsson <ola.nilsson <at> gmail.com> wrote:
>
>
> On Oct 3, 2017 17:49, "Ola Nilsson" <ola.nilsson <at> gmail.com> wrote:
>
> On Tue, Oct 3, 2017 at 3:08 PM, Robert Pluim <rpluim <at> gmail.com> wrote:
>> Ola Nilsson <ola.nilsson <at> gmail.com> writes:
>>
>>>> does your problem go away? If so, then it would be interesting how the
>>>> values returned by xg_get_scale differ with gtk_widget_get_scale_factor
>>>> and xg_get_gdk_scale called.
>>>
>>> Made no difference what I can see, except a lot of messages :
>>>
>>> (emacs:2302): Gtk-CRITICAL **: gtk_distribute_natural_allocation:
>>> assertion 'extra_space >= 0' failed
>>
>> Through inspection I noticed we're not adjusting the width of the
>> scrollbar for the scale. Does the following help?
>>
>> diff --git a/src/gtkutil.c b/src/gtkutil.c
>> index 0da7039..60ba627 100644
>> --- a/src/gtkutil.c
>> +++ b/src/gtkutil.c
>> @@ -3879,6 +3879,7 @@ xg_update_scrollbar_pos (struct frame *f,
>> top /= scale;
>> left /= scale;
>> height /= scale;
>> + width /= scale;
>> left -= (scale - 1) * ((width / scale) >> 1);
>>
>> /* Clear out old position. */
>
> This works for me:
>
> @@ -3883,7 +3883,7 @@ xg_update_scrollbar_pos (struct frame *f,
> top /= scale;
> left /= scale;
> height /= scale;
> - left -= (scale - 1) * ((width / scale) >> 1);
> + width /= scale;
>
> /* Clear out old position. */
> int oldx = -1, oldy = -1, oldw, oldh;
>
>
> I just realized that I never tested with scaling off.
I did some more tests this morning.
With scaling set to 1 (off) the scroll bars look like the attached screenshot.
But they look like that without the patch I sent too.
I have not noticed this on my other system where I have a normal monitor.
--
Ola Nilsson
[Screenshot from 2017-10-04 08-42-14.png (image/png, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Wed, 04 Oct 2017 09:04:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 28605 <at> debbugs.gnu.org (full text, mbox):
> Made no difference what I can see, except a lot of messages :
>
> (emacs:2302): Gtk-CRITICAL **: gtk_distribute_natural_allocation:
> assertion 'extra_space >= 0' failed
Hmmm... I could have sworn that using xg_get_gdk_scale would have tried
to clear entirely within the region cleared by xg_get_scale. Apparently
I failed or some boundaries became negative instead.
Sorry for the miss, martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Wed, 04 Oct 2017 09:06:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 28605 <at> debbugs.gnu.org (full text, mbox):
> This works for me:
>
> @@ -3883,7 +3883,7 @@ xg_update_scrollbar_pos (struct frame *f,
> top /= scale;
> left /= scale;
> height /= scale;
> - left -= (scale - 1) * ((width / scale) >> 1);
> + width /= scale;
Deceptively simple. Whatever was that left rigmarole needed for?
What changes with
width /= scale;
left -= (scale - 1) * (width >> 1);
> The horizontal scroll bars are still no-show.
With scaling on their positions are apparently off-window. Some
clearing effect is visible in horizontal-still-not-ok.png but might be
off as well.
> As a funny side effect, each time I turn vertical scrollbars on or off
> (not switching sides) the frame shrinks with about two lines.
This would be too strange. I suppose it comes from turning on and off
_horizontal_ scroll bars. Just as turning vertical scroll bars on and
off should shrink your frame by about two columns.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Wed, 04 Oct 2017 09:07:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 28605 <at> debbugs.gnu.org (full text, mbox):
>> I just realized that I never tested with scaling off.
>
> I did some more tests this morning.
>
> With scaling set to 1 (off) the scroll bars look like the attached screenshot.
> But they look like that without the patch I sent too.
> I have not noticed this on my other system where I have a normal monitor.
IIUC this is a GTK idiosyncrasy where the scroll bar width is determined
by the theme and Emacs cannot deal with it correctly.
See update_theme_scrollbar_width in gtkutil.c
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Wed, 04 Oct 2017 10:00:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 28605 <at> debbugs.gnu.org (full text, mbox):
On Wed, Oct 4, 2017 at 11:05 AM, martin rudalics <rudalics <at> gmx.at> wrote:
>On Tue, Oct 3, 2017 at 6:58 PM, Ola Nilsson <ola.nilsson <at> gmail.com> wrote:
>> This works for me:
>>
>> @@ -3883,7 +3883,7 @@ xg_update_scrollbar_pos (struct frame *f,
>> top /= scale;
>> left /= scale;
>> height /= scale;
>> - left -= (scale - 1) * ((width / scale) >> 1);
>> + width /= scale;
>
> Deceptively simple. Whatever was that left rigmarole needed for?
> What changes with
>
> width /= scale;
> left -= (scale - 1) * (width >> 1);
From the top of my head, the vertical scrollbar is placed to far to the left
overlapping the window to the left and leaving a white band between the
scroll bar and the left-fringe of the window to the right.
It does nothing if scale is 1, obviously.
--
Ola Nilsson
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Wed, 04 Oct 2017 11:58:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 28605 <at> debbugs.gnu.org (full text, mbox):
Ola Nilsson <ola.nilsson <at> gmail.com> writes:
> On Wed, Oct 4, 2017 at 11:05 AM, martin rudalics <rudalics <at> gmx.at> wrote:
>>On Tue, Oct 3, 2017 at 6:58 PM, Ola Nilsson <ola.nilsson <at> gmail.com> wrote:
>>> This works for me:
>>>
>>> @@ -3883,7 +3883,7 @@ xg_update_scrollbar_pos (struct frame *f,
>>> top /= scale;
>>> left /= scale;
>>> height /= scale;
>>> - left -= (scale - 1) * ((width / scale) >> 1);
>>> + width /= scale;
>>
>> Deceptively simple. Whatever was that left rigmarole needed for?
>> What changes with
>>
>> width /= scale;
>> left -= (scale - 1) * (width >> 1);
>
> From the top of my head, the vertical scrollbar is placed to far to the left
> overlapping the window to the left and leaving a white band between the
> scroll bar and the left-fringe of the window to the right.
> It does nothing if scale is 1, obviously.
Yes, I think removing the calculation for left is the correct fix (at
least it looks correct here). The horizontal scrollbars need fixing as
well, see below. xg_update_scrollbar_pos and xg_update_horizontal_scrollbar_pos
are now 99% identical apart from the 'hidden' check.
I don't think this will be the final version: I sometimes get the echo
area being the wrong size...
diff --git a/src/gtkutil.c b/src/gtkutil.c
index 0da7039..b41e8f1 100644
--- a/src/gtkutil.c
+++ b/src/gtkutil.c
@@ -3879,7 +3879,7 @@ xg_update_scrollbar_pos (struct frame *f,
top /= scale;
left /= scale;
height /= scale;
- left -= (scale - 1) * ((width / scale) >> 1);
+ width /= scale;
/* Clear out old position. */
int oldx = -1, oldy = -1, oldw, oldh;
@@ -3955,6 +3955,12 @@ xg_update_horizontal_scrollbar_pos (struct frame *f,
GtkWidget *wfixed = f->output_data.x->edit_widget;
GtkWidget *wparent = gtk_widget_get_parent (wscroll);
gint msl;
+ int scale = xg_get_scale (f);
+
+ top /= scale;
+ left /= scale;
+ height /= scale;
+ width /= scale;
/* Clear out old position. */
int oldx = -1, oldy = -1, oldw, oldh;
@@ -3981,8 +3987,12 @@ xg_update_horizontal_scrollbar_pos (struct frame *f,
gtk_widget_set_size_request (wscroll, width, height);
}
if (oldx != -1 && oldw > 0 && oldh > 0)
- /* Clear under old scroll bar position. */
- x_clear_area (f, oldx, oldy, oldw, oldh);
+ {
+ /* Clear under old scroll bar position. */
+ oldw += (scale - 1) * oldw;
+ oldx -= (scale - 1) * oldw;
+ x_clear_area (f, oldx, oldy, oldw, oldh);
+ }
/* GTK does not redraw until the main loop is entered again, but
if there are no X events pending we will not enter it. So we sync
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Thu, 05 Oct 2017 08:11:01 GMT)
Full text and
rfc822 format available.
Message #65 received at 28605 <at> debbugs.gnu.org (full text, mbox):
> Yes, I think removing the calculation for left is the correct fix (at
> least it looks correct here). The horizontal scrollbars need fixing as
> well, see below.
Looks good to me. Ola, can you check whether Robert's patch fixes
horizontal scroll bars on your system?
> xg_update_scrollbar_pos and xg_update_horizontal_scrollbar_pos
> are now 99% identical apart from the 'hidden' check.
Could you refactor them? Note that unless you have done so already, you
will probably have to sign papers anyway so that we can install your
patch. If you don't sign, we can probably apply the fix for vertical
scroll bars at most. Eli will decide how to proceed then.
> I don't think this will be the final version: I sometimes get the echo
> area being the wrong size...
How? Is the mode line of the window above fully visible or does the
horizontal scroll bar overdraw the mode line of its window and the echo
area?
Thanks for your continuous efforts to get this working, martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Thu, 05 Oct 2017 09:44:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 28605 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>> Yes, I think removing the calculation for left is the correct fix (at
>> least it looks correct here). The horizontal scrollbars need fixing as
>> well, see below.
>
> Looks good to me. Ola, can you check whether Robert's patch fixes
> horizontal scroll bars on your system?
The horizontal fix is somewhat cargo-culted from the vertical case,
so I'm not 100% sure that this hunk is correct (why is it only
adjusting the width and the x position? Should it adjust the height/y
for the horizontal case?):
+ {
+ /* Clear under old scroll bar position. */
+ oldw += (scale - 1) * oldw;
+ oldx -= (scale - 1) * oldw;
+ x_clear_area (f, oldx, oldy, oldw, oldh);
+ }
>> xg_update_scrollbar_pos and xg_update_horizontal_scrollbar_pos
>> are now 99% identical apart from the 'hidden' check.
>
> Could you refactor them?
Not until I or somebody else understands them better :-)
> Note that unless you have done so already, you
> will probably have to sign papers anyway so that we can install your
> patch. If you don't sign, we can probably apply the fix for vertical
> scroll bars at most. Eli will decide how to proceed then.
I sent off a request to assign <at> gnu.org more than a month ago, and have
heard nothing back (and have also pinged the copyright clerk at the
FSF). Help?
Worst case I can put the changes in the public domain.
>> I don't think this will be the final version: I sometimes get the echo
>> area being the wrong size...
>
> How? Is the mode line of the window above fully visible or does the
> horizontal scroll bar overdraw the mode line of its window and the echo
> area?
False alarm. Looks like my window manager is not giving Emacs the
correct height when I maximize the frame, so the window behind it was
showing through (although I guess that could also be an Emacs bug,
just not related to this one, since it happens without scroll bars).
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Thu, 05 Oct 2017 11:58:01 GMT)
Full text and
rfc822 format available.
Message #71 received at 28605 <at> debbugs.gnu.org (full text, mbox):
On Thu, Oct 5, 2017 at 10:10 AM, martin rudalics <rudalics <at> gmx.at> wrote:
>> Yes, I think removing the calculation for left is the correct fix (at
>> least it looks correct here). The horizontal scrollbars need fixing as
>> well, see below.
>
> Looks good to me. Ola, can you check whether Robert's patch fixes
> horizontal scroll bars on your system?
>
I'll try to find time before the weekend.
--
Ola Nilsson
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Thu, 05 Oct 2017 12:47:01 GMT)
Full text and
rfc822 format available.
Message #74 received at 28605 <at> debbugs.gnu.org (full text, mbox):
Robert Pluim <rpluim <at> gmail.com> writes:
> The horizontal fix is somewhat cargo-culted from the vertical case,
> so I'm not 100% sure that this hunk is correct (why is it only
> adjusting the width and the x position? Should it adjust the height/y
> for the horizontal case?):
>
> + {
> + /* Clear under old scroll bar position. */
> + oldw += (scale - 1) * oldw;
> + oldx -= (scale - 1) * oldw;
> + x_clear_area (f, oldx, oldy, oldw, oldh);
> + }
Thinking about this some more, this whole calculation just looks
wrong. oldx, oldw, oldw and oldh are in unscaled pixels, as far as I
can tell. We need to scale when using GTK routines, but x_clear_area
ends up calling X11 routines, so I've almost convinced myself that we
should in fact delete the oldw and oldx adjustments for the vertical
scrollbar rather than adding them for the horizontal one.
That code was added in commit c0055ff5b03c9121ab5bf752496b09416f0f0a7d
which is quite old, I suspect it did no real harm even though oldx
tends to end up negative, possibly x_clear_area does some kind of
clipping.
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Fri, 06 Oct 2017 08:19:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 28605 <at> debbugs.gnu.org (full text, mbox):
> The horizontal fix is somewhat cargo-culted from the vertical case,
> so I'm not 100% sure that this hunk is correct (why is it only
> adjusting the width and the x position? Should it adjust the height/y
> for the horizontal case?):
>
> + {
> + /* Clear under old scroll bar position. */
> + oldw += (scale - 1) * oldw;
> + oldx -= (scale - 1) * oldw;
> + x_clear_area (f, oldx, oldy, oldw, oldh);
> + }
>
The entire horizontal scroll bar code has been cargo-culted from the
vertical one so any adjustments should probably go the same way.
> I sent off a request to assign <at> gnu.org more than a month ago, and have
> heard nothing back (and have also pinged the copyright clerk at the
> FSF). Help?
It's relieving that you have sent a request already. Unfortunately it
seems normal that this process takes a month at least. Let's wait for
two more weeks and ask Richard if nothing happens till then - maybe he
can help us speed things up.
> False alarm. Looks like my window manager is not giving Emacs the
> correct height when I maximize the frame, so the window behind it was
> showing through (although I guess that could also be an Emacs bug,
> just not related to this one, since it happens without scroll bars).
I'm quite confident that setting ‘frame-resize-pixelwise’ to t will fix
that. Some window managers are very strict in the sense that if an
application prefers frames getting resized character-wise, that wish
prevails over the desire to maximize frames to the size of the screen.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Fri, 06 Oct 2017 08:20:01 GMT)
Full text and
rfc822 format available.
Message #80 received at 28605 <at> debbugs.gnu.org (full text, mbox):
> Thinking about this some more, this whole calculation just looks
> wrong. oldx, oldw, oldw and oldh are in unscaled pixels, as far as I
> can tell. We need to scale when using GTK routines, but x_clear_area
> ends up calling X11 routines, so I've almost convinced myself that we
> should in fact delete the oldw and oldx adjustments for the vertical
> scrollbar rather than adding them for the horizontal one.
Be sure to distinguish code that decides where to draw a scroll bar from
code that decides which area to clear and possibly redraw. Sometimes,
the area that gets cleared can be substantially larger than the area
occupied by a toolkit scroll bar. From my experience, this is often
noticeable with GTK scroll bars since their width is determined by the
chosen theme and cannot be adjusted individually by Emacs.
> That code was added in commit c0055ff5b03c9121ab5bf752496b09416f0f0a7d
> which is quite old,
... 2015 rather strikes me as "fairly recent" ...
> I suspect it did no real harm even though oldx
> tends to end up negative, possibly x_clear_area does some kind of
> clipping.
In my experience, X silently swallows anything that happens outside the
frame. GTK can be much more picky in this regard, especially when
trying to draw something outside a parent widget. But the corresponding
error messages are usually a pain to read.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Fri, 06 Oct 2017 08:38:02 GMT)
Full text and
rfc822 format available.
Message #83 received at submit <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>> Thinking about this some more, this whole calculation just looks
>> wrong. oldx, oldw, oldw and oldh are in unscaled pixels, as far as I
>> can tell. We need to scale when using GTK routines, but x_clear_area
>> ends up calling X11 routines, so I've almost convinced myself that we
>> should in fact delete the oldw and oldx adjustments for the vertical
>> scrollbar rather than adding them for the horizontal one.
>
> Be sure to distinguish code that decides where to draw a scroll bar from
> code that decides which area to clear and possibly redraw. Sometimes,
> the area that gets cleared can be substantially larger than the area
> occupied by a toolkit scroll bar. From my experience, this is often
> noticeable with GTK scroll bars since their width is determined by the
> chosen theme and cannot be adjusted individually by Emacs.
OK. The best course of action is then probably not to touch the
existing adjustments, and not to add any similar ones for the
horizontal case.
>> That code was added in commit c0055ff5b03c9121ab5bf752496b09416f0f0a7d
>> which is quite old,
>
> ... 2015 rather strikes me as "fairly recent" ...
>
Oops, I think I looked at the date on the wrong commit, I thought I'd
seen 2010.
>> I suspect it did no real harm even though oldx
>> tends to end up negative, possibly x_clear_area does some kind of
>> clipping.
>
> In my experience, X silently swallows anything that happens outside the
> frame. GTK can be much more picky in this regard, especially when
> trying to draw something outside a parent widget. But the corresponding
> error messages are usually a pain to read.
Yet another reason not to disturb the status quo.
Regards
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Fri, 06 Oct 2017 08:53:02 GMT)
Full text and
rfc822 format available.
Message #86 received at 28605 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>> The horizontal fix is somewhat cargo-culted from the vertical case,
>> so I'm not 100% sure that this hunk is correct (why is it only
>> adjusting the width and the x position? Should it adjust the height/y
>> for the horizontal case?):
>>
>> + {
>> + /* Clear under old scroll bar position. */
>> + oldw += (scale - 1) * oldw;
>> + oldx -= (scale - 1) * oldw;
>> + x_clear_area (f, oldx, oldy, oldw, oldh);
>> + }
>>
>
> The entire horizontal scroll bar code has been cargo-culted from the
> vertical one so any adjustments should probably go the same way.
It doesn't seem to make any visual difference, but if eg oldx == 0,
and oldw > 0, oldx will end up negative. That makes me uncomfortable
:-)
>> I sent off a request to assign <at> gnu.org more than a month ago, and have
>> heard nothing back (and have also pinged the copyright clerk at the
>> FSF). Help?
>
> It's relieving that you have sent a request already. Unfortunately it
> seems normal that this process takes a month at least. Let's wait for
> two more weeks and ask Richard if nothing happens till then - maybe he
> can help us speed things up.
OK, we'll wait some more.
>> False alarm. Looks like my window manager is not giving Emacs the
>> correct height when I maximize the frame, so the window behind it was
>> showing through (although I guess that could also be an Emacs bug,
>> just not related to this one, since it happens without scroll bars).
>
> I'm quite confident that setting ‘frame-resize-pixelwise’ to t will fix
> that. Some window managers are very strict in the sense that if an
> application prefers frames getting resized character-wise, that wish
> prevails over the desire to maximize frames to the size of the screen.
Hmm, I'm not sure that helps. 'toggle-frame-fullscreen' does the
correct thing, but using the maximize control in the title-bar doesn't
(but that also doesn't give me proper full screen, just full screen
minus the widget bar along the bottom of the display). I think we can
safely ignore this one and say it's my local problem.
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Fri, 06 Oct 2017 09:36:02 GMT)
Full text and
rfc822 format available.
Message #89 received at submit <at> debbugs.gnu.org (full text, mbox):
> OK. The best course of action is then probably not to touch the
> existing adjustments, and not to add any similar ones for the
> horizontal case.
Lars already touched them and IIUC provoked this bug.
>>> That code was added in commit c0055ff5b03c9121ab5bf752496b09416f0f0a7d
>>> which is quite old,
>>
>> ... 2015 rather strikes me as "fairly recent" ...
>>
>
> Oops, I think I looked at the date on the wrong commit, I thought I'd
> seen 2010.
OTOH this means that the code was not tested very intensively and Jan
didn't have much time left to improve it.
>>> I suspect it did no real harm even though oldx
>>> tends to end up negative, possibly x_clear_area does some kind of
>>> clipping.
>>
>> In my experience, X silently swallows anything that happens outside the
>> frame. GTK can be much more picky in this regard, especially when
>> trying to draw something outside a parent widget. But the corresponding
>> error messages are usually a pain to read.
>
> Yet another reason not to disturb the status quo.
To be on the safe side, we probably should leave the non-scaling parts
alone. For the scaling parts do whatever you consider appropriate. If
it fixes the behavior for Ola, we should install it and wait for
complaints.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Fri, 06 Oct 2017 09:36:02 GMT)
Full text and
rfc822 format available.
Message #92 received at 28605 <at> debbugs.gnu.org (full text, mbox):
> Hmm, I'm not sure that helps. 'toggle-frame-fullscreen' does the
> correct thing, but using the maximize control in the title-bar doesn't
> (but that also doesn't give me proper full screen, just full screen
> minus the widget bar along the bottom of the display). I think we can
> safely ignore this one and say it's my local problem.
‘toggle-frame-fullscreen’ makes a frame "fullboth" which is different
from "maximized". From the Elisp manual:
A "maximized" frame is like a "fullboth" frame, except that it
usually keeps its title bar and the buttons for resizing and
closing the frame. Also, maximized frames typically avoid hiding
any task bar or panels displayed on the desktop. A "fullboth"
frame, on the other hand, usually omits the title bar and occupies
the entire available screen space.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Fri, 06 Oct 2017 11:51:02 GMT)
Full text and
rfc822 format available.
Message #95 received at 28605 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>> OK. The best course of action is then probably not to touch the
>> existing adjustments, and not to add any similar ones for the
>> horizontal case.
>
> Lars already touched them and IIUC provoked this bug.
>
Lars' HiDPI changes were a huge improvement over what was there
before. I'm talking here only about leaving alone the x_clear_area
code, but still changing the width calculation.
>>>> That code was added in commit c0055ff5b03c9121ab5bf752496b09416f0f0a7d
>>>> which is quite old,
>>>
>>> ... 2015 rather strikes me as "fairly recent" ...
>>>
>>
>> Oops, I think I looked at the date on the wrong commit, I thought I'd
>> seen 2010.
>
> OTOH this means that the code was not tested very intensively and Jan
> didn't have much time left to improve it.
>
>>>> I suspect it did no real harm even though oldx
>>>> tends to end up negative, possibly x_clear_area does some kind of
>>>> clipping.
>>>
>>> In my experience, X silently swallows anything that happens outside the
>>> frame. GTK can be much more picky in this regard, especially when
>>> trying to draw something outside a parent widget. But the corresponding
>>> error messages are usually a pain to read.
>>
>> Yet another reason not to disturb the status quo.
>
> To be on the safe side, we probably should leave the non-scaling parts
> alone. For the scaling parts do whatever you consider appropriate. If
> it fixes the behavior for Ola, we should install it and wait for
> complaints.
OK, I'll wait for Ola confirm, then clean it up (and split it into at
least 2 to make it easier to revert).
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Sat, 07 Oct 2017 08:09:02 GMT)
Full text and
rfc822 format available.
Message #98 received at 28605 <at> debbugs.gnu.org (full text, mbox):
> Lars' HiDPI changes were a huge improvement over what was there
> before.
Can you tell me what Jan's first stab at scaling did and what Lars' did
differently? Or simpler: How do the return values of xg_get_gdk_scale
and xg_get_scale differ in practice? Because IIUC that's what these
changes boil down to in the case we're discussing here.
> I'm talking here only about leaving alone the x_clear_area
> code, but still changing the width calculation.
You mean the width of the scroll bar as it's drawn by the toolkit?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Sat, 07 Oct 2017 11:54:02 GMT)
Full text and
rfc822 format available.
Message #101 received at 28605 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
> Can you tell me what Jan's first stab at scaling did and what Lars' did
> differently? Or simpler: How do the return values of xg_get_gdk_scale
> and xg_get_scale differ in practice? Because IIUC that's what these
> changes boil down to in the case we're discussing here.
If I remember correctly, in some places it looked at the GDK_SCALE
environment variable (which is normally not set on most systems) and in
other places it queried GTK for what the scaling is, leading to general
confusion of what the frame size was supposed to be.
I should have squashed that patch series before applying instead of
merging in my branch. Merging makes it difficult to see what the
changes really are...
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Sun, 08 Oct 2017 09:52:02 GMT)
Full text and
rfc822 format available.
Message #104 received at 28605 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>> Lars' HiDPI changes were a huge improvement over what was there
>> before.
>
> Can you tell me what Jan's first stab at scaling did and what Lars' did
> differently? Or simpler: How do the return values of xg_get_gdk_scale
> and xg_get_scale differ in practice? Because IIUC that's what these
> changes boil down to in the case we're discussing here.
xg_get_gdk_scale and xg_get_scale differ in that the former only
looked at GDK_SCALE, and the latter queries the widget for its scale
factor, which will work better in environments where the scale factor
is set via the GNOME configuration utility. Lars' changes also apply
that scale in more places, resulting in eg scrollbars being at the
correct position, rather than completely off to the side of the Emacs
frame.
>> I'm talking here only about leaving alone the x_clear_area
>> code, but still changing the width calculation.
>
> You mean the width of the scroll bar as it's drawn by the toolkit?
Yes. Basically:
diff --git a/src/gtkutil.c b/src/gtkutil.c
index 0da7039..78077d7 100644
--- a/src/gtkutil.c
+++ b/src/gtkutil.c
@@ -3879,7 +3879,7 @@ xg_update_scrollbar_pos (struct frame *f,
top /= scale;
left /= scale;
height /= scale;
- left -= (scale - 1) * ((width / scale) >> 1);
+ width /= scale;
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Mon, 09 Oct 2017 08:01:02 GMT)
Full text and
rfc822 format available.
Message #107 received at 28605 <at> debbugs.gnu.org (full text, mbox):
> If I remember correctly, in some places it looked at the GDK_SCALE
> environment variable (which is normally not set on most systems) and in
> other places it queried GTK for what the scaling is, leading to general
> confusion of what the frame size was supposed to be.
OK. Are we sure that we now detect any scaling if present? Or should
we allow the user (who might know better) to explicitly supply a scaling
factor which overrides a return value of 0 (?) or 1 from the above.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Mon, 09 Oct 2017 08:01:03 GMT)
Full text and
rfc822 format available.
Message #110 received at 28605 <at> debbugs.gnu.org (full text, mbox):
> xg_get_gdk_scale and xg_get_scale differ in that the former only
> looked at GDK_SCALE, and the latter queries the widget for its scale
> factor, which will work better in environments where the scale factor
> is set via the GNOME configuration utility. Lars' changes also apply
> that scale in more places, resulting in eg scrollbars being at the
> correct position, rather than completely off to the side of the Emacs
> frame.
But we apparently still do not apply scaling everywhere, in particular
when displaying menus (Bug#27667 and Bug#28511).
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Mon, 09 Oct 2017 08:26:02 GMT)
Full text and
rfc822 format available.
Message #113 received at 28605 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>> If I remember correctly, in some places it looked at the GDK_SCALE
>> environment variable (which is normally not set on most systems) and in
>> other places it queried GTK for what the scaling is, leading to general
>> confusion of what the frame size was supposed to be.
>
> OK. Are we sure that we now detect any scaling if present? Or should
> we allow the user (who might know better) to explicitly supply a scaling
> factor which overrides a return value of 0 (?) or 1 from the above.
By "supply", do you mean setting the GDK_SCALE variable? I think that
the GTK function will pass us the right scaling factor in that case, if
I remember correctly. On modern machines, the user supplies the scaling
by using a GTK tool that doesn't set GDK_SCALE, and the GTK function
still returns the correct scaling.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Mon, 09 Oct 2017 08:27:01 GMT)
Full text and
rfc822 format available.
Message #116 received at 28605 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
> But we apparently still do not apply scaling everywhere, in particular
> when displaying menus (Bug#27667 and Bug#28511).
Yes, that's never worked, and wasn't affected by my patch set.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Mon, 09 Oct 2017 09:17:01 GMT)
Full text and
rfc822 format available.
Message #119 received at 28605 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> martin rudalics <rudalics <at> gmx.at> writes:
>
>>> If I remember correctly, in some places it looked at the GDK_SCALE
>>> environment variable (which is normally not set on most systems) and in
>>> other places it queried GTK for what the scaling is, leading to general
>>> confusion of what the frame size was supposed to be.
>>
>> OK. Are we sure that we now detect any scaling if present? Or should
>> we allow the user (who might know better) to explicitly supply a scaling
>> factor which overrides a return value of 0 (?) or 1 from the above.
>
> By "supply", do you mean setting the GDK_SCALE variable? I think that
> the GTK function will pass us the right scaling factor in that case, if
> I remember correctly. On modern machines, the user supplies the scaling
> by using a GTK tool that doesn't set GDK_SCALE, and the GTK function
> still returns the correct scaling.
That's exactly what happens, although setting the GDK_SCALE variable
directly affects the scaling factor returned from querying the widget,
in case you don't want to use the tool.
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Mon, 09 Oct 2017 12:23:02 GMT)
Full text and
rfc822 format available.
Message #122 received at 28605 <at> debbugs.gnu.org (full text, mbox):
> By "supply", do you mean setting the GDK_SCALE variable?
No. I meant an Emacs variable people would set like, for example,
‘focus-follows-mouse’.
> I think that
> the GTK function will pass us the right scaling factor in that case, if
> I remember correctly. On modern machines, the user supplies the scaling
> by using a GTK tool that doesn't set GDK_SCALE, and the GTK function
> still returns the correct scaling.
OK.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Mon, 09 Oct 2017 12:23:02 GMT)
Full text and
rfc822 format available.
Message #125 received at 28605 <at> debbugs.gnu.org (full text, mbox):
>> But we apparently still do not apply scaling everywhere, in particular
>> when displaying menus (Bug#27667 and Bug#28511).
>
> Yes, that's never worked, and wasn't affected by my patch set.
In the thread of Bug#27667 you wrote
This should be fixed on master now, I think -- at least I'm unable to
reproduce it now. Could you check and reopen if it's still an issue?
Did you write that because you presumed that once Emacs detects scaling
correctly, it would also draw menus at the correct place? Or was there
some additional reasoning involved?
I'm asking because Robert's fix for scroll bars looks so simple that it
really would be a shame if there existed no similar fix for the menus.
And there's one question that's still not completely answered: Why did
(and do) some scalers see problems with the scroll bar and/or menu
positions and others don't?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Mon, 09 Oct 2017 13:38:01 GMT)
Full text and
rfc822 format available.
Message #128 received at 28605 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
> I'm asking because Robert's fix for scroll bars looks so simple that it
> really would be a shame if there existed no similar fix for the menus.
>
It would be nice, but...
> And there's one question that's still not completely answered: Why did
> (and do) some scalers see problems with the scroll bar and/or menu
> positions and others don't?
... I see scroll bar issues, but the menus are in the right place
(although I normally have the menu-bar turned off ;-) )
It may be because I'm running under KDE. I'll see if I can get a pure
GNOME enviroment, that may behave differently.
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Mon, 09 Oct 2017 14:20:03 GMT)
Full text and
rfc822 format available.
Message #131 received at 28605 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
> In the thread of Bug#27667 you wrote
>
> This should be fixed on master now, I think -- at least I'm unable to
> reproduce it now. Could you check and reopen if it's still an issue?
>
> Did you write that because you presumed that once Emacs detects scaling
> correctly, it would also draw menus at the correct place? Or was there
> some additional reasoning involved?
It was both assumption and testing. That is, I didn't see the problem
afterwards (all menus appeared in the right place for me), but that
turned out to be due to me not following the bug recipe precisely.
After doing that, I was able to observe the problem (i.e., some of the
menus went missing).
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Tue, 10 Oct 2017 08:15:03 GMT)
Full text and
rfc822 format available.
Message #134 received at 28605 <at> debbugs.gnu.org (full text, mbox):
> ... I see scroll bar issues, but the menus are in the right place
> (although I normally have the menu-bar turned off ;-) )
>
> It may be because I'm running under KDE. I'll see if I can get a pure
> GNOME enviroment, that may behave differently.
It might be also related to the GTK versions used. Many people who
reported problems with menu positions are using GTK 3.22 and higher.
And one issue we should also look into is whether scroll bars show up
correctly for GTK builds with Lucid/Motif scroll bars and scaling on.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Tue, 10 Oct 2017 08:16:02 GMT)
Full text and
rfc822 format available.
Message #137 received at 28605 <at> debbugs.gnu.org (full text, mbox):
> It was both assumption and testing. That is, I didn't see the problem
> afterwards (all menus appeared in the right place for me), but that
> turned out to be due to me not following the bug recipe precisely.
> After doing that, I was able to observe the problem (i.e., some of the
> menus went missing).
Do you recall the special ingredient in the recipe that allowed you to
observe the problem? Was it the use of gnome-tweak-tool or the switch
from a python to a html file?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Tue, 10 Oct 2017 08:40:01 GMT)
Full text and
rfc822 format available.
Message #140 received at 28605 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>> It was both assumption and testing. That is, I didn't see the problem
>> afterwards (all menus appeared in the right place for me), but that
>> turned out to be due to me not following the bug recipe precisely.
>> After doing that, I was able to observe the problem (i.e., some of the
>> menus went missing).
>
> Do you recall the special ingredient in the recipe that allowed you to
> observe the problem? Was it the use of gnome-tweak-tool or the switch
> from a python to a html file?
Having just reproduced it here, it's the switch from python to html
that does it. If you do 'emacs -Q second.html' the SGML menu is
created correctly. I get lots of
(emacs:12642): Gtk-CRITICAL **: gtk_distribute_natural_allocation: assertion 'extra_space >= 0' failed
as well, which may be related.
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Tue, 10 Oct 2017 08:45:01 GMT)
Full text and
rfc822 format available.
Message #143 received at 28605 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>> ... I see scroll bar issues, but the menus are in the right place
>> (although I normally have the menu-bar turned off ;-) )
>>
>> It may be because I'm running under KDE. I'll see if I can get a pure
>> GNOME enviroment, that may behave differently.
>
> It might be also related to the GTK versions used. Many people who
> reported problems with menu positions are using GTK 3.22 and higher.
>
> And one issue we should also look into is whether scroll bars show up
> correctly for GTK builds with Lucid/Motif scroll bars and scaling on.
Is that combination possible? I thought
'configure --with-x-toolkit=lucid'
disabled GTK usage completely.
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Tue, 10 Oct 2017 08:55:01 GMT)
Full text and
rfc822 format available.
Message #146 received at 28605 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>> It was both assumption and testing. That is, I didn't see the problem
>> afterwards (all menus appeared in the right place for me), but that
>> turned out to be due to me not following the bug recipe precisely.
>> After doing that, I was able to observe the problem (i.e., some of the
>> menus went missing).
>
> Do you recall the special ingredient in the recipe that allowed you to
> observe the problem? Was it the use of gnome-tweak-tool or the switch
> from a python to a html file?
I don't normally use menus, so I didn't investigate much. But I
think... uhm... No, I don't think whether the menus appeared or not
had anything to do with gnome-tweak-tool. It had to do with changing
modes and buffers in Emacs. Sometimes the correct menus would appear in
the right place, and sometimes when changing buffers the menus wouldn't
appear at all, I think.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Tue, 10 Oct 2017 09:17:02 GMT)
Full text and
rfc822 format available.
Message #149 received at 28605 <at> debbugs.gnu.org (full text, mbox):
> Having just reproduced it here, it's the switch from python to html
> that does it. If you do 'emacs -Q second.html' the SGML menu is
> created correctly. I get lots of
>
> (emacs:12642): Gtk-CRITICAL **: gtk_distribute_natural_allocation: assertion 'extra_space >= 0' failed
>
> as well, which may be related.
Damn. That's the usual menu bar bug from etc/PROBLEMS.
*** Emacs built with GTK+ toolkit can unexpectedly widen frames
This resizing takes place when a frame is not wide enough to accommodate
its entire menu bar. Typically, it occurs when switching buffers or
changing a buffer's major mode and the new mode adds entries to the menu
bar. The frame is then widened by the window manager so that the menu
bar is fully shown. Subsequently switching to another buffer or
changing the buffer's mode will not shrink the frame back to its
previous width. The height of the frame remains unaltered. Apparently,
the failure is also dependent on the chosen font.
The resizing is usually accompanied by console output like
Gtk-CRITICAL **: gtk_distribute_natural_allocation: assertion 'extra_space >= 0' failed
It's not clear whether the GTK version used has any impact on the
occurrence of the failure. So far, the failure has been observed with
GTK+ versions 3.4.2, 3.14.5 and 3.18.7. However, another 3.4.2 build
does not exhibit the bug.
Some window managers (Xfce) apparently work around this failure by
cropping the menu bar. With other windows managers, it's possible to
shrink the frame manually after the problem occurs, e.g. by dragging the
frame's border with the mouse. However, some window managers have been
reported to refuse such attempts and snap back to the width needed to
show the full menu bar (wmii) or at least cause the screen to flicker
during such resizing attempts (i3, IceWM).
See also https://debbugs.gnu.org/cgi/bugreport.cgi?bug=15700,
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22000,
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22898 and
https://lists.gnu.org/archive/html/emacs-devel/2016-07/msg00154.html.
Maybe it now no more auto-widens the frame?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Tue, 10 Oct 2017 09:17:02 GMT)
Full text and
rfc822 format available.
Message #152 received at 28605 <at> debbugs.gnu.org (full text, mbox):
> Is that combination possible? I thought
>
> 'configure --with-x-toolkit=lucid'
>
> disabled GTK usage completely.
I could have sworn that there was an option to make a GTK build with
xaw3d scroll bars.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Tue, 10 Oct 2017 09:33:02 GMT)
Full text and
rfc822 format available.
Message #155 received at 28605 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 10 Oct 2017 11:16:20 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, Ola Nilsson <ola.nilsson <at> gmail.com>,
> 28605 <at> debbugs.gnu.org, Kaushal <kaushal.modi <at> gmail.com>
>
> > Is that combination possible? I thought
> >
> > 'configure --with-x-toolkit=lucid'
> >
> > disabled GTK usage completely.
>
> I could have sworn that there was an option to make a GTK build with
> xaw3d scroll bars.
What does --without-toolkit-scroll-bars do?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Tue, 10 Oct 2017 09:47:01 GMT)
Full text and
rfc822 format available.
Message #158 received at 28605 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>> Having just reproduced it here, it's the switch from python to html
>> that does it. If you do 'emacs -Q second.html' the SGML menu is
>> created correctly. I get lots of
>>
>> (emacs:12642): Gtk-CRITICAL **: gtk_distribute_natural_allocation: assertion 'extra_space >= 0' failed
>>
>> as well, which may be related.
>
> Damn. That's the usual menu bar bug from etc/PROBLEMS.
>
>
> Maybe it now no more auto-widens the frame?
It autowidens for me when it adds the SGML menu.
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Tue, 10 Oct 2017 09:55:02 GMT)
Full text and
rfc822 format available.
Message #161 received at 28605 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Date: Tue, 10 Oct 2017 11:16:20 +0200
>> From: martin rudalics <rudalics <at> gmx.at>
>> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, Ola Nilsson <ola.nilsson <at> gmail.com>,
>> 28605 <at> debbugs.gnu.org, Kaushal <kaushal.modi <at> gmail.com>
>>
>> > Is that combination possible? I thought
>> >
>> > 'configure --with-x-toolkit=lucid'
>> >
>> > disabled GTK usage completely.
>>
>> I could have sworn that there was an option to make a GTK build with
>> xaw3d scroll bars.
>
> What does --without-toolkit-scroll-bars do?
That gives me a GTK build with non-gtk scroll bars. I guess we need to
change this text in configure:
--without-toolkit-scroll-bars
don't use Motif or Xaw3d scroll bars
because that result is non-obvious to me.
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Tue, 10 Oct 2017 11:12:03 GMT)
Full text and
rfc822 format available.
Message #164 received at 28605 <at> debbugs.gnu.org (full text, mbox):
Robert Pluim <rpluim <at> gmail.com> writes:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> Date: Tue, 10 Oct 2017 11:16:20 +0200
>>> From: martin rudalics <rudalics <at> gmx.at>
>>> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, Ola Nilsson <ola.nilsson <at> gmail.com>,
>>> 28605 <at> debbugs.gnu.org, Kaushal <kaushal.modi <at> gmail.com>
>>>
>>> > Is that combination possible? I thought
>>> >
>>> > 'configure --with-x-toolkit=lucid'
>>> >
>>> > disabled GTK usage completely.
>>>
>>> I could have sworn that there was an option to make a GTK build with
>>> xaw3d scroll bars.
>>
>> What does --without-toolkit-scroll-bars do?
>
> That gives me a GTK build with non-gtk scroll bars. I guess we need to
> change this text in configure:
And those scroll bars are in the correct place when GDK_SCALE > 1,
with no character truncation.
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Tue, 10 Oct 2017 13:06:01 GMT)
Full text and
rfc822 format available.
Message #167 received at 28605 <at> debbugs.gnu.org (full text, mbox):
On Fri, Oct 6, 2017 at 1:50 PM, Robert Pluim <rpluim <at> gmail.com> wrote:
> martin rudalics <rudalics <at> gmx.at> writes:
>> To be on the safe side, we probably should leave the non-scaling parts
>> alone. For the scaling parts do whatever you consider appropriate. If
>> it fixes the behavior for Ola, we should install it and wait for
>> complaints.
>
> OK, I'll wait for Ola confirm, then clean it up (and split it into at
> least 2 to make it easier to revert).
>
> Robert
Sorry for taking so long.
I've tested Robert's patch now, and the horizontal scroll bars are
painted in the right place.
The area where the scroll bars "meet" is currently blank which looks
weird but I'm not sure it's related.
The frame is still resized to have fewer lines each time I turn
vertical scroll bars on or off.
--
Ola Nilsson
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Tue, 10 Oct 2017 13:27:02 GMT)
Full text and
rfc822 format available.
Message #170 received at 28605 <at> debbugs.gnu.org (full text, mbox):
>> Maybe it now no more auto-widens the frame?
>
> It autowidens for me when it adds the SGML menu.
If I only knew whether this is GTK version dependent or the window
manager catches this somehow ...
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Tue, 10 Oct 2017 13:27:02 GMT)
Full text and
rfc822 format available.
Message #173 received at 28605 <at> debbugs.gnu.org (full text, mbox):
>> What does --without-toolkit-scroll-bars do?
>
> That gives me a GTK build with non-gtk scroll bars. I guess we need to
> change this text in configure:
>
> --without-toolkit-scroll-bars
> don't use Motif or Xaw3d scroll bars
>
> because that result is non-obvious to me.
I think the necessary build option is --with-xaw3d.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Tue, 10 Oct 2017 13:27:03 GMT)
Full text and
rfc822 format available.
Message #176 received at 28605 <at> debbugs.gnu.org (full text, mbox):
> I've tested Robert's patch now, and the horizontal scroll bars are
> painted in the right place.
Thanks.
> The area where the scroll bars "meet" is currently blank which looks
> weird but I'm not sure it's related.
Do you see the same effect with scaling turned off?
> The frame is still resized to have fewer lines each time I turn
> vertical scroll bars on or off.
Does the frame resizing happen with horizontal scroll bars disabled too?
Does it happen without scaling?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Tue, 10 Oct 2017 14:02:01 GMT)
Full text and
rfc822 format available.
Message #179 received at submit <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>>> What does --without-toolkit-scroll-bars do?
>>
>> That gives me a GTK build with non-gtk scroll bars. I guess we need to
>> change this text in configure:
>>
>> --without-toolkit-scroll-bars
>> don't use Motif or Xaw3d scroll bars
>>
>> because that result is non-obvious to me.
>
> I think the necessary build option is --with-xaw3d.
That makes no difference. As far as I can tell from reading
configure.ac, xaw3d is only checked for when using the Lucid toolkit:
if test x"${USE_X_TOOLKIT}" = xmaybe || test x"${USE_X_TOOLKIT}" = xLUCID; then
if test "$with_xaw3d" != no; then
AC_CACHE_VAL(emacs_cv_xaw3d,
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Tue, 10 Oct 2017 15:34:01 GMT)
Full text and
rfc822 format available.
Message #182 received at 28605 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
martin rudalics <rudalics <at> gmx.at> writes:
>> I've tested Robert's patch now, and the horizontal scroll bars are
>> painted in the right place.
>
> Thanks.
Good. Git patch below.
>> The area where the scroll bars "meet" is currently blank which looks
>> weird but I'm not sure it's related.
>
> Do you see the same effect with scaling turned off?
>
>> The frame is still resized to have fewer lines each time I turn
>> vertical scroll bars on or off.
>
> Does the frame resizing happen with horizontal scroll bars disabled
> too?
Yes.
> Does it happen without scaling?
No.
Robert
[0001-Adjust-scrollbar-dimensions-when-scaling.patch (text/x-diff, inline)]
From 8efc99515108966cece1667dddb4b1abcc35f19c Mon Sep 17 00:00:00 2001
From: Robert Pluim <rpluim <at> gmail.com>
Date: Tue, 10 Oct 2017 16:20:50 +0200
Subject: [PATCH] Adjust scrollbar dimensions when scaling
2017-10-10 Robert Pluim <rpluim <at> gmail.com>
* src/gtkutil.c (xg_update_scrollbar_pos): Update width of
scrollbar when scaling is in effect
(xg_update_horizontal_scrollbar_pos): Update scrollbar size
when scaling is in effect.
---
src/gtkutil.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/gtkutil.c b/src/gtkutil.c
index c7d8f92829..88b7fd7e7b 100644
--- a/src/gtkutil.c
+++ b/src/gtkutil.c
@@ -3890,7 +3890,7 @@ xg_update_scrollbar_pos (struct frame *f,
top /= scale;
left /= scale;
height /= scale;
- left -= (scale - 1) * ((width / scale) >> 1);
+ width /= scale;
/* Clear out old position. */
int oldx = -1, oldy = -1, oldw, oldh;
@@ -3966,6 +3966,12 @@ xg_update_horizontal_scrollbar_pos (struct frame *f,
GtkWidget *wfixed = f->output_data.x->edit_widget;
GtkWidget *wparent = gtk_widget_get_parent (wscroll);
gint msl;
+ int scale = xg_get_scale (f);
+
+ top /= scale;
+ left /= scale;
+ height /= scale;
+ width /= scale;
/* Clear out old position. */
int oldx = -1, oldy = -1, oldw, oldh;
--
2.14.2.642.g20fed7cad
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Wed, 11 Oct 2017 06:58:02 GMT)
Full text and
rfc822 format available.
Message #185 received at 28605 <at> debbugs.gnu.org (full text, mbox):
On Tue, Oct 10, 2017 at 3:26 PM, martin rudalics <rudalics <at> gmx.at> wrote:
>> The area where the scroll bars "meet" is currently blank which looks
>> weird but I'm not sure it's related.
>
> Do you see the same effect with scaling turned off?
Yes.
>> The frame is still resized to have fewer lines each time I turn
>> vertical scroll bars on or off.
>
> Does the frame resizing happen with horizontal scroll bars disabled too?
Yes
> Does it happen without scaling?
No.
When scaling is off the frame is enlarged to make room for the scroll
bar, and then shrunk back again when the scroll bar is disabled.
--
Ola Nilsson
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Wed, 11 Oct 2017 08:33:01 GMT)
Full text and
rfc822 format available.
Message #188 received at submit <at> debbugs.gnu.org (full text, mbox):
> That makes no difference. As far as I can tell from reading
> configure.ac, xaw3d is only checked for when using the Lucid toolkit:
>
> if test x"${USE_X_TOOLKIT}" = xmaybe || test x"${USE_X_TOOLKIT}" = xLUCID; then
> if test "$with_xaw3d" != no; then
> AC_CACHE_VAL(emacs_cv_xaw3d,
You are right. I was misguided by the snippet below
dnl Use toolkit scroll bars if configured for GTK or X toolkit and either
dnl using Motif or Xaw3d is available, and unless
dnl --with-toolkit-scroll-bars=no was specified.
AH_TEMPLATE(USE_TOOLKIT_SCROLL_BARS,
[Define to 1 if we should use toolkit scroll bars.])dnl
USE_TOOLKIT_SCROLL_BARS=no
if test "${with_toolkit_scroll_bars}" != "no"; then
if test "${USE_X_TOOLKIT}" != "none"; then
if test "${USE_X_TOOLKIT}" = "MOTIF"; then
AC_DEFINE(USE_TOOLKIT_SCROLL_BARS)
HAVE_XAW3D=no
USE_TOOLKIT_SCROLL_BARS=yes
elif test "${HAVE_XAW3D}" = "yes" || test "${USE_X_TOOLKIT}" = "LUCID"; then
AC_DEFINE(USE_TOOLKIT_SCROLL_BARS)
USE_TOOLKIT_SCROLL_BARS=yes
fi
elif test "${HAVE_GTK}" = "yes"; then
AC_DEFINE(USE_TOOLKIT_SCROLL_BARS)
USE_TOOLKIT_SCROLL_BARS=yes
which seems to indicate that we check _separately_ for either XAW3D or
Lucid presence before we check for GTK. But apparently that only serves
to set USE_TOOLKIT_SCROLL_BARS. Since HAVE_XAW3D is set only in
conjunction with USE_X_TOOLKIT=LUCID, that separate HAVE_XAW3D check
doesn't make sense.
In any case, checking that a GTK build without toolkit scroll bars
handles scaling should have proven that a hypothetical GTK/XAW3D build
should succeed as well. So many thanks for doing that.
Sorry for having you tormented with this matter, martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Wed, 11 Oct 2017 08:34:02 GMT)
Full text and
rfc822 format available.
Message #191 received at 28605 <at> debbugs.gnu.org (full text, mbox):
>>> The area where the scroll bars "meet" is currently blank which looks
>>> weird but I'm not sure it's related.
>>
>> Do you see the same effect with scaling turned off?
>
> Yes.
Hmm... What did you want to see there instead?
>>> The frame is still resized to have fewer lines each time I turn
>>> vertical scroll bars on or off.
>>
>> Does the frame resizing happen with horizontal scroll bars disabled too?
>
> Yes
>
>> Does it happen without scaling?
>
> No.
> When scaling is off the frame is enlarged to make room for the scroll
> bar, and then shrunk back again when the scroll bar is disabled.
So with scaling on, shrinking the frame is essentially the right thing
to do and is also done correctly at the monent scroll bars are disabled.
But the frame fails to enlarge appropriately at the moment scroll bars
are enabled. Is that interpretation correct?
Robert, Lars: Do you see the same behavior as Ola?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Wed, 11 Oct 2017 08:38:02 GMT)
Full text and
rfc822 format available.
Message #194 received at 28605 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
> In any case, checking that a GTK build without toolkit scroll bars
> handles scaling should have proven that a hypothetical GTK/XAW3D build
> should succeed as well. So many thanks for doing that.
>
> Sorry for having you tormented with this matter, martin
No worries. Everything is a learning experience if you approach it
with the right attitude, and I learnt stuff here.
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Wed, 11 Oct 2017 08:50:01 GMT)
Full text and
rfc822 format available.
Message #197 received at 28605 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>> When scaling is off the frame is enlarged to make room for the scroll
>> bar, and then shrunk back again when the scroll bar is disabled.
>
> So with scaling on, shrinking the frame is essentially the right thing
> to do and is also done correctly at the monent scroll bars are
> disabled.
Shrinking the height of the frame when en/disabling vertical scroll
bars seems wrong to me.
> But the frame fails to enlarge appropriately at the moment scroll bars
> are enabled. Is that interpretation correct?
>
> Robert, Lars: Do you see the same behavior as Ola?
I've lost track :-)
With scaling:
- en/disable vertical scroll bars: frame height shrinks with every toggle
- en/disable horizontal scoll bars: ditto
Without scaling:
- en/disable vertical scroll bars: frame height unchanged
- en/disable horizontal scoll bars: frame height increases with
enable, shrinks with disable
This is all with my patch installed.
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Wed, 11 Oct 2017 09:29:02 GMT)
Full text and
rfc822 format available.
Message #200 received at 28605 <at> debbugs.gnu.org (full text, mbox):
>> So with scaling on, shrinking the frame is essentially the right thing
>> to do and is also done correctly at the monent scroll bars are
>> disabled.
>
> Shrinking the height of the frame when en/disabling vertical scroll
> bars seems wrong to me.
Silly me. I confused vertical and horizontal scroll bars. Obviously
the frame height should be left alone when dealing with vertical scroll
bars. The frame width should change, though.
> With scaling:
>
> - en/disable vertical scroll bars: frame height shrinks with every toggle
> - en/disable horizontal scoll bars: ditto
Something silly triggers here. Does the frame height at least remain
unchanged when ‘frame-inhibit-implied-resize’ is non-nil?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Wed, 11 Oct 2017 10:38:01 GMT)
Full text and
rfc822 format available.
Message #203 received at submit <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>>> So with scaling on, shrinking the frame is essentially the right thing
>>> to do and is also done correctly at the monent scroll bars are
>>> disabled.
>>
>> Shrinking the height of the frame when en/disabling vertical scroll
>> bars seems wrong to me.
>
> Silly me. I confused vertical and horizontal scroll bars. Obviously
> the frame height should be left alone when dealing with vertical scroll
> bars. The frame width should change, though.
Yes, and it does.
>> With scaling:
>>
>> - en/disable vertical scroll bars: frame height shrinks with every toggle
>> - en/disable horizontal scoll bars: ditto
>
> Something silly triggers here. Does the frame height at least remain
> unchanged when ‘frame-inhibit-implied-resize’ is non-nil?
Yes.
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Wed, 11 Oct 2017 13:12:01 GMT)
Full text and
rfc822 format available.
Message #206 received at 28605 <at> debbugs.gnu.org (full text, mbox):
On Wed, Oct 11, 2017 at 10:32 AM, martin rudalics <rudalics <at> gmx.at> wrote:
>>>> The area where the scroll bars "meet" is currently blank which looks
>>>> weird but I'm not sure it's related.
>>>
>>> Do you see the same effect with scaling turned off?
>>
>> Yes.
>
> Hmm... What did you want to see there instead?
I'm not sure. It just looks like something is missing when there is a
white square there instead of some scroll bar theme color.
>>>> The frame is still resized to have fewer lines each time I turn
>>>> vertical scroll bars on or off.
>>>
>>> Does it happen without scaling?
>>
>> No.
>> When scaling is off the frame is enlarged to make room for the scroll
>> bar, and then shrunk back again when the scroll bar is disabled.
>
> So with scaling on, shrinking the frame is essentially the right thing
> to do and is also done correctly at the monent scroll bars are disabled.
> But the frame fails to enlarge appropriately at the moment scroll bars
> are enabled. Is that interpretation correct?
I see the same behaviour as Robert.
--
Ola Nilsson
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Thu, 12 Oct 2017 08:06:01 GMT)
Full text and
rfc822 format available.
Message #209 received at 28605 <at> debbugs.gnu.org (full text, mbox):
> I'm not sure. It just looks like something is missing when there is a
> white square there instead of some scroll bar theme color.
Incidentally, that square is produced by the function that troubles us
in this thread - x_clear_area. That square represents some sort of
blind area, I have no good idea what to show there or how to paint it.
> I see the same behaviour as Robert.
To verify, can you also try what I asked Robert? Namely, evaluate
(setq frame-size-history '(100))
disable vertical scroll bars and enable them again. Then post the value
of ‘frame-size-history’.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Thu, 12 Oct 2017 09:32:02 GMT)
Full text and
rfc822 format available.
Message #212 received at 28605 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>> I'm not sure. It just looks like something is missing when there is a
>> white square there instead of some scroll bar theme color.
>
> Incidentally, that square is produced by the function that troubles us
> in this thread - x_clear_area. That square represents some sort of
> blind area, I have no good idea what to show there or how to paint it.
>
>> I see the same behaviour as Robert.
>
> To verify, can you also try what I asked Robert? Namely, evaluate
>
See below
> (setq frame-size-history '(100))
>
> disable vertical scroll bars and enable them again. Then post the value
> of ‘frame-size-history’.
>
(82
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> adjust-frame-size-1
(1494 998 1494 998)
(set-window-configuration 1))
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> adjust-frame-size-3
(1494 1100 1494 998)
(1510 1100 1536 998))
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> adjust-frame-size-1
(1494 1100 1494 998)
(change-frame-size 5))
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> xg-frame-resized
(1494 1100 1494 998)
nil)
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> xg-frame-resized
(1494 1100 1458 1100)
nil)
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> xg-frame-set-char-size-3
(1494 1100 1494 1100)
(768 595))
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> adjust-frame-size-2
(1494 1100 1494 1100)
(nil nil))
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> adjust-frame-size-1
(1494 1100 1494 1100)
(vertical-scroll-bars 3))
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> adjust-frame-size-1
(1494 1100 1494 1100)
(set-window-configuration 1))
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> adjust-frame-size-3
(1476 1100 1494 1100)
(1492 1100 1510 1100))
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> adjust-frame-size-1
(1476 1100 1494 1100)
(change-frame-size 5))
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> xg-frame-resized
(1476 1100 1494 1100)
nil)
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> adjust-frame-size-3
(1458 1100 1476 1100)
(1500 1100 1492 1100))
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> adjust-frame-size-1
(1458 1100 1476 1100)
(change-frame-size 5))
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> xg-frame-resized
(1458 1100 1476 1100)
nil)
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> xg-frame-set-char-size-3
(1458 1100 1458 1100)
(737 595))
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> adjust-frame-size-2
(1458 1100 1458 1100)
(nil nil))
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> adjust-frame-size-1
(1458 1100 1458 1100)
(vertical-scroll-bars 3)))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Fri, 13 Oct 2017 08:57:01 GMT)
Full text and
rfc822 format available.
Message #215 received at 28605 <at> debbugs.gnu.org (full text, mbox):
> See below
>
>> (setq frame-size-history '(100))
>>
>> disable vertical scroll bars and enable them again. Then post the value
>> of ‘frame-size-history’.
Thanks. Obviously the ConfigureNotify event triggering
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> xg-frame-resized
(1494 1100 1494 998)
nil)
is responsible but I have no idea where it comes from. I suppose
there's no such second event in the non-scaled scenario. Please post
the history for the non-scaled case so we can verify that.
But what stupefies me just as much is that removing the vertical scroll
bar apparently changes the text width from 1458 to 1476 in
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> xg-frame-resized
(1458 1100 1476 1100)
nil)
and then to 1494 in
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> xg-frame-resized
(1476 1100 1494 1100)
nil)
when removing the scroll bars. Can you observe that increase? Doesn't
it mean that the frame also gets wider every time you toggle the scroll
bars?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Fri, 13 Oct 2017 09:59:02 GMT)
Full text and
rfc822 format available.
Message #218 received at 28605 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>> See below
>>
>>> (setq frame-size-history '(100))
>>>
>>> disable vertical scroll bars and enable them again. Then post the value
>>> of ‘frame-size-history’.
>
> Thanks. Obviously the ConfigureNotify event triggering
>
> (#<frame emacs <at> rpluim-ubuntu 0x13462d0> xg-frame-resized
> (1494 1100 1494 998)
> nil)
>
> is responsible but I have no idea where it comes from. I suppose
> there's no such second event in the non-scaled scenario. Please post
> the history for the non-scaled case so we can verify that.
>
non-scaled:
(87
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> adjust-frame-size-1
(1386 1190 1386 1190)
(set-window-configuration 1))
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> adjust-frame-size-3
(1386 1190 1386 1190)
(1402 1190 1415 1190))
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> adjust-frame-size-1
(1386 1190 1386 1190)
(change-frame-size 5))
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> xg-frame-resized
(1386 1190 1386 1190)
nil)
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> xg-frame-set-char-size-3
(1386 1190 1386 1190)
(1415 1281))
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> adjust-frame-size-2
(1386 1190 1386 1190)
(nil nil))
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> adjust-frame-size-1
(1386 1190 1386 1190)
(vertical-scroll-bars 3))
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> adjust-frame-size-3
(1386 1190 1386 1190)
(1415 1190 1402 1190))
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> adjust-frame-size-1
(1386 1190 1386 1190)
(change-frame-size 5))
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> xg-frame-resized
(1386 1190 1386 1190)
nil)
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> xg-frame-set-char-size-3
(1386 1190 1386 1190)
(1402 1281))
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> adjust-frame-size-2
(1386 1190 1386 1190)
(nil nil))
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> adjust-frame-size-1
(1386 1190 1386 1190)
(vertical-scroll-bars 3)))
> But what stupefies me just as much is that removing the vertical scroll
> bar apparently changes the text width from 1458 to 1476 in
>
> (#<frame emacs <at> rpluim-ubuntu 0x13462d0> xg-frame-resized
> (1458 1100 1476 1100)
> nil)
>
> and then to 1494 in
>
> (#<frame emacs <at> rpluim-ubuntu 0x13462d0> xg-frame-resized
> (1476 1100 1494 1100)
> nil)
>
> when removing the scroll bars. Can you observe that increase? Doesn't
> it mean that the frame also gets wider every time you toggle the scroll
> bars?
I don't observe that increase. The width of the frame after each
disable/enable cycle is unchanged as far as I can tell.
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Fri, 13 Oct 2017 12:48:01 GMT)
Full text and
rfc822 format available.
Message #221 received at 28605 <at> debbugs.gnu.org (full text, mbox):
> non-scaled:
In the unscaled version we get one ConfigureNotify event for the removal
and one for the re-addition as expected. With the scaled version we get
two for each. The first two (when you remove the scroll bar) each
increment the width by 18 pixels each, 36 pixels in sum. Strange but OK.
The third one decrements the width as expected by 36 pixels and leaves
the height unchanged which is quite what we wanted. But then the fourth
one increments the width back to where it was after the second one and
decrements the height. Bad.
> I don't observe that increase. The width of the frame after each
> disable/enable cycle is unchanged as far as I can tell.
How comes? The scaled version starts with
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> adjust-frame-size-1
(1458 1100 1458 1100)
(vertical-scroll-bars 3)))
and ends with
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> adjust-frame-size-1
(1494 998 1494 998)
(set-window-configuration 1))
while the unscaled version starts with
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> adjust-frame-size-1
(1386 1190 1386 1190)
(vertical-scroll-bars 3)))
and ends with
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> adjust-frame-size-1
(1386 1190 1386 1190)
(set-window-configuration 1))
So for the scaled version we have 1458x1100 -> 1494x998 while the
unscaled version returns to the initial value. What do
‘frame-pixel-width’ and ‘frame-pixel-height’ return when called before,
in the middle and after toggling in the scaled version? And maybe you
could also look into the values returned by ‘frame-edges’ with varying
arguments. Maybe they reveal something interesting.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Fri, 13 Oct 2017 13:02:02 GMT)
Full text and
rfc822 format available.
Message #224 received at 28605 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>
> So for the scaled version we have 1458x1100 -> 1494x998 while the
> unscaled version returns to the initial value. What do
> ‘frame-pixel-width’ and ‘frame-pixel-height’ return when called before,
> in the middle and after toggling in the scaled version? And maybe you
> could also look into the values returned by ‘frame-edges’ with varying
> arguments. Maybe they reveal something interesting.
Start:
(frame-pixel-width)
1500
(frame-pixel-height)
1100
(frame-edges (selected-frame) 'outer-edges)
(1590 314 3106 1657)
(frame-edges (selected-frame) 'native-edges)
(1598 458 3098 1649)
(frame-edges (selected-frame) 'inner-edges)
(1598 458 3098 1649)
Disable vertical:
(frame-pixel-width)
1510
(frame-pixel-height)
998
(frame-edges (selected-frame) 'outer-edges)
(1590 314 3116 1555)
(frame-edges (selected-frame) 'native-edges)
(1598 458 3108 1547)
(frame-edges (selected-frame) 'inner-edges)
(1598 458 3108 1547)
re-enable vertical:
(frame-pixel-width)
1536
(frame-pixel-height)
896
(frame-edges (selected-frame) 'outer-edges)
(1590 314 3142 1453)
(frame-edges (selected-frame) 'native-edges)
(1598 458 3134 1445)
(frame-edges (selected-frame) 'inner-edges)
(1598 458 3134 1445)
After a couple more cycles we end up at:
(frame-pixel-width)
1536
(frame-pixel-height)
488
(frame-edges (selected-frame) 'outer-edges)
(1590 314 3142 1045)
(frame-edges (selected-frame) 'native-edges)
(1598 458 3134 1037)
(frame-edges (selected-frame) 'inner-edges)
(1598 458 3134 1037)
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Fri, 13 Oct 2017 16:19:02 GMT)
Full text and
rfc822 format available.
Message #227 received at 28605 <at> debbugs.gnu.org (full text, mbox):
On Thu, Oct 12, 2017 at 10:04 AM, martin rudalics <rudalics <at> gmx.at> wrote:
>> I'm not sure. It just looks like something is missing when there is a
>> white square there instead of some scroll bar theme color.
>
> Incidentally, that square is produced by the function that troubles us
> in this thread - x_clear_area. That square represents some sort of
> blind area, I have no good idea what to show there or how to paint it.
>
We could let either of the scroll bars use that space, either let the
verticall go all the way down or the horizontal all the way right (or
left).
--
Ola Nilsson
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Sat, 14 Oct 2017 08:37:04 GMT)
Full text and
rfc822 format available.
Message #230 received at 28605 <at> debbugs.gnu.org (full text, mbox):
> (frame-pixel-width)
> 1500
> (frame-pixel-height)
> 1100
> (frame-edges (selected-frame) 'outer-edges)
> (1590 314 3106 1657)
> (frame-edges (selected-frame) 'native-edges)
> (1598 458 3098 1649)
> (frame-edges (selected-frame) 'inner-edges)
> (1598 458 3098 1649)
>
> Disable vertical:
>
> (frame-pixel-width)
> 1510
> (frame-pixel-height)
> 998
> (frame-edges (selected-frame) 'outer-edges)
> (1590 314 3116 1555)
> (frame-edges (selected-frame) 'native-edges)
> (1598 458 3108 1547)
> (frame-edges (selected-frame) 'inner-edges)
> (1598 458 3108 1547)
>
> re-enable vertical:
>
> (frame-pixel-width)
> 1536
> (frame-pixel-height)
> 896
> (frame-edges (selected-frame) 'outer-edges)
> (1590 314 3142 1453)
> (frame-edges (selected-frame) 'native-edges)
> (1598 458 3134 1445)
> (frame-edges (selected-frame) 'inner-edges)
> (1598 458 3134 1445)
According to this after the first cycle the frame's width must have
increased from 1500 to 1536 pixels. Can't you confirm that visually?
> After a couple more cycles we end up at:
>
> (frame-pixel-width)
> 1536
> (frame-pixel-height)
> 488
> (frame-edges (selected-frame) 'outer-edges)
> (1590 314 3142 1045)
> (frame-edges (selected-frame) 'native-edges)
> (1598 458 3134 1037)
> (frame-edges (selected-frame) 'inner-edges)
> (1598 458 3134 1037)
What are the pixel dimensions of your screen? Maybe 3142 is already at
the right edge of your screen and the window manager refuses to increase
your frame any further.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Sat, 14 Oct 2017 08:37:05 GMT)
Full text and
rfc822 format available.
Message #233 received at 28605 <at> debbugs.gnu.org (full text, mbox):
> We could let either of the scroll bars use that space, either let the
> verticall go all the way down or the horizontal all the way right (or
> left).
I have never seen something the like. Can you point me at an
application which does that?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Sat, 14 Oct 2017 08:58:01 GMT)
Full text and
rfc822 format available.
Message #236 received at 28605 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>> re-enable vertical:
>>
>> (frame-pixel-width)
>> 1536
>> (frame-pixel-height)
>> 896
>> (frame-edges (selected-frame) 'outer-edges)
>> (1590 314 3142 1453)
>> (frame-edges (selected-frame) 'native-edges)
>> (1598 458 3134 1445)
>> (frame-edges (selected-frame) 'inner-edges)
>> (1598 458 3134 1445)
>
> According to this after the first cycle the frame's width must have
> increased from 1500 to 1536 pixels. Can't you confirm that visually?
>
You're right, it has. I wasn't paying enough attention to the right
edge of the frame.
>> After a couple more cycles we end up at:
>>
>> (frame-pixel-width)
>> 1536
>> (frame-pixel-height)
>> 488
>> (frame-edges (selected-frame) 'outer-edges)
>> (1590 314 3142 1045)
>> (frame-edges (selected-frame) 'native-edges)
>> (1598 458 3134 1037)
>> (frame-edges (selected-frame) 'inner-edges)
>> (1598 458 3134 1037)
>
> What are the pixel dimensions of your screen? Maybe 3142 is already at
> the right edge of your screen and the window manager refuses to increase
> your frame any further.
This screen is 3840x2160 pixels, and the emacs frame is well away from
the edges.
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Sat, 14 Oct 2017 09:22:02 GMT)
Full text and
rfc822 format available.
Message #239 received at 28605 <at> debbugs.gnu.org (full text, mbox):
> This screen is 3840x2160 pixels, and the emacs frame is well away from
> the edges.
Can you please again do (setq frame-size-history '(100)) and post its
value after you toggled scroll bars on and off _two_ times. I'd like to
understand why it stops increasing the width after the first toggling
but continues to decrease the height with subsequent togglings.
Thanks, martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Mon, 16 Oct 2017 11:42:01 GMT)
Full text and
rfc822 format available.
Message #242 received at 28605 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>> This screen is 3840x2160 pixels, and the emacs frame is well away from
>> the edges.
>
> Can you please again do (setq frame-size-history '(100)) and post its
> value after you toggled scroll bars on and off _two_ times. I'd like to
> understand why it stops increasing the width after the first toggling
> but continues to decrease the height with subsequent togglings.
(75
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> adjust-frame-size-1
(1494 692 1494 692)
(set-window-configuration 1))
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> adjust-frame-size-3
(1494 794 1494 692)
(1510 794 1536 692))
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> adjust-frame-size-1
(1494 794 1494 692)
(change-frame-size 5))
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> xg-frame-resized
(1494 794 1494 692)
nil)
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> xg-frame-set-char-size-3
(1494 794 1494 794)
(768 442))
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> adjust-frame-size-2
(1494 794 1494 794)
(nil nil))
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> adjust-frame-size-1
(1494 794 1494 794)
(vertical-scroll-bars 3))
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> adjust-frame-size-3
(1494 896 1494 794)
(1536 896 1510 794))
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> adjust-frame-size-1
(1494 896 1494 794)
(change-frame-size 5))
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> xg-frame-resized
(1494 896 1494 794)
nil)
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> xg-frame-set-char-size-3
(1494 896 1494 896)
(755 493))
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> adjust-frame-size-2
(1494 896 1494 896)
(nil nil))
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> adjust-frame-size-1
(1494 896 1494 896)
(vertical-scroll-bars 3))
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> adjust-frame-size-3
(1494 998 1494 896)
(1510 998 1536 896))
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> adjust-frame-size-1
(1494 998 1494 896)
(change-frame-size 5))
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> xg-frame-resized
(1494 998 1494 896)
nil)
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> xg-frame-set-char-size-3
(1494 998 1494 998)
(768 544))
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> adjust-frame-size-2
(1494 998 1494 998)
(nil nil))
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> adjust-frame-size-1
(1494 998 1494 998)
(vertical-scroll-bars 3))
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> adjust-frame-size-3
(1458 1100 1494 998)
(1500 1100 1510 998))
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> adjust-frame-size-1
(1458 1100 1494 998)
(change-frame-size 5))
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> xg-frame-resized
(1458 1100 1494 998)
nil)
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> xg-frame-set-char-size-3
(1458 1100 1458 1100)
(737 595))
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> adjust-frame-size-2
(1458 1100 1458 1100)
(nil nil))
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> adjust-frame-size-1
(1458 1100 1458 1100)
(vertical-scroll-bars 3)))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Tue, 17 Oct 2017 08:58:02 GMT)
Full text and
rfc822 format available.
Message #245 received at 28605 <at> debbugs.gnu.org (full text, mbox):
> (75
[...]
Thanks. This adds yet another facet to that completely irrational
behavior with scaling. The earlier trace you posted had this for the
first scroll bar removal
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> adjust-frame-size-1
(1494 1100 1494 1100)
(set-window-configuration 1))
[...]
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> xg-frame-resized
(1476 1100 1494 1100)
nil)
[...]
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> xg-frame-resized
(1458 1100 1476 1100)
nil)
[...]
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> adjust-frame-size-1
(1458 1100 1458 1100)
(vertical-scroll-bars 3)))
so the width went up from 1458 to 1476 and then to 1494 while the
height remained at 1100. Now you have
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> adjust-frame-size-3
(1458 1100 1494 998)
(1500 1100 1510 998))
[...]
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> xg-frame-resized
(1458 1100 1494 998)
nil)
[...]
(#<frame emacs <at> rpluim-ubuntu 0x13462d0> adjust-frame-size-1
(1458 1100 1458 1100)
(vertical-scroll-bars 3)))
so the width went up (albeit in one step only) to 1494 again but at the
same time the height went down from 1100 to 998.
Would inhibiting double buffering change anything? I'm still not sure
about that "Force scroll bars to be real X11 windows" change.
In the worst case we would have to test with some irrational build which
OT1H excludes
2016-10-28 Daniel Colascione <dancol <at> dancol.org>
Add double-buffering support to reduce flicker
and OTOH includes your and Lars' changes to scaling.
martin
PS: I'm afraid there are no news on the paperwork front. Right?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Tue, 17 Oct 2017 10:31:01 GMT)
Full text and
rfc822 format available.
Message #248 received at 28605 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
> Would inhibiting double buffering change anything? I'm still not sure
> about that "Force scroll bars to be real X11 windows" change.
That does seem to go against the desired direction of using the
toolkit for as much as possible.
I tried adding
(add-to-list 'default-frame-alist '(inhibit-double-buffering . t))
to my .emacs, but that doesn't seem to make a difference.
> In the worst case we would have to test with some irrational build which
> OT1H excludes
>
> 2016-10-28 Daniel Colascione <dancol <at> dancol.org>
>
> Add double-buffering support to reduce flicker
>
> and OTOH includes your and Lars' changes to scaling.
>
Hmm, reverting that commit doesn't seem simple. Maybe it's easier to
go back to the commit just before that one and apply the scaling
changes. I'll see if I can get to that this week.
> martin
>
> PS: I'm afraid there are no news on the paperwork front. Right?
I received the assignment form and have sent it back, so we're now
just waiting on the processing on the FSF side.
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Tue, 17 Oct 2017 13:10:01 GMT)
Full text and
rfc822 format available.
Message #251 received at 28605 <at> debbugs.gnu.org (full text, mbox):
> I tried adding
>
> (add-to-list 'default-frame-alist '(inhibit-double-buffering . t))
>
> to my .emacs, but that doesn't seem to make a difference.
Well, I wouldn't have expected much to change anyway.
> Hmm, reverting that commit doesn't seem simple. Maybe it's easier to
> go back to the commit just before that one and apply the scaling
> changes. I'll see if I can get to that this week.
Before you embark on that please check that a similar problem (frame
widening/shrinking) does not exist also when toggling off/on the tool
bar (including putting it on any other side of the frame), the menu bar,
the fringes and internal borders and also change the default font size.
Thanks, martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Thu, 19 Oct 2017 12:45:02 GMT)
Full text and
rfc822 format available.
Message #254 received at submit <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>> I tried adding
>>
>> (add-to-list 'default-frame-alist '(inhibit-double-buffering . t))
>>
>> to my .emacs, but that doesn't seem to make a difference.
>
> Well, I wouldn't have expected much to change anyway.
>
>> Hmm, reverting that commit doesn't seem simple. Maybe it's easier to
>> go back to the commit just before that one and apply the scaling
>> changes. I'll see if I can get to that this week.
>
> Before you embark on that please check that a similar problem (frame
> widening/shrinking) does not exist also when toggling off/on the tool
> bar (including putting it on any other side of the frame), the menu bar,
> the fringes and internal borders and also change the default font size.
Toggling the menu bar or the tool bar on/off shows the same type of
effects as the scroll bars. Toggling the fringe-mode on/off *always*
shrinks both the height and width.
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Fri, 20 Oct 2017 07:56:01 GMT)
Full text and
rfc822 format available.
Message #257 received at submit <at> debbugs.gnu.org (full text, mbox):
> Toggling the menu bar or the tool bar on/off shows the same type of
> effects as the scroll bars. Toggling the fringe-mode on/off *always*
> shrinks both the height and width.
I'm afraid you didn't test these with scroll bars turned off. So it's
easily possible that scroll bar calculations overshadow the frame size
adjustments we do for handling the above. Please try with scroll bars
turned off before you test these.
One thing you could check with scroll bars on is whether changing the
frame width (or height) and undoing that gets us back the initial size.
For example, does evaluating the following forms
(set-frame-parameter nil 'width (+ (frame-parameter nil 'width) 5))
(set-frame-parameter nil 'width (- (frame-parameter nil 'width) 5))
in sequence result in a frame of the same size?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Fri, 20 Oct 2017 13:42:02 GMT)
Full text and
rfc822 format available.
Message #260 received at 28605 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>> Toggling the menu bar or the tool bar on/off shows the same type of
>> effects as the scroll bars. Toggling the fringe-mode on/off *always*
>> shrinks both the height and width.
>
> I'm afraid you didn't test these with scroll bars turned off. So it's
> easily possible that scroll bar calculations overshadow the frame size
> adjustments we do for handling the above. Please try with scroll bars
> turned off before you test these.
I've retested with scroll bars turned off, that doesn't make any
difference, the frame height still shrinks.
> One thing you could check with scroll bars on is whether changing the
> frame width (or height) and undoing that gets us back the initial size.
> For example, does evaluating the following forms
>
> (set-frame-parameter nil 'width (+ (frame-parameter nil 'width) 5))
> (set-frame-parameter nil 'width (- (frame-parameter nil 'width) 5))
>
> in sequence result in a frame of the same size?
Now that's weird. That gets me back to a frame of the same *width*,
but each invocation of set-frame-parameter reduces the *height*, and
gives me:
(emacs:24843): Gtk-CRITICAL **: gtk_distribute_natural_allocation:
assertion 'extra_space >= 0' failed
when I reduce the width (with or without scroll bars). Are we back at
"It's a GTK bug"?
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Sat, 21 Oct 2017 08:05:02 GMT)
Full text and
rfc822 format available.
Message #263 received at 28605 <at> debbugs.gnu.org (full text, mbox):
>> I'm afraid you didn't test these with scroll bars turned off. So it's
>> easily possible that scroll bar calculations overshadow the frame size
>> adjustments we do for handling the above. Please try with scroll bars
>> turned off before you test these.
>
> I've retested with scroll bars turned off, that doesn't make any
> difference, the frame height still shrinks.
So for the moment we can omit scroll bars as the lone culprit. They are
too complicated - theme based size, minimum size constraints - anyway.
>> One thing you could check with scroll bars on is whether changing the
>> frame width (or height) and undoing that gets us back the initial size.
>> For example, does evaluating the following forms
>>
>> (set-frame-parameter nil 'width (+ (frame-parameter nil 'width) 5))
>> (set-frame-parameter nil 'width (- (frame-parameter nil 'width) 5))
>>
>> in sequence result in a frame of the same size?
>
> Now that's weird. That gets me back to a frame of the same *width*,
> but each invocation of set-frame-parameter reduces the *height*, and
> gives me:
>
> (emacs:24843): Gtk-CRITICAL **: gtk_distribute_natural_allocation:
> assertion 'extra_space >= 0' failed
>
> when I reduce the width (with or without scroll bars). Are we back at
> "It's a GTK bug"?
Recently this was mostly due to /etc/PROBLEMS
*** Emacs built with GTK+ toolkit can unexpectedly widen frames
BTW I found Ola's tool and menu bar sizes very disproportionate. Are
yours similarly large?
Anyway, the strategy now seems to be to switch off _everything_ toolkit
related (scroll bar, menu bar, tool bar and tooltips) and check whether
the problem persists. If it does, something very fundamental is broken
and we at least know from where to start. If it doesn't, then add each
of these but never two at the same time. This should give as a next
clue.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Mon, 23 Oct 2017 10:02:02 GMT)
Full text and
rfc822 format available.
Message #266 received at 28605 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>> I've retested with scroll bars turned off, that doesn't make any
>> difference, the frame height still shrinks.
>
> So for the moment we can omit scroll bars as the lone culprit. They are
> too complicated - theme based size, minimum size constraints - anyway.
I think it's the menu-bar, see below
> Anyway, the strategy now seems to be to switch off _everything_ toolkit
> related (scroll bar, menu bar, tool bar and tooltips) and check whether
> the problem persists. If it does, something very fundamental is broken
> and we at least know from where to start. If it doesn't, then add each
> of these but never two at the same time. This should give as a next
> clue.
(tool-bar-mode 0)
(scroll-bar-mode 0)
(tooltip-mode 0)
(menu-bar-mode 0)
(set-frame-parameter nil 'width (+ (frame-parameter nil 'width) 5))
(set-frame-parameter nil 'width (- (frame-parameter nil 'width) 5))
=> frame cycles back to same size
(menu-bar-mode 1)
(set-frame-parameter nil 'width (+ (frame-parameter nil 'width) 5))
(set-frame-parameter nil 'width (- (frame-parameter nil 'width) 5))
=> frame height shrinks
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Mon, 23 Oct 2017 11:55:02 GMT)
Full text and
rfc822 format available.
Message #269 received at 28605 <at> debbugs.gnu.org (full text, mbox):
> (tool-bar-mode 0)
> (scroll-bar-mode 0)
> (tooltip-mode 0)
> (menu-bar-mode 0)
>
> (set-frame-parameter nil 'width (+ (frame-parameter nil 'width) 5))
> (set-frame-parameter nil 'width (- (frame-parameter nil 'width) 5))
>
> => frame cycles back to same size
>
> (menu-bar-mode 1)
>
> (set-frame-parameter nil 'width (+ (frame-parameter nil 'width) 5))
> (set-frame-parameter nil 'width (- (frame-parameter nil 'width) 5))
>
> => frame height shrinks
Sounds "great". To check further: If with
(menu-bar-mode 0)
you toggle scroll bar or tool bar off and on, does the frame also cycle
back to the same size?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Mon, 23 Oct 2017 12:13:01 GMT)
Full text and
rfc822 format available.
Message #272 received at 28605 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>> (tool-bar-mode 0)
>> (scroll-bar-mode 0)
>> (tooltip-mode 0)
>> (menu-bar-mode 0)
>>
>> (set-frame-parameter nil 'width (+ (frame-parameter nil 'width) 5))
>> (set-frame-parameter nil 'width (- (frame-parameter nil 'width) 5))
>>
>> => frame cycles back to same size
>>
I forgot to mention: the next line is executed in the same emacs
session as the previous ones
>> (menu-bar-mode 1)
>>
>> (set-frame-parameter nil 'width (+ (frame-parameter nil 'width) 5))
>> (set-frame-parameter nil 'width (- (frame-parameter nil 'width) 5))
>>
>> => frame height shrinks
>
> Sounds "great". To check further: If with
>
> (menu-bar-mode 0)
>
> you toggle scroll bar or tool bar off and on, does the frame also cycle
> back to the same size?
Of course not, that would make this issue too easy to fix ;-)
From emacs -Q:
(menu-bar-mode 0)
(scroll-bar-mode 0)
(scroll-bar-mode 1)
The width goes back to the original, but the height shrinks
However things work correctly from emacs -Q with:
(menu-bar-mode 0)
(tool-bar-mode 0)
(scroll-bar-mode 0)
(scroll-bar-mode 1)
so looks like both the menu-bar and the tool-bar need to be disabled
for things to work as expected.
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Tue, 24 Oct 2017 09:18:01 GMT)
Full text and
rfc822 format available.
Message #275 received at 28605 <at> debbugs.gnu.org (full text, mbox):
>>> (tool-bar-mode 0)
>>> (scroll-bar-mode 0)
>>> (tooltip-mode 0)
>>> (menu-bar-mode 0)
>>>
>>> (set-frame-parameter nil 'width (+ (frame-parameter nil 'width) 5))
>>> (set-frame-parameter nil 'width (- (frame-parameter nil 'width) 5))
>>>
>>> => frame cycles back to same size
>>>
>
> I forgot to mention: the next line is executed in the same emacs
> session as the previous ones
Does it matter?
>>> (menu-bar-mode 1)
>>>
>>> (set-frame-parameter nil 'width (+ (frame-parameter nil 'width) 5))
>>> (set-frame-parameter nil 'width (- (frame-parameter nil 'width) 5))
>>>
>>> => frame height shrinks
>>
>> Sounds "great". To check further: If with
>>
>> (menu-bar-mode 0)
>>
>> you toggle scroll bar or tool bar off and on, does the frame also cycle
>> back to the same size?
>
> Of course not, that would make this issue too easy to fix ;-)
Too bad.
>>From emacs -Q:
>
> (menu-bar-mode 0)
> (scroll-bar-mode 0)
> (scroll-bar-mode 1)
>
> The width goes back to the original, but the height shrinks
>
> However things work correctly from emacs -Q with:
>
> (menu-bar-mode 0)
> (tool-bar-mode 0)
> (scroll-bar-mode 0)
> (scroll-bar-mode 1)
>
> so looks like both the menu-bar and the tool-bar need to be disabled
> for things to work as expected.
The gtk_distribute_natural_allocation error here always triggers when I
make an (unscaled) frame so narrow that the menu bar doesn't fit any
more. I can't trigger it via the tool bar though when the menu bar is
turned off. Can you trigger it via the tool bar alone?
Alas, I have no idea idea whether and how to switch off that natural
allocation distribution voodoo. And obviously we don't know whether
eliminating these warnings would help us with the frame shrinking
phenomena. In any case, eliminating these warnings should be the first
goal now.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Fri, 15 Dec 2017 18:18:02 GMT)
Full text and
rfc822 format available.
Message #278 received at 28605 <at> debbugs.gnu.org (full text, mbox):
> Good. Git patch below.
Robert, IIUC your paperwork is complete but we never applied that patch.
How shall we proceed?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Mon, 18 Dec 2017 15:59:02 GMT)
Full text and
rfc822 format available.
Message #281 received at 28605 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>> Good. Git patch below.
>
> Robert, IIUC your paperwork is complete but we never applied that patch.
> How shall we proceed?
I'm perfectly happy to have it applied by someone with commit rights
(my paperwork is complete). As a bugfix I think it should go on the
release branch, but that's not my decision to make.
Regards
RObert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Tue, 19 Dec 2017 07:03:02 GMT)
Full text and
rfc822 format available.
Message #284 received at 28605 <at> debbugs.gnu.org (full text, mbox):
> I'm perfectly happy to have it applied by someone with commit rights
> (my paperwork is complete). As a bugfix I think it should go on the
> release branch, but that's not my decision to make.
Eli, is it OK to install Robert's patch on the release branch? To me it
seems the best we have so far and any glitches it might add should be
tolerable. And it could suppress complaints that some faulty behavior
now already persists through three or four Emacs versions ...
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Tue, 19 Dec 2017 07:57:02 GMT)
Full text and
rfc822 format available.
Message #287 received at submit <at> debbugs.gnu.org (full text, mbox):
On December 19, 2017 9:02:33 AM GMT+02:00, martin rudalics <rudalics <at> gmx.at> wrote:
> > I'm perfectly happy to have it applied by someone with commit rights
> > (my paperwork is complete). As a bugfix I think it should go on the
> > release branch, but that's not my decision to make.
>
> Eli, is it OK to install Robert's patch on the release branch? To me
> it
> seems the best we have so far and any glitches it might add should be
> tolerable. And it could suppress complaints that some faulty behavior
> now already persists through three or four Emacs versions ...
>
> martin
Please show tbe actual patch you are asking about. This has been a long discussion with quite a few patches, and I'd like to know what I'm asked to approve.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Tue, 19 Dec 2017 07:58:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Tue, 19 Dec 2017 08:11:01 GMT)
Full text and
rfc822 format available.
Message #293 received at 28605 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
> On December 19, 2017 9:02:33 AM GMT+02:00, martin rudalics <rudalics <at> gmx.at> wrote:
>> > I'm perfectly happy to have it applied by someone with commit rights
>> > (my paperwork is complete). As a bugfix I think it should go on the
>> > release branch, but that's not my decision to make.
>>
>> Eli, is it OK to install Robert's patch on the release branch? To me
>> it
>> seems the best we have so far and any glitches it might add should be
>> tolerable. And it could suppress complaints that some faulty behavior
>> now already persists through three or four Emacs versions ...
>>
>> martin
>
> Please show tbe actual patch you are asking about. This has been a long discussion with quite a few patches, and I'd like to know what I'm asked to approve.
Attached.
Regards
Robert
[0001-Adjust-scrollbar-dimensions-when-scaling.patch (text/x-diff, inline)]
From 074d39597b1cff03053e369cf89ee701874afddb Mon Sep 17 00:00:00 2001
From: Robert Pluim <rpluim <at> gmail.com>
Date: Tue, 10 Oct 2017 16:20:50 +0200
Subject: [PATCH] Adjust scrollbar dimensions when scaling
2017-10-10 Robert Pluim <rpluim <at> gmail.com>
* src/gtkutil.c (xg_update_scrollbar_pos): Update width of
scrollbar when scaling is in effect
(xg_update_horizontal_scrollbar_pos): Update scrollbar size
when scaling is in effect.
---
src/gtkutil.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/gtkutil.c b/src/gtkutil.c
index c7d8f92829..88b7fd7e7b 100644
--- a/src/gtkutil.c
+++ b/src/gtkutil.c
@@ -3890,7 +3890,7 @@ xg_update_scrollbar_pos (struct frame *f,
top /= scale;
left /= scale;
height /= scale;
- left -= (scale - 1) * ((width / scale) >> 1);
+ width /= scale;
/* Clear out old position. */
int oldx = -1, oldy = -1, oldw, oldh;
@@ -3966,6 +3966,12 @@ xg_update_horizontal_scrollbar_pos (struct frame *f,
GtkWidget *wfixed = f->output_data.x->edit_widget;
GtkWidget *wparent = gtk_widget_get_parent (wscroll);
gint msl;
+ int scale = xg_get_scale (f);
+
+ top /= scale;
+ left /= scale;
+ height /= scale;
+ width /= scale;
/* Clear out old position. */
int oldx = -1, oldy = -1, oldw, oldh;
--
2.15.0.rc1
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Tue, 19 Dec 2017 16:11:02 GMT)
Full text and
rfc822 format available.
Message #296 received at 28605 <at> debbugs.gnu.org (full text, mbox):
> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: 28605 <at> debbugs.gnu.org, rudalics <at> gmx.at, ola.nilsson <at> gmail.com, larsi <at> gnus.org, kaushal.modi <at> gmail.com
> Date: Tue, 19 Dec 2017 09:10:33 +0100
>
> >From 074d39597b1cff03053e369cf89ee701874afddb Mon Sep 17 00:00:00 2001
> From: Robert Pluim <rpluim <at> gmail.com>
> Date: Tue, 10 Oct 2017 16:20:50 +0200
> Subject: [PATCH] Adjust scrollbar dimensions when scaling
>
> 2017-10-10 Robert Pluim <rpluim <at> gmail.com>
>
> * src/gtkutil.c (xg_update_scrollbar_pos): Update width of
> scrollbar when scaling is in effect
> (xg_update_horizontal_scrollbar_pos): Update scrollbar size
> when scaling is in effect.
> ---
> src/gtkutil.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/src/gtkutil.c b/src/gtkutil.c
> index c7d8f92829..88b7fd7e7b 100644
> --- a/src/gtkutil.c
> +++ b/src/gtkutil.c
> @@ -3890,7 +3890,7 @@ xg_update_scrollbar_pos (struct frame *f,
> top /= scale;
> left /= scale;
> height /= scale;
> - left -= (scale - 1) * ((width / scale) >> 1);
> + width /= scale;
>
> /* Clear out old position. */
> int oldx = -1, oldy = -1, oldw, oldh;
> @@ -3966,6 +3966,12 @@ xg_update_horizontal_scrollbar_pos (struct frame *f,
> GtkWidget *wfixed = f->output_data.x->edit_widget;
> GtkWidget *wparent = gtk_widget_get_parent (wscroll);
> gint msl;
> + int scale = xg_get_scale (f);
> +
> + top /= scale;
> + left /= scale;
> + height /= scale;
> + width /= scale;
>
> /* Clear out old position. */
> int oldx = -1, oldy = -1, oldw, oldh;
> --
> 2.15.0.rc1
Thanks, this is okay for the release branch.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Wed, 20 Dec 2017 08:55:02 GMT)
Full text and
rfc822 format available.
Message #299 received at 28605 <at> debbugs.gnu.org (full text, mbox):
> Thanks, this is okay for the release branch.
Pushed to the release branch.
Thanks, martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#28605; Package
emacs.
(Fri, 04 Sep 2020 05:06:02 GMT)
Full text and
rfc822 format available.
Message #302 received at 28605 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>> Thanks, this is okay for the release branch.
>
> Pushed to the release branch.
I've just skimmed this very long bug report, but if I understand
correctly, Robert's patched fixed the reported bug, so I'm closing this
bug report. If there's more to be fixed here (I may well have missed
something), then please respond to the debbugs address and we'll reopen.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
bug closed, send any further explanations to
28605 <at> debbugs.gnu.org and Ola Nilsson <ola.nilsson <at> gmail.com>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Fri, 04 Sep 2020 05:06:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Fri, 02 Oct 2020 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 204 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.