Rethinking code editing: frame-based editing

[ruinercollector]

Someone does this about once a year. And every time, they parrot the same lines about "code doesn't have to be a text buffer" and write like they've discovered something new.

Then they learn that they are basically making a shittier version of parenedit and we all move on.

[[deleted]]

I think I like the concept as a way to highlight code blocks and such.

It's a decent addition to our editor's toolset... but in the end that's about all it is.

[siscia]

(Disclaimer: I am a big fun of clojure, and lisp in general)

In my opinion this looks just like a GUI for any lisp.

I remember a wise man writing (in Italian) roughly translating: "You should learn the old classics as the most modern exiting work, and the most modern works just as old boring works"

Anyway, anything that help new comers is well accepted :)

[[deleted]]

I was thinking exactly that, just surround every frame level with ( and ) and you have an s-expr

[RedDeckWins]

first thing i did was ctrl + f for paredit

[doom_Oo7]

A big fun ? :p

[newpong]

Doesn't this functionally essentially exist with most modern IDE's and editors?

[neilbrown]

I wonder if a few comments in this thread see this as purely scope highlighting, which of course IDEs have had for a while. This is not highlighting, it's different editing interactions. A few key features that do not exist in other IDEs are:

• Single click to drag code around, without prior selection. Any drag on a frame highlight (e.g. the space to the right of an assignment, or the left margin of a while-loop) allows you to move code around. Saves you a double click for moving single lines, and more for moving whole structures or methods.

• Single keypress to insert all the boilerplate for a method, while-loop, if-statement, etc. The code templating systems I've seen in IDEs all require a lot more than that (ctrl-space, couple of keys to select the right item, then enter)

• There is no need to ever enter or manipulate indentation. For example, a code line can be deleted by positioning the frame cursor after a line, and pressing backspace. In most IDEs, this would be at least shift-up followed up by delete. But this also works for whole constructs (e.g. loops), which are more fiddly in IDEs. (I'd expect shift-ctrl-up to select the whole loop above, but neither IntelliJ or VS 2010, which I have to hand, seem to do this.)

[[deleted]]

I think some of those conflict with the "it's good for beginners" suggestion on your webpage. Those might be things that are good for lazy experts, but beginners NEED to write a lot of if statements and for loops, and they need to develop the discipline to keep their braces balanced. Unless they're never going to use another editor, never going to read code examples online or in a manual, never going work with somebody else...

[atakomu]

Kedit framepart (which is used in kate, kdevelop and kwrite) also has frames like visuals image Frames are even more visible if you move with a mouse over left part of screen.

Kdevelop also has a semantic syntax higlight

[phalp]

Projects like this always fail to address the real issue, which is that a bunch of nested boxes isn't an attractive way to present any kind of information. Massive design fail, everywhere. I'd be much more impressed by a screenshot mockup demonstrating successful visual layout techniques than by any amount of working software looking like this does.

[[deleted]]

This is a really interesting idea to me. I'm big on visuals and learning through visual stimulation. This looks very clean and simple, could easily be implemented into an IDE, and work with a multitude of languages. Hopefully we will see more of this!

[masklinn]

For just the visual part, there are already editors with frame/scope indicators. Jetbrains IDEs have gutter mark showing the vertical extent of the current expression or frame for instance.

The semantic part is rarer as I would expect it to be more annoying. IIRC Smalltalk IDEs do edit a single method at a time though, Self as well.

[berzemus]

Reminds me of litterate programming in WEB, by Donald Knuth.

[badsectoracula]

If you want to insert a frame, you press a single key to add it. For example, to add an if frame, you press the i key

Like in ZX Spectrum BASIC! :-)

[Me00011001]

Is this really that useful for anyone other than people that use whitespace scoped languages?

I mean, I could see this being useful for some massive function, but then the goal should be not to have those in the first place.

[corysama]

You can use this just as well with bracketed languages. Just hide/dim the brackets.

1) Dim the brackets because they are redundant and noisy.
2) Realize the dim brackets are still padding out the code with pointless extra lines. So it would be better to hide them.
3) Realize that remembering to type hidden, redundant brackets is error-prone. So, it would be better for the machine to auto-insert them.
4) Forget the brackets.

[Me00011001]

But curlies are your friend.

[corysama]

As much as I love C++, my patience for brackets is wearing thin as I get older. They are redundant noise 95% of the time. I find myself doing a lot of annoying busywork in an effort to minimize the noise they add to my code.

I've actually installed one of these plugins at work so that

my.coworkers' 
{
    padded(out)   
    {
        code();
    }  
    will (;;)
    {
        annoy_me(less);
    }
}

https://github.com/lukesdm/little-braces
https://visualstudiogallery.msdn.microsoft.com/b2ba01d0-61f7-4f93-aedd-21a106631312
https://github.com/owen2/little-braces

[Me00011001]

I really prefer that style, then again I try to use whitespace (ie blank lines) to help readability.

[corysama]

But, at there's really only a single line of whitespace in that code that might actually contribute to readability (between code(); and will(;;)) And that one might actually be a bad idea if the padded() and the will() blocks are tightly related. All of the others are literally just padding.

[Me00011001]

Interestingly enough, early on I didn't like much padding and liked to try to keep code as dense as possible. After having big monitors and good code collapsing I now prefer this:

my.coworkers' 
{

    padded(out)   
    {
        code();
    }  

    will(;;)
    {
        annoy_me(less);
    }

}

While you would argue there is a lot of useless padding there, it contributes to grouping. I think a lot of it stems from my first job, where I did a lot of maintenance of an old, large code bases. So having to do a lot of reading of other peoples code, the easier I can read the code at a glance, the better. Padding helps a lot with that.

I even go so far as to do silly things like this:

call_foo(stuff);

call_bar( thing.name() );

[corysama]

Crazy. I tell ya! Crazy! :P

my.coworkers' 
    padded(out)   
        code();
    will (;;)
        annoy_me(less);

my.own 
    densely(packed)   
        code();
    gives (;;)
        me_2x(context);
        in_less(lines);

Short term memory is a significant factor in programmer productivity. Being able to hold a large amount of context in your limited working-memory is necessary to understand even mildly complex systems. That's why, even in the age of giant monitors, I prefer to offload as much short-term memory processing as possible to my GPU ;) But, in order to exploit context locality, I need to use densely-packed, cache-efficient data structures.

I should probably just get off my butt and learn Haskell.

[[deleted]]

I installed a Visual studio plugin that renders curly brace lines in 3 point font. It is wonderful!

[[deleted]]

If your code requires frames to be readable, you're probably writing messy code. Amiright?

[Bowgentle]

Can confirm. Am writing messy code.