It’s been two years since denops v1 was released. However, denops is still not widely recognized as the ‘standard’ among Vim users because most Vim plugin developers do not use it, possibly due to a lack of knowledge or a limited perspective on denops for plugin development. This talk aims to provide a quick introduction to denops and discuss the advantages and disadvantages of endorsing it for plugin developers, with the goal of making it the ‘standard’ choice for all Vim users.
I’m a programmer who wears many hats at work, handling everything from front-end and back-end development to management tasks and technical consultations. My favorite languages are Rust and TypeScript, and I’m a devoted fan of Neovim as my preferred text editor. I’m the type of person who relishes customizing my environment to align with my preferences, and I’ve created numerous Vim plugins to make it happen. This time, I joined in this conference to promote Denops.
When developing a Vim plugin, Vim script is a primary language. However, for a plugin that’s heavily involved with the target language, there’s a case where Vim script is not enough. Luckily, Vim enables us to develop a plugin with the same language as the target. In this talk, I’ll show how to develop a Vim plugin that works with RSpec using Ruby. I’ll also provide a case where LSP is not the best tool.
I made japanese input method “skkeleton” and using everyday. When made it, significantly referenced “eskk.vim” which I used before. but unlike that, using new APIs and external process framework. I’m going to talk about these.
Second part is why use within text editor for that much, why highly affinity input method.