All in one, that's why developers like it so much. The obsession with AI makes me nervous, but the advantages still outweigh, as for me, the average developer. For now.
How do you define "code navigation"? It might've got a bit easier with automatic highlighting of selected symbols, but in return source code viewer got way too laggy and, for a couple of years now, it has this weird bug with misplaced cursors if code is scrolled horizontally. I actually find myself using the "raw" button more and more often, or cloning repo even for some quick ad-hoc lookups.
Edit: not to mention the blame view that actively fights with browser's built in search functionality.
They of course don't have to, but having something like Anna's Archive but for website history would be great.
- even higher costs associated with seeding archives (egress traffic, storage iops capacity required etc)
- chances of finding a 3rd-party seed for arbitrary file would be pretty slim, which means seeding on your own most of the time, which would make this hardly any better than offering files over HTTP only.
Anna's Archive, after all, is only an index.
Reasons that no longer exist. Storage is cheap, update distribution is free, time spent debugging various shared lib versions across OSes is expensive.
My /usr is 15G already, and /var/lib/docker isn't that far off despite people's obsession with alpine images. If more people would dismiss storage as cheap it'll quickly become expensive, just not per GiB.
> update distribution is free
I wouldn't be surprised if at one point Github would start restricting asset downloads for very popular projects simply because of how much traffic they'd generate.
Also, there's still plenty of places on the planet with relatively slow internet connectivity.
People who don't really care would, in my experience, use sarcastic tone more often.
cat's behaviour and bat's behaviour is different, though.
>cat a.txt b.txt
It was a dark and stormy night.
Once upon a time.
>bat a.txt b.txt
───────┬──────────────────────────────────────────────────────
│ File: a.txt
───────┼──────────────────────────────────────────────────────
1 │ It was a dark and stormy night.
───────┴──────────────────────────────────────────────────────
───────┬──────────────────────────────────────────────────────
│ File: b.txt
───────┼──────────────────────────────────────────────────────
1 │ Once upon a time.
───────┴──────────────────────────────────────────────────────
This difference becomes more useful once we have a more meaningful example: >cat *.py
(thousands of lines of output)
>bat -r :5 -H 2 --style full *.py
───────┬──────────────────────────────────────────────────────
│ File: __init__.py <EMPTY>
│ Size: 0 B
───────┴──────────────────────────────────────────────────────
───────┬──────────────────────────────────────────────────────
│ File: editor.py
│ Size: 2.4 KB
───────┼──────────────────────────────────────────────────────
1 │ import collections
2 │ import contextlib
3 │ import glob
4 │ import io
5 │ import os.path
───────┴──────────────────────────────────────────────────────
It's hard to imagine many people have the muscle memory for the combination of cat, head, and whatever else you need to add headers with the filename and file size, call out empty files, highlight the second line, show line numbers, do syntax formatting, and wrap to the terminal width (head doesn't do this).In fact, you're at odds with bat's README:
> you can still use bat to concatenate files. Whenever bat detects a non-interactive terminal (i.e. when you pipe into another process or into a file), bat will act as a drop-in replacement for cat
> It's hard to imagine many people have the muscle memory for the combination of cat, head, and whatever else you need to add headers with the filename and file size, call out empty files, highlight the second line, show line numbers, do syntax formatting
Honestly, it's harder to imagine many people with need for most combinations of these features. I can see general audience who would happily use one feature at a time, and if someone is constantly doing obscure one-off file analysis, chances are bat is just never enough, they're going to write long pipelines with awk/perl or use vim macros anyway, so there are no time savings nor convenience from using bat. (Is it really that much more convenient to read syntax-highlighted heads with line numbers? And I can barely remember the last time when `head` that also shows file sizes could've been much more handy than `du * ; head *`.)
Also, good luck using all that bat muscle memory in docker containers or old-school fleet of remote servers.
> and wrap to the terminal width (head doesn't do this)
Terminals already wrap long lines just fine, they don't need help from anything. They can also re-wrap lines when window gets resized.
(edit: expanded quote, markup fix)
That reminds me of one idea I had back in the day. You see, not everyone has the skill nor time to set up their own server, so clients rely on 3rd party servers. But sometimes these servers either experience intermittent connectivity issues or just die out altogether, which means users now have to set up second account and re-add everyone, while also scattering chat history across multiple accounts. What I'd like to see is some way of linking accounts across multiple servers, so that:
- message delivery could have transparent fallback (it gets delivered to me@bar.com if me@foo.com is unavailable)
- you don't have to add and authorize multiple accounts
- rosters and chat histories also get synchronizes between the two
A lot of that could probably be hacked around just on the client side, and I don't have good answers to questions like "what happens if I want to unlink two accounts for some reason".
(And going a bit off-topic: I also wish I could use multiple email addresses while registering in other places, because email provides too can fail, close altogether, or even just ban you for no good reason while also having crappy bot-driven support@.)
But the clients are lacking. On linux there is gajim that is "okish" but it lacks calling capacity with mobile clients. On mobile there is conversation and derivatives on android which are "nearly there" and monad on iOS.
Globally, the main lacking features are:
- voice and video calls cross platform
- gif integration, tenor/giphy/imgur...
- fast sync (if you open gajim after being offline for a week, it takes ages to catch up)
In my book it only got worse. Way worse. Sure, it looks more familiar to those who is used to iMessage/Whatsapp/Telegram, but I bet it would still look quite alienating for that audience. And for those who remember Gajim 1.x, disastrous UX doesn't outweigh introduction of reactions, history syncing and whatnot. Last time I checked it a couple of months ago:
- It was not possible to close group chat without leaving MUC.
- I had to constantly open separate search dialog to write to someone who's already in my roster but is not in the list of active chats.
- Speaking of active chats: what annoys me the most about modern IM clients (and that includes Gajim 2.x) is that list of chats is sorted by the last activity date. I don't even know how Whatsapp/Telegram users live with this, I got so fed up with hovering my mouse/finger over one chat and tapping it only for the whole thing to reorder in the last jiffy and opening something completely different, I just dropped my account from one of those centralized mass-market services altogether. It is that annoying.
- It had lots of smaller warts like nickname autocompletion requiring way more key presses (especially after someone mentions you).