6.23.224.1 beta: Code/Text font prio list configurable

[craigo-]

This pertains to PR #4581 that was first included in Notepad3 version 6.23.224.1 beta. See also Issue #4522, where this came from. I have also tested versions 6.23.226.1 and 6.23.228.1 and the findings below also apply to those versions.

Sorry for the delay, I have not had a whole lot of testing time this past little while.

By the way, I see that you've already updated Readme.md to reflect the new font priority settings. I'm very happy to contribute to this sort of thing by way of a PR if you like. I like great documentation :smile:

I have tested adding, removing and rearranging fonts in the new CodeFontPrefPrioList and TextFontPrefPrioList settings in Notepad3.ini and that all works well - thank you.

I did also try to remove all fonts from the TextFontPrefPrioList setting, to see whether that then makes the Text Files scheme ignore the $Text variable and simply inherit the selected Common Base scheme's style. I did this two ways:

• TextFontPrefPrioList=""
• TextFontPrefPrioList=

But neither produced the behaviour I was looking for; resetting the Text Files scheme style resulted in it using the default list for the $Text variable. Would it be possible for the TextFontPrefPrioList setting to behave in this way? Of course I don't think it makes any sense for the CodeFontPrefPrioList to behave this way, as it is used for a root style that needs some defaults.

I then thought about the current behaviour of assigning the $Code variable to both the Common Base and 2nd Common Base root styles. This didn't make a lot of sense to me, as the two styles then just end up defaulting to the same font. I preferred showcasing each Common Base as a way to quickly style all dependent substyles differently, e.g. on my system Common Base might default to Cousine, and 2nd Common Base might default to something else (perhaps Consolas). With both Common Base styles currently using the same variable, this is not possible.

This then got me thinking: why not generalise this a step further - not make any presumptions as to how the user will use the Common Base styles, and have three variables with names based on the schemes they are hardwired to, i.e.:

• The Common Base scheme uses variable $CommonBase
• The 2nd Common Base scheme uses variable $2ndCommonBase
• The Text Files scheme uses variable $TextFiles

...each of which being configurable in Notepad3.ini (and ideally, the Text Files setting being able to be empty 😄). Ultimate configurability!

Another thought I had: is it possible to have the Default Style in the Scheme dialogue somehow visually differentiate between a style explicitly set within the style, or an inherited style? Would it make sense to do so? Something like the following mockup where the greyed-out font indicates an inherited style element whereas the non-greyed-out size indicates an explicit style element - the same visual cue used for a scheme's substyles:

I did find one bug (moved to separate issue #4618 as requested).

[RaiKoHoff]

The use case for introducing a separate configuration for TEXT files (and not simple use all Common Base settings) was the difference between only reading plain text vs. coding algorithms. So, maybe for some users it make more sense to use a bigger font size or use another non monospaced font with ligatures. So it does not make sense to have the same fallback for TEXT files than for source code files (if TextFontPrefPrioList is left empty).

Upcoming PR allows generic references "$Code<N>" resp. "$Text<N>", where "<N>" refers to position in font priority list.

For the last point (bug), please open a separate issue, copy complaint text and refer to it in this issue here.

[hpwamr]

Hello @craigo- ,

Feel free to test the "BETA/RC PortableApps", version "Notepad3Portable_6.23.302.1_beta.paf" or newer, see in issue #1129.

• Notepad3Portable_6.23.302.1_beta.paf.exe.7z -s

"Notepad3Portable BETA/RC PortableApps" version can be used with or without ".7z" extension.

Also, feel free to test the "BETA/RC Setup", version "Notepad3_6.23.302.1_beta_Setup" or newer, see the 2nd list in issue #1129.

Comments and suggestions are welcome... 😃

[craigo-]

I'll break this down into two posts. This, the first, pertains to the position referencing change introduced in version 6.23.302.1 beta.

What I think this does - when the style for the scheme below is first determined or reset:

• For the Common Base scheme, the app looks for a usable font in the $Code (CodeFontPrefPrioList) priority list, starting from the first position (index 0) - by default, Cascadia Code
• For the 2nd Common base scheme, the app looks for a usable font in the $Code (CodeFontPrefPrioList) priority list, starting from the second position (index 1) - by default, Cascadia Mono
• For the Text Files scheme, the app looks for a usable font in the $Text (TextFontPrefPrioList) priority list, starting from the first position (index 0) - by default, Cascadia Mono

You can also manually input the variable and position (e.g. Font:$Code9) and it starts allocation from the 10th position on the list - by default, Lucida Console. You can even tell the Text Files scheme to use Font:Code9 and it will reference the $Code list instead of the $Text list. This happens once and the (indexed) variable is then replaced with the selected font.

Is that correct? If so, that is what it appears to do - working as designed. This then gets around the problem mentioned above where both Common Base schemes used the same variable and setting.

(It's getting late, I'll post part 2 later.)

[hpwamr]

I want to add that the font lists in Notepad3.ini can also be edited (add fonts, remove fonts, move fonts, reorder list of fonts, other list of fonts, etc...)

CodeFontPrefPrioList="Cascadia Code,Cascadia Mono,Cousine,Fira Code,Source Code Pro,Roboto Mono,DejaVu Sans Mono,Inconsolata,Consolas,Lucida Console"

TextFontPrefPrioList="Cascadia Mono,Cousine,Roboto Mono,DejaVu Sans Mono,Inconsolata,Consolas,Lucida Console"

[craigo-]

OK, Part 2. This concerns the moving of the Text Files scheme to effectively be a top-tier scheme.

Before I begin, I want to reiterate hfstar-duan's comment - thank you, particularly @RaiKoHoff and @hpwamr, for your contributions. Notepad3 would not be what it is - my preferred text/code editor - without your valued work. You are the unacknowledged life and soul of this party.

c.f. https://github.com/rizonesoft/Notepad3/issues/4522#issuecomment-1427157933

I guess it's no secret that I'm not a fan of this change, and it's confounded me until I untangled the intent - the aforementioned promotion of the Text Files scheme. I would guess that it's caused some confusion amongst some of our users (#4589, #4627). I'm no super-neuron genius, but I am familiar with both our prececessors and our current design philosophy. If I struggle, ...? I also acknowledge that our user base may very well draw from that of our predecessors - and that is a good thing.

Here is a list of reasons why I think promoting the Text Files scheme to the top tier is counterproductive.

Where Top-Tier Schemes Came From

In Notepad3, the pre-existing top-tier schemes are called Common Base and 2nd Common Base. In our predecessor, the scheme was called Default Text (the execution was slightly different, and on balance I prefer how we do it now, but the premise is the same). These are the common, base schemes upon which all other schemes are derived. c.f. my rough sketch from https://github.com/rizonesoft/Notepad3/issues/488#issuecomment-388759021.

Top-Tier Schemes are Independent of File Type

Notepad3's previous top-tier schemes did not specify a file type, consistent with Notepad2's top-tier scheme. The introduction of Text Files at this level is inconsistent with this.

Tiered Schemes are Part of the Notepad3 Ethos

Notepad3 schemes are fundamentally built on the principle of these independent, top-tier schemes. The current (and historical) UI supports this - why else have Common Base togglable, and its state visible in the status bar, no matter what current scheme has been chosen? If Notepad3 selects Text Files as the applicable scheme, the Common Base elements in the Appearance menu and the Status Bar have no meaning.

Self-Imposed Limitation

Under the previous inheritance model, there were two available Text Files schemes, based on which Common Base was selected. With this new direction, this fundamental Notepad3 feature no longer applies to the Text Files scheme; you are limited to one definition that no longer respects the Common Base / 2nd Common Base feature.

If you instead wanted to create a third Common Base that lended itself to text file support, I'd support that as it is still in line with what I see is the fundamental principle of scheme application.

Where We Stand

If I were tasked with redrawing my original sketch to accommodate where the scheme hierarchy is going, I'd struggle. And certainly, if I tried to portray this in a Schemes dialogue mockup, I think I'd outright fail. Which I believe is relevant, because I think the Schemes dialogue could stand a refresh to better describe the underlying hierarchy.

The Way Forward?

Look, I understand that there are some users for which this direction makes sense. I'd just like to point out that I am not one of them, and I get the sense that I am not alone. Is there a way we can accommodate both points of view? That is the direction I was trying to lead us in when proposing the ability to retain the Text Files style hierarchy. Could we still do such a thing? It seems to me that e.g @hpwamr's desires could yet be accommodated in a system that still respects a Common Base / (others) hierarchy - particularly in light of the PR #4615 that allows a default difference between the fonts for the two Common Base schemes. Failing that, could we have a setting that retains the Text Files lexer in its original place in the hierarchy?

[hpwamr]

Hello @RaiKoHoff , @craigo- ,

After reading the legitimate arguments of "Craigo-", my drastic suggestion is to treat "Text Files" like all other lexers inside the "Common Base" and "2nd Common Base" hierarchy (except "ANSI Art):

• Restore "Text Files" inside the hierarchy of "Common Base" and "2nd Common Base"
• Keep the font priority "$Text0" which overrides the list of fonts ($Code0/1) from "Common Base" and "2nd Common Base"
• Move "Text Files" to alphabetical place in the list of lexers.

[craigo-]

Thanks for the consideration, @hpwamr. Your suggestions go a very long way towards my desired goal.

Fully treating the Text Files scheme the same as all other schemes would also dictate that the $Text0 variable for the Text Files scheme either not be enforced, or be treated differently. There must be some way for the default style of the Text Files scheme to be "blank", and therefore fully inherit the properties of the base scheme.

I can see two ways that this might be achieved:

• Allow a null string for TextFontPrefPrioList in Notepad3.ini settings that then falls back to inheritance from Common Base schemes
• A Notepad3.ini setting, e.g. TextFilePrioListInheritance (boolean), that:
  • when off, uses the (indexed) $TextFile variable (happy for this to be the default)
  • when on, does not use the (indexed) $TextFile variable

My preference would be for the first option - it does not require any additional definition for the settings file.

~~NB: I was playing around with the idea that in an inheritance model, you could specify the default style for the Text Files scheme to be font:size:+2 and have the Text Files scheme be based on the selected Common Base scheme, at two points larger - but that does not work at present. It always injects a font name. I see the ability to solely specify a size change (relative or absolute) as a useful addition to the schemes hierarchy. I think I'll raise this as a separate feature-request issue.~~

Amendment above: you can specify size:+2 (without the font: prefix) and it works as expected.

[GitHubinatrix]

I guess it's no secret that I'm not a fan of this change, and it's confounded me until I untangled the intent - the aforementioned promotion of the Text Files scheme. I would guess that it's caused some confusion amongst some of our users (#4589, #4627).

I have read through this topic and I still do not understand why nested entries of Customize Schemes are not in alphabetical order [and apparently will not be, as that topic of mine has been closed: #4627]

[craigo-]

I'm also a little confused as to why this issue was closed, when @hpwamr expressed agreement with my arguments and proposed a reversion that never eventuated. I have tested version 6.23.718.1 rc and the Text Files scheme is still effectively top-tier, ignoring the Common Base schemes.

@GitHubinatrix, I would also be happy to further explore your suggestion in issue #4627.

[maboroshin]

Related: https://github.com/rizonesoft/Notepad3/issues/4120 : If the character doesn't exist in the font, the character is brought from a font with a lower priority.