Leap technology instead of tens/hundreds of commands/operations/...

[dumblob]

After seeing your videos and reading the rant on "text" (programming code) editors, I can see that the AST editing experience tailored for the underlying syntax/language/... leads to an excessive amount of commands/operations/... the user needs to learn first. It feels even more difficult than plain vi bindigs.

Therefore I dare to propose adopting the "Leap technology" as the way to lessen the amount of things to learn.

Thoughts?

[kneasle]

Leap does look fairly cool, but I can't really see how it's any different from / and ? in Vi. / searches forward in the document whilst jumping the cursor to the nearest location of the string specified, whilst ? does the same but backwards in the document. Both are incredibly useful and I use them a heck of a lot whilst programming, and they seem to provide the 'leap keys' but on a normal keyboard. The only thing they don't seem to be able to replace is the ability to 'leap' words into other locations, but it's never explained how that actually works so I don't feel qualified to shed light on whether this exists already in Vi-derived editors.

I would also like to remove the requirement to have a cursor at all (there doesn't seem to be a reason to have a cursor in existence the whole time).

I also disagree with the opinion that AST-based editing necessarily requires an obscene number of commands. True, some commands will need arguments (you need to know what AST node to insert, for instance) but I don't see this as extra complexity, particularly if Sapling were to provide a list of all the possible options and their keystrokes (like how intellisense/autocomplete works today).

I'm also confused by the fact that, despite looking like a great system and coming out of Apple, it is still basically unknown 30 or 40 years later. That YouTube video seems like the only reference to it that I could find.

This would make a good plugin for any editor (Sapling included).

[dumblob]

Well, I meant rather the ideas than the specific Leap implementation (which among other things requires a special keyboard 😮). Traditional mouse & text cursor (its movement, selection, etc.) is too fine-grained (too low level - imagine most generic "assembly" called Brainfuck 😉). AST on the other hand is quite coarse-grained (imagine high-level assembly like Fortran which with its hundreds of keywords feels like a dictionary of best practices rather than a generic solution).

Leap ideas seem somewhere in between (still manageable number of commands, but high versatility). Extending these ideas could make it usable for new stuff like JSON which didn't exist at the time Leap was "invented".

The only thing they don't seem to be able to replace is the ability to 'leap' words into other locations, but it's never explained how that actually works so I don't feel qualified to shed light on whether this exists already in Vi-derived editors.

No, by default vim/neovim/vi does not provide this functionality.

I would also like to remove the requirement to have a cursor at all (there doesn't seem to be a reason to have a cursor in existence the whole time).

What do you mean by a cursor? Is it some form of a mark where some last operation (e.g. edition) happened? Does it have to have visual representation? Or is it the vertical blinking rectangle? Or what is it?

Editing a tree-like structure requires some form of a selector - e.g. from the root (logarithmic number of "pieces" on average for tree with random arity, not tree representing a list) or linearly at some index of a given tree walk (e.g. source code of most programming languages is a depth-first-search ordering of a tree). But in any way, one needs this "specification" of a place where an action (removal, addition, change) shall happen. In other words "something like a cursor" will by definition be always needed 😉.

I'm also confused by the fact that, despite looking like a great system and coming out of Apple, it is still basically unknown 30 or 40 years later.

It's actually not from Apple, but just from a man who has worked for Apple. Anyway, this guy was quite famous and he knew really well what UX means.

That YouTube video seems like the only reference to it that I could find.

Here you are: https://en.wikipedia.org/wiki/Canon_Cat (and its descendant: https://en.wikipedia.org/wiki/Archy with its "current state"). And an obligatory GitHub repo with a screenshot of Archy.

[kneasle]

I'm confused by what it is that you're advocating here. Are you suggesting that we attempt to apply Leap in some form to ASTs or that Sapling should be a Leap-based editor instead of an AST-based one?

As far as cursors go, the user has to be able to specify the site of their edit (which requires some device like a cursor) but for tasks such as inspecting code this seems redundant. Also having multiple cursors is a really cool feature, so the ideal scenario in my eyes is an editor which allows you to have 0 or more cursors in existence at any one time.

[dumblob]

I'm confused by what it is that you're advocating here. Are you suggesting that we attempt to apply Leap in some form to ASTs or that Sapling should be a Leap-based editor instead of an AST-based one?

Not at all. I'm just pointing out, that AST-based editor controlled via "direct" commands modeled after all identifiable use cases will have so many commands, that it won't bring anything new over a character-based edition of traditional text-oriented editors with automated syntax formatter. Actually quite vice versa - an AST editor will be less universal.

Leap is just a show case how to approach certain set of use cases in one unified yet still efficient way instead of providing "direct" command for each of them.

As far as cursors go, the user has to be able to specify the site of their edit (which requires some device like a cursor) but for tasks such as inspecting code this seems redundant. Also having multiple cursors is a really cool feature, so the ideal scenario in my eyes is an editor which allows you to have 0 or more cursors in existence at any one time.

That was my point - cursor(s) is(are) inevitable. Btw. inspecting code usually requires some form of focus which is usually emphasized by a cursor (e.g. a highlighted line or highlighted word or highlighted paragraph etc.) - not speaking about diffs etc. where it's not just convenient, but rather closer to a necessity.

[kneasle]

Not at all. I'm just pointing out, that AST-based editor controlled via "direct" commands modeled after all identifiable use cases will have so many commands, that it won't bring anything new over a character-based edition of traditional text-oriented editors with automated syntax formatter.

I beg to differ, and Sapling is an experiment to determine whether or not my hunch is correct (and to stand as an example for others in the case that my hunch is wrong). At any rate, I think that even Vi-style text editors are making non-universal assumptions about what you're editing. As an example:

In Vim w moves the cursor forward to the first change between alpha-numeric characters and non-alpha-numeric characters, which seems unnecessarily specific were it not for the fact that a lot of code is delimited like this and therefore it's incredibly useful. This would be pointless for something like brainfuck where everything is a symbol, or a language where everything is whitespace.

But every (human-made) thing in the world is optimised for the things that users are expecting them to be used for. Swiss army knives are technically more universal than dinner knives, but are used much less often than dinner knives because eating is so common that there are knives custom-designed for the purpose.

an AST editor will be less universal.

This is kind of the point. The observation behind why I think Sapling might be useful is that programmers spend maybe 99% of their time writing highly structured text, and so by removing the universality requirement we can achieve a much more focused editing experience.

Leap is just a show case how to approach certain set of use cases in one unified yet still efficient way instead of providing "direct" command for each of them.

I appreciate that, but it seems to me that Vi also manages to do a lot with (relatively) little by making simple commands composable to allow a vast number of 'emergent' commands.

Btw. inspecting code usually requires some form of focus

I feel like this is not necessarily the case; inspecting code only requires you to change your view of the code which has nothing to do with a cursor.

[kneasle]

OK look I didn't mean to sound passive aggressive - if I did then it wasn't meant that way.

I think that LEAP and the idea of doing a lot with very little is very powerful and should be explored (but not by me since I have too many projects already) - I'd be really interested in a leap-oriented editor project (though I probably wouldn't use it myself), and I'd encourage you to start a project yourself if none exist so far. All projects that we take for granted today had to start somewhere.

The purpose of Sapling, though, is to be an experiment as to whether adding the extra complexity of AST editing produces a code editor that people who are prepared to climb the learning curve can use to edit code faster. I'm not saying that Sapling will be the perfect text editor (it won't be) but I don't think there is anything like Sapling out there yet so it seems worth a try to make it. If it turns out to be much worse than I expected (which is entirely possible) then I hope it will serve as a warning for other people trying to do the same thing.

I hope you had a good Christmas (if you celebrate it)

[dumblob]

OK look I didn't mean to sound passive aggressive - if I did then it wasn't meant that way.

No worries, I have a thick skin 😉. I'm just utterly out of time, so bare with me.

The purpose of Sapling, though, is to be an experiment as to whether adding the extra complexity of AST editing produces a code editor that people who are prepared to climb the learning curve can use to edit code faster. I'm not saying that Sapling will be the perfect text editor (it won't be) but I don't think there is anything like Sapling out there yet so it seems worth a try to make it. If it turns out to be much worse than I expected (which is entirely possible) then I hope it will serve as a warning for other people trying to do the same thing.

Oh, thanks for clarification. It makes sense. I'll try to follow the development and if I find anything I'd be convinced of it could be beneficial, I'll mention it 😜.

I hope you had a good Christmas (if you celebrate it)

Same to you!

[kneasle]

No worries, I have a thick skin 😉. I'm just utterly out of time, so bare with me.

Ah OK that makes sesnse - I just didn't know if you weren't replying because you were pissed off or because you had no time to reply... and no one loses anything for trying to make peace when there's already peace.

[dumblob]

So, after the day my head somehow said to me "well, it seams Sapling will become a projectional editor" and in such case @kneasle shall take a look at Lamdu - see overview on https://futureofcoding.org/catalog/lamdu.html .

[kneasle]

So, after the day my head somehow said to me "well, it seams Sapling will become a projectional editor" and in such case @kneasle shall take a look at Lamdu - see overview on https://futureofcoding.org/catalog/lamdu.html.

Aha that's pretty cool - it's amazing how many projects there are out there... Lambdu also pointed me to this list, which has even more editors.

That subreddit also informed me finally of the difference between a 'projectional' and 'structured' editor - a projectional editor stores the syntax tree, whereas a structured editor stores the code as text. So Lambdu is a projectional editor and Sapling is a structured editor.

I think that while projectional editors have more potential, they stand little chance of adoption because they are incompatible with all existing languages and editors. So I think the only way an editor stands a chance is if it's structured and stores no additional information other than the original source text.