-
-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
Inconsistent quote matching behaviour with multiple selections #7012
Comments
cc @dead10ck I skimmed the code and it looks like auto pairs doesn't actually look for pairs in case of same-char pairs (like |
What if count the number of "same-char" symbols in a line? If a number is odd, then put only one char. |
That would be a pretty bad heuristic and would often endup to autpairs not firing when they should. |
Yeah this is unfortunately behaving as designed currently. It intentionally does not auto pair when the preceding char is an alphanumeric in order to handle apostrophes in prose. Using TS for more language aware heuristics might help in some cases, but would be a maintenance heavy approach, since every grammar will have a different set of nodes to look for. I'm not sure what the solution is here. |
There seems to be some prior art around using TS in nvim: https://github.com/windwp/nvim-autopairs#treesitter It seems they implemented the following rules:
So my idea for solving this would be:
|
The problem with TS is that it works very inconsistently depending upon whether it can recognize the node you're starting to type when it's incomplete. Specifying to ignore auto pairs inside line-wise comments or an already-complete string literal would work fine, but not for let foo: &'static str = "foo"; The complete line parses to: (let_declaration
pattern: (identifier)
type: (reference_type
(lifetime
(identifier))
type: (primitive_type))
value: (string_literal)) But as we're typing it, e.g. once we get here: let foo: &' It does not recognize that we're starting a lifetime specifier (ERROR
(identifier)) We should also consider that this problem also affects plaintext files, as in the example given in this issue, where arguably the omission of the pair is more frequently desired than it is in code, since plaintext is more often prose. Moreover, I suspect the simple even/odd check will not work well in cases of plaintext prose since any apostrophes will throw off the count, and the result would be that sometimes it omits the auto pair and sometimes it doesn't, seemingly at random depending on how many apostrophes are used within that sentence. |
Hmm yeah for plaintext I think we can't do much better than we are currently doing. Altough the even/odd matching could still be used for double quotes since those are not really used like an apastrope. For programming languages tree sitter could just be added as an enhancement (basically do better if we can). Regarding error nodes TS actually gets this right most of the time: fn bar(){
let foo : &
let foo = 2;
} here fn bar(){
let foo = 2;
let foo : &
} we don't have an auto pair for |
Oh interesting. Yeah agreed, I think it makes sense to use TS where it can concretely improve the situation, like comments. But yeah, I share your fear that we can't really do much better for plaintext than we do now. There's simply not enough information to divine when a single quote should be paired and when it's just an apostrophe. |
I think its fair to say that #8294 closes this. There are cases where having a plaintext version is useful so I would like to keep the current For most cases you will be able to use |
Summary
See screenshot:
This is the result of a ' on a multiple selection.
On some lines, only a single quote character is added (correct). On some, two.
(It looks like if the line ends with a dot, two single quotes are added. If there is no dot, just one.)
Reproduction Steps
See summary.
Helix log
n/a
Platform
Linux
Terminal Emulator
WezTerm
Helix Version
22.12-489-g786c8c8b
The text was updated successfully, but these errors were encountered: