From: Kenichi Handa <handa@m17n.org>
To: Stefan Monnier <monnier@IRO.UMontreal.CA>
Cc: lekktu@gmail.com, 5984@debbugs.gnu.org
Subject: bug#5984: Crash displaying composed characters
Date: Sat, 01 May 2010 15:28:46 +0900 [thread overview]
Message-ID: <tl7y6g4f84h.fsf@m17n.org> (raw)
In-Reply-To: <jwvr5lw4qnn.fsf-monnier+gnus-read-ephemeral-bug@gnu.org> (message from Stefan Monnier on Fri, 30 Apr 2010 16:47:43 -0400)
In article <jwvr5lw4qnn.fsf-monnier+gnus-read-ephemeral-bug@gnu.org>, Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
> > . Emacs then enters redisplay to display the echo area. As part of
> [...]
> > . Further down, autocmp_chars calls the value of
> > auto-composition-function:
> [...]
> > . Now the " *Echo Area0*" buffer holds a totally different text,
> > unbeknownst to autocmp_chars, which still passes the old values 32
> > and 33 to TEMP_SET_PT_BOTH:
> More generally, this Lisp code could modify any buffer, so preventing
> the load-messages is not a sufficiently reliable solution (tho it might
> be desirable in any case).
Yes, and this problem is not only in auto-composition. For
instance, evaluating this crashes Emacs.
(put-text-property 1 10 'display '(height (progn (delete-region 1 10))))
How about having a special mode in which any modifications
to buffers are silently ignored, and we run Lisp in that
mode in redisplay?
Another way is to check MODIFF before and after calling
Lisp, and if the current buffer is modified, restart the
redisplay... somehow.
---
Kenichi Handa
handa@m17n.org
prev parent reply other threads:[~2010-05-01 6:28 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-20 13:42 bug#5984: Crash displaying composed characters Juanma Barranquero
2010-04-20 15:06 ` Eli Zaretskii
2010-04-20 15:48 ` Juanma Barranquero
2010-04-20 16:07 ` Eli Zaretskii
2010-04-20 18:38 ` Glenn Morris
2010-04-20 17:29 ` Eli Zaretskii
2010-04-20 17:33 ` Juanma Barranquero
2010-04-20 17:52 ` Eli Zaretskii
2010-04-20 18:43 ` Lennart Borgman
2010-04-20 19:18 ` Eli Zaretskii
2010-04-20 20:38 ` Andreas Schwab
2010-04-21 10:48 ` Juanma Barranquero
2010-04-21 12:33 ` Andreas Schwab
2010-04-21 17:21 ` Juanma Barranquero
2010-04-23 9:17 ` Eli Zaretskii
2011-07-06 2:28 ` Juanma Barranquero
2011-08-07 19:45 ` Chong Yidong
2011-11-23 3:14 ` Juanma Barranquero
2011-11-23 6:47 ` Chong Yidong
2010-04-30 20:47 ` Stefan Monnier
2010-05-01 6:09 ` Eli Zaretskii
2010-05-01 6:28 ` Kenichi Handa [this message]
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=tl7y6g4f84h.fsf@m17n.org \
--to=handa@m17n.org \
--cc=5984@debbugs.gnu.org \
--cc=lekktu@gmail.com \
--cc=monnier@IRO.UMontreal.CA \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).