Alpha-channel and FCF_INHERIT_STYLE should be applied to filepanel selection and cursor.
I think I've got it right, but better check thoroughly.
Testing Style: [x] Inherit on file panel.
Normal textset to Italic:- [x]
Normal cursorset to Inherit ==> Italic - [ ]
Selected textset to Inherit and ==> not Italic. - [x] Files highlighting
group set Normal file namestyle to Inherit ==> Italic
- [x]
- Files highlighting
+Dgroup setNormal file namestyle to Italic- [ ] The same group
Selected file namestyle to Inherit ==> not Italic. - [ ]
Selected textset to Inherit and ==> not Italic.
- [ ] The same group
Well, you initially asked for cursor, so selection is not covered. However, why not.
Ok, how should it work?
Assuming that cursor lies on top of text, e.g.
cursor
text
- cursor inherits text.
Assuming that selection lies on top of text, e.g.
selection
text
- selection inherits text.
Now, what is "selected cursor"? Is it cursor that lies on top of selection that lies on top of text, e.g.
cursor
selection
text
or something else?
- Should selected cursor inherit cursor, then selection, then text or something else?
Should selected cursor inherit cursor, then selection, then text
I suppose yes, exactly so.
But than where is "Files highlighting" in that hierarchy?
cursor
selection
highlight
text
Or?...
Don't forget that there's no "highlight". There are "highlight", "highlight selected", "highlight cursor", "highlight selected cursor". Although the last 3 are mostly useless and probably not used by anyone.
Currently highlight does not follow this logic and inherits from previous groups component-wise if "continue processing" is on. Then the final result inherits panel colors. Somehow. I didn't check how exactly.
More in 6440.
There are "highlight", "highlight selected", "highlight cursor", "highlight selected cursor". Although the last 3 are mostly useless and probably not used by anyone.
They are (supplementary) part of the Attribution highlighting concept, and I use all three on a daily basis. E.g. you can see my selection highlighting here (and, in case you're curious, selected cursor is bright green and regular cursor is bright blue).
@HamRusTal
They are (supplementary) part of the Attribution highlighting concept, and I use all three on a daily basis.
I suppose that they are redundant after we have sorted all inheritance issues out.
More in 6440.
Still unable to get it work with highlighting.
Selection and cursor over highlighted item do not inherit it's style
@johnd0e please try to describe how exactly you expect it to work in the most complex case, e.g. multiple highlight groups with "continue processing" and color / style inheritance.
Normal text- Highlighting
Normal file name. E.g. these, all with inheritance and continue processing:- [+D] Color, Style: Italic
- [+D] Marking: \
- [+L] Style: Underline
Selected text- Highlighting
Selected file name. In my case nothing is set explicitly, only Default / unset / Inherit. Normal cursor- Highlighting
File name under cursorDefault Selected cursor- Highlighting
Selected file name under cursorDefault
Highlighting works the same as before, so I expect nothing new here.
The new thing is hierarchy:
- Normal + Highlighting
- Selected + Highlighting [optional]
- Cursor + Highlighting [optional]
- Selected Cursor + Highlighting [optional]
I'm not sure if we still need that [optional] highlighting settings. Considering all the possibilities, I think it's too granular. I believe it's safe to just drop it (?) @HamRusTal However, I still find that normal/selected/cursor/selected preview useful.
If I'm still able to assign highlighting as expressively as before, I'm fine. By “as before”, I mean distinct highlighting (FG/BG color, styles, mark char, etc) for regular (normal), selected, current (under cursor), and selected current with regard to file name (glob), size, attributes, times, and number of hard links. If needed, I can explain why, but in general, Attribution is the answer.
If the highlighting settings get revamped, then it would be user-friendly to have proper automatic migration of settings. Failing to do that, we'll get numerous complaints on the forum over indefinite time span.
If I'm still able to assign highlighting as expressively as before
That is the question
Ok next attempt, 6441.
If the highlighting settings get revamped
There are no such plans.
If I'm still able to assign highlighting as expressively as before
That is the question
That is not the question. This issue is about inheritance of specific items, which makes sense only when their colors are (semi-)transparent or style inheritance is enabled, everything else stays the same.
Ok next attempt, 6441.
Working like a charm, thanks!
This issue is about inheritance of specific items, which makes sense only when their colors are (semi-)transparent or style inheritance is enabled, everything else stays the same.
Correct. So it is offtopic, but still interesting: do we really need 4 color settings for highlighting?
@alabuzhev There is a good question in https://t.me/FarManager/18518
@johnd0e
- As explained elsewhere, currently Alpha applies selectively where it makes sense, or, in other words, where a notion of a "previous color in Z-order" exists. Otherwise it's ignored. The preview shows it as black because it's a bug. Fixed.
- Because it inherits blue, as explained above.
-
Is it possible then to disable fields, where Alpha is not applicable?
-
I expect that black background of selection is fixed as well
- Which fields? The leftmost cells (AA) in the color code? We can't disable a part of an edit control, and I don't think that monitoring the input and reverting alpha to FF programmatically would make much sense.
- What black background?
-
Perhaps it is possible to achieve with edit mask.
-
If Normal text background is fully transparent (00), and Selected is not set (thus should be inherited), then selected files get black background. Not in the preview, but on real file panel.
selected files get black background
6447