all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Stefan Monnier <monnier@IRO.UMontreal.CA>
Cc: fgunbin@fastmail.fm, 32108@debbugs.gnu.org
Subject: bug#32108: 27.0.50; Insertion of char from input method during macro invocation duplicates the char
Date: Wed, 11 Jul 2018 18:23:39 +0300	[thread overview]
Message-ID: <83k1q1g5j8.fsf@gnu.org> (raw)
In-Reply-To: <jwvefga7wz2.fsf-monnier+emacsbugs@gnu.org> (message from Stefan Monnier on Wed, 11 Jul 2018 08:58:25 -0400)

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: Glenn Morris <rgm@gnu.org>, fgunbin@fastmail.fm, 32108@debbugs.gnu.org
> Date: Wed, 11 Jul 2018 08:58:25 -0400
> 
> I haven't taken the time to look at the details of why read_char sees
> the character twice, but maybe we can use the (t . EVENT) format of
> events which says that EVENT shouldn't be recorded (tho I'm not sure
> it's the same form of "recording" and I'm not sure either that we can
> apply this trick to the right "copy" of the two).

I think I'm missing something: how does (t . EVENT) help us in this
case?  What we need is a way to distinguish between a character that
gets re-processed by quail.el from the use case described in the
reference mentioned in the log message of commit 30a6b1f, which was
the reason why we added the second call to record_char to read_char,
where previously there was none.  Don't both of these use cases use
the same machinery?

Thanks.





  reply	other threads:[~2018-07-11 15:23 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-09 22:41 bug#32108: 27.0.50; Insertion of char from input method during macro invocation duplicates the char Filipp Gunbin
2018-07-10 16:18 ` Eli Zaretskii
2018-07-10 22:38   ` Filipp Gunbin
2018-07-11  0:54     ` Glenn Morris
2018-07-11  3:11       ` Eli Zaretskii
2018-07-11  9:29       ` Eli Zaretskii
2018-07-11 12:58         ` Stefan Monnier
2018-07-11 15:23           ` Eli Zaretskii [this message]
2018-07-21  9:15         ` Eli Zaretskii
2018-07-23 18:38           ` Filipp Gunbin
2018-07-23 18:58             ` Eli Zaretskii
2018-07-11  3:09     ` 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=83k1q1g5j8.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=32108@debbugs.gnu.org \
    --cc=fgunbin@fastmail.fm \
    --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 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.