Where should I start?

[ghost]

Hi! I've been using this plugin for some time and I've been bashing it as you've seen my attempts on other open discussions. I want to come out as supportive of this plugin. It's better than what vscode has so far and I like working with it, but not IN IT!

To be clear, IF you want this library to have success the following need to happen

1. Complete setup
   I mean, there is no, how to do it with ccls, how to do it with clangd. Thankfully, lazy extras has clangd, but as you can see, there are a lot of headaches with it.
2. Up to date README and minimal setup.
   I just grabbed your minimal setup, put it in my lazyvim and just does not work. Throws errors saying that it was expecting a table, not nil.
3. Fix clangd or remove it as an option.
   If clangd is such a problem as I already pointed it out and you don't have time or don't want to fix it, it needs to go. Force ccls, but PLEASE give a basic setup for it. How to install ccls, how to link it to nvim and so on. You will be surprise how little information you find online about ccls.

I really want to use this plugin. I want it to be good. But I am having a hard time using it...

[anurag3301]

there is no, how to do it with ccls, how to do it with clangd

I thought its simply configurable in lsp entry in config. But yeah can create a wiki page for better discreet explaination.

I just grabbed your minimal setup, put it in my lazyvim and just does not work. Throws errors saying that it was expecting a table, not nil.

I am not sure why it didnt work, is already using lazy in the minimal_config.lua, you can tell me more.

Fix clangd or remove it as an option.

Initially it only had ccls and nothing to do with lsp, but later lot of people wanted clangd so I added. I think I can make it better, just didn't had the time.

Anyways you shouldnt have much hard time using ccls, as I assume you already use ccls. You should simply need

return {
  {
    "anurag3301/nvim-platformio.lua",

    dependencies = {
      "akinsho/toggleterm.nvim",
      "nvim-telescope/telescope.nvim",
      "nvim-telescope/telescope-ui-select.nvim",
      "nvim-lua/plenary.nvim",
      "folke/which-key.nvim",
      "nvim-treesitter/nvim-treesitter",
    },

    ft = { "c", "cpp", "h", "hpp" },
    cmd = {
      "Pioinit",
      "Piorun",
      "Piocmdh",
      "Piocmdf",
      "Piolib",
      "Piomon",
      "Piodebug",
      "Piodb",
      "PioLSP",
    },

    config = function()
      vim.g.pioConfig = {
        lsp = "ccls",
        menu_key = "<leader>\\",
        debug = false,
      }

      local ok, platformio = pcall(require, "platformio")
      if not ok then
        vim.notify("Failed to load PlatformIO plugin", vim.log.levels.ERROR)
        return
      end

      platformio.setup(vim.g.pioConfig)
  },
}

[ghost]

I don't use ccls. There is nothing relevant I can find about ccls. Everything I found about ccls is: Why don't you use clangd?

I have no idea how to set it up in my neovim since I can't find anything about it so you can see my predicament...

[anurag3301]

clangd for sure is better and bigger project than ccls but in my opinion ccls just works fine for autcompletion and basic diagnosis and its first party supported by platformio guys as produces .ccls. If you can use ccls that would be easier and peaceful switch. You dont have to rely on the plugin, you can just run pio init --ide vim in your existing project and you have a nice .ccls file. There is no need to fight with clangd

[ghost]

Mate...there is no way I will make it out of this sane...

HOW TO CCLS!??

"If you use ccls, you can ..."

HOOOOOOOOOOOOOOOWWW?

This is what I find about CCLS...

Lazyvim does not come with ccls...I have ccls installed on my computer and then?

[anurag3301]

I am not sure about LazyVim, you can just install ccls manually on your linux system, run ccls --version to confirm it. Add lsp config like ccls config

Open a simple C/C++ file to check if it works. This whole thing is literally nothing to do with plugin, you can simply ignore the plugin and run pio init --ide vim which generates the .ccls file. Infact this is exacly what the plugin does too.

[ghost]

Yeah. It's not working. I've been in this rabbit hole enough...

I will wait for your clangd mirracle...

This is the best experience I've got so far. I know it's not optimal, but ccls gave me an anorexia.

return {
  {
    "anurag3301/nvim-platformio.lua",

    dependencies = {
      "akinsho/toggleterm.nvim",
      "nvim-telescope/telescope.nvim",
      "nvim-telescope/telescope-ui-select.nvim",
      "nvim-lua/plenary.nvim",
      "folke/which-key.nvim",
      "nvim-treesitter/nvim-treesitter",
    },

    ft = { "c", "cpp", "h", "hpp" },
    cmd = {
      "Pioinit",
      "Piorun",
      "Piocmdh",
      "Piocmdf",
      "Piolib",
      "Piomon",
      "Piodebug",
      "Piodb",
      "PioLSP",
    },

    config = function()
      vim.g.pioConfig = {
        lsp = "clangd", -- or "ccls"
        clangd_source = "compiledb",
        menu_key = "<leader>\\",
        debug = false,
      }

      local ok, platformio = pcall(require, "platformio")
      if not ok then
        vim.notify("Failed to load PlatformIO plugin", vim.log.levels.ERROR)
        return
      end

      platformio.setup(vim.g.pioConfig)

      -- Get all environments from platformio.ini
      local function get_envs()
        local fname = vim.fn.getcwd() .. "/platformio.ini"
        if vim.fn.filereadable(fname) ~= 1 then
          return {}
        end
        local envs = {}
        for _, line in ipairs(vim.fn.readfile(fname)) do
          local env = line:match("%[env:(.+)%]")
          if env then
            table.insert(envs, env)
          end
        end
        return envs
      end

      -- Clean unwanted flags from compile_commands.json
      local function clean_compile_commands()
        local fname = vim.fn.getcwd() .. "/compile_commands.json"
        if vim.fn.filereadable(fname) ~= 1 then
          return
        end

        local f = io.open(fname, "r")
        local data = f:read("*a")
        f:close()

        local ok, json = pcall(require, "dkjson")
        if not ok then
          return
        end
        local arr, _, err = json.decode(data)
        if err then
          vim.notify("Failed to parse compile_commands.json: " .. err, vim.log.levels.ERROR)
          return
        end

        local remove_flags = {
          "-mlongcalls",
          "-mlong-calls",
          "-fstrict-volatile-bitfields",
          "-fno-tree-switch-conversion",
        }

        for _, entry in ipairs(arr) do
          if entry.arguments then
            entry.arguments = vim.tbl_filter(function(a)
              for _, flag in ipairs(remove_flags) do
                if a == flag then
                  return false
                end
              end
              return true
            end, entry.arguments)
          end
        end

        f = io.open(fname, "w")
        f:write(json.encode(arr, { indent = true }))
        f:close()
      end

      -- Optional: generate minimal .clangd
      local function generate_clangd_file()
        local f = io.open(".clangd", "w")
        if not f then
          return
        end
        f:write("CompileFlags:\n")
        f:write("  Remove:\n")
        f:write("    - -mlongcalls\n")
        f:write("    - -mlong-calls\n")
        f:write("    - -fstrict-volatile-bitfields\n")
        f:write("    - -fno-tree-switch-conversion\n")
        f:write("Diagnostics:\n")
        f:write("  Suppress:\n")
        f:write("    - drv_unknown_argument\n")
        f:write("    - drv_unsupported_opt_for_target\n")
        f:write("    - pp_file_not_found\n")
        f:close()
      end

      -- Generate compile_commands.json for all environments
      local function generate_compiler()
        local envs = get_envs()
        if #envs == 0 then
          vim.notify("No PlatformIO environments found!", vim.log.levels.ERROR)
          return
        end

        for _, env in ipairs(envs) do
          vim.notify("Generating compile_commands.json for env: " .. env, vim.log.levels.INFO)
          local cmd = { "pio", "run", "-e", env, "-t", "compiledb" }
          vim.fn.system(cmd)
          clean_compile_commands()
        end

        generate_clangd_file()
        vim.cmd("LspRestart")
      end

      -- Auto-generate compile_commands.json and attach LSP on opening C/C++ files
      vim.api.nvim_create_autocmd("BufReadPost", {
        pattern = { "*.c", "*.cpp", "*.h", "*.hpp", "platformio.ini" },
        callback = generate_compiler,
      })

      -- Manual fallback command
      vim.api.nvim_create_user_command("PioLSP", generate_compiler, {
        desc = "Generate compile_commands.json, .clangd, and attach PlatformIO LSP",
      })

      -- Auto-generate immediately if platformio.ini exists
      if vim.fn.filereadable(vim.fn.getcwd() .. "/platformio.ini") == 1 then
        vim.defer_fn(generate_compiler, 100)
      end
    end,
  },
}

[Shoxx98]

clangd miracle 🤣

[anurag3301]

Uh I see. ccls is just not an option for you. I'll try to make things better for clangd this week. There is already a discussion #59.

Anyways what do you work on, what board and framework. I test it out.

[dhupee]

I will add my own, sorry not to be active the past weeks since I have new jobs and it's bit draining my soul despite being remote

but for non technical side of this project i have quite of a gripe

1. yes i still feel ccls is in the old side compare to clangd, not that i think ccls is bad, its just every LSP tutorial or anything related to Pio and C++ these days almost always in clangd for the past years, its just PlatformIO happens to still provide .ccls file when init project, and compile_commands.json are always device-scope, you need to generate it
2. there's a need for strict development discipline in all of us, this project is working well in general but if we keep updating in master breaking changes happened and few people already complain, so no direct update in master branch, one feature update branch thingy, etc.
3. the README feels personal, in a way that its still aimed for @anurag3301 own config and him alone

Point number 3 i feel is fine when this project started but as its starting to get tractions, people starting contributing it and people starting to complain, i think we need to see the project as public project instead of personal project

we already started somewhere with adding stylua for standardizing formatting, removing vimscript in favor of lua

for now and first, @anurag3301 I would like to see your nvim config, it seems you didnt public it in your account, i want to see it, because it feel your config is very custom, and i feel the issue might be started from there nvm i found it

because here's the thing, i use Lazyvim, a distribution, easy nvim config, and my config for this one is not as autistic as the readme, and i use clangd, and yes i use ESP32 and Xtensa

return {
  "anurag3301/nvim-platformio.lua",
  -- "dhupee/nvim-platformio.lua",
  branch = "main", -- branch
  cmd = { -- comment it during development
    "Pioinit",
    "Piorun",
    "Piocmd",
    "Piolib",
    "Piomon",
    "Piodb",
    "Piocmdh",
    "Piocmdf",
    "Piodebug",
    "PioTermList",
  },
  dependencies = {
    { "akinsho/toggleterm.nvim" },
    { "nvim-telescope/telescope.nvim" },
    { "nvim-telescope/telescope-ui-select.nvim" },
    { "nvim-lua/plenary.nvim" },
    { "folke/which-key.nvim" },
    { "nvim-treesitter/nvim-treesitter" },
  },
  config = function()
    require("platformio").setup({
      lsp = "clangd",
    })
  end,
}

yes the commands are outdated, im too lazy for now

[anurag3301]

I have new jobs

Congrats buddy 🥳🥳

yes i still feel ccls is in the old side compare to clangd, not that i think ccls is bad, its just every LSP tutorial or anything related to Pio and C++ these days almost always in clangd for the past years, its just PlatformIO happens to still provide .ccls file when init project, and compile_commands.json are always device-scope, you need to generate it

I dont know how bad ccls is, but clangd is much more feature rich for sure.

there's a need for strict development discipline in all of us, this project is working well in general but if we keep updating in master breaking changes happened and few people already complain, so no direct update in master branch, one feature update branch thingy, etc.

Yeah we need to finalise upon basic setup. The config is changing too frequently and breaking things. I didn't think it will reach to a point that it will become a problem.

the README feels personal, in a way that its still aimed for @anurag3301 own config and him alone

Yes you are right, I wrote my nvim config like months and months ago and I just picked that, it would be really helpful if you can provide the mordern and standerd way setup a plugin these day, ill also check it out.

Point number 3 i feel is fine when this project started but as its starting to get tractions, people starting contributing it and people starting to complain, i think we need to see the project as public project instead of personal project

And yeah the project was indeed created as personal project to be used my me. Later I thought the small number of people who does embedded stuff on platfromio and uses neovim may like this.

For config it seems lot of poeple use LazyVim so there should a wiki or info about setting it up there.

[anurag3301]

Now real talk, I feel the major problem is the scope of the project. Originally it was made to provide vscode like setup and I think the project has already acheived that. The continuous issues we are getting is lsp errors people see, to fix that all the stuff happened. What my idea is to leave this manual compile_json generation completely until there is a robust alternative

Have only .ccls which pio creates and compile_command.json which compiledb generates, Thats it. Plugin is not responsible to do any lsp setups. If you dont want errors, just suppress them in .clangd file

[dhupee]

Since this project started to get bigger with the number of contributor and users both appreciating and complaining(which is good tbh), I think we need to do few things in no particular order for now

1. stop any new developement outside of fixing LSP issue
2. testing the LSP stuff mainly in clangd, maybe with Wokwi
3. improving how we can and cannot add new commits, including project owner, branch protection rule maybe the name
4. make template for issue and pr, idk how but there's one
5. CI for lint/formatter
6. CONTRIBUTING.md

basically making sure its up to standard with how community repo should shaped like, since currently its a mess

wdyt @anurag3301 @batoaqaa

[anurag3301]

stop any new developement outside of fixing LSP issue

Problem is responsibility, I am thinking to make this plugin not reponsible for LSP related issues, there will be only .ccls and comple_commands.json which will be generated by pio --init and compiledb respectively. The plugin does nothing more, max we can have to create a .clangd file to suppress errors. Until there is robus alternative or better support from platformio guys

testing the LSP stuff mainly in clangd, maybe with Wokwi

Will try that

improving how we can and cannot add new commits, including project owner, branch protection rule maybe the name

Yes, ill disable direct push to main now

make template for issue and pr, idk how but there's one

Okay but not sure what that would look like

CI for lint/formatter

Yeah it seem pretty needed, before merge to main, format it

CONTRIBUTING.md

I'll look how other people have set it up

[batoaqaa]

I agree that it is cumbersome and too much hassle to include full support for LSP in this plugin as we are dealing with cross-compiler/embedded projects. In each project we have to deal with different mcu setups in clangd lsp nvim config and project .clangd file.

I believe plain plugin that supports pltformio in nvim is enough, and it is for the developer to learn and to take care for setting LSP.

Just for info:
ccls LSP uses either .ccls or compile_commands.json.
clangd LSP uses either compile_flags.txt or compile_commands.json.

so .ccls = compile_flags.txt.

if you have trouble setting ccls, then you can use clangd and then copy/rename .ccls to compile_flas.txt and you are good.
You have to remove compile_commands.json from project root directory as compile_commands.json takes precedence and compile_flags.txt will be ignored.

So, every time you run "pio init --ide vim" which generates/updates the .ccls file, copy/rename .ccls to compile_flas.txt.

[batoaqaa]

Greetings all,

I have updated my repository "nvim-platformio.lua" with mini_nvimPlatformio.lua (minimal standalone config) that you run without modifying your existing nvim setup.

Actually 'mini_nvimPlatformio.lua' is enough for inexperienced neovim users. they need only install neovim 0.11+ on their device and download/run this file as shown below.
It will install platformIO for you and setup its environment. Also, it will setup LSP for clangd and other good plugins.

wget https://raw.githubusercontent.com/batoaqaa/nvim-platformio.lua/refs/heads/main/mini_nvimPlatformio.lua
nvim -u mini_nvimPlatformio.lua

Or follow to install the full plugin and try it.

clangd is will supported/updated from LLVM and big players.

I need you to test it and find out if there are any issues.
If it is OK with you to go this way, then I will commit to the main project.

Regards,

[dhupee]

Especially knowing in Clangd's case, the compile_commands.json is always need to be set every git clone, because the file is tied to your own file directory, my suggestion is to simply get rid of any LSP related commands

simply only to get rid of any future complaints to cover every LSP in existence

with replacement being how to set it via typical commands in README.md, not in form of commands, but reference article

real talk, i agree that the plugins already cover basically all vscode plugin months ago, if the pio autocomplete is fast enough i dont think life isnt that annoying

[anurag3301]

1. Direct push to main is restricted, can only be done using PR
2. Added a github action to autoformat code before merging