Weird behaviour while filtering and aggregating

[cbr4l0k]

Hey, first of all, thanks for the merge... It's been working amazingly, and I guess it's more coherent with the design of the project. That's why I'm asking first now, before coding :D

I noticed some behavior that feels weird when I use the tool, and I don't know if it's just me thinking in a different way.

Currently, when I run blog I get all the things that I have in my queue, makes sense. But then, when I want to add a filter like 1d.. or /f, the behavior changes, because it adds the .all filter to the query (actually removes the .unread filter from the default query).

Not sure if this is intentional, but I think that it would feel more natural to add the .all after starting to filter, rather than actually losing the .unread functionality.

If I'm not wrong, it would only mean changing the read_filter from ReadFilter::Any into ReadFilter::Unread; and of course, adjusting some tests 😜

Hope you are doing great :)

[kantord]

Let me know if I understand the problem correctly:

• The default query (or default default query, we could say 😅) includes .unread
• When you use any query that does not explicitly include .unread, it starts also showing posts you've already read
• To you, this feels counter-intuitive, you would think that the default query still applies

Is that correct?

Because if so, that is intentional: basically the default query only applies when you do not specify a query. It sort of like an alias. That being said, I'm not sure if it is the best design.

I have the following assumptions that I'm fairly certain about;

• The default query is a useful feature and needed
• It should be possible to manually overwrite the default query in such a way that it no lon ger applies
• You should be able to override the default query without having to know exactly what the default query is (i. e. you don't need to manually supply a filter to undo filtering that is present in the default query)

But that still leaves the question: is the current design the best design? Or is there a more intuitive and ergonomic way to do it?

[cbr4l0k]

I think this is a problem with orthogonality: making one change shouldn't trigger unrelated changes. In this case, adding the filter /f is an action that should just move you one step away from the default behavior, but currently it moves you two steps away:

1. It aggregates by feed.
2. It drops the "unread only" constraint (adding all the read messages back in).

To solve the design dilemma of easily overriding the default without having to type out complex queries, what if we used uppercase modifiers as a shorthand for .all?

For example:

• /f or 1d.. keeps the default unread constraint (what the user expects).
• /F or 1D.. acts as the override to automatically search across all messages (read and unread).

[kantord]

I think this is a problem with orthogonality: making one change shouldn't trigger unrelated changes.

At least in my head, this is solved by this: specifying a query is the change that triggers to deactivation of the default query. 😆 But I understand that this is not necessarily intuitive. But that is the "justification" within my head. Basically, the default query is a fallback logic.

I think your suggestion makes a lot of sense, but I would probably try to think of "one single solution", not something that is specific to a specific option. One way would be to reference the default query by . or ... So if you wanted to keep the default query, but aggregate by feed, you could do blog .. /f.

But I guess this still does not solve the problem that the "magic" disappearance of the default query could be counter-intuitive.

[cbr4l0k]

Well, I guess for me anything is fine... I don't filter that often anyways. I just had to do it once, and was really confused no the way it worked... remembered a Wikipedia article I read once; and therefore, created the issue. But I would be fine closing the issue for now.