Can I configure nvim-lspconfig to fail silently rather than print a warning? - neovim

Over time I'm adding more and more language servers in nvim. This is starting to get somewhat annoying when I use nvim outside of a project context on a filetype that I don't have an LSP globally installed for. Every time, a warning is printed that the LSP failed to start.
I'm not sure if this error comes from nvim itself or nvim-lspconfig, but it's really annoying. If I expect an LSP to work and it doesn't, I'll check :LspInfo.
How can I silence it?

Related

Elixir: VS Code ExUnit cannot find Mix

I cannot load or run my tests, from within VS Code.
I'm a new user to Elixir, and to VS Code. I'm running Lubuntu 21.10 (Impish). I've downloaded Erlang/OTP 25 (.deb), and Elixir 1.14 (precompiled binary in /usr/share/elixir), and can get anything I need running in a Bash terminal. Again, in a standard QTerminal window,
erl, iex, mix, elixir, etc. all work fine.
In VS Code, however, I get some errors. I feel stupid, but I'm coming from Sublime Text, so please forgive me.
In the left pane of VS Code, ExUnit shows an error (red):
Clicking on this error gives me this, on the bottom right pane. The command line options, passed to mix test, seem to be the default configuration:
This result is bizarre to me, because I can open the integrated terminal, execute /bin/sh, and then run the exact mix test line that's displayed:
/usr/share/elixir/bin has been added to my PATH variable, in ~/.bashrc, ~/.profile, and /etc/environment.
However, I am further confused by all tests being excluded, and wonder if there's some connection to the core issue:
Note that I can run my tests just fine, using different command line options. I've tried adding tags, but that didn't fix the problem.
I tried Google'ing this, and played around with my settings. Here is what I have configured in the "User" settings.json, and I made sure nothing overrides this in "Workspace" settings:
Changing the useNativeTesting setting doesn't solve the problem.
On another (?) note, I get a "failed to run elixir" upon VS Code startup:
Again, I have no problem running commands from a Linux terminal, or from a terminal within VS Code.
Plot twist: If I remove the precompiled Elixir 1.14, and downgrade to an older version, via apt, the problem goes away. But Lubuntu 21.10 doesn't offer Elixir 1.14, and I'm really into using the new dbg() feature.
But for now, I cannot load or run my tests, from within VS Code, apparently because Mix cannot be found.
Thanks to Daniel Imms, from the VS Code team, for answering my question on Twitter:
"Try moving where ever you init mix and elixir (.bashrc?) into your .bash_profile and then logging out and in again or restarting. I'm guessing it's in your bashrc which doesn't run in non-interactive sessions like in tasks."

Emacs freezes when debugging a program that segfaults (DAP vscode-cpptools)

I'm having an issue when debugging c++ programs in emacs (using dap-mode, LSP, projectile...):
I have no problem with the debugger, as long as my code doesn't crash. But when the debugger hits a segmentation fault, I get the usual messages that I would see in gdb for instance, but then I also get this line:
Stopping due to fatal error: NotImplementedException: No handler implemented for request type: 'ExceptionInfoRequest'!
Then emacs freezes and the only way to unfreeze it is to kill clangd. however, when I get back control over emacs, LSP detects that clangd crashed, and suggests I restart the server. Even if I say no, emacs hangs again and I can only kill emacs to close it.
I am fairly new to emacs, and just discovered LSP / DAP integration, so I apologize if I missed anything obvious during the setup process. I don't know how to get further information on this error, I am not sure if the problem is in the vscode-cpptools, in clangd, emacs, or in the dap-mode package.
Has anyone encountered the issue, or knows how to fix this?

VSCode CMake Tools disabling "Configure On Open" doesn't seem to be working

I have a workspace with several folders in it, one of which is a C++ folder with CMake stuff in it, but the others don't (they're Python or text folders). Since recently, when I open the workspace, CMake always tries and fails to configure every folder, with causes the console to open annoyingly every time, displaying messages like Cannot find CMT for folder [...] or we don't have an extension manager created yet. Setting feature set view to "full", and Unable to determine what CMake generator to use. Please install or configure a preferred generator, or update settings.json, your Kit configuration or PATH variable. Error: No usable generator found. I don't want this, I don't want CMake Tools to try to be clever and start configuring stuff without me explicitly telling it to. I've opened the settings, and unchecked the option "Cmake: Configure On Open", and unchecked the option "Cmake: Configure On Edit". I've double-checked that I've done that in all of "User", "Workspace", and "Folder" settings. However, this doesn't seem to work, still, every time I open VSCode, it tries and fails to configure, and it opens up the annoying console and displays the annoying error messages. Oh and as a bonus, it periodically displays an annoying error message box at the botton-right. How do I fix this?

Why does vscode pylint miss obvious errors?

I have a python file open in Visual Studio Code with an obvious error (using an undefined variable) but the pylint issues listed under 'Problems' show only a long list of minor convention issues.
Running pylint manually on it (separately from vscode) spots the error fine. The error is not explicitly excluded by any vscode pylint-related configs as far as I can see.
Eventually I discovered this was due to the following default setting in vscode:
"python.linting.maxNumberOfProblems": 100
Editing this config to a higher number (e.g. 1000) made the error show up.
Evidently this limit is applied blindly to the pylint output in the order the problems are found, so if enough minor issues precede an error then the error will be hidden - not ideal.

i really would like sbt and its console to work under cygwin any way you think it can be done?

i have this issue (https://github.com/sbt/sbt/issues/562)
basically when I try to get a console it says:
[ERROR] Failed to construct terminal; falling back to unsupportedjava.lang.IllegalArgumentException: Invalid terminal type: jline.UnixTerminal
also you cant use backspace
you basically cannot use sbt in cygwin (in dos is fine but cygwin is a much nicer environment)
and have voiced my concern there
i have tried several workaround i found on the net but they are all for old releases and no use now
was just wondering if you know of any workaround?
thanks
The following works for me (mostly, see note at bottom):
Use the mintty shell. I believe this is the default shell for new cygwin installs but has been included as an alternative for a while. If mintty.exe exists in your <cygwin home>\bin folder then it's ready to use, else it can be installed through the typical cygwin package selection from the setup.exe.
Open a mintty window, right click anywhere, go to Options... -> Keys, and make sure Send Backspace as ^H is checked. This will allow the REPL to correctly interpret backspaces.
For just running the Scala REPL that should be all you need, but attempting to run sbt console can still produce that exception. To get past that, run sbt without any arguments to get to the sbt prompt. From there execute:
eval System.setProperty("jline.terminal", "scala.tools.jline.UnixTerminal")
then
console
or, as a single command (with both semi-colons being important):
; eval System.setProperty("jline.terminal", "scala.tools.jline.UnixTerminal") ; console
From what I can tell, this is caused at least in part by the Scala REPL and the sbt prompt using incompatible versions of JLine. In particular, it looks like the Scala REPL created their own wrappers around the library and are using that while sbt is using the JLine library directly.
Note
One limitation that I continue to run into is that the REPL wraps at column 80 even if the shell window has more horizontal space. Not only that, but when the REPL wraps like this it overwrites the same line rather than advancing to the next, and pulling long lines from history ends up pushing the cursor above the line you're actually editing.