* bug#22637: 25.1.50; `mode-line` face `:height` incompatible with `scroll-conservatively 101`.
2016-02-12 2:12 bug#22637: 25.1.50; `mode-line` face `:height` incompatible with `scroll-conservatively 101` Keith David Bershatsky
@ 2016-02-12 8:17 ` Eli Zaretskii
2016-02-12 16:17 ` Keith David Bershatsky
` (4 subsequent siblings)
5 siblings, 0 replies; 13+ messages in thread
From: Eli Zaretskii @ 2016-02-12 8:17 UTC (permalink / raw)
To: Keith David Bershatsky; +Cc: 22637
> 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.
^ permalink raw reply [flat|nested] 13+ messages in thread* bug#22637: 25.1.50; `mode-line` face `:height` incompatible with `scroll-conservatively 101`.
2016-02-12 2:12 bug#22637: 25.1.50; `mode-line` face `:height` incompatible with `scroll-conservatively 101` Keith David Bershatsky
2016-02-12 8:17 ` Eli Zaretskii
@ 2016-02-12 16:17 ` Keith David Bershatsky
2016-02-12 19:40 ` Eli Zaretskii
2016-02-14 3:40 ` Keith David Bershatsky
` (3 subsequent siblings)
5 siblings, 1 reply; 13+ messages in thread
From: Keith David Bershatsky @ 2016-02-12 16:17 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22637
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)
^ permalink raw reply [flat|nested] 13+ messages in thread* bug#22637: 25.1.50; `mode-line` face `:height` incompatible with `scroll-conservatively 101`.
2016-02-12 16:17 ` Keith David Bershatsky
@ 2016-02-12 19:40 ` Eli Zaretskii
0 siblings, 0 replies; 13+ messages in thread
From: Eli Zaretskii @ 2016-02-12 19:40 UTC (permalink / raw)
To: Keith David Bershatsky; +Cc: 22637
> 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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#22637: 25.1.50; `mode-line` face `:height` incompatible with `scroll-conservatively 101`.
2016-02-12 2:12 bug#22637: 25.1.50; `mode-line` face `:height` incompatible with `scroll-conservatively 101` Keith David Bershatsky
2016-02-12 8:17 ` Eli Zaretskii
2016-02-12 16:17 ` Keith David Bershatsky
@ 2016-02-14 3:40 ` Keith David Bershatsky
2016-02-14 6:05 ` Eli Zaretskii
2016-02-14 7:55 ` Keith David Bershatsky
` (2 subsequent siblings)
5 siblings, 1 reply; 13+ messages in thread
From: Keith David Bershatsky @ 2016-02-14 3:40 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22637
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;
}
}
}
^ permalink raw reply [flat|nested] 13+ messages in thread* bug#22637: 25.1.50; `mode-line` face `:height` incompatible with `scroll-conservatively 101`.
2016-02-14 3:40 ` Keith David Bershatsky
@ 2016-02-14 6:05 ` Eli Zaretskii
0 siblings, 0 replies; 13+ messages in thread
From: Eli Zaretskii @ 2016-02-14 6:05 UTC (permalink / raw)
To: Keith David Bershatsky; +Cc: 22637
> 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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#22637: 25.1.50; `mode-line` face `:height` incompatible with `scroll-conservatively 101`.
2016-02-12 2:12 bug#22637: 25.1.50; `mode-line` face `:height` incompatible with `scroll-conservatively 101` Keith David Bershatsky
` (2 preceding siblings ...)
2016-02-14 3:40 ` Keith David Bershatsky
@ 2016-02-14 7:55 ` Keith David Bershatsky
2016-02-14 19:26 ` Eli Zaretskii
2016-02-16 2:00 ` Keith David Bershatsky
2016-02-16 2:51 ` Keith David Bershatsky
5 siblings, 1 reply; 13+ messages in thread
From: Keith David Bershatsky @ 2016-02-14 7:55 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22637
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)
^ permalink raw reply [flat|nested] 13+ messages in thread* bug#22637: 25.1.50; `mode-line` face `:height` incompatible with `scroll-conservatively 101`.
2016-02-14 7:55 ` Keith David Bershatsky
@ 2016-02-14 19:26 ` Eli Zaretskii
0 siblings, 0 replies; 13+ messages in thread
From: Eli Zaretskii @ 2016-02-14 19:26 UTC (permalink / raw)
To: Keith David Bershatsky; +Cc: 22637
> 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)
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#22637: 25.1.50; `mode-line` face `:height` incompatible with `scroll-conservatively 101`.
2016-02-12 2:12 bug#22637: 25.1.50; `mode-line` face `:height` incompatible with `scroll-conservatively 101` Keith David Bershatsky
` (3 preceding siblings ...)
2016-02-14 7:55 ` Keith David Bershatsky
@ 2016-02-16 2:00 ` Keith David Bershatsky
2016-02-16 2:51 ` Keith David Bershatsky
5 siblings, 0 replies; 13+ messages in thread
From: Keith David Bershatsky @ 2016-02-16 2:00 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22637
[-- 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 --]
^ permalink raw reply [flat|nested] 13+ messages in thread* bug#22637: 25.1.50; `mode-line` face `:height` incompatible with `scroll-conservatively 101`.
2016-02-12 2:12 bug#22637: 25.1.50; `mode-line` face `:height` incompatible with `scroll-conservatively 101` Keith David Bershatsky
` (4 preceding siblings ...)
2016-02-16 2:00 ` Keith David Bershatsky
@ 2016-02-16 2:51 ` Keith David Bershatsky
2016-02-16 15:51 ` Eli Zaretskii
5 siblings, 1 reply; 13+ messages in thread
From: Keith David Bershatsky @ 2016-02-16 2:51 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22637
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)
^ permalink raw reply [flat|nested] 13+ messages in thread* bug#22637: 25.1.50; `mode-line` face `:height` incompatible with `scroll-conservatively 101`.
2016-02-16 2:51 ` Keith David Bershatsky
@ 2016-02-16 15:51 ` Eli Zaretskii
2022-02-10 8:09 ` Lars Ingebrigtsen
0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2016-02-16 15:51 UTC (permalink / raw)
To: Keith David Bershatsky; +Cc: 22637
> 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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#22637: 25.1.50; `mode-line` face `:height` incompatible with `scroll-conservatively 101`.
2016-02-16 15:51 ` Eli Zaretskii
@ 2022-02-10 8:09 ` Lars Ingebrigtsen
2022-02-10 12:33 ` Eli Zaretskii
0 siblings, 1 reply; 13+ messages in thread
From: Lars Ingebrigtsen @ 2022-02-10 8:09 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Keith David Bershatsky, 22637
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#22637: 25.1.50; `mode-line` face `:height` incompatible with `scroll-conservatively 101`.
2022-02-10 8:09 ` Lars Ingebrigtsen
@ 2022-02-10 12:33 ` Eli Zaretskii
0 siblings, 0 replies; 13+ messages in thread
From: Eli Zaretskii @ 2022-02-10 12:33 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 22637-done, esq
> 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.
^ permalink raw reply [flat|nested] 13+ messages in thread