Allow apps to force lang via code.language and add special cased files

[fidgetingbits]

This makes some tweaks to language modes:

1. It adds a list of special-cased files that are mixed into the determination of the language, so you can return a language for things even if the file extension itself doesn't imply the language. The languages included aren't actually implemented in community, so I can keep the list empty if preferred, but I figured I'd keep it populated at first to give an example of why it's useful.
2. Adds a command to show the currently forced language
3. Remove language tags and instead utilize code.language #1256 semi-recently went the route of removing language-specific tags. This has the side effect (afaict) that an app that doesn't expose the file extension in its title can no longer force a language (previously it would just tag: user.<lang>). Given we removed the tags I assume we don't want them back, so this change goes a different route and adds an action that can be overridden to force a language. It's done in a way that the language being forced by an app will still be overridden by a user manually forcing a language with force <lang>. I've included an obsidian skeleton to demonstrate how to use it. Obsidian is a markdown editor that doesn't include file extensions in it's title. I took a look at search.talonvoice.com and see that some people are using tag.markdown (so are their community is not up to date, or they custom implemented tags again) and some others are re-implementing markdown commands. Since I tried to use this app recently, and I don't like forcing a language across my entire system and have to remember to clear it afterwards, I figured I should add a way to do it.

I'm open to other ways to do this if there is a better idea.

[auscompgeek]

I personally think an app that wants to force a language should override the code.language action.

[AndreasArvidsson]

I personally think an app that wants to force a language should override the code.language action.

Totally agree. If the problem is that forced language should take precedents over an application specific language then we just need to make the matcher of the forced context more specific. mode: all or something.

[fidgetingbits]

I personally think an app that wants to force a language should override the code.language action.

Hrm ya that makes sense, is simpler. I'll change it.

Will try the 'mode: all' thing as well, as ya I think we still want forced language to take precedence over overridden code.langauge

[AndreasArvidsson]

I will look into if we can make the forced override more specific and always win over application specific

[nriley]

To be clear we tried mode: all and a couple other things in the community backlog session and couldn't get them to work.

A temporary workaround if you've already got code.language overrides is to do something like this:

nriley@b2d584a

but @AndreasArvidsson wasn't too excited about having to do that everywhere and neither am I…

[AndreasArvidsson]

It appears that the app context has a really high priority. For now I would probably recommend putting not tag: user.code_language_forced on the context where you override code.language

[nriley]

Do you think creating another context for this is better than calling actions.next? :-) thought we were trying to avoid having to make changes every time you override code.language

[AndreasArvidsson]

I guess both work I just prefer to actually use the Talon context for what it's made for. Just to be clear you put this not tag on the new context where you have your new code language override.

[nriley]

I'm OK with the not tag solution! On the community backlog session apparently people are confused by actions.next...

[fidgetingbits]

Finally got time to circle back to this. I use the code.language override with a context that uses not forced language for obsidian, as suggested. I left in the filename special casing in language_modes.py.