-
-
Notifications
You must be signed in to change notification settings - Fork 250
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make the ALL_MESSAGES command work globally #1512
base: main
Are you sure you want to change the base?
Conversation
489b5e2
to
d3297e2
Compare
Hello @zulip/server-hotkeys, @zulip/server-refactoring members, this pull request was labeled with the "area: hotkeys", "area: refactoring" labels, so you may want to check it out! |
class SearchStatus(Enum): | ||
DEFAULT = 0 | ||
FILTERED = 1 | ||
EMPTY = 2 | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a really interesting approach!
I think it would be great to include a docstring here as well, explaining this a bit?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't add any because none of the other classes in helper.py have docstrings.
What aspect do you think this could be more clear about? We could rename it too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems fair. I was just thinking it might be confusing for people looking at the code later, so a docstring would help clarify it. However, now that you mention it, it might not be necessary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good naming > docstrings/comments, but it could be helpful if the naming can't be easily improved - and it's good not to block on getting perfect names ;)
LGTM, great work @Niloth-p and interesting approach! Just a few comments for clarification. I've tested it manually, and it works well! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the very quick review, @rsashank!
class SearchStatus(Enum): | ||
DEFAULT = 0 | ||
FILTERED = 1 | ||
EMPTY = 2 | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't add any because none of the other classes in helper.py have docstrings.
What aspect do you think this could be more clear about? We could rename it too.
d3297e2
to
ac14d88
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't got very far with the review yet, but I'll post this anyways, so you can engage with it. The only edge case that I could find so far is this (maybe there are similar cases in other places):
- in the left column, view the topics of a channel (
t
) - apply a filter there (
q
+ some text +Enter
) - then press
Esc
What happens is that both the filter gets dropped and the center column switches to All Messages. I think that's too much at once. I would assume Esc
only removes the topic filter at that point (while a
, already correctly, switches to All Messages only and doesn't touch that topic filter).
You're saying in the PR description
I have assigned higher priority to use Esc for RESET_SEARCH op over the ALL_MESSAGES command, when both are possible, as it is the only key to RESET_SEARCH. And since the focus is on the current panel, it also makes more sense to use that context.
And it seems to be about that topic. I haven't investigated the code yet, but it doesn't seem to work as described in the topic search at least. Not sure if that corresponds to RESET_SEARCH
or something else.
(i've also left one other tiny comment in the code)
self.empty_search = len(users_display) == 0 | ||
self.search_status = ( | ||
SearchStatus.EMPTY if len(users_display) == 0 else SearchStatus.FILTERED | ||
) | ||
|
||
# FIXME Update log directly? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm wondering if this FIXME
is now obsolete. I'm not sure on the idea behind that comment, but going towards an Enum
seems to not allow updating log
directly anymore anyways.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not certain but imo it should be fine.
This enum merely replaces the boolean that was already being used there, so it shouldn't add any new restrictions?
I assume that the comment (added in this commit) means moving some of the logic from RightColumnView to UsersView which holds log. And this should be fine, as we already support TopicsView and StreamsView with the new enum, instead of the LeftColumnView. So, it would probably require just moving the enum to a different class.
a055908
to
1e57902
Compare
Fixed the bug. Manual Testing cases:Pressing Esc from
Maybe also the empty list functionality, since we're refactoring that. Should we be adding UI tests for these? |
The existing empty_search boolean property of views with search boxes is replaced by an enum property search_status that supports the states - DEFAULT, FILTERED and EMPTY. This allows tracking whether the results are filtered or not as well, without introducing a separate boolean property for that. Updated tests.
Added conditional checks to ensure that a search was previously performed before resetting search, using the newly added search_status.
This command worked only when a message was selected, using it as an anchor to fetch messages. Now, it has been made consistent with the other narrow commands, to work from any panel. This could not be implemented in ui.py along with other narrow commands, because of the conflict caused by the Esc key also being assigned to reset search in the side panels (GO_BACK command). When both operations, 1. reset search in the current panel view 2. narrow to all messages are possible, pressing `Esc` is set to trigger only the reset search operation and not the ALL_MESSAGES command. The next keypress of `Esc` will go to the home view once the current panel view is restored to its default state. Fixes zulip#1505.
1e57902
to
2525a79
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to me, thank you for working on this. I think this feature will improve the UI.
I can confirm the manual tests. I have added a comment about potential architecture refactoring, but I think this would be orthogonal to this PR.
Regarding UI-Tests: If it's easy to add them, I'd say yes, as this will enable said refactoring without worrying too much. But I think we don't have a good test infrastructure for testing this from the "outside perspective"? Would be curious about Neil's perspective on this.
@@ -436,7 +447,7 @@ def __init__( | |||
header=self.header_list, | |||
) | |||
self.search_lock = threading.Lock() | |||
self.empty_search = False |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's not on this PR to solve this, but it's easy to notice here: It's unfortunate that there's a lot of duplication between all the different views. A similar logic change repeated three times.
I'm currently not sure what could be a good way to refactor this. Maybe a class that knows the view state, handles the keypresses, and forwards back to the view what should happen based on some interface.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Niloth-p I left a few comments, but I need to get to bed, so will have to look again. I've not manually tested, but the behavior sounds good 👍
class SearchStatus(Enum): | ||
DEFAULT = 0 | ||
FILTERED = 1 | ||
EMPTY = 2 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The enum is an improvement overall 👍 It acknowledges that there are actually three distinct states for the search status in the code.
Re implementation in this commit structure:
- this commit tracks it, but doesn't do anything with the extra state (cf. we track empty so we can display something different)
- this commit could migrate to an enum, then extend the enum in another commit, when you need to track the other state?
- it's strange in general seeing new asserts for
FILTERED
, but fewer changes forEMPTY
, and none forDEFAULT
; doing the split as per the above bullet would make it clearer where new state tracking was added and extra asserts added, vs renaming.
For the enum element names:
DEFAULT
is OK, but in terms of a search-status, it's not as clear as it could be if that's search-on or search-off.UNFILTERED
is maybe too close toFILTERED
, but is closer to the meaning of it?EMPTY
is rather moreFILTERED_EMPTY
? We could end up in a state where it's "UNFILTERED_EMPTY" (DEFAULT_EMPTY), but I don't think the code covers that case?
Re location, helper.py is OK, though I'd prefer we reduce elements in here since 'helper' is such a generic name :)
class SearchStatus(Enum): | ||
DEFAULT = 0 | ||
FILTERED = 1 | ||
EMPTY = 2 | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good naming > docstrings/comments, but it could be helpful if the naming can't be easily improved - and it's good not to block on getting perfect names ;)
What does this PR do, and why?
The keys for 'all messages' (
a
,Esc
) did not work reliably except when a message is selected.This PR makes its behavior consistent with the other menu button narrows -
P
,#
,f
.This is implemented by first performing a refactor, to start tracking whether the list views are filtered or not.
Other approach and implementation details are part of the commit descriptions.
Several approaches were attempted before arriving at this one.
Outstanding aspect(s)
Miscellaneous reasoning details:
Esc
for RESET_SEARCH op over the ALL_MESSAGES command, when both are possible, as it is the only key to RESET_SEARCH. And since the focus is on the current panel, it also makes more sense to use that context.External discussion & connections
#zulip-terminal > Make the ALL_MESSAGES command work everywhere
How did you test this?
Self-review checklist for each commit
Changes
Before:
a
keyEsc
keyAfter:
a
keyEsc
key