bug#22637: 25.1.50; `mode-line` face `:height` incompatible with `scroll-conservatively 101`.

bug#22637: 25.1.50; `mode-line` face `:height` incompatible with `scroll-conservatively 101`.

[Keith David Bershatsky]

Setting the `:height` property of the `mode-line` face to 140, and `scroll-conservatively 101`, prevent redisplay from making point fully visible following a large yank of text.  [This also happens with some of my custom movement functions similar to paragraph down.]

Anything attached to the `timer-idle-list` will cause the cursor to come back into view when the clocks strikes midnight.  The following three minor modes are disabled in this example so that the `timer-idle-list` is empty.  NOTE:  Even something attached to the idle timer such as `(run-with-idle-timer 10 'repeat 'ignore)` will trigger a redisplay after 10 seconds and cause point to come back into view.

    (face-spec-set 'mode-line
      '((((class color) (min-colors 88))
         :box (:line-width -1 :style released-button)
         :background "grey75" :foreground "black" :height 140)
        (t
         :inverse-video t)))

    (setq scroll-conservatively 101)

    (global-eldoc-mode -1)

    (global-font-lock-mode -1)

    (blink-cursor-mode -1)

As a suggestion / feature, please consider adding a GLYPH_DEBUG message to indicate when a function from the `timer-idle-list` has triggered a redisplay.  It sure would have been a lot easier to come up with a minimal working example of the above-mentioned issue if I could have seen what was happening with `trace-redisplay`.

#ifdef GLYPH_DEBUG
      debug_method_add (w, "redisplay triggered by function attached to `timer-idle-list'");
#endif

Thanks,

Keith

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

In GNU Emacs 25.1.50.1 (x86_64-apple-darwin10.8.0, NS appkit-1038.36 Version 10.6.8 (Build 10K549))
 of 2016-02-08 built on server.private
Repository revision: de76a167dc09dc695a5acebabb7ab354a6bf556e
Windowing system distributor 'Apple', version 10.3.1038
Configured using:
 'configure --with-ns --without-imagemagick --enable-checking=glyphs
 CPPFLAGS=-I/Users/HOME/.0.data/.0.emacs/macports/include
 LDFLAGS=-L/Users/HOME/.0.data/.0.emacs/macports/lib'

Configured features:
JPEG RSVG DBUS NOTIFY ACL LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS

Important settings:
  locale-coding-system: utf-8-unix

Major mode: FM

Minor modes in effect:
  tabbar-mode: t
  ml-mode: t
  ds-mode: t
  sd-mode: t

Recent messages:
*beep*

Load-path shadows:
None found.

Features:
(shadow emacsbug message mml mml-sec epg mm-decode mm-bodies mm-encode
gmm-utils mailheader sendmail lawlist-ztree lawlist-ys lawlist-ws
lawlist-wl elmo-imap4 elmo-localdir modb-standard modb-legacy
elmo-internal elmo-flag mmelmo-imap mmelmo-buffer elsp-generic mel-u
epg-config lawlist-w3m doc-view jka-compr image-mode ccl lawlist-vl
lawlist-view lawlist-undo lawlist-txt lawlist-tm lawlist-tex compare-w
diff-mode lawlist-tabbar lawlist-speedbar lawlist-shell info
esh-groups ehelp ange-ftp lawlist-sgml lawlist-sb lawlist-ruler
lawlist-replace lawlist-rectangle lawlist-re-builder lawlist-python
skeleton lawlist-profiler lawlist-print lawlist-perl lawlist-parens
lawlist-org lawlist-calendar org-agenda org org-macro org-footnote
org-pcomplete org-list org-faces org-entities org-version
ob-emacs-lisp ob ob-tangle ob-ref ob-lob ob-table ob-exp org-src
ob-keys ob-comint ob-core ob-eval org-compat org-macs org-loaddefs
find-func holidays hol-loaddefs cal-menu calendar cal-loaddefs
lawlist-neotree lawlist-movement lawlist-mouse lawlist-ml lawlist-misc
lawlist-messages lawlist-mc lawlist-markdown noutline outline
lawlist-lorem lawlist-linum lawlist-keymap lawlist-js json map
thingatpt cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles
cc-align cc-engine cc-vars cc-defs lawlist-ispell lawlist-isearch
lawlist-info lawlist-imenu lawlist-ibuffer lawlist-hl lawlist-grep
lawlist-git pcvs-util ido seq server conf-mode lawlist-framebufs
lawlist-frame lawlist-fm lawlist-env lawlist-elscreen lawlist-elisp
lawlist-dv lawlist-image lawlist-files zeroconf dbus xml lawlist-ds
lawlist-dired dired dired-loaddefs format-spec lawlist-diff
lawlist-desktop frameset lawlist-saveplace lawlist-debug
lawlist-window debug lawlist-css smie lawlist-compile rx lawlist-color
lawlist-cm lawlist-cc-mode lawlist-cc-awk lawlist-font-lock cl-macs
lawlist-cc-fonts lawlist-cc-guess lawlist-cc-menus lawlist-cc-align
lawlist-cc-cmds lawlist-cc-styles lawlist-cc-engine lawlist-cc-langs
lawlist-cc-vars lawlist-cc-defs lawlist-cc-bytecomp lawlist-calc
lawlist-calc+ lawlist-bk lawlist-bc lawlist-bbdb gnus gnus-ems
nnheader mail-utils wid-edit mail-parse rfc2231 rfc2047 rfc2045
ietf-drums mailabbrev mail-extr rfc822 timezone lawlist-minibuffer gv
lawlist-auth gnus-util mm-util help-fns mail-prsvr password-cache
lawlist-as lawlist-archive lawlist-apropos lawlist-+ lawlist-lcl
byte-opt bytecomp byte-compile cl-extra cconv lawlist-help disp-table
easy-mmode edmacro kmacro quail help-mode easymenu cl-loaddefs cl-lib
pcase derived advice shell pcomplete comint ansi-color ring savehist
time-date mule-util tooltip eldoc electric uniquify ediff-hook
vc-hooks lisp-float-type mwheel ns-win ucs-normalize term/common-win
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 obarray 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 kqueue cocoa ns multi-tty make-network-process emacs)

Memory information:
((conses 16 2441605 221891)
 (symbols 48 86439 1)
 (miscs 40 148 312)
 (strings 32 189178 34146)
 (string-bytes 1 7207331)
 (vectors 16 56373)
 (vector-slots 8 1154092 15038)
 (floats 8 1840 391)
 (intervals 56 342 49)
 (buffers 976 13))

bug#22637: 25.1.50; `mode-line` face `:height` incompatible with `scroll-conservatively 101`.

[Eli Zaretskii]

> Date: Thu, 11 Feb 2016 18:12:57 -0800
> From: Keith David Bershatsky <esq@lawlist.com>
> 
> Setting the `:height` property of the `mode-line` face to 140, and `scroll-conservatively 101`, prevent redisplay from making point fully visible following a large yank of text.

I cannot reproduce this.  I tried some large yanks, including all of
xdisp.c, and the cursor stayed fully visible.

IME, it is sometimes required to make small changes to the default
font, like enlarge it by 1 or 2 pixels, to reproduce problems seen on
other platforms.  I will do that if needed, but please provide a full
recipe, including the text you yanked, and the precise keystrokes used
to yank it: I'd like to be sure I do all the same gestures you did,
before I start playing with font sizes.

> As a suggestion / feature, please consider adding a GLYPH_DEBUG message to indicate when a function from the `timer-idle-list` has triggered a redisplay.

We already have that, albeit in a subtle way: when that happens, you
should see this on stderr:

  redisplay_preserve_echo_area (8)

That "8" part says redisplay_preserve_echo_area was invoked by the
function that ran timers just before that.  You should be able to see
the code which produces that in detect_input_pending_run_timers,
around line 9836 in keyboard.c.

Thanks.

bug#22637: 25.1.50; `mode-line` face `:height` incompatible with `scroll-conservatively 101`.

[Keith David Bershatsky]

Thank you, Eli, for the explanation regarding how to better interpret the GLYPH_DEBUG messages that I was seeing on stderr.

I was able to reproduce problem 22637 on Emacs for Windows (XP) master branch with the following code starting from Emacs -Q, evaluating the following code in the scratch buffer, and then pressing the F1 key a couple of times.  The last line will remain below the bottom of the visible window each time the F1 key is pressed.  On Windows, a height of 120 seems to work better for purposes of reproducing the problem, whereas on OSX I was using a height of 140.

(face-spec-set 'mode-line
  '((((class color) (min-colors 88))
     :box (:line-width -1 :style released-button)
     :background "grey75" :foreground "black" :height 120)
    (t
     :inverse-video t)))

(setq scroll-conservatively 101)

(global-eldoc-mode -1)

(global-font-lock-mode -1)

(blink-cursor-mode -1)

(defun my-insert-text ()
(interactive)
  (dotimes (i 200)
    (insert "I will not obey absurd orders.\n")))

(global-set-key [f1] 'my-insert-text)

bug#22637: 25.1.50; `mode-line` face `:height` incompatible with `scroll-conservatively 101`.

[Eli Zaretskii]

> Date:  Fri, 12 Feb 2016 08:17:53 -0800
> From:  Keith David Bershatsky <esq@lawlist.com>
> Cc:  22637@debbugs.gnu.org
> 
> Thank you, Eli, for the explanation regarding how to better interpret the GLYPH_DEBUG messages that I was seeing on stderr.
> 
> I was able to reproduce problem 22637 on Emacs for Windows (XP) master branch with the following code starting from Emacs -Q, evaluating the following code in the scratch buffer, and then pressing the F1 key a couple of times.  The last line will remain below the bottom of the visible window each time the F1 key is pressed.  On Windows, a height of 120 seems to work better for purposes of reproducing the problem, whereas on OSX I was using a height of 140.
> 
> (face-spec-set 'mode-line
>   '((((class color) (min-colors 88))
>      :box (:line-width -1 :style released-button)
>      :background "grey75" :foreground "black" :height 120)
>     (t
>      :inverse-video t)))
> 
> (setq scroll-conservatively 101)
> 
> (global-eldoc-mode -1)
> 
> (global-font-lock-mode -1)
> 
> (blink-cursor-mode -1)
> 
> (defun my-insert-text ()
> (interactive)
>   (dotimes (i 200)
>     (insert "I will not obey absurd orders.\n")))
> 
> (global-set-key [f1] 'my-insert-text)

Thanks.  This is now fixed on the emacs-25 branch.

bug#22637: 25.1.50; `mode-line` face `:height` incompatible with `scroll-conservatively 101`.

[Keith David Bershatsky]

In addition to the fix that you implemented yesterday near the section of "optimization 3", another similar fix would be needed near the following "recenter" section that affects cursor visibility when using isearch where sometimes point is below the bottom of the screen and remains there subsequent to redisplay.  I have not yet been able to figure out how to use `cursor_row_fully_visible_p`, so I used something a little easier for me to understand that basically tests the same thing (I think).

If I can come up with a small test that demonstrates the problem when searching, I'll send over an example.  The following code, however, does seem to fix the problem in all of my tests.


      /* Users who set scroll-conservatively to a large number want
	 point just above/below the scroll margin.  If we ended up
	 with point's row partially visible, move the window start to
	 make that row fully visible and out of the margin.  */
      if (scroll_conservatively > SCROLL_LIMIT)
	{
	  int window_total_lines
	    = WINDOW_TOTAL_LINES (w) * FRAME_LINE_HEIGHT (f) * frame_line_height;
	  int margin =
	    scroll_margin > 0
	    ? min (scroll_margin, window_total_lines / 4)
	    : 0;
	  bool move_down = w->cursor.vpos >= window_total_lines / 2;

	  move_it_by_lines (&it, move_down ? margin + 1 : -(margin + 1));
	  clear_glyph_matrix (w->desired_matrix);

  /* Added a check/fix for a problem similar/same as bug #22637.  */
  if (1 == try_window (window, it.current.pos, TRY_WINDOW_CHECK_MARGINS))
    {
      bool fully_p = false;
      EMACS_INT posint = PT;
      struct buffer *buf;
      int x, y, rtop, rbot, rowh, vpos;
      buf = XBUFFER (w->contents);
      if ((posint >= CHARPOS (startp) && posint <= BUF_ZV (buf))
          && CHARPOS (startp) >= BUF_BEGV (buf)
          && CHARPOS (startp) <= BUF_ZV (buf)
          && pos_visible_p (w, posint, &x, &y, &rtop, &rbot, &rowh, &vpos))
        fully_p = !rtop && !rbot;
      if (!fully_p)
        {
#ifdef GLYPH_DEBUG
          debug_method_add (w, "!fully_p -- goto try_to_scroll");
#endif
          goto try_to_scroll;
        }
        else
          {
#ifdef GLYPH_DEBUG
            debug_method_add (w, "fully_p -- goto done");
#endif
            goto done;
          }
    }

	}

bug#22637: 25.1.50; `mode-line` face `:height` incompatible with `scroll-conservatively 101`.

[Eli Zaretskii]

> Date:  Sat, 13 Feb 2016 19:40:34 -0800
> From:  Keith David Bershatsky <esq@lawlist.com>
> Cc:  22637@debbugs.gnu.org
> 
> In addition to the fix that you implemented yesterday near the section of "optimization 3", another similar fix would be needed near the following "recenter" section that affects cursor visibility when using isearch where sometimes point is below the bottom of the screen and remains there subsequent to redisplay.  I have not yet been able to figure out how to use `cursor_row_fully_visible_p`, so I used something a little easier for me to understand that basically tests the same thing (I think).
> 
> If I can come up with a small test that demonstrates the problem when searching, I'll send over an example.  The following code, however, does seem to fix the problem in all of my tests.

Please do come up with a test case.  I don't want to make any change
that doesn't have a test which fails before and succeeds after the
change.  Having such test cases allows us to make sure later changes
don't reintroduce the same bug.

>   /* Added a check/fix for a problem similar/same as bug #22637.  */
>   if (1 == try_window (window, it.current.pos, TRY_WINDOW_CHECK_MARGINS))
>     {
>       bool fully_p = false;
>       EMACS_INT posint = PT;
>       struct buffer *buf;
>       int x, y, rtop, rbot, rowh, vpos;
>       buf = XBUFFER (w->contents);
>       if ((posint >= CHARPOS (startp) && posint <= BUF_ZV (buf))
>           && CHARPOS (startp) >= BUF_BEGV (buf)
>           && CHARPOS (startp) <= BUF_ZV (buf)
>           && pos_visible_p (w, posint, &x, &y, &rtop, &rbot, &rowh, &vpos))
>         fully_p = !rtop && !rbot;
>       if (!fully_p)
>         {
> #ifdef GLYPH_DEBUG
>           debug_method_add (w, "!fully_p -- goto try_to_scroll");
> #endif
>           goto try_to_scroll;
>         }
>         else
>           {
> #ifdef GLYPH_DEBUG
>             debug_method_add (w, "fully_p -- goto done");
> #endif
>             goto done;
>           }

I don't think this is correct.  try_window is called in many more
places in the display engine, so if this problem is due to what it
does, the fix should be inside try_window, not in its callers.

But I could be wrong -- I need to see the problem to be sure.

Thanks.

bug#22637: 25.1.50; `mode-line` face `:height` incompatible with `scroll-conservatively 101`.

[Keith David Bershatsky]

The following example of problem 22637 is for emacs-25 branch built this evening (February 13, 2016) on Windows (XP).  I believe this relates to the "recenter" portion of `xdisp.c`.  The cursor looks like it is resting at the top of the window, when point is actually beneath the bottom of the window.

(face-spec-set 'mode-line
 '((((class color) (min-colors 88))
    :box (:line-width -1 :style released-button)
    :background "grey75" :foreground "black" :height 120)
   (t
    :inverse-video t)))

(setq scroll-conservatively 101)

(global-eldoc-mode -1)

(global-font-lock-mode -1)

(blink-cursor-mode -1)

;;  Prevent the `timer-list' from receiving `undo-auto--boundary-timer'.
(defun undo-auto--undoable-change ()
  "Called after every undoable buffer change."
  ;; (add-to-list 'undo-auto--undoably-changed-buffers (current-buffer))
  ;; (undo-auto--boundary-ensure-timer)
  )
(setq timer-list (delq 'undo-auto--boundary-timer timer-list))

(defun test ()
(interactive)
 (switch-to-buffer (get-buffer-create "*foo*"))
 (dotimes (i 200)
   (insert "I will not obey absurd orders.\n"))
   (goto-char (point-min))
   (goto-char (- (point-max) 1000)))

(global-set-key [f1] 'test)

bug#22637: 25.1.50; `mode-line` face `:height` incompatible with `scroll-conservatively 101`.

[Eli Zaretskii]

> Date:  Sat, 13 Feb 2016 23:55:50 -0800
> From:  Keith David Bershatsky <esq@lawlist.com>
> Cc:  22637@debbugs.gnu.org
> 
> The following example of problem 22637 is for emacs-25 branch built this evening (February 13, 2016) on Windows (XP).  I believe this relates to the "recenter" portion of `xdisp.c`.  The cursor looks like it is resting at the top of the window, when point is actually beneath the bottom of the window.

Recentering had nothing to do with this.  It was due to a stupid typo
made 2.5 years ago.  Now fixed on the emacs-25 branch.

For the record, here's a variant of your test case that avoids
triggering the undo timer (provided you don't move the mouse after
pressing F1) and also makes the lines of text different to make it
evident when cursor jumps or the window is scrolled:

(face-spec-set 'mode-line
 '((((class color) (min-colors 88))
    :box (:line-width -1 :style released-button)
    :background "grey75" :foreground "black" :height 120)
   (t
    :inverse-video t)))

(setq scroll-conservatively 101)
(global-eldoc-mode -1)
(global-font-lock-mode -1)
(blink-cursor-mode -1)

(defun test ()
  (interactive)
  (switch-to-buffer (get-buffer-create "*foo*"))
  (buffer-disable-undo)
  (setq undo-auto-current-boundary-timer t
	timer-list (delq 'undo-auto--boundary-timer timer-list))
  (dotimes (i 200)
    (insert (format "I will not obey absurd orders %d.\n" i)))
  (goto-char (point-min))
  (goto-char (- (point-max) 1000)))

(global-set-key [f1] 'test)

bug#22637: 25.1.50; `mode-line` face `:height` incompatible with `scroll-conservatively 101`.

[Keith David Bershatsky]

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

Thank you, Eli, for the most recent fix implemented in relation to #22637.  Both of the fixes that you have already implemented do indeed resolve the two test cases.

You might be interested to know that the `window-scroll-functions` hook never runs after `window-start` is corrected in the following example, so anyone seeking to use that hook with a correct `window-start` is out of luck.  In addition to the test example below, this type of fact pattern occurs when using things such as isearch and ispell (e.g., when programmatically moving to a point that is not yet visible).  Attached is an updated `window_start_end_hook.diff` that depicts an example of how I have tentatively dealt with it for the new hook (but I did not attempt to fix the WSF).


(face-spec-set 'mode-line
'((((class color) (min-colors 88))
   :box (:line-width -1 :style released-button)
   :background "grey75" :foreground "black" :height 120)
  (t
   :inverse-video t)))

(setq scroll-conservatively 101)
(global-eldoc-mode -1)
(global-font-lock-mode -1)
(blink-cursor-mode -1)

(defun wsf-test-fn (win start)
  (let* (
      (end (window-end nil t))
      (pos-visible (pos-visible-in-window-p nil win nil)) )
    (message "window-start: %s | window-end: %s | pos-visible: %s"
      start end pos-visible)))

(defun test ()
 (interactive)
 (switch-to-buffer (get-buffer-create "*foo*"))
 (add-hook 'window-scroll-functions 'wsf-test-fn nil 'local)
 (buffer-disable-undo)
 (setq undo-auto-current-boundary-timer t
	timer-list (delq 'undo-auto--boundary-timer timer-list))
 (dotimes (i 200)
   (insert (format "I will not obey absurd orders %d.\n" i)))
 (goto-char (point-min))
 (goto-char (- (point-max) 1000)))

(global-set-key [f1] 'test)



[-- Attachment #2: window_start_end_hook.diff --]
[-- Type: application/diff, Size: 13413 bytes --]

bug#22637: 25.1.50; `mode-line` face `:height` incompatible with `scroll-conservatively 101`.

[Keith David Bershatsky]

The same situation mentioned in my email earlier today (02/15/2016) is also present in the first test case that we looked at for #22637.   I.e., after an insertion in the first test case, the `window-scroll-functions` hook never fires after `window-start` is corrected.  So a user seeking to use the `window-scroll-functions` hook following a large insertion (e.g., a large yank, and so forth) is out of luck in that situation in terms of using a correct `window-start`.  I have already dealt with it for the `window-start-end-hook` by forcing a call every command loop thereby bypassing "optimization 3"; however, the WSF has no fix at this time.

The difference between the first and second test case is as follows:  The first test case deals with a straight insertion.  The second test case uses insertion merely to populate the buffer with some text so that we can then see what happens when using `goto-char`.  I commented out the two lines of `goto-char` in the `test` function below to replicate the first test case scenario.  The prior email is the second test case scenario.


(face-spec-set 'mode-line
'((((class color) (min-colors 88))
   :box (:line-width -1 :style released-button)
   :background "grey75" :foreground "black" :height 120)
  (t
   :inverse-video t)))

(setq scroll-conservatively 101)
(global-eldoc-mode -1)
(global-font-lock-mode -1)
(blink-cursor-mode -1)

(defun test ()
 (interactive)
 (switch-to-buffer (get-buffer-create "*foo*"))
 (add-hook 'window-scroll-functions 'wsf-test-fn nil 'local)
 (buffer-disable-undo)
 (setq undo-auto-current-boundary-timer t
	timer-list (delq 'undo-auto--boundary-timer timer-list))
 (dotimes (i 200)
   (insert (format "I will not obey absurd orders %d.\n" i)))
 ;; (goto-char (point-min))
 ;; (goto-char (- (point-max) 1000))
  )

(defun wsf-test-fn (win start)
  (let* (
      (end (window-end nil t))
      (pos-visible (pos-visible-in-window-p nil win nil)) )
    (message "window-start: %s | window-end: %s | pos-visible: %s"
      start end pos-visible)))

(global-set-key [f1] 'test)

bug#22637: 25.1.50; `mode-line` face `:height` incompatible with `scroll-conservatively 101`.

[Eli Zaretskii]

> Date:  Mon, 15 Feb 2016 18:51:26 -0800
> From:  Keith David Bershatsky <esq@lawlist.com>
> Cc:  22637@debbugs.gnu.org
> 
> The same situation mentioned in my email earlier today (02/15/2016) is also present in the first test case that we looked at for #22637.   I.e., after an insertion in the first test case, the `window-scroll-functions` hook never fires after `window-start` is corrected.  So a user seeking to use the `window-scroll-functions` hook following a large insertion (e.g., a large yank, and so forth) is out of luck in that situation in terms of using a correct `window-start`.  I have already dealt with it for the `window-start-end-hook` by forcing a call every command loop thereby bypassing "optimization 3"; however, the WSF has no fix at this time.

The reason window-scroll-functions aren't run in both of these test
cases is that what happens there is not considered "scrolling".
Scrolling is informally defined as either an explicit call to a
function that scrolls the window, or a pseudo-scroll done by the
display engine when it detects that some part of the window's previous
display is still present, but in a different vertical position.
Moving point to an arbitrary location is neither.

bug#22637: 25.1.50; `mode-line` face `:height` incompatible with `scroll-conservatively 101`.

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> The reason window-scroll-functions aren't run in both of these test
> cases is that what happens there is not considered "scrolling".

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

Skimming this thread, Keith reported that the original problem was fixed
by Eli's patches, but then there was an additional question by Keith
answered by Eli, and the bug was then left open.

Is there anything more to do here, or should this report be closed?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#22637: 25.1.50; `mode-line` face `:height` incompatible with `scroll-conservatively 101`.

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Keith David Bershatsky <esq@lawlist.com>,  22637@debbugs.gnu.org
> Date: Thu, 10 Feb 2022 09:09:34 +0100
> 
> Skimming this thread, Keith reported that the original problem was fixed
> by Eli's patches, but then there was an additional question by Keith
> answered by Eli, and the bug was then left open.
> 
> Is there anything more to do here, or should this report be closed?

Nothing to do, so I'm closing this.

Thanks.