Kakoune has network-transparency - you can run the editor server on a remote system and run editor clients locally, communicating only via Unix socket.
> You can effectively run whole development (LSP, docker, compiler, files) on remote like it is on your local machine.
the same is possible with any other editor that implements a client/server model, and it can be done without giving the server the ability to execute code on the client
> The main problem is that Git was built so that the commit message is the _email body_, meant to be read by everyone in the project.
I find this very hard to believe. Isn't it "everyone who is interested in the commit subject/files touched should read the body". Why would anyone else read immutable historical documentation?
> Even if you're _very good_ at Git, finding the correct invocation of "git blame" (is it "-w -C -C -C"? Or just _two_ dash C's?) to even find the right messages that are relevant to the code blocks you care about is not widely known and even if you find them, still only show the first line. Then you need to "git show" the identified commit SHA to get this long form message. There is just no good way to find this information, even if it's well written.
This sounds like you are joking. Any good IDE will be able to annotate each line with blame info, and show the diff at the press of a button. On such diffs, the IDE should allow recursive blaming on context/deleted lines. Tools like Tig allow exactly that.
GitHub certainly does make it hard to see commit messages, I give you that :)
> Hundreds of hours of amazing documentation from a true genius that almost nobody will ever appreciate. It's horrifying.
?? It's not like it was written for fun. This documentation attached to a commit exists to reduce the risk of accepting the patch from someone who might not be around in future, to fix any problems introduced. By disclosing all their relevant thoughts, the author shows their good intentions: they enable others to build on top of their work. If the author kept their thoughts to themselves they would gradually build up exclusive ownership of the code, which is often not a good idea. Also a commit message serves as proof of work, which can be important when there's too many patches. For commercial projects some of this is less important.
I might be in the minority, but parent's comment is probably about people like me: most of my coworkers have context free, or at best succinct commit messages. I never read more than the first line listed in the commit list, and don't even assume the description is always accurate.
Instead I'll spend my time stalking the related merge request, where the full description of the whole change resides, with probably a link to the ticket or reference documentation, and all the back and forth on why something is or isn't a good idea.
I think the world could be a better place if all of that was in git directly, but that's also utting much more burden on an already complex tool.
> I find this very hard to believe. Isn't it "everyone who is interested in the commit subject/files touched should read the body". Why would anyone else read immutable historical documentation?
If you think about who created GIT (Linus) then it suddenly makes sense that the commit message is like an email body since most of the Linux kernel collaboration is done via a mailing list?
> Notice that both fzf and fzy ranked source/blender/makesdna/DNA_fileglobal_types.h higher than GNUMakefile. I believe this is because /make and _file in that path are on word boundaries and are ranked higher than UMakefile that is not on a word boundary.
The reason for prioritizing word boundaries is so that you can type "sln" to match "SomeLongName". So while you are improving one use case you are probably breaking another one.
I'm not sure how VSCode ranks GNUmakefile first, maybe they prioritize exact substring matches. It's still a heuristic that can fail. The ugly part is that it's not part of the "best match" algorithm that finds a global optimum.
> It first attempts a match on the filename. If there is no match, it retries on the full candidate string
reply