jghauser
enhancement: add better error handle and some hints
- adding "#" comment support
- error message when:
- indent level error
- empty line
- output not found
related to issue #5
Thanks a lot for this! :heart: Let me just add a nix devShell to this repo, so I can actually test this in a reasonable and sustainable manner. I'm afraid I've been neglecting this plugin a bit :sweat:. Will get to it very soon though!
Hey, I've added a nix flake to the repo so that I can easily work on this plugin. Can you rebase this PR on main? Sorry for the extra work!
Great, thanks a lot (and no worries about taking a moment)! I might take a few days to get to this because I'm on holidays.
The only question I have right now is about indentation. I think on line 40, you divide by 2 assuming an indentation of 2 spaces. Is that right? If so, then we should change this to use whatever the user is using (I think we can get that by querying the value of the buffer-local option shiftwidth). Luckily it seems tabs aren't allowed for indentation in the yaml syntax, so we don't have to handle that case.
Great, thanks a lot (and no worries about taking a moment)! I might take a few days to get to this because I'm on holidays.
The only question I have right now is about indentation. I think on line 40, you divide by 2 assuming an indentation of 2 spaces. Is that right? If so, then we should change this to use whatever the user is using (I think we can get that by querying the value of the buffer-local option
shiftwidth). Luckily it seems tabs aren't allowed for indentation in the yaml syntax, so we don't have to handle that case.
That's a good point! I understand your clarification and think a bit more consideration can lead to a better solution than adjusting local buffer settings. Consider a scenario where a user opens a Markdown file written by someone else, such as the example file from this repository. If the user has an unusual preference, such as an 8-space wide tab, they might encounter errors when trying to run the file. I suggest that these settings should be specified within the YAML block itself.
Phew, that was a bit of work. Now, it checks the minimal indent of the Pandoc YAML block and exits if it encounters errors, instead of running Pandoc.
By the way, have you checked the new Luarocks and the lua-tinyyaml package? I noticed that some Neovim plugins, like neo-org, are using Luarocks to install dependencies now. Do you think embedding a YAML parser will be easier with this approach? Naturally, it's a matter of your preference.
That's a good point! I understand your clarification and think a bit more consideration can lead to a better solution than adjusting local buffer settings. Consider a scenario where a user opens a Markdown file written by someone else, such as the example file from this repository. If the user has an unusual preference, such as an 8-space wide tab, they might encounter errors when trying to run the file. I suggest that these settings should be specified within the YAML block itself.
That's a good point! I like the current approach of figuring out the indent as you do :tada:. I would try to avoid having to add more settings to the yaml header.
Now, it checks the minimal indent of the Pandoc YAML block and exits if it encounters errors, instead of running Pandoc.
You read my mind! I was gonna add a change after your PR so that run_pandoc() exits if errors are found. Great to see that's already implemented!
By the way, have you checked the new Luarocks and the lua-tinyyaml package? I noticed that some Neovim plugins, like neo-org, are using Luarocks to install dependencies now. Do you think embedding a YAML parser will be easier with this approach? Naturally, it's a matter of your preference.
I've been following the development closely, yes. I already publish my papis.nvim package as a luarock and I intend to do the same with the rest of the plugins. I definitely also want to convert my dependencies to rocks, especially now that lazy.nvim supports them. I used to use a luarock to parse yaml files in papis.nvim, but stopped because it led to a lot of difficulties for users. Now this should all work quite smoothly. At the time I used lyaml, which seems more actively maintained. Is there a specific reason you're mentioning lua-tinyyaml? In any case, I think adding a luarock yaml parse will simplify this plugin massively and make it much more robust and easier to support new features.
Is there a specific reason you're mentioning lua-tinyyaml? In any case, I think adding a luarock yaml parse will simplify this plugin massively and make it much more robust and easier to support new features.
The mention of lua-tinyyaml was simply because it was the top result during my search. Indeed, any capable YAML parser should suffice for our needs. I'm glad to know that progress is being made with the LuaRocks integration—it's a step in the right direction for sure!