The meaning of FCF_INHERIT_STYLE

[johnd0e]

According description in #917

"Наследовать" расширенные атрибуты;

But I see that it is not only about "extended attributes", it also affects FG (and BG?) colors.
So...

May be there should be 3 separate flags instead?

P.S.
This issue reminds me #912

[alabuzhev]

it also affects BG and FG colors

Where?

FarManager/far/colormix.cpp

Lines 376 to 383 in f4cef8e

	if (Top.Flags & FCF_INHERIT_STYLE)
	{
	constexpr auto StyleMaskWithoutUnderline = FCF_STYLE_MASK & ~FCF_FG_UNDERLINE_MASK;
	flags::set(Result.Flags, Top.Flags & StyleMaskWithoutUnderline);
	if (const auto TopUnderline = Top.GetUnderline(); TopUnderline != UNDERLINE_NONE)
	Result.SetUnderline(TopUnderline);
	}

[johnd0e]

I can't comment on the code itself, but in practice, I observe the following:

https://github.com/shmuz/far_plugins/blob/master/plugins/luafar4editor/scripts/examples/cross.lua

Here, the colors of the cross are set as opaque. Nevertheless, when moving the
cross over text colored by Colorer, I see that the resulting foreground (FG)
color is not uniform (as one might expect), but is overlaid on the Colorer
coloring.

If you remove FCF_INHERIT_STYLE from the flags, the cross is drawn clearly
over the text and is independent of the underlying coloring.

[alabuzhev]

@johnd0e if you want to report a bug, please do so properly.
Including, but not limited to:

• what dependencies to install
• what configuration changes are needed
• what text is being highlighted by colorer, using what syntax and what schema
• what exactly you expect and what actually happens. Screenshots are welcome too.

[johnd0e]

I wasn't going to report a bug, as I initially assumed the observed behavior
was intentional.

• Reproduction requires the WT or openconsole.exe, the latest version of Far, along with the Colorer and
  LuaMacro plugins, and the installed script
  https://github.com/shmuz/far_plugins/blob/master/plugins/luafar4editor/scripts/examples/cross.lua with the following 3 lines added:

  Event { group="EditorEvent"; action=ProcessEditorEvent; }
  Event { group="EditorInput"; action=ProcessEditorInput; }
  Event { group="ExitFAR"; action=ExitScript; }

• In Interface Settings, activate [x] Use Virtual Terminal for rendering.
  In Colorer settings, disable the cross, enable TrueMod, and select any style (I
  use Navy Blue a'la NC).
• Open any file and place the cursor on a line where different colors appear,
  for example, the first line of File_id.diz.
• Press ScrollLock so that the cross.lua script draws the cross.

My expectation is that the FG color will be the same throughout the entire
line, because it is set as opaque (see cross.lua)

In reality, the colors will differ depending on what color was under the cross.

If TrueMod is disabled, the described effect does not occur.

[shmuz]

@johnd0e Probably you meant luafar4editor rather than LuaMacro.

[johnd0e]

Thank you @shmuz!

Forgot to mention, that it is necessary to add these lines to the end of file, to be able to load it in LuaMacro:

Event { group="EditorEvent"; action=ProcessEditorEvent; }
Event { group="EditorInput"; action=ProcessEditorInput; }
Event { group="ExitFAR"; action=ExitScript; }

[shmuz]

it is necessary to add these lines to the end of file, to be able to load it in LuaMacro:

LuaMacro is not needed, it may even be not loaded.
What is needed is renaming luafar4editor\_usermenu.example.lua to _usermenu.lua.

[shmuz]

@alabuzhev The plugin is located here: https://github.com/shmuz/far_plugins/releases/tag/lf4ed-3.10.2

[johnd0e]

It is not important where we run this script, both luafar4editor and luamacro can do that.
But luamacro is out of the box.

[shmuz]

@johnd0e OK, I didn't try it the way you described and didn't know that you were running it that way.

[alabuzhev]

@johnd0e, I'll try to guess.

Do you see the left one?

If so, the right one should make it obvious what is going on.

But just in case:

• Colorer marks certain tokens (e.g. numbers) as bold, for colorer reasons.
• The cross inherits the boldness and shows it to you.
• Some terminals render bold as bright, supposedly for silly historic reasons, e.g. ancient text mode terminals worked like that or something.
• In some terminals it is configurable (e.g. Intense Text Style setting in WT), in some it is not (e.g. conhost/OpenConsole).
• Microsoft guys probably have a task somewhere to make it configurable in conhost/OpenConsole as well.
  If not - they definitely should.
  Please feel free to look for it and vote/comment or create one if needed.

[johnd0e]

Thank you for explanation!

[alabuzhev]

As discussed elsewhere, currently WT and conhost/openconsole always render bold as bold in 256 and true color palettes.
WT does have a switch to do so in 16 colors as well, but conhost/openconsole does not.

I have just realized that technically this allows us to always show bold as bold in 16 colors, even if the switch is off or does not exist:

1. We can find out the exact RGB value of each of the 16 colors (we already do that for shadows)
2. We can then replace the 0-F color indices with these specific RGB values before sending the text to the console.

From the user's point of view it should look the same, but the terminal will have no other option but to use bold.