Skip to content

Conversation

@kasper93
Copy link
Member

@kasper93 kasper93 commented Jan 4, 2026

loadfile replace is not the only command that will change the current playing file and it is important to preserve watch later, when this happens.

loadfile replace is not the only command that will change the current
playing file and it is important to preserve watch later, when this
happens.
@avih
Copy link
Member

avih commented Jan 4, 2026

This is subjective and therefore not really arguable, but if I zap through a playlisy, I certainly don't want each playlist item position to get saved when i skip manually to the next item.

With a playlist, if I want to save the position, it would be only when I quit, so that next time I can continue from the same place.

Again, subjective, but that's how I feel about it.

@avih
Copy link
Member

avih commented Jan 4, 2026

loadfile replace is not the only command that will change the current playing file

The point is that replacing the current playlist can be considered as quitting, and therefore it triggers save-pos. This can be argued either way, but personally I think it's a reasonable analogy that replacing the current playlist is similar to quitting the current playlist.

I personally can't see a general usefulness in saving pos of the current file when going to the next file manually. It might be useful to some, but I'd think that most users would find it anti-useful.

The design of save-position-on-quit is to continue the next time when the current instance quits (and apparently also when it's replaced, like loadfile or loadlist). That means one logical save point per instance/playlist, not to save the position of each visited file when skipping to the next one.

@kasper93
Copy link
Member Author

kasper93 commented Jan 4, 2026

The point is that replacing the current playlist can be considered as quitting, and therefore it triggers save-pos.

It doesn't. loadlist (replace current playlist) doesn't save-pos.

The design of save-position-on-quit [...] That means one logical save point per instance/playlist, not to save the position of each visited file when skipping to the next one.

The design of save-position-on-quit is per-file and all the playlist on top is simply hacks to infer where to start. save-position-on-quit doesn't have "playlist" notion. Nor it really save-position or on-quit. This feature is glued together by sprinkling random save points in few places, but not the other.

@kasper93 kasper93 marked this pull request as draft January 4, 2026 18:08
@avih
Copy link
Member

avih commented Jan 4, 2026

save-position-on-quit doesn't have "playlist" notion.

True, hence "logical". It's logically and originally the state of the instance/playlist when one quits - if one wants to resume this instance/playlist later from where they last quit.

It did get extended over time to cover maybe other things too, and maybe it gained some inconsistencies along the way - like the fact that maybe not all playlist-replacements trigger save-pos when it's enabled, but still, essentially that is the overview and goal.

Nor it really save-position or on-quit.

Not sure what you mean by that. From a user perspective, if this option is enabled and they quit, then next time they open the same file/playlist, it would resume from the last position.

How is it not really "save position" or "on quit"?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants