Very disappointed in the decision to use the C/C++ (LSP) editor

[gtjoseph]

I wish I'd have had the time to participate in the 3.0 beta but I simply didn't so here's my somewhat late feedback...

The LSP editor is a HUGE step backwards in terms of features.

• Doesn't use the C/C++ Code Formatter
• Doesn't even obey the tab size and type set in General/Editors
• Only basic Save actions.
• Missing context menu items like Declarations and References.
• It's SLOW
• No code folding for preprocessor #if/#endif
• No coloring for code deactivated by preprocessor #if/#endif
• The hovers are overly intrusive
• The Outline doesn't include macros, doesn't allow grouping, doesn't allow hiding.
• There are more but you get the idea.

The only thing wrong with the standard CDT C/C++ editor was that indexing was mostly broken but there were ways, albeit clunky and sometimes unreliable, to get it to work. We can't even do that now because you've disabled the ability to make it the default editor and it seems the indexer is now completely non-functional for esp-idf with the CDT editor. Why couldn't you have just fixed the indexer to work with the CDT editor???

[ESP_kondalkolipaka]

Hello,

I have published a blog post on why we have moved to the LSP Editor and what it offers. Please check here
https://developer.espressif.com/blog/es ... p-support/

Many users have been reporting that the Eclipse CDT Editor/Indexer is unable to resolve headers and compilation units when working with ESP-IDF v5.0 and higher. This issue arises because the Eclipse CDT only supports the versions up to C++14. However, ESP-IDF v5.0 uses C++20 (with GCC 11.2) and ESP-IDF v5.2 uses C++23 (with GCC 13.1).

By adopting an LSP-based editor, Espressif-IDE v3.0.0 enables support for newer C/C++ standards required by more recent versions of ESP-IDF. Conversely, the old CDT C/C++ editor and its Indexer are not supported for ESP-IDF projects anymore. However, you can still use the CDT C/C++ editor for non-ESP-IDF projects as-is.

Improving the CDT Parser with the new language grammar is a huge task that requires dedicated resources. However, we feel this is not a productive task as the world is moving towards LSP-based editors; therefore, putting efforts there is not a viable option. Importantly, we need to constantly update the parser whenever there is new version support.

We will be addressing some of the limitations mentioned above in upcoming releases.

> Doesn't use the C/C++ Code Formatter
LSP based editor uses clang based formatter, please refer to this
https://developer.espressif.com/blog/es ... formatting
https://github.com/espressif/idf-eclips ... 2202018650

> Doesn't even obey the tab size and type set in General/Editors
The LSP Editor is based on the standard editor. You can set the tab width, line spacing, etc., from Preferences > General > Editors > Text Editors.

> Missing context menu items like Declarations and References.
Agreed.However, you should be able to use Ctrl+click or F3. If, for some reason, this is not working, please check here.
https://github.com/espressif/idf-eclips ... 2276935107

>It's SLOW
My observation is that the LSP indexer is faster compared old indexer. Please share your findings on this with details.

> No coloring for code deactivated by preprocessor #if/#endif
This is addresed on master branch, will be available in the next release 3.1.0.
Here is the master build if you want to try.
https://github.com/espressif/idf-eclips ... 1800310442

> The hovers are overly intrusive
Please share more details for investigation.

Thank you for sharing your views and concerns. I’m sure we will turn this around in a couple of releases.

[gtjoseph]

Hello,

I have published a blog post on why we have moved to the LSP Editor and what it offers. Please check here
https://developer.espressif.com/blog/es ... p-support/

Many users have been reporting that the Eclipse CDT Editor/Indexer is unable to resolve headers and compilation units when working with ESP-IDF v5.0 and higher. This issue arises because the Eclipse CDT only supports the versions up to C++14. However, ESP-IDF v5.0 uses C++20 (with GCC 11.2) and ESP-IDF v5.2 uses C++23 (with GCC 13.1).

OK, that's fair.

Improving the CDT Parser with the new language grammar is a huge task that requires dedicated resources. However, we feel this is not a productive task as the world is moving towards LSP-based editors; therefore, putting efforts there is not a viable option. Importantly, we need to constantly update the parser whenever there is new version support.

OK, also fair.

We will be addressing some of the limitations mentioned above in upcoming releases.

> Doesn't use the C/C++ Code Formatter
LSP based editor uses clang based formatter, please refer to this
https://developer.espressif.com/blog/es ... formatting
https://github.com/espressif/idf-eclips ... 2202018650

Using .clang-format is quite hard because you can't immediately see the result. You have to actually do a reformat. Having https://clang.llvm.org/docs/ClangFormat ... tions.html open in another window or tab helps but it's still not easy.

There's no format-as-you-type.

Some settings will also conflict with those in General -> Editors. Tab type (spaces or tabs) and Tab Width for instance. clang-format defaults to a TabWidth of 4 and "use spaces". If you set "use tabs" in General -> Editors, tabs will be used as you type but on a reformat, the tabs will be replaced with spaces. You have to set "UseTabs: Always" in .clang-format to make sure it stays tabs after a reformat.

> Doesn't even obey the tab size and type set in General/Editors
The LSP Editor is based on the standard editor. You can set the tab width, line spacing, etc., from Preferences > General > Editors > Text Editors.

See above.

> Missing context menu items like Declarations and References.
Agreed.However, you should be able to use Ctrl+click or F3. If, for some reason, this is not working, please check here.
https://github.com/espressif/idf-eclips ... 2276935107

For finding the declaration, yes. There's no equivalent for finding usages as far as I can tell.

>It's SLOW
My observation is that the LSP indexer is faster compared old indexer. Please share your findings on this with details.

It's the speed of the hovers that's seems slower.

> No coloring for code deactivated by preprocessor #if/#endif
This is addresed on master branch, will be available in the next release 3.1.0.
Here is the master build if you want to try.
https://github.com/espressif/idf-eclips ... 1800310442

I'll give it a shot today.

> The hovers are overly intrusive
Please share more details for investigation.

Unfortunately we can't easily paste images here but here's the hover for the max_cmdline_length member of the esp_console_config_t structure in the CDT...

Code: Select all

size_t max_cmdline_length;  //!< length of command line buffer, in bytes

Here's the hover using the LSP editor...

Code: Select all

field max_cmdline_length

Type: size_t (aka unsigned int)
length of command line buffer, in bytes

// In (anonymous struct)
public: size_t max_cmdline_length

The CDT version is just one line and is all you need.

There also doesn't seem to be a way to control proposals. If I start typing "st" I really don't need to see a list pop up listing every function in the universe that starts with "st".

Thank you for sharing your views and concerns. I’m sure we will turn this around in a couple of releases.

We'll see how it goes. I've reverted to 2.12.1 for now but also have the Espressif IDE 3.0.0 bundle installed so I can see them side-by-side.

[gtjoseph]

I installed the current master build and do see changes for preprocessor #id/#elif/#endif but they're not very useful right now.

Here's how it looks in the CDT editor...


It's really clear what's going on.


Here's how it looks in the LSP editor...



The green text is the same color as the comments and doesn't really make it obvious that that code is inactive and the #elif should be "active". I don't see any way to change the colors.

Of course, you still can't fold them either.

[martins]

For the inactive code BLOCK highlight, I appreciate the effort, but yea, that really is not it. Could we just change the background color of whole inacive line(s) and leave everthing else the same?

[gtjoseph]

For the inactive code BLOCK highlight, I appreciate the effort, but yea, that really is not it. Could we just change the background color of whole inacive line(s) and leave everthing else the same?

Yeah that would be a good way to do it for now.

[gtjoseph]

Here's another example of something completely useless and irritating...



A hover to tell me I'm hovering over a string literal???

I realize that this is a standard clangd thing but there's apparently no way to disable these and it's another example of why moving to an immature editor is disappointing.