elastic tabstops
Hi
I think this is an interesting concept which can be incorporated into the editor..
http://nickgravgaard.com/elastictabstops/
Please sign in to leave a comment.
Hi
I think this is an interesting concept which can be incorporated into the editor..
http://nickgravgaard.com/elastictabstops/
Please sign in to leave a comment.
This is wicked!
I look forward to the plugin...
- scott
Is it possible to implement it as a plugin at all?
I could swear, I already asked "what's wrong with the existing smart tabs?", but I cannot find it any more.
Hello Thomas,
That was exactly my own reaction
-
Maxim Shafirov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
"Smart tabs" use ordinary tabs for formatting and add spaces for fine control, thus we get intermixed tabs and spaces, the worst case IMO.
With elastic tabs only single tabs are used. Please spare 5 minutes to try the demo app on the site, it is the fastest way to get the idea.
Hello Konstantin,
Hmm, with "smart tabs" you get consistent indentation with any tab size set
and any text editor/viewer used.
In contrary with "elastic tabs" the text gets buried if viewing in practically
any editor available on earth.
Any practical concern why that's bad?
-
Maxim Shafirov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
Hi Maxim,
There's no ideal solution to this problem, and in our particular project holy wars constantly go on.
Many people use only spaces because this way we get constant formatting in all editors, but we get fixed number of spaces for indentation and if 2 spaces may look OK when using fixed fonts, they become too small when using proportional fonts.
If we will stick to tabs only, we will loose fine control over formatting. Consider this simple example, a method declaration:
void myMethod(int param1,
]]>int param2);
It is not guaranteed that we can get both 'int's to appear vertically justified using only tabs.
OK, now here smart tabs come to scene. Lets use as much tabs as possible, and then fill the rest with spaces. While I see only one problem with both 'only spaces' and 'only tabs' methods, smart tabs has 2 deficiencies:
1. George has 1tab=4spaces while Donald prefers 1tab=8spaces. At least one of them will get wrong alignment.
2. Bill sometimes uses some other editor which doesn't support smart tabs. Say, vim with expandtabs=true. A few edits and the source is full of randomly mixed tabs and spaces with indentation broken for everybody.
To my mind elastic tabs is a good solution provided that everyone uses an editor supporting them, and hopefully most of popular editors will get such support.
Correct.
No, that's not the theorie behind smart tabs. You are talking about "dumb tabs". Smart tabs will produce smart output (. is a tab, best viewed with fixed font):
void myMethod(int param1, ]]>..............int param2);
Wrong. Both will have beauty output.
Thats the killer argument against your suggestion, too. Using an editor which allows to place tabs and spaces manually (and can show them if necessary) also allows to place them at the correct location.
Tom
Correction: . is a space
This feature-- server-side code style on commit while allowing developers personal code style-- would allow every developer to do whatever they please for whitespace personal settings among other things:
http://www.jetbrains.net/jira/browse/IDEABKL-1043
With TeamWare such a feature is now practical. Feel free to vote for it.
Unfortunately, until automated code formatting is much more powerful,
you can't really rely on it--unless your team's guidelines happen to
conform to its limitations or you're willing to compromise your standard
to fit the tool.
Also, don't forget that if the code is reformatted on commit, then the
IDE has to support on-the-fly reformatting when comparing against or
viewing other versions in the repository. And it will make writing or
using external tools or scripts that do those sorts of things basically
impossible.
On balance, it just doesn't seem possible to make this kind of thing
work well enough to be worth the effort to build it.
Jon Steelman wrote:
All the nuances you mentioned and more were discussed ages ago in the original threads.
So you do manual formatting of all your code and everyone on the project follows that standard manually? If you have fully exercised the IDEA code formatting and found it completely lacking, have you entered issues for those shortcomings?
I don't find it "completely lacking." I find it too weak to allow it to be applied wholesale, automatically, as has been suggested in this thread.
My view is that the problem isn't amenable to automated solution in isolation, in a single tool. The whole ecosystem has to agree on a way of applying formatting to program text. We're so far from that it isn't worth talking about, except maybe over beers. I'd love to be proved wrong.
With IDEA and now TeamWare, JetBrains has the whole ecosystem and I have no doubt they have the intelligence and creativity to come up with a sensible and usable automated solution. I will agree that until that combination of tools and without JetBrains, it would seem like fantasy. Afterall, JetBrains established themselves by changing paradigms and having the industry scurry after them. This is another opportunity for them to be the first on something that was up until now in the realm of fantasy.