Add ranger contrib to spacemcs?

[punassuming]

Currently, I dont add anything to the contrib beyond a binding. What would be needed to convert to a package? Or is it still to niche?

[syl20bnr]

Not sure to understand the question, we already have a contribution layer for ranger in spacemacs right ?
Are you asking if it worth it ?
Well, technically the layer is not really useful, the README is very good though but it introduces some duplication with the ranger repository documentation.

If you are OK to remove it, go ahead :-)

[punassuming]

I am asking if I can just add to package.el

[syl20bnr]

oh ok, sorry I need some sleep :-)

I would like to add it to spacemacs layer but spacemacs users using emacs style may find it not useful. Do you think you can support "emacsy" key bindings in ranger ? Maybe just navigation on nfbp is sufficient.

[punassuming]

OK, currently I have emacs mode bound to jk to replicate the real ranger, right now ranger doesn't interfere with anything unless you go into it.

[punassuming]

Go to sleep :)

[sooheon]

Why not leave it as a layer? At least take out neotree and put it in in its place. Or even better, take out neotree and turn that into a layer as well. Dired is default, and neotree + ranger will be too much duplicate functionality, in my opinion.

Or more simply, what would be the benefits of making it core, not a layer?

[syl20bnr]

@sooheon to be honest I see the ranger layer as an improvement over dired but I wonder if it can completely wrap dired to the point to replacing it.
Neotree fills a niche that dired does not cover which is a file tree side bar.

@Ralesi in what measure ranger is compatible with the dired buffer key bindings ? Can we do everything we can do in dired in ranger ?

Another proposition would be to activate ranger in core when the editing style is vim, or we could make it a dotspacemacs variable.

[sooheon]

What about including it as one of the example default layers on a fresh install? That way newcomers are exposed to it, without it being forced. I don't mind making it a variable, except that there are too many of those already, and toggling a variable or adding/removing a layer are the same, except I think the layer is the correct layer of abstraction.

If we put it into core, someone like me will just add it to dotspacemacs-excluded-packages (like I've already done with neotree), and as long as it's modular enough that doing so can get rid of any trace of it, I'd be happy.

[syl20bnr]

You are right that a layer and a dotspacemacs variable are in the end the same thing. The difference is that a dotspacemacs variable is about core feature and a layer is about optional feature.

Maybe neotree could be moved to a layer called sidebar where we can propose a file tree with neotree and speedbar (the user chooses which one to activate with a layer variable) and other things.

I'm pretty convinced now that we should let ranger in a layer. But I would like to insert it as default in the layer list when vim editing style is chosen.

[sexptherapy]

Ranger is one of my favorite things in the world. That said, I don't believe the way it is in Emacs is stable or mature enough to be default anywhere. Even themes get it wrong.

Another point is that, IMHO, people coming from Vim expect something like Neotree but not something like ranger. I think ranger as a layer is more than enough, at least for now.

[punassuming]

I was never intending to overwrite anything by making it a layer. Currently, the only way dired gets overwritten at all is when you actually run ranger-enable. There are no hooks off of dired or find-file so the intent is that ranger acts as a separate app. The only hook I have is window-configuration-change to automatically disable ranger when you move out of the primary buffer. I implemented a deer function recently, based on the zsh package @vifon has created to contain a lot of the same features of ranger in a single window, but this too should be self contained. This disables preview and parent directories though so it is only for fast file navigation. I agree with @felipe-barros it is still immature in certain aspects, I haven't overwritten dired commands and I haven't implemented proper copy and paste rings, but it has gone a long way in the last 2 weeks. It should remain as a separate app though, in my opinion we should never overwrite dired as the primary form of file management.

I agree with @syl20bnr, there should be a sidebar contrib though for neotree and sr-speedbar, I have been wanting a nice taglist buffer for a while now.

[CestDiego]

@Ralesi wasn't ranger already added?

[TheBB]

As far as I understood, this discussion is about moving ranger out of its own layer to the spacemacs layer. I might have misunderstood, though. It seems the consensus is that it can wait?

[punassuming]

Yes, that was the consensus. Now that I am adding more to the layer, it makes sense to have it as a separate contrib.

[TheBB]

Okay, thanks. :-)