lsp-based replacement for cc-mode

[sebastiansturm]

I've noticed that whenever C++ editing feels slow, the Emacs profiler indicates that cc-mode is likely to blame for it (which is understandable, given how much it tries to do within emacs lisp, but not useful if I'm also having ccls or clangd running on a dozen otherwise unused CPU cores to do the same job a lot more thoroughly).

Following an old suggestion by @topisani (jacobdufault/cquery#52), I'd thus like to create a bare-bones C++-mode providing nothing but a syntax table and rudimentary fontification of keywords and literals, leaving everything else to lsp-mode. For now I'm using the syntax table from cc-mode, some keywords taken from modern-cpp-font-lock and a few modifications to spacemacs' jump-handlers, a few flycheck checkers, the spacemacs C++ layer, lsp-language-id-configuration and auto-mode-alist.

Seems to work reasonably well so far, though it still has its rough edges. Depending on the responses to this issue (if any), my plan is to either open a GitHub repository sometime soon and use this issue for further discussion, or, if someone else is working on a similar project that is further along already, throw my attempt away and contribute to that other thing instead.

[yyoncho]

Here are a few points I think that we should clear:

1. The mode should be c++ specific or we can create one generic mode which then we can use for all languages.
2. Investigate what vscode "modes" are providing and potentially follow their pattern. The language servers and lsp spec, in general, is driven by vscode needs to provide the full experience. Knowing what vscode does will help us define the minimum set of features that should come from the editor and does not come from the language servers.

[sebastiansturm]

Here are a few points I think that we should clear:

1. The mode should be c++ specific or we can create one generic mode which then we can use for all languages.
2. Investigate what vscode "modes" are providing and potentially follow their pattern. The language servers and lsp spec, in general, is driven by vscode needs to provide the full experience. Knowing what vscode does will help us define the minimum set of features that should come from the editor and does not come from the language servers.

point 2. seems like a good idea to me.

point 1. as well if you're suggesting to build some mode-defining machinery that allows me to quickly stamp out a substrate layer for language XY with custom syntax table and basic fontification. In my opinion the end result should still be an independent mode for every target language so users get all the extension points they take for granted, such as XY-mode-map and XY-mode-hook. Sometimes the name of the mode is relevant, too; I think flycheck uses this to enable/disable language-specific checkers; I personally use it with evil-set-initial-state to have some states disable evil keybindings by default

[yyoncho]

Point 1. was based on the assumption that semantic highlights will be sufficient to cover all font-lock related stuff. Apparently that is not the case.

We should also follow - https://github.com/ubolonton/emacs-tree-sitter/ which in the end my yield a superior font locking solution and then combine it with the semantic stuff that comes from language server.

[sebastiansturm]

Point 1. was based on the assumption that semantic highlights will be sufficient to cover all font-lock related stuff. Apparently that is not the case.

I see. Though even if fontification is completely covered by some other solution such as tree-sitter, wouldn't Emacs users still expect the type of language-specific customizability that usually relies on mode-specific hooks? Do you know some other (reasonably "Emacs-y") way to do that with a single mode for all target languages?

We should also follow - https://github.com/ubolonton/emacs-tree-sitter/ which in the end my yield a superior font locking solution and then combine it with the semantic stuff that comes from language server.

I've heard about that though I haven't tried it so far because it doesn't seem to offer much beyond what lsp already does (and would likely create extra overhead by providing features that are already better handled by lsp language servers?). Also, I find the idea of dynamic modules enticing in principle but the few times I tried third-party dynamic modules (think it was for some other C++ emacs extension at the time) were also some of the few times I managed to crash Emacs, which never happens to me with the separate-process model used by lsp-mode

[yyoncho]

wouldn't Emacs users still expect the type of language-specific customizability that usually relies on mode-specific hooks? Do you know some other (reasonably "Emacs-y") way to do that with a single mode for all target languages?

One potential way to solve that is to autogenerate a derived mode based on lsp-language-id-configuration(i. e. have lsp-base-mode and lsp-LANGUAGE-mode).

and would likely create extra overhead by providing features that are already better handled by lsp language servers?

Based on your previous comment, we still will need a way to handle basic fontification (comments, keywords, etc), right? So we will have to find a solution for that case. But, yes, if the dynamic module solution does not fit for some reason or if it is inferior to lsp-mode solution there is no point to use it..

AFAIK the RUST dynamic modules are more stable due to rust compile time checks.

[yyoncho]

For point 2 - here are vscode plans: microsoft/vscode#77140

[yyoncho]

@sebastiansturm is this still on the table considering tree-sitter?

[sebastiansturm]

no, I agree there's no longer a need for a C/C++-specific base mode, though the idea of having a convenient base-mode generator that defines its own, lsp-based, flycheck checker, and custom syntax highlighter (based on tree-sitter or not) still makes sense. Doesn't make sense to keep this issue open though

[yyoncho]

Closing based on the previous comment.

[laurynas-biveinis]

This seems somewhat related and might be a bit useful for someone: I wrote some code to replace cc-mode indentation with lsp-mode formatting and to disable any electric keys if on-type formatting is active: https://www.reddit.com/r/emacs/comments/ikgfxd/weekly_tipstricketc_thread/g3z9rcb?utm_source=share&utm_medium=web2x&context=3