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,
