Re: [Patch] Add: warning when no tag writer exists

[Grant Shoshin Shangreaux]

>> Now that I think of it, I totally agree.
>
>> Perhaps it would be better to enumerate which types of tracks allow
>> editing of metadata?
>
> Your code already does that by looking up an association in
> `emms-tag-editor-tagfile-functions'.

I misspoke here. I meant which types of tracks allow editing the data in
the cache-db. Which brins us to:

> We are effectively switching around the concept: we are making a cache
> editor that also writes tags, as opposed to a tag editor that saves some
> of its data in a cache.

Checking whether a track is a file or not came from my desire not to
impact existing behavior of the track editor. The way it is currently
written inadvertently switches around the concept. As far as I know,
users can currently edit metadata for any track, and it will happily
save that data to the cache. The browser displays that data back to the
user, which is what led to my confusion in the first place when the Opus
files I had attempted to tag were unchanged.

Do you feel its worthwhile to refactor the code to reflect the concept
here? Rather than emms-tag-editor, we would have emms-track-editor that
would essentially do the same thing, communicating to the user more
clearly when they are editing actual tags vs cache data.

> We'll need to communicate this to the user so that there are no
> surprises. I can think of three cases:
>
> First, if there is an association in `emms-tag-editor-tagfile-functions'
> then we edit the file, and check that it has been edited.
>
> Second, if it is a file, but with no association in
> `emms-tag-editor-tagfile-functions', then there should be a message
> along the lines of: "the file doesn't have a metadata editor, changes
> will be saved only in the Emms cache and not in the file itself"
>
> Third, if it is not a file then a similar message is displayed, such as
> "saving changes to the Emms cache" or "editing the Emms cache."
>
> One place we could put such messages, perhaps in an eye-catching
> font-lock, is at the top of the "*EMMS-TAGS*" buffer.

These are great suggetions. Thank you for making it so clear. I will
continue with the work on this patch to effectively capture these cases
(as well as the remote file case you mentioned). Regarding patches,
would it be best if I kept changes in a single commit and produced a new
patch? Please let me know if there's a preference for how to send
updates.

Thank you!

Grant