Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Use Alacritty instead of Termite

github.com

Post reply on HN
Print view View original

241–250 of 331 posts

Re: Use Alacritty instead of Termite

#241

Post by dleslie »

Cloudef wrote: post #40
dleslie wrote: post #27

Earlier quoted context omitted.

Gnome has a fairly negative rep now, thanks in part to its repeated spurning of feature requests from developers and users. I remember when the Gnome desktop was exciting; there were frequently new apps to try, things pushing niche workflows that the Gnome team didn't consider. That all stopped with Gnome3.

Gnome developers actively hate their users and non-gnome developers. This issue takes the cake: https://gitlab.gnome.org/GNOME/mutter/-/issues/217

I love how that thread is full of well-intentioned, respectful responses with deep technical knowledge and details; and the Gnome developers just won't budge.

When, finally, it becomes clear that the user demands cannot be met and Gnome is woefully inadequate as a modern desktop due to their design decisions, the final post is:

> Enough spam for today. Locking the issue.

Gnome is dead. It has been taken over by toxic developers.

Re: Use Alacritty instead of Termite

#242

Post by commoner »

noisy_boy wrote: post #167

I have been using Tilix[0] - pretty happy with it. Nice tab features, profiles/theming, quick startup, excellent rendering. Nothing to complain so far. [0]: https://gnunn1.github.io/tilix-web/

Tilix is an excellent terminal emulator, but it's not adding any new features until it gets a new maintainer. Anyone familiar with the D programming language (similar to C/C++) is welcome to apply.

https://github.com/gnunn1/tilix/issues/1700

Re: Use Alacritty instead of Termite

#244

Post by AceJohnny2 »

AceJohnny2 wrote: post #196
aDfbrtVt wrote: post #5

Does Alacritty still require you to copy terminfo to remote servers in order for backspace to work? I loved Alacritty, but copying terminfo every time gets old pretty quickly.

ncurses/terminfo is pretty fundamentally broken for the modern SSH/Tmux use-case. For example a few years ago I tried to enable 24-bit ("truecolor") support... For one thing, the terminfo reporting for 24-bit color support wasn't universally recognized: terminfo added an 'RGB' capability to report this, but because this was added only "recently" (as far as terminals are concerned), not all programs relied on it. For…

I should add that TermInfo databases, still present in Linux & macOS system today, are really interesting to compare with modern configuration systems. Nowadays we have no problem using verbose formats like TOML, JSON, YAML, or XML (plists!), because our computers are fast, have lots of storage and memory! We've traded efficiency for convenience.

Terminfo is a remnant from when computers were slow and disk/memory constrained, and it made every byte count. It was hard to efficiently encode a database of all the capabilities of the terminals at the time! The trade was in favor of efficiency at the expense of convenience.

Look up the manpage for tic, toe, infocmp & family.

Re: Use Alacritty instead of Termite

#245

Post by fuzxi »

shi_tty wrote: post #20
bennyp101 wrote: post #19

I used to use termite, but switched to kitty for ... reasons I can't remember now. Does alacritty support ligatures yet? I've been using kitty because it does, but then I have issues with tmux in kitty ... I know, I want my cake and eat it

Lots of things alacritty cannot do- 1) If you scale certain fonts using fontconfig, alacritty would ignore that. 2) No emoji colors, no ligatures (and thus no flags), also emoji size has problems ... and not to mention it's one of the slowest (yes! contrary to what they blowhard they response time to keys is very large) terminals out there. List is endless, termite had its place, but there is no doubt that there is s…

What's the appeal of emoji in the terminal?

Re: Use Alacritty instead of Termite

#246

Post by zxzax »

jstimpfle wrote: post #237
zxzax wrote: post #232

Earlier quoted context omitted.

I'd love to see the source code to the Win95 and Win98 file managers, maybe we can copy some of the performance tricks.

The "trick" is to just run a loop over a list stored in RAM.

That seems to be over simplifying, every database is "just running a loop over a list stored in RAM." The challenge is in how you build that list, and then with a GUI the challenge becomes how to display it. Win95 had to run in very memory constrained environments compared to today so I'd imagine there is some special considerations there.

Re: Use Alacritty instead of Termite

#247

Post by infogulch »

bhaak wrote: post #3

> GTK and most of the GNOME project are much of the same. Avoid them and don't make the mistake of thinking their libraries are meant for others to use. Choose your dependencies wisely. Sometimes only a crystal ball would have helped but often, a little bit of due dilligence would have prevented lots of upgrade pain down the line.

I dug in and read the linked thread and patch, and this may be a bit in the weeds, but nobody on the linked thread called out Christian Persch's comment [1] which doesn't make much sense to me. To be completely fair, this is a comment from 2015, 12 comments deep in an otherwise relatively isolated bugzilla forum, so maybe we shouldn't judge too harshly. Anyways, have a look:

    > In reply to Daniel Micay from comment #10:
    > > Implementing this in VTE would mean ruling out having any flexibility in the
    > > terminal using the library. I haven't responded any more here because an
    > > implementation inside VTE won't satisfy the use case.
    >
    > Implementing keyboard selection inside vte means that *every* terminal based
    > on vte benefits; adding only hooks for you means that all the other terminals
    > get *no* benefit.
This seems like a pretty shallow argument. What exactly stops gnome terminal (the obvious referent of "all the other terminals") from implementing this itself once the apis are available? Or, stated another way, why is gnome terminal entitled to receive all the features built on top of GTK component apis used by other projects? He's stating the conclusion that VTE is the correct layer to implement the end-user highlight/selection feature without actually making an explicit case for it, and without acknowledging that there's an argument that the layer above could actually be a better location to implement the feature.

Thoughts?

[1]: https://bugzilla.gnome.org/show_bug.cgi?id=679658#c12

Re: Use Alacritty instead of Termite

#248

Post by kzrdude »

accelbred wrote: post #171
enriquto wrote: post #81

I have no beef with gtk/gnome and the like, but I find it really funny when developers use such colorful language. Still, as a heavy terminal user, I fail to understand what's the big deal with the choice of terminal. I have used only xterm for more than 20 years (with a short stint with gnome-terminal, and I didn't find any relevant difference). It starts instantaneously and doesn't make any fuss while it's running.…

For me the killer feature is truecolor support. 256 color is rather limiting, and with truecolor you can also use gui syntax highlighting color schemes. My actual shell runs in a neovim :term, with neovim running in alacritty, so I dont care about fancy terminal features other than rendering and colors.

Why inside neovim? What's the benefit?

Re: Use Alacritty instead of Termite

#249

Post by kzrdude »

jah wrote: post #153

I've been running urxvt with tmux in a tiling window manager for the last decade. What features from these new terminal emulators am I missing out on?

kitty has ligatures and inline images support. Inline images go right out the window if using a terminal multiplexer though, unfortunately.

Re: Use Alacritty instead of Termite

#250

Post by jstimpfle »

zxzax wrote: post #246
jstimpfle wrote: post #237

Earlier quoted context omitted.

The "trick" is to just run a loop over a list stored in RAM.

That seems to be over simplifying, every database is "just running a loop over a list stored in RAM." The challenge is in how you build that list, and then with a GUI the challenge becomes how to display it. Win95 had to run in very memory constrained environments compared to today so I'd imagine there is some special considerations there.

I don't find there is a lot that could make sense to do. I believe computers running Win95 had like 16-128MB of RAM, it wouldn't be too wasteful for a file manager to store, say, 32-64K worth of cached file entries uncompressed in RAM. That could allow for maybe 1024 file entries (depending on the attributes that should be cached for each entry - more if we're really just storing a list of zero-terminated strings and maybe directory bits), which would already cover almost all realistic use cases at the time.

So it's literally a loop over that in-RAM cache in most cases.

It seems like e.g. FAT32 allowed for theoretically 64K entries per directory, but I find it unlikely that most programs would bother to optimize for that. One could just punt and allocate more memory dynamically in those cases until there is a Out-of-memory situation.

Or one could page in the directory entries chunk by chunk (so, maybe 64 chunks max) on each update which would considerably slow down some operations of the program (such as scrolling, sorting, type-ahead, when any of those cross a chunk boundary), but still be acceptable as a rare occurrence.

Or, if one specifically wanted to optimize for something like scrolling or type ahead, which are simple "linear movements", one could just keep this linear list (sorted according to user preferences / filters) in a cache file on disk. Streaming that in chunk-by-chunk is very fast as well, since you only need one disk access to get at the next chunk.

I figure that would be way overkill for most practical requirements, but it still wouldn't be a lot of work to implement.

Post reply on HN