Minor fixes on utility

[ColinHebert]

• mkdcd should use cd's completion, as only the first parameter is used
• no need to force builtins commands, if the user wants to wrap them,
  those wraps should be used

[sorin-ionescu]

The wraps may fail.

[ColinHebert]

Wouldn't that be the responsibility of the user?

[sorin-ionescu]

No. RVM used to wrap cd, and it caused nothing but problems.

[ColinHebert]

Still, this is the user's problem. I would expect cdll to behave exactly as if I actually typed cd followed by ll.

[sorin-ionescu]

RVM caused me to prepend builtin in the first place. I am the user.

As for the completion for mkdcd, it should be mkdir's completion, not cd's. The directory does not exist. Using the mkdir completion, the user gets documentation for mkdir -p, which is useful.

[ColinHebert]

So how you use cd inside your terminal, every time you time builtin cd instead of just using cd?

Regarding the completion, mkdir's completion also contains the completion for -m -v --help and --version which is misleading because if any option is passed to mkdcd the command will have an erroneous behaviour.

[sorin-ionescu]

The proper way to fix this is to check for mkdir options, not to switch to cd's completion, which gives nothing of use but cd -0/Desktop/. What's up with that -0?

[ColinHebert]

I think that's the -n option of cd that shows up (actually I didn't thought of that one).

The third form of cd extracts an entry from the directory stack, and changes to that directory. An argument of the form '+n' identifies a stack entry by counting from the left of the list shown by the dirs command, starting with zero. An argument of the form '-n' counts from the right. If the PUSHD_MINUS option is set, the meanings of '+' and '-' in this context are swapped.

[sorin-ionescu]

If you want to fix mkdcd, add option parsing then shift by 1 if an option has been detected.

[ColinHebert]

What about using _path_files -/ for completion?

[sorin-ionescu]

Why? mkdir is the main command here.

[ColinHebert]

Because only the first parameter will be used, and this parameter has to be a directory. Even if mkdir is the main command, the only thing that really matters here is that first parameter.

[sorin-ionescu]

I disagree.

If you care so much about fixing it, detect mkdir options.

[ColinHebert]

You disagree on what? Right now mkdcd only uses one parameter, that's just a fact. And that parameter MUST consist in a path to an existing directory followed by new sub-folders that will be automatically created. I'm not sure what is the thing to agree on here.

The solution I just talked about does exactly that and avoid problems that mkdcd currently have when you use the completion.

And yes of course it's possible to rewrite an entire function that will check which parameters are passed (and if the said parameter is -m handle the fact that there is an associated value) but that's not the point. Actually that's way more than what mkdcd is about!
The options we're talking about here are --version, --verbose, --help and -m, none of them are relevant to the mkdcd command (-m maybe, but I'm not even sure that should be handled at all).

[sorin-ionescu]

I do not want to handle options; I was thinking of just passing them to mkdir and let it handle them.

_path_files -/ doesn't work. It completes both files and directories.

[sorin-ionescu]

I found a bug. utility depends on alias for the *ll functions.

[sorin-ionescu]

See branch issue-145.

There is a problem though. completion has to be loaded between alias and utility.

One option is to not depend on the ll alias and just use ls -lh instead. I'm using builtins everywhere else anyway.

[ColinHebert]

Yes, I think that the dependency on alias isn't that important and ls -lh is an easy way to get rid of this dependency.

But even if we do that, completion may depend on alias ($LSCOLORS), and utility may depend on completion (compdef), so we're still stuck with alias, completion, utility in this order.

[sorin-ionescu]

I have removed the alias module dependency.

[sorin-ionescu]

How is the utility/init.zsh now? I'd like to merge it.

[sorin-ionescu]

I'm merging it. We'll make a new issue when we figure out how to deal with compdef. I wonder if it's possible to add multiple definitions in a _foo file.