Add editorFileExtension when clause context#34889
Add editorFileExtension when clause context#34889jrieken merged 4 commits intomicrosoft:masterfrom Krzysztof-Cieslak:file-extension-when
editorFileExtension when clause context#34889Conversation
|
👍 |
|
Great we want that, a dupe is already on the October plan |
jrieken
left a comment
There was a problem hiding this comment.
There is also https://github.com/Microsoft/vscode/blob/master/src/vs/workbench/common/resources.ts#L23 which is used in the explorer and in editor that aren't using the code editor widget. An analog context key, like resourceExtname, is also needed
|
|
||
| // -- mode context keys | ||
| export const languageId = new RawContextKey<string>('editorLangId', undefined); | ||
| export const fileExtension = new RawContextKey<string>('editorFileExtension', undefined); |
There was a problem hiding this comment.
Don't use File as it might not a file, maybe editorResourceExtension, editorExtension, or editorExtname?
| return; | ||
| } | ||
| this._langId.set(model.getLanguageIdentifier().language); | ||
| this._fileExtension.set(model.uri.path.split('.').pop()); |
| this._extensionKey.set(value && paths.extname(value.fsPath)); | ||
| } | ||
|
|
||
| reset(): void { |
There was a problem hiding this comment.
@jrieken. an reason why _filenameKey is not reseted here?
There was a problem hiding this comment.
@jrieken introduced by you via 6110660#diff-cb108a154667420fbda68f22a3d6d90c ?
There was a problem hiding this comment.
Should I add this missing reset in this PR?
|
OK, I renamed context to |
|
I just have one question, not connected to this particular PR but to contributing in general. Whenever I try to commit any changes they are failing with hygiene check... which would be OK, but the only reported errors are |
jrieken
left a comment
There was a problem hiding this comment.
Stuff looks good. Still unsure about the name, may fooExtname is better because it's closer to the c/fs functions. I'll collect some feedback here
| this._extensionKey.set(value && paths.extname(value.fsPath)); | ||
| } | ||
|
|
||
| reset(): void { |
|
@Krzysztof-Cieslak Make sure to invoke "Format Document" before pushing. We run a formatter as part of hygiene and TypeScript formatting much match, whitespace rules must be happy, and the copyright statement must be correct |
|
|
||
| // -- mode context keys | ||
| export const languageId = new RawContextKey<string>('editorLangId', undefined); | ||
| export const editorExtension = new RawContextKey<string>('editorExtension', undefined); |
There was a problem hiding this comment.
After a second look: we actually don't need to repeat this. Having resourceExtname/Extension is enough has it gets inherited to the editor from its column/slot. The reason for having editorLangId and resourceLangId is that latter is derived from the name while the former is more correct (look at the name and the contents)
src/vs/workbench/common/resources.ts
Outdated
| static Filename = new RawContextKey<string>('resourceFilename', undefined); | ||
| static LangId = new RawContextKey<string>('resourceLangId', undefined); | ||
| static Resource = new RawContextKey<URI>('resource', undefined); | ||
| static Extension = new RawContextKey<string>('resourceExtension', undefined); |
There was a problem hiding this comment.
So, I'd prefer resourceExtname. What do you think?
| this._schemeKey.set(value && value.scheme); | ||
| this._filenameKey.set(value && basename(value.fsPath)); | ||
| this._langIdKey.set(value && this._modeService.getModeIdByFilenameOrFirstLine(value.fsPath)); | ||
| this._extensionKey.set(value && paths.extname(value.fsPath)); |
There was a problem hiding this comment.
Way to go but we to think if folks expect .do from foo.do or do...
There was a problem hiding this comment.
I think typical behavior is to return extension with the dot. At least that's what most standard libraries I know do - Node's path.extname, .Net Framework Path.GetExtension, or Ruby's File.extname
There was a problem hiding this comment.
More interesting question is if users expects it to be normalized to lower case (i.e if "ABC.FSX" should return ".FSX" or just ".fsx")
There was a problem hiding this comment.
Good questions... I'd say we have it "as is". I can see how a "normalized" version can help but that applies to many values, e.g. filename
|
OK, removed new context from the ediotrContextKeys, leaving only resource one. And I've renamed the resource on to |
|
Thanks @Krzysztof-Cieslak |

This adds file extension
whenclause context.Some languages are using same languageId for multiple different types of files (with different extensions). It may be useful to let developers define command by file extension, and not only by languageId. For example in F#, we have single languageId (fsharp) for all different types of files (.fs - normal F# files, .fsx - F# script files, .fsi - F# signature files). We would like to be able to display some commands, or menu entries only for one of the types.