Vos commentaires

Hm, on second thought, "entity.name.function.python" is not a good choice, as it populates the "goto symbol" panel. "meta.function-call.function-name" perhaps?

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.

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.

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.

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.

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.

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.

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.

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.

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.