fix: handle empty capability options in plist mode

[suzuki]

Summary

Fix lsp--capability to correctly detect capabilities when LSP_USE_PLISTS is enabled and the server returns empty option objects like "definitionProvider": {}.

Problem

When LSP_USE_PLISTS=true, Emacs's json-parse-string parses empty JSON objects {} as nil:

(json-parse-string "{\"definitionProvider\": {}}" :object-type 'plist)
;; => (:definitionProvider nil)

This causes lsp--capability to incorrectly report that the capability is not supported, because it only checks if the value is truthy.

Affected servers

Any LSP server that returns empty option objects, for example:

• buf lsp (buf lsp serve) returns:

  {
    "definitionProvider": {},
    "typeDefinitionProvider": {},
    "referencesProvider": {}
  }

With the current implementation, "Go to Definition", "Find References", etc. are broken when using these servers with LSP_USE_PLISTS=true.

Solution

Use lsp-member? to check if the capability key exists in the server capabilities, rather than just checking if the value is truthy:

;; Before
(lsp-get (or capabilities (lsp--server-capabilities)) cap)

;; After
(let ((caps (or capabilities (lsp--server-capabilities))))
  (when (lsp-member? caps cap)
    (or (lsp-get caps cap) t)))

This correctly distinguishes between:

• Key exists with empty value ({} → nil in plist) → capability supported ✓
• Key does not exist → capability not supported ✗

Test plan

• Added unit tests for lsp--capability covering:
  • Empty object capabilities (plist mode)
  • Boolean capabilities
  • Structured capabilities (e.g., completionProvider with options)
  • Non-existent capabilities
  • String key conversion

[Copilot]

Pull request overview

This PR fixes the lsp--capability function to correctly detect LSP server capabilities when using LSP_USE_PLISTS=true mode, where empty JSON objects {} are parsed as nil by Emacs's json-parse-string. The fix uses lsp-member? to check if a capability key exists before evaluating its value.

Key changes:

• Modified lsp--capability to use lsp-member? to distinguish between missing capabilities and capabilities with empty/nil values
• Added comprehensive unit tests covering empty objects, boolean values, structured values, and non-existent capabilities

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
lsp-mode.el	Updated lsp--capability function to check for key existence using lsp-member? and return t for empty-valued capabilities
test/lsp-mode-test.el	Added two new test functions to verify correct behavior for various capability states in both plist and hash-table modes

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The test suite is missing a critical test case for when a server explicitly returns false for a capability (which would be represented as :json-false in Emacs). This is different from an empty object and should return nil to indicate the capability is not supported. Add a test case where a capability is set to :json-false and verify that lsp--capability returns nil.

[Copilot]

The documentation says the function returns t for capabilities with empty values, but doesn't mention the behavior for :json-false (explicit false). The documentation should clarify that :json-false values should return nil because they indicate the capability is explicitly not supported by the server.

[Copilot]

The implementation incorrectly treats :json-false (explicit false from server) the same as nil (empty object). According to LSP spec, when a server sends "definitionProvider": false, it explicitly indicates the capability is NOT supported. The current logic would return t for this case because lsp-member? returns true and (or :json-false t) evaluates to t. This should be changed to distinguish between nil (empty object) and :json-false (explicit false).

Suggested change

	(let ((caps (or capabilities (lsp--server-capabilities))))
	(when (lsp-member? caps cap)
	(or (lsp-get caps cap) t))))
	(let* ((caps (or capabilities (lsp--server-capabilities)))
	(val (and (lsp-member? caps cap)
	(lsp-get caps cap))))
	(cond
	;; Explicit JSON false: capability is explicitly not supported.
	((eq val :json-false) nil)
	;; Capability key exists but has an empty object / nil value: treat as supported.
	((null val) (and (lsp-member? caps cap) t))
	;; Non-nil, non-:json-false value: return the capability value itself.
	(t val))))

[kiennq]

Can we rewrite this as

(let ((caps (or capabilities (lsp--server-capabilities))))
  (or (lsp-get caps cap)
      (lsp-member? caps cap)))

So, no need to double check for lsp-member?

[suzuki]

@kiennq Thanks for the suggestion! Fixed in 365b1b3

[kiennq]

@suzuki, thanks for your changes, I hope it would resolve a large array of bugs we have regarding to deserialize json in plist.
Currently with plist deserialize we have option to set :false-object and :null-object, however empty list is not there.

Do you think it's possible to properly check for empty list using combination of lsp-get and lsp-member? So we can change the lsp-empty? and lsp-get to check both conditions?
Also, we should probably move all of the :false-object and :null-object to different values other than nil so we can properly distinguish between all of them

[suzuki]

@kiennq Sorry for the late reply. I've introduced lsp-null? for null checking. Does this change align with your thoughts?