To overwrite general vale settings in a subdirectory it is necessary to
create a new .vale.ini file in that subdirectory. Specifying paths in
the general .vale.ini does not work.
Details
Details
- Reviewers
carlavilla dbaio bofh
Diff Detail
Diff Detail
- Repository
- R9 FreeBSD doc repository
- Lint
No Lint Coverage - Unit
No Test Coverage - Build Status
Buildable 50885 Build 47776: arc lint + arc unit
Event Timeline
Comment Actions
I should add that I could only test running vale from the subdirectories themselves. Specifying paths in the general .vale.ini might work for a full run started at the root of the doc repository, but I cannot test it as the process gets killed on my machine because it eats all my memory.
Anyway, I guess vale should probably be used to check a few files only (e.g. a patch, or in my case a quarterly status report), not the full repository at once, so the case that I tested may be the most important.
Comment Actions
I do not know your exact workflow but from your commit logs I can pretty much confirm that you should never be running vale like that and should have vale integrated with your choice of editor. At least that's how I use it. Although I lost traction on this work as my request for blanket approval on vale was not accepted. You can check the vim configuration part for an example on how to do that. I was supposed to work on Emacs configuration but I didn't look into it. However if you need one quick config I will try to extract from my Emacs config and share. Running vale . is mostly meant for running CI.
On another note about this specific review this is documented and should work as mentioned as I have tested it a lot before committing. If it's not working we should notify upstream. I will give it another check later sometimes and check with upstream.
Comment Actions
Thanks @bofh. If running vale . is not how it is intended to be used, then I fear this is not the tool I need. I need something that can quickly parse status reports for common mistakes and possibly also fix them: I cannot open each single report in an editor and modify them manually one by one, it would take forever. I had already started developing my own tools (shell code written into Makefiles) in the old archived quarterly status reports repository, but I was told that it would have been better to avoid importing them in doc and use vale instead.
I abandon the revision then and I trust @bofh that everything works as expected with vale.
@carlavilla: I am going back to develop my own tools then. Is there any format that could make them acceptable for the doc/tools directory or some other place in the doc repository, or should I develop them out of it? I have no problem converting the existing tools in whatever language is prefered. An example of a test that I had written to help having one sentence per line (which I believe would be useful to the whole doc repository, not just for status): https://github.com/freebsd/freebsd-quarterly/blob/main/tools/tests/Makefile.one-sentence-per-line ; I could easily convert it to plain sh without the Makefile intermediary, or in perl, ruby, python etc.
Comment Actions
I think you have misunderstood my comments. However for your case you can do:
cd doc/website/content/en/status vale .
That would be pretty much faster.
About my previous comment I meant running vale . on the entire doc directory. At least the above comment ran properly on my host:
vale . 44.72s user 15.29s system 516% cpu 11.609 total
Comment Actions
I think you have misunderstood my comments. However for your case you can do:
cd doc/website/content/en/status vale .That would be pretty much faster.
About my previous comment I meant running vale . on the entire doc directory. At least the above comment ran properly on my host:
vale . 44.72s user 15.29s system 516% cpu 11.609 total
Yes, I confirm that running vale in the status directory is much faster, but then it runs with all the FreeBSD rules, which create too much noise. I have tried disabling rules in .vale.ini using a path, but it does not work if I cd into the status directory before running vale. This is why I was proposing to split the general .vale.ini file into multiple .vale.ini files, but then things become too complex to maintain (many .vale.ini scattered through the doc repository), and if I understood correctly this extra complexity is unnecessary for CI and editor integration. Since it would be necessary only for my usecase, I think it is better to search for another strategy.
Morever, I must admit that I dislike vale: I find writing a perl script much easier and intuitive. After all, I only need to run a few regular expressions on text files: I do not need scopes, syntax awareness, styles, vocabularies etc. I can imagine how vale could be great for CI or integrated in an editor, but for what I need to do it is a lot of complexity for an easy task.
Comment Actions
Yes, I confirm that running vale in the status directory is much faster, but then it runs with all the FreeBSD rules, which create too much noise. I have tried disabling rules in .vale.ini using a path, but it does not work if I cd into the status directory before running vale. This is why I was proposing to split the general .vale.ini file into multiple .vale.ini files, but then things become too complex to maintain (many .vale.ini scattered through the doc repository), and if I understood correctly this extra complexity is unnecessary for CI and editor integration. Since it would be necessary only for my usecase, I think it is better to search for another strategy.
Now I get the exact reason about this review. Write the rules which you want to turn off in the .vale.ini of the root and then:
cd doc vale website/content/en/status
Morever, I must admit that I dislike vale: I find writing a perl script much easier and intuitive. After all, I only need to run a few regular expressions on text files: I do not need scopes, syntax awareness, styles, vocabularies etc. I can imagine how vale could be great for CI or integrated in an editor, but for what I need to do it is a lot of complexity for an easy task.
It's totally upto personal preference whether someone will use it or not.
Comment Actions
Write the rules which you want to turn off in the .vale.ini of the root and then:
cd doc vale website/content/en/status
I do not like much to have to diverge from the .vale.ini in the doc repository to have it usable, but hopefully this is temporary and it will get less noisy in the future. After having tried your rule in https://reviews.freebsd.org/D39560, I see that it is doing what I need and that it is easy enough, so I will keep trying using vale for now.
Thanks.
Comment Actions
By the by if you just want to override something for your usecase but you don't want to land it in the repo you can always copy the .vale.ini and .vale directory in your home directory and edit them to suite your needs.
Apart from that I did this work so that all developers across the globe is writing the docs uniformly. But hey .. if you have some powertools to serve your purpose feel free to use it. I do not want any tools to be hindering the productivity of others. :)
Comment Actions
By the by if you just want to override something for your usecase but you don't want to land it in the repo you can always copy the .vale.ini and .vale directory in your home directory and edit them to suite your needs.
Thanks for the tip, I will probably use it.
Apart from that I did this work so that all developers across the globe is writing the docs uniformly. But hey .. if you have some powertools to serve your purpose feel free to use it. I do not want any tools to be hindering the productivity of others. :)
I would probably be much faster with something else, but speed is not the main goal: the main goal is to have other developers be easily able to check and fix the same things I am checking and fixing. I think using vale is better for this purpose. Thanks for your work on it :)