vthriller

And now it opens... some VSCode-esque editor in the browser that asks me to sign-in? Why would I want something even more resource-hungry and convoluted just to look up a random thing once in a while?

> In addition, it is best to use code navigation simply in a web browser

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.

Not sure about normalizing recipients' emails but some are definitely aware of it because I've seen spam that asked to "reply back to [email protected]" or something.

My guess is the sheer amount of data that archive.org has, which means:

- 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.

> Storage is cheap

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.

...which could also be a PTSD-esque reaction and not a sign of ignorance. As in "I'm so tired of being affected by this nonsense, when this would even stop".

People who don't really care would, in my experience, use sarcastic tone more often.

What you're showing here is not concatenation, there are fancy borders between file chunks and whatnot. Unless you have very different, unconventional definition of concatenation.

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)

> support clustering (for high-availabilty purposes)

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 [email protected] if [email protected] 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@.)

> On linux there is gajim that is "okish"

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).

Discussed previously: https://news.ycombinator.com/item?id=44381093

> And I'm still not a fan of the idea of building the perfect IDE by composing different TUIs together and spending hours trying to get a perfect setup.

OTOH one could build distrib similar to spacemacs/lazyvim, then you could just start with that, and once you find one particular plugin annoying or lacking, you could swap it for something else, at least theoretically (I've never used those personally, so I don't know how hard it is in practive). Not so much with all the eclipses and jetbranses of the world.

> em dashes are, in most locales, not to be surrounded by a space

This is definitely not the case for at least French and Russian, which means markup renderers now have to guess text language or force authors to declare such in some metadata header. And it gets even more complicated with inclusion of block quotes in different languages.

I'm not sure if I'd count examples with spaces and comments towards valid emails, because one could argue these are not part of the address, they're email header syntax details. Like, sure, FWS from RFC can be used somewhere in the address, but it can also be in any other header. Also, CFWS and whatnot are going to get stripped anyway by the time you'd have to deal with SMTP (see Forward-path in RFC 5321, which doesn't allow `(nonsense in parentheses)`), so I don't think they should be considered part of the valid address anyway.

And tuomov (ion3) vs debian:

https://web.archive.org/web/20070307113840/http://modeemi.fi...

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=413469

I was actually the one who submitted patches for GTK3 support! But, yes, it's never going to work with GTK4, at least not without complete overhaul.

I don't daily-drive it though, mostly because I never found time to update rather limited set of keybindings, a task that seems way more involving than a couple of little fixes that were needed to support GTK3.

See also: vi keybindings for GTK2/3: https://github.com/polachok/gtk-vikb (not an active project though)

> preferably sort its stat()s and open/read/close() by inode

A better approach would be to use information about location of data extents. Luckily there's already a crate that can help with that: https://github.com/the8472/platter-walk

The last time I stumbled upon website that used vh for font sizes I was forced to enter into the developer tools and edit that out from CSS because: 1. it didn't work well with my vertical monitor setup, letters were ridiculously large; 2. I was not been able to compensate for that with standard page zoom because it's vh, it's roughly relative to the window size, and all that zoom changed is sizes of secondary page elements.

It's bad enough on desktops, now I feel it would be a nightmare on mobile even with desktop mode turned on...

I also wonder if there are changes to the kernel that can't be reversed with a simple mitigations=off and what effect compiler-based retpoline hacks have these days. Wouldn't be surprised if there's some other variable that I'm missing.

Wouldn't it be more accurate to use Belarusian ў for ł? They both actually seem to represent [w] sound.

How do those similar projects actually handle ambiguously written laws? All that I see in Catala paper is basically "let this whole thing bounce back and forth between lawyer and programmer until it becomes unambiguous."

You can do that kind of things already, albeit not from within a single universal shell:

- https://github.com/jhspetersson/fselect

- https://github.com/osquery/osquery

It's not about Friday deployments though: https://www.zdnet.com/article/garmin-services-and-production...

You don't even need to quit editor without saving changes, you can just ^Z it, add new changes, fg the editor back and continue with your commit message.

> If the screen is small, e.g. on mobile, Talkyard could probably be pretty certain which post one is currently reading, so might work ok well, automatically.

Modern smartphones easily fit a couple of comments on a screen, at least here on HN and on that forum that I mentioned in the other thread. Heck, I just dug out a 3rd-gen iPod Touch just to see how these websites look on its comparatively small screen. The result is that even devices with comparable screens (think iPhone 4S and other phones of that time) can occasionally fit a number of one-liners or, depending on a font size, a couple of longer comments.

The trick might still work though if you prefer much larger fonts, but otherwise smartphones don't make this feature easier to implement.

----

Speaking of mobile: I once experimented with showing replies one at a time. It did a good job at keeping the context around, looked and worked well on mobile devices, but I'm pretty sure it would make harder to find new comments, skim over discussions (and, say, find interesting/insightful comments just by scrolling around), and probably worsen experience in some other way. You can have a look over at https://vthriller.github.io/tmp-hn-comments/carousel.html

> Could also experiment with mouse pointing on a post, to make it the keyboard target. And then pressing 'P' to jump to its parent.

People often prefer keyboard navigation because they want to minimize palm movement as much as possible, and that means reduction of mouse usage as well. Aside from that, if mouse is in your hand already, you might as well click on an on-screen button near the comment—that would be faster than bringing palm back to keyboard.

You might want to try to mitigate that by switching binding to a key on the other half of the keyboard, so that it can be pressed with the other hand, but even then only a handful of people that spend hours navigating through threaded comment jungles will teach themselves to use both input devices to aid reading threads, and it's hard to think about anyone that can fit into that category. (At first I thought about on-duty moderators of traffic-heavy forums, but they don't usually need that much of a context to notice violations.)

However, you made a good point about accessibility earlier: people with some sort of impairment might win from that kind of hybrid navigation mode. But would it be easier for them than, say, keyboard-only navigation? This area needs much more research.

> Maybe it's not only that Mattermost is better at marketing (are they?) but also that they are less "power user focused"?

Familiarity plays a significant role here. There's plenty of chat apps that look and behave in a similar way, so it's easier to pick up or switch to another one if you so desire.

> 2. What about keyboard shortcuts?

That just would not work on smartphones.

> But how would Talkyard know which post, of many, you're reading, if the screen is large

One way is to implement arrow-key navigation and highlight current message in some way (border, bgcolor or whatever), but I'm not sure if that would work well outside of some special keyboard-centric navigation mode designed to cater to fans of software like mutt or vimperator.

Zulip comes to mind: in there selected message affects what topic people are going to reply into, and if people are not used to that feature (or to the idea of chats with topics in general), they can easily dismiss or fail to notice that very selection and treat the input box just like they would that in any other chat app, which would result in misdirected replies. Some teams are fine with spending some time babysitting the conversation (change topics of other people's replies after the fact, teach colleagues how to use that particular software etc.), but others would just switch to simpler software, with flatter conversations and/or less navigation features.

> 1. What if, at the top of the page, there were buttons like "Scroll to parent"?

Do you talk about the very top of the whole page (scroll position 0) or about sticky header at the top of the viewport? If it's the latter, then it's going to be as problematic as keyboard shortcuts (i.e. can't decide which message's parent we need to jump and where to return to).

> 3. A button "Show ansectors", for every post. Click it, and Talkyard would popup a dialog, with all ancestors (parent, grandparent, ...)

That implementations seems to be both the most robust and the easiest to implement.

I think "show me every parent message prior to this one" would be a better way to describe the feature that I occasionally miss in every implementation of threaded conversations. Sibling folding is just one of the ways to implement that.

The problem is that in very large threads it's quite hard to remind yourself about the context of the conversation that you're currently reading: you either need to scroll a lot to get to some grand-grandparent and back, or start manually folding messages above, one by one, subthread by subthread, until the context gets uncluttered.

Let met illustrate what I was describing: https://i.imgur.com/pm1SIRJ.png?r (You could imagine way more replies in those shaded areas—a situation that is not that uncommon here on HN.)

> It'd be interesting to have a look at that news site forum (if you have a link?).

I doubt that you will find it particularly useful (site in Russian, and I've no idea how reliably that feature works for unregistered users), but anyway: https://www.opennet.ru/forum/

> I wonder how they determine which messages are new. Maybe it's [new since one's last visit]?

It is. While not as powerful as status tracking for individual messages (can't skip some messages for future read as easily, can't mark message as unread etc.), it is enough for most users most of the time.

Re: finding new comments, I've seen another solution on one of the news site forums that I quite liked: messages are folding individually (i.e. only content is hidden but not the children), and when you enter the thread through the "new" link, only new messages are shown in an unfolded state.