LSP "window/logMessage" messages go nowhere

[garyo]

I'm trying to configure the latest vue-language-server and it's not working yet (errors in my side with config, I'm sure). It just fails silently though, until I look in the events buffer and see the actual errors:

server-notification Thu Oct 17 12:06:49 2019:
(:jsonrpc "2.0" :method "window/logMessage" :params
          (:type 1 :message "(node:9968) UnhandledPromiseRejectionWarning: TypeError: Cannot read property 'vetur' of null\n    at VLS.configure (c:\\Users\\garyo\\AppData\\Roaming\\npm\\node_modules\\vue-language-server\\dist\\services\\vls.js:145:47)\n    at VLS.<anonymous> (c:\\Users\\garyo\\AppData\\Roaming\\npm\\node_modules\\vue-language-server\\dist\\services\\vls.js:77:18)\n    at Generator.next (<anonymous>)\n    at c:\\Users\\garyo\\AppData\\Roaming\\npm\\node_modules\\vue-language-server\\dist\\services\\vls.js:8:71\n    at new Promise (<anonymous>)\n    at __awaiter (c:\\Users\\garyo\\AppData\\Roaming\\npm\\node_modules\\vue-language-server\\dist\\services\\vls.js:4:12)\n    at lspConnection.onDidChangeConfiguration (c:\\Users\\garyo\\AppData\\Roaming\\npm\\node_modules\\vue-language-server\\dist\\services\\vls.js:76:71)\n    at handleNotification (c:\\Users\\garyo\\AppData\\Roaming\\npm\\node_modules\\vue-language-server\\node_modules\\vscode-jsonrpc\\lib\\main.js:500:43)\n    at processMessageQueue (c:\\Users\\garyo\\AppData\\Roaming\\npm\\node_modules\\vue-language-server\\node_modules\\vscode-jsonrpc\\lib\\main.js:271:17)\n    at Immediate.setImmediate (c:\\Users\\garyo\\AppData\\Roaming\\npm\\node_modules\\vue-language-server\\node_modules\\vscode-jsonrpc\\lib\\main.js:258:13)"))

Perhaps it would be a good idea for eglot to notify the user of these messages somehow? Right now they're ignored:

(cl-defmethod eglot-handle-notification
  (_server (_method (eql window/logMessage)) &key _type _message)
  "Handle notification window/logMessage") ;; noop, use events buffer

[joaotavora]

The problems is if I enable then some users are really annoyed because some servers abuse such messages. Maybe I could use warn and the user could set warning-minimum-log-level to see them.

[garyo]

From my perspective while debugging client/server to get things working, having these is valuable, and not knowing they were there did cost me some time. But having messages show up all the time would be annoying of course. So I would suggest showing them by default, but having a per-server opt-out for abusive servers.

[joaotavora]

OK, I'll take a PR that mixes my warn idea with your opt-out idea.

[ArsenArsen]

perhaps a new buffer to display these would be reasonable? IIUC, VSCode among others do something similar. servers definitely abuse this.

it would still possibly be useful to have some server messages promoted based on type, see: https://microsoft.github.io/language-server-protocol/specifications/specification-3-15/#messageType

[joaotavora]

But why isn't the events buffer a reasonable place to consult. Just because the format isn't pretty there? Because there is lots of other junk?

[ArsenArsen]

I do currently, but it gets a bit difficult to parse out information from it when it is heavily populated. however, due to the nature of the issue, I'd not consider adding a dedicated buffer a high-priority task

hm, perhaps 'prettifying' the events buffer would be more effective even

[joaotavora]

hm, perhaps 'prettifying' the events buffer would be more effective even

Yes, or simply using M-x occur or even just C-s this buffer. In the latest jsonrpc.el version that Eglot is using, the default format is one line per event.