This looks suspiciously similar to what LTeX produces for me. Are you sure that this is not the true origin of the error? If this is indeed LTeX, you will see it in :LspInfo.
If so, here is some info about changing the language of LTeX: https://valentjn.github.io/ltex/advanced-usage.html In short, you could try \usepackage[french]{babel}, or LTeX: language=fr-FR.
I looked at material.nvim randomly, and they use vim.api.nvim_set_hl to set their colors. It seems that the equivalent of the above command is :lua vim.api.nvim_set_hl(0, "Normal", {}).
:highlight Normal guifg=0 guibg=0 worked for me, at least when run interactively in a nvim -u NORC session.
I really need to try out Mercury one day. When we did a project in Prolog at uni, it felt cool, but also incredibly dynamic in a bad way. There were a few times when we misspelled some clause, which normally would be an error, but in our case it just meant falsehood. We then spent waaay to much time searching for these. I can’t help but think that Mercury would be as fun as Prolog, but less annoying.
I actually use from time to time the Bower email client, which is written in Mercury.
I got curious and decided to check this out. This value was set to the current one in 2009: https://github.com/torvalds/linux/commit/341c87bf346f57748230628c5ad6ee69219250e8 The reasoning makes sense, but I guess is not really relevant to our situation, and according to the newest version of the comment 2^16 is not a hard limit anymore.
As a data point, I have a Green Cell battery in my X220. I have bought the battery on July 24, 2022 and I have been using my X220 regularly but lightly. The battery was marketed as 6600 mAh at 10.8 V. As of writing, the OS reports design capacity of 73.26 Wh and current capacity of 60.6 Wh:
POWER_SUPPLY_NAME=BAT0
POWER_SUPPLY_TYPE=Battery
POWER_SUPPLY_STATUS=Discharging
POWER_SUPPLY_PRESENT=1
POWER_SUPPLY_TECHNOLOGY=Li-ion
POWER_SUPPLY_CYCLE_COUNT=0
POWER_SUPPLY_VOLTAGE_MIN_DESIGN=11100000
POWER_SUPPLY_VOLTAGE_NOW=11783000
POWER_SUPPLY_POWER_NOW=28726000
POWER_SUPPLY_ENERGY_FULL_DESIGN=73260000
POWER_SUPPLY_ENERGY_FULL=60600000
POWER_SUPPLY_ENERGY_NOW=54960000
POWER_SUPPLY_CAPACITY=90
POWER_SUPPLY_CAPACITY_LEVEL=Normal
POWER_SUPPLY_MODEL_NAME=45N1023
POWER_SUPPLY_MANUFACTURER=SANYO
POWER_SUPPLY_SERIAL_NUMBER= 9001
Edit: Actually, I thought about it, and I don’t think clang’s behavior is wrong in the examples he cites. Basically, you’re using an uninitialized variable, and choosing to use compiler settings which make that legal, and the compiler is saying “Okay, you didn’t give me a value for this variable, so I’m just going to pick one that’s convenient for me and do my optimizations according to the value I picked.” Is that the best thing for it to do? Maybe not; it certainly violates the principle of least surprise. But, it’s hard for me to say it’s the compiler’s fault that you constructed a program that does something surprising when uninitialized variables you’re using happen to have certain values.
You got it correct in this edit. But the important part is that gcc will also do this, and they both are kinda expected to do so. The article cites some standard committee discussions: somebody suggested ensuring that signed integer overflow in C++20 will not UB, and the committee decided against it. Also, somebody suggested not allowing to optimize out the infinite loops like 13 years ago, and then the committee decided that it should be allowed. Therefore, these optimisations are clearly seen as features.
And these are not theoretical issues by any means, there has been this vulnerability in the kernel for instance: https://lwn.net/Articles/342330/ which happened because the compiler just removed a null pointer check.
It seems that Neovim can’t see the nvim-lspconfig plugin itself. Have you installed it? If so, how?
Same in Python, Rust, Haskell and probably many others.
But apparently JS does work that way, that is its
filteralways iterates over everything and returns a new array and not some iterator object.