From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Keith David Bershatsky Newsgroups: gmane.emacs.devel Subject: Re: Process: Determining the origin of a command loop. Date: Wed, 19 Dec 2018 20:11:57 -0800 Message-ID: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Trace: blaine.gmane.org 1545279042 20308 195.159.176.226 (20 Dec 2018 04:10:42 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 20 Dec 2018 04:10:42 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 20 05:10:38 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gZpfR-00056F-9T for ged-emacs-devel@m.gmane.org; Thu, 20 Dec 2018 05:10:38 +0100 Original-Received: from localhost ([::1]:35245 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gZphS-0006i5-Pq for ged-emacs-devel@m.gmane.org; Wed, 19 Dec 2018 23:12:42 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44539) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gZpgp-0006hm-FG for emacs-devel@gnu.org; Wed, 19 Dec 2018 23:12:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gZpgm-00055w-7n for emacs-devel@gnu.org; Wed, 19 Dec 2018 23:12:03 -0500 Original-Received: from gateway21.websitewelcome.com ([192.185.45.89]:16775) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gZpgl-00054w-RC for emacs-devel@gnu.org; Wed, 19 Dec 2018 23:12:00 -0500 Original-Received: from cm12.websitewelcome.com (cm12.websitewelcome.com [100.42.49.8]) by gateway21.websitewelcome.com (Postfix) with ESMTP id BEE6B400C645C for ; Wed, 19 Dec 2018 22:11:58 -0600 (CST) Original-Received: from gator3053.hostgator.com ([50.87.144.69]) by cmsmtp with SMTP id Zpgkgv7jWiQerZpgkg0Xln; Wed, 19 Dec 2018 22:11:58 -0600 X-Authority-Reason: nr=8 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lawlist.com ; s=default; h=Content-Type:MIME-Version:Subject:Cc:To:From:Message-ID:Date: Sender:Reply-To:Content-Transfer-Encoding:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=XqggQx65AFtt1tilo+SGHf5rq+Lc4OdhkoIz1S7M37A=; b=nIb3HdpCJbO4UiSMXpIO2vsBtE mF7FESoXTOR8ONJFeJJGp27ualQ1zXaON9o5NMiyLJVVP4zMQpbD0JPHgy+O0Dm9RoZhxhJege5YO Eyjb5A84molvhhPMdAPF00mJ0j2mRy5FzW+p6om1TWb6kYstAqwkVxhPGVxsj44Bj6EYvHRxF/i6A 3udyL5tQLcFSoNBJvDvt7+FDv0zKjhhdx8IaW0G5u0rx2cbwVp+uSbtBTbDdKCuNFUe9pMpfE1gwH tep61mPi0T8SXyFNwGZ6hWY2Vb76opx7wFu9h+QMch0josRqEtz/pDchyqsrhy5MammyIXjM7bm8v cvOINLBw==; Original-Received: from cpe-45-48-239-195.socal.res.rr.com ([45.48.239.195]:57302 helo=server.local) by gator3053.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.91) (envelope-from ) id 1gZpgj-0030Cn-Ul; Wed, 19 Dec 2018 22:11:58 -0600 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3053.hostgator.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - lawlist.com X-BWhitelist: no X-Source-IP: 45.48.239.195 X-Source-L: No X-Exim-ID: 1gZpgj-0030Cn-Ul X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: cpe-45-48-239-195.socal.res.rr.com (server.local) [45.48.239.195]:57302 X-Source-Auth: lawlist X-Email-Count: 1 X-Source-Cap: bGF3bGlzdDtsYXdsaXN0O2dhdG9yMzA1My5ob3N0Z2F0b3IuY29t X-Local-Domain: yes X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 192.185.45.89 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:231930 Archived-At: 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 > > * * * > > > > 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.