Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add ]r / [r to go to the next / previous SpellRare #14773

Closed
ColinKennedy opened this issue May 15, 2024 · 0 comments
Closed

Add ]r / [r to go to the next / previous SpellRare #14773

ColinKennedy opened this issue May 15, 2024 · 0 comments

Comments

@ColinKennedy
Copy link
Contributor

Is your feature request about something that is currently impossible or hard to do? Please describe the problem.
Currently there is ]s and [s which go to the next and previous SpellBad or SpellRare in the buffer. This works well if you have a comprehensive dictionary that defines nearly all words, in which case ]s and [s might just hop to instances of SpellRare. But what if your dictionary has missing words? Then you'd have to press ]s repeatedly through 1+ SpellBad just to get to the SpellRare that you meant to jump to.

Describe the solution you'd like
It'd be nice if SpellRare got its own mapping. Since it's currently open, ]r and [r could do the trick.

Describe alternatives you've considered
Writing a function that computes the next jump location and defining the mapping manually. In truth that's what my plugin currently does but a native solution would be faster and less prone to errors.

Additional context
Like [s and ]s, any new mappings should take into account 'wrapscan'.

zeertzjq added a commit to zeertzjq/neovim that referenced this issue May 17, 2024
Problem:  Cannot move to previous/next rare word
          (Colin Kennedy)
Solution: Add the ]r and [r motions (Christ van Willegen)

fixes: vim/vim#14773
closes: vim/vim#14780

vim/vim@8e4c4c7

Co-authored-by: Christ van Willegen - van Noort <github.com@vanwillegen-vannoort.nl>
zeertzjq added a commit to neovim/neovim that referenced this issue May 17, 2024
Problem:  Cannot move to previous/next rare word
          (Colin Kennedy)
Solution: Add the ]r and [r motions (Christ van Willegen)

fixes: vim/vim#14773
closes: vim/vim#14780

vim/vim@8e4c4c7

Co-authored-by: Christ van Willegen - van Noort <github.com@vanwillegen-vannoort.nl>
theofabilous pushed a commit to theofabilous/neovim that referenced this issue May 19, 2024
)

Problem:  Cannot move to previous/next rare word
          (Colin Kennedy)
Solution: Add the ]r and [r motions (Christ van Willegen)

fixes: vim/vim#14773
closes: vim/vim#14780

vim/vim@8e4c4c7

Co-authored-by: Christ van Willegen - van Noort <github.com@vanwillegen-vannoort.nl>
dccampbell added a commit to dccampbell/neovim that referenced this issue May 20, 2024
* version bump

* docs: news neovim#28773

* perf(treesitter): use child_containing_descendant() in has-ancestor? (neovim#28512)

Problem: `has-ancestor?` is O(n²) for the depth of the tree since it iterates over each of the node's ancestors (bottom-up), and each ancestor takes O(n) time.
This happens because tree-sitter's nodes don't store their parent nodes, and the tree is searched (top-down) each time a new parent is requested.

Solution: Make use of new `ts_node_child_containing_descendant()` in tree-sitter v0.22.6 (which is now the minimum required version) to rewrite the `has-ancestor?` predicate in C to become O(n).

For a sample file, decreases the time taken by `has-ancestor?` from 360ms to 6ms.

* feat: remove deprecated features

Remove following functions:
- vim.lsp.util.extract_completion_items
- vim.lsp.util.get_progress_messages
- vim.lsp.util.parse_snippet()
- vim.lsp.util.text_document_completion_list_to_complete_items
- LanguageTree:for_each_child
- health#report_error
- health#report_info
- health#report_ok
- health#report_start
- health#report_warn
- vim.health.report_error
- vim.health.report_info
- vim.health.report_ok
- vim.health.report_start
- vim.health.report_warn

* fix(version): fix vim.version().prerelease

fixes neovim#28782 (when backported)

* fix: extend the life of vim.tbl_flatten to 0.13

`vim.iter(t):flatten():totable()` doesn't handle nil so isn't a good
enough replacement.

* docs(gen_help_html.lua): handle modeline and note nodes

Problem:

'modeline' and 'note' are unhandled in the online HTML documentation.

Some (not all) modelines are parsed by the vimdoc parser as a node of
type 'modeline'.

Solution:

- Ignore 'modeline' in HTML rendering.
- Render 'note' text in boldface.

* fix(health): broken ruby detect neovim#28804

* fix(path): avoid chdir() when resolving path (neovim#28799)

Use uv_fs_realpath() instead.

It seems that uv_fs_realpath() has some problems on non-Linux platforms:
- macOS and other BSDs: this function will fail with UV_ELOOP if more
  than 32 symlinks are found while resolving the given path.  This limit
  is hardcoded and cannot be sidestepped.
- Windows: while this function works in the common case, there are a
  number of corner cases where it doesn't:
  - Paths in ramdisk volumes created by tools which sidestep the Volume
    Manager (such as ImDisk) cannot be resolved.
  - Inconsistent casing when using drive letters.
  - Resolved path bypasses subst'd drives.

Ref: https://docs.libuv.org/en/v1.x/fs.html#c.uv_fs_realpath

I don't know if the old implementation that uses uv_chdir() and uv_cwd()
also suffers from the same problems.
- For the ELOOP case, chdir() seems to have the same limitations.
- On Windows, Vim doesn't use anything like chdir() either. It uses
  _wfullpath(), while libuv uses GetFinalPathNameByHandleW().

* feat(api): broadcast events to ALL channels neovim#28487

Problem:
`vim.rpcnotify(0)` and `rpcnotify(0)` are documented as follows:

    If {channel} is 0, the event is broadcast to all channels.

But that's not actually true. Channels must call `nvim_subscribe` to
receive "broadcast" events, so it's actually "multicast".

- Assuming there is a use-case for "broadcast", the current model adds
  an extra step for broadcasting: all channels need to "subscribe".
- The presence of `nvim_subscribe` is a source of confusion for users,
  because its name implies something more generally useful than what it
  does.

Presumably the use-case of `nvim_subscribe` is to avoid "noise" on RPC
channels not expected a broadcast notification, and potentially an error
if the channel client reports an unknown event.

Solution:
- Deprecate `nvim_subscribe`/`nvim_unsubscribe`.
  - If applications want to multicast, they can keep their own multicast
    list. Or they can use `nvim_list_chans()` and `nvim_get_chan_info()`
    to enumerate and filter the clients they want to target.
- Always send "broadcast" events to ALL channels. Don't require channels
  to "subscribe" to receive broadcasts. This matches the documented
  behavior of `rpcnotify()`.

* vim-patch:9.1.0414: Unable to leave long line with 'smoothscroll' and 'scrolloff'

Problem:  Unable to leave long line with 'smoothscroll' and 'scrolloff'.
          Corrupted screen near the end of a long line with 'scrolloff'.
          (Ernie Rael, after 9.1.0280)
Solution: Only correct cursor in case scroll_cursor_bot() was not itself
          called to make the cursor visible. Avoid adjusting for
          'scrolloff' beyond the text line height (Luuk van Baal)

vim/vim@b32055e

vim-patch:9.1.0416: some screen dump tests can be improved

Problem:  some screen dump tests can be improved (after 9.1.0414)
Solution: Make sure screen state changes properly and is captured in the
          screen dumps (Luuk van Baal)

vim/vim@2e64273

* fix(vim.iter): enable optimizations for arrays (lists with holes) (neovim#28781)

The optimizations that vim.iter uses for array-like tables don't require
that the source table has no holes. The only thing that needs to change
is the determination if a table is "list-like": rather than requiring
consecutive, integer keys, we can simply test for (positive) integer
keys only, and remove any holes in the original array when we make a
copy for the iterator.

* ci: change label `backport` to `target:release`

`backport` is too similar `ci:backport release-x.y` and causes
confusion.

* fix(move): half-page scrolling with resized grid at eob (neovim#28821)

* vim-patch:9.1.0418: Cannot move to previous/next rare word (neovim#28822)

Problem:  Cannot move to previous/next rare word
          (Colin Kennedy)
Solution: Add the ]r and [r motions (Christ van Willegen)

fixes: vim/vim#14773
closes: vim/vim#14780

vim/vim@8e4c4c7

Co-authored-by: Christ van Willegen - van Noort <github.com@vanwillegen-vannoort.nl>

* vim-patch:cf78d0df51f2

runtime(sshdconfig): add basic ftplugin file for sshdconfig (vim/vim#14790)

vim/vim@cf78d0d

Co-authored-by: Yinzuo Jiang <jiangyinzuo@foxmail.com>

* vim-patch:94043780196c (neovim#28831)

runtime(matchparen): fix :NoMatchParen not working (vim/vim#14797)

fixes: neovim#28828

vim/vim@9404378

* refactor(path.c): add nonnull attributes (neovim#28829)

This possibly fixes the coverity warning.

* refactor!: remove `nvim` and `provider` module for checkhealth

The namespacing for healthchecks for neovim modules is inconsistent and
confusing. The completion for `:checkhealth` with `--clean` gives

```
nvim
provider.clipboard
provider.node
provider.perl
provider.python
provider.ruby
vim.lsp
vim.treesitter
```

There are now three top-level module names for nvim: `nvim`, `provider`
and `vim` with no signs of stopping. The `nvim` name is especially
confusing as it does not contain all neovim checkhealths, which makes it
almost a decoy healthcheck.

The confusion only worsens if you add plugins to the mix:

```
lazy
mason
nvim
nvim-treesitter
provider.clipboard
provider.node
provider.perl
provider.python
provider.ruby
telescope
vim.lsp
vim.treesitter
```

Another problem with the current approach is that it's not easy to run
nvim-only healthchecks since they don't share the same namespace. The
current approach would be to run `:che nvim vim.* provider.*` and would
also require the user to know these are the neovim modules.

Instead, use this alternative structure:

```
vim.health
vim.lsp
vim.provider.clipboard
vim.provider.node
vim.provider.perl
vim.provider.python
vim.provider.ruby
vim.treesitter
```

and

```
lazy
mason
nvim-treesitter
telescope
vim.health
vim.lsp
vim.provider.clipboard
vim.provider.node
vim.provider.perl
vim.provider.python
vim.provider.ruby
vim.treesitter
```

Now, the entries are properly sorted and running nvim-only healthchecks
requires running only `:che vim.*`.

* fix(diagnostic): show backtrace for deprecation warnings

Problem: On nvim 11.0-dev, deprecation warnings due to an use of
hard-deprecated APIs such as:
- `vim.diagnostic.disable()`
- `vim.diagnostic.is_disabled()`
etc. are not accompanied by backtrace information. It makes difficult
for users to figure out which lines or which plugins are still using
deprecated APIs.

Solution: use `backtrace = true` in vim.deprecate() call.

* vim-patch:df859a36d390

runtime(sql): set commentstring for sql files in ftplugin

closes: vim/vim#14800

vim/vim@df859a3

Co-authored-by: Riley Bruins <ribru17@hotmail.com>

* vim-patch:36e974fdf3f5

runtime(graphql): basic ftplugin file for graphql

closes: vim/vim#14801

vim/vim@36e974f

Co-authored-by: Riley Bruins <ribru17@hotmail.com>

* vim-patch:4d7892bfb1db

runtime(dart): add basic dart ftplugin file

fixes vim/vim#14793
closes vim/vim#14802

vim/vim@4d7892b

Co-authored-by: Riley Bruins <ribru17@hotmail.com>

* vim-patch:9.1.0421: filetype: hyprlang files are not recognized

Problem:  filetype: hyprlang files are not recognized
Solution: recognize 'hypr{land,paper,idle,lock}.conf' files
          as 'hyprlang' filetype, add hyprlang ftplugin
          (Riley Bruins)

closes: vim/vim#14803

vim/vim@5f1b115

Co-authored-by: Riley Bruins <ribru17@hotmail.com>

* Update CMakeLists.txt

* Create health.lua

---------

Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
Co-authored-by: vanaigr <vanaigranov@gmail.com>
Co-authored-by: dundargoc <gocdundar@gmail.com>
Co-authored-by: bfredl <bjorn.linse@gmail.com>
Co-authored-by: Lewis Russell <lewis6991@gmail.com>
Co-authored-by: Jongwook Choi <wookayin@gmail.com>
Co-authored-by: MoonFruit <dkmoonfruit@gmail.com>
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
Co-authored-by: Luuk van Baal <luukvbaal@gmail.com>
Co-authored-by: Gregory Anders <8965202+gpanders@users.noreply.github.com>
Co-authored-by: Christ van Willegen - van Noort <github.com@vanwillegen-vannoort.nl>
Co-authored-by: Christian Clason <c.clason@uni-graz.at>
Co-authored-by: Yinzuo Jiang <jiangyinzuo@foxmail.com>
Co-authored-by: Riley Bruins <ribru17@hotmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant