[HN Gopher] Rio: Terminal app built over WebGPU, WebAssembly and...
___________________________________________________________________
Rio: Terminal app built over WebGPU, WebAssembly and Rust
Author : crabboi
Score : 185 points
Date : 2023-05-24 13:25 UTC (9 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| gkfasdfasdf wrote:
| Looking forward to trying the web version on a chromebook and
| comparing to hterm.
| flashback2199 wrote:
| [flagged]
| danstewart_ wrote:
| > Be kind. Don't be snarky. Converse curiously; don't cross-
| examine. Edit out swipes.
|
| https://news.ycombinator.com/newsguidelines.html
| flashback2199 wrote:
| Thanks, I have edited my comment to meet the requirements of
| the community.
| [deleted]
| v3ss0n wrote:
| Yeah I still can't understand the point of requiring GPU for
| terminals.
|
| What webgpu needed is graphics drawing applications are most
| graphics drawing apps on web are still using canvas 2d or SVG,
| not even webgl.
|
| If we are to build a graphic heavy tool like figma - all
| choices we have are mostly SVG.
| Tade0 wrote:
| Rendering text is surprisingly resource-intensive.
|
| 10 years ago I was tasked with making a mobile browser game
| and the thing that took 30% of the time when rendering a
| frame were the few bits of text that were there to display
| the score etc.
|
| Once we started heavily caching text, performance increased
| considerably.
| flashback2199 wrote:
| Isn't rendering text inside a graphics framework and then
| saying that rendering text is surprisingly resource-
| intensive a bit like implementing an O(n log n) algorithm
| with nested for-loops and saying that the problem domain is
| surprisingly resource-intensive? Surely the thing that was
| causing text rendering to be resource-intensive was doing
| it inside a graphics framework?
| cyral wrote:
| https://faultlore.com/blah/text-hates-you/
| littlestymaar wrote:
| Rendering text, _is_ resource intensive.
|
| If you don't rotate or zoom, then most of the work can be
| cached (at least when using latin fonts with few
| ligatures) which make things appear to be fast, but if
| you tried to render text in real time without caching
| (because you're allowing rotation and zoom, and you can't
| cache everything) then you'd see how expensive it is.
| flashback2199 wrote:
| Okay, sure, rendering text that meets modern expectations
| is resource-intensive.
| mteam88 wrote:
| I would love it if I could run this in the browser over SSH to a
| remote server... Is that possible?
| VikingCoder wrote:
| There are things like it for sure:
|
| https://tailscale.com/blog/ssh-console/
|
| https://twitter.com/bradfitz/status/1585678043515084800?lang...
|
| https://leaningtech.com/webvm-virtual-machine-with-networkin...
| mteam88 wrote:
| I know, I was thinking specifically for this project.
| zamnos wrote:
| Maybe Xpra would work?
| mteam88 wrote:
| Xpra doesn't have a browser client as far as I can tell
| gnabgib wrote:
| Not presently - browsers prevent access to ports like SMTP,
| telnet, SSH[0]. Which you definitely want by default - you
| don't want a random website to be able to access services like
| that from your machine.
|
| [0]:
| https://src.chromium.org/viewvc/chrome/trunk/src/net/base/ne...
| garganzol wrote:
| There are screenshots, but not a real thing to try (in browser).
| This is somewhat discouraging.
| VikingCoder wrote:
| I hope it gets modules to make it look as awesome as Cool Retro
| Term:
|
| https://github.com/Swordfish90/cool-retro-term
| maxmcd wrote:
| Anyone see how to run it in browser? Would love to try that out.
|
| edit: seems like most of the wasm stuff is some tests within this
| lib: https://github.com/raphamorim/rio/tree/main/sugarloaf
| doodlesdev wrote:
| As someone who still just uses whatever terminal emulator my
| desktop environment provides, what are the advantages of choosing
| another terminal emulator application? Also, what's the point of
| providing GPU rendering on the terminal? I've never experienced
| latency or any problems otherwise related to rendering, so I
| wonder why some terminals nowadays pride themselves in using GPU
| rendering. Am I missing something?
|
| Also, which terminal emulator would you recommend?
| jacobsenscott wrote:
| I think it is a little like when people trick out their honda
| civic with led lights, and new speakers, etc. It is fun, but
| you can get to all the same places just as well with a stock
| honda civic. IOW it seems there are a subset of hackers that
| are sort of terminal hobbyists.
| atomicUpdate wrote:
| I use Terminator. I like all of the configuration that's
| possible with the layouts that can be done, plus it has right-
| click to paste, which I got used to with PuTTy. The default
| Terminal in Debian is very bare-bones by comparison.
| rShergold wrote:
| It may have something to do with this mind blowing exchange
| between Casey Muratori (a highly experienced game engine
| developer) and the Microsoft Terminal team.
|
| https://github.com/microsoft/terminal/issues/10362
|
| It really highlighted how crappy software gets written in large
| corporations. They told him rendering monospaced fonts on the
| GPU would involve a multi year PHD research project.
|
| Apparently they then went on to infiltrate his discord server
| so they could ask questions. Then write up a blog post calling
| the change "trivial".
|
| https://twitter.com/cmuratori/status/1522471966929653761
| zadjii wrote:
| As it turns out, the thing Muratori suggested absolutely
| _didn't_ work for a large variety of edge cases. That was
| experimented with for a couple releases before being even
| _more_ substantially rewritten:
| https://github.com/microsoft/terminal/pull/14959
|
| I hate that what was definitely intended as a joke originally
| turned into this massive miscommunication and flame war.
| Admittedly tone is hard to convey on the internet, and
| italics is no replacement for a good old fashioned ":P". But
| this could have been a good place for everyone to work
| together, rather than flame one another.
|
| It's certainly an experience that everyone can learn from.
| NegativeK wrote:
| Some older terminals are slow enough to rate limit text output
| from things like streaming logs. I don't think that's
| specifically a GPU versus CPU, though.
|
| I use Terminology, from the Enlightenment WM team. It's fast,
| supports unicode, is easily configurable, and behaves how I,
| personally, prefer. But if you don't really have a preference,
| I don't think fancy different terminals are going to be that
| important.
| moonchrome wrote:
| You never seen a case where a slow terminal would throttle the
| app running because it couldn't render output fast enough ?
|
| I use JetBrains IDEs and honestly their built in terminal
| emulators are embarrassingly slow. VSCode is buttery smooth in
| comparison. Sad state of things.
| th0ma5 wrote:
| It always seems like this kind of thing will suffer from
| accessibility issues?
| [deleted]
| eatonphil wrote:
| How does one get full CJK Input Method Editing working for a
| project like this?
|
| I've sort of been looking into it and it doesn't seem there are
| cross platform libraries for handling IMEs and not many people
| talk about even the platform-specific APIs.
| JdeBP wrote:
| I have news for whoever did that screen shot: 256 colours is not
| "all colours" nowadays. (-:
|
| There was a real push, which must be approaching a decade ago at
| this point, to get all terminal emulators able to understand the
| ITU-T T.416 control sequences for direct 24-bit RGB colour. Even
| if they implement it _really badly_ , and some do, almost
| everyone _tries_ to support this colour system now.
|
| See the screenshot of the old syscons FreeBSD kernel built-in
| terminal emulator at
| https://tty0.social/@JdeBP/110424206935120790 for what I mean by
| really badly. It still does understand the control sequences,
| though.
| wvenable wrote:
| 256 colors ought to be enough for anybody.
| fnordpiglet wrote:
| That's like 254 too many.
| CSSer wrote:
| Sounds like writing code in notepad.
| tambourine_man wrote:
| Apple didn't get the memo it seems. Terminal.app has been
| unchanged in many, many years.
|
| I still stubbornly use it as my daily driver for some probably
| terrible reason.
| tambourine_man wrote:
| I'm sticking to Terminal.app for the reasons stated by you in
| this thread. It works, it's fast and text renders beautifully
| with whatever theme you fancy.
|
| However, it could use some love from Apple. Better keyboard-
| only text selection, horizontal and vertical splitting, True
| Color (not Cyndi Lauper style)...
| dilap wrote:
| I've tried a gazillion terminals but I always come back to
| the built-in Terminal.app. I appreciate that it has no bugs
| (that I know of).
| norir wrote:
| I switched to Terminal.app from iterm2 almost 10 years ago
| because of horrific scroll and input latency for iterm2 after
| one of the osx upgrades (maybe Mavericks or Yosemite?). For
| the last few years I've been using kitty, which works well
| and for my setup allows me to eschew tmux. But Terminal.app
| still mostly just gets the job done so if it's working for
| you, I'd say stick with it.
| jackbravo wrote:
| I love that Terminal.app, out of the box, changes the
| colorcheme depending on your desktop dark or light
| configuration. iTerm does this on new versions, but only on
| 10.14 and later, which my company doesn't support yet :-p
| Patrick_Devine wrote:
| Also, Terminal.app is really bad at rendering Unicode block
| characters correctly. It doesn't space them correctly
| vertically, so if you have a lot of block chars it looks like
| total garbage. iTerm/kitty/etc. all render it correctly.
| tambourine_man wrote:
| Have you tried messing with the line height in preferences?
| The font panel will allow you to set whatever you please
| Patrick_Devine wrote:
| Yes, but I shouldn't have to do that, particularly when
| it works correctly in most other terminals.
| JdeBP wrote:
| Spare a thought for we developers of terminal emulators.
| The block and line drawing characters have been being
| bodged since the time that IBM added the extra 9th column
| in hardware.
|
| I have a fairly trivial bodge for them in mine. Kovid
| Goyal over a period of 7 years has built up an extensive
| system for overriding the glyphs for block and line
| drawing characters that are supplied in fonts and
| replacing them with ones that Kitty constructs itself,
| all started because they just didn't line up when using
| what the fonts supplied.
|
| * https://github.com/kovidgoyal/kitty/issues/16
|
| * https://github.com/kovidgoyal/kitty/blob/28b84a2d5b2720
| b88fd...
| yakubin wrote:
| I actually have the opposite problem. I'd like to limit
| terminal apps to just the 16 colours I have defined in my
| terminal settings (which is actually 3 colours in my case),
| but some apps (like the rust compiler e.g.) emit escape
| sequences which slightly change the shade in some places, in
| 256 colour space. I'd like to disable those 256 colours and
| limit everything to 16. I don't think I can though.
| sieabahlpark wrote:
| [dead]
| tambourine_man wrote:
| I think you can set how the terminal presents itself in
| both tmux and regular Terminal.app
|
| If the app doesn't check for support and simply spills the
| control characters, there may be garbled output.
| yakubin wrote:
| I've tried switching this setting in Terminal.app and all
| it seems to do is change the value of the TERM
| environment variable. I haven't observed any other
| effect.
| JdeBP wrote:
| As a rust programmer, you can explain to us where in this
| source code the rust compiler is emitting these escape
| sequences for colours outwith the AIXTerm 16 colour set.
|
| * https://github.com/rust-
| lang/rust/blob/master/compiler/rustc...
| yakubin wrote:
| I don't see it here, but one example would be help
| messages saying "consider introducing lifetime `'bla`
| here", which are preceded with a source code quote saying
| something like: fn foo<'bla>(...)
|
| According to _cat -v_ , _< 'bla>_ is preceded by
| ^[[38;5;10m, which, according to [1], "applies extended
| color value to the foreground", and further that 38;5;<s>
| sets "foreground color to <s> index in 88 or 256 color
| table".
|
| [1]: <https://learn.microsoft.com/en-
| us/windows/console/console-vi...>
| JdeBP wrote:
| Oh dear. You will I hope not be too embarrassed by
| learning that the 10 in SGR 38;5;10 (that control
| sequence) is colour index 10, which is less than 16, and
| a member of the very AIXTerm 16 colour set that you want.
| Thus the rust compiler is _not_ in fact using a colour
| outwith the 16 AIXTerm colours.
| yakubin wrote:
| Then I don't know how it happens, because I only have
| yellowish background + black and red defined in my
| terminal (also white, which I don't see used anywhere).
| And here is a screenshot from my Terminal.app, where the
| lifetime is gray: <https://0x0.st/HqVq.32.png>.
| timcavel wrote:
| [dead]
| WesolyKubeczek wrote:
| With iTerm.app, getting a message that "your system ran out
| of application memory" is a reason for me to stick to the
| Terminal.app.
|
| It's a 96 GiB of RAM machine, for chrissake! That ought to be
| enough for everybody!
| folkrav wrote:
| I used iTerm on a 2011 iMac with 6GB of mismatched RAM
| until 2018 at work, and a crappy 2012 MBP with 4GB RAM
| (subsequently upgraded to 8GB) from 2012-2016 without
| issue. This is not normal at all lol
| michaelmcdonald wrote:
| How on earth have you had iTerm use up so much memory it's
| given you an error? I've been using iTerm for years on some
| absolute crap machines, abusing iTerm with tmux and
| numerous customizations, and have never received that
| error.
| 0x457 wrote:
| Unlimited scroll buffer + compiling something large with
| verbose logs non-stop?
| awestroke wrote:
| Well just limit the scroll buffer then
| WesolyKubeczek wrote:
| Unlimited scroll buffer, but good scrollback hygiene (I
| clear scrollback after I don't need it), and it ran out
| of memory by just sitting there -- I was using something
| else during that time and all terminals had been at the
| shell prompts.
| josephd79 wrote:
| I've never had that issue before, but I switched awhile
| back to wezterm.
| _joel wrote:
| That sounds very wrong to me, I used iTerm fine for years
| on 8GB
| JdeBP wrote:
| Did anyone actually send Apple a memo? At
| https://github.com/termstandard/colors#not-supporting-
| trueco... there are pointers to where people have asked, when
| they have. There's nothing for Terminal.App.
|
| (That's the big push that I mentioned. Going since January
| 2014.)
| tambourine_man wrote:
| I don't know where or who we would address it to.
| "Feedback" is such a black whole.
| JdeBP wrote:
| Is Apple making Microsoft look good by comparison, again?
| (-:
|
| Microsoft Terminal has a whole open GitHub issues system
| to itself.
|
| * https://github.com/microsoft/terminal/issues/
| akkartik wrote:
| I think the reasons are often good:
| https://lobste.rs/s/fikvmn/farewell_macos#c_swz7p7
| [deleted]
| osener wrote:
| This is the first GUI app I've seen built with WebGPU. This is
| pretty interesting, could this be the future of cross platform
| GUI frameworks?
| tambourine_man wrote:
| Flutter uses canvas, AFAIK. Similar concept, but 2D
| dagurp wrote:
| It's only available on mac
| pastacacioepepe wrote:
| Check the roadmap, it's macOS desktop -> web browser -> linux
| desktop -> windows desktop -> nintendo switch (??)
| WirelessGigabit wrote:
| I'll switch when it runs on my Tamagochi.
| benadam11 wrote:
| https://github.com/raphamorim/rio/blob/6443ebc7dda27041cb
| 85e...
| norman784 wrote:
| AFAIK wezterm[1] and warp[2] are built on top of the WebGPU
|
| [1] https://wezfurlong.org/wezterm/
|
| [2] https://www.warp.dev
| osener wrote:
| I thought Warp was built with GPUI from https://zed.dev/,
| which is built using Metal (thus macOS only).
|
| edit: found the reference at
| https://twitter.com/nathansobo/status/1619398212712022017
| norman784 wrote:
| Thanks for the clarification.
| dizhn wrote:
| wezterm added support for it but that's not the only option.
| I don't really know much about webgpu but as far as I know
| wezterm does not run on the browser. https://wezfurlong.org/w
| ezterm/config/lua/config/front_end.h...
| [deleted]
| pdimitar wrote:
| Kinda off-topic: what's the fastest terminal for macOS these
| days?
| graypegg wrote:
| Nothing to back this up, but alacrity?
| pdimitar wrote:
| Yeah I am using it already. But recently I saw a thread here
| on HN that measured terminals by other means than what
| Alacritty advertises... and it was actually one of the
| slowest. Hence I got slightly curious but not enough to
| pursue deeply.
| jackbravo wrote:
| in their README:
|
| > Is it really the fastest terminal emulator?
|
| Benchmarking terminal emulators is complicated. Alacritty
| uses vtebench to quantify terminal emulator throughput and
| manages to consistently score better than the competition
| using it. If you have found an example where this is not the
| case, please report a bug.
|
| Other aspects like latency or framerate and frame consistency
| are more difficult to quantify. Some terminal emulators also
| intentionally slow down to save resources, which might be
| preferred by some users.
|
| If you have doubts about Alacritty's performance or
| usability, the best way to quantify terminal emulators is
| always to test them with your specific usecases.
| KrugerDunnings wrote:
| I'd love some sixel support to embedded graphics in the terminal
| MayeulC wrote:
| Or some terminal graphics protocol, which is more efficient
| than sixels: https://sw.kovidgoyal.net/kitty/graphics-protocol/
| KrugerDunnings wrote:
| That be fine also. I've been playing around with sixel and
| it's a great way to add plotting to a repl.
| stickyricky wrote:
| What's the implication of using WebGPU? Better terminals in the
| browser? Better electron terminals? A quirk for better native
| portability?
| baudaux wrote:
| Maybe building better virtual environments inside the browser
| brundolf wrote:
| VSCode's terminal is rendered with WebGL (a cousin of WebGPU),
| since VSCode is an Electron app
| fyrn_ wrote:
| WebGL is not really related to WebGPU in any way. WebGL is
| almost a strict subset of Gles3, WebGPU is a completely
| different API, sharing on a few concepts. They're about as
| related as Java and JavaScript
| brundolf wrote:
| They're different APIs, but they have similar goals and
| benefits: expose native-adjacent performance for GPU tasks
| in a highly cross-platform API supported by browsers and
| other host software. The original poster was asking "why
| [vs native graphics APIs]?", and I think the "why" is the
| same for both.
|
| Also- VSCode is literally an example of a use-case where
| you might do this in WebGPU, they just didn't
| vlakreeh wrote:
| Probably portability, it's a pretty good low (but not too low)
| abstraction layer over the systems preferred graphics API. I'm
| not a graphics programmer but my understanding is it's closer
| to vulkan or metal in terms of control over the hardware
| compared to OpenGL, which has rocky support on Mac now anyways.
| Narishma wrote:
| It's not a clear win though. You gain some portability and
| lose some to platforms not supported by WebGPU.
| littlestymaar wrote:
| What platform do you have in mind (given that WebGPU has at
| least 2 OpenGL backend, including one that supports WebGL)
| baudaux wrote:
| I suppose it is just a question of time
| JdeBP wrote:
| Sometimes "now with added GPU" is not the issue at all.
|
| There's a demo program that comes with libcaca, called cacademo.
| It can either output text to standard output with ECMA-48 control
| sequences, or crank up a built-in X client that displays a very
| simple text window.
|
| I SSHed into a remote machine with it from a local machine that
| had an X server. Tunnelled over the SSH connection, the X version
| of the demo was a little slower than running directly on the
| remote machine's own display, but mostly didn't drop frames. The
| mode where it sent ECMA-48 control sequences over the SSH
| connection to a local terminal emulator was woefully slower, to
| the point that it was displaying less than 1 frame a second
| sometimes, and visibly tearing the display. I tried it with both
| Microsoft Terminal and MobaXTerm to see whether it was the
| terminal emulator. It wasn't.
|
| Sending colour information as ITU-T T.416 RGB control sequences,
| or even as AIXTerm 16-colour control sequences, to be interpreted
| by a control sequence state machine in the terminal emulator and
| turned into a display buffer and graphics drawing commands, turns
| out not to be as efficient over SSH as the X protocol over SSH.
| Yes, X11.
|
| The X path was going through an X client library to the X server.
| It was probably using the old X11 primitives for text, rather
| than doing client-end rendering. The terminal emulator path was
| going through ncurses, then probably wasn't being batched up very
| much over the SSH connection, and then was going through a
| decoder that had to (amongst other things) parse numbers from
| human-readable to machine-readable thousands of times per frame
| because ECMA-48 uses decimal-character-encoded values in control
| sequences, and the cacademo program outputs _lots_ of colour
| changes, frequently a colour change for each successive cell.
| MayeulC wrote:
| Did you try ssh compression to see if it made any difference?
| JdeBP wrote:
| No. But it was like for like. It was the one single SSH
| connection in both cases, simply running cacademo with and
| without a DISPLAY environment variable.
|
| I think that part of the problem lies with SSH: the lack of
| batching as I mentioned, which might also be at ncurses' door
| too. Of course one wants terminal output to go over the wire
| as soon as possible, and not wait "until we have a buffer-
| ful". But not in this case.
|
| Rather, batching up the control sequences to change colour,
| cursor position, and then output the relevant character into
| a single exchange over the wire would be better. That would
| be equivalent to a an X primitive to write character X at
| position Y with attributes Z, which presumably goes as a
| single message over the wire.
|
| But a combination of whatever output buffering ncurses and
| libcaca are doing, what happens in the pseudo-terminal and
| sshd at the remote end, and then what happens at the local
| end when ssh is outputting to _its_ pseudo-terminal, are all
| almost certainly strongly militating against that.
|
| ... In addition to converting lots of numbers from machine-
| readable to human-readable, then back to machine-readable
| again. (-:
|
| I should mention that at one point I was transcoding from
| AIXTerm to ITU T.416 colour control sequences. The latter are
| about 4 times as long as the former, and that noticeably
| slowed things down even further. Yes, I'm in favour of 24-bit
| colour like the other terminal emulator authors, but it does
| come at a measurable price.
| awestroke wrote:
| Just use a non-graphical ssh session if you just want a shell
| on the remote machine
| graypegg wrote:
| Cool! Porting to the web is an interesting idea. I can't help but
| imagine going back to the 70s and trying to show someone that
| yes, everyone has this full colour, mouse-supporting, GUI app
| platform accessible on any device and interlinked between
| billions of similar interactive documents from around the
| world... but it was really important that we set up a TTY. The
| smug (or horrified) look on their face would be priceless.
| [deleted]
| norman784 wrote:
| My question is what's their selling point, I used the past few
| years few terminals that have pretty good features:
|
| - Alacritty minimal and blazingly fast
|
| - Wezterm with batteries included
|
| - Warp even batteries included
| rob74 wrote:
| Thanks for the recommendations! Since switching from Kubuntu to
| Ubuntu, I have been looking for a replacement for Konsole and
| had finally settled on Terminator, but one major gripe I have
| with it is searching the scrollback, which is a bit buggy
| (results aren't highlighted, search is case sensitive even
| though it's not supposed to be). I just tried Wezterm and it
| seems to tick all the boxes. Now I just have to figure out how
| to configure it, seems a bit more complicated than most other
| terminal emulators...
| HeckFeck wrote:
| - st, the most terminal we could fit into 3000 LOC
| ilrwbwrkhv wrote:
| Kitty has the lowest latency and is the best terminal in the
| market, but they are not on windows.
| alchemist1e9 wrote:
| Install WSL and then Nixpkgs on Windows11. Kitty away!
| manaskarekar wrote:
| Kitty is my favorite but acts weird when ssh-ing into other
| machines for reasons discussed on their github. (To do with
| setting the $TERM correctly)
| tomjakubowski wrote:
| `kitty +ssh me@example.com' installs the termcap file (or
| is it terminfo?) on the remote host for you
| happens wrote:
| Had that problem for a while too, but you can actually
| really easily set the TERM variable for every ssh
| connection separately from your local TERM. Just put the
| following in your ~/.ssh/config: Host *
| SetEnv TERM=xterm-256color
| JdeBP wrote:
| Kitty isn't "xterm-256color". That's something that
| Thomas Dickey, and I, and others, have pointed out time
| and again. It's just plain wrong to say to programs that
| something is XTerm when it isn't.
|
| Kitty is, unsurprisingly:
|
| https://invisible-
| island.net/ncurses/terminfo.src.html#tic-k...
|
| The problem that people have is different anyway. When
| they're doing things correctly, and setting the _correct_
| terminal type, they then face "But my terminfo on that
| Linux distribution DVD that I got isn't up to date!", or
| "But my termcap on FreeBSD isn't up to date!".
|
| The answer to that problem is to point out that terminfo
| supports a local ~/.terminfo/ if one needs one, and
| FreeBSD termcap has a TERMPATH environment variable that
| one can point at a ~/.termcap.db file, or indeed one
| placed anywhere else, if the system termcap database
| isn't up to date.
| happens wrote:
| I'm not sure what to make of this. The terminfo you
| linked suggests to me that kitty provides at least the
| same capabilities as xterm-256color, unless I'm
| understanding the "use" capability wrong.
|
| Most machines I've SSHed into didn't have kitty's
| terminfo installed, which results in many things not
| working. Using xterm-256color as a safe fallback has
| always worked for me however. It would always be possible
| to define the TERM variable per host and use TERM=kitty
| for hosts that have the correct terminfo installed. Is
| there a drawback to that apart from not being technically
| correct?
| Patrick_Devine wrote:
| Kitty also has the benefit of supporting much better keyboard
| handling through key codes. This includes things like button
| press/release/repeat, other keyboard modifiers and better
| escape handling. More details:
| https://sw.kovidgoyal.net/kitty/keyboard-protocol/
|
| It's really a shame that more terminals don't support this
| protocol, because we could have a lot more sophisticated
| terminal applications.
| sjm wrote:
| Yeah I'd love to know what this is aiming for over WezTerm,
| which already supports both WebGPU and OpenGL rendering. Maybe
| just that it is closer to being able to run in a browser?
|
| I have to take a moment to just evangelize WezTerm a bit. I
| switched over from iTerm in the last few months and IMO
| WezTerm's absolute killer feature is its Lua-based
| configuration. You can do so much with it, down to running
| scripts on key binds, and the API is powerful enough to do
| virtually anything you want. For example I have some key binds
| that act differently when the active pane is running emacs vs.
| a shell.
| josephd79 wrote:
| I'm also a WezTerm user for awhile now, Lua based config is
| definitely rad.
| nxpnsv wrote:
| I love how WezTerm feels consistent between my Linux and Mac
| machines. Lua config took me a while to figure out, but
| keeping it simple works well...
| alwillis wrote:
| +1 for WezTerm. Switched from iTerm2 a while ago and have
| been very happy with it. Its configurability is next level.
| esjeon wrote:
| This is anyway a niche market on Linux - you can go really far
| with gnome/kde default terminals, and even slimmer ones like
| xterm/urxvt/st are more than enough to perform all the
| necessary tasks.
|
| Perhaps, on Mac, you badly need an alternate terminal app ,
| because the default one is unbearably slow.
| BaculumMeumEst wrote:
| > the default one is unbearably slow
|
| https://danluu.com/images/term-latency/loaded-terminal-
| laten...
| natrys wrote:
| Meanwhile I have to wonder what's the selling point of these
| over good old urxvt? It has an ecosystem of perl plugins, which
| has all the batteries I need and more. In its daemon/client
| mode I can have 20+ terminal windows open and they consume sum
| total of like 30MB memory, with embedded perl interpreter and
| everything. I feel like one or two instances of these modern
| incarnations is enough to completely dwarf that number.
|
| GPU rendering is really cool, but I don't really understand
| what might people be doing where CPU rendering in terminal is
| anywhere close to being a bottleneck. People lose ability to
| comprehend way before that, why would I want gibberish to be
| printed even faster? Redirecting output to a file (or
| /dev/null) is almost always what I would want?
| awestroke wrote:
| Well, if you search for these projects yourself and read the
| first few paragraphs on their websites, you might learn the
| selling points. Warp has a lot of features that are just not
| possible in urxvt.
| natrys wrote:
| Having seen them, there are two things I have to say:
|
| 1. I wouldn't say there really is much that would be "just
| not possible" in urxvt. If you drop down to Perl level, you
| can do almost everything (albeit you would have to write
| Perl).
|
| 2. The reason urxvt doesn't have majority of those selling
| points is because they arguably aren't the concern of
| terminal emulator at all. Things like better autocomplete
| menu, command editing, history browsing etc. historically
| fell under purview of the shell. You can have all these
| things with say zsh and a few chose plugins.
| JaggerJo wrote:
| But.. why?
|
| Couldn't you just use Rust + OpenGL/SDL2/.. or even AppKit if
| macOS is the only supported OS?
| awestroke wrote:
| Feel free to use those things
___________________________________________________________________
(page generated 2023-05-24 23:01 UTC)