New setting: draw-bold-text-with-bright-colors

[markuspeloquin]

The new setting is draw-bold-text-with-bright-colors, and it is disabled by default, as it always should have been. This is also the name Alacritty uses. Similarly, it is disabled by default.

Should resolve #595, #1112

[markuspeloquin]

Disclaimer: I do not know how to get this on my Android. I was merely able to build it cleanly after updating minSdkVersion to 24. I tried ./gradlew assemble on the APK but it wouldn't install...

[agnostic-apollo]

but it wouldn't install...

Signing keys.

https://github.com/termux/termux-app#installation

Will look into testing pull later. Pull has conflicts with my local work and will require moving stuff. The changes seem good. Will have to see if changing default to false is the right move. Thanks

[thunder-coding]

Will have to see if changing default to false is the right move.

I would prefer this option being false by default due to the following reasons:

1. It is a behaviour exhibited by old terminal emulators not supporting bold characters. And Termux supports printing bold characters
2. It deviates from existent behaviour.

[agnostic-apollo]

I'll have to read up on this.

It deviates from existent behaviour.

Existent behavior for termux? New property already defaults to false and will change termux behavior.

termux-app/termux-shared/src/main/java/com/termux/shared/termux/settings/properties/TermuxPropertyConstants.java

Lines 442 to 458 in b1b36a3

	/** Defines the set for keys loaded by termux that have default boolean behaviour with false as default.
	* "true" -> true
	* "false" -> false
	* default: false
	*/
	public static final Set<String> TERMUX_DEFAULT_FALSE_BOOLEAN_BEHAVIOUR_PROPERTIES_LIST = new HashSet<>(Arrays.asList(
	KEY_DISABLE_FILE_SHARE_RECEIVER,
	KEY_DISABLE_FILE_VIEW_RECEIVER,
	KEY_DISABLE_HARDWARE_KEYBOARD_SHORTCUTS,
	KEY_DISABLE_TERMINAL_SESSION_CHANGE_TOAST,
	KEY_ENFORCE_CHAR_BASED_INPUT,
	KEY_HIDE_SOFT_KEYBOARD_ON_STARTUP,
	KEY_TERMINAL_ONCLICK_URL_OPEN,
	KEY_USE_CTRL_SPACE_WORKAROUND,
	KEY_USE_FULLSCREEN,
	KEY_USE_FULLSCREEN_WORKAROUND,
	KEY_DRAW_BOLD_TEXT_WITH_BRIGHT_COLORS,

[thunder-coding]

Existent behavior for termux? New property already defaults to false and will change termux behavior.

Sorry, my bad. I assumed that Termux didn't force bold text to print with bright colors. Had never ran over this issue myself.

I do believe changing the default behaviour would be nice thing to do. Would like to know your reasoning behind keeping the current behaviour.

[agnostic-apollo]

I have no reasoning currently and will need to read up on its history. I haven't noticed the issue myself either.

[markuspeloquin]

Here, you can see how Linux treats bright vs bold. If the color is bright, it converts it to non-bright and switches on 'bold':
https://github.com/torvalds/linux/blob/e8d018d/drivers/tty/vt/vt.c#L1761-L1765

But 'bold', 'italic', and 'underline' are merely implemented as colors. Here, you can see that when bold is enabled, the color (b0BBB0FFF for 3-bit background and 3-bit foreground) gets 8 added to the foreground:
https://github.com/torvalds/linux/blob/e8d018d/drivers/tty/vt/vt.c#L681-L682

The 'support' for bright color codes 90-97 added in torvalds/linux@cc67dc2 did not add the bright colors, they were already there. Those bright colors previously could only be specified by the intensity flag or by using the 256-color pallete. The commit hints at this, but these color codes weren't standardized in ECMA-48, which only specified SGR values up to 65. But these were commonly implemented by many terminals.

Of course, those color codes aren't necessary, \e[90m through \e97m are equivalent to \e[38;5;8m through \e[38;5;15m. In the 256-color pallete, 0-7 are the normal intensity colors, 8-15 are the bright colors, and the rest are hard-coded. But I think it helps to illustrate how the concepts of bright (colors 8-15) were conflated with bold.

Note I'm done editing after prematurely posting halfway through.