Implement missing actions: open_entry, open_all_entries, close_all_entries.

[dinhhuy258]

Accoding to @RaafatTurki comment:

I've figured since we have "folding" in sfm we would want the entry related actions to match the actual features provided by n/vim for text folding:

is_implemented	action	equivalent text fold shortcut	description
yes	close_entry	zc	close a fold
no	open_entry	zo	open a fold
yes	toggle_entry	za	toggle a fold
no	close_all_entries	zM	close all folds
no	open_all_entries	zR	open all folds

open_entry mean to only expand the dir or nested file without attempting to edit them.

[dinhhuy258]

The actions.lua file are getting bigger now.
Should we consider categorizing actions in different groups? (please suggest group name)

navigation

edit                 
vsplit               
split                
tabnew               
close_entry          
toggle_entry
first_sibling        
last_sibling         
parent_entry         
change_root_to_parent
change_root_to_entry 

fs

create               
copy                 
move                 
delete                       
toggle_selection     
clear_selections     
trash                          

explorer/misc

reload               
close     
system_open

[RaafatTurki]

I agree, that file is getting quite large.
I would divide them further to something like:

core:
  edit
  reload
  close
  toggle_selection
  clear_selections
  change_root_to_entry
  change_root_to_parent

nav:
  first_sibling
  last_sibling

layout:
  vsplit
  split
  tabnew

nesting OR folding:
  close_entry
  toggle_entry
  parent_entry

fs:
  create
  move
  copy
  delete
  trash

misc/os:
  system_open

what do you think?

[dinhhuy258]

Hmm. It sounds good, but there is something that is not right.
For example:

• parent_entry: Move the cursor to the parent directory It should belong to nav
• toggle_entry and edit: These 2 actions share the same behavior if the entry is a directory but it's in a different category.

[RaafatTurki]

You're quite right. this brings forth an another point. I think the action system needs a bit of work:

Right now some of the actions are "fat" (they do more than what they say they do)

side note: perhaps the actions open_entry, close_entry ... etc, should be expand_entry, collapse_entry .. etc for less vagueness.

For example edit doesn't just "edit" a file, it also expands a dir, so it really should be edit_or_expand_entry which tries to edit_entry first and if fails try expand_entry

So ideally we should have very basic and minimal set of actions that do one thing only.
and compose larger actions using a chaining logic such as:

M.edit_entry = function()
  -- return false if current entry isn't editable
  -- return false if editing the current entry has failed
  -- return true if editing the current entry has succeeded
end

M.expand_entry = function()
  -- return false if current entry isn't expandable
  -- return false if expanding the current entry has failed
  -- return true if expanding the current entry has succeeded
end

-- a function that takes any number of actions, tried them in order until one of them succeeds
function M.chain(...)
  -- return true if any of the actions succeeded
  -- return false if all of the actions failed
end

M.Actions = {
  edit_or_expand = M.chain(M.edit, M.expand)
}

This gives the ability to both us and the users to compose custom actions very easily.
Also I'm willing to work on this PR.

[dinhhuy258]

side note: perhaps the actions open_entry, close_entry ... etc, should be expand_entry, collapse_entry .. etc for less vagueness.

Yes, we should rename these actions to avoid confusion. The idea of the action name (edit, open_entry, close_entry...) was taken from the nvim-tree plugin :P .

So ideally we should have very basic and minimal set of actions that do one thing only.
and compose larger actions using a chaining logic such as:

Amazing idea., it will make the code more readable and extendable.

Also I'm willing to work on this PR.

Thank you very much, I am looking forward to seeing your pr..