bug#29002: it.first_visible_x is erroneously 0 while horizontal scrolling.

bug#29002: it.first_visible_x is erroneously 0 while horizontal scrolling.

[Keith David Bershatsky]

I am working on developing crosshairs (#17684) and multiple fake cursors (#22873).  As part of that work, I need the correct it.first_visible_x in the example recipe listed below.  I have tried to workaround the bug by using w->hscroll * FRAME_COLUMN_WIDTH (f); however, I have not been able to come up with a programmatic test to identify the bug in order to implement the workaround.  Implementing a workaround is complicated because I visit each visible screen line with IT, and hscl is true in this situation:

  bool hscl = (!w->suspend_auto_hscroll
               && EQ (Fbuffer_local_value (Qauto_hscroll_mode, w->contents), Qcurrent_line)
               && w->hscroll > 0);

Here is the recipe:

STEP #1:  Build a new Emacs master branch incorporating the function `bug-hscroll` at an appropriate location inside xdisp.c.

DEFUN ("bug-hscroll", Fbug_hscroll, Sbug_hscroll, 0, 0, 0,
       doc: /* Demonstrate the Emacs hscroll bug. */)
  (void)
{
  struct window *w = decode_live_window (selected_window);
  struct it it;
  void *itdata = bidi_shelve_cache ();
  struct text_pos start_text_position;
  int first_x;
  SET_TEXT_POS_FROM_MARKER (start_text_position, w->start);
  start_display (&it, w, start_text_position);
  first_x = it.first_visible_x;
  bidi_unshelve_cache (itdata, false);
  Lisp_Object my_object_one = make_number (first_x);
  AUTO_STRING (my_string_one, "This is the value of it.first_visible_x:  %s");
  CALLN (Fmessage, my_string_one, my_object_one);
  return make_number (first_x);
}

void
syms_of_xdisp (void)
{

  defsubr (&Sbug_hscroll);
  DEFSYM (Qbug_hscroll, "bug-hscroll");

***

}


STEP #2:  Open the newly built Emacs; open a scratch buffer; and evaluate the following elisp code.

(define-key global-map (kbd "<wheel-right>") (lambda () (interactive) (scroll-right 1)))
(define-key global-map [f5] (lambda () (interactive) (bug-hscroll)))

(setq-local auto-hscroll-mode 'current-line)
(setq display-line-numbers t)
(setq truncate-lines t)


STEP #3:  Paste some miscellaneous long lines into the scratch buffer, e.g.,:

Aliquam erat volutpat. Nunc eleifend leo vitae magna. In id erat non orci commodo lobortis. Proin neque massa, cursus ut, gravida ut, lobortis eget, lacus. Sed diam. Praesent fermentum tempor tellus. Nullam tempus. Mauris ac felis vel velit tristique imperdiet. Donec at pede. Etiam vel neque nec dui dignissim bibendum. Vivamus id enim. Phasellus neque orci, porta a, aliquet quis, semper a, massa. Phasellus purus. Pellentesque tristique imperdiet tortor. Nam euismod tellus id erat.

Nullam eu ante vel est convallis dignissim. Fusce suscipit, wisi nec facilisis facilisis, est dui fermentum leo, quis tempor ligula erat quis odio. Nunc porta vulputate tellus. Nunc rutrum turpis sed pede. Sed bibendum. Aliquam posuere. Nunc aliquet, augue nec adipiscing interdum, lacus tellus malesuada massa, quis varius mi purus non odio. Pellentesque condimentum, magna ut suscipit hendrerit, ipsum augue ornare nulla, non luctus diam neque sit amet urna. Curabitur vulputate vestibulum lorem. Fusce sagittis, libero non molestie mollis, magna orci ultrices dolor, at vulputate neque nulla lacinia eros. Sed id ligula quis est convallis tempor. Curabitur lacinia pulvinar nibh. Nam a sapien.

Nullam eu ante vel est convallis dignissim. Fusce suscipit, wisi nec facilisis facilisis, est dui fermentum leo, quis tempor ligula erat quis odio. Nunc porta vulputate tellus. Nunc rutrum turpis sed pede. Sed bibendum. Aliquam posuere. Nunc aliquet, augue nec adipiscing interdum, lacus tellus malesuada massa, quis varius mi purus non odio. Pellentesque condimentum, magna ut suscipit hendrerit, ipsum augue ornare nulla, non luctus diam neque sit amet urna. Curabitur vulputate vestibulum lorem. Fusce sagittis, libero non molestie mollis, magna orci ultrices dolor, at vulputate neque nulla lacinia eros. Sed id ligula quis est convallis tempor. Curabitur lacinia pulvinar nibh. Nam a sapien.


STEP #4:  Place the cursor at the END of one of the newly pasted long lines of miscellaneous text.


STEP #5:  Scroll right using the horizontal mouse wheel (if you have one, or some equivalent thereof if you don't).


STEP #6:  Press the F5 key.  See that it.first_visible_x is GREATER than 0.


STEP #7:  Move the arrow key one character to the left.  We remain horizontally scrolled to the right; i.e., pressing the left arrow-key does not cancel the horizontal scrolling.


STEP #8:  Press the F5 key.  See that it.first_visible_x is erroneously 0.


EXPECTATION:  it.first_visible_x should be equal to w->hscroll * FRAME_COLUMN_WIDTH (f).  And, keep in mind that the current-line can also horizontally scroll ...


Thanks,

Keith

bug#29002: it.first_visible_x is erroneously 0 while horizontal scrolling.

[Keith David Bershatsky]

Here is a link to a screen-shot depicting #29002:

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

bug#29002: it.first_visible_x is erroneously 0 while horizontal scrolling.

[Eli Zaretskii]

On October 26, 2017 6:45:57 AM GMT+03:00, Keith David Bershatsky <esq@lawlist.com> wrote:
> Here is a link to a screen-shot depicting #29002:
> 
> https://www.lawlist.com/images/bug_hscl.png

This is not a bug; your expectations are incorrect.  To see why, modify your
recipe to omit the "scroll right" part (step 5).  You will see that bug-hscroll
reports zero.

When hscrolling only the current line, first_visible_x is set to zero, to
reflect the situation for the non-current lines, which are normally not
hscrolled.  However, if you invoke scroll-right, the non-current lines
become hscrolled, so you see a non-zero value of first_visible_x.
In addition, the manual hscroll temporarily disables auto-hscrolling,
and moving cursor re-enables it, which is why gou see the value
reset to zero.

Yes, it's complicated...

I'm not sure why you expected non-zero values in this case, but if you
want to identify this situation, use the function
hscrolling_current_line_p.  Or just calculate the value yourself
using w->hscroll.

bug#29002: it.first_visible_x is erroneously 0 while horizontal scrolling.

[Keith David Bershatsky]

Thank you, Eli, for looking at #29002.

In the screen-shot, line 4 is the current-line and it is hscrolled.

• hscrolling_current_line_p is true.

• w->suspend_auto_hscroll is false.

• w->hscroll > 0.

• All non-current lines are also hscrolled.

• it.first_visible_x == 0.

What would be a good method to programmatically test to see whether all other lines are hscrolled given the above?

As I visit each screen line from top to bottom of the window, I will need to determine whether the line is hscrolled and then try make my way over to a screen relative X coordinate.  move_it_in_display_line_to will need an absolute X.

For example, let's say we are on line 6 in the screen-shot.  How do we know that it is hscrolled?  If we know for sure it is hscrolled, then we can tell move_it_in_display_line_to try and reach (w->hscroll * FRAME_COLUMN_WIDTH (f)) + my_arbitrary_screen_relative_x.

Keith

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

DATE:  [10-25-2017 21:51:55] <26 Oct 2017 07:51:55 +0300>
FROM:  Eli Zaretskii <eliz@gnu.org>
> 
>  * * *
> 
> I'm not sure why you expected non-zero values in this case, but if you
> want to identify this situation, use the function
> hscrolling_current_line_p.  Or just calculate the value yourself
> using w->hscroll.

bug#29002: it.first_visible_x is erroneously 0 while horizontal scrolling.

[Eli Zaretskii]

> Date:  Wed, 25 Oct 2017 23:20:09 -0700
> From:  Keith David Bershatsky <esq@lawlist.com>
> Cc:  29002@debbugs.gnu.org
> 
> • hscrolling_current_line_p is true.
> • w->suspend_auto_hscroll is false.
> • w->hscroll > 0.
> • All non-current lines are also hscrolled.
> • it.first_visible_x == 0.
> 
> What would be a good method to programmatically test to see whether all other lines are hscrolled given the above?

The above means that auto-hscroll is set to 'current-line'.  In this
case, the line that shows point is hscrolled by w->hscroll, and all
the other lines are hscrolled by w->min_hscroll (in units of the
frame's canonical character width).

bug#29002: it.first_visible_x is erroneously 0 while horizontal scrolling.

[Keith David Bershatsky]

Thank you for the suggestion about using w->min_hscroll.

Unfortunately, w->min_hscroll returns a value of 0 in this example.

Here is a link to a new screen-shot based upon the revised bug-hscroll test incorporating w->min_hscroll:

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

And, here is the revised test used as a basis to create the new screen-shot:

DEFUN ("bug-hscroll", Fbug_hscroll, Sbug_hscroll, 0, 0, 0,
       doc: /* Demonstrate the Emacs hscroll bug. */)
  (void)
{
  struct window *w = decode_live_window (selected_window);
  struct it it;
  void *itdata = bidi_shelve_cache ();
  struct text_pos start_text_position;
  int first_x, min_hscroll;
  SET_TEXT_POS_FROM_MARKER (start_text_position, w->start);
  start_display (&it, w, start_text_position);
  first_x = it.first_visible_x;
  min_hscroll = w->min_hscroll;
  bidi_unshelve_cache (itdata, false);
  Lisp_Object my_object_one = make_number (first_x);
  Lisp_Object my_object_two = make_number (min_hscroll);
  AUTO_STRING (my_string_one, "it.first_visible_x:  %s | w->min_hscroll:  %d");
  CALLN (Fmessage, my_string_one, my_object_one, my_object_two);
  return make_number (first_x);
}

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

DATE:  [10-26-2017 08:56:23] <26 Oct 2017 18:56:23 +0300>
FROM:  Eli Zaretskii <eliz@gnu.org>
> 
>  * * *
> > 
> > • hscrolling_current_line_p is true.
> > • w->suspend_auto_hscroll is false.
> > • w->hscroll > 0.
> > • All non-current lines are also hscrolled.
> > • it.first_visible_x == 0.
> > 
> > What would be a good method to programmatically test to see whether all other lines are hscrolled given the above?
> 
> The above means that auto-hscroll is set to 'current-line'.  In this
> case, the line that shows point is hscrolled by w->hscroll, and all
> the other lines are hscrolled by w->min_hscroll (in units of the
> frame's canonical character width).

bug#29002: it.first_visible_x is erroneously 0 while horizontal scrolling.

[Eli Zaretskii]

> Date:  Thu, 26 Oct 2017 11:56:08 -0700
> From:  Keith David Bershatsky <esq@lawlist.com>
> Cc:  29002@debbugs.gnu.org
> 
> Unfortunately, w->min_hscroll returns a value of 0 in this example.

For the lines other than the current one, you should use
it.first_visible_x, it is simpler.  For the current line, use
w->hscroll.

bug#29002: it.first_visible_x is erroneously 0 while horizontal scrolling.

[Keith David Bershatsky]

Here is a link to screen-shot #3:

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

In that screen-shot, we make the following observations:

* A total of 5 screen lines.

* Line 1 is the current line.

* All 5 lines visually appear to be horizontally scrolled.

* Using the revised function bug-hscroll (below), we iterate over each screen line and generate the values for it.first_visible_x and it.vpos.

* it.first_visible_x returns as being 0 for each of the 5 screen lines.

It is as though Emacs is unaware that the non-current lines still visually appear to be hscrolled, because Emacs "thinks" they are not.

DEFUN ("bug-hscroll", Fbug_hscroll, Sbug_hscroll, 0, 0, 0,
       doc: /* Demonstrate the Emacs hscroll bug. */)
  (void)
{
  struct window *w = decode_live_window (selected_window);
  struct it it;
  void *itdata = bidi_shelve_cache ();
  struct text_pos start_text_position;
  Lisp_Object temp = Qnil;
  Lisp_Object result = Qnil;
  Vmax_mini_window_height = make_number (1);
  SET_TEXT_POS_FROM_MARKER (start_text_position, w->start);
  start_display (&it, w, start_text_position);
  while (true)
    {
      temp = listn (CONSTYPE_HEAP, 3,
                    make_number (it.vpos),
                    build_string (" | "),
                    make_number (it.first_visible_x));
      result = Fcons (temp, result);
      if (IT_CHARPOS (it) == ZV)
        break;
      move_it_by_lines (&it, 1);
      if (it.current_y >= it.last_visible_y)
        break;
    }
  bidi_unshelve_cache (itdata, false);
  result = Fnreverse (result);
  AUTO_STRING (my_string_one, "%s");
  CALLN (Fmessage, my_string_one, result);
  return result;
}

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

DATE:  [10-29-2017 04:23:07] <29 Oct 2017 13:23:07 +0200>
FROM:  Eli Zaretskii <eliz@gnu.org>
> 
> > Date:  Thu, 26 Oct 2017 11:56:08 -0700
> > From:  Keith David Bershatsky <esq@lawlist.com>
> > Cc:  29002@debbugs.gnu.org
> > 
> > Unfortunately, w->min_hscroll returns a value of 0 in this example.
> 
> For the lines other than the current one, you should use
> it.first_visible_x, it is simpler.  For the current line, use
> w->hscroll.

bug#29002: it.first_visible_x is erroneously 0 while horizontal scrolling.

[Eli Zaretskii]

> Date:  Sun, 29 Oct 2017 10:29:29 -0700
> From:  Keith David Bershatsky <esq@lawlist.com>
> Cc:  29002@debbugs.gnu.org
> 
> Here is a link to screen-shot #3:
> 
> https://www.lawlist.com/images/bug_hscl_03.png
> 
> In that screen-shot, we make the following observations:
> 
> * A total of 5 screen lines.
> 
> * Line 1 is the current line.
> 
> * All 5 lines visually appear to be horizontally scrolled.
> 
> * Using the revised function bug-hscroll (below), we iterate over each screen line and generate the values for it.first_visible_x and it.vpos.
> 
> * it.first_visible_x returns as being 0 for each of the 5 screen lines.

This cannot be true: if every line in the window is hscrolled,
first_visible_x must be non-zero, right after the call to
start_display.  If first_visible_x is zero, only the current line can
be hscrolled.

bug#29002: it.first_visible_x is erroneously 0 while horizontal scrolling.

[Eli Zaretskii]

> Date: Sun, 29 Oct 2017 20:29:16 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 29002@debbugs.gnu.org
> 
> > * A total of 5 screen lines.
> > 
> > * Line 1 is the current line.
> > 
> > * All 5 lines visually appear to be horizontally scrolled.
> > 
> > * Using the revised function bug-hscroll (below), we iterate over each screen line and generate the values for it.first_visible_x and it.vpos.
> > 
> > * it.first_visible_x returns as being 0 for each of the 5 screen lines.
> 
> This cannot be true: if every line in the window is hscrolled,
> first_visible_x must be non-zero, right after the call to
> start_display.

Forgot to say: I cannot reproduce your results.  In my case,
first_visible_x is non-zero all the way through the loop, as expected.

Are you sure this isn't a side effect of one of your other changes?

bug#29002: it.first_visible_x is erroneously 0 while horizontal scrolling.

[Keith David Bershatsky]

I agree ... and that leads us to bug #29002.  :)

In the normal situation, the screen refreshes when the arrow key is used and non-current lines cease to be horizontally scrolled.  In the current example, however, non-current lines remain horizontally scrolled and Emacs "thinks" that they are not.  When I say that Emacs "thinks" they are not, I am referring to IT.

There are few ways that I look at this unique situation:

A.  If the Emacs design is to permit non-current lines to remain horizontally scrolled in this unique situation, then we may need something like a new window pointer to store the value of the first-visible-x for those non-current lines.

  OR

B.  If the Emacs design is NOT to permit non-current lines to remain horizontally scrolled in this unique situation, then redisplay needs to refresh all non-current lines so that they snap back to a non-horizontal scroll state.

  OR

C.  IT is incorrect such that it.first_visible_x needs to be changed to reflect the proper value.  [From an untrained eye, it looks like the value is the same as w->hscroll in this unique situation.]

If this unique situation is "a feature", then we need a way to properly calculate the first-visible-x for non-current lines.  If this is *not* a feature, then redisplay should refresh all non-current lines so that they are no longer horizontally scrolled.

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

DATE:  [10-29-2017 11:29:16] <29 Oct 2017 20:29:16 +0200>
FROM:  Eli Zaretskii <eliz@gnu.org>
> 
> > Date:  Sun, 29 Oct 2017 10:29:29 -0700
> > From:  Keith David Bershatsky <esq@lawlist.com>
> > Cc:  29002@debbugs.gnu.org
> > 
> > Here is a link to screen-shot #3:
> > 
> > https://www.lawlist.com/images/bug_hscl_03.png
> > 
> > In that screen-shot, we make the following observations:
> > 
> > * A total of 5 screen lines.
> > 
> > * Line 1 is the current line.
> > 
> > * All 5 lines visually appear to be horizontally scrolled.
> > 
> > * Using the revised function bug-hscroll (below), we iterate over each screen line and generate the values for it.first_visible_x and it.vpos.
> > 
> > * it.first_visible_x returns as being 0 for each of the 5 screen lines.
> 
> This cannot be true: if every line in the window is hscrolled,
> first_visible_x must be non-zero, right after the call to
> start_display.  If first_visible_x is zero, only the current line can
> be hscrolled.

bug#29002: it.first_visible_x is erroneously 0 while horizontal scrolling.

[Keith David Bershatsky]

For all of the tests referred to in #29002, I have been using Emacs master branch from October 23, 2007.  The _only_ modifications to the code base have been within xdisp.c by adding the function bug-hscroll and the defsubr / DEFSYM in syms_of_xdisp.  No other changes exist.  I am on OSX 10.6.8.

I can build Emacs on Windows XP and see if the results are the same, but it will take about 30 to 45 minutes to download and build anew.

I suspect that this unique situation is not "a feature" and the problem may lie within the need to refresh the screen for non-current lines, since IT "thinks" they are not horizontally scrolled.  However, I thought to myself that this could be a cool feature that I have never seen except in this unique situation.

Keith

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

DATE:  [10-29-2017 11:56:05] <29 Oct 2017 20:56:05 +0200>
FROM:  Eli Zaretskii <eliz@gnu.org>
> 
>  scrolling.
> 
> > Date: Sun, 29 Oct 2017 20:29:16 +0200
> > From: Eli Zaretskii <eliz@gnu.org>
> > Cc: 29002@debbugs.gnu.org
> > 
> > > * A total of 5 screen lines.
> > > 
> > > * Line 1 is the current line.
> > > 
> > > * All 5 lines visually appear to be horizontally scrolled.
> > > 
> > > * Using the revised function bug-hscroll (below), we iterate over each screen line and generate the values for it.first_visible_x and it.vpos.
> > > 
> > > * it.first_visible_x returns as being 0 for each of the 5 screen lines.
> > 
> > This cannot be true: if every line in the window is hscrolled,
> > first_visible_x must be non-zero, right after the call to
> > start_display.
> 
> Forgot to say: I cannot reproduce your results.  In my case,
> first_visible_x is non-zero all the way through the loop, as expected.
> 
> Are you sure this isn't a side effect of one of your other changes?

bug#29002: it.first_visible_x is erroneously 0 while horizontal scrolling.

[Eli Zaretskii]

> Date:  Sun, 29 Oct 2017 11:56:22 -0700
> From:  Keith David Bershatsky <esq@lawlist.com>
> Cc:  29002@debbugs.gnu.org
> 
> I agree ... and that leads us to bug #29002.  :)
> 
> In the normal situation, the screen refreshes when the arrow key is used and non-current lines cease to be horizontally scrolled.  In the current example, however, non-current lines remain horizontally scrolled and Emacs "thinks" that they are not.  When I say that Emacs "thinks" they are not, I am referring to IT.

What Emacs "thinks" is on display.  And there we see hscrolled lines.
So first_visible_x must be non-zero, and that is what I see.  If
first_visible_x were zero, you'd see the line's text starting with the
first character of each line.  I very much doubt that this is somehow
Windows-specific, since xdisp.c is the platform-independent part of
the display engine.

Or maybe the horizontal scroll bar on macOS somehow causes this.  What
happens if you scroll-right with some key, like F8, and not with the
mouse?

(In any case, invoking scroll-right in this situation makes very
little sense to me.)

bug#29002: it.first_visible_x is erroneously 0 while horizontal scrolling.

[Keith David Bershatsky]

Horizontal scroll bars are not visible in this example.  I have been using the horizontal mouse-wheel.  I can reproduce the issue by evaluating (scroll-right 1) in the minibuffer when at the end of a long-line, and then pressing the left arrow-key, and then calling F5 (bound to bug-hscroll).

It appears to me that (scroll-right 1) is kind of a temporary form of horizontal scrolling, which automatically cancels as to non-current lines in a vareity of situations when keyboard input is received.  Plain old scroll-right without the optional distance argument is semi-permanent, and non-current lines do not automatically return to a non-scrolled state.

F8 is undefined on OSX, but I saw in a grep search that "C-x >" is bound to scroll-right.  That behaves differently than (scroll-right 1) using the optional argument to control the distance.  I also tried using "C-u 1 C-x >", but it behaves the same as "C-x >".

The issue described in #29002 is not present when invoking "C-u 1 C-x >" or "C-x >" -- i.e., both of which appear to be semi-permanent forms of horizontal scrolling.

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

DATE:  [10-29-2017 12:23:33] <29 Oct 2017 21:23:33 +0200>
FROM:  Eli Zaretskii <eliz@gnu.org>
> 
> > Date:  Sun, 29 Oct 2017 11:56:22 -0700
> > From:  Keith David Bershatsky <esq@lawlist.com>
> > Cc:  29002@debbugs.gnu.org
> > 
> > I agree ... and that leads us to bug #29002.  :)
> > 
> > In the normal situation, the screen refreshes when the arrow key is used and non-current lines cease to be horizontally scrolled.  In the current example, however, non-current lines remain horizontally scrolled and Emacs "thinks" that they are not.  When I say that Emacs "thinks" they are not, I am referring to IT.
> 
> What Emacs "thinks" is on display.  And there we see hscrolled lines.
> So first_visible_x must be non-zero, and that is what I see.  If
> first_visible_x were zero, you'd see the line's text starting with the
> first character of each line.  I very much doubt that this is somehow
> Windows-specific, since xdisp.c is the platform-independent part of
> the display engine.
> 
> Or maybe the horizontal scroll bar on macOS somehow causes this.  What
> happens if you scroll-right with some key, like F8, and not with the
> mouse?
> 
> (In any case, invoking scroll-right in this situation makes very
> little sense to me.)

bug#29002: it.first_visible_x is erroneously 0 while horizontal scrolling.

[Eli Zaretskii]

> Date:  Sun, 29 Oct 2017 13:12:15 -0700
> From:  Keith David Bershatsky <esq@lawlist.com>
> Cc:  29002@debbugs.gnu.org
> 
> It appears to me that (scroll-right 1) is kind of a temporary form of horizontal scrolling, which automatically cancels as to non-current lines in a vareity of situations when keyboard input is received.  Plain old scroll-right without the optional distance argument is semi-permanent, and non-current lines do not automatically return to a non-scrolled state.

Yes, it's temporary.  For a permanent hscroll, you need to invoke
scroll-left/right with its second argument non-nil (which happens
automatically in interactive invocation).

Does the hscroll get reset after moving cursor if you type "M-x"?

bug#29002: it.first_visible_x is erroneously 0 while horizontal scrolling.

[Keith David Bershatsky]

Yes, "M-x" immediately cancels the hscroll of non-current lines when called after moving the cursor.

Thank you for explaining how the second optional argument in scroll-right/left can be used to obtain a permanent hscroll.  :)

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

DATE:  [10-30-2017 11:02:27] <30 Oct 2017 20:02:27 +0200>
FROM:  Eli Zaretskii <eliz@gnu.org>
> 
> > Date:  Sun, 29 Oct 2017 13:12:15 -0700
> > From:  Keith David Bershatsky <esq@lawlist.com>
> > Cc:  29002@debbugs.gnu.org
> > 
> > It appears to me that (scroll-right 1) is kind of a temporary form of horizontal scrolling, which automatically cancels as to non-current lines in a vareity of situations when keyboard input is received.  Plain old scroll-right without the optional distance argument is semi-permanent, and non-current lines do not automatically return to a non-scrolled state.
> 
> Yes, it's temporary.  For a permanent hscroll, you need to invoke
> scroll-left/right with its second argument non-nil (which happens
> automatically in interactive invocation).
> 
> Does the hscroll get reset after moving cursor if you type "M-x"?

bug#29002: it.first_visible_x is erroneously 0 while horizontal scrolling.

[Eli Zaretskii]

> Date:  Mon, 30 Oct 2017 12:36:38 -0700
> From:  Keith David Bershatsky <esq@lawlist.com>
> Cc:  29002@debbugs.gnu.org
> 
> Yes, "M-x" immediately cancels the hscroll of non-current lines when called after moving the cursor.

OK, I installed a change which should fix the hscroll after cursor
motion.

With that, I'm marking this bug done.

Thanks.

bug#29002: it.first_visible_x is erroneously 0 while horizontal scrolling.

[Keith David Bershatsky]

Yes, your patch does indeed fix the issue.

Greatly appreciated,

Keith

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

DATE:  [11-04-2017 02:32:04] <04 Nov 2017 11:32:04 +0200>
FROM:  Eli Zaretskii <eliz@gnu.org>
> 
> > Date:  Mon, 30 Oct 2017 12:36:38 -0700
> > From:  Keith David Bershatsky <esq@lawlist.com>
> > Cc:  29002@debbugs.gnu.org
> > 
> > Yes, "M-x" immediately cancels the hscroll of non-current lines when called after moving the cursor.
> 
> OK, I installed a change which should fix the hscroll after cursor
> motion.
> 
> With that, I'm marking this bug done.
> 
> Thanks.

bug#29002: it.first_visible_x is erroneously 0 while horizontal scrolling.

[Keith David Bershatsky]

The new fix relating to #29002 has an unintended side-effect of causing a full redisplay too often, e.g., when using isearch.

I am uncertain why the current Emacs design sets w->suspend_auto_hscroll to *true* every command loop, but that is what causes the new condition to force a thorough redisplay much more often than is actually needed.


	  /* If the position of this window's point has explicitly
	     changed, no more suspend auto hscrolling.  */
	  if (w->suspend_auto_hscroll
	      && NILP (Fequal (Fwindow_point (window),
			       Fwindow_old_point (window))))
	    {

AUTO_STRING (my_string_one, "Hello world!");
CALLN (Fmessage, my_string_one);

	      w->suspend_auto_hscroll = false;
	      /* Force thorough redisplay of this window, to show the
		 effect of disabling hscroll suspension immediately.  */
	      SET_FRAME_GARBAGED (XFRAME (w->frame));
	    }

bug#29002: it.first_visible_x is erroneously 0 while horizontal scrolling.

[Eli Zaretskii]

On November 5, 2017 11:15:41 AM GMT+02:00, Keith David Bershatsky <esq@lawlist.com> wrote:
> The new fix relating to #29002 has an unintended side-effect of
> causing a full redisplay too often, e.g., when using isearch.
> 
> I am uncertain why the current Emacs design sets
> w->suspend_auto_hscroll to *true* every command loop, but that is what
> causes the new condition to force a thorough redisplay much more often
> than is actually needed.
> 
> 
> 	  /* If the position of this window's point has explicitly
> 	     changed, no more suspend auto hscrolling.  */
> 	  if (w->suspend_auto_hscroll
> 	      && NILP (Fequal (Fwindow_point (window),
> 			       Fwindow_old_point (window))))
> 	    {
> 
> AUTO_STRING (my_string_one, "Hello world!");
> CALLN (Fmessage, my_string_one);
> 
> 	      w->suspend_auto_hscroll = false;
> 	      /* Force thorough redisplay of this window, to show the
> 		 effect of disabling hscroll suspension immediately.  */
> 	      SET_FRAME_GARBAGED (XFRAME (w->frame));
> 	    }

Please describe a recipe where you see suspend_auto_hscroll being
set true every command loop.

bug#29002: it.first_visible_x is erroneously 0 while horizontal scrolling.

[Keith David Bershatsky]

Step # 1:  Download a fresh copy of the emacs-26 branch.

Step # 2:  Inside the function `set_window_hscroll` within window.c, add a message just before the function returns.

AUTO_STRING (my_string_one, "window.c:  set_window_hscroll");
CALLN (Fmessage, my_string_one);

Step # 3:  Build the new Emacs, and launch without any user configuration.

Step # 4:  From the Welcome screen, type:  C-r

Step # 5:  Slowly type the word Emacs and watch the echo area as you type each letter.

Inasmuch as the function `set_window_hscroll` is being called each time we type a letter, the proposed fix to #29002 causes a thorough redisplay after every keystroke while using isearch.  This is probably not limited to isearch -- it was just the first occasion where the side affect was immediately noticeable.

Keith

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

DATE:  [11-05-2017 02:44:39] <05 Nov 2017 12:44:39 +0200>
FROM:  Eli Zaretskii <eliz@gnu.org>
> 
> On November 5, 2017 11:15:41 AM GMT+02:00, Keith David Bershatsky <esq@lawlist.com> wrote:
> > The new fix relating to #29002 has an unintended side-effect of
> > causing a full redisplay too often, e.g., when using isearch.
> > 
> > I am uncertain why the current Emacs design sets
> > w->suspend_auto_hscroll to *true* every command loop, but that is what
> > causes the new condition to force a thorough redisplay much more often
> > than is actually needed.
> > 
> > 
> > * * *
> 
> Please describe a recipe where you see suspend_auto_hscroll being
> set true every command loop.

bug#29002: it.first_visible_x is erroneously 0 while horizontal scrolling.

[Eli Zaretskii]

> Date:  Sun, 05 Nov 2017 08:59:47 -0800
> From:  Keith David Bershatsky <esq@lawlist.com>
> Cc:  29002@debbugs.gnu.org
> 
> Step # 1:  Download a fresh copy of the emacs-26 branch.
> 
> Step # 2:  Inside the function `set_window_hscroll` within window.c, add a message just before the function returns.
> 
> AUTO_STRING (my_string_one, "window.c:  set_window_hscroll");
> CALLN (Fmessage, my_string_one);
> 
> Step # 3:  Build the new Emacs, and launch without any user configuration.
> 
> Step # 4:  From the Welcome screen, type:  C-r
> 
> Step # 5:  Slowly type the word Emacs and watch the echo area as you type each letter.
> 
> Inasmuch as the function `set_window_hscroll` is being called each time we type a letter, the proposed fix to #29002 causes a thorough redisplay after every keystroke while using isearch.  This is probably not limited to isearch -- it was just the first occasion where the side affect was immediately noticeable.

OK, I made thorough redisplay happen in fewer situations.

bug#29002: it.first_visible_x is erroneously 0 while horizontal scrolling.

[Keith David Bershatsky]

Thank you for the revision.  I have tested the latest patch and everything is working well.

Keith

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

DATE:  [11-05-2017 10:12:26] <05 Nov 2017 20:12:26 +0200>
FROM:  Eli Zaretskii <eliz@gnu.org>
> 
> * * *
> 
> OK, I made thorough redisplay happen in fewer situations.