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
At the moment, there exist experimental options for custom label commands.
In my work, the diagnostics for these extended labels are basically useless, since I have macros that wrap the actual label and prepend a certain prefix to it.
For example:
I propose to add another option to the server that allows a mapping from custom label commands to a prefix, which would be considered when checking for duplicate or unused references.
To this end, I've started to work on this by extending crates/parser/src/config.rs appropriately. But, it appears that the planned change is a little more fundamental than anticipated, because base_db::semantics::tex::Label or ...::LabelKind do not appear to carry information about the actual command. If I'm not mistaken, that information is dropped in the lexer, replacing the read token (e.g., \asm) with just CommandName::LabelDefinition (see here).
Since the changes do not appear to be as easy as I thought, I'd like to discuss with you if (1) this is a reasonable (experimental) feature to add, (2) the plan on how to support this aligns with the general style and structure of the project, and (3) my analysis of the code base regarding the difficulty to implement this is on point or not.
The text was updated successfully, but these errors were encountered:
It'd be incredible if there is a somewhat less ad-hoc solution to custom prefixes, i.e., texlab identifying custom label commands automatically and adding them automagically, simply because one of the documents contains e.g. \newcommand{\asm}[1]{\label{asm:#1}}.
Of course, something like this would be dramatically more complicated and the question is if such complication justifies this feature.
Thanks for
texlab
, I've been enjoying it a lot!At the moment, there exist experimental options for custom label commands.
In my work, the diagnostics for these extended labels are basically useless, since I have macros that wrap the actual label and prepend a certain prefix to it.
For example:
I propose to add another option to the server that allows a mapping from custom label commands to a prefix, which would be considered when checking for duplicate or unused references.
To this end, I've started to work on this by extending
crates/parser/src/config.rs
appropriately. But, it appears that the planned change is a little more fundamental than anticipated, becausebase_db::semantics::tex::Label
or...::LabelKind
do not appear to carry information about the actual command. If I'm not mistaken, that information is dropped in the lexer, replacing the read token (e.g.,\asm
) with justCommandName::LabelDefinition
(see here).Since the changes do not appear to be as easy as I thought, I'd like to discuss with you if (1) this is a reasonable (experimental) feature to add, (2) the plan on how to support this aligns with the general style and structure of the project, and (3) my analysis of the code base regarding the difficulty to implement this is on point or not.
The text was updated successfully, but these errors were encountered: