Re-sending as the ML did not allow images before. Changed its settings.
> From: Daniel Mendler <mail@daniel-mendler.de>
> Date: Wed, 29 Jun 2022 18:41:49 +0200
>
>> I am now taking a closer look at tmr-confirm in order to document it in
>> the README.org. It is read by tmr--read-timer which, in turn, is at the
>> heart of all the commands we have.
>>
>> I thought that tmr-confirm=t would be translated in the doc string as
>> "When non-nil, operations on timers require confirmation." By
>> implication, a nil value should be sort of an "expert mode" where no
>> confirmation is asked, right?
>>
>> My confusion is that I cannot get any prompt to confirm an action.
>> Everything seems to be in "expert mode" regardless of tmr-confirm.
>>
>> Maybe I accidentally evaluated older code or missed something, so
>> apologies in advance.
>
> The difference is only observable for a single timer. We should maybe
> call this option tmr-confirm-single instead. If there is only a single
> timer and if tmr-confirm=nil, then tmr-cancel/clone will cancel/clone
> this timer directly (without an additional selection process). If you
> have more than one timer you always have to select/confirm via
> completing-read anyway. Maybe the word confirm was also not the best
> choice, since it just means that we always go through selection. It
> eliminates the special treatment for a single timer. Does this make sense?
Okay, now I get it. I misunderstood what it was supposed to do.
Calling it tmr-confirm-single sounds better in that regard. The doc
string can then explain what this is all about.
> Try this first: [...]
I could not get it to work because I realised that I needed this:
(setq embark-quit-after-action nil)
The default value is t, which prevents the embark--restart in the
embark-post-action-hooks from doing its job.
Now that I got embark to work, the minibuffer remains open, but the list
of candidates is not updated. I still get the timer I just cancelled.
See attached screenshot.
--
Protesilaos Stavrou
https://protesilaos.com