| Summary: | Suggestion: rename "LSP Client" menu to "Code Insight" or similar | ||
|---|---|---|---|
| Product: | [Applications] kate | Reporter: | Ellie <el> |
| Component: | general | Assignee: | KWrite Developers <kwrite-bugs-null> |
| Status: | RESOLVED INTENTIONAL | ||
| Severity: | wishlist | CC: | 6yearold, waqar.17a |
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | All | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Ellie
2020-06-21 15:01:10 UTC
Additional note: after browsing the menus more, the change I'm suggesting here would also allow moving "Tools > Invoke Code Completion" into such a "Code Insight" (or similar) menu where I think it would be better grouped, even if it possibly not always relies on LSP under the hood. I don't think that "LSP" abbreviation is too technical. To the contrary, it quickly draws attention. For instance, I didn't even know that Kate got LSP support and once I saw it in the plugins list, I instantly enabled it and got all that fancy stuff working. The name makes sense in the plug in list, not in the UI. Users of classic IDEs in particular may not know what LSP means, and it makes no sense to name it in the UI after some backend technique rather than the task and then to move out stuff that is for the same task (that is, deep insight about the code/"Code Insight") but just HAPPENS to be not based on LSP for some of the features. It makes for a cluttered and harder to understand UI, so I fail to see how it is a reasonable menu structure. Nobody cares if a menu item happens to be LSP-backed or not. Closing this as imo LSP is clear enough. It is disabled by default, so if you are enabling it, it is highly likely that you already know what it is |