all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Christoph Arenz <tiga.arenz@web.de>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: Severe regressions in context of keyboard macros
Date: Thu, 26 Sep 2019 12:46:20 +0200	[thread overview]
Message-ID: <be5ad8a6-c7d2-be0f-f976-f64786f03588@web.de> (raw)
In-Reply-To: <83wodynkuo.fsf@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!




  reply	other threads:[~2019-09-26 10:46 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 [this message]
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             ` Fwd: " Christoph Arenz

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=be5ad8a6-c7d2-be0f-f976-f64786f03588@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 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.