Subject: Re: bug#56393: Actually fix the long lines display bug

From: Eli Zaretskii <[email-masked]>
Date: Thu, 07 Jul 2022 16:36:38 +0300

> Cc: Lars Ingebrigtsen <[email-masked]>, [email-masked]
> From: Gerd Möllmann <[email-masked]>
> Date: Thu, 07 Jul 2022 13:29:10 +0200
> 
> +  DEFVAR_PER_BUFFER ("auto-narrow--narrowing-state",
> +		     &BVAR (current_buffer, auto_narrow__narrowing_state), Qnil,
> +		     doc: /* Internal variable used by `auto-narrow-mode'.  */);
> +
> 
> Don't know about the "--" in the name.  AFAICS, no other per-buffer
> variable has that. Likewise the "__" in the name.
> 
> Not that it is important.  I just noticed it.  And, maybe it's some
> convention that I don't know.

It's our current convention for "internal" variables and functions,
similar to the "internal-" prefix you know about.

> @@ -832,6 +835,11 @@ bset_width_table (struct buffer *b, Lisp_Object val)
>  {
>    b->width_table_ = val;
>  }
> +INLINE void
> +bset_auto_narrow__narrowing_state (struct buffer *b, Lisp_Object val)
> +{
> +  b->auto_narrow__narrowing_state_ = val;
> +}
> 
> If someone feels like it, could you tell me what the '[bw]set_.*'
> business is for?  A serializer?  Or for setting breakpoints?

It was originally supposed to make it easier to move to a more
sophisticated GC, where it is important to have one place where a
struct member is set, so that you could do whatever GC needs to do
with variables that got written to.  Unfortunately, the GC
modernization is still not here.

> modified   src/xdisp.c
> @@ -18872,11 +18872,20 @@ set_vertical_scroll_bar (struct window *w)
>  	  && NILP (echo_area_buffer[0])))
>      {
>        struct buffer *buf = XBUFFER (w->contents);
> -      whole = BUF_ZV (buf) - BUF_BEGV (buf);
> -      start = marker_position (w->start) - BUF_BEGV (buf);
> -      /* I don't think this is guaranteed to be right.  For the
> -	 moment, we'll pretend it is.  */
> -      end = BUF_Z (buf) - w->window_end_pos - BUF_BEGV (buf);
> +      if (! BUFFER_AUTO_NARROWED_P (buf))
> +	{
> +	  whole = BUF_ZV (buf) - BUF_BEGV (buf);
> +	  start = marker_position (w->start) - BUF_BEGV (buf);
> +	  /* I don't think this is guaranteed to be right.  For the
> +	     moment, we'll pretend it is.  */
> +	  end = BUF_Z (buf) - w->window_end_pos - BUF_BEGV (buf);
> 
> I can almost guarantee that it's not guaranteed that window_end_pos is
> always right.  But I don't have an alternative, ATM.  Could you please
> add a TODO or what's customary today in the comment, so it's easier to
> find?

Yes, this should test window_end_valid before using window_end_pos.
An alternative could be window-start point plus some estimation of the
window's text, perhaps?