GNU bug report logs -
#56393
Actually fix the long lines display bug
Previous Next
Full log
Message #194 received at 56393 <at> debbugs.gnu.org (full text, mbox):
> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 56393 <at> debbugs.gnu.org
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> 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?
This bug report was last modified 3 years and 33 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.