All,
Here is the “specification” for the behavior of the ‘reindent’ command in ST2:
reindent
Corrects indentation of the selection with regular expressions set in the syntax’s preferences. The base indentation will be that of the line before the first selected line. Sometimes does not work as expected.
That “spec”, even without the final disclaimer, is sufficiently vague as to elicit more questions than it answers. For instance, “corrects” to what?
But at least it does inform you that whatever it does is based on the regular expressions set in the syntax’s preferences.
Frankly, I wouldn’t touch it with a ten-foot pole.
(The settings are called out here: http://www.sublimetext.com/docs/3/indentation.html )
Here is the “specification” for the behavior of the ‘reindent’ command in ST3:
reindent
XXX ??? XXX
Need I say more?
OK. So, if you’re happy with the indentation of your text the way it is, the way you wrote it, why on God’s green earth would you then run an ill-specified or UN-specified command on it, and expect that command to just do what you want done, “out of the box”?
I don’t understand the rationale of applying magical thinking to what is supposed to be regarded as an engineering discipline, and use of the tools thereof.
The command palette “Indentation: Reindent Lines” behavior in ST3 is exactly the same as it was in ST2.
We’ve already covered the deficient state of the specification for this command, so why would anyone even attempt to use it?!?
If someone did find an editor that did have a re-indent command that just happened to do what they felt like it ought to do that day, and that user made that editor their “primary” editor, and invested some sum of money and/or scores of hours in it setting up their toolchain, and then their new client, who uses an in-house home-grown source control or build facility, says they do not accept 4-space indentation and require 3-space indentation, but the new favorite “primary” editor only gives you a choice of 2, 4, 6, or 8 space indentation, and is not otherwise easily configurable, I wonder what that user would do then?
Go look at this page: http://jsbeautifier.org/
Do you see how many options and choices there are? Does anyone SERIOUSLY expect ST to do all that “out of the box”?!?
Give me a freakin’ break.
szimek: (Or Arjan/Kaniken/sinoxer, or whatever you are calling yourself this week…)
Tito has given out a perfectly good suggestion, predicated on the fact that we have one of the most massively customizable and extensible editors on the planet, with a perfectly usable plugin manager that makes it easy to add functionality to get your work done, to do things the way you want them done, but still you insist on some obscure unspecified ‘feature’ working “out of the box” or being “fixed” in a dev build, and work just the way you think it should, or you can’t make it your primary text editor, or you won’t buy a license (for a quarter of the going rate for comparable tools),
and you call it a "bug" if it doesn't?
Excuse me?
Un-flippin-believable.
Now, shanonvl seems to have accepted the advice graciously, some days ago.
But you…
YOU “don’t want to use a separate package just to fix one bug in the default JS package”.
What a load of horse shit.
Do you even have any idea what the Q.A. definition of a bug IS?
A “bug” is a feature that does not function according to the engineering specification provided for it.
Period.
We’ve already established the fact that there IS no valid specification for this “feature”.
That being the case, how can you call it a “bug”?
Oh, wait, I know why. Because YOU are special.
Oh, and by the way, bud, you’re TAB key must be broken. I can hit that sucker all damn day and you know what happens when I do? I get a freakin’ TAB INSERTED and my line is indented. So WTF are you even talking about?
(IF, by some unimaginable quirk of fate or coincidence, you happen to actually NOT be Arjan, then just consider yourself a close enough clone to have drawn ire normally and uniquely reserved for him… and don’t be that guy.)
oldwarhorse