Skip to content

feat: add workspace language defaults and per-file choices - #1061

Open
sebthom wants to merge 3 commits into
eclipse-tm4e:mainfrom
sebthom:issue-1042
Open

sebthom wants to merge 3 commits into
eclipse-tm4e:mainfrom
sebthom:issue-1042

Conversation

@sebthom

@sebthom sebthom commented Sep 21, 2026

Copy link
Copy Markdown
Member

Support importing grammars and binding them to content types. Refresh highlighting and editing rules when a file's selected language changes.

@sebthom
sebthom force-pushed the issue-1042 branch 3 times, most recently from 071396c to 7675c6b Compare September 22, 2026 10:18
Support importing grammars and binding them to content types.
Refresh highlighting and editing rules when a file's selected language
changes.
@sebthom

sebthom commented Sep 22, 2026

Copy link
Copy Markdown
Member Author

@jensli did you give it a try? is it what you expected functionality wise?

@jensli

jensli commented Sep 22, 2026

Copy link
Copy Markdown
Contributor

did you give it a try? is it what you expected functionality wise?

Yes, it works! Great!

Here are some thought and observations:

  • I think it would be useful to define a command for the Choose Language.... menu action. In that way it could be accessed using the Quick Access function (Ctrl + 3), or the user could set their own keyboard shortcut.

  • The content type work is unrelated to the Choose Language functionality, isn't it? Choose Language is for choosing any language for a given file extension. The content type association is for associating languages and file extensions in a new way, but doesn't help with choosing languages. Or have I misunderstood something?

  • It seems like this change also repaired the Import TextMate Grammar functionality. Before this change I got an exception when trying to import.

  • After this change, the new custom Mumps language was chosen by default, instead of the Objective-C language from the language pack, without having to manually switch language. I think that's a good thing. If the user adds a custom language that's probably the one they want to use.

@sebthom

sebthom commented Sep 22, 2026

Copy link
Copy Markdown
Member Author

Here are some thought and observations:

  • I think it would be useful to define a command for the Choose Language.... menu action. In that way it could be accessed using the Quick Access function (Ctrl + 3), or the user could set their own keyboard shortcut.

That's a good idea, thanks!

  • The content type work is unrelated to the Choose Language functionality, isn't it? Choose Language is for choosing any language for a given file extension. The content type association is for associating languages and file extensions in a new way, but doesn't help with choosing languages. Or have I misunderstood something?

They serve different purposes, but are related. Choose Language... changes the language for one file, while content-type bindings set the default for matching files across the workspace.

Those associations also help put likely matches first in the chooser, alongside the grammar's own file patterns. And they let editing features such as bracket matching and folding follow the selected language.

  • It seems like this change also repaired the Import TextMate Grammar functionality. Before this change I got an exception when trying to import.

The import repair was a separate fix in #1053

  • After this change, the new custom Mumps language was chosen by default, instead of the Objective-C language from the language pack, without having to manually switch language. I think that's a good thing. If the user adds a custom language that's probably the one they want to use.

This should actually only happen if you select the checkbox "Set this grammar as the workspace default for matching files" which is off by default.

@sebthom

sebthom commented Sep 23, 2026

Copy link
Copy Markdown
Member Author

@jensli please give the new snapshot version in https://github.com/eclipse-tm4e/tm4e/actions/runs/35843669695/artifacts/10742691263 a try. it contains the command handler change.

Language configurations can supply multi-character surrounding pairs,
including through the autoClosingPairs fallback. Flattening these into
characters can trigger JFace's even-length assertion or create false
pairs.

Require exactly one UTF-16 character per delimiter in the matcher.
Keep the shared configuration intact so multi-character auto-closing
continues to work, and remove the now-redundant quote-length check.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants