Comments (17)
Hmm... it may be performance issue. I think there're too many rendering events from nvim and they're stacked.
from nyaovim.
I have a similar issue. My issue is, I cannot press and hold HJKL to move around. I have to press and release time else nothing happens.
I will investigate to detect the source of the problem if it is a config option.
UPDATE:
It is not a config option as I just try nyaovim with a blank init.vim.
from nyaovim.
Sorry, I missed your comment because this issue has 'enhancement' tag π
Hmm..., could you check <C-d>
causes the same issue? Input with modifier and input without modifier are not handled in the same place. (the former is handled with keydown
event and the latter is handled with input
event.) I want to isolate the problem.
from nyaovim.
Sorry, I was out of Internet coverage for the past two weeks and will be for many upcoming days too (hopefully).
I forgot to mention that pressing ctrl-d
and ctrl-f
work as expected. However, HJKL
has this issue. Excuse me, If I will not be able to answer any question you may have, as I will be offline :)
from nyaovim.
I can confirm that <C-d>
/ <C-u>
work as expected. I would like to add that I experience lag anytime the "screen" moves (i.e.: scrolloff
) even if I don't hold down the movement keys.
from nyaovim.
Scrolling screen causes redraw of entire window (e.g. <C-e>
, <C-y>
). All rendering events are passed from Neovim via msgpack-rpc. And it seems that the RPC is slow as long as I profiled in previous. So we might improve msgpack5rpc
package.
from nyaovim.
Could anyone confirm that <C-e>
and <C-y>
cause this issue?
I think this is because the difference of processing key input.
If input is with modifier key, it is processed in keydown
event (e.g. <C-e>
). But if input is without modifier key, it is processed in input
event of <input>
element (e.g. j
).
This is because we can't catch compositionstart
/compositionend
events on keydown
event. I want to confirm this issue is derived from the difference.
from nyaovim.
If msgpack decoding is the bottleneck (rhysd/neovim-component#2), then https://github.com/tarruda/libmpack may help, once it is ready. cc @tarruda
from nyaovim.
Thank you for the notice. Although I'm not familiar with Node.js native extension (e.g. overhead on calling C from Node), it looks very helpful.
BTW, I wonder why msgpack-c was not adopted.
from nyaovim.
BTW, I wonder why msgpack-c was not adopted.
We are using msgpack-c already, but libmpack is intended to be easy to embed in non-C hosts such as node.js. So instead of using nodejs's mspack library, NyaoVim could ship with libmpack.
@tarruda gave a good explanation of the motivation for libmpack in gitter which I'll paste here:
libmpack is meant to hold most logic of a neovim client in a cross-language way(as long as a language can bind to C)
ZyX-I:
Whatβs the problem with currently used msgpack implementation except that it could be more memory-efficient (and, likely, faster) in some cases?
Can you describe in libmpack README why this project exists and how it compares to msgpack-c?
tarruda:
These are the main reasons:
- It is not trivial to simply include its files into another project(eg: a lua C module) since it relies too much on C99 features and compilation with -Wconversion issues a bunch of warnings. You need to build the library and link against it, which IMO is cumbersome for a simple serialization library that is being embedded into other projects(lua or node.js modules for example).
- It couples msgpack serialization format with a set of predefined C typedefs. This means the user almost always has to recursively convert the allocated structures into some other application-specific format, especially if binding to another language.
- It doesn't work without allocating memory. For example, you can't send/receive simple primitives without a msgpack_sbuffer_t(which is then dynamically extended by msgpack internal functions).
- msgpack-rpc lacks a proper C implementation. I actually haven't found a sane msgpack-rpc implementation even in other languages such as ruby, they are all very complicated(Eg: separate server and client APIs, have hard dependencies platform-specific on event loop libraries).
As I said, I want to use it as the base of a C neovim client that can be easily bound to any language, but I also wanted it to be flexible enough to use in any C project
For example, it has no system dependencies so it can be used in kernel development(eg: communicate with userspace using msgpack-rpc via netlink sockets)It also has an extra bonus that is not immediately visible: If you use -O3 and limit its API usage to a single file and use the amalgamation(and define MPACK_API as static) it will not emit any symbols, the whole thing will be inlined into a single loop in your function(even user-provided callbacks are inlined)
from nyaovim.
Thank you very much for the detailed information. I understood π
from nyaovim.
@rhysd c-y
and c-e
work perfectly. It is only hjkl
keys that has to be released and pressed to repeat the key.
When I press and hold L
I see a pop up suggesting another letter as shown in the screenshot below.
from nyaovim.
c-y and c-e work perfectly. It is only hjkl keys that has to be released and pressed to repeat the key.
Thank you for your confirming! I understood.
I'm going to go to U.S. this week on business trip. So the fix will come in the end of this week or beginning of next week.
When I press and hold L I see a pop up suggesting another letter as shown in the screenshot below.
Hmm, are you installing some UI plugins? If not, I think it is derived from text field in <input>
element (e.g. Input Method).
from nyaovim.
@khalidchawtany that looks like its coming from OSX
@rhysd you might be able to stop that from happening using autocomplete="off"
when not in insert mode.
from nyaovim.
@johnhamelink you were right it is coming from OS X. Disabling press and hold solves the problem for me.
defaults write NSGlobalDomain ApplePressAndHoldEnabled -bool false
from nyaovim.
@rhysd / @justinmk For sequential 1-line scrolling, I find it unlikely that the bottleneck is node-msgpack5. In this case neovim sends ui_scroll
notifications followed by line redraws of the invalidated area, which is a short payload and wouldn't result in noticeable deserialization overhead even if the msgpack implementation is very inefficient.
The best way to handle ui_scroll
notifications is to use a coordinate transformation function from the UI's native toolkit. Here is how the python gtk UI does it, which results in smooth scrolling even though the high level UI logic is implemented in python.
For page scrolling, more lines need to be redrawn, so a slow msgpack implementation could cause the bottleneck, and in this case libmpack would solve the problem. But this is not the only possible bottleneck: Since the UI must maintain the entire screen state in memory, it can be slow to handle burst updates resulted from both scrolling and region redraws. For this we also need to have a C client for Neovim, which will be built on top of libmpack.
After this C client is released(a relatively small layer on top of libmpack), most Neovim UIs built on top of it will get a significant performance boost.
from nyaovim.
Thank you for the comments. I think the problem is that input without modifier (e.g. j
, k
) is caught at <input>
text field. And inputting to text field has some side effects. They may make NyaoVim slow.
I'm going to go to U.S. this week on business trip. So let me check your comments more and try to fix this problem at this week-end or beginning of next week.
from nyaovim.
Related Issues (20)
- Strange redraw behaviour
- Uncaught TypeError: Cannot read property 'editor' of null
- clipboard: error invoking win32yank:
- scrolloff strange update behavior
- q key for command window or recording macros non-functional HOT 1
- can not binding <M-n> key in mac os.
- copy with mouse HOT 1
- yarn global add nyaovim not work HOT 2
- No argument possible HOT 1
- Cannot install in Ubuntu 16.04 HOT 5
- Installation error HOT 2
- NyaoVim always starts with two open buffers
- Not possible to paste on prompt with Ctrl+V or window menus HOT 1
- I cannot open a file directly from command line using NyaoVim HOT 2
- Colorful (subpixel) font rendering
- Would like a way to donate to this project?
- :autocmd FocusGained not working with nvim 0.3.8 HOT 1
- WSL2 support?
- How to change Font
- transparent HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from nyaovim.