4 ms·

This has come up before, so I probably should mention it in the README at this point. There are some differences: The main feature of sd is the command descrip

This has come up before, so I probably should mention it in the README at this point. There are some differences: The main feature of sd is the command descriptions in autocomplete. PATH_DIRS doesn't include these, so it's hard to compare them. At least by default, PATH_DIRS won't autocomplete nested directories. If you have blog/publish, it works fine. If you have blog/admin/ssl, you won't get autocompletion for admin. You can still run blog/admin/ssl with PATH_DIRS, but the subcommands are not discoverable anymore. (I'd love to know if there's an option to change this!) Finally, a trivial new script would be very easy to write, but giving it autocomplete for existing directories `new blog/admin/whatever` would not be trivial. And an "edit" script (which I use more often than new) would be very annoying without the same autocomplete. And if you write those, then, well, you've basically just implemented sd with SD_ROOT=$HOME/bin :)

cb321 4y ago
Fair enough. I agree that the README treating autocomplete descriptions as a "but, wait also!" does not make it seem like "the main feature". Projects often evolve faster than documentation. It happens. :) Seems this is more all about autocomplete (which can be..pretty ornate in Zsh) than dispatch.. I don't know of a `setopt` to fix completion for the blog/admin/ssl case, but Zsh mailing list guys are very helpful. With absolute paths Zsh is pretty multi-component smart..E.g. "/u/lo/bi<TAB>" can expand to "/usr/local/bin/" (with my mix of setopts anyway, assuming the expansion is unique). So, could just be more bug than intention. -- FWIW, the distinctions you drew highlighted (to me) "second class" support for NON-`sd` commands Re: this summary line. I expect this is the sort of thing a daily `sd` user might notice anon, but I did not see any issue on your github repo about this. I suspect it would not be hard to address. To be more concrete, the standard man format has a one-liner-ish summary of what regular commands are used by the old `man -k/apropos` system. You just need a general `extracted-summaries-from-man-or-scripts` data file (updated in cron/etc.). Once system & `sd` summaries are merged, search of that file(s) (even by just grep) is a more complete path to discovery. :) The TAB completion discovery you like is really just prefix-only search. You might be able to use this same data file to make `sd` a master meta-command that could dispatch not just to your own scripts but to anything both in $PATH and with a 1-line summary in its man page (or some similar rules). I might imagine typing sd prefix<TAB><more-to-isolate>--help<ENTER> becoming common. And, of course, just generating a barely populated man page with just titles and your summary line and installing that into the regular man-system and using apropos is another idea for non-TAB-oriented discovery/search/recall. Well.. /Brainstorming for now and Happy New Year! :)

cb321 4y ago

Fair enough. I agree that the README treating autocomplete descriptions as a "but, wait also!" does not make it seem like "the main feature". Projects often evolve faster than documentation. It happens. :) Seems this is more all about autocomplete (which can be..pretty ornate in Zsh) than dispatch.. I don't know of a `setopt` to fix completion for the blog/admin/ssl case, but Zsh mailing list guys are very helpful. With absolute paths Zsh is pretty multi-component smart..E.g. "/u/lo/bi<TAB>" can expand to "/usr/local/bin/" (with my mix of setopts anyway, assuming the expansion is unique). So, could just be more bug than intention. -- FWIW, the distinctions you drew highlighted (to me) "second class" support for NON-`sd` commands Re: this summary line. I expect this is the sort of thing a daily `sd` user might notice anon, but I did not see any issue on your github repo about this. I suspect it would not be hard to address. To be more concrete, the standard man format has a one-liner-ish summary of what regular commands are used by the old `man -k/apropos` system. You just need a general `extracted-summaries-from-man-or-scripts` data file (updated in cron/etc.). Once system & `sd` summaries are merged, search of that file(s) (even by just grep) is a more complete path to discovery. :) The TAB completion discovery you like is really just prefix-only search. You might be able to use this same data file to make `sd` a master meta-command that could dispatch not just to your own scripts but to anything both in $PATH and with a 1-line summary in its man page (or some similar rules). I might imagine typing sd prefix<TAB><more-to-isolate>--help<ENTER> becoming common. And, of course, just generating a barely populated man page with just titles and your summary line and installing that into the regular man-system and using apropos is another idea for non-TAB-oriented discovery/search/recall. Well.. /Brainstorming for now and Happy New Year! :)