5 ms·

With respect, emoji support and tabs were the most requested features for years according to the uservoice page that tracked the public feature requests. I no

by austdi 7y ago

With respect, emoji support and tabs were the most requested features for years according to the uservoice page that tracked the public feature requests. I no longer work on the project but that team is filled with some of the most passionate and dedicated people you could find to shepherd the console from where it was to now. We collectively lived and breathed the console, yet the team was always understaffed and almost always had at least one dev that was pulled off by management to work on what was believed to be a higher priority project. Implementing the emoji support took me years and that doesn't even count the rendering of them, just the ability to shuttle them through the internals and back. Tabs as well required quite a bit of work behind the scenes, there was an entire blog series written on the work that led up to tabs being possible.

rcarmo 7y ago
There is a substantial difference between random (but massive) user feedback and expert user feedback. UserVoice fails utterly at capturing the latter, because very specific (and critical) user feedback gets buried under “nice” things that fall outside the 80% of what users actually _need_. As a former Marketing guy (reformed) I’ve seen this time and again, and really wish features were prioritized differently—not to diss on what you did, since I’ve had plenty of pains with encodings, code points, etc. over the years-but considering the target audience for a terminal, I would definitely have prioritized mouse reporting over it, because it would make non-Windows users happier and more likely to adopt Windows/WSL as their primary development platform.
- bitcrazed 7y ago
  PM for Windows Command-Line here. Appreciate your feedback, but we solicited and received feedback from many, MANY sources. UserVoice, Stack Overflow, Github Issues, customer interviews, email, Twitter, comments after speaking at events, comments from customers at booths at OSCON, Build, Ignite, JSConf, PyCon, etc. to name just a few. We received an OVERWHELMING number of asks for unicode text support. Emoji are simply one class of unicode glyph but they're pretty important for those working with tools/scripts that use emoji to indicate the state or outcome of an operation. Further, many users speak non-Latin languages which require non-ASCII glyphs, some of which can be quite challenging to support in a grid-based display format (e.g. Arabic, Hebrew). This whole class of asks around "Unicode Support" required not just a brand new renderer that could actually draw the correct glyph in the correct cell, but also a whole new way of storing, iterating, and navigating variable-width code-points qucikly and efficiently. These asks (and many others like them) vastly outnumbered asks for mouse support.
nickjj 7y ago
> Implementing the emoji support took me years and that doesn't even count the rendering of them, just the ability to shuttle them through the internals and back. Tabs as well required quite a bit of work behind the scenes, there was an entire blog series written on the work that led up to tabs being possible. I'm not trying to knock your efforts but wouldn't you say being able to use the mouse takes priority over things like this? Especially since your target audience is Windows users. I could be totally wrong but every time I try out the MS terminal I get the impression that no one on the dev team uses it in their day to day because there's no way it could ship multiple times for years without mouse support otherwise.
- austdi 7y ago
  I would say that emoji support takes precedence, because emoji support implies support for UTF-16 surrogate pairs. Originally the console could only support UCS-2 which could not represent all CJK characters. Adding surrogate pair support brought better functionality to a significant portion of the world's population. Emojis were only a (very visible) part of that feature. Besides, the console does support the mouse. It's my understanding that mouse input events have been available for decades. I'm not sure where you're seeing problems with them. I can guarantee that everyone on the dev team dogfoods their product.
  - JdeBP 7y ago
    nickjj's description was very clear: > if you use tmux and have Vim open and try to click into Vim or any tmux window, nothing happens. This means one of three things: * tmux doesn't know to enable mouse reports, which will be almost certainly a TERM and terminfo configuration issue. * The terminal emulator does not recognize the control sequences that turn on the various kinds of mouse reporting (DEC Locator, X10, Unicode rxvt, and ECMA-48-conformant XTerm). * The terminal does not pass on mouse input events as mouse reports. I shouldn't play the "mouse input events have been around for decades" card here, if I were you. DEC Locator reports precede anything relating to Win32, dating back to the VT220 in 1983. People could quite justifiably play the "Windows Terminal is not as good as a terminal from 1983" card in response. (-: ... and zamadatix did point to the known open issue on this. It's both the second and third items.

by austdi 7y ago

rcarmo 7y ago

There is a substantial difference between random (but massive) user feedback and expert user feedback. UserVoice fails utterly at capturing the latter, because very specific (and critical) user feedback gets buried under “nice” things that fall outside the 80% of what users actually _need_. As a former Marketing guy (reformed) I’ve seen this time and again, and really wish features were prioritized differently—not to diss on what you did, since I’ve had plenty of pains with encodings, code points, etc. over the years-but considering the target audience for a terminal, I would definitely have prioritized mouse reporting over it, because it would make non-Windows users happier and more likely to adopt Windows/WSL as their primary development platform.

bitcrazed 7y ago
PM for Windows Command-Line here. Appreciate your feedback, but we solicited and received feedback from many, MANY sources. UserVoice, Stack Overflow, Github Issues, customer interviews, email, Twitter, comments after speaking at events, comments from customers at booths at OSCON, Build, Ignite, JSConf, PyCon, etc. to name just a few. We received an OVERWHELMING number of asks for unicode text support. Emoji are simply one class of unicode glyph but they're pretty important for those working with tools/scripts that use emoji to indicate the state or outcome of an operation. Further, many users speak non-Latin languages which require non-ASCII glyphs, some of which can be quite challenging to support in a grid-based display format (e.g. Arabic, Hebrew). This whole class of asks around "Unicode Support" required not just a brand new renderer that could actually draw the correct glyph in the correct cell, but also a whole new way of storing, iterating, and navigating variable-width code-points qucikly and efficiently. These asks (and many others like them) vastly outnumbered asks for mouse support.

nickjj 7y ago

> Implementing the emoji support took me years and that doesn't even count the rendering of them, just the ability to shuttle them through the internals and back. Tabs as well required quite a bit of work behind the scenes, there was an entire blog series written on the work that led up to tabs being possible. I'm not trying to knock your efforts but wouldn't you say being able to use the mouse takes priority over things like this? Especially since your target audience is Windows users. I could be totally wrong but every time I try out the MS terminal I get the impression that no one on the dev team uses it in their day to day because there's no way it could ship multiple times for years without mouse support otherwise.

austdi 7y ago
I would say that emoji support takes precedence, because emoji support implies support for UTF-16 surrogate pairs. Originally the console could only support UCS-2 which could not represent all CJK characters. Adding surrogate pair support brought better functionality to a significant portion of the world's population. Emojis were only a (very visible) part of that feature. Besides, the console does support the mouse. It's my understanding that mouse input events have been available for decades. I'm not sure where you're seeing problems with them. I can guarantee that everyone on the dev team dogfoods their product.
- JdeBP 7y ago
  nickjj's description was very clear: > if you use tmux and have Vim open and try to click into Vim or any tmux window, nothing happens. This means one of three things: * tmux doesn't know to enable mouse reports, which will be almost certainly a TERM and terminfo configuration issue. * The terminal emulator does not recognize the control sequences that turn on the various kinds of mouse reporting (DEC Locator, X10, Unicode rxvt, and ECMA-48-conformant XTerm). * The terminal does not pass on mouse input events as mouse reports. I shouldn't play the "mouse input events have been around for decades" card here, if I were you. DEC Locator reports precede anything relating to Win32, dating back to the VT220 in 1983. People could quite justifiably play the "Windows Terminal is not as good as a terminal from 1983" card in response. (-: ... and zamadatix did point to the known open issue on this. It's both the second and third items.