I wonder if the author might be willing to reconsider. He should have newfound appreciation for how annoying name collisions can be.
Good to know. I'll keep avoiding his software.
People talk about entitlement in games but here you are not even paying or even having a pretense of sponsoring.
(“Criticising me for punching your face really shows your entitlement. You don't pay me to choose whom I punch in the face. You have no right to tell me how I spend my free time!”)
Also, mobs occasionally have a point. The opposite of the ‘five billion flies’ fallacy is still a fallacy.
> W A R N I N G! Your browser is not supported by this site.I cannot guarantee that things will work as they should. Consider downloading either Mozilla >=1.4 or Internet Explorer >= 6
And it states:
> It has been tested on Internet Explorer 6 and Mozilla 1.4.
I was not quite sure if this was a joke, or if the homepage was really not updated for such a long time (it says "Created by Kovid Goyal © 2003").
Anyway, for minimal work, I think you can simply remove the warning, and this statement about IE6/Mozilla 1.4, because as far as I can see, everything works fine.
Edit: Ah, in the 2018 thread, someone noticed the same thing: https://news.ycombinator.com/item?id=17924093
The correct terminal type, per Dickey terminfo, is "kitty". (The PuTTY variant KiTTY is apparently also "putty".) And the terminfo database lends itself both to copying individual records and to having extra records in one's home directory.
ncurses from FreeBSD Ports is built with terminfo, but the ncurses from base uses termcap. Kind of a mess :)
Most application ports have USES=ncurses without arguments, which means they will prefer the ports ncurses — if it's installed at build time. Official binary packages are built without it installed of course. So rebuilding the ncurses apps you care about would make them use terminfo.
Also you can convert terminfo to termcap: https://invisible-island.net/ncurses/man/infotocap.1m.html
I was a heavy terminal user already but running macOS at work and linux at home, I got really annoyed by having to memorize different shortcuts. So I just gave up and started using tmux. Now, no matter what platform I am on, the behaviour is pretty much the same. I just use Kitty because it performs really well.
Maybe I should try re-enabling it again. It's been a while. Maybe tmux or VIM fixed this.
Scrolling itself seems smooth for me in general.
The major difference between them is that alacritty is written in rust (and has a really nice config that auto-reloads) and kitty is written in C with a smattering of python.
first commit in alacritty: Sun Feb 21 08:15:41 2016 -0800
first commit in kitty: Fri Oct 14 12:33:27 2016 +0530
I think it lacks features compared to Kitty. At the very least tabs for multiple sessions and support for a transparent background made it not an option for me.
Kitty has replaced the standard terminal in Ubuntu for me, and I am quite happy with its performance and Unicode support.
Good to know though, so thanks for the reply.
Line up a row of real terminals, and of course they do not constrain one another, size-wise. Indeed, back in the 1990s the DTTerm terminal emulator pioneered the terminal emulators' abilities for applications to set any arbitrary size (within reason) for a terminal emulator.
I did a quick review of terminal emulators in light of this, and varyingly tabbed terminal emulators do not support application resizing (DECSLPP/DECSNLS/DECSCPP) at all or support it in limited, or at least odd (compared to real terminals), ways. Konsole, possibly the best of the bunch, implements resizing properly, leaving large margins when the requested terminal screen size does not match the GUI window size, but triggers a GUI resize whenever a tab receives the input focus back, so application-requested size changes do not last if one switches amongst tabs. One tabbed terminal emulator author is actively opposing the idea that terminals should be resizable by applications emitting these control sequences, completely reversing course from DTTerm's innovation.
The problem for Windows Terminal is compounded by the fact that it isn't just supporting terminal I/O applications, it is supporting console I/O applications. In console I/O not only can applications set the screen buffer size at whim, they can also set the window rectangle. Not supporting either is a huge and very noticable step backwards, by over three decades, for Windows TUI applications that Windows Terminal is aimed to be compatible with.
A tabbed UI is not a universally unproblematic thing when it comes to terminal emulators. (-:
Also, a whole lot of it is written in Python and I actually contributed smaller changes in pull requests. It feels good to be able to just change things.
P.S. weirdly on Linux it's entirely opposite; vim in an xterm is much faster than gvim.
I wish ncurses were more eager to adopt descriptions of innovations in terminal emulator design.
On both real (DEC) terminals and terminal emulators, background colour erase is settable off and on, with DECECM; so a full-screen application can set the behaviour and know what the colour is going to be, leading to more efficient screen redraws. The ncurses/terminfo model, in contrast, is that the behaviour is fixed on or off, and a boolean (named bce) in the database tells softwares which it is for any given terminal type.
In reality, it is the paradigms of ncurses and terminfo that are the problems here.
It's obviously better than iterm2, but Apple's built-in terminal is actually rather fast.
Please stop spreading cargo cult information dating from 10.4 days. Terminal.app has been great ever since 10.6.
I have to learn a few new shortcuts, but I am quite satisfied so far, it does all things I want in a terminal that Alacritty did not, like tabs and transparency.
"fast"? What, terminal emulation is slow now? Needs hardware acceleration? Be serious.
A graphical terminal emulator should use underlying graphical environment features/libraries for things like hardware-assisted rendering.
> A graphical terminal emulator should use underlying graphical environment features/libraries for things like hardware-assisted rendering.
I've mostly done OpenGL recently, and I think xterm (which is fast) is an exception in that it uses just X11 primitives, but I also know that some font frawing APIs are very slow. GDI is what I have in mind mostly. So using Hardware more directly (i.e. OpenGL) might be not the worst idea.
But it sounds like what should really be written is a fast, hardware-backed, low-latency but limited-feature graphics library.
Then have your terminal use that. I still say that direct awareness of the hardware is _way_ too much coupling.
I've also heard about performance issues with high res, large terminals. It's a lot of pixels to throw at the screen and I'm sure most terminal emulators were written with much smaller screens in mind.