strange fish_title behaviour ?

[pik]

I use Tilda for my primary terminal, which supports terminal-tabs, additional tabs have their associated titles placed along the top of a Tilda-Window, if more tabs are in existence than the width of the window, it is possible to scroll through these left and right.

Now the issue I'm having is that when function fish_title is triggered (which is to say any command) there appears to be a brief instance where the length of the title screen is indeterminate or otherwise different from pre-command and post-command state. Specifically this behaviour is visible because Tilda will re-arrange (scroll) the tabs as it would on change of title-length, even though the title might not have changed at all from pre-command to post-command states. Setting a static title via. a set_title function will prevent the re-arrangement/scrolling of the title bars.

function set_title -a new_title
    eval "function fish_title; echo $new_title; end"
end

Here is my normal title function for reference:

function fish_title
    if test $_ = 'fish'
    switch (pwd)
      case /
        echo "      /      "
      case '*'
            pwd
      end       
    else 
      echo $_ 
    end
end

[ridiculousfish]

This sounds like a terminal bug to me. What happens if you run, say, echo -ne "\033]0;foobar\007" in bash? Does it reproduce?

[pik]

echo -ne "\033]0;foobar\007"

Does not produce any output.

Here is what the signal connection in Tilda looks like:
g_signal_connect (G_OBJECT(term->vte_term), "window-title-changed", G_CALLBACK(window_title_changed_cb), term);

Adding a debug_print to window_title_changed_cb shows that each fish command results in two callbacks. I haven't looked at the libvte code for it - so not sure.

[ridiculousfish]

In bash, echo -ne "\033]0;foobar\007" should change the title to foobar. It's not expected to output to the console. When you run it, does the title bug reproduce?

Also, it sounds like you're set up to instrument the title change callback - are you able to print the title that's being set? It's surprising that there's two callbacks here. From inspecting the fish code I only expect one.

[pik]

echo -ne "\033]0;foobar\007"

On OS X in bash this does change the title, in Linux it produces no output (or title change). Likewise no output in fish on either OS X or Linux.

I'm not sure why there are two callbacks there either. If I set it to function fish_title; echo foo;end I still get two window-title-changed signals per terminal command, I'll try and take a look at the libvte code over the weekend.

[pickfire]

echo -ne "\033]0;foobar\007"

I don't produce that in Linux either.

[pik]

I haven't read the fish-shell code for set_title but I can add some additional information which may be useful. Here is a gist of a short Tilda run with vte compiled with some custom print statements: https://gist.github.com/pik/deac6f2b0b963bd57811

Here is a fish_title function which seems to exhibit the problematic behaviour (tested in tilda, gnome-terminal, xterm {Linux 4.2.5-1-ARCH #1 SMP PREEMPT}) -- A single env call will always increment TITLE by 2.

function fish_title
    set -q TITLE; and set -gx TITLE (math $TITLE + 1); or set -gx TITLE 0;
    pwd
end

[faho]

From the docs:

The $_ environment variable will always contain the name of the job to be put into the foreground (Or 'fish' if control is returning to the shell) when the fish_prompt function is called. The first argument to fish_title will contain the most recently executed foreground command as a string, starting with fish 2.2.

It's not quite said outright, but fish_title is called once when a command is executed and then again when control returns to fish. (This appears necessary to me so the title doesn't include the last command when fish is in control again)

So incrementing by 2 is as-intended. Why tilda seems to not get the titles, I don't know - is this maybe an issue with it not reacting fast enough?

[pik]

@faho - I didn't realize this was an intentional behaviour (bash only emits a single event per command), if you read my opening comment the problem isn't that Tilda isn't reacting fast-enough, it's rather it reacts right away - so a command which alters the title (however briefly) will displace the terminal tabs, but in that case this might be best avoided adding a configurable min-width to tilda.

[krader1961]

There have been so many changes to the relevant code since this was opened, and few people are using this niche terminal, I'm going to close this. If fish 2.5 on Tilda is still broken for you, @pik, please reopen.