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: Fri, 29 Sep 2017 19:08:42 +0300 Message-ID: <83shf57aid.fsf@gnu.org> References: Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1506701342 7276 195.159.176.226 (29 Sep 2017 16:09:02 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 29 Sep 2017 16:09:02 +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 Fri Sep 29 18:08:58 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 1dxxqS-0001Jm-Cs for ged-emacs-devel@m.gmane.org; Fri, 29 Sep 2017 18:08:56 +0200 Original-Received: from localhost ([::1]:36017 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dxxqZ-00041v-RK for ged-emacs-devel@m.gmane.org; Fri, 29 Sep 2017 12:09:03 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35516) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dxxqS-00041n-Ne for emacs-devel@gnu.org; Fri, 29 Sep 2017 12:08:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dxxqO-0001io-H7 for emacs-devel@gnu.org; Fri, 29 Sep 2017 12:08:56 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:47726) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dxxqO-0001ig-Ck; Fri, 29 Sep 2017 12:08:52 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1332 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dxxqN-0004pA-KC; Fri, 29 Sep 2017 12:08:52 -0400 In-reply-to: (message from Keith David Bershatsky on Wed, 27 Sep 2017 19:21:17 -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:218905 Archived-At: > Date: Wed, 27 Sep 2017 19:21:17 -0700 > From: Keith David Bershatsky > > In developing implementation of my own feature requests to draw crosshairs (#17684) using multiple fake cursors (#22873), I have come across situations when Emacs is starting up and restoring buffers (custom version of desktop.el) such that several internal functions cause Emacs to crash -- presumably because the combination of buffer and window are not ready yet. I am presently using the following five (5) tests to see whether window/buffer are ready for things like `start_display`, `move_it_to`, etc. Is there a better test to see whether the buffer/window combination is ready for me to get to work? The answer is "always". The crashes you see must be due to some other factors, and you haven't told enough to guess what those factors might be. Showing a couple of backtraces from those crashes might fill in those blanks. > if (w != XWINDOW (selected_window)) > return; This doesn't feel relevant. You can always redisplay a window that is not the selected window, provided that you take care to switch to its buffer (redisplay does that already). > if (!WINDOW_VALID_P (selected_window)) > return; How did you get into this situation? It shouldn't happen during redisplay, AFAIR. > ptrdiff_t charpos = marker_position (w->start); > ptrdiff_t bytepos = marker_byte_position (w->start); > > bool barf_crash_one = (charpos >= BEGV && charpos <= ZV) ? false : true; > if (barf_crash_one) > return; If window's start point is invalid, it means the window needs to be redisplayed. Again, I'm not sure I understand how do you get into this situation in the middle of redisplay. > bool barf_crash_two = (charpos == BYTE_TO_CHAR (bytepos)) ? false : true; > if (barf_crash_two) > return; Likewise. Markers are updated when a buffer is modified, so this should never happen. > bool barf_crash_three = (BUF_BEG_BYTE (b) <= bytepos && bytepos <= BUF_Z_BYTE (b)) ? false : true; > if (barf_crash_three) > return; Since you already verified the same condition about the character position, and you already verified that the character position and the byte position are consistent, this condition is redundant.