Added support for sorting folders above files.

[cbrown1]

The only issue I am aware of is when building a full path to test whether a child is a folder. I don't really use lua much, and didn't find a function analogous to Python's os.path.join. So as you can see, I hardcoded something but I don't know how portable it is (I am on linux).

I tried to respect your effort to minimize if's inside loops, and the added functionality adds a layer of complexity when reading the code as a result. See what you think.

[sum01]

I don't actually see where this makes it show the full path on files. Am I missing something?

---

Anyways, you shouldn't need to make changes to the get_scanlist() function, as it already saves absolute paths into the tree_view[].

refresh_view() would be a more applicable place to change the disaplayed content, as it uses get_basename() (which uses Golang's basname) on each filename when building the displayed file tree.

I suggest skipping the get_basename() call here if you want to show the full paths.

I also personally think the filemanager-foldersfirst option should be false by default, as it's not the current default behaviour.

---

And for future knowledge, to join paths in a portable way, you need to use JoinPaths(dir, filename), although it's not needed for your proposed changes.

JoinPaths() is provided by the Micro plugin API, which internally calls Golang's join function.

[sum01]

I just now realized you meant this to show directires above files. My bad, I need some coffee...

[sum01]

I think I agree that it's a bit annoying to read for minor speed improvements. I decided to time it and the difference between running the if's or not was 0.001 second on a 100000 item list, at least for my machine.

I'll most likely merge this & turn it all into 1 loop with some goto's as continue statements, unless you feel like doing it.

Just make sure to change to using JoinPaths() like my first post mentions at the bottom.

[sum01]

What is the "problem opening files" you mentioned in the last commit?

[cbrown1]

I get the following error when I try to open a file (tab key):

filemanager:563: attempt to call a non-function object
stack traceback:
	filemanager:563: in function 'try_open_at_y'
	filemanager:1157: in main chunk
	[G]: ?

Press enter to continue

Any ideas?

[sum01]

Indicies start on 1 in Lua (unless you specifically create a zero index). This is (probably) what's causing the issues with try_open_at_y, as when it goes to access it, it gets a nil value.

Change that 0 to a 1 & I should be able to merge this.

[sum01]

I would test this myself, but for some reason the nightly bin won't launch for me. If someone else is willing (@tommyshem @NicolaiSoeborg ?), pull his remote, fix the attempt to access a nil value, and see if this PR works 👍

Otherwise you'll be waiting on me to get Micro working.

[tommyshem]

Tested on Mac as is and it works. Not sure what the fix access nil value is?
Can you give me more info on how to cause the nil fault?
Does it need testing on Linux ?

To get the latest micro I just pulled it from GitHub and built it with make build-all and run from the go build directory.
My path is ~/go/src/github.com/zyedidia/micro
run ./micro

I don't use micro editor much now as using vscode with plugins but willing to help test with more info.

[sum01]

@tommyshem This #33 (review)

The fix is just changing the 0 to a 1 (and then testing the opening of a few files).

And yeah, I haven't personally been using Micro for a while now either.

[tommyshem]

Tested on Mac
micro --version
Version: 1.4.1
Commit hash: 1856891
Compiled on August 10, 2018

and nightly version

./micro --version
Version: 1.4.2-dev.11
Commit hash: 6140dab
Compiled on August 21, 2018

I have not changed the 0 to 1 (original pull request) and I can not get it to crash with any errors it opens the right files.

Tried in different directories and different files and can not get it to crash on Mac.

Is it related to #28 fault with micro 1.4.0

[sum01]

So I figured out how to get Micro working, and debugged a little bit.

It turns out Lua is preventing an error here, which makes me curious why @cbrown1 even got errors.

---

This code does assign a nil value, but Lua "throws it away" since he used the length operator #, which stops on nil values. Thus the same index is assigned twice, since the first time it's nil, and the second time it will assign an actual "useful" filename/object.