Sort of.
They basically said they didn’t know about the issues with hyprland, they recently looked into them and to them in looks like hyprland has changed enough to be supported.
But, they were silent on the DHH. That part is the serious concern.
Supporting Hyprland definitely looks like a mistake, they weren’t aware of what went on around there.
They probably should have gone with supporting Niri and maybe Cosmic instead.
Gotos being bad falls in the it depends category.
Bad:
Good:
I don’t see any actual temper lost here.
In one case he points out that someone is making commits that have messed up a file’s indentation, and to stop doing that because it’s messing things up (they were).
In the other case he points out that rust’s default format rules are wrong (in the context of version control readability, they are) and asks someone to fix them.
I’m more interested in what the Oil shell has been doing, it has a higher potential roof while keeping backwards compatibility rather than the current standard of affairs 10ish year development cycle of a new shell with slight improvements.
Switching shells can be a massive pain in the ass, so if we’re making a change, it has to be worth it.
Oil looks like it could be worth it and then some.
I think it’s mostly former apple users who like gnome (gnome 3 era anyway) the most, since to them MacOS looks awkward and slow.
Those users are shown too much in one go kde, lock up and scare themselves away from it.
KDE really needs to change how they introduce new users to it if they want to gain new users. The troubles this user had in KDE will actually help them do that in a small way, but they need more footage of first time users explaining what they are trying to do to help them see what’s actually confusing of not obvious your first time around.
I’ll repost my comment yesterday about this very thing (link: https://news.ycombinator.com/item?id=45279384#45283636)
It’s also too early to worry about DOM apis over wasm instead of js.
The whole problem with the DOM is that it has too many methods which can’t be phased out without losing backwards compatibility.
A new DOM wasm api would be better off starting with a reduced API of only the good data and operations.
The problem is that the DOM is still improving (even today), it’s not stabilized so we don’t have that reduced set to draw from, and if you were to mark a line in the sand and say this is our reduced set, it would already not be what developers want within a year or two.
New DOM stuff is coming out all the time, even right now we two features coming out that can completely change the way that developers could want to build applications:
being able to move dom nodes without having to destroy and recreate them. This makes it possible so you can keep the state inside that dom node unaffected, such as a video playing without having to unload and reload a video. Now imagine if that state can be kept over the threshold of a multi-page view transition.
the improved attr() api which can move a lot of an app’s complexity from the imperative side to the declarative side. Imagine a single css file that allows html content creators to dictate their own grid layouts, without needing to calculate every possible grid layout at build time.
And just in the near future things are moving to allow html modules which could be used with new web component apis to prevent the need for frameworks in large applications.
Also language features can inform API design. Promises were added to JS after a bunch of DOM APIs were already written, and now promises can be abortable. Wouldn’t we want the new reduced API set to also be built upon abortable promises? Yes we would. But if we wait a bit longer, we could also take advantage of newer language features being worked on in JS like structs and deeply immutable data structures.
TL;DR: It’s still too early to work on a DOM api for wasm. It’s better to wait for the DOM to stabalize first.
No, but there’s so many similarities and so much back-and-forth cross-pollination between the two that it’s still worth sharing.
You wouldn’t say: “Don’t post anything about cURL” just because it runs on more than linux.
Most notably it is the first language which understands the code it is compiling
wat
I paid for it too!
It’s the first piece of shareware I actually went out of my way to pay for because it was so good that I’d be genuinely pissed off if it died. I’d probably end up switching to pijul or something else for my projects if it ever did.
I’ve seen a bunch of people messing the windows version running in linux in the fork forums, so it may be coming in an unsupported capacity.
Yeah, I use it when ssh’d into a server, but it’s just so awkward to use.
Sometimes it just really doesn’t want to separate a hunk. Other times you want to stage all lines except one, and you have to do a million splits just to target the lines you want to keep.
It’d be far easier if you could just select the lines you want to affect. It’s literally the first feature shown in lazygit’s readme. I think half the reason that people use lazygit is that partial commits are so awkward to perform in most other clients.
Luckily Fork does it as well as lazygit
Fork !!!
It’s hands down the best git client.
It’s free as in: sublime text or winzip where they ask you once a month if you want to pay for it but you can just select: I’m still trying it out, and it gets out of your way.
And one killer feature that I haven’t seen any other git clients handle: allowing me to stage only one side of the diff. As in: if I change a line (so it shows up as one removed line and one new line in git), I can decide to add the new line change while still keeping the old line.
So changing this:
doThing(1);
into this:
doThing(2);
Shows up in git as:
- doThing(1);
+ doThing(2);
But if I still want to keep doThing(1);, I don’t have to go back into my code to retype doThing(1);, or do any manual copy-pasting. I can just highlight and add only doThing(2); to the staging area and discard the change to doThing(1);.
So now the code exists as:
doThing(1);
doThing(2);
Now with a one-liner example like this, we could always re-enter the code again. But for larger code changes? It’s far easier to just highlight the code in the diff and say: yes to this and no to the other stuff.
And when you get used to it, it makes it really easy to split what would be large git commits into smaller related changes keeping your git history clean and easy to understand.
The first problem is they’re letting AI touch their code.
The second problem is they’re relying on a human to pick up changes in moved code while using git’s built-in diff tools. There’s a whole bunch of studies that show how git’s diff algorithms are terrible, and how swapping to newer diff algos improves things considerably.
TL;DR on the studies:
There’s also a bunch of alternative diff algos you can use, but the best ones are paid, and the free ones have fewer features. See:
Most new users won’t even know that there is a choice until they’re presented with it, and most will just stick with the default option anyway. (which most distros have/are switching to wayland)
The top comment in the linked article pointed out how that chunk of text was less than truthful:
There’s definitely regressions that need to be fixed, but the way it is presented here is just misinformation, mixing things like project-specific bugs and misunderstandings in as Wayland problems.
*BSD is officially supported by Wayland and by several display servers (a better state than for X11 where the *BSD’s had to patch things quite extensively downstream), the graphics tablet thing is a KDE-specific bug, and global hotkeys is available in some display servers through XDG portals (albeit a bit slowly), and using multiple independent mouse cursors is very specifically a Wayland feature (wayland multi-seat). Restoring window state is also supported, it just works differently than X11, and sway at least supports global fullscreen the same way as i3. […]
The other comments pick out the other issues the top comment didn’t go through.
It’s not about caring, it’s about the lawyers making the argument javascript’s genericness easier
Imagine if god showed up one day and said: “It’s actually Jod” then left
I was unfamiliar with the decorate flag, but I can’t see any difference after trying.
I will say this is one command I absolutely refuse to create an alias for.
I have force committed to memory the command: git log --graph --remotes --all (and the variation with the --oneline flag appended to the end if needed) so I can use it anywhere.
It’s the one command I can’t live without.
Try this link on an iPhone: https://jpegxl.info/resources/jpeg-xl-test-page.html
Hang on…
Just because no one has asked it yet…
Are you only using a HDMI cable and have you not tried a display port cable?
FYI: The “HDMI Forum” didn’t want to allow open source implementations of HDMI 2.1. They wanted to charge people a fee for using it. This is why people use display port, it has no fee and it usually has newer feature support earlier.