-
-
Notifications
You must be signed in to change notification settings - Fork 261
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
footlinks: Add threshold configuration for footlinks. #841
Conversation
a38e3fa
to
9ff5ab2
Compare
9ff5ab2
to
298922e
Compare
298922e
to
c9eb86f
Compare
@neiljp pr is updated, please take a look now. |
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.
@Abhirup-99 This seems to work well - and I'd forgotten how many places we use footlinks now!
Other than the inline comments, some other general thoughts:
- You have updated tests, but it would be great to see one for the new behavior, unless I've missed this being covered - preferably at least testing how the controller parameter affects the number of shown footlinks, and potentially that the new value gets passed in from the config file?
- You've removed the functionality we previously had for that config option, which we have in 0.5.2; it'd be useful to allow the old option to be used, perhaps only as an alternative, but without allowing both in the file at the same time.
- The README doesn't document the new/alternative option
- We could add a FAQ entry about enabling/disabling/maximum footlinks, particularly in terms of how the old/new option interacts?
9281799
to
77841d6
Compare
@zulipbot add "PR needs review". |
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.
@Abhirup-99 This has become quite complex for a 'good first issue', so thanks for sticking with it!
(most notably to handle the overlapping old and new config options, as well as the tests with configs)
The parameterized_zuliprc
looks to be really useful for adding other tests for our config handling later 👍
We should be able to simplify the tests later if we refactor main, which you might have mentioned in the stream?
tests/cli/test_run.py
Outdated
"notify": "enabled", | ||
"color-depth": "256" | ||
}]) | ||
def test_successful_main_function_with_config( |
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 test is with a config file but specifying the default values?
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.
Yes, just a default value check, we can remove it though. Was writing a bunch of tests, so thought one which checks the default flow would also be useful.
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 having the set of defaults passing would be a good test case, but we could integrate it with the similar pre-existing one, perhaps? I'd have to take another look.
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.
Ok sure, but I have updated it to make it more of a successful main completion with various variations of maximum-footlinks and footlinks values.
tests/cli/test_run.py
Outdated
): | ||
modified_zuliprc = parameterized_zuliprc(minimal_zuliprc, zulip_config) | ||
mocker.patch('zulipterminal.core.Controller.__init__', | ||
side_effect=SystemExit) |
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.
Does it matter that this has a side effect?
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.
Yes, without the side effect, the functions would never terminate, as it would go one with Controller
initialization.
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 we have a number of tests which might not terminate on failing; I'd like to resolve that, but doesn't the validation failure happen before the Controller init?
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 control would finish in each case whether it goes to completion with the SystemExit in Controller init or it throws errors and stops, or it stops with SystemExit in Controller init and the test fails due to the assert statements after the completion. The SystemExit are the safety nets that would ensure that in any of the above cases the control finishes.
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 have updated the logic to mock the calls now, rather than using SystemExit.
77841d6
to
8ae61f0
Compare
@zulipbot add "PR needs review". |
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.
@Abhirup-99 The parametrized_zuliprc is great 👍
To clarify what I said before, we want disabled=0 and enabled=3 for the new maximum levels (not 1000). If the user wants other values then they can use maximum-footlinks=[integer>=0]. Perhaps the maximum=3 was confused with enabled=3 in the previous version?
Regarding the refactor commit, I was referring to extracting something like exit_with_error("some text")
. This would simplify the code slightly (include some red color, exit appropriately), but also ease testing as you can
- mock it
- assert on the text passed in
- check it raises
For ensuring the Controller __init__
doesn't happen, if we mock it without a side-effect then it does nothing? We can assert that it does or doesn't get called, too, if we're supposed to exit before that point.
zulipterminal/cli/run.py
Outdated
@@ -285,6 +286,19 @@ def main(options: Optional[List[str]]=None) -> None: | |||
else: | |||
theme_to_use = zterm['theme'] | |||
|
|||
ZULIPRC_CONFIG = 'in zuliprc file' |
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'd prefer we didn't rely on testing against this - this is intended for output purposes.
Perhaps we can move the validation into parse_zuliprc
?
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.
But parse_zuliprc
is specifically for parsing the zuliprc file, rather than validation. All other validations take place in the main
function.
zulipterminal/cli/run.py
Outdated
# Random Large Figure which practically | ||
# wouldn't be there in the messages | ||
maximum_footlinks = 1000 |
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 should be 3; see my general feedback.
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.
Ahem. After running with the non-PR dev version quite a bit, I see lots of footlinks in some cases, so 1000 seems like a reasonable limit after all. Ideally we wouldn't use a fixed high number but something more programmatic, eg rather than comparing x to 1000 in a conditional we could wrap it and have a bool be True or False in this case, and dependent on the number otherwise.
zulipterminal/cli/run.py
Outdated
if zterm['footlinks'][1] == ZULIPRC_CONFIG: | ||
print(" footlinks setting '{}' specified {}." | ||
.format(*zterm['footlinks'])) | ||
else: | ||
print(" maximum footlinks setting '{}' specified {}." | ||
.format(*zterm['maximum-footlinks'])) |
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.
We output this as just a maximum value in the about popup; we should make them consistent.
We could output the maximum and append an element to the last part of the zterm tuple to indicate it came from the footlinks option?
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.
That could be done, but then it would force another if clause during the traversing of zterm, and again another to check the length of the tuple during printing. Wouldn't a bit of hard-coded values and an if-else during printing be better than that approach?
495f20c
to
e16e1f1
Compare
@zulipbot add "PR needs review". |
@zulipbot remove "PR needs update" |
b7cd789
to
9e8e23a
Compare
9e3fcea
to
94b57ec
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.
@Abhirup-99 This is looking really ready :)
These should all be fairly straightforward changes, but let me know if not 👍
6e8f299
to
50c9e8e
Compare
@zulipbot add "PR needs review". |
@zulipbot remove "PR needs update" |
50c9e8e
to
35bb784
Compare
This enables the user to configure the maximum footlinks in zuliprc. The change is backward compatible with footlinks introduced in 0.5.2.README updated. Fixes zulip#773.
35bb784
to
ec69179
Compare
@Abhirup-99 Thanks for your extended work on this - I've just merged this manually as 0eeb6ea 🎉 As we discussed this does slightly change the previous meaning/behavior, which will need addressing in the release notes, or we could adjust later to be more backwards compatible. I adjusted the general layout in various places including in the tests and made a small simplification, removed some apparent holdover code from the previous commit we already merged and clarified the commit text. I'd suggest looking into |
This enables user to configure footlinks threshold settings
using footlinks_threshold in zuliprc, retiring the previous
footlinks. Tests have been updated to reflect the change.
Fixes #773.