Move parts or all of the core into plugins

[giddie]

I'd like to suggest that the "utility" functions be moved into a plugin, so that it's not mandatory to have those functions in the namespace. I tend to either write my own set of utility functions or write proper scripts as needed. The built-in utilities are interesting to read for reference, but I don't think I'd ever actually remember to use them.

[giddie]

@ColinHebert In 3, 4, and 5, if you create a new directory, you have to maintain a fresh list of which core modules will get loaded. What happens when one of the core modules is renamed, or a new one is added, or they're generally rearranged? Your setup breaks without any merge conflict. I think the current system is safer.

@sorin-ionescu You make a good point about editing the core module in-place. That would be OK, but I don't see how this is an improvement over the current situation. It is in fact more obscure, because the list is more hidden.

If utility, alias, and keyboard are pared down to the essentials, and the convenience stuff is moved into a plugin, I don't think anyone is likely to want to remove any of the core. It's not something that would be useful, and it would just make it more difficult for devs to update the core. I would in fact prefer to keep everything as it is and make those modifications in my own fork, rather than go with the modular approach.

@sorin-ionescu I don't buy that discoverability is fixed by documentation. To me, that sounds like papering over a usability issue. Both are necessary. In this instance, I don't see how the loss in usability provides a significant gain in functionality.

[ColinHebert]

@giddie If one module is renamed it will blow up because when you start your shell one module can't be found (the renamed one). If a new one is added, and you created your own core, it means that you're on your own. You will have the exact same behaviour as before. If someone create his own core, he is responsible for it, I don't see any issue with that. If you want to, you can do in place modifications, but it's not the way I recommend (but this is not really the issue here).

---

Regarding the hidden part, not being in the root doesn't mean you can't find it anymore. The root will only contain the loading system, everything else is in modules. There is no more to that. It's like saying "I can't find my personal files because they're not in the root of my system"; it's not because there is a hierarchy (which is pretty clear) that nobody will know where to find things. I would even argue that it's exactly the opposite.

---

I really don't get the last point. What do you mean? If you're used to the old structure, of course it will be easier for you to find the things you were looking for. But having something different doesn't mean that's more complicated than before. And if someone could read the code before, he will be able to continue to do that (seriously nothing changes except for some files moving into folders). It's not a loss in usability, it's just different (barely).

What it brings is more flexibility, as you can load only what you want using the same system for everything ("core modules or classic modules"), it's more consistent. Instead of having some files sourced in init.zsh, they're declared like every other modules in the zshrc. I don't get how this is a loss in usability or readability.

[giddie]

@ColinHebert The situation currently is that you can remove or edit files in core, and if a new one is added, or an old one is renamed, it'll crop up in the merge, and you'll either get the new file that is sourced automatically, or a merge conflict. This seems more straight-forward and safer, to me. Anyway, as @sorin-ionescu already mentioned, it would be possible to modify the core in-place, and I'm more OK with that, so maybe this is more of a personal preference thing.

---

I didn't say the file couldn't be found any more, I said that it was more difficult to find. The current layout has all the relevant files right there when you open the repository. The ones you want to look at are in front of you, straight away. After that, you can maybe start to explore what plugins are available etc... The module system mixes core with plugins, and you end up not really being sure what's loaded by default and what isn't without expending quite some effort. You can't assume that people are going to read the documentation carefully or discover templates/zshrc.zsh before diving in, and they might just be checking out the Github repo to see what the fuss is about.

The problem isn't so much that there's a hierarchy (although I do think it's superfluous), it's that the hierarchy mixes the "important" stuff with the "optional" stuff in a gratuitous way.

---

In my view, the loss of usability is caused by the mixing of core and plugins to the point where everything is lumped into a big nondescript pool together, and you're left wondering what's important and what isn't. People didn't need to follow the flow of execution previously to figure out which files were loaded; it was obvious that the files in the root are important. Less time grokking init.zsh means more time checking out the code that matters. I know that if I load all the .zsh files in the root, that's pretty much all the important stuff in OMZ. That's not possible with the module layout. I don't think most people that want to tweak OMZ are interested in serious shell coding; they just want to see what it does and maybe tweak things here and there. The old layout made that easy.

I see that this idea is tempting because of the uniformity it adds to the implementation, but I don't think it's a win for the users; I really don't.

[ColinHebert]

If a new user who doesn't know how it works and doesn't know how to use ZSH (we're talking about this kind of users right?) start to use that without reading the basic documentation it will never work (unless they're good enough to know that the zshrc in templates is what they will need).

If we're talking about entry level developers, reading the zshrc will be enough to understand that one of the loaded modules is core and this is a really nice hint regarding where the "important stuff" can be.

And I'm quoting the "important stuff" part because once again, as @sorin-ionescu said, it really depends on what you want to do. If you just want to have the completion you can just load the completion. There is not really any module more important than any other. There is just these modules that were the core of OMZ before which can now be loaded with the "core" meta-module but if you only want aliases, you can go ahead and load only aliases.

The thing is, OMZ with the current layout gives more importance to some parts that they actually need, and this was why you opened this issue in the first place. In your configuration utility didn't have its place in the "core" part of OMZ. But it was only for your case. @sorin-ionescu disagreed with that in the first place, because in his configuration utility are a part of the "must have" of OMZ.

Now this modularity solves this situation because in the end there are no parts "more important" than any other, it only depends on what you intend to do.

[sorin-ionescu]

If modules are defined one per line instead of all on the same line in the core meta module, Git merges should work well, even if you have made personal, in place, changes.

[giddie]

Oh man, we're just not going to agree on this, are we?

What makes OMZ great is that it provides a simple framework for tweaking aliases, functions, keyboard bindings, environment variables, options, etc... I want to be able to tweak these things, but I don't see why anyone would want to disable them. What would be the point? There's always going to be a replacement. If I disable alias.zsh, it's almost certainly because I want to use my own set of basic aliases, and where will I put those? Why not just replace the ones in the original alias.zsh? The same goes for all the basic core files, pretty much. OMZ provides a great set of categories for the basic configuration of ZSH. Why would I want to disable any of it? (I think utility is a special case, because it doesn't contain anything to do with basic configuration.)

In setting up my OMZ, I always have in the back of my mind: "Could someone else clone my fork and make this their own?". That way, I can set friends up with my OMZ setup without too much stuff that's unique to me. That's why I tweak basic stuff in OMZ, and keep things unique to me either in .zshrc (or local.zsh in my setup), or in a plugin. For instance, I have added correct_all to my alias.zsh, because I like ZSH to correct command arguments, but I've placed correct dvorak in my local.zsh, because I know that I'm unusual for using a Dvorak keyboard layout. My intention is, as I've mentioned before, to have something akin to a CSS reset, with some ready-made bits of awesomeness ready to throw in if I want them. That's what a framework should be.

The idea of modules breaks down this utopia for me. Categories of configuration disappear into a mire of plugins.

Maybe I'm not articulating it well, and maybe I haven't even completely figured out what upsets me about this so much, but as stupid as it sounds, it really doesn't smell right to me.

[sorin-ionescu]

@giddie,

You are myopic by your own use case and ignoring others. I was as well. You are asking, 'Why this?' and 'Why that?' I have asked those questions myself. I do not know why. People's brains are wired differently. I have had private whining about different parts of the core for months.

You are advocating convention over configuration, which works until it doesn't, at which point it becomes a nightmare. It's short term profit over long term benefit.

Instead of asking why would someone want to disable it, whatever it may be, ask why would someone want to enable it.

There is no real separation between configuration, utility functions, and aliases for a particular tool or use case. Some plugins are configuration because they change the environment. Perl, Python, and Ruby are a good example.

What is a plugin to you or me may be essential to someone else. dpkg is essential to a Debian user. pacman is essential to an Arch Linux user. rails is essential to a Rails user.

A modular approach is superior.

[stephenmckinney]

I really like direction of branch issue-23. The configuration is explicit and code is much more browsable. You can take one look at .zshrc and follow what module you're including. Also customizing a "core module" is now just as easier as customizing a plugin. Each module becomes a first class citizen, while still being opinionated with the core meta module: +1 for 1, 2, 5.

Personally I'd favor a well written README explaining modules rather than a wiki, since the README can be tracked along with the code. That way it's easy to see what code introduced what changes in usage. But that's all a matter of personal taste.

[sorin-ionescu]

@poorlilrichboy Yes, documentation is lacking. @ColinHebert has written a README for tmux and is in the process of writing one for git. I'd appreciate if people would write documentation for the plugins they use. It frees me to focus on the code and in-code documentation for contributors.

[giddie]

OK, I concede defeat. I'm not happy, but maybe it'll grow on me.

[jedahan]

Is ls ~/.oh-my-zsh more transparent than cat ~/.oh-my-zsh/modules/core/init.zsh? I agree with @giddie that adding this layer of abstraction does make OMZ more complicated, but the benefits seem to outweigh the negatives:

• Modularization benefits power users by making core modifications simple and safe. = Any user who only modifies ~/.zshrc should be unaffected.
• It is harder for new contributors to know what they can depend upon when developing modules

Putting core in the same list as other modules indicates that module authors cannot depend on anything loaded by core. This should be included in the appropriate documentation, either under contributing or module authoring.

There is a chance this is already the case, or that core will eventually be so small that no sane module would require any functionality defined in core. In that case any documentation would not need to be as explicit, and could just describe modules as vanilla zsh scripts.

[sorin-ionescu]

@jedahan, the idea behind core is not to provide features, but to act as a meta-module to turn the following

zstyle ':omz:load' omodule \
  'environment' \
  'terminal' \
  'keyboard' \
  'completion' \
  'history' \
  'directory' \
  'spectrum' \
  'alias' \
  'utility' \
  'archive' \
  'git'

into

zstyle ':omz:load' omodule \
  'core' \
  'archive' \
  'git'

Perhaps not having core and being more explicit about what is being loaded is not such a bad thing because my idea of a core may not your idea of a core, and it clearly isn't with some people.

[jedahan]

Perhaps I was not explicit in my last comment - the current implementation being pursued for core as a meta-module is a good compromise for users, power users, and contributors. It allows those who disagree with what your idea of a core to modify it easily, while making regular users happy with a simple and safe default config. In fact having the core abstracted away from normal users is an extra layer of safety - they do not have to worry about module loading order, except 'core first'.

In short, I prefer core implemented as it is in this branch for the reasons listed above. My discussion point regarding documentation is outside the scope of this issue and muddled the message of '+1'.

I appreciate the time you have taken to provide clear and explicit responses.