Re: Process: Determining the origin of a command loop.

[Keith David Bershatsky]

Thank you, Eli, for taking the time to review this particular thread.

Whereas an individual cursor (the real cursor) has very little overhead, an 
average of approximately 200 fake cursors are indeed semi-costly and merit 
optimization.  The current draft of 
crosshairs/visible-fill-column/multiple-fake-cursors relies upon 
display_and_set_cursor to determine when to generate the goodies.  I would like 
to optimize/suppress the goodies so that they are erased/redrawn only when 
absolutely necessary.  Let us assume that we make the following modifications 
to the Emacs master branch and evaluate the following Lisp code after launching 
the newly built Emacs from the terminal so that we can see the STDERR 
trace-redisplay output.  As to the current buffer in this situation, there is 
no need to erase and redraw the goodies (200 fake cursors) because the cursor 
is in the same location and the buffer is unmodified in all respects.  The only 
changes are occurring in the *compilation* buffer, which is not the current 
buffer.  The hallmarks of this situation are "redis
 play_preserve_echo_area (12)".

In a nutshell, I am looking for a way to programmatically detect this situation 
and suppress redrawing the cursor(s) in the unmodified windows.

(progn
  (trace-redisplay 1)
  (when global-eldoc-mode
    (global-eldoc-mode -1))
  (when jit-lock-context-timer
    (cancel-timer jit-lock-context-timer))
  (setq jit-lock-context-timer nil)
  (when (timerp undo-auto-current-boundary-timer)
    (cancel-timer undo-auto-current-boundary-timer))
  (fset 'undo-auto--undoable-change
        (lambda () (add-to-list 'undo-auto--undoably-changed-buffers 
(current-buffer))))
  (fset 'undo-auto-amalgamate 'ignore)
  (when blink-cursor-mode
    (blink-cursor-mode -1)
    (when (memq 'blink-cursor-check post-command-hook)
      (remove-hook 'post-command-hook 'blink-cursor-check)))
  (setq compilation-scroll-output t)
  (compile "while :; do echo \"Hello-World\"; sleep 1; done"))

diff --git a/src/xdisp.c b/src/xdisp.c
index 4201bdc..9ed03d3 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -29775,6 +29775,16 @@ display_and_set_cursor (struct window *w, bool on,
   FRAME_RIF (f)->draw_window_cursor (w, glyph_row, x, y,
                                      new_cursor_type, new_cursor_width,
                                      on, active_cursor);
+
+  if (trace_redisplay_p)
+    {
+      Lisp_Object window;
+      XSETWINDOW (window, w);
+      Lisp_Object window_string = Fprin1_to_string (window, Qnil);
+      char *window_char = SSDATA (window_string);
+      fprintf (stderr, "\ndisplay_and_set_cursor (%s):  on (%d) | active 
(%d)\n",
+                       window_char, on, active_cursor);
+    }
 }

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

> Date: [12-19-2018 07:24:50] <19 Dec 2018 17:24:50 +0200>
> From: Eli Zaretskii <address@hidden>
> 
> * * *
> >
> > I am unaware of any reason why the cursor in the active window needs 
> > updating in this situation.
> 
> The way the code is written, we might move the cursor as part of
> updating the window, and the code doesn't record the fact whether it
> did or didn't move the cursor, or turned it off.  So it always
> redisplays the cursor on the correct place at the end.
> 
> > Q:  How can I determine the origin of the command loop in this situation so 
> > that I can suppress the cursor from being updated in the active window?
> 
> I don't really understand the question ("origin of the command loop"?
> what's that?), and more generally, don't see why you would want to
> suppress the cursor update.