~protesilaos/tmr

1

I can't get tmr-confirm to work?

Details
Message ID
<8735fnfuxw.fsf@protesilaos.com>
DKIM signature
missing
Download raw message
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.

-- 
Protesilaos Stavrou
https://protesilaos.com
Daniel Mendler <mail@daniel-mendler.de>
Details
Message ID
<99637f9e-3698-6a5c-07e3-ca93c724ec49@daniel-mendler.de>
In-Reply-To
<8735fnfuxw.fsf@protesilaos.com> (view parent)
DKIM signature
missing
Download raw message
> 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?

Feel free to adjust or rename the option as you see fit. As I mentioned
in the commit message, I added the option to enable better Embark
support in combination with embark--restart. Embark works better if we
don't treat single timers specially.

Try this first:

1. Set tmr-confirm=nil
2. Create two timers
3. Run tmr-cancel
3. Run embark-act, cancel first timer
4. The minibuffer will be restarted (if embark--restart is configured
for tmr-cancel). Now the first timer will be cancelled two, which is
probably undesired.

Then try this:

1. Set tmr-confirm=t
2. Create two timers
3. Run tmr-cancel
3. Run embark-act, cancel first timer
4. The minibuffer will be restarted (if embark--restart is configured
for tmr-cancel). The first timer will still be there.

Daniel
Reply to thread Export thread (mbox)