-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Support 1337 escape sequence to show inline images #614
Comments
Clicking on the link to open the image is possible via the an API that's experimental at the moment. It's experimental because it's likely to change but here is the current syntax: // Add a link for a particular regex and handle when it's clicked.
xterm.registerLinkMatcher(/\w\.png/, function (mouseEvent, imageFile) => {
// imageFile is the text of the link
}); The API should hopefully be finalized in the next couple of versions. |
Hi Daniel, thank you for your speedy reply! Was wondering if there a way to display html on the fly through a set of control characters? Similar to how DomTerm uses “\e]72;<html>\a” sequences ?
https://lwn.net/Articles/670078/
From: Daniel Imms <[email protected]>
Reply-To: "sourcelair/xterm.js" <[email protected]>
Date: Saturday, March 18, 2017 at 4:47 PM
To: "sourcelair/xterm.js" <[email protected]>
Cc: cristynkells <[email protected]>, Author <[email protected]>
Subject: Re: [sourcelair/xterm.js] how to view images in line (#614)
Clicking on the link to open the image is possible via the an API that's experimental at the moment. It's experimental because it's likely to change but here is the current syntax:
// Add a link for a particular regex and handle when it's clicked.
xterm.registerLinkMatcher(/\w\.png/, function (mouseEvent, imageFile) => {
// imageFile is the text of the link
});
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
@cristynkells there isn't right now, standard xterm doesn't support anything like that so if we did want to support it it would certainly need to be in an addon. |
Is this supported today? Right now I don't see how this can be done even with an add on. Basically I'm trying to investigate what it would take to build something with inline plots (something we already have in other IDE, PTVS, RTVS, Spyder, and the like e.g. https://ipython.org/ipython-doc/3/interactive/qtconsole.html). |
@DonJayamanne since this issue I've become aware of a standard some terminals have implemented for displaying images. Because of this we could add it to the core library, it's probably a pretty hefty feature though in terms of making sure everything is correct, particularly relating to getting the scroll bar right as right now there's no such thing as variable height rows in the viewport. |
Yes, I found iTerm does this. Thanks for getting back. |
Hi there. I opened a related issue on VSCode and redirected here. I wonder if supporting iTerm2 image feature is a possibility as it can be used as easy as this,
And I already used it on a project. |
@ebraminio If we are going to draw graphics and possibly some more hypertext, I would really like to be able to specify coordinates where to render it, not just blindly dump it under the current cursor position... check #1176. |
@rs: Oh, of course, how could I forget about CUP! :o) |
Opps this was labelled incorrectly. This would be a great feature to get a contribution for, here are some of my thoughts:
|
+1 for custom escape sequences. Best place to start with those is to implement OSC and DCS subparser interfaces, where custom subparser can hook into the main parser. Also the main parser still has some escape code flaws and the test library still needs to be completed to cover all the basic sequences. Btw DEC already had some terminal extensions for graphics and image loading (REGIS and SIXEL). No clue if it would make much sense to implement those, since the browser env of xterm.js has much better capabilities to draw such things. |
SIXEL is supported by some programs (gnuplot) and some terminals (mlterm, xterm), there is even libsixel (https://github.com/saitoha/libsixel) for easy conversion. Seems not to be as dead as I thought... Unsure about the OSC 1337 command, this seems to be supported by iterm2 only. Edit: Also see jupyter console and https://github.com/liftoff/GateOne, they are both capable to show graphics, not sure though if they hack it around/on top of the terminal on a higher level. This might be a nice addon feature for xterm.js, still in doubt if this should be part of the terminal itself, as it raises many questions from data and state to output representation. |
From my point of view, Sixel support would be nice for a monitoring dashboard-style thing. Could easily show gauges and stuff in it - there are even browsers, iirc, that support rendering with it. |
Any progress on this? #2503 seems to have been parked. I would really love to see inline images in VSCode especially (for Jest + Puppeteer + Jest-Image-Snapshot screenshot testing in my case). |
Bump I'd be interested in this, as well. |
@dvag-sebastian-goeb @markusbkk |
I saw. Unfortunately, that's not quite the same as iTerm2. I'm working on something that requires iTerm2 image protocol support. |
bump 🙏 |
@markusbkk PR for iterm IIP support: jerch/xterm-addon-image#43. |
Just merged the IIP support. It passes all my basic tests, but since I have no mac to work with I cannot really compare it with iTerm and therefore labelled it as alpha. So if anyone wants to do some digging - a side by side comparison with iTerm's output from different images and |
I landed here from the VS Code issue microsoft/vscode#65283. Could you describe how to test xterm-addon-image in VS Code? I am willing to test it on my Mac. |
@wsshin Idk if vscode allows loading custom xterm.js addons - if not, you prolly have to pull source and add it there yourself. |
@wsshin if you want to try test it out in vscode you can search the vscode codebase for xterm-addon-search which is an example usage of an addon from npm |
thanks for the tip @Tyriar and the addon @jerch. it seemed like i had to start with an old vscode commit (59faab44cd8287e247cfab8c389b9f0f44174bcf) to satisfy the xterm version dependency in xterm-addon-image. there's probably a better way to do this. i'm just a newbie to the code base, node.js, and typescript. |
This is prolly due to my rigid versioning policy in the addon: "peerDependencies": {
"xterm": "~5.1.0"
} which basically tags addon releases to a certain xterm.js minor version (normally most recent one). This close addon entanglement to xterm.js versions is needed due to its heavy usage of private APIs (which also cannot be exposed by public API easily). This is somewhat unfortunate, but I dont know of a better way atm. There is a major catch though with vscode - in the past vscode used the |
thanks for that remark. i haven't previously considered disregarding or updating the version requirement of xterm-addon-image. it turns out vscode:HEAD (specifically 10b2a8e42eddf7504f7b6e6b19d73eb5f888d075) compiles and works with xterm-addon-image, even though it's running xterm 5.2.x. i've updated my repo accordingly. |
is there any chance of this making it into insiders? i hadn't previously used vscode OSS, and it's starting to set in how limiting it is... not having access to extensions renders it useless... edit: i realize you can sideload extensions, but you can't evidently can't make remote-ssh work, and i do 100% of my work through the remote-ssh extension. archlinux guys have patches for this, but i'm trying to make windows OSS work, and there doesn't seem to be any workaround that i can see for the missing remote-ssh functionality. edit2: if anyone wants to try to reproduce or improve what i've done, the head commit is whatever junk i've been messing around with, and might be broken. the "good" commit is trbot86/vscode@5799f44 |
@trbot86 Plz note that there are still some loose ends with the addon - most prominent the ability to serialize image data forth and back. So I am not sure, if it is ready for production rollout yet. |
@Tyriar Should we close this issue, as the addon is in the base repo now? |
I can't find a better issue in vscode (that isn't locked) to ask this in, but now that this is implemented in vscode OSS:main, how do we get this into insiders edition? |
@trbot86 Isnt the insider edition built regularily from vscode's base repo? Because vscode's repo contains all the needed bits, so it should just work imho. Or do you mean something else with "insiders edition"? |
@trbot86 images are now enabled by default in main, stable and insiders. See https://code.visualstudio.com/docs/terminal/advanced#_image-support |
Thanks for the link. I had tested the feature without success, but the image I was testing was extremely large (~8k resolution), and it produced no output. It works when using a smaller image. Do you happen to know offhand how vscode's sixel support is intended to handle images that are too large to fit in the terminal window? Trying to isolate whether the failure is in the program converting the image to sixels, or in vscode or xterm.js. Edit: I also want to say thank you!! This is amazing! Should have said that from the beginning. :) |
@trbot86 memory
screen coverage Also see https://github.com/xtermjs/xterm.js/blob/master/addons/xterm-addon-image/README.md. |
Thanks for the detailed answer. It sounds like I'm likely butting up against pixelLimit, as the image in question was something like 8000x5000 pixels. I'm not sure how much the sixel format inflates the PNG size, but the image was something like 2-3MB. I think sixels are perhaps quite wasteful, so I could conceivably also hit the sixelSizeLimit. Well, I can probably just avoid trying to show such large images. It would be nice, from a graceful degradation standpoint, to perhaps render a small image explaining the failure when a limit is hit, rather than the actual image. No big deal though. :) |
8000x5000 pixels? Thats 160 MB in RGBA for just one image - no, you cannot expect this to work in an env with only 2GB address space. If you have hi-res output needs a terminal is prolly not the right tool for it. If you want reasonable output & performance, then it is better to grab the terminals viewport size (e.g. by
Thats not possible while maintaining the text grid - it would screw up output / screen state. Also other terminals have similar limits in place, so it is not surprising behavior. |
Yes that's totally fair. It makes sense to slice or shrink large images before viewing them. Easy enough to add an imagemagick convert -resize step in a script. |
Details
Feature request
Is there a way to view images from the command line?
by either clicking on the image (much like the linkify addon) or via a command:
$ cat vacation-beach-pic.png
The text was updated successfully, but these errors were encountered: