-
Notifications
You must be signed in to change notification settings - Fork 3
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
Panelization is not kept while switching panel listing mode #3810
Comments
Branch: 3810_keep_panelization |
|
Replying to mooffie:
|
Let me sum up my comments (as I get the feeling I added too much noise):
Unless you want listing_cmd() to reset the panelization when a listing is already shown, you just need to delete the "else" section in switch_to_listing(). (That's comment:3)
Otherwise your patch is basically fine. (That's comment:2)
(BTW, set_basic_panel_listing_to() is used only once. You may want to get rid of it. I started to write a patch to do this but I gave up because matters of style are highly subjective and I figured you'd prefer your own style.) |
Replying to mooffie:
I'm working on this branch right now. |
Done. |
Nice! Some comments:
I'll later give the code another look, but overall it seems ok. |
Replying to mooffie:
I propose to use "format" instead of "mode".
I think this file just should be removed. I hope, nobody is interested in keybinding names at 4.7.x time.
Sure.
I think comment should be as short as possible. Sapienti sat. |
Replying to andrew_b:
Pick any of the two. I lean towards "mode", because it's consistent with the interface, but I don't mind "format". It's for you to decide.
(I remeber a user asking on the mailing list if it's possible to switch between two (or more) custom user formats. This might be an argument againt "format", as it could give the impression of the functionality that user had in mind.)
For the record: my problem with the current comment is not its shortness. Let's inspect it:
These two words describe what the code does. This "what" happens to be obvious, and so these words serve no real purpose. A programmer reading the code would like to know why we reset the penalization. This reset is only needed when switch_to_listing() was a no-op (in my words: "If a listing was already showing"; here, I shortened that phrase by 5 words already... and the "we" can be removed too ;-).
That's not true: the code doesn't change the listing mode.
Again: I won't mind if you remove the comment completely. I do remember, though, reading that code a couple of weeks ago (I was aware of the bug and worked on a patch) and not readily understanding its purpose. But that was with the old version; perhaps this new one is easier to figure out. |
Replying to mooffie:
|
I believe we also need to rename "PanelListingChange" to "Panel{Change,Setup}Listing{Format,}". The verb should come first (as we did in "CycleListingFormat").
(My preference is for "Setup" over "Change", as the latter isn't as definite. But then one could ask why we have "OptionsXYZ" commands there instead of "SetupXYZ".)
Except for this the code looks fine to me (I tested it), so I'm voting for it.
(BTW: IMHO, the comment in "(listing_cmd): reset panel filter" should go because it doesn't explain the difficulty in the code (and there is a difficulty there). The comment just repeats what we're doing ("we reset the ...") instead of explaining why we're doing it.) |
I added two fixup commits for review. |
Replying to andrew_b:
|
Replying to mooffie:
Yes. Sorry. Done. |
All looks fine to me! |
|
Merged to master: [ed1ed00].
|
|
Important
This issue was migrated from Trac:
andrew_b
(@aborodin)How to reproduce.
Result: switch from panelization to normal file listing mode.
Expected result: keep panelization result.
The text was updated successfully, but these errors were encountered: