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

Typing combining characters in Julia #1617

Closed
cormullion opened this issue Feb 5, 2022 · 5 comments
Closed

Typing combining characters in Julia #1617

cormullion opened this issue Feb 5, 2022 · 5 comments
Labels
fixed-in-nightly This is (or is assumed to be) fixed in the nightly builds.

Comments

@cormullion
Copy link

Hi! When I'm using Julia in the REPL, I can write eg vectors by typing a letter followed by \vec followed by TAB to produce:

Screenshot 2022-02-05 at 11 59 03

(macOS Terminal, Version 2.12 (443), font JetBrainsMono Regular)

In wezterm, it doesn't work so well, because the arrow doesn't appear:

Screenshot 2022-02-05 at 11 56 12

(macOS, wezterm 20220101-133340-7edc5b5a, no font specified, looks like JetBrainsMono)

although the Julia REPL is convinced there's more than one character there.

I copied this "character" and did this:

Screenshot 2022-02-05 at 12 02 07

which looks better when pasting into github:

❯ wezterm ls-fonts --text "e⃗"
e⃗   \u{65}\u{20d7} glyph=70   wezterm.font("STIXGeneral", {weight="Regular", stretch="Normal", italic=false})
                             /System/Library/Fonts/Supplemental/STIXGeneral.otf, CoreText

wezterm.lua looks like this:

local wezterm = require 'wezterm';

return {
  color_scheme = "Dracula+",
}

I've spent some time searching the copious documents, and can't find anything I can understand that might fix this behaviour. Thanks for any suggestions!

wez added a commit that referenced this issue Feb 5, 2022
For a sequence like `e U+20d7` the intent is to render the `e` with
a vector arrow over the top.

This is typically implemented by fonts as an `e` followed by the
vector glyph (or vice versa), where either one of those may have
a zero advance so that the two elements are combined.

There were two problems here:

* During shaping we'd see the zero advance and assume that the entry
  was useless and skip it
* During rendering, if we didn't think it had any cell width, we'd
  not render it

Cursoring through that particular sequence can hide the vector
mark if the cursor is set to the default block cursor due to annoyances
in how the block cursor is rendered (it changes the fg color to match
the bg, but for elements outside where we think the cursor is, this
makes those elements invisible).

refs: #1617
@wez
Copy link
Owner

wez commented Feb 5, 2022

I've pushed a commit that seems to resolve this for me. It typically takes about 40 minutes or so to build for macOS. When you see the green check mark next to the commit hash above, you'll be able to download the latest nightly and try it out.

I would recommend setting default_cursor_style="SteadyBar" to avoid a glitch where the vector portion of the combining mark turns invisible when cursoring through/near the glyph.

@wez wez added the fixed-in-nightly This is (or is assumed to be) fixed in the nightly builds. label Feb 5, 2022
@cormullion
Copy link
Author

cormullion commented Feb 5, 2022

Hi! Thanks for looking into this... I think you've definitely fixed it!

Screenshot 2022-02-05 at 14 32 31

Even the rarely used double-stacking works (fairly) well.

The default_cursor_style is definitely needed, otherwise the combining marks keep disappearing:

Screenshot 2022-02-05 at 14 35 14

Thanks again!

wez added a commit that referenced this issue Feb 5, 2022
This puts to final rest #478, wherein ligatured glyphs that span
cells would render portions of the glyph with the wrong fg color,
where wrong was usually the bg color and cause the glyph to turn
invisible when cursoring through the ligature.

The approach used here is to divide the glyph into 7 discrete strips
where each strip either intersects with the cursor, the selection, or
neither. That allows us to render each strip with the appropriate
foreground color.

This change simplifies some of the logic and allows some other code
to be removed, so that feels good!

As is tradition with these renderer changes, there's a good chance that
I overlooked something in testing and that the metrics or alignment
might be slightly off for some font/text combo.  Let's see how this
goes!

refs: #784
refs: #478
refs: #1617
@wez
Copy link
Owner

wez commented Feb 5, 2022

The block cursor glitch should also be fixed as of bd47979 which you can try in ~40 minutes!

@wez wez closed this as completed Feb 6, 2022
@cormullion
Copy link
Author

Hi wez - that fix looks good too!

While designing the JuliaMono font, I've been using many different terminals and editors. I'm coming to the conclusion that - for fonts at least - wezterm is shaping up to be the best terminal around. So thanks again for your work and support!

@github-actions
Copy link
Contributor

github-actions bot commented Feb 4, 2023

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 4, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
fixed-in-nightly This is (or is assumed to be) fixed in the nightly builds.
Projects
None yet
Development

No branches or pull requests

2 participants