Wezterm: vttest

[erf]

Describe the bug

Are you using vttest ? It is a great way to test your terminal features. Some of them fails now.

Also maybe this comment might help.

Environment (please complete the following information):

• macOS 10.15.2 (19C57)
• Frontend: not sure
• 20200113-222147-724ad3a

To Reproduce

Download vttest from: https://invisible-island.net/vttest/

run vttest from terminal

press 1 to run the first test. press Enter several times to skip to next test and show errors.

[wez]

I ran it in the past; the problem I had with it was that it requires a human to look at it and know whether the output is correct; there is no scalable way to automate its conformance tests. I agree that we should have correct behavior, but I'm more motivated to correct behavior that manifests for real applications before behaviors that no one is actually hitting.

With that in mind, if you're experiencing something broken in an application, please file a separate issue about that with repro steps and that will get priorized ahead of vttest conformance!

[wez]

I fixed up the cursor positioning conformance. There are a couple of screens that switch to 132 column mode that look messed up simply because we don't (and lkely won't) support 132 mode at all.
I also ran through the screen tests, and they look reasonable; some don't make a lot of sense to me (scroll positioning test doesn't have any information on what correct should look like), and we're not handling some of the character set shifts, but in a UTF-8 world I don't think that is a super high priority.

[erf]

Thanks, i opened up a new issue, regarding the vis editor.

Maybe you could make a set of unit test files which tries to run spesific vt100 commands and read back the result?

Feel free to close this.

[wez]

Thanks, i opened up a new issue, regarding the vis editor.

Thanks!

Maybe you could make a set of unit test files which tries to run spesific vt100 commands and read back the result?

Yep, that's the approach used by our unit tests already!

[erf]

I noticed the background colour is not set in the vttest 2, screen 3.

Btw. i notice a lot of executables that works in other terminals, does not in this. E.g. brew and vttest i have to enter the full path. Is there a configuration to fix this?

[wez]

@erf regarding the path: that may be because your shell configuration doesn't set up your PATH in all cases; by default your $SHELL is spawned and the PATH is inherited from your desktop environment.

You can force wezterm to spawn a login shell on macOS by default placing this in your ~/.wezterm.toml; this will tell your shell to process login related startup items and will likely make your PATH more consistent:

# on macOS, ask the system to start the shell in login mode.
# This makes new tabs and windows slightly slower to appear.
default_prog = ["login", "-pf"]

[erf]

If i add that to config file, im prompted for login each time i start the terminal, which is cumbersome, but the paths work then. I dont have to do this on the other emulators like terminal, term2 and alacritty. Wonder if there is another way to solve this. Im using the zsh btw.

[wez]

I may have used the wrong arguments for login (was writing that from memory as I'm not at a mac machine right now), but if you are using zsh then you can use:

default_prog = ["zsh", "-l"]

to run it as a login shell with no auth prompts.

[wez]

btw: the reason this isn't automatic is because the unix way to spawn a login shell for any shell is to set its argv[0] to start with a - character, and Rust's command spawner doesn't current expose a way to do this.

I'm looking at adding an option to speculatively try passing -l as an option to deal with this, which happens to work for zsh, bash and fish, but may not work for other shells (so we need a way to disable it)

[erf]

Thanks, that works!

btw resize the window from vttest 2 does not work, but it does not work in Iterm2 or Alacritty either, only in the macOS Terminal app. Its a xterm controll sequence as mentioned here, not sure if it should be added or not.

[wez]

I pushed a commit that should make the login shell automatic.

regarding resizing: that's often seen as annoying; the user picked the size and placement and usually doesn't want an application to change it. There are some potential security/abuse concerns about a number of the escape sequences that manipulate things outside of the terminal display which is why they are often disabled by default. I don't see a compelling use case for that feature, and don't have plans to implement it.

[erf]

vis opens now after the 38b19cb fix ! will close #134

one weird thing is that the terminal now opens in the root folder, not in the HOME folder, on startup

[wez]

Ah, I just commented on that other issue: I think you were running the wrong vis due to the problems with your path.

Re: starting in the root folder, do you still have default_prog set? Remove that from your config file and I think you'll pick up the correct home dir.

[erf]

I removed the default_prog and that worked. Thanks for your help - good to be up and running:) Will have to look into the configuration now. Seem like a promising new terminal, great work so far!

Maybe i should close this issue now, and i could rather report in a new issue to avoid too much mess;)

[erf]

For reference, when i removed default_prog it seem i can't run executables anymore, even though i first though i could. Not sure what happened, but could you supply the link to the latest build again with the fix?

Unrelated but there seem to be an issue with utf-8 symbols, not sure if this is related to my system setup, or not supported yet.

[wez]

Please use the latest nightly build from the download page, and open new issue(s) for things that you're seeing!