From: Eli Zaretskii <eliz@gnu.org>
To: 5984@debbugs.gnu.org
Subject: bug#5984: Crash displaying composed characters
Date: Tue, 20 Apr 2010 22:18:40 +0300 [thread overview]
Message-ID: <83mxwy3pbj.fsf@gnu.org> (raw)
In-Reply-To: <83vdbm3udi.fsf@gnu.org>
> Date: Tue, 20 Apr 2010 20:29:29 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc:
>
> . The call to auto-composition-function loads uni-combining.el. And
> because force-load-messages is non-nil, that displays the 2
> messages
>
> Loading lisp/international/uni-combining.el (source)...
> Loading lisp/international/uni-combining.el (source)...done
>
> . 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:
>
> if (NILP (string))
> TEMP_SET_PT_BOTH (pt, pt_byte);
> return unbind_to (count, gstring);
>
> . temp_set_pt_both uses BUF_ZV and BUF_ZV_BYTE to validate its
> argument, but now BUF_ZV and BUF_ZV_BYTE correspond to the text
> "Loading ...", which has an entirely different length and
> contents, and the validation fails. Therefore, temp_set_pt_both
> aborts.
>
> One kludgy way of fixing this would be to bind force-load-messages to
> nil around the call to auto-composition-function. But that sounds too
> harsh: after all, whoever sets that variable, actually wants to see
> all these messages.
>
> Another way is to force the "Loading..." messages use the second echo
> area buffer. Do we have ways to do something like that?
>
> Ideas are welcome.
Here's one idea: use push_message and restore_message to save and
restore the current echo area message around the call to
auto-composition-function. WDYT?
next prev parent reply other threads:[~2010-04-20 19:18 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 [this message]
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
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=83mxwy3pbj.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=5984@debbugs.gnu.org \
/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).