|
1 |
| -global-state |
2 |
| - [X] finish refactoring nvim, rpc |
3 |
| - [X] from debug session, stop, then start (restart) should work |
4 |
| - [X] make sure sample plugins still work |
5 |
| - [_] clojure socket repl plugin refactor |
| 1 | +Versioning |
| 2 | + re: https://github.com/neovim/neovim/pull/5535 |
| 3 | + re: https://github.com/neovim/neovim/pull/5386 |
| 4 | + |
| 5 | + [_] an we start writing tests for these things? |
| 6 | + [X] We'd have to start an nvim --embed, and maybe specify the NVIM_... ? |
| 7 | + [X] Then, we connect |
| 8 | + [X] Test version validation |
| 9 | + [_] Integration test |
| 10 | + -insert some text in current buffer |
| 11 | + -command split the a new buffer put some stuff in it |
| 12 | + -command switch back to the original buffer |
| 13 | + -get the text of current buffer |
| 14 | + |
| 15 | + Tough to figure out exactly how to test against multiple version of |
| 16 | + Neovim's API. For now, let's just do this basic test, and document |
| 17 | + the version of Neovim used. |
| 18 | + |
| 19 | + Following the philosophy described above, we need |
| 20 | + [_] Make the user specify required API level on `connect` |
| 21 | + |
| 22 | + [_] Change the api to one function `exec`, pass the op as the first |
| 23 | + arg, and then use varargs, or a collection of args. |
| 24 | + Implementing `exec` and `exec-async` should include |
| 25 | + version-supported? check, maybe assume nvim_command will always |
| 26 | + be supported. |
| 27 | + |
| 28 | + [_] On `connect`, intern dynamically created functions similar to the |
| 29 | + macros we use now. |
| 30 | + |
| 31 | + [_] Change the existing samples to use this, maybe only support one |
| 32 | + sample. |
| 33 | + |
| 34 | + [_] Make a `doc` function that basically does `ns-publics` |
| 35 | + |
| 36 | + [_] Update the docs, including video? |
| 37 | + In terms of the docs, we'll take a similar approach that other |
| 38 | + AWS client libs have taken, we'll steer them heavily toward |
| 39 | + the *actual* docs, and using `nvim-get-api-info`. |
| 40 | + |
| 41 | + [_] Tag the existing version, bump the version (project & github), |
| 42 | + and release. |
| 43 | + |
| 44 | + Why aren't we doing anything statically? |
| 45 | + Although I'd prefer actual functions in source code, I don't like |
| 46 | + That I'd have to change code when they version the API |
| 47 | + But, more importantly, since the api_level supports a range of |
| 48 | + levels, I'd either |
| 49 | + have to support side-by-side versions |
| 50 | + but that would be easy with codegen & ns2, ns3, etc. |
| 51 | + make patches to all versions, if version by api-level |
0 commit comments