Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use a more commonly supported character for fat_headline_lower_string #89

Conversation

davidstosik
Copy link
Contributor

@davidstosik davidstosik commented Jul 6, 2024

Update: this PR now uses matching "Upper Half Block" and "Lower Half Block" to generate vertically centered half headlines.

What

This PR replaces the character 🬂 (Block Sextant-12 (U+1FB02)) with (Upper Half Block (U+2580)) to be used for the fat_headline_lower_string configuration everywhere.

Why

The Block Sextant-12 character is part of a Unicode block named Symbols for Legacy Computing.
(Emphasis on "legacy" mine. 😬)

This character seems to not be supported by a lot of fonts and many terminals, as well as other applications (one might even see a "missing character" square while browsing this PR and links I provided).

I have for example confirmed that it would not work with the following:

  • Terminal apps:
    • macOS' Terminal.app
    • iTerm2
    • Alacritty with builtin_box_drawing set to false
  • Fonts:
    • Monaco
    • MonaspiceNe Nerd Font
    • SFMono Nerd Font
    • Fira Code Nerd Font

Upper Half Block is slightly thicker than Block Sextant-12, but it also appears to be more widely supported across terminals and fonts.

I think a default configuration that will work in most environments would provide a better user experience, and would likely prevent many developers from spending hours diving into the unknown territories of font rendering, Unicode blocks, NeoVim LUA configuration, etc.

How

A simple script that replaces all instances of the Block Sextant-12 character in the repository:

 ag -l \U0001fb02 | xargs -n1 sed -i '' -e "s/\U0001fb02/▀/"

Anything else?

Alternative

An alternative to Upper Half Block would be the thinner (Upper One Eighth Block (U+2594)).

Matching "lower" and "upper"

If it is important for the width of the fat headline top and bottom padding be identical, then we could also change fat_headline_upper_string to use a character of the same width.
Respectively, in order of appearance above:

Screenshots

Using the evening colorscheme, iTerm2 with MonaspiceNe Nerd Font.

What Screenshot
Before image
This PR image
Alt:
upper one eighth
image
Alt:
matching half blocks
image
Alt:
matching 1/8 blocks
image

 ## What

This commit replaces the character `🬂`
([Block Sextant-12 (U+1FB02)](https://unicodeplus.com/U+1FB02))
with `▀`
([Upper Half Block (U+2580)](https://unicodeplus.com/U+2580))
to be used for the `fat_headline_lower_string` configuration everywhere.

 ## Why

The _Block Sextant-12_ character is part of a Unicode block named
[_Symbols for Legacy Computing_](https://en.wikipedia.org/wiki/Symbols_for_Legacy_Computing).

This character seems to not be supported by a lot of fonts and many
terminals, as well as other applications (one might even see a "missing
character" square while browsing this PR and links I provided).

I have for example confirmed that it would not work with the following:
- Terminal apps:
  - macOS' Terminal.app
  - iTerm2
  - Alacritty with `builtin_box_drawing` set to `false`
- Fonts:
  - Monaco
  - MonaspiceNe Nerd Font
  - SFMono Nerd Font

_Upper Half Block_ is slightly thicker than _Block Sextant-12_, but it
also appears to be more widely supported accross terminals and fonts.

I think a default configuration that will work in most environments
would provide a better user experience, and would likely prevent many
developers from spending hours diving into the unknown territories of
font rendering, Unicode blocks, NeoVim LUA configuration, etc.

 ## How

A simple script that replaces all instances of the _Block Sextant-12_
character in the repository:

```sh
 ag -l \U0001fb02 | xargs -n1 sed -i'' -e "s/\U0001fb02/▀/"
```

 ## Anything else?

 ### Alternative

An alternative to _Upper Half Block_ would be the thinner `▔`
([Upper One Eighth Block (U+2594)](https://unicodeplus.com/U+2594)).

 ### Matching "lower" and "upper"

If it is important for the width of the fat headline top and bottom
padding be identical, then we could also change
`fat_headline_upper_string` to use a character of the same width.
Respectively, in order of appearance above:
- `▄` ([Lower Half Block (U+2584)](https://unicodeplus.com/U+2584))
- `▁` ([Lower One Eighth Block (U+2581)](https://unicodeplus.com/U+2581))
@davidstosik davidstosik marked this pull request as ready for review July 6, 2024 03:12
@davidstosik
Copy link
Contributor Author

davidstosik commented Jul 6, 2024

And a proof that most fonts don't support Block Sextant-12: copy the first paragraph in my PR description above, paste it in https://www.programmingfonts.org/#firacode, then scroll through fonts.

image

Or even just do it in any text editor, like for example macOS' TextEdit:
image


(You can check out Google Fonts too.)

@davidstosik
Copy link
Contributor Author

davidstosik commented Jul 6, 2024

TIL that macOS' Font Book can search fonts by supported characters.

🬂 (Block Sextant-12) ▀ (Upper Half Block)
image image

@davidstosik
Copy link
Contributor Author

davidstosik commented Jul 6, 2024

Here's a final comment: Nerd Fonts don't seem to be designed to add a glyph for the block sextant-12 character code, so it'll boil down to whether the original, unpatched font supported it to begin with.

image

davidstosik added a commit to davidstosik/dotfiles that referenced this pull request Jul 6, 2024
@davidstosik
Copy link
Contributor Author

@lukas-reineke Pinging you in case you've missed this. 🙏🏻

@lukas-reineke
Copy link
Owner

Sorry for the delay.
I'm not against changing this, but I think top and bottom should match, so your matching half blocks example is probably best.

This matches fat_headline_lower_string's "Upper half block"
@davidstosik
Copy link
Contributor Author

@lukas-reineke Done. 999ad2e

@lukas-reineke
Copy link
Owner

Thanks

@davidstosik
Copy link
Contributor Author

Just out of curiosity, why not merge the PR?
Now GitHub isn't able to link the commit (bf17c96) back to this PR, which I think is a shame, as that's lost context...

Just curious really.

@lukas-reineke
Copy link
Owner

I just had to change the commit message to include a breaking change notification.
The PR is still linked in the release notes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants