Code refactor actions are disabled in CDT LSP editor

[emaayan]

when using the LSP editor code refactor such as extract to method are disabled

OTOH opening them via the standard CDT editor they show up

this the version stack i'm using

[jonahgraham]

I think there are multiple (very connected) bugs here:

1. The legacy C/C++ Editor's actions are displayed (correctly disabled, bug confusingly) when in the C/C++ perspective. Opening a Java file has the same issue:

2. The LSP provided refactorings aren't being exposed to the user in the same way as previous flows. AFAICT LSP4E doesn't contribute to the top-level Refactor menu. That probably needs to be raised in https://github.com/eclipse-lsp4e/lsp4e - or is CDT LSP expected to add such contributions. For example, rename is in the context-menu Refactoring submenu, but the Code Actions submenu has some of the items we are used to seeing in the Refactor menu (like extract expression)

The CDT actions are retargettable, so theoretically CDT LSP could add the new targets.

Not sure what the preexisting thoughts in this area are. @ghentschke is this an area that has already been discussed?

[emaayan]

I think there are multiple (very connected) bugs here:

1. The legacy C/C++ Editor's actions are displayed (correctly disabled, bug confusingly) when in the C/C++ perspective. Opening a Java file has the same issue:

2. The LSP provided refactorings aren't being exposed to the user in the same way as previous flows. AFAICT LSP4E doesn't contribute to the top-level Refactor menu. That probably needs to be raised in eclipse-lsp4e/lsp4e - or is CDT LSP expected to add such contributions. For example, rename is in the context-menu Refactoring submenu, but the Code Actions submenu has some of the items we are used to seeing in the Refactor menu (like extract expression)

The CDT actions are retargettable, so theoretically CDT LSP could add the new targets.

Not sure what the preexisting thoughts in this area are. @ghentschke is this an area that has already been discussed?

not seeing any code actions in LSP editor..

[ghentschke]

Not sure what the preexisting thoughts in this area are. @ghentschke is this an area that has already been discussed?

No, we haven't discussed this issue yet (AFAIK).

The CDT actions are retargettable, so theoretically CDT LSP could add the new targets.

That seems a good solution to me.

[ghentschke]

not seeing any code actions in LSP editor..

The code actions proposals depend on the selected code. Clangd decides if a refactoring can be made:

[emaayan]

not seeing any code actions in LSP editor..

The code actions proposals depend on the selected code. Clangd decides if a refactoring can be made:

that's that i thought but no matter what selection i chose i see no code actions.

[jonahgraham]

There are some code actions, for example:

We are reliant on the Code Actions that clangd provides here, and AFAICT clangd don't document them well. For example, when clangd 15 was released there were some entries in their release notes and the design walk through references the code from the docs, but that is not user docs.

[emaayan]

There are some code actions, for example:

We are reliant on the Code Actions that clangd provides here, and AFAICT clangd don't document them well. For example, when clangd 15 was released there were some entries in their release notes and the design walk through references the code from the docs, but that is not user docs.

thanks, i've finally managed to get this particular one appear , but it does seem very limited.

[jonahgraham]

thanks, i've finally managed to get this particular one appear , but it does seem very limited.

Glad to hear that you got something working - the clangd is still more limited in that regard. In the distant past a lot of refactorings (and Codan checks) in CDT were contributed by university students as part of their master's degrees. We are relying on the clangd ecosystem here, so this is perhaps a third item for my list for the multiple bugs. This one however is best reported to clangd itself.

[emaayan]

thanks, i've finally managed to get this particular one appear , but it does seem very limited.

Glad to hear that you got something working - the clangd is still more limited in that regard. In the distant past a lot of refactorings (and Codan checks) in CDT were contributed by university students as part of their master's degrees. We are relying on the clangd ecosystem here, so this is perhaps a third item for my list for the multiple bugs. This one however is best reported to clangd itself.

i'm not sure exactly what i would be reporting on as the effects are only seen on eclipse.
this whole started as i am using espressif-IDE which recently moved to LSP https://developer.espressif.com/blog/espressif-ide-lsp-support/ because they support newer C standards, and that took away refactoring, so now i need to workup a strange process where i "re-open" the source in the legacy editor, do my refactor and get back to the original LSP editor.

[jonahgraham]

i'm not sure exactly what i would be reporting on as the effects are only seen on eclipse.

clangd is the "provider" of refactorings going forward, but...

this whole started as i am using espressif-IDE which recently moved to LSP

... as you are using a commercial product then in the first instance contacting them makes sense. For example, if you don't need newer C++ standards for your coding, then always using the legacy editor makes sense to me.

cc: @kolipakakondal

[emaayan]

it's not a product it's just a plugin , you download individually, or download the eclipse bundles with it. it's just how i noticed it in the first place.

[jonahgraham]

Thanks for the clarification and the feedback. I hope that as we migrate to clangd based flows future development effort into things like refactoring go to the correct place. As for "product", I meant it was a product in the sense that that Espressif, a company, makes it available and should be supporting their users (you). I tagged @kolipakakondal from their team so they can weigh in on what they expect their users to do in this situation. Espressif are leading the way in that they are one of the first companies to make an Eclipse product based on cdt-lsp available to their users. I do expect that will need future refinement contributed to the open source by Espressif and other interested parties.

[emaayan]

thanks, btw i should also add that the extract to variable feels very cludgy to me and that i can barely rename it, it also seems like rename hot ley f2 is overridden by default.

…

On Sat, Dec 28, 2024, 19:49 Jonah Graham ***@***.***> wrote: Thanks for the clarification and the feedback. I hope that as we migrate to clangd based flows future development effort into things like refactoring go to the correct place. As for "product", I meant it was a product in the sense that that Espressif, a company, makes it available and should be supporting their users (you). I tagged @kolipakakondal <https://github.com/kolipakakondal> from their team so they can weigh in on what they expect their users to do in this situation. Espressif are leading the way in that they are one of the first companies to make an Eclipse product based on cdt-lsp available to their users. I do expect that will need future refinement contributed to the open source by Espressif and other interested parties. — Reply to this email directly, view it on GitHub <#386 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADGP5MCQHFFMWA3MD6YJ6YD2H3QDVAVCNFSM6AAAAABTU3AOTWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNRUGM4DSOJRG4> . You are receiving this because you authored the thread.Message ID: ***@***.***>