Grant Shoshin Shangreaux <[email protected]> writes: > Yoni Rabkin writes: > >> The emms-tracktag should be changed to emms-info-tracktag in order to be >> consistent with the rest of the info methods. > > the tracktag tool is specifically for writing tags. there's a separate > utility for reading info, but i hadn't planned on integrating that at > this time. audiotools does look fairly handy, so if there were desire to > enhance EMMS's features with some of its utilities, that is something I > could certainly work on. For now, I really just wanted an Opus capable > tagger. Its unfortunate there didn't seem to be a good stand alone > option for it (opustools unfortunately doesn't include a tagger, unless > you want to re-encode the file).
That puts us in a dilemma since other info backends, such as exiftool, can be used to write as well. So we either name everything which calls a backend to work with info, reading or writing, in the -info- namespace, or we split read and writing into separate namespaces. Unless people have a strong opinion either way, I'm going to ask that reading info be in the -info- namespace and writing in the -tag- namespace. Which would require you to change emms-tracktag.el and its various code references to emms-tag-tracktag. This way we could later on write emms-tag-exiftool.el and others like it, with emms-tag-editor being the "frontend" to these. > that being said, there's not much to the integration at this point, it > could be brought into the emms-tag-editor module, rather than being on > its own. It should have its own file. >> I think that adding ert testing is fine, but I would only add it after >> the code has stabilized somewhat. Since the unit tests are very short, >> they can be kept in the same file as the tracktag code for now. > > sounds good. i've been trained to write tests at work all the time, so > its more of a development habit of mine. i do think it makes sense wait > until this code/feature has stabilized. The difference is between writing tests and committing them. I think that they should be committed to the codebase at a later time. >>> By the way, I used some real metadata from tracks I have, but afaik that >>> is not copyrighted data. If we'd prefer to keep it out of the code base, >>> I can replace it. >> >> Indeed, we should not have real metadata in the codebase since this is >> what an automated search 'bot would latch onto and potentially cause >> trouble. > > i just remove the tests from the commit at this point. > >> Based on the volume of code you are adding, I would recommend that you >> open a Savannah account (if you don't have one already) and that I give >> you write access to the repo. At that point you can do all of your work >> in a remote branch. >> >> In a remote branch you can break anything and everything with impunity, >> and everyone else can easily grab a copy for testing. We recently did >> this with Petteri's info-native branch and it worked well. > > done! thank you! Welcome aboard! -- "Cut your own wood and it will warm you twice"
