Which vte version ?

And what do you mean by "doesn't copy the new value" ?

Never mind the copying, g_intern_string copies.

I need the exact version. If you're not using 0.26.2, try with that. And if you're using ubuntu's broken vte 0.26.0, then this is expected (and NOTGNOME).

0.26.2

(Actually it seems ubuntu's still is broken even in 0.27.4, so if you're using ubuntu, that's it. Otherwise:)

Should be easy enough to modify vteapp.c with a --emulation switch to get a testcase.

The whole point is, if TERM is in the environment when running vte_terminal_fork_command_full(), vte should pick it up, not forcing something else. I'm using vte 0.26.2 from arch which has no patches.

So everything is working as expected then. Vte should make sure the child gets TERM set to the emulation as provided by vte_terminal_set_emulation / vte_pty_set_term , not the value from the passed env. 

-> NOTABUG ?

vte_pty_set_term() is not working, because there is no pty object before running vte_terminal_fork_command_full and afterwards the environs are already merged. vte_terminal_set_emulation() not only shows critical warnings, it also prevents using TERM setting like xterm-256color.
So the questions remains, why does VtePty overrides the TERM if already set? I know the child needs a TERM value, so why not only set it if not defined.

It works this way because that's how it was designed. The child process needs a TERM value that works with vte, not some random stuff passed via TERM from the parent process.

vte_terminal_fork_command_full() is just a convenience wrapper around vte_pty_new + g_spawn. It will use the emulation set from vte_terminal_set_emulation(); if you need something different, you need to use vtepty manually.

If vte_terminal_set_emulation has critical warnings, they need to be fixed. What's the exact message?

Is there a ways to get a list of accepted termcaps in vte? And although I get that both the console and vte have to both support the emulation; a user reported that exporting TERM=xterm-256color fixed the 8 color issue he had, so in that case maybe vte supports more colors, but the console application isn't aware of it.

Actually vteapp already has the --termcap option for this, and I can repro that it outputs critical warnings.

(In reply to comment #11)
> Is there a ways to get a list of accepted termcaps in vte? 

Well. If you set the emulation directly, it looks in $datadir/vte/termcap-$(VTE_API_VERSION), falling back to /etc/termcap. There are just a few builtin termcaps (xterm, xterm-color), and /etc/termcap is usually empty on modern systems.

So I guess this functionality isn't really supported right now. A first step would be to make vte use terminfo instead of termcap ...

(See also bug 169295.)

Hi,

right now, it seems that vte only ships an xterm termcap. So, afaict, the only emulation mode supported by vte-based terminals is 'xterm'.

But vte does support some fancy stuf, like 256 colors. So exporting TERM=xterm-256color works and enables (for example) the use of 256 colors theme in vim.

Exporting TERM in .bashrc/.zshenv is indeed possible, but means care should be taken there to handle all the possible terminals (for example the Linux console might not support xterm-256color etc.). It'd be best to support setting the TERM variable from the terminal actually supporting it, but right now it doesn't seem possible because of this.

I have to admit all this is a bit confusing, and it's a bid sad to not benefit of all the vte features (256 colors is an example but I guess there are other capabilities which vte has which are not used right now).

Bug 728900 will make vte use terminfo, so then you'll be able to use vte_terminal_set_emulation in your app. However, we will still use the set emulation as TERM env var when spawning, and that's not going to change.

And will that help apps benefit of the vte features?

Not sure what you mean? In any case this bug asked for a way to allow overriding TERM env var, which this will provide.

I was referring to comment #14 about the various vte features (like 256 colors). That support needs to be somehow exported to the apps, and the only way to make them aware of that (that I know) is the $TERM variable.

So I guess it'll be ok when bug #728900 is done (will that be done for vte2 and vte3 or only vte3?), so I guess adding a dependency to the bug entry would be a nice indication.

The TERM env var will always be set to the value of vte_terminal_set_emulation(). So with terminfo, you'll be able to use xterm-256color.

This will only be done on vte master, not vte2 nor vte3.