blog · git · desktop · images · contact
2018-01-21
There haven’t been a lot of changes in xiate in the last two years. The program worked and stayed pretty much the same. There have been things that kept bugging me, though, and they are about to be addressed.
xiate has a client-server model, so there’s a daemon running all the time and to open a new terminal window, you have to use a little client. They communicate using a UNIX domain socket. To keep the code simple(r), the client simply send a message to that socket and then quit. This is about to change.
xiatec now blocks until the associated terminal window has been
closed – just like running xterm does. And I think this is a sensible
thing to do.
This opens new scripting possibilities. Or rather, it brings them back, if you used XTerm before. It means you can do this again:
#!/bin/sh
xiatec -e vim /some/file
do_more_work_on /some/file
The second command won’t be executed until the terminal running Vim has finished. I actually needed that in a script recently.
About a year ago, ccrusius on GitHub opened a pull request for xiate
that included a rewrite of xiate’s client in C. I didn’t listen back
then and didn’t see the need for it. The original xiatec is a shell
script that uses socat to talk to the server. It was very short and
simple.
Problem is, if you want to keep the socket connection open until the
server closes it, things are not so simple anymore. It certainly is
possible to do this in a shell script, but it’s ugly. Plus, socat adds
a few megabytes to the memory footprint, which matters now since there
would be a lot of theses processes.
So, kick the shell script, write a little C client.
As I said in the original blog post about xiate, the client-server model is about performance. When I began writing xiate, even the most simple VTE terminal program took about a second to start up. This was unacceptable. The client-server model is a workaround.
Later, I found out that neither VTE nor Gtk had nothing to do with this problem. It was UIM that caused the delay. This framework needed to parse a lot of files on each startup and that takes time. If you don’t have UIM installed, everything’s fine.
Now, I don’t need UIM. I had it installed because I was interested in foreign languages that don’t use the latin alphabet. I could just remove it.
I did that and I removed the client-server model from xiate as well – in a development branch. It was fast enough. (And so were all the other VTE terminals, so I thought about using sakura for a while. At the end, there were some features missing, though.) But: Memory usage skyrocketed. Each terminal window now needed at least 30-40 MB of RAM, maybe even more if you had a long scrollback history.
The original server needed 40-50 MB of RAM for multiple terminal windows.
It’s 2018 and all of our machines have a hell lot of RAM. Still, I’m not yet ready to accept that one terminal window needs that much memory. Maybe I’ll change my mind later. (Or maybe I’ll have a mental breakdown, kick out all CPUs that do speculative execution and work on a tiny box with a tiny but exotic CPU all the time. Who knows.)
This is something that only st can do (at least I didn’t find it in any other popular terminal emulator):
$ xiatec -e /bin/true; echo $?
0
$ xiatec -e /bin/false; echo $?
1
If the programm running inside of the terminal quits with a non-zero
exit code, you can now evaluate that in the parent process. Just like
with st, xiatec will only return 0 or 1:
$ xiatec -e sh -c 'exit 42'; echo $?
1
$ st -e sh -c 'exit 42'; echo $?
child finished with error '10752'
1
The original exit status is lost, because if there is an internal xiate error, you cannot tell this apart from an error in the child program. An exit code of “42” is meaningless – it may have come from the child or from xiate. You don’t know.
Many modern terminal emulators have a “search” feature. xiate now has something that – I think – is more powerful. Hit Ctrl+Shift+F to dump the content that’s currently visible in your terminal (including scrollback history) to a temporary file and then run a custom tool on that file.
My tool for this job looks like this:
#!/bin/sh
trap 'rm -f "$1"' EXIT
xiatec -name term-floating -e vim -R "$1"
When I hit Ctrl+Shift+F, I now get a new terminal window showing all the content in Vim. I can search through it, edit it, save parts of it to a file, whatever.
Well, I hope there won’t be so many changes in the future anymore. I want to do a feature freeze now and kill any bugs that I may have introduced with the recent changes.
Maybe the binaries will get renamed in some future release. I think
the daemon should be called xiated and the client remains xiatec, so
it’s immediately clear what you’re dealing with.