fxliang
fxliang
扒了下代码，每个候选都是重新算的位置，如果要不跳动应该先过一遍要显示的computeCandidate中是不是有任意一个有commentOnTop的显示需求，调整一下应该就可以解决的 当然如果这个状态就是设计意图，那就算了 ```java // Draw candidates if (computedCandidate instanceof ComputedCandidate.Word) { float wordX = computedCandidate.getGeometry().centerX(); float wordY = computedCandidates.get(0).getGeometry().centerY() - (candidatePaint.ascent() + candidatePaint.descent()) / 2; if (shouldShowComment) { String comment...
试改了下，让不显示comment、comment_on_top: false、无comment这3种状态下的候选基本居中（有些y坐标参数没有完全消化暂且叫基本居中），然后在有comment和无comment的时候候选会上下跳动，似乎也不是太好看   
> @fxliang 我感觉固定一下整个候选栏的高度就好；我看有 comment 时把候选词都下移一点也还挺舒服的 @WhiredPlanck 现在的候选栏应该是 candidate_view_height 和 comment_height的相加，如果再加一个参数，会怪，算死人，容易出来一些异常状态吧（比如最近改的那个keyboard_height参数和key_height之间的关系就已经让人不好理解） 其实原来的方式comment_on_top为true的时候只要将comment_height和comment_text_size设置合适的大小，就也不会太难看了 另外尺寸相关的最好固定单位才好理解，比如preset_keyboards里面的width是横向的百分比，然后高度方向又另外一个单位（似乎是象素？）就很怪
> @fxliang 重构任务艰巨 🤣 建议键盘内的尺寸都用百分比来一表示，实际像素尺寸是height和width分别和keyboard_height和keyboard_width计算获得。 然后keyboard_height和keyboard_width也可以用屏幕百分比来表示，主要是因为键盘不能移出屏幕边沿。 横屏的时候可以用keyboard_height_land和keyboard_width_land设定。 浮动键盘的可以用keyboard_height_float和keyboard_width_float设定。 这样键盘内部的尺寸单位就基本统一了。
any update? I check latest version, it seems not solved. adding some code here to tell nvim backend to exit, might be the solution? [https://github.com/equalsraf/neovim-qt/blob/master/src/gui/mainwindow.cpp](https://github.com/equalsraf/neovim-qt/blob/master/src/gui/mainwindow.cpp#L250-L269) ```c++ void MainWindow::closeEvent(QCloseEvent *ev) {...
> manually``` :confirm qa``` is ok, so does manully using ```:q``` but by click the close button, no. only nvim-qt.exe exit, nvim.exe with sub processes(seems for coc) left there alive....
no error msgs shown... I try start nvim-qt from powershell( windows terminal), it close normally, no processes left. I make a lnk to nvim-qt -- -u NOCFG, no plugins, close...
 
disable coc, close the window with mouse, then nvim.exe,conhosts.exe, python.exe left back.
> Ok I've come across something that might be related to this one. > > See #1076 for a possible fix. Although we might become too aggressive in killing the...