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.
> 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
> I don’t yet love how history works. Four months in, I still can’t get used to not having ctrl-r.
I think it's worth getting used to but there are plugins like fzf that implement ctrl-r
> `BROWSER=otherfunc aws sso login`
Aliases/functions are generally not visible in child processes.
I guess it worked if the "aws" tool invoked BROWSER via a bash process that either sources aliases from a bashrc, or reads exported functions ("export -f otherfunc").
It would work for fish too if "aws" invoked BROWSER via fish (though fish doesn't need exporting, since functions are also loaded in non-interactive shells).
I recommend that you make otherfunc a script, then it will work everywhere (also with arbitrary wrappers like strace, gdb).