Dude, I would just 2d print the png they sent and give them the piece of paper.

If they complained, I would say: "I literally printed the thing you told me to print."

Space-f lets you open a file in the current workspace, and :open /path always let’s you open any file on the computer

Is this a file tree, or just a fuzzy finder?

Fuzzy finders aren't a substitute for a file tree picker. They're only great, until you don't know the name of a file, or until you need to know of a file's existence in the first place.

I remember being really interested in Helix when it came out, but it didn't have a built-in file picker.

Is this still an issue for users? Is there a built-in solution, or a usermade solution to this?

Also, is there plugin support?

I can't use an editor without rainbow indent/brackets, without them code just takes too long to read that it becomes frustrating.

you have to fix the indentation because if not then the document won’t work or mean something completely different

Whitespace has no meaning in json. You can indent however you want, or not at all.

I'm assuming you're running into issues because you're writing json in a yaml file which does care about indentation, and you're only writing json in yaml to get access to comments.

In which case it circles back around to: why not use toml? Whitespace formatting doesn't corrupt the file, and it has built in comments.

Cut and paste problem?

Another way of reading it is: "GitUI is unfinished, but the parts that are done are amazing"

What do you mean about animations?

Every use-case I can think about is already well supported by vanilla css/js without libraries or frameworks. (not including really out-there use-cases like game engines or image editors)

Can you give an example?

Svelte uses labels, so Svelte itself is weird compared to everything. Except in a way to assembly and 50s goto-control-flow styled code.

it looks like JS/TS with arrow functions.

JS/TS already has arrow functions.

This comment just seems weird no matter which angle I try to approach it from.

immature tooling ecosystem

It's over a decade old now. I wouldn't call that immature.

Looking at your linked comment...

following a basic tutorial somehow ended up spending multiple seconds just to transpile and run “Hello, World!”.

1. Install deno
2. Create hello.ts containing: console.log("hello world");
3. deno run hello.ts (time taken to run command: 0.037s)

[...] 3 different ways of specifying the files and settings you want to use [...] 3 incompatible ways to define and use a “module”

Yes, that tends to happen as ecosystems evolve over time. Typescript allows developers to use modern standards-compliant modules, while maintaining backwards compatibility for older code.

embracing duck typing means [...]

One of typescript's strengths is that its type system isn't all or nothing. Typescript will support duck typers, but it isn't forced or limited to that. You can add as much or as little typing as you want. In theory, this means that the language supports simple beginners up to experts creating turing-complete theorem solvers at compile time. In practice, this means a much smoother onboarding and porting experience.

Have a “generalized fibonacci” module taking 3 inputs [...]

I'm not sure if this is the basic problem challenge or the hello world example was. It seems a bit ambiguous as to what you really want, but it's easy to create a module that takes inputs and produces outputs while running on backend servers, in browsers, and in CLIs.

It's not rebase vs merge, it's rebase AND merge.

Commit your changes into logical commits as you go.

Then just before submitting a pull request, review your own code. That includes reviewing your own commits too, not just the code diff.

Use rebase to:

• Swap commits so that related changes are together
• Edit your commit messages if you find a mistake or now have a better idea of what to put in your messages
• Drop any useless commits that you just end up reverting later
• Squash any two commits together where the first was the meat of desired change and the second was the one thing that you forgot to add to that commit so you immediately followed it up with another commit for that one missing thing.

Then, and only then, after you have reviewed your own code and used rebase to make the git history easier to read (and thus make it easier to review), then you can submit a pull request.

Samwho has great interactive articles, his recent article on memory allocation and slightly older article on load balancing are great for beginners just starting to explore those areas.

If anyone is interested in other interactive articles that aren't necessarily about coding, Ciechanowski's are the best. He hand-codes each interactive example and each article is so full that they could easily be entire chapters of textbooks.