Don't forget the self-documenting aspect. The manual is included, the api documentation is included, you can ask emacs which command is executed when you click somewhere or when you press a button. I recently tried to do the same thing in Intellij, pita. Not only, can you find documentation, you can jump to the source code, inspect variable values at runtime, and debug or profile everything. All of that from inside the environment.
Seems like the conceptual design helped with that too, reducing the activation energy needed for clear, interactive documentation. The code and the UI are both designed against the same set of consistent concepts, which naturally brings them together and, in turn, makes it so much easier to tie them from one to another. Simplest example: every interaction in the UI is a "command" and commands are reflected in elisp, so having a way to jump from an interaction to the corresponding code and documentation just makes sense. The documentation can be organized along the same conceptual lines as the code and the UI.
Dynamic scoping is a feature in the Emacs ecosystem. It plays a similar role to dependency injection in other languages. It is what allows you to change global state for some function call. Dynamic scoping together with buffer-local, file-local, directory-local variables is similar to scopes in dependency injection libraries --- a powerful organizational tool.
One way to deal with large binary files is git-annex, it is as decentralized as git. But I dare say it lost to git-lfs, because Github and co weren't interested in hosting it.
thinking more about this, the difference between a hierarchical and non-hierarchical storage i the existence of additional indexes representing the hierarchy.
in most filesystems files are addressed by an inode. and directories are just lists of inodes. if you remove those then you end up with a KV store: inode->file.
consequently i see no difficulty to convert a KV store into a hierarchy by adding the necessary tables/directories representing the hierarchy.
the KV store i am talking about doesn't use paths, it uses IDs. the paths are in a hierarchical directory that is added on top of the KV store, or alongside of it. the result is a filesystem.
Yes, the history of the name is as you write. But the value of the command lies in finding the commits, and, especially, in finding which lines changed together.
yes, there is also a "cat" executable that is being looked at. In this case it is probably harmless, but I am not sure why they have no source for it. someone suggested it came from gvim.
A proposal in the attached issue suggests just building it from openbsd sources which is probably not the worst place to get source for tee.
