sammccall added a comment. Thanks for digging through this!
Adding an option doesn't avoid a decision about what the behavior will be. >99% of users will use the default for something as fine-grained as this. So we need to find a default that works well for most people. And if it's good enough to be the default, it's probably good enough to be the only behavior - supporting multiple has high costs and benefits few people. As for behavior, it seems there's a few different changes/aspects worth looking at: **Inserting trailing quotes after filenames** The advantages: - don't have to type the quote, or remember whether it's `>` or `"` - makes the file/directory distinction in the completion list obvious The disadvantages: - looks funny in completion list (I haven't included issues if the line already has more text and a closing quote here, as we have to consider this case carefully either way) My take here is that inserting the trailing quote is somewhat useful and people quickly get used to it. What do you think? **Inserting slashes after directories** The current workflow (with the slash inserted) is: 1. start typing directory name 2. select completion item 3. hit enter or similar 4. start typing filename, or hit ctrl-space etc The proposed workflow is: 1. start typing directory name 2. select completion 3. hit slash This is certainly a better workflow, especially you don't know the first character of the next path segment (well, at least for US keyboard layout users where slash is easy to reach). My main concerns are a) may not be available in all editors, b) users may not know about it and use it. 1. start typing directory name 2. select completion 3. hit enter or similar 4. hit slash which is pretty clumsy. One option would be to check whether the client has `commitCharacter` support. If so, omit the slash, and send slash as a `commitCharacter`. Otherwise include the slash... This obviously solves the editor but not the user problem. **Handling the rest of the line** We may not be completing at the end of the line. This happens if the user completes in the middle of the file path, or the editor has inserted a matching quote, etc. Now we need to decide how much of the line we're going to replace. Various API contracts mean this should be the same for every completion item in a given context. We can re-insert text that already exists in the replaced range (e.g. closing quotes), but the cursor will be placed on the right of it. Let's look at `#include "a/b^c"` where c might be empty. (There are other cases, but I think this is the most important). Our main options are: 1. replace b, c, and `"` with the completion (and quote) 2. replace b and c with the completion 3. replace b with the completion Option 3 is dominated by option 2 I think - it tends to produce nonsense tokens. So only 1 and 2 are worth considering. Advantages of replacing the closing quote: - is consistent with inserting closing quotes elsewhere, which seems like useful behavior elsewhere - puts us at the end of the line after the completion, ready to hit enter Disadvantages of replacing the closing quote: - less jarring when completing a directory, as it doesn't eat the closing quote Are there others? This one seems like a wash to me, and I'm comfortable with the current behavior. In particular I don't see the conflict between inserting quotes and editors auto-pairing quotes that you mention. Can you elaborate? --- I don't want to jump to a conclusion, but I would at least figure that the most important part of this change/issue with current behavior is the workflow around completing a directory name. Is that right? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D64391/new/ https://reviews.llvm.org/D64391 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
