Apologies for taking so long to get to this. Busy times.

I have a number of comments:

First, the mode only really works with mpv at the moment. If I skip
around in VLC then it won't track to the skipped position. I would
suggest either making it support VLC as well, or blocking it from
working in anything but mpv with a friendly message (or a similar
communicative option). Otherwise, people who only use VLC (or another
player) will not understand why the feature is broken. If a feature only
works with certain backends, we need to be communicative with users of
the other backends.

Second, the use of `emms-playing-time-resume-from-last-played' is
non-standard. The user should expect that when they set
`emms-playing-time-resume-from-last-played' then it will start working,
and when they set it to nil then it will stop _immediately_. But in this
case the variable instead controls the insertion of a hook on loading
the mode. I think that the hook can be there all of the time, and a
variable such as `emms-playing-time-resume-p' will control if
`emms-playing-time-maybe-seek-to-last-played' is called at runtime. This
way a user can even change the value of `emms-playing-time-resume-p'
locally (as in a lamba/let).

Third, I was wondering if it makes sense to add two variables that can
optionally check if the track is within a set number of seconds from the
beginning or a set number of seconds from the end, and if so "snap" to
the beginning or end, respectively. This would prevent a situation when
someone stops a track a few seconds from the end, and then when they
play the track again it will just jump to those ending
seconds. Similarly, if a user starts a track and stops it a second or
two in because of an interruption, perhaps they would appreciate that it
"snaps" to the start instead of those two seconds or so in.

-- 
   "Cut your own wood and it will warm you twice"

Reply via email to