fix json classname fillin to use spec defined var

[ajm01]

No description provided.

[ajm01]

fixes: #499

[turkeylurkey]

Can you explain the design decision to cancel the old method of specifying parameters ($1, $2, $3 etc) and institute this new method instead? I suspect the change in the way we process these json files is a bug. Has LSP4MP changed from ${1} to ${TM_XXX}?

[ajm01]

Can you explain the design decision to cancel the old method of specifying parameters ($1, $2, $3 etc) and institute this new method instead? I suspect the change in the way we process these json files is a bug. Has LSP4MP changed from ${1} to ${TM_XXX}?

Yes LSP4MP now uses ${TM_XXX} - which is are LSP spec defined fill in vars that LSP4E is implemented to fill in for us - in this PRs case, with the base name of the java part for classname. The LSP4MP (and now LSP4jakarta) codebase understands that this specific var is to be passed back as is in the snippet to LSP4E which will fill it in with the base file name of the part being edited for classname. The other $1, $2 etc vars will be filled in by the Language Server code as it is done in the 0.1.x level of code.

In the 0.1.x codebase of lsp4jakarta, we retrieved the classname along with the packagename as part of the 'jakarta/java/classpath' message flow when getting classpath filtering for the snippets. we no longer are supporting that flow in the new codebase so this is how we make a provision for the base file name to be used for the classname - but now in the LSP4E layer.

[turkeylurkey]

Ok, I see what you mean, LSP4MP does this too.