neovim-qt
neovim-qt copied to clipboard
equalsraf
GuiRenderLigatures Issues
@kierun
Creating a bug here so as to not spam the large thread.
From #166:
Ah, I see. The runtime was wrong, installed and I can see ligatures.
screenshot
I mean, they are horribly broken but that could be my font.
screenshot1
Which it is.
However, using the mouse now causes neovim to crash… Should I open a new bug for that?
Yes, please provide more details on your GuiRenderLigatures issues here.
Sorry for the break, the changes are still experimental.
Please be specific, I'm not sure what each screenshot above correlates to.
What font are you using? Steps leading up to the issues? What specific actions result in a crash?
Here is the feature on my machine:
√ (master|…56); cmake -G Ninja -DCMAKE_INSTALL_PREFIX=$HOME ..
[…] ← I can paste those is need be.
(master|…56); ninja -j 5 install
[…] ← I can paste those is need be.
√ (master|…56); nvim-qt --version
NVIM-QT v0.2.17.9999
Build type:
Compilation: -Wall -Wextra -Wno-unused-parameter -Wunused-variable -std=c++11
Qt Version: 5.14.2
Environment:
nvim: nvim
args: --cmd let &rtp.=',/home/yann/share/nvim-qt/runtime' --cmd set termguicolors
runtime: /home/yann/share/nvim-qt/runtime
NVIM v0.4.4
Build type: Debug
LuaJIT 2.0.5
Compilation: /usr/bin/cc -g -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wmissing-prototypes -Wimplicit-fallthrough -Wvla -fstack-protector-strong -fno-common -fdiagnostics-color=always -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -I/home/yann/src/neovim/build/config -I/home/yann/src/neovim/src -I/home/yann/src/neovim/.deps/usr/include -I/usr/include -I/home/yann/src/neovim/build/src/nvim/auto -I/home/yann/src/neovim/build/include
Compiled by [email protected]
Features: +acl +iconv +tui
See ":help feature-compile"
system vimrc file: "$VIM/sysinit.vim"
fall-back for $VIM: "/home/yann/share/nvim"
Run :checkhealth for more info
Then running it, I get:
Font is Monoid Nerd Font. However, any mouse input (left, middle, and right click) gets me this:
Another oddness: the font width appears to be variable!
This is using a PrgamataPro patched (with Nerd Fonts) font. At the end, I did a left mouse click.
Font is Monoid Nerd Font. However, any mouse input (left, middle, and right click) gets me this:
The input issues are unrelated to GuiRenderLigatures. A bisect suggests 3a59d6bd6e24a0935272a87e4300f97472e40d13 is to blame.
I will file a new bug (or pull request) shortly...
Another oddness: the font width appears to be variable!
Interesting... Is the font you are using well-formed? Is there a space before b?
The raw characters like == and their equivalent ligature must be the same width.
Here is my machine with Fira Code:
File Content:
a == b
a != b
a -> b
a => b
Your machine looks okay for Monoid. Does the issue disappear when you change fonts? Does the issue disappear on :GuiRenderLigatures 0?
What setting causes the highlight lines to appear vertically and horizontally outward from the cursor?
The feature has some interesting implications. GuiRenderLigatures 1 renders entire lines and GuiRenderLigatures 0 renders individual cells. With your config, cursor movements trigger an entire screen redraw... Ouch!
Have you noticed any performance degradation? Lagging?
I'd like to do some testing and performance profiling with your configuration...
Is the font you are using well-formed? Is there a space before b?
Not sure. I've had issues with PragmataPro and Nerd Font so that could be it. I'll try with Monid.
Your machine looks okay for Monoid. Does the issue disappear when you change fonts?
Yes, it does:
What setting causes the highlight lines to appear vertically and horizontally outward from the cursor?
Neovim but should work in vim too:
set cursorcolumn
set cursorline
The feature has some interesting implications. GuiRenderLigatures 1 renders entire lines and GuiRenderLigatures 0 renders individual cells. With your config, cursor movements trigger an entire screen redraw... Ouch!
☹ That's not good. I might get ride of those.
Have you noticed any performance degradation? Lagging?
Not really but my machine is not being taxed by window manager and things like that…
I'd like to do some testing and performance profiling with your configuration...
Here it all is, in its horribly mess… I should clean it up but I am so so so lazy…
frowning_face That's not good. I might get ride of those.
No need to change, keep the settings as you like them. I am also unable to perceive any slowness.
This is purely theoretical and may not be a concern in practice :)
Not sure. I've had issues with PragmataPro and Nerd Font so that could be it. I'll try with Monid.
Could you provide link or information on how to install this specific font?
I would like to understand what causes the appearing/disappearing space before 'b'.
Cursor disappears on the second character of the ligatures. Also, when the cursor is on the first character the second character disappears.
@khalidchawtany Thanks for the bug report!
I cannot reproduce on Linux or Windows with Fira Code or Monoid. Testing on MacOS pending, no VM access right now.
Can you provide a minimal repro case? It would be helpful to have: file, colorschme, and specific font.
I assume your platform is MacOS?
MacOS version: 10.15.7 (19H2)
I tried using another font like Fira Code and none of the cursor or the character disappear!
The font with the problem is Operator Mono, I patched it to support ligatures myself.
./nvim-qt --version
NVIM-QT v0.2.17.9999
Build type: Release
Compilation: -Wall -Wextra -Wno-unused-parameter -Wunused-variable -std=c++11
Qt Version: 5.15.1
Environment:
nvim: nvim
args: --cmd let &rtp.=',/Users/juju/Development/Applications/neovim-qt/neovim-qt/build/bin/nvim-qt.app/Contents/MacOS/../Resources/runtime' --cmd set termguicolors
runtime: /Users/juju/Development/Applications/neovim-qt/neovim-qt/build/bin/nvim-qt.app/Contents/MacOS/../Resources/runtime
NVIM v0.5.0-c10c2fab5
Build type: Release
LuaJIT 2.0.5
Compilation: /usr/bin/clang -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -DNDEBUG -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wmissing-prototypes -Wimplicit-fallthrough -Wvla -fstack-protector-strong -fno-common -fdiagnostics-color=auto -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -DMIN_LOG_LEVEL=3 -I/tmp/neovim-20201002-12405-1hnb1sr/build/config -I/tmp/neovim-20201002-12405-1hnb1sr/src -I/usr/local/include -I/tmp/neovim-20201002-12405-1hnb1sr/deps-build/include -I/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include -I/usr/local/opt/gettext/include -I/tmp/neovim-20201002-12405-1hnb1sr/build/src/nvim/auto -I/tmp/neovim-20201002-12405-1hnb1sr/build/include
Compiled by [email protected]
Features: +acl +iconv +tui
See ":help feature-compile"
system vimrc file: "$VIM/sysinit.vim"
fall-back for $VIM: "/usr/local/Cellar/neovim/HEAD-c10c2fa/share/nvim"
Run :checkhealth for more info
The font with the problem is Operator Mono, I patched it to support ligatures myself.
Ahhhhh, interesting. The Qt API I used is vaguely documented. The glyphs for that font are probably presented in a format I did not expect.
Could you provide the TTF/OTF file or install instructions?
https://github.com/kiliman/operator-mono-lig is the tool used to patch the font (Support ligatures).
The font can be obtained from https://www.typography.com/fonts/operator/styles/operatormono but you have to pay for :(
Edit: I found the font in github just search for (github operator mono otf)
@khalidchawtany @kierun
It looks like both have a similar issue: non-working non-free ligatures fonts.
If you can provide me a copy of the fonts privately, I will use them for debugging purposes only and I will delete the files afterwards. You can find my email in git logs (trying to avoid directly posting it, spam).
Otherwise, you can try to debug the issues on your respective machines.
Best guess, there is an issue near these lines: https://github.com/equalsraf/neovim-qt/blob/e16af64771c9a20992ab2901142c1321165b6c74/src/gui/shellwidget/shellwidget.cpp#L481-L512
It looks like both have a similar issue: non-working non-free ligatures fonts.
Done. Let me know if you got it, it is quiet a big archive…
Progress update.
@khalidchawtany
Operator Mono has proven most vexing...
The font has poor monospace metrics, each ligature is slightly larger than the individual characters composing it.
Here is an example of the length-mismatch 10i-> vs 10iXX:
I have some code to correct this issue. We can analyze each glyph and correct the position to fit within cell bounds:
Operator Mono also has issues with multi-QGlyphRun text layouts. The string ☰ -> 0/1 == will trigger issues.
The unmodified render of that string is incorrect (from a Neovim grid perspective). The glyph-run split, random run ordering, spacing issues, and encoding scheme make it very hard to determine which characters belong to which glyph. The issues may be too severe to correct via Qt's API.
Regarding RTL, we probably need to pivot on https://doc.qt.io/qt-5/qglyphrun.html#isRightToLeft. I will investigate further.
@kierun
I've installed several of the Pragmata Pro fonts you provided. No ligatures appear, and the font looks different from your screenshots. I am not sure what is going wrong there...
Some debug output may help triage the issue. We need to understand the format of position/index lists for that font.
This patch will print the first 10 positions/indexes whenever a "==" appears:
diff --git a/src/gui/shellwidget/shellwidget.cpp b/src/gui/shellwidget/shellwidget.cpp
index e2f3787..e5d65fd 100644
--- a/src/gui/shellwidget/shellwidget.cpp
+++ b/src/gui/shellwidget/shellwidget.cpp
@@ -468,6 +468,13 @@ void ShellWidget::paintForegroundTextBlock(
auto glyphPositionList{ glyphRun.positions() };
int sizeGlyphRun{ glyphPositionList.size() };
+ if (text.contains("==")) {
+ qDebug() << glyphPositionList.mid(0,10);
+ qDebug() << glyphRun.glyphIndexes().mid(0,10);
+ qDebug() << glyphRun.rawFont().glyphIndexesForString("a == b");
+ qDebug() << m_cellSize;
+ }
+
const int cellWidth{ (cell.IsDoubleWidth()) ?
m_cellSize.width() * 2 : m_cellSize.width() };
Can you send me some output from "a == b" or similar?
Thanks @jgehrig for debuggin this issue.
Using set guifont=Operator\ Mono\ Lig:h18 with ligatures, the output of a file containing a == b is:
QVector(QPointF(0,17), QPointF(10,17), QPointF(20,17), QPointF(30,17), QPointF(50,17), QPointF(60,17), QPointF(70,17), QPointF(80,17), QPointF(90,17), QPointF(100,17))
QVector(2, 29, 2, 435, 2, 30, 2, 2, 2, 2)
QVector(29, 2, 335, 335, 2, 30)
QSize(10, 28)
@jgehrig It might be some time before I am able to do that. I am horrendously busy but will get to it this week. My apologies.
I cant set the option GuiRenderLigatures 0/1, nvim not recognized this option.
@bsjaramillo
What version are you running? You can check with nvim-qt --version.
GuiRenderLigatures is only available in master right now, NVIM-QT v0.2.17.9999
Here are CI nighly build install instructions for Windows: https://github.com/equalsraf/neovim-qt/wiki/Windows-AppVeyor-Builds
@jgehrig i have the version 0.2.14, it was installed with chocolatey running choco install nvim
@bsjaramillo
Okay, expected behavior. GuiRenderLigatures is not supported in that version.
You'll need to upgrade (manual install) using the link above.
@jgehrig i done it, now i have the version 0.2.17.999 but im getting the same problem
@bsjaramillo
Have you tried this? https://github.com/equalsraf/neovim-qt/#why-are-the-gui-commands-missing
@jgehrig i didnt tried that, but i dont understand it, i got add "NVIM_QT_RUNTIME_PATH" to environment variables?
@jgehrig ok, i fix it, i forget copy the new runtime folder generated by the building to my nvim folder
@jgehrig ok, i fix it, i forget copy the new runtime folder generated by the building to my nvim folder
but this building is very slow when navigate in a file :c
Enabling ligature support and relative line numbers at the same time result in very slow line movement (e.g. hold j or k).
Presumably this is because all lines are redrawn when cursor moves. Hopefully there is a way to speed it up, maybe the GUI could render line numbers instead of relying on the vim option; idk anything about this stuff.
@ejolson9
Presumably this is because all lines are redrawn when cursor moves.
Correct!
Unfortunately, there isn't a good way to render only the line number changes. This would require a new API from Neovim. The best performance improvement I can think of is only calling update() for the regions of the screen that have actually changed. This is a non-trivial piece of work. Lots of higher-impact work is in line ahead of this.
This scenario has always concerned me in theory. However, I've never actually noticed a visible difference in performance on my machines. I've also asked a few other users, and they reported the same: no visible difference. But I also don't use number or relativenumber daily...
I can definitely see severe performance loss with relativenumber on. With number only it's less bad (20% less framerate maybe?) but I don't know how to quantify it properly.
Using nvim-qt 0.2.17.9999, nvim 0.6.0-dev+ 14-gdf33f30e8 (nightly); on an AMD-8350 4.0GHz, 8GB RAM. (If any other spec matters, let me know and I'll add it). Just another data-point on performance loss with Ligatures.
