ilya-biryukov added a comment. In D66990#1655030 <https://reviews.llvm.org/D66990#1655030>, @nridge wrote:
> I was hoping though that a patch like this, which would bring us largely to > parity with Eclipse CDT's highlightings, wouldn't need to blocked on a change > to the upstream protocol proposal, which could take a while. Is feature parity a hard requirement? Having slightly different highlightings in that case should not be too disruptive. > I think the way cquery does it > <https://github.com/cquery-project/vscode-cquery/blob/4aac325dcf0735aa5d5f98960f28d6af6ca83d50/src/extension.ts#L84> > it better in this regard: in place of a single kind enum, they essentially > have a 4-tuple of `(kind, parent kind, storage class, role)`. A design like this definitely makes more sense. I was thinking of a slightly simpler model: adding a set of "modifiers" to each highlighting should be enough to encode all of it, e.g. a modifier 'is class member' could be used to distinguish methods and fields from global functions and variables, a modifier 'is usage' can be used to distinguish usages from declarations, etc. But there's no combinatorial explosion in the cquery's model, which is the important bit. >> That would also mean we would rely on every editor to apply consistent >> styling for this, at least by default: make `somethind-decl` just like >> `decl` but bold. >> I don't think there's any way to enforce this. Different designs lead to different interpretations: if we encode this as a separate highlighting kind, there's a greater chance this would be highlighted in different color rather than just applying modifiers. If we model this as "something in addition to the main highlighting", there's a greater chance this would be interpreted as something that should be "bold". Agree there is no way to enforce this. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D66990/new/ https://reviews.llvm.org/D66990 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
