From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Christoph Arenz Newsgroups: gmane.emacs.devel Subject: Fwd: Re: Severe regressions in context of keyboard macros Date: Fri, 27 Sep 2019 16:58:59 +0200 Message-ID: <8e4a0541-5234-708d-9095-e685dfee9287@web.de> References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------B97B8F0175639BC117762506" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="131660"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 27 18:59:12 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iDtaJ-000Y7G-7D for ged-emacs-devel@m.gmane.org; Fri, 27 Sep 2019 18:59:11 +0200 Original-Received: from localhost ([::1]:53722 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iDtaG-00062X-VR for ged-emacs-devel@m.gmane.org; Fri, 27 Sep 2019 12:59:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53780) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iDriH-0001d4-5K for emacs-devel@gnu.org; Fri, 27 Sep 2019 10:59:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iDriE-0003fU-Ln for emacs-devel@gnu.org; Fri, 27 Sep 2019 10:59:16 -0400 Original-Received: from mout.web.de ([212.227.17.12]:41017) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iDriA-0003e5-SJ; Fri, 27 Sep 2019 10:59:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1569596343; bh=bbcPbx9KDmk/vNFoqaCQliYUErh1GuWEkm3VeiZORiU=; h=X-UI-Sender-Class:Subject:References:To:Cc:From:Date:In-Reply-To; b=fIqTiZyy3QVDMKJ71/NLeyNCiCGlSoUlrmA+33aJB2YdqcoAlsne7JydYSOgxf2/J IxYlFfJfMw32yUJPehwjrmc2GW1OoNZxpaCd19D0VZNUTW1KFo849Khk0YsUaul8Dt y6DiZFVrpOQ0/lQnjZDgc/upapFo+w0f16483CFI= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Original-Received: from oc3710058320.ibm.com ([94.16.133.3]) by smtp.web.de (mrweb102 [213.165.67.124]) with ESMTPSA (Nemesis) id 0MD8BU-1iNlBz2rIS-00GWME; Fri, 27 Sep 2019 16:59:03 +0200 X-Forwarded-Message-Id: In-Reply-To: Content-Language: en-US X-Provags-ID: V03:K1:YvOHcEErVRZvYmIs8ZszwVGOV7P8m4FmkG50Dt7D/tsbHIPRuxy UPysopdUJCHKw/4uSGPpDOEjpBECT3bZ5E5hfzJ555JqV4cXyE2g368eOdrofoUDIk+6fAZ oULnX7637P11EYx3EAwht2f6tfGjqU4r0bJmeibeNKgqEP8xZHeZANzVXZ9tGtBojtZLZyC LyMVsle/v4BbNmWwaTuYw== X-UI-Out-Filterresults: notjunk:1;V03:K0:WFQsjz0Osek=:r0dtBPasB0RZ9Zsc/Ndv2r Qw2pZl5LtrceNtmWDmeMc6lHOoAreaSrEzgzXJk5MItEWnU3LshmkZTeDeiRlhT+h+fIIT1mJ q/eP4Qh9IwVQ8ceR7XjkyGM/9Og4Rd896FvQvYp4t1xPLustmxK5px2hC99Is5/Ozm/3Tk0Px 0Tcg33AYBGkQm+xgHN1n5XHRLB8AFZD5qHSQNV0LmU9mx1ewTdj8uMJvHY0MAyzQKbLrcNTLK qQLMb2Mv8W7FJ5jqFbN6DFvFit1Gqis+IXWGqwezpl37H2hYYvSHN7lJXKu0jKL42KcCFIkpr GxF+9/ezNbGS/rlQj4v0kcGRyUxwHDug7/ij2atwAcblNb7to6fIjc6k/ZLlQh5XYVAjaRNWw NTw47aw4ZV30q3KTwq/W8rtLuRAhalP7Sb85WDPD9sMhEaTzCQL91lHydGJvhrQRpTGKSaika 0WqYzidrtA6iwTGA1oVDZ0Xq4kw1xAWveDL0RAL/vkxjOd+G03dU2jNOiQRYjfSKF7U0UGURF vUzfh5jnIuMt6BgtDBcrmE5+SGEvDFFD5gddNqGQozftd+5aZzn1qDgwEgbgvKHpCbqc8KMZC 2cF9Rspqm22RvKtEF30aLYGyrdaq5WW2dVEmN8OvlsykfOg8UMLqa1vZugHXqePmFnfWK0ufj Kr+jLuhfimTJf+mDzOiKDtA3ipql+LHictDcGl8h/y8gTdMc+LcF3thFWZu45EZaJiYCr9x4y acIeZ7Sc4fHJ3Igp+mPen7QAnjb1IKSi1bBYm+k5YwBYe0QW6UOWcuXo6XD3tzwyOrGSZGCp X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 212.227.17.12 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:240342 Archived-At: This is a multi-part message in MIME format. --------------B97B8F0175639BC117762506 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable 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 =2D------- Forwarded Message -------- Subject: Re: Severe regressions in context of keyboard macros Date: Thu, 26 Sep 2019 12:46:20 +0200 From: Christoph Arenz To: Eli Zaretskii 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=C3=A8re' = -- 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: f r ` e r e , text inserted in buffer: "fr=C3=A8re, fr=C3=A8re,=C2=A0 fr=C3=A8re=C2=A0 " last-kbd-macro: "fr`ere,=C2=A0 " =2D-> Note the two(!) recorded after the `,' though only one was typed in! french-postfix: keys pressed: f r e ` r e , text inserted in buffer: "fr=C3=A8re, fr=C3=A8rre,, fr=C3=A8rre,, " last-kbd-macro: "fre`rre,, " =2D-> Note the double recording of `r' and `,' ! =2D-> This closely resembles the reported symptoms for the calc package! french-azerty: keys pressed (on US keyboard-layout): f r e 7 r e m text inserted in buffer: "fr=C3=A8re, fr=C3=A8re, fr=C3=A8re, " last-kbd-macro: "fr7rem " =2D-> 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! --------------B97B8F0175639BC117762506 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 --------
Subj= ect: 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=C3=A8re' -- the first `e' is with a ``' on top of it -- hopeful= ly 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=C3=A8re, fr=C3=A8re,=C2=A0 fr=C3=A8re= =C2=A0 "
last-kbd-macro: "fr`ere,=C2=A0 "
--> 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=C3=A8re, fr=C3=A8rre,, fr=C3=A8rre,, "<= br> 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=C3=A8re, fr=C3=A8re, fr=C3=A8re, "
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!

--------------B97B8F0175639BC117762506--