From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Test whether buffer/window is ready for start_display, etc. Date: Thu, 05 Oct 2017 11:03:39 +0300 Message-ID: <83efqixbqc.fsf@gnu.org> References: Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1507190669 16013 195.159.176.226 (5 Oct 2017 08:04:29 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 5 Oct 2017 08:04:29 +0000 (UTC) Cc: emacs-devel@gnu.org To: Keith David Bershatsky Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 05 10:04:25 2017 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 1e018o-0003PM-Tp for ged-emacs-devel@m.gmane.org; Thu, 05 Oct 2017 10:04:23 +0200 Original-Received: from localhost ([::1]:38228 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e018w-0004R6-7Z for ged-emacs-devel@m.gmane.org; Thu, 05 Oct 2017 04:04:30 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33438) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e018M-0004Qn-Dq for emacs-devel@gnu.org; Thu, 05 Oct 2017 04:03:55 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e018J-0006wk-Ao for emacs-devel@gnu.org; Thu, 05 Oct 2017 04:03:54 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:44625) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e018J-0006wf-7i; Thu, 05 Oct 2017 04:03:51 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2625 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1e018I-0007SP-Hy; Thu, 05 Oct 2017 04:03:51 -0400 In-reply-to: (message from Keith David Bershatsky on Wed, 04 Oct 2017 19:35:13 -0700) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:219113 Archived-At: > Date: Wed, 04 Oct 2017 19:35:13 -0700 > From: Keith David Bershatsky > Cc: emacs-devel@gnu.org > > Crosshairs and multiple fake cursors are drawn/erased when the following functions are called, each depending upon the flavor of Emacs (NS, X11, W32). This approach is based upon the existing method in which the real cursor is drawn. > > * ns_update_window_end (nsterm.m) > > * x_update_window_end (w32term.c) > > * x_update_window_end (xterm.c) This design is very problematic. The "normal" cursor is drawn in update_window functions because it only depends on the location of point, so it doesn't need to be redrawn if the window needs no update. But your fake cursors are different, AFAIU, and require redrawing even when the window didn't change. So your idea (AFAIU) of following the footsteps of normal cursor drawing is not a good idea. The only safe way of displaying such stuff is by making redisplay_window aware of the changes in the window, by, for example, moving some overlay to where the fake cursor is drawn. With your current design, as I understand it, you will have many problems down the line, because it simply doesn't fit into how the display engine works. So I think you should redesign your implementation, to have the fake cursors updated as part of the normal window update code in redisplay_window.