Welcome to the Parallax Discussion Forums, sign-up to participate.
cgracey wrote: »
Uh, can we discuss the merits of coding in proportional fonts, instead of monospaced fonts? That should be even more interesting than tabs. I mean, there are a lot more proportional fonts to choose from. And does anyone know if 'Courier New' is really better than 'Courier'?
Roy Eltham wrote: »
I felt you needed that "lesson", because you clearly are missing the issue (I feel intentionally now).
1. In code (which is the context here) you are not really working with fields. You have variable length strings of code, so you either need a very large tab size or you always fail (your case 1).
2. I don't mix tabs and spaces, I use only spaces.
I've had to deal with cleaning up hundreds of thousands of lines of code with tabs that assumed the wrong size in my lifetime of coding. I and everyone I know coding for a living uses spaces instead of tabs for the very reasons I explained in my "lesson" that you dismiss.
re: "tool counting spaces"
The spin compiler doesn't care about the size of the indent when making a new scope (which is what the indenting does in spin), just that it's more than the previous scope indent amount.
You can have your first indent be 3 spaces, then your second be at 14, and your third at 20. It doesn't care at all about the tab stops or any multiple of spaces like you described, there is no rounding up or down.
Rayman wrote: »
I wonder what python editors do...
Use 4 spaces per indentation level.
Tabs or Spaces?
Spaces are the preferred indentation method.
Tabs should be used solely to remain consistent with code that is already indented with tabs.
Python 3 disallows mixing the use of tabs and spaces for indentation.
Python 2 code indented with a mixture of tabs and spaces should be converted to using spaces exclusively.
When invoking the Python 2 command line interpreter with the -t option, it issues warnings about code that illegally mixes tabs and spaces. When using -tt these warnings become errors. These options are highly recommended!
AJL wrote: »
Probably a waster of metaphoric breath to try to make my case, but here goes nothing.
Let's not pretend that the tab key was invented by computer designers. It existed on typewriter keyboards for the very purpose of aligning text between lines and it was set by the user to the size that suited the purpose of the document they were producing.
Thanks for the unnecessary lesson on how tabs work. It only gets messed up in two cases:
1. You select a tab stop value that is less than the largest item in a field;
2. You intermix spaces and tabs; this is a bad idea but you might not notice, others are the ones who suffer the consequences when they open your file in an editor with a different tab stop setting.
Many editors let you select custom tab stop sets. That is the better option IMHO.
Demonising the use of tabs seems like shortsightedness to me.
ManAtWork wrote: »
Another important thing, IMHO:
Save File (and Compile which also does a Save in FlexGUI) should NOT clear the UNDO buffer. It is very annoying if you delete some part of the code just to try something out and after compiling you find out that it's not possible to undo the delete. Save should be "safe" and not mean "forget everything I've done before".
ManAtWork wrote: »
A "recent files" menu would be nice, orr an option to load the last top level file at startup. I often switch between different projects so each time I have to browse through the directory tree.
A navigation list of the file hierarchy (dependency tree with objects and sub-objects) of the current project would also be handy. It allows to quickly open the files you need to edit once the top level file is compiled
Syntax highlightning helps to spot typos and syntax errors quickly. You know it... You edit a part of code and wonder why nothing happens. Then you find out that the whole part was commented out. With syntax highlighting you'd notice this immediately. There are some open source editors with configurable syntax parsers. If this is too much work simple scanning for reserved words, operators and comments would be sufficient for now.
separate background colors for CON, PUB, DAT ... sections. This is unique to the Propeller Tool. It makes the editor window look a bit like a candy shop but I like it. You can scroll through large files and find the section you look for faster.
Roy Eltham wrote: »
This is the coder friendly font I have been using for several months now, it's pretty great and free: https://www.jetbrains.com/lp/mono/