Skip to content
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

Allow to register a language for an output channel #11005

Closed
ArtemGovorov opened this issue Aug 26, 2016 · 13 comments
Closed

Allow to register a language for an output channel #11005

ArtemGovorov opened this issue Aug 26, 2016 · 13 comments
Assignees
Labels
api feature-request Request for new features or functionality *out-of-scope Posted issue is not in scope of VS Code output Output channel system issues

Comments

@ArtemGovorov
Copy link
Contributor

ArtemGovorov commented Aug 26, 2016

I have taken the idea from this extension https://github.com/formulahendry/vscode-code-runner and created a language + grammar to highlight the output of my extension:

  "contributes": {
    ...
    "languages": [
      {
        "id": "wallaby-output",
        "mimetypes": [
          "text/x-code-output"
        ]
      }
    ],
    "grammars": [
      {
        "language": "wallaby-output",
        "scopeName": "wallaby.output",
        "path": "./wallaby-output.tmLanguage"
      }
    ]
  },

screen shot 2016-08-26 at 6 31 37 pm

It seems to work ok, but because of using the text/x-code-output mime type, the languages and its grammar gets applied to all output channels, not just mine. So not only my extension and other extensions using the same trick may clash with other output channels and each other, also some built-in features seem to stop working in all output channels - for example the file absolute paths detection stops creating links for the paths.

I'm wondering if it's possible to somehow constraint a language to work only within a specific output channel? If not, would it be possible to add such feature?

@ArtemGovorov
Copy link
Contributor Author

ArtemGovorov commented Aug 29, 2016

From the API perspective, it'd be nice if the

export function createOutputChannel(name: string): OutputChannel;

function also accepted a languageId: string, or perhaps an instance of DocumentSelector, but this may be an overkill for this specific purpose.

@jrieken jrieken added feature-request Request for new features or functionality api labels Aug 29, 2016
@jrieken
Copy link
Member

jrieken commented Aug 29, 2016

Cool, idea. I'd go with languageId or an Uri when creating a channel.

@ArtemGovorov
Copy link
Contributor Author

BTW, apart from being able to colorize an output channel, here's another scenario that the feature implementation enables - implementing and registering any custom link providers for an output channel (we're using it for test links on the screenshot above).

@ArtemGovorov
Copy link
Contributor Author

ArtemGovorov commented Oct 11, 2016

In v1.7 mimetypes were removed, so the workaround doesn't work anymore and currently custom output highlighting is broken in our extension, and few other extensions using the same trick, such as:

@jrieken
Copy link
Member

jrieken commented Oct 11, 2016

hm... @isidorn can you comment?

@isidorn
Copy link
Contributor

isidorn commented Oct 11, 2016

I will comment here #13502 since @ArtemGovorov already created that issue

@jroesch
Copy link

jroesch commented Apr 5, 2017

Is anyone actively working on this issue? I think I understand how to make the change for this, and would be willingly to give it a shot sometime later this week.

@ArtemGovorov
Copy link
Contributor Author

@jroesch Did you have a chance to look into this one?

@jrieken I see more and more extension using text/x-code-output mime type and simply breaking each other because of this. For example an output channel highlighting supplied by one extension is breaking highlighting from other extension (even though they are highlighting completely different independent output channels).

@jrieken
Copy link
Member

jrieken commented Nov 17, 2017

This feature request will not be considered in the next 6-12 months roadmap and as such will be closed to keep the number of issues we have to maintain actionable. Thanks for understanding and happy coding!

@jrieken jrieken closed this as completed Nov 17, 2017
@seanpoulter
Copy link
Contributor

seanpoulter commented Nov 17, 2017

@jrieken, would it be considered if I submitted a PR?

@jrieken jrieken added the *out-of-scope Posted issue is not in scope of VS Code label Nov 24, 2020
@xhliu
Copy link

xhliu commented Nov 25, 2020

Any fix coming? Seems a very useful feature.

@freedomhero
Copy link

Any update for this feature request?

@zhfnjust
Copy link

we need this feature

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api feature-request Request for new features or functionality *out-of-scope Posted issue is not in scope of VS Code output Output channel system issues
Projects
None yet
Development

No branches or pull requests

8 participants