141–150 of 154 posts
[dead]
Eh, v + showmatch / % gets you very far in languages that use ()[]{} (angle brackets you have to add to matchpairs). It gets you nowhere in Python though, not without plugins.
Earlier quoted context omitted.
I actually used a language and editor like this in a previous large company. It was an experimental language that they wanted to replace their current application level language and was built ontop of JetBrains MPS https://www.jetbrains.com/mps/ which has that feature among others. My personal opinion after working with that lang is all of this is that its theoretically interesting. But a dead end in practice along w…
What was the issue with MPS? MPS also looks like "custom widgets in normal text-based java" i.e. mixed paradigms and not "ground up ast-based editing". I'm not sure if I can agree with your other points. I can't think of the last time I cat'd or maniuplated rust/java/go outside a heavy and slow editor. Many languages have more or less "one" editor with all the features that most people use, and often use it for chang…
I was really excited about the concept and read some papers on it at the time. Then I ran a real world application of it, and writing code in it was just a bad experience.
I think I didn't explain the gradual typing properly. I mean the broader concept of moving developers from one way of doing things to another.
When the vast majority of people and tools are working a certain way. Introducing a whole new thing that requires them to work a whole different way is a hard sell.
So having a way for people to move gradually from point A to point B at their own pace and pick up benefits along the way is really nice.
One example of this is Typescript with gradual typing. Swapping form js to typescript is fairly easy. You can still use your old tools and over time you can start to adapt new features into your code, and over time everyone gets used to this new stricter/better approach.
I think ast based code like this essentially requires you to throw out everything all at once, not just editor, but literally everyone's workflow today and rebuild from the ground up.
I just don't think it will ever be more than a niche thing unless it can loosen up on strictness and play nice with existing tooling.
Earlier quoted context omitted.
I know, I use Emacs+Evil. I'm going to give Ki a try and, in case of success, to think about writing Ki binding for Emacs.
emacs already has structural editing packages like combobulate
Earlier quoted context omitted.
> The challenge is getting this to be a useable way of entering programs. Well exactly. When the path between Program A and Program B can only be valid programs, you are going to end up with either a much longer, less intuitive path, or deleting everything and starting again. It can also be quite possible to invent structures which are valid but have no valid path to creating them.
> It can also be quite possible to invent structures which are valid but have no valid path to creating them. I'm curious if you have an example of such a structure? Pedantically: if, for every valid tree, there exists a bidirectional path to the empty root node, there's always at least one path between all given pairs of valid trees ... albeit one that no developer would ever take.
Many years ago, I created an editor operating on syntax trees that I think is more "hard-core" than this - that is, only tree-oriented operations are done. There is no parsing of text, since entering plain text, rather than a tree, is impossible. Hence, there can be no syntactically invalid programs. The challenge is getting this to be a useable way of entering programs. I think I made progress on this, but the feasi…
I actually used a language and editor like this in a previous large company. It was an experimental language that they wanted to replace their current application level language and was built ontop of JetBrains MPS https://www.jetbrains.com/mps/ which has that feature among others. My personal opinion after working with that lang is all of this is that its theoretically interesting. But a dead end in practice along w…
Earlier quoted context omitted.
I'm not sure how that's not "recreating everything". What's still shared if you replace the whole state machine (handling file management, etc) and also replace the whole input handling system? A terminal emulator and a copy of Lua?
There are certainly different possibilities of where the line would be drawn. I am not that familiar with vim internals, but I don't consider file management to be part of vim editing model. And we are only talking about editing model (e.g. b being beginning of a word), not the whole editor (plugin system, ui, lsp and treesitter integration, etc). Though it is true that some parts are more tightly related to "vim". T…
nmap can shadow the built-in commands, replacing them with whatever function you want.
> There some cases were Neovim already wants to disconnect itself from vim legacy like allowing to scroll viewport without moving the cursor
I think you mean beyond where the cursor is so it's hidden, but you can jump the screen so the cursor's current position is at the top/middle/bottom without moving the cursor using zt/zz/zb.
[dead]
> vim's modal editing is powerful but the movements are text-based. Eh, v + showmatch / % gets you very far in languages that use ()[]{} (angle brackets you have to add to matchpairs). It gets you nowhere in Python though, not without plugins.
Earlier quoted context omitted.
That comparison table is strange and sometimes wrong. Neovim for example detects and updates external file changes by default. And the coherence of the keybindings in Ki is "Great" bit vim/helix: > As you can see, there's no single logical categorization for these keymaps, they are either lowercase-uppercase, normal-alt, left-right bracket, or outright unexplainable. Word, End, Back, Change Word and even Change Inner…
Re. incoherence of vim's keybindings, I partially agree. Most of the times, shift means "bigger", and only in a few places it means "invert". Examples of "bigger" are all the motions involving words vs. WORDS, where WORDS are a broader interpretation of words; "V" is like "v" but by lines, thus in larger chunks; "C", "D", "Y" do the same as their unshifted counterparts, but extended to the end of line; etc. Examples…