5 ms·

Mouse events still don't pass through to tmux which makes it unusable in every day usage. In other words, if you use tmux and have Vim open and try to click int

by nickjj 7y ago

Mouse events still don't pass through to tmux which makes it unusable in every day usage. In other words, if you use tmux and have Vim open and try to click into Vim or any tmux window, nothing happens. This also happens without tmux too if you're just using terminal Vim. It's like the event gets absorbed and thrown out. I highly recommend to check out WSLtty if you're interested in a good WSL terminal: https://github.com/mintty/wsltty https://github.com/mintty/wsltty It has equally as low input latency, really good keyboard shortcut support, clickable URLs, tmux works perfectly (with and without the mouse), it's rock solid, uses almost no resources, has smaller / less distracting window borders vs MS' terminal and it has lots of themes. I've been using it for full time development with tmux + terminal Vim for almost a year now and it hasn't failed me yet.

zamadatix 7y ago
They just started working on this https://github.com/microsoft/terminal/issues/376 https://github.com/microsoft/terminal/issues/376 I don't think it'll make it for 1.0 as they are doing a new feature freeze.
- nickjj 7y ago
  That's unfortunate because it was reported many many preview versions ago by multiple people and that issue you linked is from a year ago. I wish they would hire the dude who makes WSLtty. It feels like the MS team doesn't want to address the really important things that make a terminal optimal for full time development. It's like they spent 3 years creating a tabbed interface and supporting icon emojis but ignored other critical features for so long (for the longest time you couldn't even zoom in and out with a hotkey).
  - 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.
  - zenexer 7y ago
    WSLtty is just Mintty, which is just PuTTY. PuTTY et al have had a very long time to mature, and I still find them to be quite problematic. They don't perfectly match any terminfo/termcap entries (they're far from matching xterm--Windows Terminal is actually closer in that regard), and even if they did, some key combinations that should send unique codes don't--for example, Shift + arrow keys, which I use with tmux.
    - JdeBP 7y ago
      PuTTY has its own terminfo entry. * https://invisible-island.net/ncurses/terminfo.ti.html#tic-putty https://invisible-island.net/ncurses/terminfo.ti.html#tic-pu...
      - zenexer 7y ago
        It does, but I've found it to be inaccurate at times, or at least have some oddities with the programs I tend to frequent (tmux with byobu configuration in particular). That's not to say it's not an improvement, but it doesn't fix everything.
        JdeBP 7y ago
        Then you should report the mismatch to get it fixed. * https://unix.stackexchange.com/a/419092/5132 https://unix.stackexchange.com/a/419092/5132 * https://unix.stackexchange.com/a/446912/5132 https://unix.stackexchange.com/a/446912/5132 * https://unix.stackexchange.com/a/560992/5132 https://unix.stackexchange.com/a/560992/5132
        zenexer 7y ago
        It's not just a mismatch issue. For example, I expect Shift + arrow keys to send unique sequences so they'll be differentiated from just plain arrow keys. PuTTY doesn't do that, nor does it provide an option to do so.
  - zapzupnz 7y ago
    I'm glad I'm not the only one struck by how bizarre those seemed as headline features. Compare to other toolkits (I'll use macOS) where automatically transitioning between windows and tabs is a standard feature of the GUI toolkit, and emoji support is provided for free by the operating system's text subsystem. I would've imagined this to be the case on Windows, at least for Metro apps — isn't that where the new GUI development is going on? I'm probably way off-base, but it always seems like problems that should be solved system-wide on Windows are solved in different ways by different teams at different times.

by nickjj 7y ago

zamadatix 7y ago

They just started working on this https://github.com/microsoft/terminal/issues/376 https://github.com/microsoft/terminal/issues/376 I don't think it'll make it for 1.0 as they are doing a new feature freeze.

nickjj 7y ago
That's unfortunate because it was reported many many preview versions ago by multiple people and that issue you linked is from a year ago. I wish they would hire the dude who makes WSLtty. It feels like the MS team doesn't want to address the really important things that make a terminal optimal for full time development. It's like they spent 3 years creating a tabbed interface and supporting icon emojis but ignored other critical features for so long (for the longest time you couldn't even zoom in and out with a hotkey).
- 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.
- zenexer 7y ago
  WSLtty is just Mintty, which is just PuTTY. PuTTY et al have had a very long time to mature, and I still find them to be quite problematic. They don't perfectly match any terminfo/termcap entries (they're far from matching xterm--Windows Terminal is actually closer in that regard), and even if they did, some key combinations that should send unique codes don't--for example, Shift + arrow keys, which I use with tmux.
  - JdeBP 7y ago
    PuTTY has its own terminfo entry. * https://invisible-island.net/ncurses/terminfo.ti.html#tic-putty https://invisible-island.net/ncurses/terminfo.ti.html#tic-pu...
    - zenexer 7y ago
      It does, but I've found it to be inaccurate at times, or at least have some oddities with the programs I tend to frequent (tmux with byobu configuration in particular). That's not to say it's not an improvement, but it doesn't fix everything.
      - JdeBP 7y ago
        Then you should report the mismatch to get it fixed. * https://unix.stackexchange.com/a/419092/5132 https://unix.stackexchange.com/a/419092/5132 * https://unix.stackexchange.com/a/446912/5132 https://unix.stackexchange.com/a/446912/5132 * https://unix.stackexchange.com/a/560992/5132 https://unix.stackexchange.com/a/560992/5132
        zenexer 7y ago
        It's not just a mismatch issue. For example, I expect Shift + arrow keys to send unique sequences so they'll be differentiated from just plain arrow keys. PuTTY doesn't do that, nor does it provide an option to do so.
- zapzupnz 7y ago
  I'm glad I'm not the only one struck by how bizarre those seemed as headline features. Compare to other toolkits (I'll use macOS) where automatically transitioning between windows and tabs is a standard feature of the GUI toolkit, and emoji support is provided for free by the operating system's text subsystem. I would've imagined this to be the case on Windows, at least for Metro apps — isn't that where the new GUI development is going on? I'm probably way off-base, but it always seems like problems that should be solved system-wide on Windows are solved in different ways by different teams at different times.