91–100 of 140 posts
Earlier quoted context omitted.
In the age of Vim being a full IDE, these kinds of things only become more important.
Vim is a not an ide. Intellij with java is worlds apart from any vim setup I've ever seen in the wild.
Earlier quoted context omitted.
Does anyone have a handy guide for getting rolling with (neo)vim as IDE? I’ve been using LunarVim which mostly works but has enough annoying edges that I want to roll my own config; but there is a lot of ground to cover and I’m not sure where to start.
Kickstart.nvim [1] is a good starting point. One big Lua file which gets you 90% there and shows what’s possible while making it easy to change/add stuff and getting started doing your own config. [1]: https://github.com/nvim-lua/kickstart.nvim
As someone who has dabbled in terminal emulation (I was the maintainer of Console Telnet for Win32 twenty years ago), I have respect for someone who takes the time to optimize a terminal emulator by building a fast parser and being careful with screen updates. That used to be the only way to make a graphical program fast, but these days hardware is so fast you can render an entire scene before the next screen refresh…
As someone who has dabbled in terminal emulation (I was the maintainer of Console Telnet for Win32 twenty years ago), I have respect for someone who takes the time to optimize a terminal emulator by building a fast parser and being careful with screen updates. That used to be the only way to make a graphical program fast, but these days hardware is so fast you can render an entire scene before the next screen refresh…
libvte is a big reason that GNOME Terminal tends to be faster than competing terminal emulators, including xterm and rxvt. One of VTE's tricks is that it doesn't bother painting the screen if the contents are going to be overwritten in the next frame anyway; you can scroll through megabytes of data in fractions of a second this way. The idea that it's slow, that's new to me.
Long dumps of output with VTE seems to be fast enough, at least with a barebones program that creates a VTE widget and doesn't do much else. But Gnome Terminal was noticeably slower than my naive program, last time I tried it. I don't know why.
Earlier quoted context omitted.
libvte is a big reason that GNOME Terminal tends to be faster than competing terminal emulators, including xterm and rxvt. One of VTE's tricks is that it doesn't bother painting the screen if the contents are going to be overwritten in the next frame anyway; you can scroll through megabytes of data in fractions of a second this way. The idea that it's slow, that's new to me.
I have a 655MB file with 1.5 million lines of lorem ipsum. I timed a cat in several terminal emulators. For this simple test, gnome-terminal beat xterm a little bit but wasn't anywhere close to the rest: foot 0m9.410s alacritty 0m16.881s konsole 0m36.737s gnome-terminal 1m1.096s xterm 1m16.919s Foot has an page that explains when and why it's fast, and also when it's not, compared to alacritty. https://codeberg.org/d…
https://tomscii.sig7.se/2020/12/A-totally-biased-comparison-...
And I don't really care that much but I will say that while it is a bit of a dog in the bulk display race, no one beats xterm in the keyboard latency contest.
Tbh, I never ventured outside of Konsole. Never felt I was missing something or was limited by performance or anything beyond what the stock Konsole offered.
Konsole is decent if you are running kde, but I'd guess majority of people don't
https://www.gamingonlinux.com/index.php?module=statistics&vi...
KDE is just the best overall DE today.
As someone who has dabbled in terminal emulation (I was the maintainer of Console Telnet for Win32 twenty years ago), I have respect for someone who takes the time to optimize a terminal emulator by building a fast parser and being careful with screen updates. That used to be the only way to make a graphical program fast, but these days hardware is so fast you can render an entire scene before the next screen refresh…
libvte is a big reason that GNOME Terminal tends to be faster than competing terminal emulators, including xterm and rxvt. One of VTE's tricks is that it doesn't bother painting the screen if the contents are going to be overwritten in the next frame anyway; you can scroll through megabytes of data in fractions of a second this way. The idea that it's slow, that's new to me.
Earlier quoted context omitted.
I have a 655MB file with 1.5 million lines of lorem ipsum. I timed a cat in several terminal emulators. For this simple test, gnome-terminal beat xterm a little bit but wasn't anywhere close to the rest: foot 0m9.410s alacritty 0m16.881s konsole 0m36.737s gnome-terminal 1m1.096s xterm 1m16.919s Foot has an page that explains when and why it's fast, and also when it's not, compared to alacritty. https://codeberg.org/d…
There can be distinctly different run speeds between bulk entry dumb terminal and opcode heavy tui behavior. https://tomscii.sig7.se/2020/12/A-totally-biased-comparison-... And I don't really care that much but I will say that while it is a bit of a dog in the bulk display race, no one beats xterm in the keyboard latency contest.
Unfortunately there is no support for ligatures. A good programming font like fira or source code pro makes for such a quality of life improvement. At least easier on the eyes. It seems that many terminal emulators can’t or won’t support them, because they are hard to render properly. Sticking to wezterm for now.