jfcherng-sublime / ST-CustomStatusMessage

This plugin sets a custom message in the status bar.
MIT License
1 stars 0 forks source link

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

Open eugenesvk opened 2 years ago

eugenesvk commented 2 years ago

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

The last check is the reason https://github.com/jfcherng-sublime/ST-CustomStatusMessage/blob/bcad7311f96174604708ed15a8595e388e9e6103/plugin/listener.py#L41

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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