From: Christoph Arenz <tiga.arenz@web.de>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Fwd: Re: Severe regressions in context of keyboard macros
Date: Fri, 27 Sep 2019 16:58:59 +0200 [thread overview]
Message-ID: <8e4a0541-5234-708d-9095-e685dfee9287@web.de> (raw)
In-Reply-To: <be5ad8a6-c7d2-be0f-f976-f64786f03588@web.de>
[-- Attachment #1: Type: text/plain, Size: 3666 bytes --]
FYI -- the bug regarding the input methods and keyboard macros is now
filed in a separate bug report:
bug#37526: 27.0.50; double-recording of keys with input-methods and
keyboard-macros
Thanks,
Christoph
-------- Forwarded Message --------
Subject: Re: Severe regressions in context of keyboard macros
Date: Thu, 26 Sep 2019 12:46:20 +0200
From: Christoph Arenz <tiga.arenz@web.de>
To: Eli Zaretskii <eliz@gnu.org>
CC: emacs-devel@gnu.org
On 9/24/19 10:45 AM, Eli Zaretskii wrote:
>> How about the following patch? It solved the calc bug for me and I
>> could not find other regressions so far.
>> Running make check showed no difference.
>> As mentioned, I do not understand all potential effects, so it should
>> be given some thoughts and tests.
> Thanks, but I'd like to avoid changes in keyboard.c on behalf of input
> recording issues, unless such changes are really a must. In this
> case, we already have 2 facilities to deal with unwanted repeated
> recording of keys:
Thanks for the pointers!
> . a Lisp program can bind inhibit--record-char to a non-nil value to
> avoid recording input events while some Lisp form is executed (you
> can see an example of using this in quail.el:quail-start-translation
> . a Lisp program can push onto unread-command-events a cons cell of
> the form '(no-record . KEY) to avoid recording KEY more than once
> (you can see an example of using this in
> cua-base.el:cua--prefix-override-replay)
>
> Can you use one of these facilities to solve the issue in Calc? Note
> that you will need to build Emacs from the Git master branch to be
> able to use these facilities, they are not available before Emacs 27.
I think we are on to something here!
The sample in quail.el sounded fitting for me at first, but I could not
get it working for the calc case.
So I took a closer look at input-methods -- that is what quail is used
for, right?
I tried some simple tests using the french word for brother (`frère' --
the first `e' is with a ``' on top of it -- hopefully my mailer does not
screw this up...)
using various french input methods: french-prefix, french-postfix and
french-azerty -- all in context of keyboard macro recording and playback.
The calc case should fit nicely with the -postfix case, I thought.
However, on master branch 07367e5b95fe31f3d4e994b42b081075501b9b60, I
got this:
french-prefix:
keys pressed: <f3> f r ` e r e , <spc> <f4> <f4> <f4>
text inserted in buffer: "frère, frère, frère "
last-kbd-macro: "fr`ere, "
--> Note the two(!) <spc> recorded after the `,' though only one was
typed in!
french-postfix:
keys pressed: <f3> f r e ` r e , <spc> <f4> <f4> <f4>
text inserted in buffer: "frère, frèrre,, frèrre,, "
last-kbd-macro: "fre`rre,, "
--> Note the double recording of `r' and `,' !
--> This closely resembles the reported symptoms for the calc package!
french-azerty:
keys pressed (on US keyboard-layout): <f3> f r e 7 r e m <spc> <f4> <f4>
<f4>
text inserted in buffer: "frère, frère, frère, "
last-kbd-macro: "fr7rem "
--> This looks as I would expect it.
A quick check on emacs-24.5 showed that all cases were handled correctly
back then.
So, some of the new ways of handling this are not covering all corner
cases, and work wrong with -postfix and calc prefix handling.
Does this give any clues what still needs to be fixed? I am lost in the
complexity of how the code should handle this...
N.B. For what it's worth, I am physically using a german keyboard with a
US layout in GNOME.
Probably this should not matter and be equivalent to a US keyboard...
Thanks!
[-- Attachment #2: Type: text/html, Size: 6051 bytes --]
prev parent reply other threads:[~2019-09-27 14:58 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-19 8:17 Severe regressions in context of keyboard macros Christoph Arenz
2019-09-20 7:23 ` Eli Zaretskii
2019-09-20 15:43 ` Christoph Arenz
2019-09-20 17:54 ` Eli Zaretskii
2019-09-23 11:57 ` Christoph Arenz
2019-09-24 8:45 ` Eli Zaretskii
2019-09-26 10:46 ` Christoph Arenz
2019-09-26 10:56 ` Eli Zaretskii
2019-09-26 11:22 ` Christoph Arenz
2019-09-26 12:10 ` Eli Zaretskii
2019-09-26 18:27 ` Christoph Arenz
2019-09-28 9:18 ` Christoph Arenz
2019-09-28 9:46 ` Eli Zaretskii
2019-09-29 17:42 ` Christoph Arenz
2019-10-15 12:12 ` Eli Zaretskii
2019-09-28 12:35 ` Stefan Monnier
2019-09-28 13:44 ` Eli Zaretskii
2019-09-29 17:59 ` Christoph Arenz
2019-09-27 14:58 ` Christoph Arenz [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=8e4a0541-5234-708d-9095-e685dfee9287@web.de \
--to=tiga.arenz@web.de \
--cc=eliz@gnu.org \
--cc=emacs-devel@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).