added persistent timers

[basaran]

Please test and let me know how it goes. I had a conflict on my repository but they should be resolved fine.

We should now be able to set both pomodoro and break timers, and they should persist.

[olimorris]

Many thanks for this I really appreciate your efforts.

My immediate thoughts are that for someone like myself who will stick rigidly to 25/5, the initial prompt to set the timers is intrusive. I'm happy just pulling in the plugin, changing the formatting for my status bar and that's it.

I'm not sure what the best way to accommodate this is; If @pomodoro_mins is set then don't do an initial prompt, check the disk for the existence of the user txt files and prompt if they don't exist.

What do you think?

[basaran]

It should only ask (to confirm the default you have set in your timer var, or the confirm the hard coded default of "25,5") for the first time you start the timer after a new install. Consecutive timers will read from the txts.

Say, this is new install:

set -g @plugin 'basaran/tmux-pomodoro-plus'
set -g @pomodoro_start 'p'
set -g @pomodoro_cancel 'P'
set -g @pomodoro_notifications 'on'

Starting the timer will confirm 25-5 as it is the hard coded value.

Say, this is new install too but you set the variables:

set -g @plugin 'basaran/tmux-pomodoro-plus'
set -g @pomodoro_mins 30
set -g @pomodoro_break_mins 10
set -g @pomodoro_start 'p'
set -g @pomodoro_cancel 'P'
set -g @pomodoro_notifications 'on'

It will ask you to confirm the 30-10 for the first time. In the next runs the txt files will take precedence. I think it's quite uniform this way, and it might please the quick install/test users. What do you think?

[basaran]

I think we can also skip the post install confirmation if the variables were set from the config. Let me look into it.

[basaran]

well, I changed it but I think it was better before. Now, the user config takes predence. You can still set a new timer through the prompt, it will persist during the session, but if you launch new, the txt values will be ignored, as the variables take precedence and ignore the txt values.

[basaran]

okay :)

Try the alt branch on my repo. I made it so, it will not ask to confirm anything.

1. If no user vars are provided, it pulls the hardcoded defaults (25,5), and writes them.
2. If user vars are provided, then those are written to disk.
3. If you set new timers through the prompt, they take precedence over the user vars.

[basaran]

I found out about something else - remember the issue of the tick from yesterday. It is a problem with version 3.2_a-1, which is what was on installed my laptop. 3.2_a-2 on the desktop didn't have the issue that is why I have been happily patching stuff and sending PRs :)

However, not everyone has the latest greatest installed. I suppose we should to ditch the whole "persistent" command-prompt settings. I propose we keep the command-prompt option as a nicety for the user so they can set whatever they like for the current running session, and motivate the users to use the variables to make anything permanent.

[olimorris]

However, not everyone has the latest greatest installed. I suppose we should to ditch the whole "persistent" command-prompt settings. I propose we keep the command-prompt option as a nicety for the user so they can set whatever they like for the current running session, and motivate the users to use the variables to make anything permanent.

Okay, agree. It's much simpler at least. Is there anything you're proposing to merge in this pull request?

[basaran]

nope, I will send a new one later this evening

[basaran]

@olimorris

so :) it turns out tmux also provide pop-up menus? What do you think about this?

The menus take care of the input validation part as well. I don't think anyone will really need to put 21.5 minutes.

[basaran]

I think this should satisfy all requirements in the most simple way, without any compromise. We have persistent timers, pomodoro menus, and if you set the var in your config, it takes precedence over everything. Please let me know if you see any issues. I moved a few things around.

[olimorris]

Oh wow this is really slick!! 👏🏼 . Love it!!

One question...any idea what the tmux color groups are for the selection:

Mine are coming out yellow in my config. Shall test again a bit later then merge.

[olimorris]

Also, any idea what the min version of tmux is for the popups?

[basaran]

I think tmux is pulling the color from the terminal theme. I didn't see an option for "selection". In this case it was the "yellow" color in the theme. I use Alacritty, and it has an option for selectionBackground. I will test when I get online.

I checked the manual pages from a release in 2020, it has the menus. Most people should have it.

[olimorris]

Excellent. I think we can get this merged then. Thanks again for all of your hardwork. I'm super happy with the simplicity of the API and the ability to add a layer of customisation should a user need it.

[olimorris]

set-window-option -g mode-style is what I used to change it!

[basaran]

great, thank for the merge. When I have some time, I will think of a way to add an auto-start pomodoro feature. I think we can pop another menu after the break time is over and ask the user to continue or cancel or something if they had recur enabled.

Ideally, we could also have another variable to enable/disable it through the config add possibly have another step added to the current menu flow, something like "would you like to make recurring" .

But, I think we are okay for now though, I have to get back to customizing these non standard shortcuts through tmux and emacs :)