1. 15

  2. 6

    I spent the past few days learning leo. I used it for research and writing, not programming. Some thoughts:

    • The documentation is terrible and the APIs are jank.
    • I haven’t yet run into issues with editing external files, but I’m not collaborating with anyone so can’t speak to that.
    • Node cloning is very, very cool, as is clone-find-all. You can organize and group nodes in several distinct ways simultaneously by cloning them under different outlines.
    • The scripting features are badly documented but seem to be where the power is. You can easily use python to walk outline trees and manipulate nodes from inside the Editor. I’ve found a couple good uses for this, but I’m limited in scope by the poor documentation. A cookbook would really help.
    • Potential use cases: partially dynamic files. One-off templates. File metadata.

    IMO plaintext files are the wrong abstraction level for code and it’s nice to see some steps towards other models of code.

    1. 5

      I used Leo a long time ago, back when I was doing a lot of text editor research, and I’ve got to say it seems like a pointless project.

      Outline editors exist as plugins in nearly every popular text editor.

      Secondly, you say plaintext files are wrong abstraction level for code. But code is just glyphs structured in whatever way the language sees fit.

      Really we need something like an AST-based editor - or search and replace? Code is written as text. But we interpret code as an AST. They are orthogonal so it makes sense for both to exist within the same editor to have maximum power :)

      1. 7

        something like an AST-based editor

        Structure editors are one of these perennial ideas that have been done many times and keep getting re-invented. (The page I linked isn’t an especially great summary, but it does have a bunch of links to examples.) I do agree that it seems like an obviously better way to go… as long as your editor can reliably parse your language. (Some proponents even suggest abandoning text entirely and storing source as binary ASTs, but that’s pretty radical… ColorForth comes to mind, but I’m pretty sure I’ve seen others.) The only communities I know of where structure editors are mainstream are Lisp/Scheme/Clojure, with paredit and its copycats. I’d argue the bar is lower for languages with uniform, trivially-parseable syntax.

        Implicit in the argument for structured editing is that “style” (author-customized formatting) adds little or negative value. I’m not sure I buy that for every language, but I do notice that format normalizers (gofmt, Black, etc) seem to be getting popular, so maybe they’ll pave the way for wider adoption of structured editing in other languages. The LSP may make implementations of these ideas more viable across existing editors and IDEs. Ultimately, it’s a cultural change, and probably a slow one, as people tend to get very attached to their editor setups.

        My favorite structured editor (and language) of the moment is Hazel, but it’s not really ready for prime time. I don’t have any use for Leo, myself.

        1. 3

          I totally agree. I’m sure many of us has heard, seen and used them but currently text still wins I guess because of universality.

          Edit: I just realized, that this is a good explanation for why text will be the ruler over everything for a long time, if not forever. LSPs are just enabling better manipulation of the structures we create with text to a larger audience.

          1. 3

            A good IDE, with solid support for the language you’re using, is basically a structure editor already. Code completion, bracket and indentation creation, comma and other punctuation insertion, the examples just go on and on. I don’t think about text when I write code in a language like this, I don’t have to, the IDE fills in all the boring stuff I don’t care about automatically. However, and this is a good thing, at least in my opinion, the fact that the files are just text means I can easily search them with grep, change them with sed, make quick edits with vim or any other editor, and so on. So I get the best of both worlds already as far as I can tell.

            1. 6

              he fact that the files are just text means I can easily search them with grep, change them with sed

              I think this is less because text is particularly good for these things and more that we haven’t developed equivalent tools that would work. I can’t grep for “foo in the body of a method”, because grep (and the text file) have no concept of what a “method” is.

              1. 2

                Yeah, I guess what I was getting at there is that I can always fall back to these extant programs that need to exist anyway for actual text files, but that I primarily interact with code through an IDE that turns the text into, effectively, a structure I can manipulate without worrying much about individual characters. I didn’t mean that grep and sed are somehow intrinsically important.

          2. 5

            Secondly, you say plaintext files are wrong abstraction level for code. But code is just glyphs structured in whatever way the language sees fit.

            The problem with plaintext files are that there’s no good way to distinguish metadata from actual contents. You can use delimiters, but those are also going to be plaintext and now you have to distinguish “delimiter” from “actual contents that looks like the delimiter”. It’s the same problem with escaped strings, where you have to write "a \"quote\" here" instead of "a "quote" here".

            Use case: I have the call chain f -> g -> h -> i and want to optimize g to get g'. The ideal correctness test to be to run the chain with random inputs with both g and g' and see if they give same results. But if all I have is text, I can’t “represent” the two possible codebases without having both simultaneously and giving them separate function names. And then I have to modify f to call each in turn. Whereas with a higher abstraction level, I could give g' as an “alternate implementation” to g and generate both “files” in turn.

            1. 4

              I won’t lie, your use case flew right over my head.

              1. 4

                Here’s another: I have to add a lot of debug information to a file. With flat text, I have to sprinkle if DEBUG_MODE {} everywhere, which is cumbersome and makes it harder to understand what’s going on. With rudimentary structured editing, I still need that code everywhere, but I can choose to hide them in the editor. With advanced structured editing, I’m turning a tree of nodes into a flat text file. So I can put the debug code in debug nodes, so that when the “debug” version of the code is generated it looks like:


                But if I generate the “production” version of the code, the one that’s actually checked into version control, it looks like


        Stories with similar links:

        1. Leo Editor via jm 7 years ago | 6 points | 2 comments