Debounced Event Filter

[jeffeb3]

I'm using Shell Commands to execute a bash git script to keep my notes synced with my server. I am using the "File content modified" event and it is killing itself trying to keep up, now that my notes are large enough that git takes any amount of time.

I am considering ways to fix this. One really excellent way would be to add a "debounce" to the event in SC. I am using lodash.debounce on one of my FOSS projects: https://docs-lodash.com/v4/debounce/ . My crappy code use is here: https://github.com/jeffeb3/sandify/blob/master/src/components/InputOption.js#L12 (this just waits to update the display until the user has stopped typing for 1.5s).

The way I imagine this working is a user defined number of seconds (with zero to disable, or maybe a separate event type, IDK). If they set 5s, then the event would keep feeding the debounce with updated information. As soon as 5s had elapsed without any new calls to debounce, the event would trigger. This would ensure the final event always fired, and it would drop intermediate events that were just updating things that were already out of date. The absolute "minimum viable product" would be to create a second "File content modified" event, with a name like "File content updated", and it always does this debounce.

That is my take on it. You may want to think about making this more widely available, or how to make it clear to the users.

I can probably find another solution or work around in the "user space". Something like a bash version of debounce, or making the shell command just touch a file on the system when there was a change, and have a cron job periodically check that file, and call the git push script. But that only solves it for me.

[Taitava]

Hi, I can agree on this. There has been some dicussion about this earlier, but maybe I could use your topic as the main topic for this feature from now on and do some further planning on it.

A quote from my comment in #284:

It's a good idea, actually something that would suit for many other events, too. The feature could be called as threshold.

It could be a shell command level setting:

• Threshold duration: in milliseconds, e.g. 500 would be 0.5 seconds like you suggested. If 0, threshold is not used.

Edit: Also need to add an option defining whether the shell command execution should happen early or late:

• Executing early first executes the shell command and then waits for the threshold duration. If any execution attempts occur during the waiting, they will be cancelled silently.
• Executing late waits until the threshold is passed, and then executes the shell command. This is better if you need to ensure that also the last event occurrence will execute the shell command. Otherwise the final event occurring time might go unnoticed.
• OR: Maybe consider if these could be combined: Execute immediately, then wait and see if further execution attempts are made, and if yes, do a re-execution after the threshold duration is over. No setting would be needed. I need to think about this.

Also #287 talks about this.

So, some design principles:

• The threshold setting would be set on a shell command, and it would affect most events:
  • File contents modified
  • File/folder created/deleted/moved/renamed
  • Switching the active pane
• Events not affected by the feature:
  • File menu / Folder menu / Editor menu: These are based on user directly commanding to execute commands, so no threshold is needed.
  • Obsidian starts / quits: Maybe no need because happens infrequently?
  • Added 2024-01-11: Every n seconds - it's supposed to execute at fixed intervals.
• Delay will be defined in seconds with the ability to use decimals. E.g. 1 would be one second, and 0.001 would be one millisecond. This differs from my previous comment in the quote above, but I think seconds as a unit would be better in line with the fact that the Every n seconds event uses seconds as a unit, too - although it doesn't support decimals at the moment.

Consider implementing early / late / both setting like described in the quote above.

I guess the late option could work for you @jeffeb3 ? But to make the UI simpler (and settings file, too), perhaps there would be no need for being able to select early / late / both if both would be used always? Then we'd only have a setting for the threshold duration. And, if explicit early / late modes are needed, they can be added... later. 😉

Note that the late and both modes would also need to monitor for Obsidian exiting. If Obsidian exits before the threshold duration is over, the shell command should be executed. This way no late file content modifications will go unnoticed even if the modification happens really close to user quitting Obsidian.

Need to find out if a threshold could prevent multiple events executing a shell command too close to each other

Currently, if two events (e.g. File content modified and Switching the active pane) happen at the same time (or almost same time) and both are enabled for a shell command, they are completely unaware of each other, and the shell command will be executed twice.

If the threshold works on a shell command level, it should play pretty nicely: all events that occur nearly the same time, should easily be able to see that there is a threshold situation going on.

Correct handling of {{event_*}} variables

I need to think about the following scenario:

• Note A.md is modified, causing a shell command to be executed and a threshold situation to start. The shell command uses e.g. variable {{event_file_name}}, and so text Note A.md is passed to it.
• Note B.md is modified at the same time, causing the shell command not to be re-executed (at least yet) because of the threshold.
• Note C.md is modified at the same time. The re-execution is delayed for the same reason.

When the threshold is over and the shell command gets executed again, what should {{event_file_name}} contain: Note B.md or Note C.md? Is there any way to be able to execute the shell command twice, so that both values can be submitted to the shell command via the variable?

Perhaps this would work: Execute the shell command with Note B.md value, then wait again for a threshold duration, and execute the shell command with Note C.md value? If there are a lot of files changing at the same time (e.g. due to an external application or due to Obsidian Sync), this can build up an extended execution-threshold-execution queue. Maybe it wouldn't be too bad?

[Taitava]

When should threshold counting start?

• A) Start counting from the moment a shell command starts executing.
• B) Start counting from the moment a shell command finishes executing.

If shell commands are quick to run, then the choice does not matter. But in case a shell command takes long to execute, it might make sense to stretch the threshold duration so that re-execution may happen e.g. one second (or whatever threshold duration is used) after finishing the first execution. Then you don't need to guess how long your shell command will take to execute and there's no need to use very long threshold durations "just in case".

Maybe start with B and implement A later if needed?

[Taitava]

The option B will be used, so threshold counting starts after the shell command finishes executing. If something else is needed, I can consider adding a setting later - maybe.

[channingwalton]

Hi, I came here to ask something similar, this would be really useful for me too.
By way of example, I have a script to run vale linting on the document I'm editing, writing the results to a md file that I have open in Obsidian. Running the script on every change is heavy, so I just run it every 20 seconds. It would be nice to debounce the events instead.

[Taitava]

Thank you for your message and interest 🙂. I think this could be the next feature to implement.

[Taitava]

Testers for event debouncing? 🙂

Hi everybody! I think I've got the event debouncing developed to a pretty good phase now and it will be released in version 0.22.0 some day. (Commits can be seen in issue #380). To me it looks like working ok, but I haven't done extensive testing, so I could use some help with that🙂 . I'm thinking about either doing a beta test release if there are some interested beta testers out there. (Or I might just do a normal release and do any possible changes to the behavior in later releases - this plugin is still in its 0.x era, after all).

I have written a documentation page for this. I'll publish it later here when the test is open, but if you want to read it already now, you can find it here on GitHub: https://github.com/Taitava/obsidian-shellcommands-documentation/blob/0.22.0/Events/Events%20-%20debouncing.md

I'll probably develop a few more features before making a beta (or actual) release, so this is just a pre-announcement.

Please react to this message with a 👍 if you are interested to do some beta testing. I don't have a schedule when the test will be open and when it will close, but take your time, no need to hurry when testing. If you decide to participate, all I'm asking is short feedback about the feature and documentation after you've tested it. If all is working well to your liking, just a short "all ok" comment is enough 🙂. But of course all problem reports and ideas of improvement are very valuable to this project!

I'll tag here people that have been interested in this feature in the past. I hope I'm not missing anybody. It would be great if some of you could take part in testing when I get it ready. Also, others can participate, too! 😎
@jeffeb3
@channingwalton
@HuangZhuo (discussion #284)

Thank you! 🌞

[jeffeb3]

I want to try it. I looked at the documentation. It seems reasonable. I don't know your users broadly (who does). But I wonder if maybe a better way to get people to understand how to use it is just to make a recipe for good git syncing.

It looks like I would use this mode to sync to git: https://github.com/Taitava/obsidian-shellcommands-documentation/blob/0.22.0/Events/Events%20-%20debouncing.md#mode-cooldown-first-then-execute and I can also call the command from "obsidian starts" to get any updates from my other obsidians and "obsidian quits" since the delayed action may get clipped.

I looked for a few minutes on a way to install the plugin from a specific git branch, but I use this notebook every day, so I'm not excited to break it. I didn't see a good way to update, except to a released version. So if you're confident 0.22.0 won't break anything, that would be the easiest way to update to it. Or, if there is a simple way to install a specific git branch, I can follow that.

This seems like a nice added feature. Thanks.

[Taitava]

I wonder if maybe a better way to get people to understand how to use it is just to make a recipe for good git syncing.

Thank you for the suggestion!

• I will write a git sync guide to the Example shell commands folder of the documentation, and link it to the Events - debouncing.md page mentioned above.

I can also call the command from "obsidian starts" to get any updates from my other obsidians and "obsidian quits" since the delayed action may get clipped.

Hmm, using Obsidian quits to push commits to the server might actually not execute the shell command if Obsidian happens to quit during the cooldown phase, because the deboucing also affects the Obsidian quits event, too. I think people could have different preferences on this:

• In some cases, Obsidian quits should be prevented to execute a shell command, as it would otherwise happen too soon after the command finished execution the last time.
• In other cases (like in your situation), Obsidian quits should run, to ensure that all commits are pushed to a server.

I don't know if this should be taken care of either by creating a setting that would allow Obsidian quits to bypass debouncing, or if there should be a separate setting indicating that if there are any debounced events when Obsidian quits (regardless of whether the event is enabled or disabled), then the debounced event could be exceptionally executed even though the cooldown is not yet over. I guess we all need more experience on how this debouncing currently works, and once you will get to try it, time will tell what will be the best way to improve the debouncing in this regard.

I looked for a few minutes on a way to install the plugin from a specific git branch, but I use this notebook every day, so I'm not excited to break it. I didn't see a good way to update, except to a released version. So if you're confident 0.22.0 won't break anything, that would be the easiest way to update to it. Or, if there is a simple way to install a specific git branch, I can follow that.

I think I will make a beta release, so not a final 0.22.0 release yet. When the beta is released, you will be able to install it using another plugin called BRAT (Beta Reviewers Auto-update Tester). I have an old beta test guide over here that could be used for this beta test, too. I'll go through it and see if anything needs updating when I will make an announcement of the beta test.

As always, I do recommend making sure that your backups are up-to-date before upgrading the plugin or installing a beta test version. It would be even better if you can copy your Obsidian vault to a temporary directory to use for testing, and perhaps disable or remove any possible git push commands so that the temporary copy vault cannot interfere with your remote git repository before you have tested that the new plugin version works reliably. 👍

Thank you for yourinterest to try out this feature! 🙂

[Taitava]

The 0.22.0-beta.1 test is now open

Hi @jeffeb3 , @channingwalton and @HuangZhuo (and possibly other interested testers out there)! 🙂

• Instructions for installing the beta version (please use a non-important vault for testing): Participating in beta testing #98
• If you encounter any problems:
  • For event debouncing related problems, please continue this current discussion Debounced Event Filter #319 .
  • For problems related to other features in the beta, please post in discussion 0.22.0-beta.1 #391 .
• Discussion 0.22.0-beta.1 #391 contains a short list of other features included in the beta test, but the main testable feature is this debouncing. 👍
• Debouncing related documentation: https://publish.obsidian.md/shellcommands/Events/Events+-+debouncing

Happy testing, and thank you for your interest and feedback! ❤️

[Taitava]

I just edited the debouncing documentation link to the above post.

[Taitava]

I wonder if maybe a better way to get people to understand how to use it is just to make a recipe for good git syncing.

@jeffeb3 I have now finally created an example vault for Git syncing, and a short note in the documentation, too. There's not much guidance, but inspecting the two shell commands in the vault should give users a simple starting point to build their own synchronizer. The documentation page is not in Obsidian Publish yet, but I'll put it there when I'll create the second beta test.

If there's anything to improve in the Git sync vault/example (probably there is), another discussion topic can be created for that in the Show and tell category. 🙂

[Taitava]

Should the cooldown time be prolonged if an event triggering is detected?

Currently, in SC 0.22.0-beta.1, the cooldown duration is always fixed to the user configured amount of seconds.

An example configuration:

• Cooldown duration: 5 seconds
• Debouncing mode: Cooldown first, then execute
• Enabled event: File content modified

Scenario:

• User writes content to a note file and keeps writing for about 20 seconds.
• A debounced event causes a shell command to be executed 5 seconds after the user started typing.
• So, the shell command is executed four times while the user is still typing.

If some kind of prolonging mechanism would be developed, further event triggerings during a cooldown phase would "restart" the cooldown so that the shell command would only be executed once, after the user stops typing for five seconds.

Any opinions on this? If something like this would be implemented (perhaps in a subsequent 0.22.0-beta.2 test), should it have a setting, or could it simply be a constant behavior?

[jeffeb3]

That makes a lot of sense to me. The unknown is that I don't know what kind of use cases people will come up with. You can do anything with a shell.

You essentially have the option to execute at the beginning, a cooldown, and then an option to execute again at the end.

I think it would be simpler to understand the configuration if it was just:

• One enable/disable to execute before the cooldown
• One enable/disable to execute at the end of the cooldown

If neither is checked, there is no cooldown/debounce.

I would like it if the only option for the cooldown was to keep extending it when new events triggered in the middle (in the example of writing for 20s). But you mention the git lens example. Wouldn't that need to fire more often?

If you want to support the git lens example, then I think you also need to have a choice of the type of cooldown. Maybe it is a boolean labelled "combine cooldowns"? If enabled, commands won't be executed until the cooldown has passed without any new events. If disabled, commands will be executed every time the cooldown timer expires.

The dropdown options seem a little clunky to me. This is probably how I'd fix it, but it is ok as is, and you might have a better way to fix it.

[Taitava]

I think it would be simpler to understand the configuration if it was just:

• One enable/disable to execute before the cooldown

• One enable/disable to execute at the end of the cooldown

Thank you for your suggestion. I will do the change. Yes, it might simplify the UI. I think what I was targeting with the current dropdown was to avoid cluttering the settings UI with two settings when I was able to shrink it down to one. But if two toggles are easier to understand, I'm ready to change it.

Btw, speaking of cooldown, what do you think about the term, is it good or is there a better alternative for it? When I started implementing this debouncing, I was really new to the concept and terminology (and I still am), so I just picked cooldown. I think it's more used in gaming, when e.g. a weapon has a cooldown period before it can be used again. If there's a better alternative that's easier to understand, I could change it.

I would like it if the only option for the cooldown was to keep extending it when new events triggered in the middle (in the example of writing for 20s). But you mention the git lens example. Wouldn't that need to fire more often?

True, Git lens could benefit from not extending the cooldown.

If you want to support the git lens example, then I think you also need to have a choice of the type of cooldown. Maybe it is a boolean labelled "combine cooldowns"? If enabled, commands won't be executed until the cooldown has passed without any new events. If disabled, commands will be executed every time the cooldown timer expires.

Yes, this could be a toggle, too. I guess the combining could be enabled by default? Would most commands that use debounce prefer having the combining turned on?

The dropdown options seem a little clunky to me. This is probably how I'd fix it, but it is ok as is, and you might have a better way to fix it.

Yea, let's move away from the dropdown. 👍

[Taitava]

I have now replaced the dropdown with two toggles. The code is committed, and will be availabvle in SC 0.22.0-beta.2 some day. I guess I will take some time before creating the second test version. I'll probably implement the prolonging/combining feature for that too, if it's not too much of work.

• I also need to edit the documentation to reflect the changes made to the settings, but I'll do that when creating the second beta.

Here's how the new settings now look like:

Debouncing disabled:

[Taitava]

Prolonging is implemented

@jeffeb3 The cooldown prolonging feature is now implemented and will be available in 0.22.0-beta.2 later. It's a setting and off by default.

• I need to write documentation about it.

[channingwalton]

I've been experimenting with this and it all seems good.

But I have one issue which is probably something to do with what I am trying to do …
My script runs vale for the current file being edited and writes the output to an md file in my vault. I pin that file to the left pane.
Changes trigger the script but it looks like that creates an infinite loop, where changes to the output file triggers another invocation of the script for the original file.

A more trivial script (logging the date to an external file for example), doesn't suffer this problem.

I need to experiment more, I'm not entirely sure what's happening.

[Taitava]

Yeah, the File content modified event has the nature that it can easily cause infinite execution loops.

What you can do to prevent it, is to add an if statement to your shell command that checks which file was modified, and only run vale if the modified file was not the file that receives output from vale.

I do not know vale at all (I assume it's vale.sh that I just found by googling), but I'll try to write a small example. I don't remember what shell you are using, so I'll just write it for Bash.

if [ {{event_file_name}} != "ValeOutputNote.md" ]
then
    vale MyNote.md > ValeOutputNote.md
fi

So, {{event_file_name}} contains the modified file's name that triggered the event. You can also use {{event_file_path:relative}} to be more specific, if needed.

Does this help? 🙂

• I think I'll write a similar example to the File content modified event's documentation page, too.

[channingwalton]

That did it! I was using file_path:absolute to pass to the script which isn't the same thing.

Thank you for all this work, much appreciated.

[Taitava]

Nice to hear it works now, and thank you for your feedback! 🌞

[jeffeb3]

Documentation feedback:

On this page for File Content Modified triggers, you might want to change the warnings to include using debouncing as an option.

[jeffeb3]

In the "Execute, cooldown, execute again if necessary":

If there are 10 events during the cooldown, does it execute twice (once for the first and once for the last) or 10 times (making sure to get every event in between)? It seems to infer there would be two events. But I wasn't sure.

[Taitava]

On this page for File Content Modified triggers, you might want to change the warnings to include using debouncing as an option.

True, thank you for pointing this out! 🙂

• I will write that to the documentation.

In the "Execute, cooldown, execute again if necessary":

If there are 10 events during the cooldown, does it execute twice (once for the first and once for the last) or 10 times (making sure to get every event in between)? It seems to infer there would be two events. But I wasn't sure.

It's designed to execute twice. All the other event triggerings should be discarded.

This has a potential issue if a shell command relies on any {{event_*}} file variables. If e.g. three files are modified, and a script want's to always get a modified file's name (using {{event_file_name}} for example), there would be three modifications, but only two executions, so one of the file names will never be passed to the shell command. More on this in my old comment a year ago upper in this discussion (heading Correct handling of {{event_*}} variables).

I decided to postpone solving this problem later, as I don't have a clear idea for a solution yet, and I'm willing to give users time to try out the debouncing so maybe someone will come up with an idea, if I don't figure it out myself.

[jeffeb3]

My testing:

BRAT is cool. When I first went to the new settings page, the version was the beta, but the debounce option wasn't there. I restarted obsidian and it showed up.

This was my first attempt at it. My use case is a git sync script. It does git commit --all and then pushes.

To test, I opened a terminal and ran watch -n 1 git log -n 3. That showed me the last few commits and included stuff like "30 seconds ago").

With this setup, I could type anything and immediately got a new commit (good). After 5s, I would type something else, and I did not get a commit. After a minute, I typed something and I did get a commit.

I switched the type to "Execute, cooldown, execute again if needed". I could type something, see the commit (1 second ago) and type something else. After 35s, the second commit would be made. This 35s seems repeatable. I expected that cooldown to be 5s. UPDATE: I think this might be the git push command taking 30s. I'm not sure why it is 30s or why it is so consistent, but 35s is fine with me.

My goal with this shell command is just to make sure the git server has an identical copy of what is here locally, and the local copy is exactly what is on the server. I don't imagine I will be in a situation where I switch from one local computer to another fast enough to cause a merge issue or anything. As long as the syncs are happening quickly enough for me to get synced by the time I get to the other machine, this will be fine. If it was 10 minutes, that's probably too long. But 5s or 35s is a reasonable "frame rate" for "human interface time".

I would like to make sure it gets the last update on obsidian quits. Maybe I should just copy the shell command and disable debounce on the second. It's not a huge deal (and having any debounce is a huge deal IMO). So not a deal breaker.

[jeffeb3]

If I use "Cooldown first, then execute":

• I type something, 5s later, the commit happens.
• If I type something else 5s later (presumably, git push is still cranking), it never commits the second edit.

This is definitely trickier than it looks. Since you don't know what shell command is going to be ran, you can't just pick one for the user. But I'm still not sure which one is best for me. I'm leaning towards ECEAIN.

[Taitava]

My testing:

BRAT is cool. When I first went to the new settings page, the version was the beta, but the debounce option wasn't there. I restarted obsidian and it showed up.

Ok. I guess you had SC 0.21.0 installed before using BRAT to install SC 0.22.0-beta.1 and even though the version number changed, the old plugin version was still running, maybe. But good that a restart solved it. 👍 I use BRAT very rarely, so I'm not familiar with how it deals with plugin installations when a non-beta installation is present before the beta installation. It didn't come to my mind to test that scenario when making 0.22.0-beta.1, I only tested by creating a new temporary vault and installing BRAT + 0.22.0-beta.1 from scratch.

This was my first attempt at it. My use case is a git sync script. It does git commit --all and then pushes.

To test, I opened a terminal and ran watch -n 1 git log -n 3. That showed me the last few commits and included stuff like "30 seconds ago").

Good idea to use watch to monitor the created commits in real time. 👍

With this setup, I could type anything and immediately got a new commit (good). After 5s, I would type something else, and I did not get a commit. After a minute, I typed something and I did get a commit.

Yes, Execute immediately, then cooldown discards all further events that happens during the first execution (30 seconds) and during the cooldown (5 seconds).

I switched the type to "Execute, cooldown, execute again if needed". I could type something, see the commit (1 second ago) and type something else. After 35s, the second commit would be made. This 35s seems repeatable. I expected that cooldown to be 5s. UPDATE: I think this might be the git push command taking 30s. I'm not sure why it is 30s or why it is so consistent, but 35s is fine with me.

To me too, 30 seconds feels quite a long time for git push, at least when the commits contain just trivial small text changes. I would understand it if the commits would contain e.g. images. Also strange that the 30 seconds is consistent, I'd assume there to be variation when uploading data to a server. Does it still take so long today compared to yesterday?

My goal with this shell command is just to make sure the git server has an identical copy of what is here locally, and the local copy is exactly what is on the server. I don't imagine I will be in a situation where I switch from one local computer to another fast enough to cause a merge issue or anything. As long as the syncs are happening quickly enough for me to get synced by the time I get to the other machine, this will be fine. If it was 10 minutes, that's probably too long. But 5s or 35s is a reasonable "frame rate" for "human interface time".

I agree, 35 seconds is still tolerable in this case.

I would like to make sure it gets the last update on obsidian quits. Maybe I should just copy the shell command and disable debounce on the second. It's not a huge deal (and having any debounce is a huge deal IMO). So not a deal breaker.

Yes, copying the shell command is currently the only option. For a better solution, should there be a toggle setting for every event that could be used to disable debouncing for some event(s)?

• The toggle could appear under each event, and only be visible if the event is enabled, and only if debouncing is enabled.
• The setting name could be for example Enable debouncing for this event. Or something better?
• It would be enabled by default for all events (except menus).

I know it would be yet again another new setting cluttering up the UI.

[Taitava]

If I use "Cooldown first, then execute":

• I type something, 5s later, the commit happens.

• If I type something else 5s later (presumably, git push is still cranking), it never commits the second edit.

Thank you for bringing this up. It never crossed my mind that Cooldown first, then execute can actually miss the last event, even though it's aimed to be a mode where it always executes "the last occurred event".

So, to get a clear picture of the problem, I'll break down the phases that discard events:

1. Cooldown phase 5 seconds before execution: Discard further events during this phase.
   • Discarding is expected and causes no harm, because one execution is incoming, covering every discarded event's needs.
2. Execution phase, e.g. 30 seconds: Discard further events during this phase, too. It's a two-folded problem:
   • On one hand, simultaneous execution should be avoided.
   • On the other hand, the latest event won't get attention, and in your case discarding is not desirable, as you will be missing one commit.

So, how to solve this?

• In a situation where further events occur during the phase 2 (during execution), would it be acceptable to redo cooldown+execution after the first execution finishes? I hope this is not again a situation which needs a new setting. Perhaps I'd answer yes, change the behavior this way and see what people will say.
• Currently, Execute, cooldown, execute again if needed already does that kind of chaining. You can use that mode for now to ensure you'll always get the latest change committed, but then again you might end up also having unnecessary "editing just started" commits that contain incomplete edits.

I'm leaning towards ECEAIN.

What does ECEAIN mean? 🙂

[Taitava]

@jeffeb3 I just made this change to the Execute after cooldown mode (btw the mode was renamed from Cooldown first, then execute):

In a situation where further events occur during the phase 2 (during execution), would it be acceptable to redo cooldown+execution after the first execution finishes?

So, another execution will occur, if needed. There will be no setting for this, at least that's my opinion for now. The change will be available in 0.22.0-beta.2 sometime in the future.

[Taitava]

0.22.0-beta.2 test version is now available

Summary of changes:

• Debounce mode settings fields changed - hopefully it's now clearer.
• Cooldown duration can now be prolonged.
• "Execute after cooldown" mode now starts another cooldown + execution process afterward, if needed.
• Added {{event_type}} variable. (Not related to this debouncing feature).

[Taitava]

Hi @jeffeb3, @channingwalton, and @HuangZhuo ! 🙂 If you have time to test the second beta, please let me know how the debouncing now serves your needs in its current form 👍. If there are any small or big things that could be improved, I can do some planning about what will be done for the final 0.22.0 version and what will be done later. 🌞 If this now working well enough, I can release 0.22.0 as-is.

[Taitava]

0.22.0 is now released