all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Keith David Bershatsky <esq@lawlist.com>
Cc: emacs-devel@gnu.org
Subject: Re: Test whether buffer/window is ready for start_display, etc.
Date: Fri, 29 Sep 2017 19:08:42 +0300	[thread overview]
Message-ID: <83shf57aid.fsf@gnu.org> (raw)
In-Reply-To: <m2h8vnpnqa.wl%esq@lawlist.com> (message from Keith David Bershatsky on Wed, 27 Sep 2017 19:21:17 -0700)

> Date: Wed, 27 Sep 2017 19:21:17 -0700
> From: Keith David Bershatsky <esq@lawlist.com>
> 
> 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.



  reply	other threads:[~2017-09-29 16:08 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-28  2:21 Test whether buffer/window is ready for start_display, etc Keith David Bershatsky
2017-09-29 16:08 ` Eli Zaretskii [this message]
  -- strict thread matches above, loose matches on Subject: below --
2017-10-05  2:35 Keith David Bershatsky
2017-10-05  8:03 ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83shf57aid.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=esq@lawlist.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.