Open Olical opened 2 months ago
I'm using an 13" Early 2015 Macbook Air with a 1.6 Ghz Dual-core Intel Core-i5 laptop.
This is a screenshot of the effect:
Here, I just did :w
to write/save the file. The message is:
"fnl/conjure/client/clojure/nrepl/action.fnl" 736L, 22932B written
and is viewable using g<
or :mess
(mess being short for message :-).
:redraw
and :redraw!
don't fix the mangled screen but moving to another portion of the file that puts the previous bottom beyond the top of the window works before returning to the previous position. Like paging down and back up seems to return things back to expected.
:mode
does repaint the entire window and restores things to what you expect.
The text in the window is further messed up when you go to the top of the window and cursor down. The old text shows through if the new text line is shorter. Here's a screenshot: See lines 13 - 15.
If I set the cmdheight
option is set to 3 the window isn't messed up.
But the command window is messed up (not refreshed) if I start another command on the command line such as :he
.
This would suggest that it's a Neovim issue.
Cool, that makes sense. I suspected as much because it kinda looks like a multi line message being printed and cleared instantly. This can also happen if the line is too long when it's printed...
Maybe it's a case of using a long file path and a small terminal? Then the echoed text is split onto two lines + some weird race condition that clears it quickly but leaves us in a weird state.
I think if this instant clear + render bug doesn't happen then we'd see one of those "press enter to continue" text lines.
I don't think nfnl echos anything though, it uses vim.notify which WILL use echo if you don't have a plugin installed to display pretty notify windows. That also only notifies if:
On Tue, 3 Sept 2024, 23:34 Russ Tokuyama, @.***> wrote:
If I set the cmdheight option is set to 3 the window isn't messed up. conjure-not-messed-1.png (view on web) https://github.com/user-attachments/assets/8cd1ff38-f376-4b77-90cf-9e11f7c2b4c5
But the command window is messed up (not refreshed) if I start another command on the command line such as :he. conjure-not-messed-2.png (view on web) https://github.com/user-attachments/assets/d293ce8e-7300-4e91-b18b-4bb9f32707fd
This would suggest that it's a Neovim issue.
— Reply to this email directly, view it on GitHub https://github.com/Olical/nfnl/issues/44#issuecomment-2327556587, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACM6XIDIVLB6GR3FOOOVDDZUY2ORAVCNFSM6AAAAABNSUX6NCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMRXGU2TMNJYG4 . You are receiving this because you authored the thread.Message ID: @.***>
Another way I just reproduced it easily: Run :NfnlCompileAllFiles
in the Conjure repo. That creates a LOT of rendering issues.
Spotted these errors when writing a macro file in the Conjure project.
So it looks to be caused by some warnings being printed by the Fennel compiler! I wonder how I can capture those so I can send them through vim.notify
. For now, I'll fix the warnings in Conjure, but I'll then repro it in this repo and try to fix it.
I found three such warnings/errors in the Conjure project.
This is the most minimal repro I can find, you just need a function with something non-whitespace before a string.
(fn x [y]
y"")
I'll see if I can capture that as a warning and put it through the notify system.
Ah hah! This is the same bug! https://todo.sr.ht/~technomancy/fennel/239
I think the right thing to do right now is to wait and see how easily this can be addressed in the compiler. Or if it's even a valid bug, maybe they'll have a good reason for it. At that point I'll add a workaround to nfnl but at least we know what causes it now and can keep an eye out for it.
We SOMETIMES see an odd rendering issue when writing files in Conjure's repo. The screen sort of jumps up by one line and it's hard to get nvim to redraw it,
<c-l>
doesn't seem to help. Mayberedraw!
would? I think that does more.@russtoku has also seen this, so it's not just me although I think I've only ever seen it on my laptop. I have not seen it (as far as I can remember) on my much more powerful and bigger screened desktop. Both of them run the same dotfiles, nvim config and Linux distro.
I wonder if it's potentially a race condition since I only see it on my slower laptop CPU? I have tried raising the font size, shrinking the window and using lots of splits on my desktop but it never does it. I think I saw it mostly with splits open on my laptop.
If anyone can reliably reproduce this or has similar weirdness around "fast machine good, slow machine bad", please let me know!