bug#32177: Current line number shifts one column to the left.

bug#32177: Current line number shifts one column to the left.

[Keith David Bershatsky]

1.  Launch a newly built GUI version of Emacs master branch (07/16/2018).

2.  WINDOWS XP -- GUI Emacs:  From the *GNU Emacs* welcome screen, type M-: and evaluate the following:

    (progn
      (switch-to-buffer (get-buffer-create "foo"))
      (setq header-line-format "foo")
      (display-line-numbers-mode 1)
      (setq bidi-display-reordering nil)
      (dotimes (i 57)
        (insert "\n"))
      (recenter 1)
      (sit-for 1)
      (insert "@"))

[OR]

2.  OSX 10.6.8 GUI Emacs:  From the *GNU Emacs* welcome screen, type M-: and evaluate the following:

    (progn
      (switch-to-buffer (get-buffer-create "foo"))
      (setq header-line-format "foo")
      (display-line-numbers-mode 1)
      (setq bidi-display-reordering nil)
      (dotimes (i 50)
        (insert "\n"))
      (recenter 1)
      (sit-for 1)
      (insert "@"))

3.  Observe that line number 58 (on Windows XP), or line number 51 (on OSX 10.6.8), shifts one column to the left of where it should be.  Here is a link to a screenshot depicting the bug with both versions of Emacs (Windows / OSX):

https://www.lawlist.com/images/bug_07_16_2018.png

A modification of the current line is necessary to reproduce this bug.  In my case, I notice the bug a few times each day when I place an overlay on the current line.  The bug is rather elusive and requires just the right circumstances to see it happen.  For example, if I _first_ kill the *GNU Emacs* buffer, then the code above in Step #2 is insufficient to reproduce the bug.

On OSX 10.6.8, my build configuration is:

CFLAGS='-O0 -g3' ./configure \
--with-ns \
--enable-checking='yes,glyphs' \
--enable-check-lisp-object-type \
--without-compress-install \
--without-makeinfo \
--with-gnutls=no \
--with-mailutils \
--without-makeinfo

On Windows XP, my build configuration is:

CFLAGS='-O0 -g3' ./configure \
--prefix=/c/docume~1/admini~1/desktop/trunk \
--enable-checking='yes,glyphs' \
--enable-check-lisp-object-type \
--without-compress-install \
--without-makeinfo \
--with-gnutls=no \
--with-mailutils \
--without-makeinfo

bug#32177: Current line number shifts one column to the left.

[Eli Zaretskii]

> Date: Mon, 16 Jul 2018 10:36:12 -0700
> From: Keith David Bershatsky <esq@lawlist.com>
> 
> 1.  Launch a newly built GUI version of Emacs master branch (07/16/2018).
> 
> 2.  WINDOWS XP -- GUI Emacs:  From the *GNU Emacs* welcome screen, type M-: and evaluate the following:
> 
>     (progn
>       (switch-to-buffer (get-buffer-create "foo"))
>       (setq header-line-format "foo")
>       (display-line-numbers-mode 1)
>       (setq bidi-display-reordering nil)
>       (dotimes (i 57)
>         (insert "\n"))
>       (recenter 1)
>       (sit-for 1)
>       (insert "@"))
> 
> [OR]
> 
> 2.  OSX 10.6.8 GUI Emacs:  From the *GNU Emacs* welcome screen, type M-: and evaluate the following:
> 
>     (progn
>       (switch-to-buffer (get-buffer-create "foo"))
>       (setq header-line-format "foo")
>       (display-line-numbers-mode 1)
>       (setq bidi-display-reordering nil)
>       (dotimes (i 50)
>         (insert "\n"))
>       (recenter 1)
>       (sit-for 1)
>       (insert "@"))
> 
> 3.  Observe that line number 58 (on Windows XP), or line number 51 (on OSX 10.6.8), shifts one column to the left of where it should be.  Here is a link to a screenshot depicting the bug with both versions of Emacs (Windows / OSX):
> 
> https://www.lawlist.com/images/bug_07_16_2018.png

Actually, the screenshot shows that line number 57 is to the right of
where it should have been.

In any case, I cannot reproduce this here, not in "emacs -Q", not on
master and not on the emacs-26 branch.

Why did you need to turn off bidi-display-reordering?  Does the
problem go away when you don't do that?

bug#32177: Current line number shifts one column to the left.

[Eli Zaretskii]

> Date: Mon, 16 Jul 2018 21:20:04 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 32177@debbugs.gnu.org
> 
> In any case, I cannot reproduce this here, not in "emacs -Q", not on
> master and not on the emacs-26 branch.

I succeeded in reproducing this, but only if I enlarge the frame so it
is taller than the default.

bug#32177: Current line number shifts one column to the left.

[Keith David Bershatsky]

Thank you, Eli, for looking into issue #32177.  I was happy to hear that you were eventually able to reproduce the bug on your end.

I was able to reproduce the issue on my end with bidi-display-reordering set to a non-nil value of t, but it will take some time to come up with an emacs -Q recipe.

Although it is not often very that I need to inspect the undo-tree history file, setting bidi-display-reordering to a nil value of t gives a tremendous enhancement to movements within that buffer.  Without setting bidi-display-reordering to nil, movements with arrow keys up/down and so forth is unbearably s-l-o-w.  Occasionally, I have to inspect the desktop save file and that too has some very long lines where I think setting bidi-display-reordering may help.  Here is a little snippet written by Noam Postavsky that produces a line matching the format of the undo-tree history file.

    (require 'cl-lib)

    (defun make-deep-object (depth)
      (let ((obj 1))
        (while (> (cl-decf depth) 0)
          (setq obj (vector (list obj))))
        obj))

    (setq print-circle t)

    (let ((buf (get-buffer-create "*test*")))
      (with-current-buffer buf
        (insert (prin1-to-string (make-deep-object 4964))))
      (switch-to-buffer buf))

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

DATE:  [07-16-2018 11:20:04] <16 Jul 2018 21:20:04 +0300>
FROM:  Eli Zaretskii <eliz@gnu.org>
> 
> * * *
> 
> Why did you need to turn off bidi-display-reordering?  Does the
> problem go away when you don't do that?

bug#32177: Current line number shifts one column to the left.

[Keith David Bershatsky]

I take back (in part) what I said below.  It turned out that one of the settings in the org-mode buffer I am using is (setq bidi-paragraph-direction 'left-to-right), which _also_ can be used to reproduce issue 32177.  So it looks like we can use either bidi-paragraph-direction or bidi-display-reordering to reproduce issue 32177.

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

DATE:  [07-16-2018 13:33:03] <16 Jul 2018 13:33:03 -0700>
FROM:  Keith David Bershatsky <esq@lawlist.com>
> 
> * * *
> 
> I was able to reproduce the issue on my end with bidi-display-reordering set to a non-nil value of t, but it will take some time to come up with an emacs -Q recipe.
> 
> * *

bug#32177: Current line number shifts one column to the left.

[Eli Zaretskii]

> Date:  Mon, 16 Jul 2018 13:33:03 -0700
> From:  Keith David Bershatsky <esq@lawlist.com>
> Cc:  32177@debbugs.gnu.org
> 
> Although it is not often very that I need to inspect the undo-tree history file, setting bidi-display-reordering to a nil value of t gives a tremendous enhancement to movements within that buffer.  Without setting bidi-display-reordering to nil, movements with arrow keys up/down and so forth is unbearably s-l-o-w.  Occasionally, I have to inspect the desktop save file and that too has some very long lines where I think setting bidi-display-reordering may help.  Here is a little snippet written by Noam Postavsky that produces a line matching the format of the undo-tree history file.

You should know that setting that variable to nil is not supported, so
you are playing with fire, that's all.

bug#32177: Current line number shifts one column to the left.

[Eli Zaretskii]

> Date: Mon, 16 Jul 2018 21:40:29 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 32177@debbugs.gnu.org
> 
> > Date: Mon, 16 Jul 2018 21:20:04 +0300
> > From: Eli Zaretskii <eliz@gnu.org>
> > Cc: 32177@debbugs.gnu.org
> > 
> > In any case, I cannot reproduce this here, not in "emacs -Q", not on
> > master and not on the emacs-26 branch.
> 
> I succeeded in reproducing this, but only if I enlarge the frame so it
> is taller than the default.

And I no longer can reproduce this, so a more reliable recipe is
needed.

Thanks.