3 ms·

Poor Steven. He took so much heat then, for a concept that was way ahead of its time. These kinds of extra-helpful term emulators seem like the natural progres

Poor Steven. He took so much heat then, for a concept that was way ahead of its time. These kinds of extra-helpful term emulators seem like the natural progression of auto-completion and all the other goodies people love about oh-my-zsh. Once someone gets this right, it will seem silly to use a 'dumb' terminal in a graphical environment.

jlgreco 13y ago
There is a right way and a wrong way to add advanced features to the whole command line experience. The separation between shells and terminals is a good thing and should not be ignored. New features should be added to shells, and only if necessary, we can add new features to terminal emulators to support those shell features. Many, if not most, of those supporting features are already in terminal emulators. For example, every single modern terminal emulator supports mouse input (pretty much by definition): this could be used by shells if they were so inclined. If you want to add some sort of menu-based completion that supports mouse selection, great! The shell is the correct place to do it. Want to display some images or vector graphics? Some terminal emulators will have your back even in those situations, though support for those things would need to be more widespread before that stuff could really be used properly.
- wtallis 13y ago
  Great point. I wonder though if some of the more advanced UI features that people want as part of their terminal+shell are being held back by relatively ancient paradigms for how terminals do complex interactive stuff. In-band signalling, ReGIS, Sixel, and Tektronix 4014 all feel like old-fashioned tech that won't be getting more popular, even if they are technically capable of getting the job done.
- albiabia 13y ago
  I totally agree that in Computer Science there are established paradigms, but I think sometimes these paradigms keep people from exploring different ways of thinking. Talking specifically about TermKit: If I'm on a Mac using Terminal to access the local shell, why would I care if the features are coming from the shell itself or the Terminal app? Of course it would be 'better' or more 'proper' if all the functions were built into the shell, but like you say, it takes widespread adoption. I don't see what the problem is with starting to add features to your terminal and then let the good ones trickle back down into the shell as they become widely adopted. Seems like a confusing nightmare, but I'm not fundamentally against it.

jlgreco 13y ago

There is a right way and a wrong way to add advanced features to the whole command line experience. The separation between shells and terminals is a good thing and should not be ignored. New features should be added to shells, and only if necessary, we can add new features to terminal emulators to support those shell features. Many, if not most, of those supporting features are already in terminal emulators. For example, every single modern terminal emulator supports mouse input (pretty much by definition): this could be used by shells if they were so inclined. If you want to add some sort of menu-based completion that supports mouse selection, great! The shell is the correct place to do it. Want to display some images or vector graphics? Some terminal emulators will have your back even in those situations, though support for those things would need to be more widespread before that stuff could really be used properly.

wtallis 13y ago
Great point. I wonder though if some of the more advanced UI features that people want as part of their terminal+shell are being held back by relatively ancient paradigms for how terminals do complex interactive stuff. In-band signalling, ReGIS, Sixel, and Tektronix 4014 all feel like old-fashioned tech that won't be getting more popular, even if they are technically capable of getting the job done.
albiabia 13y ago
I totally agree that in Computer Science there are established paradigms, but I think sometimes these paradigms keep people from exploring different ways of thinking. Talking specifically about TermKit: If I'm on a Mac using Terminal to access the local shell, why would I care if the features are coming from the shell itself or the Terminal app? Of course it would be 'better' or more 'proper' if all the functions were built into the shell, but like you say, it takes widespread adoption. I don't see what the problem is with starting to add features to your terminal and then let the good ones trickle back down into the shell as they become widely adopted. Seems like a confusing nightmare, but I'm not fundamentally against it.