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
It's not clear from metaModel.json that MessageActionItem can contain arbitrary additional fields #2148
{
"name": "MessageActionItem",
"properties": [
{
"name": "title",
"type": {
"kind": "base",
"name": "string"
},
"documentation": "A short title like 'Retry', 'Open Log' etc."
}
]
},
I think it would be more standard to have an optional data field of type LSPAny, like on the Diagnostic object.
Is there any way that we can make this aspect of MessageActionItem clear in the json spec so tools that consume metaModel.json can support it correctly?
I agree on the data filed. The reason it is that way is that MessageActionItems are available since a very long time and that was added for backwards compatibility since servers added additional properties :-(.
All I can think of right now is to add a property supportCustomProperties to these types.
Are you aware of other types that behave this way, or is it just MessageActionItem?
Am I correct in assuming that this supportCustomProperties property would only be intended for use as a hack on legacy types, whereas newer types would lean towards using a data field?
Activity
dbaeumer commentedon Jun 4, 2025
I agree on the
datafiled. The reason it is that way is thatMessageActionItemsare available since a very long time and that was added for backwards compatibility since servers added additional properties :-(.All I can think of right now is to add a property
supportCustomPropertiesto these types.dbaeumer commentedon Jun 4, 2025
Would that work?
debonte commentedon Jun 4, 2025
Yes, that should work, thanks!
Two questions:
MessageActionItem?supportCustomPropertiesproperty would only be intended for use as a hack on legacy types, whereas newer types would lean towards using adatafield?