Skip to content
This repository has been archived by the owner on Mar 12, 2023. It is now read-only.

Plugin is disabled on multiselection even for indicators that don't depend on a selection #2

Open
eugenesvk opened this issue Oct 19, 2022 · 3 comments

Comments

@eugenesvk
Copy link

Encoding/line ending etc. should still be shown even when there are multiple selections

The last check is the reason

return bool(get_plugin_setting("enabled") and is_regular_view(view) and len(view.sel()) == 1)

Think it'd be better to add that check the indicators that should fail on multiselection and then instead of erasing the whole message just make those indicators ""?

@jfcherng
Copy link
Member

jfcherng commented Oct 19, 2022

This seems to be a difficult issue. What should be shown if I have a template "{line_endings}, Ln {row} Col {col}"? I would say only "{line_endings}" but that's not possible.

@jfcherng
Copy link
Member

jfcherng commented Oct 19, 2022

the only way I can figure out is add another setting like template_multi_selection. But again, what should happen if I still use "{line_endings}, Ln {row} Col {col}" as template_multi_selection?


I feel there should be multiple set_status with different keys for different situations but I don't have a overview now.

@eugenesvk
Copy link
Author

the only way I can figure out is add another setting like template_multi_selection. But again, what should happen if I still use "{line_endings}, Ln {row} Col {col}" as template_multi_selection?

You could ask the user to enter a dictionary of separate segments, e.g.,

"{line_endings}", ← segment 1
", ",             ← segment 2 (custom user separator, might need special handling is seg3 is hidden)
"Ln {row} Col {col}"]  ← segment 3

And then if the variable inside that segment is invalid/doesn't make sense, simply don't show the whole segment, including the text within it

I feel there should be multiple set_status with different keys for different situations but I don't have a overview now.

Yeah, the indicators could be grouped by window / buffer / caret? And then each group has its own _is_enabled and the rest? Similarly to how you split the update into _update_variables_on_view_activated and _update_variables_on_selection_changed

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants