Suggestion: tree view file browser sidebar

[dbkaplun]

No description provided.

[Hunter-Github]

To clarify my 👎 : micro is in a specific market niche as a competitor to nano, not to Atom/Sublime/NeoVim/Emacs. Making it a file manager will lead to scope creep & bloat. It already has a neat file/path autocompletion routine which kinda obviates the need in any sidebar (IMHO).

EDIT no.1 Related: #243
EDIT no.2 If a sidebar is added it will be a lookalike of slap 😜

[ipstone]

I agree with Hunter. Related, if there's a very 'seamless' way of integrating micro with another file browser on all platforms, it would be great.

[CamilleScholtz]

I agree with hunter here, I've always been a fan of the "unix philosphy" (especially the do one thing and do it well rule), and something more extensible, more flexible and more customizable would be to somehow split the view (using tmux for example), and opening micro in one, and something like ranger in the other.

[handicraftsman]

Will be cool if you'll add Projects function to editor. Projects and tree views are greatly combined together. (example - Atom editor)

[mame98]

I think that the bar should be hidden by default and if you press the Keyboard Shortcut, you can toggle the panel and select a file in the tree view. This would be really useful and it would not destroy any market niche as this would be an optional feature. In my opinion this is a feature that nano was/is missing. Another idea would be to offer an optional file browser when you open a file, so you do not have to leave the editor/open built-in terminal if you forgot the path to a file.

[niieani]

I agree with @mame98. I see micro in a slightly different niche than nano / mcedit. It's basically a new niche, one that hasn't been filled yet - there were literally no editors with good UX on the command line prior to micro. Micro is one-of-a-kind. I see it as a very light version of VSCode/Atom/Sublime. Not a full-blown IDE, but a way to painlessly edit some code-bases where a visual IDE is not available.

[ipstone]

@niieani very well stated!

[Anachron]

I agree here, have a toggleable panel would definitely be sweet.

[gordonbrander]

Could this be done as a plugin? That would be a neat way to sidestep the above debate.

[mame98]

@gordonbrander thats a good idea, I agree that this would be a fine solution for both points of view 👍

[NicolaiSoeborg]

Creating a file navigation sidebar as an (optional) plugin is on its way: https://github.com/NicolaiSoeborg/filetree-plugin (micro-editor/filetree-plugin#2)

[DanielPower]

Can plugins currently receive mouse input from micro? If so, I'd like to be able to click on items in the tree view to switch to them. I will try to work on adding this myself, but time is scarce right now.

[NicolaiSoeborg]

I can't see any obvious way to do it, in the current code base.
You can see all onAction()'s here: https://github.com/zyedidia/micro/blob/master/cmd/micro/actions.go

[id777]

I think we don't need another nano editor. What for? Nano is a good itself. It has syntax hightlighting, different settings for each language. Just dig into it, and you will be wonder how many fuatures nano has.
So, make another nano doesn't make sence.

In the same time we don't need something like vim. Editor which can't be used without bunch of personal settings, customization, and plugins. It's not for everyone, and vim takes a lot of time to learn.

What I want to see in micro - it's a command-line sublime text. I want convinience what gives me sublime in console. To use it with Tmux. I want something nice out of box. Not just to edit configs on servers from time to time (for it we can use nano). I want editor like sublime or atom in command line. And this is what I first though when I first time heard about micro. Maybe I'm wrong?

[evanescente-ondine]

Yeah, but one shouldn't have to use full-blown vi or the like, to have the equivalent of a project tree. To have it integrated with a file browser is must-have, since something like ranger should always be at hand and running.

[vviikk]

You can just use the EDITOR env variable and ranger. I think micro should not implement this. Also, if you want this to be a sidebar, I've actually gotten this solution working with tmux. Sorry - but this was two years back and I don't have this code with me.

https://unix.stackexchange.com/questions/82632/tmux-ranger-integration-opening-text-files-in-new-panes

But you can have ranger in the left pane and open up files in micro/any-cli-editor on the right.

Voting to close this issue.

In an case, using ranger to move around and then when you find the file you want, just press l and you're in micro. Should micro implement this? Nah. There's a difference between a text editor and an IDE. If we are about to implement file browsers, then a ton of features that are IDE related (testing, debugging, in build terminal... all seem valid to be implemented)

Another way to easily find/edit files is fzf which I use religiously.

[tomoya06]

Creating a file navigation sidebar as an (optional) plugin is on its way: https://github.com/NicolaiSoeborg/filetree-plugin (micro-editor/filetree-plugin#2)

wow that makes me start to enjoy Micro LOL thanks!

[datdinhquoc]

i <3 Micro

100x faster than Slap

start micro --> ctrl+e --> plugin install filemanager

To launch filemanager when starting micro:

echo "filemanager.toggle_tree()" >> ~/.config/micro/init.lua

[0-st]

i <3 Micro

100x faster than Slap

start micro --> ctrl+e --> plugin install filemanager

To launch filemanager when starting micro:

echo "filemanager.toggle_tree()" >> ~/.config/micro/init.lua

This is very annoying as it hijacks the focus from the editor.

[0-st]

👎 for the idea of integrating a file manager
👍 for the idea of adding a project panel

[jackwilsdon]

How do I vote for neither @Sarkasper? It seems like something a plugin should be providing to me (especially since we already have the filemanager plugin).

[datdinhquoc]

i <3 Micro
100x faster than Slap
start micro --> ctrl+e --> plugin install filemanager
To launch filemanager when starting micro:

echo "filemanager.toggle_tree()" >> ~/.config/micro/init.lua

This is very annoying as it hijacks the focus from the editor.

the command added in file init.lua is optional, u can open filemanager only when u need by pressing ctrl+e and type tree.

actually i don't like the command toggle_tree stealing focus on the document too, i already submitted a feature request to have a command to switch between editor panes so i can switch back to the being edited file.

[datdinhquoc]

i <3 Micro
100x faster than Slap
start micro --> ctrl+e --> plugin install filemanager
To launch filemanager when starting micro:

echo "filemanager.toggle_tree()" >> ~/.config/micro/init.lua

This is very annoying as it hijacks the focus from the editor.

@Sarkasper
i found a solution for not stealing editor pane focus: NicolaiSoeborg/filemanager-plugin#32

basically, instead of just 1 line: filemanager.toggle_tree(), we can add an extra function this way:

filemanager.toggle_tree()

function onViewOpen(view)
  tabs[curTab+1].CurView = 1
end

and we have focus on the being edited file.

[ghost]

So regarding that micro is the first in its field or something like that, i believe there's at least 1 editor like that which is mle(or eon) and how it handles file managing is by using tree command from outside. So maybe that'll help? IMO simple file choosing(not managing) like that would be appropriate enough to not call this bloat but also convenient enough to be integrated as a standard feature. Maybe not as a side-bar (although possible) but maybe on another tab/split.

[franzflasch]

Slap had its last commit in 2016 and I usually don't like backing the wrong horse. So could someone please add a usable file browsing pane which opens files in tabs and keeps open on the side, like sublime does it? In my opinion micro should be a sublime-like editor in the terminal. I don't want a new nano or vim, but I want a usable sublime-like editor in the terminal, without using any additional tools like ranger or something like that.

[ghost]

@franzflasch it is tricky because any modifications plugins can do practically restricted to the current buffer, so split-view can be used to open/close pane since it is in the same buffer, but maintaining the same pane across all buffers just feels wrong. simplify your needs, that is. you can check out another plugin, hopefully it will do the job for you.

[senotrusov]

If you're making a text editor to edit the contents of files, why not have some way to list those files?

I would really like to have an editor that will allow me to quickly fix something in projects when I am away from the main computer, and given that this is kind of a temporary solution, I would not want to build a workflow from Ranger, Tmux and Micro in order to just look at the list of files.

In addition, I'm not sure that for me, or for another person, even if he constructs such a solution, it will be convenient to transfer it to dozens of remote computers where it may seem useful to him.

The beauty of the Micro is that even if the host I want to use it on is completely foreign to me, I only need one command to install it.

In the interface for opening files, which is now available, you should at least roughly know what the file is called and where it is located. I sometimes open parts of a project that I haven't been in for months or years and I don't remember at all what files I can meet there and what names they can have. In this sense, such a simple thing as a list of files helps a lot. It also helps when I need to edit every file in a directory.

I understand that this may cause even more rejection, but I would like to add that searching for the contents of files is, in a sense, also just a list of files, with a little bit of context contained in them. Maybe integrating with tools like ripgrep would add another important way to navigate through files - listing files based on their content rather than the location in the directory they're in.

I understand the arguments against turning a text editor into an IDE, but I think these arguments simply mistakenly hide the issue behind language constructs. The decision to implement any feature of the system can be measured in terms of how difficult it is to implement and maintain, and what percentage of the product's users would be happy to use that feature.

Try using these criteria to compare a list of files and, for example, a debugger for one of the supported languages. Obviously these are very different things. The presence of a debugger turns the editor into a full-fledged IDE, a list of files - I don’t think so.

Besides, you already have a built-in terminal.