1. I don't see any reason to get rid of them. But they do primarily exist simply because that was what was there before. The filters factories that I created later on took into consideration that they could be combined with logic and other filters. Initially I made one for versions of all the filters that the browser had so I could preserve it's API.
2. I did not build an autoload system for the filters that are kept. Their names are generated and rather verbose. And just because you kept a filter doesn't mean you want to load it automatically next time. I didn't make assumptions about what people might want to do. I personally found that I rarely used kept filters directly. What I do is I look through my kept filters and copy the ones I want into my config. I fix their names and sometimes modify them. They are good way to understand how filters work as well. I don't really keep that many anymore. I can write them directly without much effort. 3. Yes of course. Https://codeberg.org/ZeniesQis/zis-hydras.git I just pushed them as part of my emacs configuration cleanup. I mostly only use a couple of the EMMS ones. Have fun! Goodnight! Erica (Zenie) Sent from Proton Mail for Android. -------- Original Message -------- On Friday, 11/28/25 at 22:40 Igor Sosa Mayor <[email protected]> wrote: Hi Erica, thanks for your reply and your elaborate explanation. I have at least three questions: 1. when you say > The filter system was just beginning to take shape and backward compatible was a big concern. > Now, there is no longer a good reason to have both. what are you exactly proposing? Just to have the since-filter and remove the not-filter? 2. when you say > Also the filters you build on the filter stack can be saved, > and you can copy them into your config, give them a name and just have them as choices in the system. They are human readable data. How does the save mechanism really work? If a) I make a filter, b) execute emms-filters-keep, the filter is saved to the file I have configured with emms-filters-multi-filter-save-file. But: If I restart emacs, this file is never read again (I do not see any code for this in emms-filters.el). How is this supposed to work? Could you maybe give us an example? 3. could you share your hydra please? Many thanks in advance. On 11/28/25 18:54, Erica Qi wrote: > Hello everyone, > > I thought I should show the fix and explain a little bit about the filter > system. These were two of the first filters I replaced from the old browser > filters. > > I replaced them purely to be backwards compatible in the same choices. But > really, the not filter is unnecessary. > So much so that I forget to put the 'not'. > > A 'push-not' of the played-within filter does the same thing. > > So here is the fix, and a short explanation of using the > Interactive filter stack. > > --- > > The fix is the 'not' in front of the (funcall .... > > Filters are simple tests which take an Emms track. They get the values they > care about and test them how they want. > And return true or false. > > To get a filter that is the not of another filter we can use the original > filter and put a 'not' around it. > > (defun emms-filters-make-filter-not-played-within (days) > "Make a not played since DAYS filter." > (lambda (track) > (not (funcall (emms-filters-make-filter-played-within days) > track)))) > > (emms-filters-register-filter-factory "Not played since" > 'emms-filters-make-filter-not-played-within > '(("Days: " (:number . nil)))) > > Historically, the within and not-within were 2 of the first filters I created > because the browser originally had them. > The filter system was just beginning to take shape and backward compatible > was a big concern. > Now, there is no longer a good reason to have both. > > Another way to filter 'not within is with the interactive filter stack. Push > a 'Not' filter of 'played-since' onto the filter stack with 'push-not'. > That's a not played within filter. > You can save it, and put the definition in your config. > It's just data. > > The filter stack is the way to filter your tracks. > > Pushes can be 'regular', 'and', 'or' and 'not'. > > The filter stack is a stack of filter lists. > Each list is a list of 'or' filters. > Between the lists you can think of them as 'and' > > So think of an 'and list' of 'or's. > > A 'not' is a special way to start a new 'and' that indicates that it is 'not' > this or this or this. > > There are actually 4 ways to push a filter onto the filter stack. There is > the regular push, push-and, push-or, push-not. > > The 'regular' push starts a new list of lists. You can have more than one on > the stack. That means you can be searching and decide to 'start over' with > some quick search. When you are done with that you can 'pop' back down to > where you were and resume where you left off. > > push-and adds a new list with a filter in it to whatever is going on. > Push-and is the same as push if it's the first one. > > push-or adds a new filter to the current 'and' list. > push-not starts a new 'and' list flagged as 'not'. > > Popping goes back to the previous way things were. > Smashing will clear the stack to a new choice. > Squashing reduces the stack to have only the top thing. > Swap will swap the top thing with the one below it. > > You can also swap and pop, so swap the last thing with the thing before it > and pop it off. If you swap-pop enough you have a squash. > > If you happen to make a 'new' filter as you go, that filter will show up in > its factory's menu so you don't need to create it again until the next > session. > > Also the filters you build on the filter stack can be saved, > and you can copy them into your config, give them a name and just have them > as choices in the system. They are human readable data. > > Don't forget you can also push and pop your results on the > cache-stack. If you have a huge library this can speed things up quite a > bit. The cache is the data, the filter is a 'view' of the data. You can push > to the cache stack and keep going or smash your filter and continue like that. > > Caches can also be stashed for later in the session. Once stashed you can > push them back on your cache stack whenever you want. They are like a > snaposhot database of your results. > > I hope that all makes sense. > I don't know why I didn't think to just say do a 'push-not'. > > Also, I do have a nice hydra that allows all this to be done interactively so > you can see the two stacks change as you push and pop filters. > > I'm not sure transient is capable of the same thing. I haven't seen one that > shows much in the way of formatted and changing data. I'm working on a > filter-view-mode for it. But it's not ready yet. I'll post a link to my > hydra. > > Have a nice day or evening. It's evening here. > > Erica > > Sent from Proton Mail for Android. > > -------- Original Message -------- > On Tuesday, 11/25/25 at 08:53 Igor Sosa Mayor <[email protected]> > wrote: > Hi emms-users, > > I have already a small problem. In this case with the filter factory > defined as "Not played since". If I filter my tracks with "Played since" > and "Not played since" 30 days, I get exactly the same results... Either > it is a problem with the way my tracks are storing the time or a problem > with the code. > > More precisely my question is: is this code working at expected? > > (defun emms-filters-make-filter-not-played-within (days) > "Make a not played since DAYS filter." > (lambda (track) > (funcall (emms-filters-make-filter-played-within days) track))) > > Thanks in advance! > > Best, > > >
