You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
documentSymbol: include visibility in detail so clients can order an outline by it #339
Include a member's visibility (and other modifiers) in the documentSymboldetail string, so clients can order declarations by visibility without parsing source.
Today textDocument/documentSymbol returns detail as the signature — e.g. "(int $id, string $customer, int $amountMinor): Mini\Domain\Invoice" for a method and "Mini\Domain\PaymentGateway" for a property. The LSP protocol has no structured field for visibility (SymbolKind says what a thing is, SymbolTag only standardises Deprecated), so the only channel is this prose — and the convention among PHP tooling is to lead it with the modifiers. Intelephense sends "abstract protected", "private", "final"; VS Code's own PHP language features do the same.
Use case
Clients use detail to order an outline by visibility — public members first, private helpers last — because that is what a class is for. With signatures as detail, every entry reads as public and the ordering silently stops applying. Concretely: in a Monaco-based editor's outline, a class whose private property and methods should sink below its public API keeps them interleaved, and there is no other signal in the protocol to recover the visibility from.
Proposed solution
Prefix detail with the declaration's modifiers, in the intelephense style, optionally followed by the signature:
method: "public function createAndPay(int $id, ...): Invoice"
property: "private PaymentGateway $gateway"
class: "final class InvoiceService"
interface method: "abstract protected function charge(...)"
Since detail is free prose, servers that keep the signature after the modifiers remain compatible with clients that show the full string.
Alternatives considered
Parse visibility client-side. Would require the client to parse PHP declarations itself — it only has the token stream, and the whole point of an LSP is that the server already knows this.
A new protocol field. Not standardisable for one server; detail is the established channel.
SymbolTag/SymbolKind extension.SymbolKind has no visibility dimension and changing it would break the protocol's values.
documentSymbol for this class currently reports detail"(int $id, ...): Mini\Domain\Invoice" and "(PaymentGateway $gateway): bool"; the request is that it report "public function createAndPay(...)" and "private function charge(...)".
Activity