eskk.vim
eskk.vim copied to clipboard
vim-skk
Adding annotations to user dictionary entries seems to be glitchy
That's me again :) Hopefully you haven't got tired of my issues.
I must admit, I don't have the need to add custom entries yet. It's just that this prompt pops up every now and then, and I don't really know what I'm supposed to do, other than pressing Esc/Ctrl-c (somehow) twice. I didn't. Right now I think I get the hang of it for the most part. But it doesn't seem to always work properly.
Disclaimer. I'm going to use (supposedly) imaginary words.
I type, ;asuri<Space>, it asks me for the converted version, I type, ;asu<Space>ri<CR>. This way it works.
Now let's try to add an annotation: ;asuri<Space>, ;asu<Space>ri<Ctrl-j>;annotation<CR>. It adds the word all right, but when I press Enter, ▽ is still in the buffer, and it doesn't seem like it finished properly. Am I doing it wrong? Missing something?
On a side note, is there an easier (than double-Esc/Ctrl-c) way to cancel adding an entry?
On a side note, is there an easier (than double-Esc/Ctrl-c) way to cancel adding an entry?
I think empty enter is the better way to cancel.
The twice reason:
You have pressed space key twice. They are adding an entry and henkan. The states are stacked.
The first cancel is adding an entry.
But henkan is not canceled! So you want to cancel both, you need to press esc keys twice.
Reason.
https://github.com/tyru/eskk.vim/blob/8e3f82a838452b44062c567dd8aad5f613931ec2/autoload/eskk.vim#L2128
If you input annotation, the eskk is disabled to input ;.
So insert word is canceled.
If in eskk#util#prompt() eskk restores eskk state, it is better.
But I don't know how to implement it.
Great.
Regarding the cancelling thing. It appears Enter, Esc, Ctrl-C (and Ctrl-G for that matter) are not much different in that regard. I'm mostly running vim (or usually nvim) in tmux. And with tmux it looks like this:
Then I press any of those:
And for me the last state looks like it's asking for something else (after all, the cursor is still at the command bar), although in a weird way (empty prompt). Now I see, that at this point I can just continue typing. Without tmux it looks a bit different, although still confusing:
I'm not sure, but it might be just how vim works (or vital). Meaning, there's not much to be done about it.
And for me the last state looks like it's asking for something else (after all, the cursor is still at the command bar), although in a weird way (empty prompt). Now I see, that at this point I can just continue typing. Without tmux it looks a bit different, although still confusing:
Yes. I know the behavior. But I don't know it can be fixed.
But it's introduced by eskk, isn't it? I can't see such effect after input() or vital's input_safe(). Do you know what causes it? Which command (file:line)?
Yes. I think it is langmap behavior. And eskk implementation is complex and hard to debug. You can read the code. It is open source
You can read the code.
I've been doing it in my free time for a while now :) I'd like to find the cause so if you have any pointers... I've got a hunch that after eskk#filter() it doesn't stop, that some code is executed afterwards...
The issue comes down to this:
1.vim:
function! F1()
call input('> ')
redraw
echo ''
return ''
endfunction
inoremap <expr> a F1()
$ nvim -u NONE +'so 1.vim'
Then press a twice (enter Insert mode, and trigger the mapping).
Coming back to eskk, input(...) happens in s:Dictionary_remember_word_prompt(), redraw | echo '' is s:clear_command_line(), and return '' is eskk#filter() that after the prompt returns nothing.
Now, I'm not sure why it should be redraw and echo ''. But after trying different combinations, I can tell this, the cursor is still in the command line. To make it return to the buffer, eskk#filter() should return something, e.g. return 'a^H'. This way it looks okay even without redraw and echo. What do you think?
s:clear_command_line() is also used here. Can you help me make eskk get there (steps to reproduce)?
P.S. How do you run the tests?
Now, I'm not sure why it should be redraw and echo ''.
It is to clear the input() command line.
You can test it by to remove the redraw and echo.
The problem seem only neovim. I have tested Vim8 and it does not happen...
So it cannot fix it in eskk.vim side. You should report the problem in neovim issues instead.
Let us see what neovim developers has to say...
P.S. I believe returning the cursor back to the buffer is more important than clearing the command line. But I must admit, that my solution to that doesn't look beautiful. Maybe together with neovim developers we can come up with a better solution.
To be honest, I hoped we could come up with a better solution. I can't help but feel that echo '' there is not really needed. Or shouldn't be there. And I was going to investigate what caused the nvim regression, but haven't found the time yet.
On a side note, @tyru, are the tests still runnable? How do I run them?
I can't help but feel that echo '' there is not really needed.
I have said it is to clear the command line.
I probably wasn't clear enough. Let's take vim.
redraw after input():
echo '' after input():
redraw | echo '' after input():
That is, redraw before echo '' is useless, as far as I can see. And if you ask me, having only redraw is preferable, since this way vim goes back to indicating the current mode. Especially considering that eskk alters the indicator (--INSERT (lang)--) to show that it's active.
Having that said, redraw and echo '' together might have served some purpose in the past. And maybe they even cover some case these days. So I can understand if you won't fix it.
P.S. The neovim guys started working on the issue, and I expect a fix to appear one of these days in the master branch. Most likely, if has('nvim') | return | endif isn't gonna be needed in the future. I'm going to keep an eye on it, and notify you of the time it's released.