Sr speedbar

[edrex]

This builds on #2002, adding a key binding SPC f t overlaying the neotree binding. @CarlQLange also opened #3224, but didn't make any additional commits.

Caveat: I'm not 100% happy with Speedbar being a global singleton buffer rather than allowing an independent buffer per frame. In a multiple frame workflow where the speedbar frame is already visible in another frame, the first SPC f t toggles the buffer off in the other frame, and the second reinitializes it in the current frame.

[robbyoconnor]

I removed my previous comment. Nevermind :) We really shouldn't have 3 PRs for the same thing...

[TheBB]

I tried this out, and I like it, but would like it to be a bit more solid.

1. Can we try to make the keybindings as close as possible to those of neotree? Please document them in the README.
2. With the speedbar open I tried SPC hdf and opened the documentation of a function. Suddenly I had two speedbars...

I would also like to suggest the layer be called just "speedbar".

[edrex]

1. Can we try to make the keybindings as close as possible to those of
   neotree? Please document them in the README.

This only implements one binding, SPC f t, which mimics neotree's binding, and it's documented in the README. The only other binding Neotree defines is SPC p t, but that would require projectile integration so I left it out. Does that seem ok?

1. With the speedbar open I tried SPC hdf and opened the documentation
   of a function. Suddenly I had two speedbars...

I'd also seen speedbar duplication - #2002 (comment) - but only when toggling the speedbar frame via (sr-speedbar-toggle). I haven't seen buffer duplication when using (sr-speedbar-show-or-hide) via the included keybinding. Are you seeing duplication when using the keybinding?

I would also like to suggest the layer be called just "speedbar".

I guess I was imagining that at some point someone might make a Spacemacs layer for plain speedbar, and sr-speedbar seemed more concise.

[TheBB]

Neotree defines these bindings. I'm not sure how many carry over to speedbar or how easily, but consistency is king around here. :-)

In general we prefer to name layers after the features they provide, not the packages that they use. So layers are called auto-completion, spell-checking and syntax-checking instead of company, flyspell and flycheck. This helps newcomers. Certainly we're not super consistent on this rule (eyebrowse) but I would vote for speedbar over sr-speedbar.

[edrex]

@TheBB ah I was focusing on global bindings and hadn't thought about changing the bindings for the speedbar major mode, but that makes sense.

I've actually stopped feeling the need for a persistent directory listing pane after using Spacemacs for awhile and habituating on SPC f f and friends. I suspect that this "Sidebar Withdrawal" is a common progression for users coming from Sublime Text 2, Atom, et al. It may explain why three people have picked up this patch and then not taken it very far.

I feel bad about picking up a patch and then dropping it, but I'm feeling like closing this honestly, especially since it doesn't support multiple frames well. Others feeling like this is important? @blinkd

[saneletm]

with regular sr-speedbar on emacs, I can click SPC with the cursor on a file name, and I can see the contents of the file, a list of classes and function and vars. How can I get the same functionality using this layer on spacemacs?

[lukeorland]

This seems related: https://github.com/anshulverma/projectile-speedbar

[robbyoconnor]

@lukeorland -- maybe make a new PR?

[nicbet]

Quick comment: I just merged this PR locally into v0.200.4. I really do love this functionality and prefer this over the default Neotree that this layer shadows. The ability to switch between files and buffers is incredibly helpful.

[Compro-Prasad]

@nicbet Did you checkout treemacs? What are the differences?

[robbyoconnor]

This issue is rather old

…

On 06/28/2018 10:23 AM, Compro Prasad wrote: @nicbet <https://github.com/nicbet> Did you checkout treemacs? What are the differences? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3559 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABaMAy9CXtR1CV093AfvGNxfrIrlqgCks5uBREEgaJpZM4GV6Vr>.

[Compro-Prasad]

@sdwolfz I think we can continue without this PR for the following reasons:

1. sr-speedbar isn't actively maintained
2. It is an uncommon package
3. treemacs does things better and has an active maintainer

[sdwolfz]

@Compro-Prasad indeed this PR is old and with the recent changes that introduced treemacs this requires more work.

@edrex sorry but I'll have to close this PR.