Christian Clason

That certainly works; if you want my opinion on option 2, I would need more details ;)

My concern was that `make-range` seems strictly more powerful; whether that power is used currently I don't know. (And whether the implementation actually works correctly...)

> right now the range is calculated as . Same logic as make-range Ok, then there's really no reason. I was thinking -- as has been requested a few times...

Ok, so there is worth in the directive; the question is whether we need it _here_. Since I am not familiar with the queries here, I will leave this to...

The idea is that make-range could capture the range between different nodes (and not just for text objects -- which is out of scope for this repo, of course). If...

@ribru17 do we want to go through with this? if so, it needs a (big) rebase. (I worry a bit about reusing `make-range` in an incompatible fashion, but maybe we...

Actually, now that Nvim 0.10 has been out a while and had its first bugfix release, I feel much more comfortable bumping the minimum version on `master`. So how about...

Look, the reasoning here is quite simple: We _cannot_ add configuration options for every single thing ("but mom, I just want _this_ single thing!" -- yes, but other people want...

> I will say that it is sad that Neovim has to adapt to how exactly things are done in VS Code because everything is controlled by Microsoft (editor, protocol...

# Resolution The LSP specification is unambiguous about inlay hints having a specified position _where they should appear_ (even declaring where multiple hints with the same position should be rendered)....