Sort numbered files/folders in the sidebar correctly

I too would like this sorting behavior in Sublime.

The Mac OS X Finder does sort this way:

Sublime currently sorts this way:

At work we have one large folder with ~1000 files named like this (because of, you know, reasons) - having a natural sort order of those would indeed make life a bit easier as 1 and 2 wouldn't be separated by 10-199 . :)

Oh, and it makes a lot of estetic sense, too.

I am not sure it is ST's role to compensate for poor file naming decisions.

I would far rather that ST maintains normal string comparison behaviour than try to get clever and put things were I don't expect them. One glitch or hard to understand sorting decision in sorting file names would be far worse for me than maintaining current behaviour which is logical and easily comprehensible even it sometimes exposes annoyances when it highlights poor naming decisions by humans or tools.

Padding file names containing numbers with zeros to allow correct string comparisons is the cross-platform, cross-tool, universal solution here. 

If one of your human colleagues doesn't understand how string comparisons work here is a chance for them to learn a valuable lesson that will pay them back many times over.

If some tool is automatically naming files in a pattern that prevents correct string comparisons then I think the problem lies with that tool rather than with ST.

You are incorrectly assuming that it is always within possibility to mass-rename files to make them lexicographically sortable. This is certainly not always the case as developers not always have full control over projects they need to work on, or the file naming schema depends on some external facility outside of the developer's control altogether. Also, zero-padding filenames could lead to the necessity to mass-rename a large number of files when their sequence overflows their existing padded field length, which would get exponentially more expensive with each order of magnitude reached.

No I am not assuming anything of the kind.

For all the very good reasons you give renaming is very often far worse than just putting up with things as they are.

We are in furious agreement on everything you said.

But the next time we are designing a new scheme let's not make the same old mistakes like failing to pad numbers in file names. Let's make new and more interesting mistakes.

Why would we have to put up with things as they are? If everybody did that, ST wouldn't even exist in the first place. Every tool exists to solve some problem and to make our lives easier. We don't change our work to match our tools, we change our tools to match our work.

"We don't change our work to match our tools"

Yes we do. Work changes to match the available tools all the time.

"we change our tools to match our work"

Then waste no more time seeking my approval. Go implement the change you want. Show us all how much better you implementation is and how it has improved people's lives. Nothing succeeds like success.

This attitude can be applied word-for-word to absolutely each and every feature request here on Userecho, and not just for ST2. The position that nothing should be changed and everybody should instead "go implement the change [they] want" is a true gem; you're essentially saying that instead of asking for a trivial sorting change, everybody should go build their own IDEs from scratch. This makes so much sense.

You are twisting my words wildly to make them fit what you want me to say.

It appears that you think arguing here with me is going to get you what you want. I think that is not as likely to work as the positive action approach that I am suggesting.

But you are free to take whatever approach you like and I wish you well with the 'argue with people on the internet' approach to seeing the change you want realised in the world. It does work sometimes and I hope it works for you on this matter.

1 - 'Normal' sorting. Well yes I agree there is no more meaning to 'normal' than to 'natural' in terms of sorting. But that's not what I said. Read carefully to get full meaning. The phrase being used is 'normal string' sorting. So I am referring not to 'normal' but to 'normal string'. Does taking the words I am using in context make my point clearer? Do you agree that there is a clear and well understood set of rules that have been in place for decades on how strings are to be sorted? They may be crude and brutal and arbitrary and even annoying but we all know what they are without thinking about it very much. There are no real surprises there and the fewer surprises my computer presents me with the happier I am.

2 - I wonder what you think 'natural number sorting' is and is not. What is natural for you might be natural for me but not for someone else. What about RTL languages, what about, what about. I am happy to stick with the well understood behaviour of how string sorting works to avoid any clashes with whatever each person might consider 'natural' and 'unnatural' (whatever those terms mean). String sorting may well be arbitrary and annoying and all those sorts of things but a simple, clear and deterministic set of well understood rules is my preference over getting 'cute' with more 'clever' schemes. 

3 - "Can you come up with a scenario where natural number sorting would result in sublime sorting incorrectly, but lexicographical sorting would not?" Yep here are two very obvious cases:

    1 : any case where what you think is 'natural' i think is 'unnatural'

    2 : any case where the attempt to apply one or more 'clever' 'natural' sorting algorithms has an implementation bug - I have huge respect for Jon but he is human and is therefore capable of coding a bug.

Neither of these cases apply if we just accept the arbitrary constraint of using the raw string sorting of the base language. And as a bonus we don't cruft up the ST code with junk.

Anyway I think we have both made our positions clear and I certainly think yours is a position worthy of respect. I don't think it is stupid or anything like that. It is just that I strongly disagree and hope very much it is not implemented.

Just about every single requested feature can be rejected on the basis that developers are human and new features carry the risk of introducing new bugs. That's a bogus argument.

Okay, in your reading cross that one off the list.

I assume the rest of my points are worthy of valid consideration in your opinion?

Not really.

> Do you agree that there is a clear and well understood set of rules that have been in place for decades on how strings are to be sorted?

> I wonder what you think 'natural number sorting' is and is not. What is natural for you might be natural for me but not for someone else.

No. There are many ways to sort strings. Yes, there is the naïve lexicographical sort by raw Unicode code point that you're supporting; then there is locale-aware lexicographical sorting — alphabetical order varies between languages, so if you want things properly sorted in alphabetical order, you will need to use a collation specific to your language, and you can't rely on the naïve numeric values of the characters. Then there is the natural sorting order, which you can read more about in this essay by Jeff Atwood. It is not called natural because the other sort orders are somehow unnatural; it is called that, because it makes most sense to humans. You might be surprised if your editor sorts your files in natural order, but most people (programmers aside) are routinely surprised when some programmer somewhere has decided that "this is the one true sort order" and has decided that the ordering "1, 10, 2, 3, 4, 5, 6, 7, 8, 9" makes sense for everybody.

> What about RTL languages, what about, what about.

This is a non-issue. Numbers do not change direction in RTL languages (2013 is still 2013 in Hebrew, it is not 3102), and language directionality is a purely presentational concern — the string itself is not in reverse direction, it is only typographically rendered in reverse direction.

> any case where what you think is 'natural' i think is 'unnatural'

This is also a non-issue. I find tab-autocompletion in a programming language very unnatural, because tabulation is routinely used for code formatting; still, I'm not trying to get it removed from any and all editors just because it clashes with my personal preferences; I can turn it off in my preferences, move on and forget about it.

> It is just that I strongly disagree and hope very much it is not implemented.

I really can't see how not implementing a feature that has eight time more positive votes than negative can be good for anyone. You're very entitled to your opinion that natural sort order is not necessary and that you find it "unnatural" and that you don't want to use it; you're not entitled to argue that nobody should get it even if they genuinely want it.

8 vs 2 is technically a multiple of 8 but you are grasping now aren't you.

So if 16 more people voted this down you would see it as being good to not have it implemented? Surely not. You want this feature don't you? 

So even if 50 people voted it down you wouldn't suddenly go 'Oh I must have been wrong. My personal opinion is worthless in the face of a number of people who wouldn't fill a medium sized room clicking on a button showing they disagree with me.'

You have your opinion. It's valid. It has support. It is worthwhile. Let that be enough as far as opinions go.

Now take action beyond talking. I have the easy path here because I am arguing for 'no change' so there is no work for me or anyone else to do. Those who are want change now need to take action to implement the change they want. Take up the challenge, go do the work that needs to be done to improve the world in the way you want it improved. 

Good luck and may the road rise to meet you.

Aren't you thinking about 16 vs 2, because that's what I'm seeing in the vote box? 16 positive votes are certinly eight times more than the 2 negative votes.

And no, if 50 people voted it down I'd say "oh well, apparently this feature is not that important to many people, so I can't expect to have it implemented just for me". You, on the other hand, see that just a medium-sized-roomful of people have supported that feature, and your active position is that it MUST NOT be implemented, disregarding the fact that you have only one other vote besides yours defending that position.

ST2 being a closed-source commercial project, I can't really understand what you're talking about with your "go do the work that needs to be done" argument. I don't mind contributing, when it is made possible.

"Aren't you thinking about 16 vs 2, because that's what I'm seeing in the vote box? 16 positive votes are certinly eight times more than the 2 negative votes."

Yes those is the facts and we both agree that they are the facts. Not sure why you are restating them but there's something we agree on. The votes are 16 up 2 down. No more to discuss there.

-----

"your active position is that it MUST NOT be implemented"

Nope. My position is that I don't **want** it implemented (especially not when there are a lot of things not yet done that I **do** want). It is just as valid for me to say what I want as it is for you to say what you want. Neither of us is saying the other is **wrong** in some ultimate sense are we? We are just expressing preferences. That's fine and healthy.

If you have some belief that my opinion in here carries more weight than yours and that I can block your idea or work then you are granting me unwarranted powers.

----

"I can't really understand what you're talking about"

Well here a few ideas to think about:

- Is there an existing Python 3 library or module that implements what you want to see?

- If there is an existing library/module what is is its name?

   - Now go test it in a simple harness and demonstrate that it is reasonably bug free and implements the change you want in an effective and efficient manner

- If there is not existing code then you have the freedom to write, test, debug, document and publish one. And then lobby here for it to be implemented either in the core of ST or as a plugin or package (not sure how a plugin/package would work but that's for those who want change to research to see if it can be done).

None of those require access to the ST core code. You can test the behaviour of sorting code as a standalone task.

In any situation in life you can help your cause best by doing as much of the initial work as you can. The easier you make it for others to give you what you want in life the more likely you are to get it.

There are other non-code idea like building up a positive community around the issue, documenting the requirement, documenting the algorithm you want to see implemented, etc etc.

You have a valid idea here. I disagree with you but don't let someone (or 16 or 50 people) disagreeing with you turn you away from something you want to do. Just take the active steps to make the change you want to see happen. I wish you well on your journey.

Here you go: http://ideone.com/W0HUe

This, of course, is completely useless, as the Python API does not expose the sidebar contents (except for the list of top-level directories, but not their contents), and certainly does not expose any mechanism for sorting it. A Python implementation of the natural sort algorithm would be completely useless in this case, as the sorting is obviously implemented on the C++ side, which is closed-source; jan otte could have known that, if only he bothered to figure out what he's talking about.

Keep poisoning the thread with vitriol and hatred and the chance of anyone wading through it all reduce all the time.

I never suggested you would be able to simply drop in some code and have the sorting changed. I am not an idiot, no more than you are. Did I not say you would be looking at testing your code 'standalone'.

So are you happy that the code supplied by Matthijs van der Vleuten is the sorting algorithm you want to see implemented? If it is then that is wonderful. Now do (or extract) the testing and the documentation details and check if there are any licence restrictions and as much of that prep work as you can and do as much other stuff as you can so that if Jon decides to implement your requested change it is as little work for Jon as you can make it.

The cheaper you make the change for Jon the more likely it is you will see it implemented. I really don't think I am saying anything other than the completely obvious. How you are getting yourself into such a state of unpleasantness over it is beyond me.

You apparently don't realize how trivial a change we're talking about. It's like I'm asking somebody to lend me $10 and you're saying I should first register with the government as a banking institution.

If it is trivial to to implement then it should be trivial to document the requirements in a positive constructive way.

I suspect you are right and that you have already put more, words, time and energy into arguing with me than it would take to take the positive road and lay out your idea in a formal or semi-formal manner.

There are issues to be addressed like whether A1 sorts before or after 1A. What is the 'natural' way? How about 110.b.123 and 110.1.123 and 110.1b.123  and 110.12.123 and 110_1b_123? How about 123a and 1234 and 123.1? These sorts of things may be so obvious to you that you consider they go without saying but setting them down clearly can do no harm can it?

Again I am not suggesting addressing these implementation details are huge hurdles and they may even justify being called 'trivial'. Again if addressing them is trivial then there seems to be little reason not to address them.

Anyway, I wish you well on however you decide to progress with this.

Cool. A positive and constructive contribution. Nice work!

1 - That's why I asked if there would be a case where natural sorting would produce incorrect results compared to lexicographic ('normal') sorting.

Regarding the term 'natural sorting': it's how this way of sorting is commonly described.

Regarding your happiness: surely this way of sorting could be disabled in your settings.

2 - Sure, there may be natural languages that use a different system to represent numbers that won't be accomodated by natural sorting. I don't think that should prevent Roman numerals from being sorted this way.

Regarding your last sentence:

Simple: perhaps for computers. Sublime is an editor for humans. Most humans consider the string '9' to come before the string '10', because those strings are representing numbers.

Clear: numeric parts of a string are compared numerically. That doesn't sound unclear to me.

Deterministic: why would it not be deterministic? Sorting would always result in the same order.

3 - That's a vague "anything that's different is wrong" argument. Can you come up with a concrete example?

Regarding bugs: anything can contain bugs, and bugs can be fixed.

If this is as easy for you to implement, including features like "surely this way of sorting could be disabled in your settings" then I invite you to go implement it along with settings to turn it on and off at will.

Let us know when you are done and have proved me wrong.

Oh, I'd love to help too! Since you're so generous with the invitations, I'd like if you point us in the direction of the public repository of ST2's code.

Read my response to your other post. 

You do not need access to the core ST code to make active constructive progress on this issue.