richard9404 added a comment. I think we should first think about what are participating in a modularised development environment. In terms of code completion, there are usually four layers:
- a "backend" which knows everything about the language, e.g. ClangSema - a "frontend" which follows some well-known protocol(s), e.g. clangd - an adapter which deals with all kinds of quirks of the frontend and editor and ensures everyone's happy, e.g. vscode-clangd or some magic configuration files for vim lsp plugins - an editor which the user is accustomed to but knows little about the language, e.g. vscode or vim with some lsp plugin Now, the completion behaviours we care about. **the default behaviour** I think ClangSema, as a language backend library, targets more about frontend developers rather than end users, and should provide rich but "pure" information to ensure flexibility. It doesn't seem necessary for it the decide which behaviour is more advantageous, especially for some end user oriented behaviours. In this specific case, I suppose it is more reasonable to either provide an option or return the raw info and let the upper levels to decide what to do. **the slashes** Different editors, under different user settings, have differences in completion behaviour, which are not always distinguishable from LSP's `ClientCapabilities`, e.g.: - whether some key needs to be hit to commit an completion: If hitting `Enter` (or something else) is mandatory and `commitCharacters` are not supported, it should be better for clangd to include the ending slashes in the completion results; but if committing is implicit, it seems more reasonable to let the user hit `/` to trigger another completion, and users of these kinds of editors should be unlikely to hit `Enter` after selecting a completion item - is it easy to forcibly trigger a completion: manually triggering completion is uncommon and most editors would bind it to some multi-key shortcuts, which makes the completion less fluent, or the user will need to `<Backspace>`->`/` if another completion is needed immediately after a directory completion I think clangd should choose a behaviour suitable for the most usual circumstance, while trying to support more cases via options (or init params) and leaving the decision to the adapters. **completion with trailing stuff** When the suffix of a completion item matches with the prefix of the content following the completion point, things get complicated. The backend and language server are able to decide the range that should be replaced, and everything works perfectly as long as the editor correctly support `textEdit`. But an editor without `textEdit` support will turn to `insertText`, and it has to decide whether the "duplication" should be eliminated, which is impossible for a language-natural editor to implement accurately. The editor will either keep them in all cases, or merge them in all cases, producing something like `#include "dir/^.h"` -> `#include "dir/foo.h".h"` or `ret = Func1(ns::^);` -> `ret = Func1(ns::Func2();`. This is indeed a tricky issue. 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
