Autokey not working with newly opened windows
113 views
Skip to first unread message
pg...@duralexnonlex.org
Jun 17, 2022, 7:52:11 AM6/17/22
to autoke...@googlegroups.com
Hi Autokey devs & users!
Software info: Ubuntu 20.04.4LTS, Gnome 3.36.8, Autokey 0.96.0 – very new to all three.
I am experiencing some glitches with Autokey and wanted to ask for help here before submitting bug reports, in case I'm doing something wrong.
I have several scripts set up, to convert some Ctrl+key or Alt+key combinations into movement or deletion keys. One example:
keyboard.send_key("<down>")
with hotkey <ctrl>+e (on Dvorak keyboard).
I want all these filters to work in all windows *except* Emacs windows, which have window class "emacs.Emacs". I solved this by:
1. making sure (via Emacs's init file) that all Emacs windows have the string ".Emacs" at the end of their title
2. setting Autokey's window filter to
(?!(.*\.Emacs))
for all the scripts.
This solution seems to work perfectly with all existing Emacs- and non-Emacs-windows when I start Autokey. Except that if I open a *new* Emacs window, then those keys are unresponsive there. What I mean is that, for example, pressing '<ctrl>+e' does neither send the '<down>' key (as per the script above), nor the '<ctrl>+e' key. On the other hand, if I open a new window of some other program (say Firefox or Nautilus), the hotkeys work fine there.
This happens with all hotkeys I set up.
Is this a bug, or am I doing something wrong in my setup?
Thank you for you insights and help!
Luca
Little Girl
Jun 18, 2022, 10:17:49 AM6/18/22
to autokey-users
This is a wild shot in the dark, but do new windows have the ".Emacs" string at the end of their title or have a title at all? Maybe a tweak of the filter based on the new window title will take care of it.
jack
Jun 18, 2022, 10:24:04 AM6/18/22
to autokey-users
How about a pattern stuck as:
.*Emacs$
Also, somewhere there is a script that shows what autokey thinks is the window title. I get it from the right click menu on tray icon... Maybe installed as part of autokey? 'Get window info', i think
Jack
Jack
jack
Jun 18, 2022, 10:43:29 AM6/18/22
to autokey-users
Also, try changing:
keyboard.send_key("<down>")
To:
keyboard.send_keys("<down>")
Send_key used to be a bit iffy. Send_keys was ok. May have all changed in 0.96. dunno
Jack
Jack
On 18 Jun 2022, at 15:17, Little Girl <littl...@gmail.com> wrote:
jack
Jun 18, 2022, 10:45:56 AM6/18/22
to autokey-users
I know this is stupid, but is the script doing the correct thing in the original Emacs window? Can't see how, but who knows.
Also, why not just rebind ^e in Emacs?
Jack
On 18 Jun 2022, at 15:17, Little Girl <littl...@gmail.com> wrote:
jos...@main.nc.us
Jun 18, 2022, 6:33:26 PM6/18/22
to autoke...@googlegroups.com
Welcome to everything - especially to AutoKey!
There are several issues here.
* You are attempting to use a negative window filter (all windows except
...).
This is very hard to do correctly in AutoKey (and an enhancement to fix it
has been worked on, but I'm not sure of its current status other than that
it's definitely not released). The problem (bug) is that AutoKey applies
the filter to the window class and to the window title and succeeds if
either is a match. You need a more complex window filter to compensate for
this shortcoming.
* (as Jack mentioned) Never use keyboard.send_key() unless nothing else
will work. See
https://github.com/autokey/autokey/wiki/Emitting-Keyboard-Events for a
full explanation.
* You might not need it yet for this issue, but whenever AutoKey appears
to be misbehaving and staring at your script doesn't reveal the cause,
then getting AutoKey's side of the story by running an AutoKey trace is
usually very helpful and may provide good information for the developers
if AutoKey is actually doing something wrong. See
https://github.com/autokey/autokey-python2/wiki/Problem-Reporting-Guide
for how to do this along with more information on how to report problems.
* AutoKey is not particularly fond of remapped keyboards. Depending on how
you set yours up, AutoKey may not be seeing the keypresses you think you
are sending it. A trace will show you if this is a problem.
Since there are a number of factors to this situation, take it one step at
a time and post back here so we can help you get it sorted.
Thanks so much for posting here first before filing issues. We much prefer
to handle as many user support issues as possible here and on Gitter so we
don't add clutter to the issues the developers need to focus on. And there
are more people to assist you here than there are on our GitHub site.
Joe
> --
> You received this message because you are subscribed to the Google Groups
> "autokey-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to autokey-user...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/autokey-users/7709dfa6-8aa6-4f46-878b-d9730bade397%40duralexnonlex.org.
>
There are several issues here.
* You are attempting to use a negative window filter (all windows except
...).
This is very hard to do correctly in AutoKey (and an enhancement to fix it
has been worked on, but I'm not sure of its current status other than that
it's definitely not released). The problem (bug) is that AutoKey applies
the filter to the window class and to the window title and succeeds if
either is a match. You need a more complex window filter to compensate for
this shortcoming.
* (as Jack mentioned) Never use keyboard.send_key() unless nothing else
will work. See
https://github.com/autokey/autokey/wiki/Emitting-Keyboard-Events for a
full explanation.
* You might not need it yet for this issue, but whenever AutoKey appears
to be misbehaving and staring at your script doesn't reveal the cause,
then getting AutoKey's side of the story by running an AutoKey trace is
usually very helpful and may provide good information for the developers
if AutoKey is actually doing something wrong. See
https://github.com/autokey/autokey-python2/wiki/Problem-Reporting-Guide
for how to do this along with more information on how to report problems.
* AutoKey is not particularly fond of remapped keyboards. Depending on how
you set yours up, AutoKey may not be seeing the keypresses you think you
are sending it. A trace will show you if this is a problem.
Since there are a number of factors to this situation, take it one step at
a time and post back here so we can help you get it sorted.
Thanks so much for posting here first before filing issues. We much prefer
to handle as many user support issues as possible here and on Gitter so we
don't add clutter to the issues the developers need to focus on. And there
are more people to assist you here than there are on our GitHub site.
Joe
> You received this message because you are subscribed to the Google Groups
> "autokey-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to autokey-user...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/autokey-users/7709dfa6-8aa6-4f46-878b-d9730bade397%40duralexnonlex.org.
>
pg...@duralexnonlex.org
Jun 22, 2022, 1:23:21 PM6/22/22
to autoke...@googlegroups.com
Thanks "Little Girl", Jack, Joe for the tips! Sorry for the delayed reply.
@Little Girl & Joe: Yes, I made sure that all Emacs windows have ".Emacs" at the end (through Emacs's init file), so that the negative-matching regex would work for either window title or window class.
@Jack: Yes, the rebindings were working correctly – which means they were *not* operating – on pre-existing Emacs windows. The problem appeared with newly opened ones.
@Jack & Joe: Thanks for the tip about using "send_keys" rather than "send_key"!
@Jack & all others: "Also, why not just rebind ^e in Emacs?". My problem is that if I allow the Autokey bindings to work also on Emacs, then Emacs would perceive <down> when I press ^e, and this restricts my key-binding freedom there: in Emacs I can remap ^e internally to different things depending on the "mode" (say, Latex mode, Org mode, etc).
However, I decided to simply avoid using the negative-matching regex and use my keybidings globally, but with "send_keys" instead of "send_key". Cleverly, Autokey does not remap shift+control+e, so I can press this when I need to sent ^e to Emacs. Now everything is working fine.
If the devs or other users are interested in the results, I'm happy to try to solve the original problem by using a different regex and see if the "send_keys" makes a difference, + checking the diagnostics mentioned by Joe, and report here.
Thank you all for the prompt and kind help!
Cheers,
Luca
@Little Girl & Joe: Yes, I made sure that all Emacs windows have ".Emacs" at the end (through Emacs's init file), so that the negative-matching regex would work for either window title or window class.
@Jack: Yes, the rebindings were working correctly – which means they were *not* operating – on pre-existing Emacs windows. The problem appeared with newly opened ones.
@Jack & Joe: Thanks for the tip about using "send_keys" rather than "send_key"!
@Jack & all others: "Also, why not just rebind ^e in Emacs?". My problem is that if I allow the Autokey bindings to work also on Emacs, then Emacs would perceive <down> when I press ^e, and this restricts my key-binding freedom there: in Emacs I can remap ^e internally to different things depending on the "mode" (say, Latex mode, Org mode, etc).
However, I decided to simply avoid using the negative-matching regex and use my keybidings globally, but with "send_keys" instead of "send_key". Cleverly, Autokey does not remap shift+control+e, so I can press this when I need to sent ^e to Emacs. Now everything is working fine.
If the devs or other users are interested in the results, I'm happy to try to solve the original problem by using a different regex and see if the "send_keys" makes a difference, + checking the diagnostics mentioned by Joe, and report here.
Thank you all for the prompt and kind help!
Cheers,
Luca
jos...@main.nc.us
Jun 23, 2022, 1:59:49 AM6/23/22
to autoke...@googlegroups.com
Glad you have a workaround!
I'm a little hazy on the original problem. If the problem is primarily
with newly opened Emacs windows, then running an AutoKey trace might show
what the problem is. It sounds like the window filter is failing to match
the window title/class of those specific windows. That's worth looking at
if you want to spend the effort testing it.
Our window filter code badly needs an upgrade and one was proposed and
worked on, but not completed.
Joe
I'm a little hazy on the original problem. If the problem is primarily
with newly opened Emacs windows, then running an AutoKey trace might show
what the problem is. It sounds like the window filter is failing to match
the window title/class of those specific windows. That's worth looking at
if you want to spend the effort testing it.
Our window filter code badly needs an upgrade and one was proposed and
worked on, but not completed.
Joe
Little Girl
Jun 23, 2022, 10:22:12 AM6/23/22
to autokey-users
I'm glad you got it working, too. In the event that you still want to figure out why it didn't originally work, someone in the Emacs IRC channel said that I should ask you how you were ensuring that each window had .Emacs at the end of its title. Maybe those new windows don't.
pg...@duralexnonlex.org
Jun 23, 2022, 10:34:32 AM6/23/22
to autoke...@googlegroups.com
Hi Joe and Little Girl,
I'll explore more and run traces and report. Just a quick answer to this:
> I'm glad you got it working, too. In the event that you still want to figure out why it didn't originally work, someonein the Emacs IRC channel said that I should ask you how you were ensuring that each window had .Emacs at the end of its title. Maybe those new windows don't.
I set
(setq frame-title-format "%b .Emacs")
And can confirm that Autokey's "Window filter" in the script settings does see ".Emacs" at the end of the title. But it's possible that the window has a different title in the very first milliseconds after its creation – I'll run a trace to check this.
Cheers,
Luca
I'll explore more and run traces and report. Just a quick answer to this:
> I'm glad you got it working, too. In the event that you still want to figure out why it didn't originally work, someonein the Emacs IRC channel said that I should ask you how you were ensuring that each window had .Emacs at the end of its title. Maybe those new windows don't.
I set
(setq frame-title-format "%b .Emacs")
And can confirm that Autokey's "Window filter" in the script settings does see ".Emacs" at the end of the title. But it's possible that the window has a different title in the very first milliseconds after its creation – I'll run a trace to check this.
Cheers,
Luca
jack
Jun 23, 2022, 10:39:49 AM6/23/22
to autokey-users
I assume autokey looks at the window titles when you press the key... So a very short title change would not matter.
What happens if you create the new Emacs window, then restart autokey? Does autokey pick up both the Emacs Windows?
Jack
pg...@duralexnonlex.org
Jun 23, 2022, 10:52:13 AM6/23/22
to autoke...@googlegroups.com
> What happens if you create the new Emacs window, then restart autokey? Does autokey pick up both the Emacs Windows?
Yes, it does in that case.
I may add that changing "...send_key" into "...send_keys" does not solve the problem.
jack
Jun 23, 2022, 10:57:34 AM6/23/22
to autokey-users
... But does not pick up a third Emacs window unless you restart autokey. I assume.
I know this is silly, but what happens if you give the new windows a title that does not end in Emacs? And modify your key to match the new title, of course.
Jack
Little Girl
Jun 23, 2022, 12:19:28 PM6/23/22
to autokey-users
Hey there,
Yeah, maybe you could get AutoKey to loop the script, possibly with a short delay in it, so that it has a chance to recognize the new Emacs windows after they open.
pg...@duralexnonlex.org
Jul 12, 2022, 4:42:44 PM7/12/22
to autokey-users
Hi Joe, Jack, Little Girl,
I'm finally reporting back with some Autokey traces. Sorry for the delay, been quite busy.
Let me summarize again my setup and my problem:
Ubuntu 20.04
KDE Plasma 5.18.8, Qt version 5.12.8
Autokey-qt 0.96.0 [also -gtk, see below]
Dvorak keyboard or standard US keyboard, the situation is the same in both.
I set up two scripts:
"UP"
keyboard.send_keys("<up>")
Hotkey: <ctrl>+.
Window Filter: .
"DOWN"
keyboard.send_keys("<down>")
Hotkey: <ctrl>+e
Window Filer: (?!(.*\.Emacs))
* The script "UP" is intended to be a global remapping of ctrl+. to the "up" key.
* The script "DOWN" is intended to be a remapping of ctrl+e to the "down" key in all windows *except* Emacs windows.
* All Emacs windows in my system have window-class "emacs.Emacs" and their window-title always ends with ".Emacs".
Observed behaviour:
* In all non-Emacs windows, also newly opened ones, the two key combinations work as intended.
* In Emacs windows *that already exist when Autokey is started*, the two key combinations work as intended.
* In Emacs windows *opened after Autokey is started*, the UP script work as intended, but the DOWN script (the one with negative matching) does not produce any output, as if no key was pressed.
Here are traces obtained with "autokey-qt -l" and the corresponding actions:
(a) Moving mouse to an existing Emacs window ('scrach'), pressing ctrl+.:
2022-07-12 21:41:59,015 DEBUG - autokey.iomediator.iomediator - Key.CONTROL pressed
2022-07-12 21:41:59,441 DEBUG - autokey.service - Raw key: '.', modifiers: [<Key.CONTROL: '<ctrl>'>], Key: .
2022-07-12 21:41:59,441 DEBUG - autokey.service - Window visible title: '*scratch* .Emacs', Window class: 'emacs.Emacs'
2022-07-12 21:41:59,441 INFO - autokey.service - Matched Script "up" with hotkey and prompt=False
2022-07-12 21:41:59,448 DEBUG - autokey.service - Script runner executing: Script('up')
2022-07-12 21:41:59,449 DEBUG - autokey.iomediator.iomediator - Send via event interface
2022-07-12 21:41:59,451 DEBUG - autokey.interface - Send special key: ['<up>']
2022-07-12 21:41:59,673 DEBUG - autokey.iomediator.iomediator - Key.CONTROL released
(b) Moving mouse to an existing Emacs window ('scrach'), pressing ctrl+e:
2022-07-12 21:42:04,050 DEBUG - autokey.iomediator.iomediator - Key.CONTROL pressed
2022-07-12 21:42:04,499 DEBUG - autokey.service - Raw key: 'e', modifiers: [<Key.CONTROL: '<ctrl>'>], Key: e
2022-07-12 21:42:04,500 DEBUG - autokey.service - Window visible title: '*scratch* .Emacs', Window class: 'emacs.Emacs'
2022-07-12 21:42:04,724 DEBUG - autokey.iomediator.iomediator - Key.CONTROL released
(c) Moving mouse to a newly opened Emacs window ('Messages'), pressing ctrl+.:
2022-07-12 21:42:50,755 DEBUG - autokey.iomediator.iomediator - Key.CONTROL pressed
2022-07-12 21:42:51,070 DEBUG - autokey.service - Raw key: '.', modifiers: [<Key.CONTROL: '<ctrl>'>], Key: .
2022-07-12 21:42:51,070 DEBUG - autokey.service - Window visible title: '*Messages* .Emacs', Window class: 'emacs.Emacs'
2022-07-12 21:42:51,070 INFO - autokey.service - Matched Script "up" with hotkey and prompt=False
2022-07-12 21:42:51,077 DEBUG - autokey.service - Script runner executing: Script('up')
2022-07-12 21:42:51,077 DEBUG - autokey.iomediator.iomediator - Send via event interface
2022-07-12 21:42:51,079 DEBUG - autokey.interface - Send special key: ['<up>']
2022-07-12 21:42:51,293 DEBUG - autokey.iomediator.iomediator - Key.CONTROL released
(d) Moving mouse to a newly opened Emacs window ('Messages'), pressing ctrl+e:
2022-07-12 21:42:54,076 DEBUG - autokey.iomediator.iomediator - Key.CONTROL pressed
2022-07-12 21:42:54,573 DEBUG - autokey.service - Raw key: 'e', modifiers: [<Key.CONTROL: '<ctrl>'>], Key: e
2022-07-12 21:42:54,573 DEBUG - autokey.service - Window visible title: '*Messages* .Emacs', Window class: 'emacs.Emacs'
2022-07-12 21:42:55,060 DEBUG - autokey.iomediator.iomediator - Key.CONTROL released
(e) Moving mouse to a non-Emacs window (Dolphin file browser), pressing ctrl+.:
2022-07-12 21:43:26,014 DEBUG - autokey.iomediator.iomediator - Key.CONTROL pressed
2022-07-12 21:43:26,311 DEBUG - autokey.service - Raw key: '.', modifiers: [<Key.CONTROL: '<ctrl>'>], Key: .
2022-07-12 21:43:26,311 DEBUG - autokey.service - Window visible title: '.config — Dolphin', Window class: 'dolphin.dolphin'
2022-07-12 21:43:26,314 INFO - autokey.service - Matched Script "up" with hotkey and prompt=False
2022-07-12 21:43:26,318 DEBUG - autokey.service - Script runner executing: Script('up')
2022-07-12 21:43:26,318 DEBUG - autokey.iomediator.iomediator - Send via event interface
2022-07-12 21:43:26,325 DEBUG - autokey.interface - Send special key: ['<up>']
2022-07-12 21:43:26,513 DEBUG - autokey.iomediator.iomediator - Key.CONTROL released
(f) Moving mouse to a non-Emacs window (Dolphin file browser), pressing ctrl+e:
2022-07-12 21:43:28,137 DEBUG - autokey.iomediator.iomediator - Key.CONTROL pressed
2022-07-12 21:43:28,472 DEBUG - autokey.service - Raw key: 'e', modifiers: [<Key.CONTROL: '<ctrl>'>], Key: e
2022-07-12 21:43:28,472 DEBUG - autokey.service - Window visible title: '.config — Dolphin', Window class: 'dolphin.dolphin'
2022-07-12 21:43:28,473 INFO - autokey.service - Matched Script "down" with hotkey and prompt=False
2022-07-12 21:43:28,483 DEBUG - autokey.service - Script runner executing: Script('down')
2022-07-12 21:43:28,484 DEBUG - autokey.iomediator.iomediator - Send via event interface
2022-07-12 21:43:28,491 DEBUG - autokey.interface - Send special key: ['<down>']
2022-07-12 21:43:28,707 DEBUG - autokey.iomediator.iomediator - Key.CONTROL released
I see that the trace in the Emacs cases (b) and (d) is the same, but in case (b) Emacs correctly receives ctrl+e (unmodified keypress sent), while in case (d) Emacs does not receive anything at all (the unmodified ctrl+e was expected instead).
* Let me add: if I redo as above but with the titles of the two Emacs windows swapped, the situation remains the same. So it's the fact that's a new window that seems to be breaking things, not the specific window title.
Also: I changed from Gnome & autokey-gtk 0.96.0 to KDE & autokey-qt 0.96.0, and this quirk happens in both desktops.
Let me know if I can send you any other info. Thank you again for Autokey and your help!
Cheers,
Luca
I'm finally reporting back with some Autokey traces. Sorry for the delay, been quite busy.
Let me summarize again my setup and my problem:
Ubuntu 20.04
KDE Plasma 5.18.8, Qt version 5.12.8
Autokey-qt 0.96.0 [also -gtk, see below]
Dvorak keyboard or standard US keyboard, the situation is the same in both.
I set up two scripts:
"UP"
keyboard.send_keys("<up>")
Hotkey: <ctrl>+.
Window Filter: .
"DOWN"
keyboard.send_keys("<down>")
Hotkey: <ctrl>+e
Window Filer: (?!(.*\.Emacs))
* The script "UP" is intended to be a global remapping of ctrl+. to the "up" key.
* The script "DOWN" is intended to be a remapping of ctrl+e to the "down" key in all windows *except* Emacs windows.
* All Emacs windows in my system have window-class "emacs.Emacs" and their window-title always ends with ".Emacs".
Observed behaviour:
* In all non-Emacs windows, also newly opened ones, the two key combinations work as intended.
* In Emacs windows *that already exist when Autokey is started*, the two key combinations work as intended.
* In Emacs windows *opened after Autokey is started*, the UP script work as intended, but the DOWN script (the one with negative matching) does not produce any output, as if no key was pressed.
Here are traces obtained with "autokey-qt -l" and the corresponding actions:
(a) Moving mouse to an existing Emacs window ('scrach'), pressing ctrl+.:
2022-07-12 21:41:59,015 DEBUG - autokey.iomediator.iomediator - Key.CONTROL pressed
2022-07-12 21:41:59,441 DEBUG - autokey.service - Raw key: '.', modifiers: [<Key.CONTROL: '<ctrl>'>], Key: .
2022-07-12 21:41:59,441 DEBUG - autokey.service - Window visible title: '*scratch* .Emacs', Window class: 'emacs.Emacs'
2022-07-12 21:41:59,441 INFO - autokey.service - Matched Script "up" with hotkey and prompt=False
2022-07-12 21:41:59,448 DEBUG - autokey.service - Script runner executing: Script('up')
2022-07-12 21:41:59,449 DEBUG - autokey.iomediator.iomediator - Send via event interface
2022-07-12 21:41:59,451 DEBUG - autokey.interface - Send special key: ['<up>']
2022-07-12 21:41:59,673 DEBUG - autokey.iomediator.iomediator - Key.CONTROL released
(b) Moving mouse to an existing Emacs window ('scrach'), pressing ctrl+e:
2022-07-12 21:42:04,050 DEBUG - autokey.iomediator.iomediator - Key.CONTROL pressed
2022-07-12 21:42:04,499 DEBUG - autokey.service - Raw key: 'e', modifiers: [<Key.CONTROL: '<ctrl>'>], Key: e
2022-07-12 21:42:04,500 DEBUG - autokey.service - Window visible title: '*scratch* .Emacs', Window class: 'emacs.Emacs'
2022-07-12 21:42:04,724 DEBUG - autokey.iomediator.iomediator - Key.CONTROL released
(c) Moving mouse to a newly opened Emacs window ('Messages'), pressing ctrl+.:
2022-07-12 21:42:50,755 DEBUG - autokey.iomediator.iomediator - Key.CONTROL pressed
2022-07-12 21:42:51,070 DEBUG - autokey.service - Raw key: '.', modifiers: [<Key.CONTROL: '<ctrl>'>], Key: .
2022-07-12 21:42:51,070 DEBUG - autokey.service - Window visible title: '*Messages* .Emacs', Window class: 'emacs.Emacs'
2022-07-12 21:42:51,070 INFO - autokey.service - Matched Script "up" with hotkey and prompt=False
2022-07-12 21:42:51,077 DEBUG - autokey.service - Script runner executing: Script('up')
2022-07-12 21:42:51,077 DEBUG - autokey.iomediator.iomediator - Send via event interface
2022-07-12 21:42:51,079 DEBUG - autokey.interface - Send special key: ['<up>']
2022-07-12 21:42:51,293 DEBUG - autokey.iomediator.iomediator - Key.CONTROL released
(d) Moving mouse to a newly opened Emacs window ('Messages'), pressing ctrl+e:
2022-07-12 21:42:54,076 DEBUG - autokey.iomediator.iomediator - Key.CONTROL pressed
2022-07-12 21:42:54,573 DEBUG - autokey.service - Raw key: 'e', modifiers: [<Key.CONTROL: '<ctrl>'>], Key: e
2022-07-12 21:42:54,573 DEBUG - autokey.service - Window visible title: '*Messages* .Emacs', Window class: 'emacs.Emacs'
2022-07-12 21:42:55,060 DEBUG - autokey.iomediator.iomediator - Key.CONTROL released
(e) Moving mouse to a non-Emacs window (Dolphin file browser), pressing ctrl+.:
2022-07-12 21:43:26,014 DEBUG - autokey.iomediator.iomediator - Key.CONTROL pressed
2022-07-12 21:43:26,311 DEBUG - autokey.service - Raw key: '.', modifiers: [<Key.CONTROL: '<ctrl>'>], Key: .
2022-07-12 21:43:26,311 DEBUG - autokey.service - Window visible title: '.config — Dolphin', Window class: 'dolphin.dolphin'
2022-07-12 21:43:26,314 INFO - autokey.service - Matched Script "up" with hotkey and prompt=False
2022-07-12 21:43:26,318 DEBUG - autokey.service - Script runner executing: Script('up')
2022-07-12 21:43:26,318 DEBUG - autokey.iomediator.iomediator - Send via event interface
2022-07-12 21:43:26,325 DEBUG - autokey.interface - Send special key: ['<up>']
2022-07-12 21:43:26,513 DEBUG - autokey.iomediator.iomediator - Key.CONTROL released
(f) Moving mouse to a non-Emacs window (Dolphin file browser), pressing ctrl+e:
2022-07-12 21:43:28,137 DEBUG - autokey.iomediator.iomediator - Key.CONTROL pressed
2022-07-12 21:43:28,472 DEBUG - autokey.service - Raw key: 'e', modifiers: [<Key.CONTROL: '<ctrl>'>], Key: e
2022-07-12 21:43:28,472 DEBUG - autokey.service - Window visible title: '.config — Dolphin', Window class: 'dolphin.dolphin'
2022-07-12 21:43:28,473 INFO - autokey.service - Matched Script "down" with hotkey and prompt=False
2022-07-12 21:43:28,483 DEBUG - autokey.service - Script runner executing: Script('down')
2022-07-12 21:43:28,484 DEBUG - autokey.iomediator.iomediator - Send via event interface
2022-07-12 21:43:28,491 DEBUG - autokey.interface - Send special key: ['<down>']
2022-07-12 21:43:28,707 DEBUG - autokey.iomediator.iomediator - Key.CONTROL released
I see that the trace in the Emacs cases (b) and (d) is the same, but in case (b) Emacs correctly receives ctrl+e (unmodified keypress sent), while in case (d) Emacs does not receive anything at all (the unmodified ctrl+e was expected instead).
* Let me add: if I redo as above but with the titles of the two Emacs windows swapped, the situation remains the same. So it's the fact that's a new window that seems to be breaking things, not the specific window title.
Also: I changed from Gnome & autokey-gtk 0.96.0 to KDE & autokey-qt 0.96.0, and this quirk happens in both desktops.
Let me know if I can send you any other info. Thank you again for Autokey and your help!
Cheers,
Luca
Little Girl
Jul 13, 2022, 8:20:27 PM7/13/22
to autokey-users
Hey there,
Hopefully you pasted those in backwards, because the only obvious difference between b and d is the window title. There's a typo in the window title of b, so it should be the one failing, with "scrach" in one line and "scratch" in the other:
(b) Moving mouse to an existing Emacs window ('scrach'), pressing ctrl+e:
2022-07-12 21:42:04,500 DEBUG - autokey.service - Window visible title: '*scratch* .Emacs', Window class: 'emacs.Emacs'
From what you said, though, b is behaving properly and d isn't and it makes no difference if you swap those lines. If the title has nothing to do with it, I have no idea. Both the windows that work and the ones that don't work were created by Emacs and the one event that seems to separate them is the introduction of AutoKey. The baffling part is that AutoKey should make key-presses and key-releases possible rather than preventing them.
jack
Jul 14, 2022, 2:40:41 AM7/14/22
to autoke...@googlegroups.com, Little Girl
99% sure that will be a typo. "*scratch*" is a standard emacs
buffer...automatically created. i can't imagine anybody would try to
mess with its name.
it does all look a bit baffling. at the weekend i'll have a go at recreating... i have emacs.
jack
If today was yesterday or tomorrow, I'd be fine
it does all look a bit baffling. at the weekend i'll have a go at recreating... i have emacs.
jack
If today was yesterday or tomorrow, I'd be fine
--
You received this message because you are subscribed to the Google Groups "autokey-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to autokey-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/autokey-users/6387829d-d513-4005-95b6-09e43edd502dn%40googlegroups.com.
pg...@duralexnonlex.org
Jul 14, 2022, 9:45:29 AM7/14/22
to autoke...@googlegroups.com
Hi Jack and Little Girl,
Sorry, "scrach" was just a typo of mine. The trace was copy&pasted from the terminal.
I tried one more thing: created a negative regex for Dolphin windows (the file manager) instead of Emacs. The problem appears also in this case: in *newly opened* Dolphin windows the negative-regex script does not send anything (neither the alternative send_keys, nor the unmodified hotkey). So this is not something peculiar to Emacs.
Cheers,
Luca
>> To view this discussion on the web visit https://groups.google.com/d/msgid/autokey-users/6387829d-d513-4005-95b6-09e43edd502dn%40googlegroups.com <https://groups.google.com/d/msgid/autokey-users/6387829d-d513-4005-95b6-09e43edd502dn%40googlegroups.com?utm_medium=email&utm_source=footer>.
> To view this discussion on the web visit https://groups.google.com/d/msgid/autokey-users/e4d07970-8020-5e09-286a-583a3fbc872d%40gmail.com <https://groups.google.com/d/msgid/autokey-users/e4d07970-8020-5e09-286a-583a3fbc872d%40gmail.com?utm_medium=email&utm_source=footer>.
Sorry, "scrach" was just a typo of mine. The trace was copy&pasted from the terminal.
I tried one more thing: created a negative regex for Dolphin windows (the file manager) instead of Emacs. The problem appears also in this case: in *newly opened* Dolphin windows the negative-regex script does not send anything (neither the alternative send_keys, nor the unmodified hotkey). So this is not something peculiar to Emacs.
Cheers,
Luca
>
> --
> You received this message because you are subscribed to the Google Groups "autokey-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to autokey-user...@googlegroups.com <mailto:autokey-user...@googlegroups.com>.
> --
> You received this message because you are subscribed to the Google Groups "autokey-users" group.
> To view this discussion on the web visit https://groups.google.com/d/msgid/autokey-users/e4d07970-8020-5e09-286a-583a3fbc872d%40gmail.com <https://groups.google.com/d/msgid/autokey-users/e4d07970-8020-5e09-286a-583a3fbc872d%40gmail.com?utm_medium=email&utm_source=footer>.
Little Girl
Jul 14, 2022, 10:29:27 AM7/14/22
to autokey-users
You're doing some terrific testing. It loooks like AutoKey checks for the presence of windows that match the window filter only once when the script is launched. As a work-around, you might want to manually filter for new windows inside a loop in your script. Meanwhile, this should become an issue in the AutoKey issue tracker so the developers can take a look at it and possibly modify the behavior of the window filter entirely or provide a toggle or additional option so the user can decide whether the filter should be applied once on launch or continuously thereafter.
Reply all
Reply to author
Forward
0 new messages