feat: languages (identifiers) as setting

[mcanouil]

Introduce a new configuration setting for specifying an array of language identifiers to lint. This enhancement broadens the "activation" function to include multiple languages, allowing for improved handling of documents beyond just Markdown such as RMarkdown and Quarto without maintenance burden.

Note that language identifiers provided won't trigger the activation of the extension, only the presence of a file with the language identifier being markdown will.
The settings will only only linting of any files in a workspace with one markdown file.

Fixes partially #228 as extension activation is delegated to other extensions.

[DavidAnson]

This PR does not seem to address the activation concerns I raised in the issue you link to: #228 (comment)

Or, rather, it tries to by using the onStartupFinished event to load the extension unconditionally into every VS Code instance: https://code.visualstudio.com/api/references/activation-events#onStartupFinished

I consider that bad behavior by an extension (imagine if they all behaved that way) and it's why I tagged the issue vscode-feature-wanted.

[mcanouil]

Sorry, I initially aimed to open this as draft as I was still tinkering with the code mostly for the points in your comment.

A middle ground could be to keep the current activation event, but keep the settings to allow markdownlint to lint any kind of files.
The settings won't change the activation but since Quarto projects will have Markdown files (README.md), Quarto documents could be picked up.

What do you think? (current version of the PR)

Screen.Recording.2025-02-02.at.00.35.34.mov

[mcanouil]

FWIW, the first attempt (onStartupFinishedand early return) was based on the following comment:

• [Extensions] Bind package.config's activation onLanguage to configuration microsoft/vscode#38125 (comment)

[mcanouil]

The addition of the setting (no changes in activation conditions) will allow to use markdownlint as a dependency and force the activation in appropriate context.

  "activationEvents": [
    "onLanguage:quarto"
  ],
  "contributes": [
    "configurationDefaults": {
      "markdownlint.languages": [
        "markdown",
        "quarto"
      ]
    }
  ]

const extensionsToActivate = ["DavidAnson.vscode-markdownlint"];
extensionsToActivate.forEach(async (extensionId) => {
	const extension = await vscode.extensions.getExtension(extensionId);
	LOG.appendLine(`Activating ${extensionId}...`);
	if (extension) {
		if (!extension.isActive) {
			await extension.activate();
		}
		LOG.appendLine(`${extensionId} activated.`);
	} else {
		LOG.appendLine(`Failed to activate ${extensionId}.`);
	}
});

[DavidAnson]

What thing are you suggesting should contain the configuration above for "onLanguage:quarto"? If that's not present in the configuration for THIS extension, it will not be activated for quarto files and will not perform linting if a quarto file is opened (unless the extension has already been loaded for some other reason - but that's unpredictable). This is the essence of the problem: if languages are to be configurable, the metadata for this extension must ALSO be updated (as far as I know) - and that's not possible for a user to do.

[mcanouil]

The code (#368 (comment)) about how to activate markdownlint is to be added not by markdownlint (you) but by anyone wanting to use markdownlint to lint files that has not "markdown" as language identifier, "quarto" VSCode extension to use markdownlint on Quarto files, VSCode-R to add support for RMarkdown documents, etc.

The only thing needed for that is the current change in the PR, the markdownlint.languages setting.
Nothing else is to be changed in your extension.

Sorry if I was not clear.

[DavidAnson]

• What if a user adds a language that does not have an associated extension?
• Or what if they don't have the associated extension installed?
• Who is going to convince every language extension to add code to activate markdownlint?
• How is a random user supposed to know about these hidden requirements?

I don't think these questions have good answers, which is why I don't think this feature is practical today.

[mcanouil]

• What if a user adds a language that does not have an associated extension?

-> it means opening the file won't trigger activation but opening a markdown file and going back to the other will work as an activated extension is not deactivated.

• Or what if they don't have the associated extension installed?

-> Same as above.

• Who is going to convince every language extension to add code to activate markdownlint?

-> There is no convincing. If the developers of a markdown-like language wants support markdownlint, they will otherwise, they won't. It will be up to the developers. No burden for you or maybe user asking why it's not working (that's already the case).
A note in the setting description stating that direct support for languages other than markdown should come from the third parties.

• How is a random user supposed to know about these hidden requirements?

-> That's documentation and messages, but again a note in the description would shift the burden on the developers of markdown-like languages. For instance, the quarto VSCode extension uses various extensions already to provide computing abilities inside "quarto" (markdown) documents.
Dependencies can be declared: extensionDependencies (https://code.visualstudio.com/api/references/extension-manifest).

I don't think these questions have good answers, which is why I don't think this feature is practical today.

To be sure I understand what you are saying here, does it mean you prefer to block any support at all rather than offers the ability for other to extend your extension support via their own extension and a setting? (I'm fine if the answer is yes, it would only mean to fork your entire extension)

[mcanouil]

To be clear, I fully agree that this is not perfect but the issue is opened on VSCode since November 2017.

• [Extensions] Bind package.config's activation onLanguage to configuration microsoft/vscode#38125

[mcanouil]

Please feel free to close the PR if the setting it's adding is not desirable for you. I would not want to take up any more of your time.

Thank you for your work on markdownlint, it's really a great tool/extension.

[DavidAnson]

I don't want behavior to be inconsistent, so I'm not ready to accept this PR. However, I'm on the fence about the suggestion in the issue you link to and if that's a reasonable approach in practice, then my concerns here are mostly addressed. I need to play around with that approach myself to see how well it works, especially in the context of bundling and in the web (versus desktop) editor scenario. I'm going to leave this PR open for now and will follow up once I do some experimentation there.

[mcanouil]

Thanks for considering!

[mcanouil]

I edited one of my message and in case you did not see, it's possible (actually it should) for an extension to declare other extensions as dependencies via extensionDependencies (https://code.visualstudio.com/api/references/extension-manifest).

[DavidAnson]

@alexdima, is the "iceberg" approach you recommend in microsoft/vscode#38125 (comment) still considered the best workaround? Are there any tips on implementing that with bundling and in web context?