I believe hash -d and supsequent expansion of those paths only works in ZSH, which calls this "static named directories" (http://zsh.sourceforge.net/Doc/Release/Expansion.html#Static...).

Similarly, man and woman in Emacs generate a ToC that imenu (M-x imenu) can use.

The announcement already mentions that ProxyJump is meant to be a simplified version of indirection, not a completely new feature.

Or use the reader view.

This is why you don't let cats anywhere near your keyboard ;-)

I agree on the section definitions. It's very hard to remember which underline I need to use because every project (or even document) can just define their own order implicitly. The sphinx project recommends a specific order somewhere in their documentation that I look up every time I need to write rst, but markdowns just-count-the-hashes is much easier.

To be honest, I don't find this to be true. To email a patch, you usually have to

* figure out if you can use git-request-pull or git-send-email * sign up for a mailing list (which, depending on the mailing list software the project uses, can take anywhere between a few seconds and annoyingly large amounts of minutes) * optionally figure out how to not receive the whole traffic of the ML or set up custom email filters * figure out if you have to CC the people responsible for the area of the code you're going to send a patch for (which might be written down in a wiki, some CONTRIBUTING file or somewhere else) * figure out if the project wants an extra cover letter for the patch series or not (and optionally search the man pages for how to write one).

With GitHub, I just use [hub](https://hub.github.com/) or an Emacs package or plugins for other editors to

* fork the repository * (without additional tools, I now have to add my newly created remote) * push to my own remote * create the pull request after reading CONTRIBUTING<tab>

which so far has been the exact same workflow for every project I've seen (ymmv of course).

If I was going to email a patch to a project,

- I would already be following the mailing list and/or the bug tracker,

- I would already have read the relevant guidelines before starting to work on the tree, and

- I would already have figured out to whom should I refer my patch.

And no lock-in to git itself. The project can use git, hg, cvs, svn, darcs, rcs, sccs, whatever. I can, after obtaining the tree, create diffs to orig files and be done with it.

If I was going to contribute to a project on github (which I did a few times), the above-mentioned are still relevant, if one wants to contribute to a projects, they should be familiar with it. Also, I would have to know how things work the github way. And because the github way is so mechanical, it becomes hard to enforce project rules.

Then, the github web interface is score oriented: Commit numbers, release numbers, source tree layout in the face, source language statistics, search that can take me to other projects, profiles with contribution numbers, many other irrelevant stuff. It makes one want to "score", and "show off". It distracts from the actual goal of one's contribution: sharing.

Note that not all of those use Phabricator as a bug tracker (KDE, lighttpd, LLVM, Haskell, I imagine a lot of bugs for Wikimedia are reported through project chat pages on the wikis themselves).

The same thing exists for regional and inter city trains in germany that the Deutsche Bahn is responsible for: http://www.apps-bahn.de/bin/livemap/query-livemap.exe/dn?L=v...

If by "hardcodes" you mean "can be changed in the configuration file", then yes, that's true.

The issue is that if no configuration is available/found/readable things doesn't stop working with a sensible/expected error - but rather enters a new and unexpected (error) state. Error if you didn't want to use Google's resolvers.