Proposal: A set of "canonical extensions" distributed with the shell

[jpco]

I think a big part of the appeal of es is the combination of these three characteristics;

1. It doesn't do much by default ("minimal")
2. It can be extended to do a lot ("extensible")
3. Extending it is always just a matter of finding the right hook function and modifying it in es script ("simple")

However, this combination can cause friction when there's a behavior that es doesn't have by default due to (1), an may not be trivial to add or change due to (3). Examples of this include #33, #66, and #108. There are other examples in the mailing list as well, and various esrcs in the examples directory have a lot of overlap.

I think these cases illustrate that there's a certain class of extensions to es which are 1. pretty common to want, 2. not-quite-trivial to implement, and 3. only have basically one way to do it. For these it might make sense to create a small directory of canonical, "first-party" scripts that get installed into, say, /usr/local/lib/es, such that people can easily put . /usr/local/lib/es/status.es right on top of their .esrc if they want to have $status in their interactive loop.

Other examples might include $cdpath, cd history or pushd/popd, the autoload directory, path caching, or interactive shell init behavior (which in turn enable .bashrc-style init files). I'm picturing nice, composable, well-commented, even tested scripts, plus a mention of the directory in the man page. They could be a nice demonstration of what "effective es" looks like, and give users some of these nice additional features without requiring them to comb through the github, the source (for the examples directory), or the old mailing list, and helping limit some of the "noise" of feature requests in the core shell.

What do people think of this?

[wryun]

This sounds good to me. It also gives an opportunity for people to contribute without having to get too deep into the C.