I think this is a good idea to allow tabulation symbols for indentation blocks.
When i write code in text editor, the indentation with two spaces is little noticeable, the indentation with more spaces is more noticeable, but if i need 3 or more levels of indentation, writing 12 spaces takes too much time. And pressing 3 times tab key takes normal quantity of time + the indentation is well noticeable.
Maybe allow the indentation with tabulation symbols and forbid mixing them with spaces like this is made in Python?
For me, a Nim-friendly editor converts tabs to spaces, or auto indents on new-line.
There are other benefits like code-suggest features, but it is up to you what tools you use ;-)
Thank you very much for '#? replace(sub = "t", by = " ")' ))
Really I think that it is a bad idea to forbid tabs because 'not to risk the mixing of tabs and spaces'. There is no any risk if you are not mixing tabs and spaces, if you are mixing them - error will be anyway. Maybe it was better to add a compile option --allow-tabs or something like that...
I Write in Python 1 year, there was no any incident with mixing tabs and spaces. I do not use IDE, i use gedit - text editor with highlighting syntax.
But if there is a way to correct this, than it is good. I hope that code from first line will only replace those tabs, that are used in indents, not those tabs, that are using in strings =)
Afaik it will replace all tabs you have in your text. You use "t" normally to represent them.
Talking about "tabs" ... I feel like some people don't know what "tabs" really do. They tab"stop" at specific columns. Most systems/editors have "predefined" tabs these days. But for real they can be arbitrarily chosen. Like a TAB at column 4 and the next a column 10. A tab has no "specified" width itself. Actually a tab can result in 1 to tabwith "spacing" in the result. They are used to line up data.
Using tabs in the editor is something I do in some languages all the time but never "raw" inside strings! And I complain about every system which does not "agree" on my view of tabs width (looking at you github.. caressing my greasemonkey script to fix it). But I really know better :)
'''Afaik it will replace all tabs you have in your text''' Oh, no... and if i'd had code like such:
a = Gtk.Text
a.write('text \t text \n text')
Then i'll have problems =)
I need to say, that the syntax of Python satisfies all my desires on the current day ))
@OderWat, ok, thank you. I am reading the manuals of this language and resenting if I don't like something =)
I think than Nim is in any case better than clean C or C++ for me to write modules for Python =)
I'll try to get used ))
https://news.ycombinator.com/item?id=4623781
Are all of you using only fixed width fonts? I know most people do, I have never really understood why.
With proportional fonts unfortunately 2 spaces generate a tiny indent step. So I have to use 3 or 4 spaces, or finally a tab! I think I will do the later with the replace command mentioned above. The only disadvantage is that github puts 8 spaces for each tab, so I have to convert files before uploading to github.
Allowing tabs means "allowing mixed" because TABs are what the are. They are not "4 spaces in the package of one \t" they are meant as stops at fixed positions starting from 0 and if you use a Tabstop of 4 and you use indentation of 2 you will have 1 tab and two spaces in front of your text at indent level 3.
Allowing \t to let uses choose how their indentation width is, makes probably sense if you only allow tabs and no spaces but not if you allow both (mixed or not).
So if you really want to allow tabs the Nim compiler needs to know the tab width intended to be used. This would complicate the parser I guess but would be possible as preprocessor which converts the given tab size to spaces before continuing with compilation. That would be even transparent imho (as for example the columns position would stay the same for error reporting).
To me this boils down that there could be a source-code-filter which gets a tab-size and does the correct tab transformation on the source. This way everybody who wants can use tabs in his sources and Nim itself does not need to change anything besides the inclusion of such filter.
I guess a PR would maybe go through :)
Hi. Looks like this conversation is long dead, but I wanted to add my take. I'm new to Nim, just started learning it recently. Respectfully, this debate drives me nuts! I've read arguments for and against tabs and spaces, many are well thought out, some, not so much.
The bottom line is this. Compilers were originally created to bridge human readable text and machine language. Every compiler has been written to improve this bridge. In other words, compilers are designed to make coding easier for the coder, not the computer. While there are some ways the person must adapt to the compiler: punctuation, word choice, etc., when a choice is between the human's ease of use and the computers ease of parsing, the human has historically won out when possible. If not for this, we'd all be expected to write in assembly, or worse, binary.
As has been written, there has been a tabs verses spaces debate for decades. As there is no clear majority, why not make life easier for all.
We have several examples to learn from, but here's one. Henry Ford used to produce his cars saying: "You can have any color you want, as long as you want black." When other manufacturers began releasing cars in other colors, Henry was forced to change his attitude. In other words, if Nim doesn't offer what the people want, they will go to a language that does. This is quite a disservice to Nim. New as I am, it seems like an awesome step forward. It seems that Nim would soon out-python Python.
The dispute seems to be mostly that mixed tabs and spaces make for challenging code. I think its reasonable therefore to require one or the other, but only at the file level. This way, each person on a team can do what make them feel most productive.
I have done my best not to say which I prefer. The reason is that it doesn't matter. I guess its obvious I like tabs, else why would I be here. Forcing people to use one or the other, for no other reason than, "That was what we felt was best," makes little sense, as some clearly feel otherwise.
Finally, suggestions have been made to either reconfigure the editor, use find/replace, etc. Which is more performant, a thread or a process? Threads share resources, and are therefore quicker to spawn and require less resources from the machine. It seems unreasonable to require umpteen people to change their way of coding, IE creating processes, rather than making the change in one place for all to use, threading.
As I wrote above, I'm new to the language, maybe this has been fixed, but the tutorial says otherwise. Either way, thanks for reading.
Bonus rant, someone wrote above that tabs are used to tabulate data. What is a program if it isn't lists of data? Someone also wrote that Nim would have to know how many spaces are in a tab. If mixing is not permitted, why? Nevertheless, here's the answer. One tab = one indent level. The standard says two spaces are one indent level. If a = c and b = c, a = b, one tab = 2 spaces = one indent level.
Again, thank you for reading.
What is a program if it isn't lists of data?
It's a tree. Glad you asked. ;-)
Seriously though, the problem is this statement
As there is no clear majority, why not make life easier for all.
as it's not true. It doesn't make life easier for people who develop in teams using various different editors and different programming languages. Or for people like me who occasionally read code written in different languages.
Soon somebody will use tabs for Nim and because there are plenty of non-Nim files that I have to open, some of which use a "compression" technique where indentation is 4 spaces but 8 spaces are compressed into a single tab (no, I'm not kidding, this is quite common for reasons I will never understand) every tab has to have the width of 8 spaces, wasting a lot of screen space making my life more miserable.
Now you can say, "no problem, the editor's tab setting should be language specific!" to which I say, "look, if smart editors are the solution, why not use one that inserts spaces when you press a tab"...
The bottom line is this. Compilers were originally created to bridge human readable text and machine language. Every compiler has been written to improve this bridge. In other words, compilers are designed to make coding easier for the coder, not the computer.
Clearly you haven't seen the C++ compiler. ;) (I mean, a C++ compiler, because that language doesn't even have a standard implementation.)
As has been written, there has been a tabs verses spaces debate for decades. As there is no clear majority, why not make life easier for all.
Nim makes life easier for all by ending this pointless debate for them and allowing them to focus on more important stuff.
I have done my best not to say which I prefer. The reason is that it doesn't matter
If it doesn't matter as you say, then why rant about it ? Choose one,and be done with it. Consistency across codebase is more important than the space vs tabs debate.
A simple way to check if your view is worth it, you can try to implement mixing tabs and spaces in toy compiler Nim0. You only have to look at the 5 ossIndentXXX procedures that manage syntax indentation for the compiler. The algorithm there is probably simpler that the one used in Nim, but if you manage to write a source file that mixes tabulations and spaces for indentation that the compiler and your editor are happy with, it will base the discussion on real code.
At the present time, it was easier to select a simple rule (no tabs in Nim source) than lose time on vaporware discussions, even if some users think that a better solution exists.