Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Prune: A Tree-Based, Home-Row-Oriented Code Editor

facebook.com

Post reply on HN
Print view View original

31–40 of 47 posts

Re: Prune: A Tree-Based, Home-Row-Oriented Code Editor

#31

Post by rtpg »

tikhonj wrote: post #13

An interesting idea that's definitely worth exploring. However, I think the conflict between tree-based editing and normal editors is completely unnecessary. In fact, you can actually get basic tree-based editing today in Emacs! The easiest language to support like this is Lisp because its syntax is about as close to pure tree as possible. And, indeed, Emacs has had structural editing for lisp for a while in the form…

That Structured Haskell Mode (https://github.com/chrisdone/structured-haskell-mode) readme has some very interesting gifs to show how things work.

It's pretty powerful, and I use SHM in my Haskell stuff to mostly good effect. I just have some issues involving the default indentation that I need to get round to fixing, and I haven't figured out how to surround a block with square brackets yet. But otherwise, very good stuff.

Re: Prune: A Tree-Based, Home-Row-Oriented Code Editor

#32

Post by dr_win »

goldfeld wrote: post #17
dr_win wrote: post #8

I've been working on something similar for ClojureScript (Plastic editor package for Atom) https://github.com/darwin/plastic

Wow, cool! Do you plan on making its guts available as a lib to be used under other frontends? I have a ClojureScript ncurses framework and would like to attempt a terminal editor, https://github.com/goldfeld/i9n

The core will be reusable as a javascript library (rendered via react.js). But you will have to provide keyboard inputs, file I/O and other APIs currently provided by Atom/Electron/Node.js.

Re: Prune: A Tree-Based, Home-Row-Oriented Code Editor

#33

Post by duncanawoods »

westoncb wrote: post #22

I've spent a lot of time thinking about the fundamentals of code editing after building this: https://www.youtube.com/watch?v=tztmgCcZaM4&feature=youtu.be... . My main conclusion—which has a lot in common with the Prune editor—so far, came from asking, "what are we really doing when writing code?" and settling with, "selecting and configuring 'language constructs'". I believe this same thing can be done with generic…

Hi - heads-up, your site http://symbolflux.com seems to be down.

Re: Prune: A Tree-Based, Home-Row-Oriented Code Editor

#34

Post by westoncb »

duncanawoods wrote: post #33
westoncb wrote: post #22

I've spent a lot of time thinking about the fundamentals of code editing after building this: https://www.youtube.com/watch?v=tztmgCcZaM4&feature=youtu.be... . My main conclusion—which has a lot in common with the Prune editor—so far, came from asking, "what are we really doing when writing code?" and settling with, "selecting and configuring 'language constructs'". I believe this same thing can be done with generic…

Hi - heads-up, your site http://symbolflux.com seems to be down.

Yep, no money to renew web hosting atm :(

Re: Prune: A Tree-Based, Home-Row-Oriented Code Editor

#36

Post by kctess5 »

halosghost wrote: post #11

Interesting notion. I am inherently skeptical, because, like many I imagine (and as the article actually discusses), I am squarely in one of the text editor camps (which shall remain nameless to avoid anyone thinking I'm intending on a flamewar). I am certainly open to the notion of alternative forms of interaction with code, but too often I see this take on the form of an IDE with “designer-like” capacities (this is…

Out of curiosity, how do you deal with not having some of the things that IDEs support?

I too am firmly in a text editor camp, but I've recently been basically forced to use Eclipse while writing Java (ick) at work. The fact that it knows a lot about the code is invaluable sometimes - auto-importing package names as you type, fixing build rules in other files automatically, code completion, type-definitions that appear with inline usage notes, etc. Granted, enterprise Java in a build environment is the ideal use case for an IDE, but many of those features are useful all the time. Now when I write other code, it feels somewhat archaic that my text editor of choice isn't giving me function docs/typedefs and managing dependencies as I write.

As much as I despise the text editor in Eclipse, living without those things is basically impossible. I have "solved" this problem by constantly switching contexts between my editor of choice and Eclipse, whenever I need to do something crafty. What do other people do about this?

Re: Prune: A Tree-Based, Home-Row-Oriented Code Editor

#39

Post by hellofunk »

A lot of the ideas expressed here are already available in a couple of the better Clojure development setups (known in Clojure as refactoring tools) -- since it is a lisp, that makes it a good language for implementing this stuff. However, in reality most Clojure devs are not taking advantage of all that this style of editing provides, partly because it requires more than the tool: it requires a different perspective on the code you write to think in this "refactor" way.
Post reply on HN