FarGroup
Do not apply style attributes to empty space
Description of the new feature or improvement
Currently Underline, Overline and Strikeout attributes are applied to the whole field (e.g. full editbox width in a dialog, or full column width on the filepanel). That has little sens and looks ugly.
There should be a possibility to apply style only to the real text.
Proposed technical implementation details (optional)
No response
That has little sens
Applying these attributes to static interface elements doesn't make much sense in the first place. Why do you need that? They are mostly for dynamic color overlays, e.g. files highlighting or editor lines.
Files highlighting is exactly where I mostly see the described behavior:
I am not saying I particularly dislike it, but sometimes it is seen in dialogs (where I have hotkeys underlined) and it looks really weird:
Well, text in editbox is not static. Sample usage: underline it in red, when the entered value is not correct. But could be useful for static text too, in my opinion.
P.S. And files highlighting is not OK now. That I'd call ugly.
Ok, supposedly we can say that the highlighted areas are just "fill" and don't have any "foreground", therefore any visible foreground attributes (under/overline and strikethrough) should not apply there:
Is this what you want?
Is this what you want?
Not really. Ideally, these “blank” areas are controlled separately. Or at least each time a user specifies visual attributes like underlining, there's a choice whether to apply the attributes to the respective blank areas.
The thing is, even separating "text" and "blank" is not so trivial. Currently almost everywhere those things are formatted & aligned first and then printed in one go using the specified color. To separate, we will need to reimplement all that and output chunks one by one, switching colors in between. It's not impossible, but can be labor-intensive and error-prone.
I don't feel like adding a bunch of new colors or logic on top of that only to control blank areas separately. It might be useful occasionally, but hardly worth the effort.
labor-intensive and error-prone
And likely will affect performance I assume
Technically yes. But it's about 'printing' to a memory buffer, not to a device, so probably within the margin of error.
Ok, supposedly we can say that the highlighted areas are just "fill" and don't have any "foreground"
I'd say yes, that is exactly what I mean/want.
But when filename contains real spaces - that is different, I suppose that spaces must be under/overlined/strikedout etc.
But I'm not sure about Inverse.
But when filename contains real spaces - that is different, I suppose that spaces must be under/overlined/strikedout etc.
Exactly.
Dropping styles from all spaces would be trivial. I can add it today and it will only need 10 or so lines of code. And it would probably be way better than the current situation. But it would be incorrect and probably annoying in certain corner cases. But today. But incorrect. And the proper solution, as described above, is complex and labor-intensive, so it may require a year. Or 10 years. But proper. But 10 years.