-
Notifications
You must be signed in to change notification settings - Fork 464
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Alias Command #701
Comments
I really, really like this idea. It removes almost the entire downside of using the subfolders as namespaces, which has obvious benefits in organising stuff. Potentially also plugins, at some point. |
+1. Note that most |
Nothing to add beyond it being a great idea, and useful forward compatibility step as well I would think. |
There are a couple of general categories of tools:
It's the last category that this is a big win for - especially because different people have favourite commands and flags for them. I'd probably As above, I'd prefer to match the bash syntax as closely as possible here. |
This is mostly done. There currently isn't anything preventing aliases from referring to themselves, which I hope to fix, but the main functionality is implemented now. |
Hooray! (other comment: you've put the new docs below the wrong link anchor, so cross-references to cls will now refer to alias, and there's no way to reference alias - just move the old anchor below the new docs, and add a new one above 😄 ) |
Oops! I didn't notice that because the section links within that document worked as expected. Will fix. |
- Improve link in Binpatches.rst - Fix `alias` anchor in Core.rst (ref #701) - Increase depth of Plugins.rst table of contents. Some plugins were hard to find because they fit in multiple categories.
Addresses an issue with recursive aliases crashing (#701)
Problem: there are about 70 scripts in the main scripts directory, counting third party scripts.. Most people will not use most scripts. This makes the output of the "ls" internal command cluttered and confusing. We could put lots of scripts into well-organized folders but that would require excessive typing for the scripts people do use.
One possible solution is allowing people to "alias" scripts in subfolders as if they were in the main folder.
If this command is set up properly, it will be possible for us to arrange scripts into subfolders and have people use dfhack.init to alias the ones they use into the main folder.
I'm not sure how good an idea this is. Thoughts?
The text was updated successfully, but these errors were encountered: