Improve documentation on move right

Question

Improve documentation on move right

sdondley opened this issue a year ago · comments

I'm trying to learn this plugin but having trouble with the documentation which isn't providing a lot of clarity for me on what "move right" does. All I see is this setting:

local enable_moveright = true

And this:

      -- don't move right when repeat character
      :with_move(cond.none())

I don't know what these things mean. Some kind of example would be helpful.

Benoit de Chezelles · Answer 1 · Tue Aug 15 2023 22:33:20 GMT+0800 (China Standard Time)

You can find documentation about the Rule API in the Wiki:
https://github.com/windwp/nvim-autopairs/wiki/Rules-API#controlling-rule-behavior

Alternatively I renamed the methods to be easier to read & understand:
https://github.com/bew/dotfiles/blob/dacd162c24edec9ddc2b02b80162dcdf4d7e5cf0/nvim-wip/lua/mycfg/plugs_for_file_editing.lua#L357-L365
So that snippet would be :end_moves_right_when(cond.never) meaning that when you type the end char of the pair, the plugin will always insert that end pair instead of (usually) just moving the cursor to the right (after the existing end pair for example if it exists)

I believe my renames are much more readable and easier to understand in the config.
@windwp What do you think about these, would you accept a PR to change the names like this (keeping the old ones for backward compat) ?

Steve Dondley · Answer 2 · Tue Aug 15 2023 22:46:52 GMT+0800 (China Standard Time)

OK, thanks.

This is one of the things things that annoys me about autopairs modules. If I have to type the close pair anyway, what is the plugin really saving me from? I seem to remember trying one years ago in vim where I could hit the tab key and jump out from between the pairs. I have no idea what it was.

So anyway, to address my annoyance, I just wrote this little function to jump over the closing end of the pair:

local function jump_over_closing_pair()
  local line = vim.api.nvim_get_current_line()
  local col = vim.api.nvim_win_get_cursor(0)[2]
  local char_to_right = string.sub(line, col + 1, col + 1)
  local chars_to_jump = { '"', ")", "]", "}", "'", ">" }

  if vim.tbl_contains(chars_to_jump, char_to_right) then
    vim.cmd("stopinsert")
    vim.api.nvim_feedkeys("la", "n", true)
  else
    vim.cmd("stopinsert")
  end
end

vim.keymap.set("i", "<esc>", jump_over_closing_pair, { noremap = true, silent = true })

Here, if you hit <esc> next to a closing pair, it takes you out of insert mode automatically and puts you back in insert mode after the closing pair. Saves me from hitting the shift key in combo with an awkward punctuation mark to type. In the unusual case I don't want to be in insert mode, I hit <esc> twice.

woulfenrir · Answer 3 · Thu Aug 31 2023 14:33:52 GMT+0800 (China Standard Time)

I am having a similar issue with the ':with_move' behavior as well. I am trying to add an autopair match for '<', '>', where the autopair only fires if '=' does not follow immediately after the starting character, '<'. I have written this:

lua

local npairs = require('nvim-autopairs')
local Rule = require('nvim-autopairs.rule')
local cond = require('nvim-autopairs.conds')

local ruleArrows = Rule("<[^=]$", ">")

ruleArrows
    :use_regex(true)
    :with_move(cond.done())

npairs.add_rule(ruleArrows)

This works well in triggering the pair only if '=' is not present immediately after the opening character '<'. The issue is that the cursor moves to the right of the closing character, '>' regardless of what key I press. For example, when I try to type a "<div>" tag I get the following behavior:

Typing '<d' --> '<d>' (so far so good; now the expectation is that after I type 'i', the cursor will remain within the '<d>', and look like '<di>' except...) --> typing '<di>' --> '<d>' (with the cursor now to the right of '>'). Now if I manually bring the cursor back inside '<d>' to finish typing the intended '<div>', the cursor continues moving to the right of the '>' character, regardless of the key that I type. Now the expectation is that, that should only happen when I press '>' next to the closing character, but instead it happens with any key press, essentially only allowing me to make tags with only one character inside them.

Tyler Barnes · Answer 4 · Thu Oct 05 2023 06:12:18 GMT+0800 (China Standard Time)

OK, thanks.

This is one of the things things that annoys me about autopairs modules. If I have to type the close pair anyway, what is the plugin really saving me from? I seem to remember trying one years ago in vim where I could hit the tab key and jump out from between the pairs. I have no idea what it was.

So anyway, to address my annoyance, I just wrote this little function to jump over the closing end of the pair:
local function jump_over_closing_pair()
  local line = vim.api.nvim_get_current_line()
  local col = vim.api.nvim_win_get_cursor(0)[2]
  local char_to_right = string.sub(line, col + 1, col + 1)
  local chars_to_jump = { '"', ")", "]", "}", "'", ">" }

  if vim.tbl_contains(chars_to_jump, char_to_right) then
    vim.cmd("stopinsert")
    vim.api.nvim_feedkeys("la", "n", true)
  else
    vim.cmd("stopinsert")
  end
end

vim.keymap.set("i", "<esc>", jump_over_closing_pair, { noremap = true, silent = true })
Here, if you hit <esc> next to a closing pair, it takes you out of insert mode automatically and puts you back in insert mode after the closing pair. Saves me from hitting the shift key in combo with an awkward punctuation mark to type. In the unusual case I don't want to be in insert mode, I hit <esc> twice.

This is genius, thanks for this snippet! I agree this is the most annoying thing about autopairs, but now it's perfect

EDIT: started to find this a bit annoying when editing existing code, but awesome when writing new code. So I mapped it to <S-esc> instead. Seems much nicer so far.

EDIT2: that also got annoying. I just added control-l and control-h maps instead:

vim.keymap.set("i", "<C-h>", function()
  vim.cmd("stopinsert")
  vim.api.nvim_feedkeys("ha", "n", true)
end)
vim.keymap.set("i", "<C-l>", function()
  vim.cmd("stopinsert")
  vim.api.nvim_feedkeys("la", "n", true)
end)

stale · Answer 5 · Tue Dec 12 2023 11:22:53 GMT+0800 (China Standard Time)

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

Benoit de Chezelles · Answer 6 · Wed Dec 13 2023 06:46:19 GMT+0800 (China Standard Time)

I'm surprised a plugin like tabout.nvim wasn't mentioned here, here you go (:

@windwp I'd still be interested what you think about the renames I proposed in my comment above 🤔

windwp · Answer 7 · Tue Feb 06 2024 21:39:12 GMT+0800 (China Standard Time)

rename will make a breaking change to user config. your new name is too long and it is different on every function . it more easy to type with then the autocomplete will show all suggestion.

Benoit de Chezelles · Answer 8 · Wed Feb 07 2024 01:26:26 GMT+0800 (China Standard Time)

Thanks for your answer, I'd argue that we read code more often than we write it, so the longer names feels easier to me because they're self-descriptive.

But I understand your point. Then maybe we could improve/add documentation for the different Rule functions, so that when you're navigating through the autocompletion suggestions the attached documentation helps understand what each does?

stale · Answer 9 · Wed Apr 10 2024 08:18:57 GMT+0800 (China Standard Time)

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.