Hacker News new | ask | show | jobs
by robertelder 3094 days ago
Love:

- Being super productive with terminals

Hate:

- The #1 thing by far in my book is not having better support for unicode. It is not possible to accurately determine the width of a unicode character in advance of printing it in the terminal. I'm aware that there are many non-printable and control characters with unicode that don't have a 'width', but even if you neglect those, the code that determines how wide a unicode characer is, is terminal specific and there is no way to access the information in advance in order to correctly align text that contains unicode, for example with whitespace padding.

This is the kind of problem that will never bother you until it does, but then when you do encounter it, you can beat your head against the wall for weeks without finding a satisfactory solution, and the only thing that comes close is something that detects aspects of your environment on every terminal out there.

I think that improving support for unicode in terminal is something that would be a good idea to do sooner rather than later, because unicode will only get more important, and in the meantime, people will continue to build abstractions upon very poor interfaces that will need to be supported in the future. Unicode is insanely complicated, so it might be too much work to support it fully, so one solution might be to expose some API that gives people the power to make their own work around (for example, through access to an snprintf like function for where n = max print width). You could add other kinds of 'empirical test' functions that allow you to avoid the work of actually understanding the entire unicode standard (which is still changing).

Here is a github repo that documents the unicode problems I have encountered:

https://github.com/RobertElderSoftware/roberteldersoftwaredi...

If I had to build one from scratch:

- If I was building one from scratch, I would probably put a better focus on separating out all the different components that actually make up the 'terminal'. In a typical bash session, you've got: /bin/bash, ttys, ptys, the terminal emulator, readline (possibly), process groups, session leaders, file descriptors, etc. This stuff is all extremely difficult to learn, and it is very 'invisible' to the average user. Most people don't need to think about it, but when you want to do certain kinds of automation tasks, they become very important.

It would be cool, if each of these concepts was formalized to provide a well-defined interface and reduce tight coupling between these components. As it is, to an average user these concepts blur together and seem like they're 'the same thing'.