Thoughts on Editor Formatting

For a few decades I have had some ideas on what I’d like to see in an editor. I’ve also revised that and added to it over time. Some things I’d love to see in all editors include (but it might as well start with Codea):

  1. Half-height display of blank lines.

Why? Because UI experience in the last twenty years has demonstrated the value of “white space” (less is more). I make great use within my own code of blank lines between code blocks to help the developer-reader distinguish blocks of related code. But that also wastes a lot of screen space. I’d like to use white space to separate blocks of code, while being a little less wasteful of limited screen real estate. It would also be useful to separate code with varying lengths, depending on relative logical connection, like a 1/2 line or full line or 1 1/2 lines… the worst I’ll do now is one line versus two lines, or two blank lines with a one-line comment in between.

  1. Faded borders around logical code blocks.

Why? For decades (which seem like eons), programmers have used indentation (a manual workaround, maybe the first “hack” ever in computer programming) to distinguish “if/then” and loop code blocks. As time went on, editors added different colors for reserved words like “if” and “for”, and automatic indentation (which can be purposely or accidentally defeated, but mostly works).

But what I’d love to see is a very faded, almost barely visible border drawn around each code block (particularly for longer blocks, which are bad programming style to be avoided, but still always happen):

+---- if condition then -----------+
 |               print("Yes!")                       |
 |         +--if other condition then -+ |
 |          |        print("Yeah!")              |  |
 |          +--end-----------------+ |
 |---- else ----------------------|
 |                print("Nuh uh")                 |

Caveat: This is the kind of idea that might look great in my head, but in practice may just clutter the screen, and can be hard to do (like handling special cases, what if a developer puts an if statement all one line, like:

 if true then print("true") else print("false") end
  1. Colors by type of variable

Okay, this does exist in many editors, just not Codea, but I’d like to see another color (or, if we’re running out of colors, a font style like bold or italic) IF the syntax reveals that a particular variable is a parameter versus local variable versus global. That can be tricky, because the editor will need some low level of syntax evaluation to figure that out, which is a lot of work for an editor. Other environments do do that (like XCode, Eclipse, IntelliJ) But it’s a really, really useful feedback to see that a variable has NOT been defined as local (you forgot to do it, which can cause really bad, hard to find bugs), or that it was passed in as a parameter.

But, as I said, doing this could be really tricky, so not a requirement…

@blacatena Everyone has their own coding style. For me 1 blank line between functions or ever groups of code is sufficient. The normal indentation that Codea has now for ifs and loops is fine. As for colors for different key words, I find that more annoying than useful. An example is using the DARK theme which colors things. I find that hard to use so I’ve don’t used it. What I find important in an editor is how it functions and how easy it is to use. I’m not after pretty, but functionality.

I think before I asked for those features, I’d ask for code folding: click the > by a block and fold/unfold that block.

But what I really need is a better way to manage tabs. My Dungeon program has 51 tabs, 90 classes, almost 900 methods. Yikes. Takes me all morning to scroll from one side to the other.

Oh, and there’s an idea: when I use find to go to a function in a given tab, slide the tabs so that that tab is in view.

And, B, a “go back” after find.

@RonJeffries - on the same page as you with collapsable/expandable functions, mentioned this a few times. I find the editor a little messy nowadays with odd things happening occasionally more often with indentation positioning. I still think there is room for improvement there.

Having said that - I still keep plugging away with it, despite my free time disappearing. I think Codea is an excellent package - long may it continue to be so.

Yes, I really like it too.

code folding +1

If Codea supports code folding, it can be useful for projects with medium to large amounts of code, helping to rescue us from the details when needed, and providing a more complete, large scale view of the entire code.

I have a guess, just a guess, that developers might be concerned about the performance of the editor, such as the inability of the editor to respond immediately after a lot of code folding.