[HN Gopher] WezTerm is a GPU-accelerated cross-platform terminal...
___________________________________________________________________
WezTerm is a GPU-accelerated cross-platform terminal emulator
written in Rust
Author : thunderbong
Score : 131 points
Date : 2023-03-13 15:34 UTC (7 hours ago)
(HTM) web link (wezfurlong.org)
(TXT) w3m dump (wezfurlong.org)
| SaintSeiya84 wrote:
| In what something is written is irrelevant, please stop with this
| "written in Rust" as it is not an automatic badge of quality. if
| you have to specify that something is written in any language
| (Rust the latest trend) then it has no merits on its own.
| gchamonlive wrote:
| Is it trying to pull merits from the fact that it is written in
| Rust, though? I think attributing quality claims by default
| from the language is something you are projecting on your own.
| The title just says it is "written in Rust", not "written in
| Rust, therefore better".
| eyko wrote:
| After trying out Hyper (electron), Warp (Rust) and iTerm
| (Objective-C, Swift), I'm not as much interested in the
| language itself, but at least the fact that it's not an
| Electron terminal. So I guess I do subconsciously project the
| "therefore better", not because it's Rust, but because I'm
| assuming it won't grab a couple GB of memory.
| bakugo wrote:
| > The title just says it is "written in Rust", not "written
| in Rust, therefore better".
|
| Why does the title say "written in rust" then, if not because
| the author believes it's inherently worthy of merit? It's
| largely irrelevant to users of the software.
| timeon wrote:
| For those who may be interested? Why does it bother you
| when it is not relevant to you?
|
| I follow HN mostly through RSS with various filters. Rust
| is one of the keywords that I follow.
| smohare wrote:
| [dead]
| cstrahan wrote:
| Knowing something is written Rust does tell me that it will be
| relatively easy to add my own features (possibly upstreaming
| those changes if others so desire) and fix any bugs I find.
|
| Why? Because a project written in Rust will certainly be using
| Cargo for package management, which is absolutely delightful
| relative to just about any other language's package manager.
|
| I can git clone and start hacking on just about any Rust
| project almost immediately. If I'm using 100 tools throughout
| the day (that's a conservative estimate) I'd much prefer each
| of those were written in Rust than C or C++, for instance.
| Otherwise that's 100 opportunities for me to find a missing
| feature or bug and end up futzing with autotools and cmake and
| ninja and distro-packaged but-not-quite-the-right-version
| dynamic libraries and broken pkg-config files and and and...
|
| As an example, I recently needed to add support to probe-rs for
| debugging embedded devices via JTAG with a CMSIS-DAP probe. One
| git clone and I immediately have all of my dependencies
| resolved, my editor immediately has go to definition and
| autocomplete working, and I have a host of debug target
| definitions for debugging probe-rs itself.
|
| OpenOCD doesn't support the chip I'm targeting, so if I wanted
| to use that instead of probe-rs I'd have to first set up a dev
| env for it and add that support myself. That consists of using
| a tool like bear to trace the build execution so it can spit
| out a compile_commands.json file so the C and/or C++ language
| server can make sense of the project. Oh, and I need to repeat
| that step if I realize later that I missed a couple defines,
| otherwise the lang server will think huge swathes of code are
| preprocessed-out. And this is all _after_ I've chased down the
| myriad of build and runtime dependencies.
|
| I find missing functionality and/or critical show stopping bugs
| _regularly_ in the tools I use, and it doesn't matter if the
| tools are commercially funded or super popular or whatever: I
| opened an issue for a critical miss-linking problem in Google's
| bazel build rules for the Go language, and that's _still_ open
| something like 6 years later. And ironically, I discovered the
| bug while working on a project that uses Go, C++ and C++
| protobufs -- two of those things are Google inventions, and the
| other is a predominant language in the Google stack! Their own
| stuff doesn't even work together.
|
| So no, it's not a matter of me choosing bad tools, to be clear.
| I'm just often put in a position that the best course of action
| is rolling up my sleeves and fixing whatever issue I've
| discovered.
|
| For someone like me, knowing something is written Rust gives me
| some peace of mind, knowing that it'll be (comparatively) easy
| to work on when I inevitably discover a deficiency. Not because
| the language is great (though that's also true), but because
| the package management simply doesn't suck.
|
| So please, please stop with the fallacy that "it has no merits
| on its own". It does have merits, though maybe you don't
| personally appreciate them. And that's okay. But some of us
| _do_ appreciate those merits -- and they very much
| unequivocally, objectively are there.
| rickette wrote:
| A few years back lots of posts included "written in Go". I
| don't we'll ever get rid of it...
| crispinb wrote:
| Much as it can be irritating for a hype/hate-intolerant person
| (I am one too), you cannot possibly contend it's irrelevant
| here, so you'll just have to put up with it.
| badsectoracula wrote:
| > In what something is written is irrelevant, please stop with
| this "written in Rust" as it is not an automatic badge of
| quality.
|
| It is not an automatic badge of quality for the program itself,
| but it is an indicator that someone, somewhere is using
| $LANGUAGE to make a program like that.
|
| It isn't so much promotion for the program itself, but for
| $LANGUAGE both to attract like-minded programmers who like it
| as well as show other programmers that $LANGUAGE is using for
| making things - which perhaps will give them an incentive to
| check out the language too, if for no other reason than perhaps
| answering the curiosity some may have about how a program like
| that is written in that language.
|
| Hacker News is a place full of programmers after all and
| programmers do tend to care about programming languages and
| their uses.
| [deleted]
| flykespice wrote:
| > In what something is written is irrelevant
|
| Would you say the same if something was written in FORTRAN,
| COBOL or assembly?
| DannyBee wrote:
| It is also unlikely, being a GPU based terminal, that it is
| written without lots of unsafe memory munging and other fun
| things, since the underlying API's are still C/C++, and even if
| they aren't, interacting with GPUs and other hardware is just
| hard sometimes if they haven't been built thinking of your
| programming of language. There is of course, a difference
| between wrapping C apis and them being automatically unsafe,
| and using lots of unsafe rust like memory transmutation/etc.
|
| In the case of wezterm, a quick glance shows that not only is
| this correct (lots of unsafe rust, even beyond the normal use
| of wrapped functions), there is also not a lot of documentation
| about what the safety conditions of the various unsafe code is.
|
| (which is the usual good practice in handling this sort of
| thing).
|
| So to your point, saying it's "written in rust" doesn't matter
| here.
| einpoklum wrote:
| > since the underlying API's are still C/C++,
|
| If the use of GPUs is via CUDA, there are my wrappers [1]
| which are RAII/CADRe, and therefore less unsafe. And on the
| Rust side - don't you need a bunch of unsafe code in the
| library enabling GPU support?
|
| [1] : https://github.com/eyalroz/cuda-api-wrappers/
| DannyBee wrote:
| You do, but people here really don't like to admit the rust
| ecosystem is like that. There is plenty of code that is
| infinitely better and safer than the equivalent C++ would
| ever be.
|
| There is lots of "bad" unsafe code that is much worse, and
| over time, they will have just as much trouble trying to
| handle this overall as C++ does.
|
| (and no the ability to say you don't want unsafe transitive
| crates doesn't fix anything)
| kvark wrote:
| Is it really? If I see a game written in, say, Haskell, this
| grabs my interest. What's wrong with looking at Rust written
| software?
| eredengrin wrote:
| Not sure if you are referring to the title specifically or the
| trend in general, but the title is taken almost directly from
| the one sentence blurb on the wezterm site. As a general
| description, I can see why as an open source project it would
| be useful to include the implementation language as one of the
| first descriptors of the project, and this seems to be fairly
| common practice. For example, look through just about any This
| Week In Matrix [0] blog post and you'll see various projects
| described as "x written in C" or "y written in C++17" or "z
| written in kotlin" etc. Programmers/sysadmins are curious so
| for a tool aimed primarily at that demographic, I don't see why
| a project shouldn't include that it's written in rust just to
| avoid grouping itself with the other trendy rust projects (as
| you likely wouldn't have complained if it were written in eg
| c++ and advertising that fact in its one sentence description).
|
| [0] https://matrix.org/blog/posts
| Strom wrote:
| It's not irrelevant for open source. As a Rust programmer I
| find these projects much more interesting than say COBOL, which
| I don't use. The ability to fix something myself is a big
| factor in my choice of what software I use.
| feiss wrote:
| I've been using it for +1 year now, love it.
|
| I have only one complain: I tried everything to configure it to
| open in a specific position in the screen (top left corner), and
| for FSM's sake, It's impossible! (Windows 10)
| eviks wrote:
| it's possible now with the nightly version (might need negative
| X on some machines) local wezterm =
| require("wezterm") wezterm.on('gui-startup',
| function(cmd) -- set startup Window position local tab,
| pane, window = wezterm.mux.spawn_window(cmd or
| {position={x=0,y=0},width=100,height=20} ) end)
| ama5322 wrote:
| On my machine, when I last tried the various accelerated terminal
| emulators, I wasn't convinced. At least under plain X, GL context
| creation adds extra latency when creating new windows (might be
| different if you use a compositor all the time I guess). In
| addition, on terminals such as kitty, the startup time of a full
| new process was really non-negligible I suspect due to the python
| support.
|
| With a tiling window manager, the built-in notebook/tiling
| functionality is not really useful (the window manager is more
| flexible and has universal keybindings) so when looking at the
| time required to pop a full new window in either single or shared
| instance they were actually behind regular xterm. Resource usage
| wasn't stellar either (xterm was still better than most
| lightweight libvt-based terminals). Couldn't feel much of a
| latency improvement (again, X without compositor).
|
| I'm sure at full throughput the difference is there, but who is
| looking at pages of output you can't read? I do keep terminals
| open for days, but my most common usage case is mostly open
| window -> run a small session -> close and I got annoyed fast.
| pablo1 wrote:
| I agree with you, but stuck with wezterm for some time now for
| it's non-GPU related features. Specifically the font
| configuration with fallbacks and configurable font features
| such as ligatures and glyph variations is nice. I use a tiling
| window manager and a terminal multiplexer, so I have no use for
| terminal tabs/splits/panes. I wish there was something as
| "simple" as alacritty, but with nicer font rendering.
| supernikio2 wrote:
| I love wezterm due to its ligature and colourscheme support,
| and the fact it's very clean and simple compared to, say,
| Konsole (I also generally use i3 leading to KDE apps not being
| the prettiest).
| zadjii wrote:
| In my experience, there's two archetypes of terminal users: *
| Open one window and leave it open forever. Reuse that one for
| all commands. * Open a window, run a couple commands, and close
| it.
|
| For the second group, startup perf is everything, because users
| hit that multiple times a day. For the first group, not so
| much.
|
| Some of the other tiling functionality is also more helpful for
| folks that aren't on platforms with as powerful of window
| managers (macOS, Windows)
| minusf wrote:
| i think a very effective workflow is missing from this list:
| open a long running terminal window but have many tmux panes.
|
| many modern wm's and terminals have multitab and multiwindow
| features but i invested time only into learning tmux and i
| can use it anywhere. and of course nohup functionality is
| builtin by definition.
|
| i have said it before and i can say it again: terminals come
| and go, tmux stays.
| badsectoracula wrote:
| I am in the second group, kinda - i hit Win+Shift+X (my
| global key for opening a new terminal) pretty much all the
| time to enter a few commands. I basically open terminals in a
| "train of thought"-like fashion, when i think of something
| that isn't about what i do in one terminal i open another to
| run/check/etc out. Sometimes i even close those terminals too
| :-P (when i work on something there might be several terminal
| windows scattered all over the place in different virtual
| desktops).
|
| Also i'm using xterm and i always found it very fast, i never
| thought that i'd like a faster terminal.
| incrudible wrote:
| > I'm sure at full throughput the difference is there
|
| I am not. It makes next to no sense to me. Maybe if you have a
| highres screen and dedicated VRAM. Otherwise going through the
| GPU interfacing ceremony just adds overhead.
| killerstorm wrote:
| A GPU-accelerated terminal emulator sounds like a nuclear-
| powered kitchen mixer to me.
|
| Like, why? Over 20 years of using terminal emulators not even
| single time I was like "Man, I wish my terminal was faster".
|
| Is this just a fun project to do, like, "yay, I wrote a GPU-
| accelerated terminal emulator!"?
| imran-iq wrote:
| It depends on your workflow and on your resolution too. For
| example I do most things exclusively inside the terminal. If
| you are using vim, and are making use of splits, on a
| 4k60hz(or 1440p144hz) screen and want to scroll on one split
| and not the other, you will notice how slow and laggy redraws
| are. This was especially noticeable on macos (yay work
| computers) for me, which led me down the GPU accelerated
| terminal rabbit hole. iterm2 had its metal renderer, which
| (at the time) only worked with ligatures disabled, whereas
| kitty/wez/etc did not have that limitation.
|
| The litmus test I use is how smooth can the terminal emulator
| run `cmatrix` at fullscreen
| trey-jones wrote:
| cmatrix is the benchmark I didn't know I needed. Konsole
| seems to handle it fine, even in multiple tmux panes at
| once, or maybe I just can't see.
| imran-iq wrote:
| I've only had the issue on macos, konsole on my linux box
| works fine. I've stuck with kitty though cuz it works
| great on both linux and macos and I love the url opening
| feature as mentioned here:
| https://news.ycombinator.com/item?id=35140206
| naikrovek wrote:
| because rendering on the CPU is CPU-intensive when there's a
| lot of stuff scrolling by.
|
| even on an integrated GPU, text rendering is far faster when
| you use the GPU to render glyphs to a texture then display
| the texture instead of just displaying the glyphs
| individually with the CPU.
| chupasaurus wrote:
| Then what about the existence of Konsole?
| ofchnofc wrote:
| [dead]
| otabdeveloper4 wrote:
| A faster terminal is a great idea, but GPU acceleration is
| not the way to do this.
|
| GPUs aren't really meant for bit blitting sprite graphics.
| (Which is what a terminal really does.)
| incrudible wrote:
| Actually they were, before 3D acceleration became a thing,
| 2D acceleration was a thing.
| layer8 wrote:
| The 2D acceleration wasn't called GPU at the time though.
| That denomination only started with 3D acceleration.
| adastra22 wrote:
| Isn't that literally what GPUs were designed to do?
| layer8 wrote:
| The term GPU is primarily associated with 3D graphics,
| and most of what GPUs do is designed for that. Hardware
| acceleration of 2D graphics existed long before 3D
| hardware acceleration became common for PCs, but wasn't
| called GPU, instead it was simply referred to as a
| graphics card.
| rowanG077 wrote:
| If you can to the number crunching for 3D graphics, you
| see as hell can do it for 2D graphics.
| layer8 wrote:
| It's a different set of operations for the most part,
| when you look into it. Drawing a 2D line or blitting a 2D
| sprite is quite different from texture-shading a 3D
| polygon. It's not generic "number crunching".
| imtringued wrote:
| Ok but just because operations aren't perfectly identical
| doesn't mean you can't do it and it certainly doesn't
| mean it will be slow. I have had great success with
| SDL_gpu.
| rowanG077 wrote:
| It's tensor ops all the way down
| adastra22 wrote:
| Texture blitting is a very important part of 3D graphics,
| and is essentially what is required here.
| layer8 wrote:
| The difference is that applying textures to a 3D object
| is almost never a pixel-perfect operation, in the sense
| of texture pixels mapping 1:1 to final screen pixels,
| whereas for text rendering that's exactly what you want.
| Either those are different APIs, or you have to take
| extra care to ensure the 1:1 mapping is achieved.
| adastra22 wrote:
| There are ways to configure the texture blitter to be
| precisely 1:1. This is written into the GL/Vulkan
| standards for exactly this reason, and all hardware
| supports/special cases it. It is how pretty much every
| GUI subsystem out there handles windowing.
| jlokier wrote:
| The transforms are specified so you can position things
| perfectly these days, when aligned with screen pixels.
|
| Think of the compositing of layers of translucent windows
| used in modern 2d window managers, while dragging them
| around. Or even scrolling in a browser. Those rely on the
| GPU for fast compositing.
|
| Even for 3d, think of the screen-space techniques used in
| games, where it's necessary to draw a scene in layers
| combined with each other in various interesting logical
| ways (for shadows, lighting, surface texture, etc), with
| the pixels of each layer matching up in a reliable way.
| sllabres wrote:
| Probably inspired by the performance problems with the
| windows terminal [1] and the accelerated terminal [2]
| developed by Molly Rocket as 'answer'? A series of videos
| presenting the poc [3]
|
| [1] https://news.ycombinator.com/item?id=28743687 (It takes a
| PhD to develop that) [2] https://github.com/cmuratori/refterm
| [3] https://www.youtube.com/watch?v=hxM8QmyZXtg,
| https://www.youtube.com/watch?v=pgoetgxecw8
| buildartefact wrote:
| GPU-accelerated terminals have been a thing for a long
| time.
| an-unknown wrote:
| > xterm was still better than most lightweight libvt-based
| terminals
|
| Even worse: although many terminal emulators claim to emulate
| some "ANSI" terminal or be "VT100 compatible" and so on, most
| of them aren't at all. Simply run vttest in your terminal of
| choice and be surprised, especially by how many of them fail at
| very basic cursor movement tests. One of the few terminal
| emulators which gets most things right is xterm. It's also one
| of the very few terminal emulators which even supports exotic
| graphics capabilities like Sixel/ReGIS/Tek4014. Nobody should
| underestimate xterm ...
| rowanG077 wrote:
| Xterm is like that sleeper car. Looks basic but beats
| everyone if it comes down to it.
| tmtvl wrote:
| The author of Zutty has a pretty comprehensive writeup around
| that: https://tomscii.sig7.se/2020/12/A-totally-biased-
| comparison-...
| benfrain wrote:
| As a Neovim user I like that the config is in Lua. There are
| however odd things that it still doesn't have compared to Kitty,
| like the ability to have squared off corners in macOS
| imran-iq wrote:
| The killer feature of kitty for me is `crtl-shift-e`[0]. I
| really wish more emulators would copy it. Wezterm has explicit
| hyperlinks[1], but it requires you to click it with a mouse
| which is the last thing I want to do when inside a terminal.
|
| --
|
| 0: https://sw.kovidgoyal.net/kitty/conf/#shortcut-kitty.Open-
| UR...
|
| 1: https://wezfurlong.org/wezterm/hyperlinks.html#explicit-
| hype...
| ivolimmen wrote:
| For me the starting reason was the speed of the terminal but
| now its the open last command output in less[0], I know no
| other terminal that does this and it is a true life saver.
|
| 0: https://sw.kovidgoyal.net/kitty/conf/#shortcut-
| kitty.Browse-...
| mkhnews wrote:
| I used wezterm for a while and we added this key binding, I
| think it was from Wez himself ? - {
| key="e", mods="CTRL|ALT",
| action=wezterm.action{QuickSelectArgs={
| patterns={ "http?://\\S+",
| "https?://\\S+" }, action =
| wezterm.action_callback(function(window, pane)
| local url = window:get_selection_text_for_pane(pane)
| wezterm.open_with(url) end) } }
| },
| imran-iq wrote:
| Just the thing I was missing. Thank you
| eviks wrote:
| is there a way to make this work with Explicit Hyperlinks?
| tngranados wrote:
| I switched to WezTerm a few months ago after setting up a new
| computer and missing an easy way to share the iTerm2 config
| between my computers just like I do with most of my other tools
| that use dotfiles.
|
| It's a very nice application, easy to configure, very
| customisable, stable. I've only have experienced one bug with
| app, I opened an issue in GH and Wez had a nightly version with a
| fix in just a few hours.
|
| If you haven't check it out yet, I highly recommend it.
| [deleted]
| epage wrote:
| Been digging into escape sequences lately and gave WezTerm a spin
| to test some things out
|
| One thing that put a sour taste in my mouth for WezTerm is they
| document all escape sequences [0] using a deviation from standard
| syntax (sometimes using `:` over `;` like for RGB colors, at
| least I've not found any other documentation about this being
| commonly adopted). They do put a disclaimer at one point in the
| document but that only helps if you read it linearly and it feels
| weird to document your implementation of a standard to only work
| with your terminal, locking people's applications into it.
|
| As for rendering, I had problems with what look like correct
| escape sequences not rendering correctly (alternative underline
| styles, colored underlines). I still need to dig further into
| this where in the stack the problem is (my application or where
| in WezTerm)
|
| [0] https://wezfurlong.org/wezterm/escape-sequences.html
| drougge wrote:
| Colon is the correct separator there. Semicolon separates
| different instructions, a group of values that is a single
| instruction is colon separated. For example \e[38:5:196;1m
| specifies red and bold.
|
| Using ";" is popular, and some parsers even require it, but it
| makes little sense. A terminal that doesn't know about 38
| (anything old) will interpret that 5 as blink if you use ";",
| which is not what anyone wants.
| zadjii wrote:
| From my experience, the colon separator for 256/rgb
| attributes is a fairly recent clarification to the spec. I
| think that's the way it was always supposed to be. But when I
| was initially writing the 256 color support for the Windows
| Console about 6 years ago, `TERM=xterm-256color` still
| emitted colors with just the semicolons as a separator.
|
| The colons are more correct, but the semicolons are seemingly
| more broadly supported.
| drougge wrote:
| Part of the problem is probably that termcap uses : as a
| separator between capabilities. There is \C for colon, but
| there are implementations that don't support it. If nothing
| else I know the termcap[info] command in screen doesn't.
|
| That doesn't stop terminals from supporting it of course,
| just from saying they do.
| epage wrote:
| > Colon is the correct separator there
|
| Where would I find this documented and how broadly is it
| supported? So far, the most exhaustive documentation I've
| found is wikipedia [0], vt100 [2], and wezterm with only
| wezterm talking about this. I also have not seen `:` handled
| in the various parsers (e.g. `vte` for alacritty) or
| generators (e.g. `termcolor`) I've looked at.
|
| [0] https://en.wikipedia.org/wiki/ANSI_escape_code
|
| [1] https://vt100.net/emu/dec_ansi_parser
| rjzzleep wrote:
| Does anyone know the impact on battery compared to alacritty and
| kitty?
| halz wrote:
| Definitely lower battery consumption than Alacritty, at least
| while this is still an unresolved issue
| https://github.com/alacritty/alacritty/issues/3108
| betaby wrote:
| OSC52 support is a major plus for me, another one with OSC52
| support is alacritty
| yuryk wrote:
| Best terminal for MacOS.
| quag wrote:
| I really wanted WezTerm to be the best terminal on macOS.
| However, when I tried switching from Kitty to WezTerm a month
| or so ago I found WezTerm's latency was noticeably higher than
| Kitty and WezTerm often painted lines as blank in vim when they
| actually had content. So I was forced to go back to Kitty on
| macOS.
|
| On Linux, it's no contest, I love WezTerm over Kitty on Linux
| and didn't have any of these issues.
| konart wrote:
| Downloaded the latest stable for macOS and still has the same
| problem as before - if you have long list of items you want to
| scroll through or if you try ot simple move cursor with an
| arrow (hjkl) - you get some weird lags. Neither kitty nor
| Alacritty has this.
| mattrighetti wrote:
| What does this have to offer compared to Alacritty?
| halfdan wrote:
| Main thing was support for ligatures which Alacritty does not
| support: https://github.com/alacritty/alacritty/issues/50
| grozzle wrote:
| Lower OpenGL / GLES version number requirements, so wezterm
| can run on Arm64 hardware with no hassle.
| dmytrish wrote:
| Tabs, splits, programmability, best-in-class graphics
| support, an ssh multiplexor, session management, Lua
| scripting.
|
| Alacritty and Wezterm have very different--if not opposite--
| philosophies. Choose Alacritty if you want something simple,
| fast, focused, done right. Choose WezTerm for flexibility and
| being a cross-platform environment by itself.
| arusahni wrote:
| As someone who doesn't use tmux, two features pushed me to
| this over Alacritty: native scrollback with a scrollbar, and
| native tabs.
| lwhsiao wrote:
| Ligatures is one. I also find the copy mode and the
| hyperlinks feature [1] handy.
|
| [1]: https://wezfurlong.org/wezterm/hyperlinks.html
| realworldperson wrote:
| [dead]
| [deleted]
| kitsunesoba wrote:
| WezTerm seems nice in a lot of ways, but it's got some odd
| quirks, like how it lacks menus on macOS or how on Linux, it uses
| a hyperminimalist tiling-WM-style titlebar instead of whatever
| your WM furnishes.
|
| This makes it seem pretty squarely targeted at i3/Sway/vim sorts
| of users, which doesn't make it bad but an odd fit for more
| general users.
| pohl wrote:
| I installed the nightly version yesterday, and was pleased to
| see menus On macOS.
| anta40 wrote:
| I tried WezTerm for a few months on MacOS. No problem so far
| (my use case is pretty minimal, e.g tab 1 for compiling, tab 2
| for code editing, tab 3 for SSH, etc), except lacking of GUI
| for user configuration. You need to understand Lua for that:
| https://wezfurlong.org/wezterm/config/files.html
|
| Eventually I uninstalled it and back to iTerm2. Maybe one day
| I'll learn Lua and use it again.
| dmytrish wrote:
| I feel like WezTerm has a vision of being something bigger than
| a traditional VT emulator. It feels more like an environment to
| live in, an Emacs of terminal emulators, with its own tiling,
| status bar, dynamic scripting, builin Lua console, programmable
| events, very rich graphics. It's not a faithful old-school TTY
| emulator like xterm, it's not featureful, but boring Konsole,
| it's not ascetic but fast Alacritty. It's an experiment.
|
| I don't personally like all of its design decisions, but an
| Emacs-like vibe really intrigues and attracts me.
| volkadav wrote:
| Wez is a really nice guy to work with too; had the pleasure of
| working with him briefly a bit over a decade ago (we were at sort
| of sister companies on a project that involved both). Sadly he
| was impacted by the layoffs at Meta recently, so if you're
| looking for an incredibly productive and sharp as hell engineer,
| it might be worth looking him up.
| Kukumber wrote:
| 145mb-226mb for a terminal
|
| that's worse than an electron terminal
|
| something is wrong
| dralley wrote:
| Keep in mind, wezterm is a statically linked binary, while
| builtin and distro-provided packages will use dynamic linking.
| Depending on how it's built, it may also have embedded
| debuginfo and lack LTO.
| rektide wrote:
| It is a bit frustrating how much hate Electron gets but
| statically compiled languages are all the rage & general
| concensus is it's totally sweet.
| timeon wrote:
| It is not just about size of the app but also RAM
| footprint.
| _gabe_ wrote:
| This does seem crazy. I have a hobby project that's a
| statically linked animation editor (so it does a lot of stuff
| including exporting/encoding GPU streams into a video). It has
| AV1, Freetype, and a few other large deps included and it only
| clocks in at 16.7mb
| i_love_cookies wrote:
| [dead]
| kristjansson wrote:
| Looks like the macOS binary size is a combination of shipping 3
| binaries, each with most of the application compiled in (and
| statically linked), and containing builds for both Apple
| Silicon and x86 in each. 2 % tree . .
| +-- Contents +-- Info.plist +-- MacOS |
| +-- strip-ansi-escapes | +-- wezterm | +--
| wezterm-gui | +-- wezterm-mux-server +--
| Resources | +-- terminal.icns | +--
| wezterm.sh +-- _CodeSignature +-- CodeResources
| 2 % du -hs Contents/MacOS/* 2.8M Contents/MacOS/strip-
| ansi-escapes 48M Contents/MacOS/wezterm 119M
| Contents/MacOS/wezterm-gui 44M
| Contents/MacOS/wezterm-mux-server
|
| A bit of duplicative bloat, but there's nothing wrong with that
| for an young project trading a bit of space for an easier
| build/release process.
| nu11ptr wrote:
| This is the size of the binary or RAM usage? If the size the
| binary, does it matter in most cases? If the size of RAM, yeah,
| I can see how that seems a lot for a terminal.
| selectnull wrote:
| It's easy to downvote, but the question is not totally out of
| place.
|
| On my machine:
|
| * WezTerm 224 MB
|
| * iTerm2 74 MB
|
| * Terminal (default MacOS) 10 MB
|
| And yet, I have read comments proclaiming that iTerm is
| bloatware.
|
| p.s. I've been using Wezterm for more than a year, and I love
| it.
| deagle50 wrote:
| terminal.app doesn't even support true color (for
| starters)... apples and oranges.
| [deleted]
| naikrovek wrote:
| well if you're so sure, look at the code and the feature
| list[0] (to see what it actually does) then tell us what it is
| doing wrong.
|
| [0]: https://wezfurlong.org/wezterm/features.html
| an-unknown wrote:
| If I compare this feature list to e.g. features of xterm
| (VT52/VT100/VT220/VT320/VT420/partial VT520 support, graphics
| via Sixel/ReGIS/Tek4014, ...), I don't see a single reason
| why wezterm should be roughly 100MB large (according to
| pacman on Archlinux) vs roughly 1MB for xterm.
|
| If you think "but terminal multiplexing and SSH!", then feel
| free to add 0.9MB for screen (or 1MB for tmux) and 4.8MB for
| openssh, and you're still way below the size of wezterm.
| beepbooptheory wrote:
| idk, I am with you and I don't typically care about sizes
| like this, but this does feel like quite a lot, although not
| as much as reported above. The split between the two rust
| programs here is pretty interesting.
|
| [nix-shell:~]$ du -hs $(nix-build '<nixpkgs>' -A wezterm)
|
| _94M_ /nix/store/w7hpqwqqp7xq70wjsm8bd1yara0rhk9v-wezterm-20
| 220408-101518-b908e2dd
|
| [nix-shell:~]$ du -hs $(nix-build '<nixpkgs>' -A kitty)
|
| _25M_
| /nix/store/9k0jn3219l6l7ywcqyvbifhd38cagfd9-kitty-0.25.2
|
| [nix-shell:~]$ du -hs $(nix-build '<nixpkgs>' -A alacritty)
|
| _6.2M_
| /nix/store/cq7zaagwcwn9blynw027bqszhnld2sk2-alacritty-0.10.1
|
| Is the feature set difference between these really that much?
| At least, between kitty and wezterm?
| eredengrin wrote:
| Alacritty is basically as minimal a terminal emulator as
| you're going to get, wezterm is the polar opposite end of
| the spectrum. Kitty is in the middle, the main thing that
| wezterm has that kitty doesn't that I'm aware of is the
| daemon process that allows you to disconnect/reconnect to
| sessions which is what allows wezterm to function as a tmux
| replacement (vs kitty can't replace that aspect of tmux).
| Compared to alacritty, it has multiplexing, ssh sessions
| (new tabs/panes opened in that session are opened in the
| context of the remote host without requiring additional
| authentication), incredibly flexible configuration via lua,
| etc. And as far as size goes, kitty and wezterm are written
| in different languages so comparing them directly is not so
| simple.
| [deleted]
| [deleted]
| baggiponte wrote:
| what's the difference with alacritty?
| eviks wrote:
| tabs, ligatures and much more flexible configuration with its
| lua configs
| yohannesk wrote:
| I am guessing multiplexer. I really miss tmux on windows,
| hopefully this could be a replacement. But I don't know about
| the project
| zadjii wrote:
| FWIW the Windows Terminal also natively supports panes & tabs
| for multiplexing: https://learn.microsoft.com/en-
| us/windows/terminal/panes which were highly inspired by tmux.
| [deleted]
| linsomniac wrote:
| Been using WezTerm as my primary term for ~6 months and been
| loving it. In particular: - Keyboard cut-and-
| paste. CtlShiftSpace to highlight likely selections, matching
| letter to cut, shift letter to cut AND paste. - Built in
| mosh+tmux-like functionality, but at the GUI level. I do a lot
| of terminal work at home from my Mac connected to my Linux laptop
| WezTerm instance, with multiple panes/tabs.
| metal_am wrote:
| Honest question: for someone who doesn't live in a terminal, what
| does something like this do that a default terminal with OhMyZsh
| doesn't do?
| gleenn wrote:
| Zsh is the shell which is a mini language and environment, so
| you can run that in many different terminals. OhMyZsh is a set
| of configuration scripts and plugins to configure Zsh. A
| terminal is the thing that renders text, handles input and all
| the escaping complexities. So it's usually the UI/colors around
| the text that the shell provides. Old terminals were even
| physical devices with ports that allowed connecting to headless
| computers.
| kzrdude wrote:
| Wezterm for example supports various protocols for images in a
| terminal. Many do, but some standard terminals don't. Gnome-
| terminal still doesn't. Terminal.app in MacOs doesn't.
| michaelsbradley wrote:
| kitty is also worth a look, though it doesn't run on Windows:
|
| https://sw.kovidgoyal.net/kitty/
|
| https://github.com/kovidgoyal/kitty/releases
|
| I used iTerm2 on macOS for many years and still keep it around,
| but switched to kitty as my daily driver in late 2021 and have
| been very happy with it.
| malkosta wrote:
| me too...kitty got me out of iterm2, it feels more responsive,
| faster to close and open new windows/tags
| codetrotter wrote:
| Not to be confused with KiTTY
|
| http://www.9bis.net/kitty/index.html#!index.md
|
| > KiTTY is a fork from version 0.76 of PuTTY
|
| > KiTTY is only designed for the Microsoft(r) Windows(r)
| platform.
| einpoklum wrote:
| Not a criticism of this app itself, but - I could not find an
| explanation on the website why I would prefer this terminal
| emulator & multiplexer to those available with every desktop
| environment, such as gnome-terminal, lxterminal, qterminal,
| xfce4-terminal etc.
| MuffinFlavored wrote:
| Serious question: why does a terminal editor need GPU
| acceleration? It's usually showing 80x25 of text, yeah? I guess
| text can get scrolling quickly sometimes or it needs maybe...
| 1,000,000 lines of lookback
| NikkiA wrote:
| Why do you think pixels constituting text are any different to
| pixels constituting images?
|
| A terminal editor needs GPU acceleration for the same reasons
| any other displayed item needs GPU acceleration.
| dmytrish wrote:
| Text rendering is a quite CPU-intensive thing to do nowadays.
| It can burn your CPU with unnecessary work to move bitmaps
| around, while the GPU, which is specifically created and tuned
| for this kind of tasks, stays idle.
|
| This is basic mechanical sympathy.
| s9w wrote:
| [dead]
| linsomniac wrote:
| A couple of points: - WezTerm has
| windows/tabs/panes in it, and one use case would be ~10 panes
| on a 4K display in various columns/rows. - Within those
| you might have applications that themselves have columns/rows
| of panes, like vim. - Why not use the GPU to draw the
| graphics so you can offload the CPU? When there's a lot of
| text to go through (something scrolling stdout hard, jumping
| through a big file), the extra performance can be nice.
| yjftsjthsd-h wrote:
| > It's usually showing 80x25 of text, yeah?
|
| That would be pretty small in modern times. Certainly some
| people are working with terminals that size, often then
| spilling out into multiple terminals side by side on the
| screen, but modern resolutions are good enough to support a lot
| more text per terminal than that. As a single data point, my
| half-screen terminal right now is 140x75.
___________________________________________________________________
(page generated 2023-03-13 23:02 UTC)