Skip to content
This repository was archived by the owner on Jan 10, 2025. It is now read-only.

[Question]: How to print images in Wezterm? #187

Closed
rashil2000 opened this issue Jul 19, 2021 · 18 comments
Closed

[Question]: How to print images in Wezterm? #187

rashil2000 opened this issue Jul 19, 2021 · 18 comments

Comments

@rashil2000
Copy link
Contributor

I recently saw that image support was added for wezterm. However, I haven't got it working.

image

Is there a setting that needs to be configured?

@swsnr
Copy link
Owner

swsnr commented Jul 19, 2021

@rashil2000 Make sure to update to the latest release; other than that I'm sorry to say that you're on your own. I do not provide support for mdcat.

@swsnr swsnr closed this as completed Jul 19, 2021
@rashil2000
Copy link
Contributor Author

rashil2000 commented Jul 19, 2021

I'm on the latest version, 0.23.2, that's why I said recently.

Maybe @MuhammedZakir, who added this feature, can provide some directions?

@swsnr
Copy link
Owner

swsnr commented Jul 19, 2021

@rashil2000 Please spare me the passive aggressive emphasis; I can't guess what version "recently" should refer to.

@MuhammedZakir
Copy link
Contributor

@rashil2000: what is the output of mdcat --detect-only? Please also post the values of these environment variables:

  • TERM_PROGRAM
  • TERM_PROGRAM_VERSION
  • TERM (does PowerShell use this?)

@rashil2000
Copy link
Contributor Author

@lunaryorn I would like to sincerely apologize. I saw that the PR's (#182, #185, #186) were merged a few days ago so I assumed the recency was implied. It was really not my intention to sound aggressive.

@MuhammedZakir here are the values:

mdcat --detect-only: Terminal: WezTerm
TERM_PROGRAM: WezTerm
TERM_PROGRAM_VERSION: 20210718-221318-5904140a

PowerShell does not set the TERM variable, it is set by WezTerm itself.
TERM: xterm-256color

@swsnr
Copy link
Owner

swsnr commented Jul 19, 2021

@rashil2000 Thanks. I'm very sorry for the misunderstanding, and would like to apologize myself for the harsh reply.

I hope you'll be able to solve this problem, and I am sorry that I cannot help you any further. 😔

@MuhammedZakir
Copy link
Contributor

MuhammedZakir commented Jul 20, 2021

@MuhammedZakir here are the values:

mdcat --detect-only: Terminal: WezTerm
TERM_PROGRAM: WezTerm
TERM_PROGRAM_VERSION: 20210718-221318-5904140a

  • I use the exact WezTerm version and it works for me in Linux.
  • As you can see, mdcat indeed detects your terminal as WezTerm.

Does image works in WezTerm Windows version? Try: wezterm imgcat \path\to\image

If the above works, then it's a problem with mdcat. One thing that comes to my mind is problem with resolving path (win: \ vs *nix: /). I don't know how mdcat resolve relative paths in a cross-platform way. @lunaryorn ?

@swsnr
Copy link
Owner

swsnr commented Jul 20, 2021

Please understand that I don't provide support for mdcat. I am sorry but I just don't want to spent my own time to debug and fix other people's problems 🤷‍♂️

This is open source after all: You can read, edit, and debug the code just as good as I can.

@rashil2000
Copy link
Contributor Author

Does image works in WezTerm Windows version?

image

@MuhammedZakir
Copy link
Contributor

mdcat-0.23.0-x86_64-pc-windows-msvc.zip

Using above, see if the paths are resolved correctly. Paths will be printed above respective images.

@rashil2000
Copy link
Contributor Author

image

I think the beginning forward-slash is the problem.

See here:

image

@rashil2000
Copy link
Contributor Author

rashil2000 commented Jul 20, 2021

Update: I just tried mdcat in bash shell (Git Bash/MSys2) and the images work there...

image

No idea what's going on... :(

@MuhammedZakir
Copy link
Contributor

Update: I just tried mdcat in bash shell (Git Bash/MSys2) and the images work there...

![image](https://user-images.githubusercontent.com/46838874/126402889-94a00a9b-0e5a-4316-8ca2-81bbf8c47ad8.png)

No idea what's going on... :(

Can you try that using the executable I posted and tell me what the path is?

@rashil2000
Copy link
Contributor Author

It prints out the same path as before

@MuhammedZakir
Copy link
Contributor

MuhammedZakir commented Jul 25, 2021

One last thing: does mdcat D:/path/to/img work in bash (i.e. without leading slash)?

If it does work, then a simple fix is to remove the leading slash in images' path in Windows. Otherwise, remove leading slash
only in PowerShell? The downside is that if a shell other than Powershell does not support path with leading slash, then we will have to add that to the list of shells to remove leading slash.

If @lunaryorn is okay with above solution, I will open a PR. Of course, if there is a better way to do this, please do say so. :-)

@swsnr
Copy link
Owner

swsnr commented Jul 25, 2021

I am sorry but I'm not. This is too much of a hack in my opinion, and I'm not convinced that it is the only way.

You would need to figure out where that slash ultimately comes from, why it appears in some but not in other cases, and demonstrate why stripping it manually from the path is the only way around this.

I won't do this myself for this issue didn't affect me, and as far as I'm concerned you're not obliged to do just because you contributed wezterm support 🙂

@rashil2000
Copy link
Contributor Author

rashil2000 commented Jul 25, 2021

One last thing: does mdcat D:/path/to/img work in bash (i.e. without leading slash)?

Bash works both with and without leading slash, but PowerShell and Cmd don't.

You would need to figure out where that slash ultimately comes from, why it appears in some but not in other cases, and demonstrate why stripping it manually from the path is the only way around this.

The slash comes because the resolved URL (whether from file scheme or from https scheme) contains a leading slash in its path property. This is not a problem on Unix systems as they naturally start with leading slash, but it is a problem on Windows. I'm afraid there's no way other than to check for OS here and strip the slash on the path property if it's Windows.

I won't do this myself for this issue didn't affect me, and as far as I'm concerned you're not obliged to do just because you contributed wezterm support 🙂

I think it was pretty evident from your earlier three comments that you won't like to work on this because it doesn't affect you, but please enlighten me on the need to mention this again?

Obviously I'm in no position to force @MuhammedZakir to solve this, they're doing this voluntarily. They can straightaway say if they don't wish to spend their time on it.

Also, if you don't like people sending bug reports (that don't affect you) to you, you should specify that in the Readme. Or better yet, disable the "Issues" tab in your repo. People actually do this, it saves both the users and developers' countless minutes. I get that it works for you (because you wrote it), but at the very least people won't be under the false impression that (unlike most repos here) you're actually interested in improving your utility (for it to work everywhere).
I'm sorry if this sounds bitter but it had to be said at this point.

@swsnr
Copy link
Owner

swsnr commented Jul 25, 2021

Alright I don't think we need to take this any further 🙂

Repository owner locked and limited conversation to collaborators Jul 25, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants