Added a basic hack to change the tab title via the display handlers.

[tmr232]

You can use the following code to change a tab's title:

def set_title(title):
    display.display({'title':title}, raw=True)

This seems like a bit of an ugly solution, abusing the display handlers, but I figured any other solution would require adding more IPC to the code so we are better off like this.

closes #100 and #122.

[takluyver]

I think additions to the messaging protocol (which is what this is) need to be thought out more carefully. It makes sense to have something like this - we can change the title in the terminal as well, so jupyter console could look at the same field. I'm not sure whether it would make sense to display the 'title' somewhere in the notebook UI too.

I don't think sticking it into the display_data mimebundle is quite the right way to do it. A new message type would probably be the cleanest way, but we generally have quite a high bar to add message types. It could be metadata on an existing message, or a 'payload'. @minrk , thoughts?

[tmr232]

I figured as much. Since this is a tiny amount of code, I thought it would not hurt to suggest it as it would not cost anyone too much time reviewing.

For future reference - should I submit PRs to get feedback, or is there another place to bring up ideas?

[takluyver]

It's fine to submit PRs to get feedback, but for things that change the messaging protocol between the kernel and the frontend, it's fairly unlikely that they'll be accepted as is. In these cases, you may want to bring it up on the Jupyter mailing list first. Or open an issue on the jupyter_client repo, which is where the message protocol docs live.

[minrk]

While I don't love payloads, this is an area where they might work. Alternately, the current trend toward custom mime-types might also allow this to be done without any extensions to the message spec.

[ccordoba12]

The title of a tab is something that should be handled by the frontend, not the kernel because IMHO it doesn't have anything to do with executing code :-)

So I'd propose to close this PR and just follow #148.