https://anvil-editor.net/ is more directly inspired by and similar to Acme (but makes no attempt to borrow from Vim).
https://github.com/martanne/vis is a minimalist editor that stays close to Vim but adds Sam-style regular extensions and multi-cursor editing (but not Acme-style "execute anything on screen"). For example, you can select all instances of a regex and edit them all at once afterwards interactively.
> https://anvil-editor.net/ is more directly inspired by and similar to Acme (but makes no attempt to borrow from Vim).
Wow, I didn't think there is still open source software around that isn't hosted on GitHub or another code hosting platform. And the page also makes it very hard to tell if the project is still active, the only date I could find was in the license (2019). I actually had to download the latest version and look inside the archive to see that it's from November 2024...
Which brings me to a question: I'm not entirely clear on the relationship between and capabilities of Sam and Acme.
Is the ability of Vis to select all instances of a regex and edit them all at once afterwards interactively (see e.g. https://asciinema.org/a/41361) Vis's own idea, or was it part of Acme? Is it part of Ad?
Your comment about writing a text editor library is precisely what got me started with amp ~10 years ago, where much of its core functionality was extracted here:
I’m an IDE-with-vim-bindings user, and I don’t get the desire for another vim. The value proposition in vim (or vscode or idea) is in the extra functionality on top of the core editing experience. If you give me a different text editing experience, but don’t support the ecosystem of plugins, the value proposition is almost zero. There are basically no methods of text input that will make me more productive than a good debugger, test and project/file explorer integration.
One thing that I would love to see is vim like bindings for navigating a semantic representation - navigating a tree sitter representation instead of words and symbols.
Many editors pop up with zero ecosystem and become successful anyway. All you need to do is provide a better editor experience in some fashion for there to be a value proposition. Atom, VS Code, helix, zed, etc. none of these had mountains of plugins and integrations initially.
Plus building vi-like editors is just a fun exercise a lot of programmers undertake, hence why there are so many. People have to try things to know what is better.
There are ads disguised as articles, but they are usually about Apple products. Often the article is a direct link to the corresponding product web page.
This is very exciting! I've been longing for an acme-like editor that adapts better to mainstream OSes. Being vim-like is a major plus. I'm gonna try this out!
There is a reason why interactive command shells such as bash, korn, and zsh only support two editing modes; emacs and vi.
Emacs reifies its LISP underpinnings by modelling edit commands as an AST[0]. "Top down" as it were. This optimizes for command categorization.
Vi/vim/derivatives model editing by "flattening" the editing command tree such that the vast majority are no more than two or three keystrokes (excluding repeat count prefixes). This optimizes for uniform command distribution.
Both eschew requiring a mouse and/or a GUI, which vastly increase their applicability.
As to which is superior, that is the subject of thousands of "editor wars" threads in one form or another.
My stance is to pick whichever best suits how you like to think when solving problems.
> Both eschew requiring a mouse and/or a GUI, which vastly increase their applicability.
This is a prime example of what is, it seems to me, one of the absolutely core misunderstandings of the wider Unix world.
GUI does not mean, imply, or require a mouse. The original Mac and Lisa were mouse-centric, yes, but folks, that was 40 years ago now and the world has moved on.
You can use a modern Mac entirely without a pointing device, via Voiceover, which is built in to all Macs, iPhones, iPads, etc.
Windows has been amenable to being 100% keyboard driven since Windows 1.0 in 1985 and I have been using Windows primarily by keyboard controls since 1988.
This is the standard method of computer interaction for millions of blind computer users around the world since the 1980s.
What's more, the Windows keyboard UI strongly influenced IBM CUA, which in turn was informed by the mid-1980s Apple Human Interface Guidelines, and that influenced OS/2, DOS from 1990 or so onwards (so MS/PC DOS 4 and later), and that influenced Xfce, KDE, GNOME 1/2, and most other xNix GUIs.
It is only the shell oriented xNix world that has refused to adapt.
Console-mode shell-only Linux text editors such as eFTE, SETedit, and Tilde all have the third-of-a-century-old standard UI and can be used 100% with the keyboard but also have menus and dialog boxes.
The standard design of basically all 21st century GUIs (except for the handful that are intentionally different – GNOME, Pantheon, Unity) does not need graphics. It does not need a mouse. It can be, and still today is, sometimes implemented entirely in text mode, it works on dumb text terminals, and it was universal in 1990s DOS, OS/2 and other native x86 OSes.
The result of the refusal of the xNix world to even notice this is happening has absolutely crippled the field of editor design on xNix.
In all other fields of software, text editors moved on from the awful and terribly dated design of Vi and Emacs by the late 1970s. See this interview with Larry Tesler, who invented cut/copy/paste as a computer UI.
This means that there are something like a million times more users out there happily editing text every day with editors with better UI than the absolute top-rated shell editors on any xNix.
From what I've noticed, despite the label "outdated", I can't reliably notice any difference in utility between these categories. neo/vim users (which I certainly don't use) are at least as effective using these tools as so-called "modern" text editors. I don't think anyone can categorically say that modern text editor users (e.g. vscode) are more productive/better/extract more utility/etc. than their terminal based counterpart like you can say for other truly outdated technologies. And these tools make up a huge portion of the (coding) market. I don't think it should matter that they don't target the masses.
I think there are a lot bigger problems to solve in the xNix environment than getting people to stop pressing escape to enter normal mode.
(the argument for Emacs makes less sense since it has customizations available to be as "modern" as you want. You may criticize it's byzantine configuration process, but that's a different topic. It's also funny how Apple, the poster child for elegance in UIs has Emacs keybindings by default everywhere in macOS, even the concepts of "yanking" and "killing". In hindsight though, it makes perfect sense)
I am absolutely not saying that there is any difference in utility whatsoever. I have watched skilled exponents of Vim and Emacs perform wizardry, and I've also seen an adept of Jedit do things with plain English text that I don't know how to do in any editor.
This is absolutely not about utility or capabilities.
It's about UI.
I am aware of efforts to bring a standard modern (as in, 1990s) UI to both editors.
For Emacs there is ErgoEmacs -- https://ergoemacs.github.io/ -- which is amazing and makes it slightly usable even for me, steeped in CUA for over a third of a century.
For Vim I know of Cream -- https://cream.sourceforge.net/ -- but it seems unmaintained for a long time and when I tried it I couldn't get it working.
What I am saying is two other, quite different things:
1. Using the Linux shell is needlessly hard and complicated, because of its adamant refusal to adopt the modernised UIs of other text-mode OSes from 30+ years ago. These could be bringing the shell into harmony with the GUI, making the experience better, and it would be trivially easy to set things up so that experienced users with their own ways of doing things were not inconvenienced at all.
2. As a result of this refusal, or even of this blank ignorance and lack of curiosity in how other OSes and other platforms modernised text-mode apps, the dominant tools in Linux and other FOSS xNixes have no standadisation. Even when there are TUIs driven by ncurses or whatever, they're all different and all inconsistent. There's no need for it. It's wasting everyone's time.
In other words, the tools don't need to be different from one another and they don't need to look and work so differently from in GUI desktops.
ok, I think I understand what you meant better. I guess my mental model of UI has some sort of utility baked in but I see how this isn't necessarily the case. I would agree with this take actually. It is deffinitely is a jarring experience with with terminal stuff as every TUI is a world unto itself.
Essentially and any all Windows apps that edit text.
MS Word and all of Office, and all of its rivals. IE, Edge, Chrome, Firefox, and all other browsers, GUI email clients including on Linux and all the BSDs, etc.
I have written about this, in case you're unfamiliar with CUA:
It's not just me. There's also some Zigs or Zags or something; pretty sure your list is missing several entries.
My pet theory, we can thank LSP for that, as it removed the major hurdle for any new editor project: the complexity of supporting modern programming languages and practices. Being able to offload most of that complexity to a language server (and most of the rest to tree-sitter) just about makes a new editor a viable side project.
As for motivation... I wonder how many of the new editors are a "let's rewrite it in Rust" thing?
> As for motivation... I wonder how many of the new editors are a "let's rewrite it in Rust" thing?
None?
I mean, Helix and Kakoune are written in Rust, but they are not rewrites, they have very different goals than e.g. neovim.
They explore different concepts, workflows and ideas, and the choice of Rust as a language merely stems from the authors finding Rust to be a pleasant and appropriate language to explore their ideas
It’s quite a young editor but is conceptually pretty neat! It works on syntax trees as defined by tree sitter, and the tutorial on their site shows off how powerful that is pretty nicely.
I also like how it gets by with pretty much just buffers and readline for everything. I’m a bit more wary of all config happening by changing code and recompiling, though.
Definitely one I’m watching, though it’s far from being able to tempt me away from Helix at this stage.
This is nice. I like this editor, will try it out. The beginnings of a "mode" exist in vim, with plugins like tinykeymap that let you get into "tab manipulation mode" or "window manipulation mode", you can really do that with anything though, but maybe not as extensively as in Ki. It's quite a neat trick, example that lets you c-w +++++ instead of c-w + c-w +:
If "ki editor" is hard to google, I suppose "ad editor" must be basically impossible to google. A clever way to keep the project low-profile before it's ready for world domination :)
I wonder why every attempt at copying vi's concept, which is reasonable, also ends up copying its keybinding from the 70s.
I'm not talking about hjkl, but rather y for yank, p for put, d for delete, u for undo... where today every other software adopts a different vocabulary, namely x for cut, c for copy, v for paste, z for undo, etc.
I think those bindings are fine, what is more problematic to me is the inconsistencies or straight up arbitrary mappings (gg and G come to mind). I feel like kakoune did a great job at improving vims bindings to make more sense.
Speaking of 70s, my personal showstopper for vi isn't mode switching (actually, quite convenient). It's the cursor being on top of a symbol, rather then between symbols, so you need to mind when to 'i' and when to 'a'. And no, virtual spaces doesn't change much, the whole editing model is built around it.
Terminal is just the display, I'm talking about editor model. Even if the cursor is displayed as vertical bar, vi would still models it on-symbol and switching between modes will move it sometimes inconsistently. Well explained here: https://www.reddit.com/r/vim/comments/99h4le/comment/e4nsx0m...
Reddit doesn't like my network and I won't dig up some proxy they prefer. You can describe an incantation that will "move it sometimes inconsistently" instead.
My personal take is just you have to remember what you did last to choose between "a" and "i". If you do i123<Esc>iabc, you get "12abc3" rather then "123abc".
And then as the link says:
- <Esc> moves to the left [...] but if you do i_Ctrl-O or i_Ctrl-\_Ctrl-O [...] it moves to the right!!
- An empty line still allows normal mode to have a cursor, but since there are zero characters this cursor is kind of “fake”.
None of those are inconsistent. If a is confusing for you, use i, A and o, that'll be enough for most things you want. Most of the time you'll drop into insert mode through cw, cib and the like anyway.
What do you mean by empty lines? Does your vim somehow have lines in the buffer that aren't in the file?
The point is that they teach you that 'i' enters insert mode and '<esc>' exits it. This is not true! It it was true and 'i' and '<esc>' only switched mode, then the sequence 'i<esc>' would have no effect. Instead 'i<esc>' leaves the cursor on another character.
I think the parent poster meant that two newlines in file are displayed as an empty line. That's ok. What's odd is that the cursor is allowed to stay in the empty line, as if it was on a virtual character at the end of the line. However, if the line is not empty, the cursor is not allowed to go one character right of the last one.
CUA bindings are very QWERTY-centric, which feels even more dated to me. The mnemonic style binds remain more equal across layouts. In the case of p, there's also P, so you'd likely lose half the functionality trying to force it into the CUA style. I guess you could use ctrl-shift-v, but that tends to be "paste without formatting".
I grew up mostly with Windows and CUA, and I still became a big fan of vim.
vim bindings are even more QWERTY-centric, no? That's why I skipped it after a brief look, many years ago: having to memorize a lot of unfamiliar key commands was bad enough, but coming at it as a lifelong Dvorak user, the keys also seemed to be scattered incoherently all over the keyboard.
IMO, it's because mnemonics make more sense than QWERTY keyboard placement. Of course, there are exceptions even in Vim (e.g., ^E and ^Y for viewport scrolling), but bindings to value rather than pointer for things make it easier for those with alternate layouts (very few apps use scancode rather than keycodes for bindings, but they are possible such as GNOME's Alt+<key above Tab> for same-app window switching).
You fell victim to one of the classic blunders - the most
famous of which is "never get involved in a land war in
Asia" - but only slightly less well-known is this:
Sooner or later, wanting to write a program editor has ensnared many a skilled developer, only to find it to be a time vampire when considered anything more than an intellectual exercise.
I appreciate your joke, but also - it doesn't have to be so bad as that! Of all the everyday tools a developer might choose to reinvent in their own personal style, an editor is likely the easiest to complete.
I have written three different code editors over the course of my career, and the last of them I have been using every day for a long time. It is a good feeling, building tools which suit oneself perfectly!
Indeed, I was chuckling along as I read the README, as this is remarkably similar to my attempt at the same problem about 14 years ago. Though sminez seems much more skilled and motivated than I am: https://github.com/sminez/penrose
I respect the ambition. I thought I was combining chocolate and peanut butter a few times, but after sinking a few days into it, realized I was building a Homer car. All of those projects were driven by my desire for some way of interacting with some common data or whatever rather than solving a unique technical problem, so I now force myself to define a very granular UI spec and start with the front end code, and the profile of the homer car reveals itself way earlier in the process. Popping open the code editor and banging out the scaffolding for a back-end always feels so productive, but if it’s a fundamentally flawed idea, it’s very much the opposite, in reality.
People should be aware of two related editors:
https://anvil-editor.net/ is more directly inspired by and similar to Acme (but makes no attempt to borrow from Vim).
https://github.com/martanne/vis is a minimalist editor that stays close to Vim but adds Sam-style regular extensions and multi-cursor editing (but not Acme-style "execute anything on screen"). For example, you can select all instances of a regex and edit them all at once afterwards interactively.
> https://anvil-editor.net/ is more directly inspired by and similar to Acme (but makes no attempt to borrow from Vim).
Wow, I didn't think there is still open source software around that isn't hosted on GitHub or another code hosting platform. And the page also makes it very hard to tell if the project is still active, the only date I could find was in the license (2019). I actually had to download the latest version and look inside the archive to see that it's from November 2024...
It is active and it works remarkable well as an editor.
Which brings me to a question: I'm not entirely clear on the relationship between and capabilities of Sam and Acme.
Is the ability of Vis to select all instances of a regex and edit them all at once afterwards interactively (see e.g. https://asciinema.org/a/41361) Vis's own idea, or was it part of Acme? Is it part of Ad?
Your comment about writing a text editor library is precisely what got me started with amp ~10 years ago, where much of its core functionality was extracted here:
https://crates.io/crates/scribe
Good luck with the project! Building a text editor to scratch your own itch is fun.
Love amp <3
I’m an IDE-with-vim-bindings user, and I don’t get the desire for another vim. The value proposition in vim (or vscode or idea) is in the extra functionality on top of the core editing experience. If you give me a different text editing experience, but don’t support the ecosystem of plugins, the value proposition is almost zero. There are basically no methods of text input that will make me more productive than a good debugger, test and project/file explorer integration.
One thing that I would love to see is vim like bindings for navigating a semantic representation - navigating a tree sitter representation instead of words and symbols.
Many editors pop up with zero ecosystem and become successful anyway. All you need to do is provide a better editor experience in some fashion for there to be a value proposition. Atom, VS Code, helix, zed, etc. none of these had mountains of plugins and integrations initially.
Plus building vi-like editors is just a fun exercise a lot of programmers undertake, hence why there are so many. People have to try things to know what is better.
Neovim has treesitter-objects, which let you use semantic tokens like these in motions.
E.g.: daf = "delete around function", vic = "visual inside class", etc.
I saw the headline and thought HackerNews is now showing ads. But it's an editor called "ad".
There are ads disguised as articles, but they are usually about Apple products. Often the article is a direct link to the corresponding product web page.
This is very exciting! I've been longing for an acme-like editor that adapts better to mainstream OSes. Being vim-like is a major plus. I'm gonna try this out!
Is it just me, or in the latest few (10?) years there have surged more vi-like alternatives like never before?
- Kakoune
- Helix
- Vis
- Ki
- Ad
- ...
There is a reason why interactive command shells such as bash, korn, and zsh only support two editing modes; emacs and vi.
Emacs reifies its LISP underpinnings by modelling edit commands as an AST[0]. "Top down" as it were. This optimizes for command categorization.
Vi/vim/derivatives model editing by "flattening" the editing command tree such that the vast majority are no more than two or three keystrokes (excluding repeat count prefixes). This optimizes for uniform command distribution.
Both eschew requiring a mouse and/or a GUI, which vastly increase their applicability.
As to which is superior, that is the subject of thousands of "editor wars" threads in one form or another.
My stance is to pick whichever best suits how you like to think when solving problems.
0 - https://en.wikipedia.org/wiki/Abstract_syntax_tree
> Both eschew requiring a mouse and/or a GUI, which vastly increase their applicability.
This is a prime example of what is, it seems to me, one of the absolutely core misunderstandings of the wider Unix world.
GUI does not mean, imply, or require a mouse. The original Mac and Lisa were mouse-centric, yes, but folks, that was 40 years ago now and the world has moved on.
You can use a modern Mac entirely without a pointing device, via Voiceover, which is built in to all Macs, iPhones, iPads, etc.
Windows has been amenable to being 100% keyboard driven since Windows 1.0 in 1985 and I have been using Windows primarily by keyboard controls since 1988.
This is the standard method of computer interaction for millions of blind computer users around the world since the 1980s.
What's more, the Windows keyboard UI strongly influenced IBM CUA, which in turn was informed by the mid-1980s Apple Human Interface Guidelines, and that influenced OS/2, DOS from 1990 or so onwards (so MS/PC DOS 4 and later), and that influenced Xfce, KDE, GNOME 1/2, and most other xNix GUIs.
It is only the shell oriented xNix world that has refused to adapt.
Console-mode shell-only Linux text editors such as eFTE, SETedit, and Tilde all have the third-of-a-century-old standard UI and can be used 100% with the keyboard but also have menus and dialog boxes.
The standard design of basically all 21st century GUIs (except for the handful that are intentionally different – GNOME, Pantheon, Unity) does not need graphics. It does not need a mouse. It can be, and still today is, sometimes implemented entirely in text mode, it works on dumb text terminals, and it was universal in 1990s DOS, OS/2 and other native x86 OSes.
The result of the refusal of the xNix world to even notice this is happening has absolutely crippled the field of editor design on xNix.
In all other fields of software, text editors moved on from the awful and terribly dated design of Vi and Emacs by the late 1970s. See this interview with Larry Tesler, who invented cut/copy/paste as a computer UI.
https://worrydream.com/refs/Tesler_2012_-_A_Personal_History...
This means that there are something like a million times more users out there happily editing text every day with editors with better UI than the absolute top-rated shell editors on any xNix.
From what I've noticed, despite the label "outdated", I can't reliably notice any difference in utility between these categories. neo/vim users (which I certainly don't use) are at least as effective using these tools as so-called "modern" text editors. I don't think anyone can categorically say that modern text editor users (e.g. vscode) are more productive/better/extract more utility/etc. than their terminal based counterpart like you can say for other truly outdated technologies. And these tools make up a huge portion of the (coding) market. I don't think it should matter that they don't target the masses.
I think there are a lot bigger problems to solve in the xNix environment than getting people to stop pressing escape to enter normal mode.
(the argument for Emacs makes less sense since it has customizations available to be as "modern" as you want. You may criticize it's byzantine configuration process, but that's a different topic. It's also funny how Apple, the poster child for elegance in UIs has Emacs keybindings by default everywhere in macOS, even the concepts of "yanking" and "killing". In hindsight though, it makes perfect sense)
I think you misunderstand what I am saying.
I am absolutely not saying that there is any difference in utility whatsoever. I have watched skilled exponents of Vim and Emacs perform wizardry, and I've also seen an adept of Jedit do things with plain English text that I don't know how to do in any editor.
This is absolutely not about utility or capabilities.
It's about UI.
I am aware of efforts to bring a standard modern (as in, 1990s) UI to both editors.
For Emacs there is ErgoEmacs -- https://ergoemacs.github.io/ -- which is amazing and makes it slightly usable even for me, steeped in CUA for over a third of a century.
For Vim I know of Cream -- https://cream.sourceforge.net/ -- but it seems unmaintained for a long time and when I tried it I couldn't get it working.
What I am saying is two other, quite different things:
1. Using the Linux shell is needlessly hard and complicated, because of its adamant refusal to adopt the modernised UIs of other text-mode OSes from 30+ years ago. These could be bringing the shell into harmony with the GUI, making the experience better, and it would be trivially easy to set things up so that experienced users with their own ways of doing things were not inconvenienced at all.
2. As a result of this refusal, or even of this blank ignorance and lack of curiosity in how other OSes and other platforms modernised text-mode apps, the dominant tools in Linux and other FOSS xNixes have no standadisation. Even when there are TUIs driven by ncurses or whatever, they're all different and all inconsistent. There's no need for it. It's wasting everyone's time.
In other words, the tools don't need to be different from one another and they don't need to look and work so differently from in GUI desktops.
Mmm, given that I have an AZERTY keyboard, I take a look at ErgoEmacs's configuration and .. no way I'm going into this! I'll stay with VSCode..
ok, I think I understand what you meant better. I guess my mental model of UI has some sort of utility baked in but I see how this isn't necessarily the case. I would agree with this take actually. It is deffinitely is a jarring experience with with terminal stuff as every TUI is a world unto itself.
Which editor do these million times more users use?
Essentially and any all Windows apps that edit text.
MS Word and all of Office, and all of its rivals. IE, Edge, Chrome, Firefox, and all other browsers, GUI email clients including on Linux and all the BSDs, etc.
I have written about this, in case you're unfamiliar with CUA:
https://www.theregister.com/2024/01/24/rise_and_fall_of_cua/
vscode!
It's not just me. There's also some Zigs or Zags or something; pretty sure your list is missing several entries.
My pet theory, we can thank LSP for that, as it removed the major hurdle for any new editor project: the complexity of supporting modern programming languages and practices. Being able to offload most of that complexity to a language server (and most of the rest to tree-sitter) just about makes a new editor a viable side project.
As for motivation... I wonder how many of the new editors are a "let's rewrite it in Rust" thing?
> As for motivation... I wonder how many of the new editors are a "let's rewrite it in Rust" thing?
None? I mean, Helix and Kakoune are written in Rust, but they are not rewrites, they have very different goals than e.g. neovim.
They explore different concepts, workflows and ideas, and the choice of Rust as a language merely stems from the authors finding Rust to be a pleasant and appropriate language to explore their ideas
I'd never heard of Ki, and it's hard to google. Do you have a reference?
https://ki-editor.github.io/ki-editor/
It’s quite a young editor but is conceptually pretty neat! It works on syntax trees as defined by tree sitter, and the tutorial on their site shows off how powerful that is pretty nicely.
I also like how it gets by with pretty much just buffers and readline for everything. I’m a bit more wary of all config happening by changing code and recompiling, though.
Definitely one I’m watching, though it’s far from being able to tempt me away from Helix at this stage.
This is nice. I like this editor, will try it out. The beginnings of a "mode" exist in vim, with plugins like tinykeymap that let you get into "tab manipulation mode" or "window manipulation mode", you can really do that with anything though, but maybe not as extensively as in Ki. It's quite a neat trick, example that lets you c-w +++++ instead of c-w + c-w +:
If "ki editor" is hard to google, I suppose "ad editor" must be basically impossible to google. A clever way to keep the project low-profile before it's ready for world domination :)
Sounds like a Google problem; https://duckduckgo.com/?t=ffab&q=ki+text+editor&ia=web gives https://ki-editor.github.io/ki-editor/ in the first screen.
It’s the first result for “ki editor” on Google as well. I suspect they just typed in “ki”.
> It’s the first result for “ki editor” on Google as well. I suspect they just typed in “ki”.
I tried "ki vimlike." In retrospect, "ki editor" would have made more sense.
Screenshots, please.
I wonder why every attempt at copying vi's concept, which is reasonable, also ends up copying its keybinding from the 70s.
I'm not talking about hjkl, but rather y for yank, p for put, d for delete, u for undo... where today every other software adopts a different vocabulary, namely x for cut, c for copy, v for paste, z for undo, etc.
I think those bindings are fine, what is more problematic to me is the inconsistencies or straight up arbitrary mappings (gg and G come to mind). I feel like kakoune did a great job at improving vims bindings to make more sense.
Speaking of 70s, my personal showstopper for vi isn't mode switching (actually, quite convenient). It's the cursor being on top of a symbol, rather then between symbols, so you need to mind when to 'i' and when to 'a'. And no, virtual spaces doesn't change much, the whole editing model is built around it.
It's the terminal that controls the cursor. You can tell vim to change it and have a vertical bar in insert mode and a block otherwise if you want.
By default you just get what your terminal does.
Terminal is just the display, I'm talking about editor model. Even if the cursor is displayed as vertical bar, vi would still models it on-symbol and switching between modes will move it sometimes inconsistently. Well explained here: https://www.reddit.com/r/vim/comments/99h4le/comment/e4nsx0m...
Reddit doesn't like my network and I won't dig up some proxy they prefer. You can describe an incantation that will "move it sometimes inconsistently" instead.
My personal take is just you have to remember what you did last to choose between "a" and "i". If you do i123<Esc>iabc, you get "12abc3" rather then "123abc".
And then as the link says:
- <Esc> moves to the left [...] but if you do i_Ctrl-O or i_Ctrl-\_Ctrl-O [...] it moves to the right!!
- An empty line still allows normal mode to have a cursor, but since there are zero characters this cursor is kind of “fake”.
None of those are inconsistent. If a is confusing for you, use i, A and o, that'll be enough for most things you want. Most of the time you'll drop into insert mode through cw, cib and the like anyway.
What do you mean by empty lines? Does your vim somehow have lines in the buffer that aren't in the file?
The point is that they teach you that 'i' enters insert mode and '<esc>' exits it. This is not true! It it was true and 'i' and '<esc>' only switched mode, then the sequence 'i<esc>' would have no effect. Instead 'i<esc>' leaves the cursor on another character.
\n\n
That's two characters, i.e. not empty?
I think the parent poster meant that two newlines in file are displayed as an empty line. That's ok. What's odd is that the cursor is allowed to stay in the empty line, as if it was on a virtual character at the end of the line. However, if the line is not empty, the cursor is not allowed to go one character right of the last one.
CUA bindings are very QWERTY-centric, which feels even more dated to me. The mnemonic style binds remain more equal across layouts. In the case of p, there's also P, so you'd likely lose half the functionality trying to force it into the CUA style. I guess you could use ctrl-shift-v, but that tends to be "paste without formatting".
I grew up mostly with Windows and CUA, and I still became a big fan of vim.
No need for Ctrl: imagine simply mapping p to v and P to V.
vim bindings are even more QWERTY-centric, no? That's why I skipped it after a brief look, many years ago: having to memorize a lot of unfamiliar key commands was bad enough, but coming at it as a lifelong Dvorak user, the keys also seemed to be scattered incoherently all over the keyboard.
IMO, it's because mnemonics make more sense than QWERTY keyboard placement. Of course, there are exceptions even in Vim (e.g., ^E and ^Y for viewport scrolling), but bindings to value rather than pointer for things make it easier for those with alternate layouts (very few apps use scancode rather than keycodes for bindings, but they are possible such as GNOME's Alt+<key above Tab> for same-app window switching).
I don't see how that is a problem, given how trivially easy most of these editors make it to rebind keys.
To paraphrase The Princess Bride[0]:
Sooner or later, wanting to write a program editor has ensnared many a skilled developer, only to find it to be a time vampire when considered anything more than an intellectual exercise.Good luck on your journey. :-)
0 - https://www.imdb.com/title/tt0093779/quotes/?ref_=tt_dyk_qu
There was a time when writing your own editor was considered a rite of passage.
Kinda like how art students copy master works and noob programmers recreate classic games (pong, space invaders, tetris, pacman, ...).
I love it when people share their rewrites, recreations.
I appreciate your joke, but also - it doesn't have to be so bad as that! Of all the everyday tools a developer might choose to reinvent in their own personal style, an editor is likely the easiest to complete.
I have written three different code editors over the course of my career, and the last of them I have been using every day for a long time. It is a good feeling, building tools which suit oneself perfectly!
Indeed, I was chuckling along as I read the README, as this is remarkably similar to my attempt at the same problem about 14 years ago. Though sminez seems much more skilled and motivated than I am: https://github.com/sminez/penrose
I respect the ambition. I thought I was combining chocolate and peanut butter a few times, but after sinking a few days into it, realized I was building a Homer car. All of those projects were driven by my desire for some way of interacting with some common data or whatever rather than solving a unique technical problem, so I now force myself to define a very granular UI spec and start with the front end code, and the profile of the homer car reveals itself way earlier in the process. Popping open the code editor and banging out the scaffolding for a back-end always feels so productive, but if it’s a fundamentally flawed idea, it’s very much the opposite, in reality.
[flagged]