-
Notifications
You must be signed in to change notification settings - Fork 29.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add editorFileExtension
when clause context
#34889
Add editorFileExtension
when clause context
#34889
Conversation
👍 |
Great we want that, a dupe is already on the October plan |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
@@ -28,6 +28,7 @@ export namespace EditorContextKeys { | |||
|
|||
// -- 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't use File
as it might not a file, maybe editorResourceExtension
, editorExtension
, or editorExtname
?
@@ -111,6 +114,7 @@ export class EditorModeContext extends Disposable { | |||
return; | |||
} | |||
this._langId.set(model.getLanguageIdentifier().language); | |||
this._fileExtension.set(model.uri.path.split('.').pop()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
😱 use paths.extname
} | ||
|
||
set(value: URI) { | ||
this._resourceKey.set(value); | ||
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)); | ||
} | ||
|
||
reset(): void { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jrieken. an reason why _filenameKey
is not reseted here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd say that is bug cc @bpasero
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jrieken introduced by you via 6110660#diff-cb108a154667420fbda68f22a3d6d90c ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🙉
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
} | ||
|
||
set(value: URI) { | ||
this._resourceKey.set(value); | ||
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)); | ||
} | ||
|
||
reset(): void { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd say that is bug cc @bpasero
@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 |
@@ -28,6 +28,7 @@ export namespace EditorContextKeys { | |||
|
|||
// -- 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
@@ -23,11 +23,13 @@ export class ResourceContextKey implements IContextKey<URI> { | |||
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, I'd prefer resourceExtname
. What do you think?
} | ||
|
||
set(value: URI) { | ||
this._resourceKey.set(value); | ||
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Way to go but we to think if folks expect .do
from foo.do
or do
...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
when
clause 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.