bug#21469: 25.0.50; right scrollbar wrongly placed when resizing split window

bug#21469: 25.0.50; right scrollbar wrongly placed when resizing split window

[Robert Pluim]

To reproduce:

emacs -Q
C-x 3 # split-window-right
Then use the mouse to move the horizontal separator in the middle of
the mode-line to the left. The frame stays the same size, but the
right scrollbar moves inwards from the right edge. It also appears
that the right scrollbar controls the window to the left, not the
window to the right.

This is with git emacs commit 166812addb0a1b9b2258ef3ce76424cd7facfa8b

If I rebuild using ‘--without-toolkit-scroll-bars’ everything works as
expected.

In GNU Emacs 25.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.14.13)
 of 2015-09-13
Windowing system distributor 'The X.Org Foundation', version 11.0.11701000
System Description:	Ubuntu 15.04

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS
NOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11

Important settings:
  value of $LC_COLLATE: C
  value of $LC_MONETARY: en_GB.UTF-8
  value of $LC_NUMERIC: en_GB.UTF-8
  value of $LC_TIME: en_GB.UTF-8
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Group

Minor modes in effect:
  gnus-topic-mode: t
  gnus-undo-mode: t
  diff-auto-refine-mode: t
  desktop-save-mode: t
  show-paren-mode: t
  savehist-mode: t
  ido-everywhere: t
  global-auto-revert-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  size-indication-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
Decrypting /home/rpluim/.authinfo.gpg...done
Reading /home/rpluim/.newsrc.eld...
Opening nntp server on eternal...done
Opening nnimap server on GMail...done
Opening nnimap server on Fortinet...done
No new newsgroups
Checking new news...
Reading active file via nndraft...done
Checking new news...done
Making completion list... [2 times]


Features:
(shadow sort gnus-cite mail-extr nnir emacsbug sendmail gnus-topic
nndraft nnmh gnus-agent gnus-srvr gnus-score score-mode nnvirtual
gnus-msg gnus-art mm-uu mml2015 mm-view mml-smime smime dig utf-7
gnus-cache gnus-sum epa-file epa derived epg network-stream nsm
starttls nntp gnus-group gnus-undo gnutls gnus-start gnus-cloud nnimap
nnmail mail-source tls utf7 netrc nnoo parse-time gnus-spec gnus-int
gnus-range message rfc822 mml mml-sec mm-decode mm-bodies mm-encode
mail-parse rfc2231 rfc2047 rfc2045 ietf-drums mailabbrev gmm-utils
mailheader gnus-win eww mm-url gnus gnus-ems nnheader mail-utils
wid-edit url-queue url url-proxy url-privacy url-expand url-methods
url-history url-cookie url-domsuf url-util url-parse auth-source
cl-seq eieio mm-util help-fns mail-prsvr password-cache url-vars
mailcap shr dom subr-x browse-url org-rmail org-mhe org-irc org-info
org-gnus gnus-util org-docview doc-view jka-compr image-mode
org-bibtex bibtex org-bbdb org-w3m vc vc-dispatcher vc-git diff-mode
iso-transl face-remap key-chord dired+ image-dired image-file dired-x
dired-aux dired desktop frameset ox-ioslide f dash s ucs-normalize
ox-odt rng-loc rng-uri rng-parse rng-match rng-dt rng-util rng-pttrn
nxml-parse nxml-ns nxml-enc xmltok nxml-util ox-html ox-beamer
ox-latex ox-publish ox org-element avl-tree org advice org-macro
org-footnote org-pcomplete pcomplete org-list org-faces org-entities
noutline outline easy-mmode org-version ob-emacs-lisp ob ob-tangle
ob-ref ob-lob ob-table ob-exp org-src ob-keys ob-comint comint
ansi-color ring ob-core ob-eval org-compat org-macs org-loaddefs
format-spec find-func cal-menu calendar cal-loaddefs finder-inf
dictionary-autoloads connection-autoloads edmacro kmacro
helm-git-autoloads helm-git-files-autoloads helm-git-grep-autoloads
helm-helm-commands-autoloads eieio-core cl-macs link-autoloads
log4j-mode-autoloads stripe-buffer-autoloads vlf-autoloads info
package epg-config paren savehist ido seq byte-opt bytecomp
byte-compile cconv cl-extra help-mode easymenu autorevert filenotify
cus-start cus-load server cl gv cl-loaddefs pcase cl-lib time-date
mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel x-win term/common-win x-dnd tool-bar dnd
fontset image regexp-opt fringe tabulated-list newcomment elisp-mode
lisp-mode prog-mode register page menu-bar rfn-eshadow timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core 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 charscript
case-table epa-hook jka-cmpr-hook help simple abbrev 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
dynamic-setting system-font-setting font-render-setting move-toolbar
gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 561175 17840)
 (symbols 48 135516 0)
 (miscs 40 548 318)
 (strings 32 149055 20453)
 (string-bytes 1 4797262)
 (vectors 16 62885)
 (vector-slots 8 1059839 6781)
 (floats 8 514 264)
 (intervals 56 659 61)
 (buffers 976 33)
 (heap 1024 114218 2399))

bug#21469: 25.0.50; right scrollbar wrongly placed when resizing split window

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Date: Sun, 13 Sep 2015 15:31:34 +0200
> 
> emacs -Q
> C-x 3 # split-window-right
> Then use the mouse to move the horizontal separator in the middle of
> the mode-line to the left. The frame stays the same size, but the
> right scrollbar moves inwards from the right edge. It also appears
> that the right scrollbar controls the window to the left, not the
> window to the right.

Doesn't happen on w32 with the current master, FWIW.  Probably
GTK-specific.

bug#21469: 25.0.50; right scrollbar wrongly placed when resizing split window

[martin rudalics]

 > emacs -Q
 > C-x 3 # split-window-right
 > Then use the mouse to move the horizontal separator in the middle of
 > the mode-line to the left. The frame stays the same size, but the
 > right scrollbar moves inwards from the right edge. It also appears
 > that the right scrollbar controls the window to the left, not the
 > window to the right.
 >
 > This is with git emacs commit 166812addb0a1b9b2258ef3ce76424cd7facfa8b
 >
 > If I rebuild using ‘--without-toolkit-scroll-bars’ everything works as
 > expected.
 >
 > In GNU Emacs 25.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.14.13)
 >   of 2015-09-13
 > Windowing system distributor 'The X.Org Foundation', version 11.0.11701000
 > System Description:	Ubuntu 15.04
 >
 > Configured features:
 > XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS
 > NOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
 > TOOLKIT_SCROLL_BARS GTK3 X11

I cannot reproduce that here with GTK+ 3.4.2.  Does it also happen when
you do (set-frame-parameter nil 'right-divider-width 6)?  Could this be
cairo related?

martin

bug#21469: 25.0.50; right scrollbar wrongly placed when resizing split window

[Robert Pluim]

martin rudalics <rudalics@gmx.at> writes:

>
> I cannot reproduce that here with GTK+ 3.4.2.  Does it also happen when
> you do (set-frame-parameter nil 'right-divider-width 6)?  Could this be
> cairo related?

That results in the right scrollbar being slightly offset to the left
as soon as I split the window, however the subsequent behaviour is the
same.

I don't have cairo configured. Is there an easy way to undo the
cairo-related changes?

Regards

Robert

bug#21469: 25.0.50; right scrollbar wrongly placed when resizing split window

[Robert Pluim]

Robert Pluim <rpluim@gmail.com> writes:

> martin rudalics <rudalics@gmx.at> writes:
>
>>
>> I cannot reproduce that here with GTK+ 3.4.2.  Does it also happen when
>> you do (set-frame-parameter nil 'right-divider-width 6)?  Could this be
>> cairo related?
>
> That results in the right scrollbar being slightly offset to the left
> as soon as I split the window, however the subsequent behaviour is the
> same.
>
> I don't have cairo configured. Is there an easy way to undo the
> cairo-related changes?

In an attempt to bisect this, I've just gone back to:

commit 94ae2ad44cfd711c836e0fbd86b9e133724482d5
Author: Stefan Monnier <monnier@iro.umontreal.ca>
Date:   Tue Nov 5 23:11:04 2013 -0500

which behaves the same, so it's unlikely to be cairo-related.

I'm starting to think this is either something in my environment or a
GTK issue.

Robert

bug#21469: 25.0.50; right scrollbar wrongly placed when resizing split window

[martin rudalics]

 > I'm starting to think this is either something in my environment or a
 > GTK issue.

In xg_set_toolkit_scroll_bar_thumb in gtkutil.c could you check whether
_we_ already select the wrong bar->window?  Provided your earlier
assumption that "the right scrollbar controls the window to the left,
not the window to the right" holds, obviously.

martin

bug#21469: 25.0.50; right scrollbar wrongly placed when resizing split window

[Robert Pluim]

martin rudalics <rudalics@gmx.at> writes:

>> I'm starting to think this is either something in my environment or a
>> GTK issue.
>
> In xg_set_toolkit_scroll_bar_thumb in gtkutil.c could you check whether
> _we_ already select the wrong bar->window?  Provided your earlier
> assumption that "the right scrollbar controls the window to the left,
> not the window to the right" holds, obviously.

How would I check that?

Looking more closely, it appears that I don't initially even have a
scrollbar, even if I visit a file; it doesn't appear until I split the
window.

Robert

bug#21469: 25.0.50; right scrollbar wrongly placed when resizing split window

[martin rudalics]

 >> In xg_set_toolkit_scroll_bar_thumb in gtkutil.c could you check whether
 >> _we_ already select the wrong bar->window?  Provided your earlier
 >> assumption that "the right scrollbar controls the window to the left,
 >> not the window to the right" holds, obviously.
 >
 > How would I check that?

If ...

 > Looking more closely, it appears that I don't initially even have a
 > scrollbar, even if I visit a file; it doesn't appear until I split the
 > window.

... you never get an initial scroll bar, it would be indeed hard to
check that.  IIRC running Emacs from a console logs GTK errors in the
console output.  Can you try that?  Also could you send us screenshots
of your initial scroll-bar-less frame and the one where a scroll bar is
halfway visible somewhere in a window.

martin

bug#21469: 25.0.50; right scrollbar wrongly placed when resizing split window

[Robert Pluim]

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

martin rudalics <rudalics@gmx.at> writes:

> ... you never get an initial scroll bar, it would be indeed hard to
> check that.  IIRC running Emacs from a console logs GTK errors in the
> console output.  Can you try that?  Also could you send us screenshots
> of your initial scroll-bar-less frame and the one where a scroll bar is
> halfway visible somewhere in a window.

From a console or from an xterm? From an xterm I get nothing output at
all.

Initial frame:


[-- Attachment #2: emacs-initial-frame.png --]
[-- Type: image/png, Size: 81312 bytes --]

[-- Attachment #3: Type: text/plain, Size: 50 bytes --]


After splitting and moving the central divider:


[-- Attachment #4: emacs-after-split-and-move.png --]
[-- Type: image/png, Size: 74477 bytes --]

bug#21469: 25.0.50; right scrollbar wrongly placed when resizing split window

[martin rudalics]

 >>From a console or from an xterm? From an xterm I get nothing output at
 > all.

My memory probably fails.  Somewhere GTK should write a log maybe I find
out where.

Thanks for the pngs.  Please do the following:

(1) After starting, evaluate the form (window--dump-frame).  This should
     produce a buffer called *window-frame-dump*.  Post the contents
     here.

(2) Now split the single window via C-x 3, evaluate (window--dump-frame)
     again and post the new contents of the *window-frame-dump* buffer.
     And please also post a png of the frame at that time.

(3) Now drag the border, evaluate (window--dump-frame) once more, post
     the new *window-frame-dump* buffer contents and a png of the frame.

Hopefully we can deduce something from these.

Thanks, martin

bug#21469: 25.0.50; right scrollbar wrongly placed when resizing split window

[Robert Pluim]

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

martin rudalics <rudalics@gmx.at> writes:

>>>From a console or from an xterm? From an xterm I get nothing output at
>> all.
>
> My memory probably fails.  Somewhere GTK should write a log maybe I find
> out where.
>
> Thanks for the pngs.  Please do the following:
>
> (1) After starting, evaluate the form (window--dump-frame).  This should
>     produce a buffer called *window-frame-dump*.  Post the contents
>     here.
>


[-- Attachment #2: frame-dump1.txt --]
[-- Type: text/plain, Size: 903 bytes --]

frame pixel: 1640 x 792   cols/lines: 91 x 22   units: 18 x 36
frame text pixel: 1612 x 792   cols/lines: 89 x 22
tool: 0  scroll: 12/0  fringe: 16  border: 0  right: 0  bottom: 0

#<window 3 on *scratch*>   parent: nil
pixel left: 0   top: 0   size: 1640 x 756   new: 756
char left: 0   top: 0   size: 91 x 21   new: 21
normal: 1.0 x 1.0   new: 1.0
body pixel: 1612 x 720   char: 89 x 20
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 12  divider: 0
height header-line: 0  mode-line: 36  divider: 0

#<window 4 on  *Minibuf-0*>   parent: nil
pixel left: 0   top: 756   size: 1640 x 36   new: 0
char left: 0   top: 21   size: 1640 x 1   new: 1
normal: 1.0 x 1.0   new: 0
body pixel: 1612 x 36   char: 89 x 1
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 12  divider: 0
height header-line: 0  mode-line: 0  divider: 0


[-- Attachment #3: Type: text/plain, Size: 447 bytes --]


Something is definitely wrong there: the cols/lines values in that
file seem correct, but the values shown in the tooltip when I drag the
bottom right corner of the frame to resize it are approximately half
that (41x11 in this case).

> (2) Now split the single window via C-x 3, evaluate (window--dump-frame)
>     again and post the new contents of the *window-frame-dump* buffer.
>     And please also post a png of the frame at that time.
>


[-- Attachment #4: frame-dump2.txt --]
[-- Type: text/plain, Size: 1437 bytes --]

frame pixel: 1640 x 792   cols/lines: 91 x 22   units: 18 x 36
frame text pixel: 1612 x 792   cols/lines: 89 x 22
tool: 0  scroll: 12/0  fringe: 16  border: 0  right: 0  bottom: 0

#<window 7>   parent: nil
pixel left: 0   top: 0   size: 1640 x 756   new: 1640
char left: 0   top: 0   size: 91 x 21   new: 91
normal: 1.0 x 1.0   new: 1.0

#<window 3 on *scratch*>   parent: #<window 7>
pixel left: 0   top: 0   size: 812 x 756   new: 812
char left: 0   top: 0   size: 45 x 21   new: 45
normal: 0.5 x 1.0   new: 0.5
body pixel: 784 x 720   char: 43 x 20
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 12  divider: 0
height header-line: 0  mode-line: 36  divider: 0

#<window 8 on *scratch*>   parent: #<window 7>
pixel left: 812   top: 0   size: 828 x 756   new: 828
char left: 45   top: 0   size: 46 x 21   new: 46
normal: 0.5 x 1.0   new: 0.5
body pixel: 800 x 720   char: 44 x 20
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 12  divider: 0
height header-line: 0  mode-line: 36  divider: 0

#<window 4 on  *Minibuf-0*>   parent: nil
pixel left: 0   top: 756   size: 1640 x 36   new: 0
char left: 0   top: 21   size: 91 x 1   new: 91
normal: 1.0 x 1.0   new: 0
body pixel: 1612 x 36   char: 89 x 1
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 12  divider: 0
height header-line: 0  mode-line: 0  divider: 0


[-- Attachment #5: emacs-split2.png --]
[-- Type: image/png, Size: 76721 bytes --]

[-- Attachment #6: Type: text/plain, Size: 150 bytes --]


> (3) Now drag the border, evaluate (window--dump-frame) once more, post
>     the new *window-frame-dump* buffer contents and a png of the frame.
>

[-- Attachment #7: frame-dump3.txt --]
[-- Type: text/plain, Size: 1502 bytes --]

frame pixel: 1640 x 792   cols/lines: 91 x 22   units: 18 x 36
frame text pixel: 1612 x 792   cols/lines: 89 x 22
tool: 0  scroll: 12/0  fringe: 16  border: 0  right: 0  bottom: 0

#<window 7>   parent: nil
pixel left: 0   top: 0   size: 1640 x 756   new: 1640
char left: 0   top: 0   size: 91 x 21   new: 91
normal: 1.0 x 1.0   new: nil

#<window 3 on *scratch*>   parent: #<window 7>
pixel left: 0   top: 0   size: 595 x 756   new: 595
char left: 0   top: 0   size: 33 x 21   new: 33
normal: 0.36660505237215035 x 1.0   new: 0.36660505237215035
body pixel: 567 x 720   char: 31 x 20
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 12  divider: 0
height header-line: 0  mode-line: 36  divider: 0

#<window 8 on *scratch*>   parent: #<window 7>
pixel left: 595   top: 0   size: 1045 x 756   new: 1045
char left: 33   top: 0   size: 58 x 21   new: 58
normal: 0.6333949476278498 x 1.0   new: 0.6333949476278498
body pixel: 1017 x 720   char: 56 x 20
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 12  divider: 0
height header-line: 0  mode-line: 36  divider: 0

#<window 4 on  *Minibuf-0*>   parent: nil
pixel left: 0   top: 756   size: 1640 x 36   new: 0
char left: 0   top: 21   size: 91 x 1   new: 91
normal: 1.0 x 1.0   new: 0
body pixel: 1612 x 36   char: 89 x 1
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 12  divider: 0
height header-line: 0  mode-line: 0  divider: 0


[-- Attachment #8: emacs-split-move2.png --]
[-- Type: image/png, Size: 140077 bytes --]

[-- Attachment #9: Type: text/plain, Size: 76 bytes --]


> Hopefully we can deduce something from these.
>
> Thanks, martin
>
>
>
>

bug#21469: 25.0.50; right scrollbar wrongly placed when resizing split window

[Robert Pluim]

Robert Pluim <rpluim@gmail.com> writes:

> frame pixel: 1640 x 792   cols/lines: 91 x 22   units: 18 x 36
> frame text pixel: 1612 x 792   cols/lines: 89 x 22
> tool: 0  scroll: 12/0  fringe: 16  border: 0  right: 0  bottom: 0
>
> #<window 3 on *scratch*>   parent: nil
> pixel left: 0   top: 0   size: 1640 x 756   new: 756
> char left: 0   top: 0   size: 91 x 21   new: 21
> normal: 1.0 x 1.0   new: 1.0
> body pixel: 1612 x 720   char: 89 x 20
> width left fringe: 8  left margin: 0  right margin: 0
> width right fringe: 8  scroll-bar: 12  divider: 0
> height header-line: 0  mode-line: 36  divider: 0
>
> #<window 4 on  *Minibuf-0*>   parent: nil
> pixel left: 0   top: 756   size: 1640 x 36   new: 0
> char left: 0   top: 21   size: 1640 x 1   new: 1
> normal: 1.0 x 1.0   new: 0
> body pixel: 1612 x 36   char: 89 x 1
> width left fringe: 8  left margin: 0  right margin: 0
> width right fringe: 8  scroll-bar: 12  divider: 0
> height header-line: 0  mode-line: 0  divider: 0
>
>
> Something is definitely wrong there: the cols/lines values in that
> file seem correct, but the values shown in the tooltip when I drag the
> bottom right corner of the frame to resize it are approximately half
> that (41x11 in this case).

That made me take another close look at my DPI settings. Gnome claimed
not to be using a DPI scaling factor, but I set it to 2, then back to
1, and now the scrollbars appear where they should. If I set it to 2
the problem reappears.

The question now is: is this an emacs or a GTK bug?

Regards

Robert

bug#21469: 25.0.50; right scrollbar wrongly placed when resizing split window

[martin rudalics]

 > That made me take another close look at my DPI settings. Gnome claimed
 > not to be using a DPI scaling factor, but I set it to 2, then back to
 > 1, and now the scrollbars appear where they should. If I set it to 2
 > the problem reappears.
 >
 > The question now is: is this an emacs or a GTK bug?

Then everything is clear.  Glenn Morris intimately knows the list of
bugs already filed for this issue.  This won't be funny :-(

martin

bug#21469: 25.0.50; right scrollbar wrongly placed when resizing split window

[martin rudalics]

 > Glenn Morris intimately knows the list of
 > bugs already filed for this issue.

And that list was so far bug#18429, bug#20619 and bug#21348.

martin

bug#21469: 25.0.50; right scrollbar wrongly placed when resizing split window

[martin rudalics]

 > emacs -Q
 > C-x 3 # split-window-right
 > Then use the mouse to move the horizontal separator in the middle of
 > the mode-line to the left. The frame stays the same size, but the
 > right scrollbar moves inwards from the right edge. It also appears
 > that the right scrollbar controls the window to the left, not the
 > window to the right.
 >
 > This is with git emacs commit 166812addb0a1b9b2258ef3ce76424cd7facfa8b
 >
 > If I rebuild using ‘--without-toolkit-scroll-bars’ everything works as
 > expected.
 >
 > In GNU Emacs 25.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.14.13)
 >   of 2015-09-13

Robert, is this still an issue?

martin

bug#21469: 25.0.50; right scrollbar wrongly placed when resizing split window

[Robert Pluim]

martin rudalics <rudalics@gmx.at> writes:

>> emacs -Q
>> C-x 3 # split-window-right
>> Then use the mouse to move the horizontal separator in the middle of
>> the mode-line to the left. The frame stays the same size, but the
>> right scrollbar moves inwards from the right edge. It also appears
>> that the right scrollbar controls the window to the left, not the
>> window to the right.
>>
>> This is with git emacs commit 166812addb0a1b9b2258ef3ce76424cd7facfa8b
>>
>> If I rebuild using ‘--without-toolkit-scroll-bars’ everything works as
>> expected.
>>
>> In GNU Emacs 25.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.14.13)
>>   of 2015-09-13
>
> Robert, is this still an issue?

No. I think it got fixed when Lars implemented a bunch of GTK scaling
fixes (or maybe I fixed it :-) ). In any case current emacs-26 doesn't
have this bug. Closing.

Robert