From: Eli Zaretskii <eliz@gnu.org>
To: Vitalie Spinu <spinuvit@gmail.com>
Cc: andreas.matthias@gmail.com, 19511@debbugs.gnu.org
Subject: bug#19511: 25.0.50; Failed assertions in redisplay() code. (dispnew.c:1405; xdisp.c:17524)
Date: Mon, 05 Jan 2015 20:24:27 +0200 [thread overview]
Message-ID: <83r3v984ro.fsf@gnu.org> (raw)
In-Reply-To: <87y4phupt5.fsf@gmail.com>
> From: Vitalie Spinu <spinuvit@gmail.com>
> Cc: Andreas Matthias <andreas.matthias@gmail.com>, 19511-done@debbugs.gnu.org
> Date: Mon, 05 Jan 2015 08:59:02 -0800
>
> > I hope Polymode will be changed to not call bury-buffer in that
> > situation (I always thought bury-buffer is strictly for interactive
> > use, FWIW).
>
> Bury-buffer is used to "hide" from the indirect buffer from the
> user. That was the easiest way to implement that and should have been
> rewritten anyways.
bury-buffer is a command. A command typically does a lot of dwim-ish
stuff that is not directly related to its main job. If you needed to
merely put the buffer at the end of buffer-list, you could have called
bury-buffer-internal instead, which does precisely that and nothing
else. Assuming you really need to manipulate buffer-list at all.
> Removing it doesn't change the fact that buffers are switched
> (with-current-buffer ...) inside font-lock-fontify-region-function. But
> I guess that's not an issue (right?).
Right, that's not the issue. The problem is the call to
switch-to-prev-buffer that bury-buffer does. That results in a call
to set-window-buffer, which is the one that invalidates window_end_pos
etc.
> Would it be enough to remove `bury-buffer` call to get back the
> optimization?
Probably, but if you show me the changes, I can see if they achieve
that.
> What are other elisp functions that can potentially invalidate
> window_end?
Any function that calls apply_window_adjustment, for example. Which
is called in just a handful of places, see window.c. Also
set-window-start and functions that split or delete windows.
Basically, those that really change the window's display (and
therefore shouldn't be called in a fontification function).
next prev parent reply other threads:[~2015-01-05 18:24 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-04 22:27 bug#19511: 25.0.50; Failed assertions in redisplay() code. (dispnew.c:1405; xdisp.c:17524) Andreas Matthias
2015-01-05 15:58 ` Eli Zaretskii
2015-01-05 16:59 ` Vitalie Spinu
2015-01-05 17:53 ` Stefan Monnier
2015-01-05 18:31 ` Eli Zaretskii
2015-01-05 18:24 ` Eli Zaretskii [this message]
2015-01-05 18:10 ` Andreas Matthias
2015-01-05 18:36 ` Eli Zaretskii
2015-01-05 18:41 ` Vitalie Spinu
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=83r3v984ro.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=19511@debbugs.gnu.org \
--cc=andreas.matthias@gmail.com \
--cc=spinuvit@gmail.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.