Hacker News Reader

Comment by majewsky | Hacker News Reader

Constructive criticism: As a Vim user, this website contains nothing that would convince me to actually try Amp. The only thing mentioned on there that does not apply to my Vim setup is "written in Rust". And as much as I love Rust, "written in Rust" is not a sufficient argument to get me to give up a tool that I've been living and breathing for over a decade.

If, on the other hand, I'm not the target audience, the website should make that clear, e.g. "Amp is a Vi-like editor designed for people who find Vim too hard to get started with" or whatever.

View on HN

I am a Vim user too, but I am very different from you.

Vim is my main editor. I have used it daily for years.

At the beginning I didn't like it. Then I spent time on it. Configured it. Installed plugins.

And I still don't like it.

But then I try other editors and either I miss one feature or I start pressing j to go down or whatever. I'm Vim's hostage.

This editor seems to target me personally.

Maybe give https://kakoune.org/ a try?

I've spent a few hours so far learning to use and setup Kakoune. It seems very thoughtfully designed, extremely flexible, great LSP integration, and ofc it's fast.

The community is very helpful. They have a reasonably active Discourse and Discord server which has been extremely tolerant of my inane questions.

For me, a mediocre programmer, there are a couple issues that have made it harder to switch to:

1. I wish someone would package of version of Kakoune that has all the quality-of-life stuff already in there. Setting up this editor feels like getting a whole new hobby. I just wanna work more effectively.

1b. It's very UNIX-y. Probably many people will love this aspect, but like, it does exactly one thing and that is edit text. You need to call out to other programs or plugins for any other functionality.

You can absolutely configure it to interoperate with many other UNIX programs to get something IDE-like, and looking through the setups of other users, many people do this. However, I would like a canonical way to do IDE things, rather than 100 different options. When adopting a new workflow, I just want to be able to function with it before I optimize it for my specific preferences.

2. The teaching infrastructure that exists for vim isn't there yet. Kakoune uses a different language. Rather than just the list of functions, it should really start with the most common things to workflow and then get deeper in the weeds.

Anyway, it's a very cool and good FOSS project and everyone reading this comment should look into it. If you're more competent than me you will probably like it. I found this[1] blog post helpful.

[1] https://cosine.blue/2019-09-06-kakoune.html

Do you perhaps have some awesome-kakoune cheatsheet for it, which you can recommend?

I found https://cosine.blue/2019-09-06-kakoune.html helpful.

Unfortunately I don't! Unlike GP I like vim, so I haven't had a reason to try switching to Kakoune, but I thought it might meet their needs.

I've been using Pycharm with the IdeaVim plugin for several years, and I found that it matches 99% of my expectations.

The extremely rare missing vim feature (to be honest none comes to mind) is more than balanced by the features from Pycharm and sane defaults.

Best part is that I'm not disoriented when I end up on a server with nothing but vi : it's still the same keystrokes.

Surprisingly IdeaVim, has become pretty good.

I was a Vim user for years, tried out Kakoune and never went back. I think for many Vim users there are many possible improvements. Hell, even as a Kakoune user i'd still like to see tweaks.

But, i agree with the GP comment - i don't see anything on this intro page that tells me why i'd want to use it.

I was a huge kakoune fan for a little while. What eventually dragged me back to vim was (a) proper async LSP support and (b) I wanted the same keybindings between my terminal editor and vscode, and the vscode vim keybindings are pretty good.

I keep trying to switch back to Vim but the selection-first workflows and multicursor really keep me Kakoune.

I really want to like Vim again though, for Onivim (2). Looks so pretty.

ah fuck you're making me miss kakoune

yeah there's nothing like it. but vim is just so polished and the vim-keybinding ecosystem is so big.

What seems to be the difference between the two of you? Better yet, what about amp appeals to you, and what about vim makes you dislike it but still be held hostage?

Personally, I use vim because:

- Most of the time I live on the server and running vscode (or any gui based editor) over X feels kinda useless.

- I don't like the sftp/sshfs based solutions

- (neo)vim is light enough that I can install anywhere (I have permissions) if its not already present

VS Code now has a "Remote SSH" plugin which installs the editor and all of its plugins on a remote server with one command, giving you an editor and file browser on that server almost instantly

I was never able to get VS Code's Remote SSH functionality to work. IIRC the server-side code indexing hung indefinitely.

I'm still curious what was special about my environment, since it seems to work for most people.

> or I start pressing j to go down

Doesn't any modern browser or IDE have a VIM emulation plugin?

I mean, the input modes ARE the main reason to use Vim. I haven't used Vim as a main editor for almost 5 years now, but all the basic commands are still on the tips of my fingers, because in every editor or IDE I move to, Vim emulation is the first thing I install. It's the most productive developer tool that I've ever learned, and it's like a passport of a country that gives you ability to live in any country in the world, to the point where you don't ever return home.

You're not a VIM's hostage. You're just following a very natural way of navigation--it's very easy to learn and you don't easily forget it.

A very different story is using some other shortcuts like "F5" for single step and "F6" for continue etc.. I always forget about these after 2 weeks not using it.

Is this the right place to go into a vim war? Perhaps we could restrict this to a discussion of the "amp" editor.

Is a discussion of "Who is the audience for the 'amp' editor" not a discussion of the amp editor?

Afaik what the world really needs is a vim like editor with sane defaults, partly overhauled shortcuts that are closer to other tools and some common scenarios solved in less steps (e.g. exiting the editor, multicursor stuff, ...)

Kakoune is aimed at multicursor stuff and has relatively sane defaults. It shows help dialogues when pressing key combos too.

Genuinely curious why multicursor is a big deal?

Multi-cursor editing is the fastest way to accurately modify large amounts of text, especially repetitive text. It's well worth learning for your respective editor. Most other editing methods don't come close, especially in terms of speed.

But it’s still just search and replace right, like renaming a variable or function, or am I missing something?

What you are missing, is that you get cursors that you can manipulate. Overwriting what they selected is the obvious thing (and then it would be indeed the same as search and replace) — but there are some less obvious things that make this thing powerful in a different way E.g.:

  1. select the next 3 occurances of "foo"
  
  2. Press End on keyboard to jump to end of line (even if the part after "foo" was different each time)
  
  3. Start typing away

You can also use the arrow keys to move the cursors, hold shift to do selections, alt + arrow to jump to the next/previous word and so on. Of course all of this can be done with regexes as well, but it takes longer usually to come up with just the right one, even if you are good with them.

The difference is the interactivity and instantaneous feedback. I don't want to have to blindly write a regex substitution when I could instead be seeing what is happening at each step, right in front of me.

Neovim gives you a preview of the result of your regex replacement, and with the ability to reference capture groups it's a pretty powerful.

Yeah, I'm a neovim user, and I enjoy that feature. There are just times when multiple cursors would be ever so slightly more ergonomic.

Vim also has it with `:set hlsearch incsearch`.

That doesn't preview the result of the regex, just the text that would be replaced IIRC.

> Genuinely curious why multicursor is a big deal?

It is easy to see what is going to happen. Also, you can do things that aren't possible (or very hard) with regexes.

Example: You want to add an argument at the beginning and at the end of a sequence of `foo(...)` invocations. You hit the "mark current word" key, now the first "foo" is highlighted. You hit the "mark next occurrence" key a couple of times. Now you have, say, five "foo" that are highlighted.

Now you hit cursor-right and you can immediately see the five cursors move after the opening parenthesis. You type, say "1, " and you see that argument being added to the beginning of the parameter list.

Now for something that isn't easy to do with regexes: You move the cursors to the left until they are all on the opening parenthesis. Now you hit the "jump to matching parenthesis" key. Now you have five cursors on the closing parenthesis. You move them to the left and add your argument.

Each individual editing step is immediately visible. You didn't have to invest the time to come up with a regex that does the trick. But you were able to avoid doing something five times.

Interesting. I can see that being useful when editing a json data for example. Not something I run into too often and I can manage the same outcome in vim easily enough, but it’s a bit more advanced so I can see the appeal for sure.

I am somebody who really has no problem with regexes, but multicursor is something I constantly use in a similar way as described above. This is great for all kind of structured data as well because you can also opt in to only work on certain occurances and immidiately see where things go wrong. When I would so the same with regexes I might use "replace next occurance" but halfway get to one line that fails, undo the lines before, retry again etc.

Once you get the hang of it it is really a quite valuable tool, which gladly you can find in more and more places (e.g. the inspect stylesheet editor in firefox also has multicursors).

I showed multicursors in atom to a greybeard when we were editing some yaml for a ansible configuration and he was really impressed with the ways you can use this feature for that stuff.

I use vscode and used sublime text before it.

If multicursor was to ever break in vscode, I would switch back to sublime text in a heartbeat.

Multiple cursors is the dealbreaker feature for any editor I use.

Everything else is just too painful.

kakoune integrates multiple cursors as a first class concept, rather than bolting it on. So editing commands that work on "the current selection" transparently work for multiple selections as well. You can see the changes live, which is nice.

For example, global search and replace is the same commands as search and replace, except you select the entire buffer first so that the search will make one selection per regex hit in the file

I've been using https://spacevim.org/ for this purpose for some time, though Vim per-se isn't my daily editor -- I use PyCharm with VIM emulation.

It lazy loads everything and supports most languages, has help throughout, and a responsive community for any issue you may encounter.

What would you do to shorten exiting vim?

  <esc> :wq

Is the longest it's ever been for me and

:q

Is the norm if I'm in visual mode and haven't edited the buffer.

Space is my leader key, save is mapped to <leader>w, exit is mapped to <leader>q, and <esc> is mapped to jk. So nominally exiting from insert mode in an unsaved buffer (jk<space>w<space>q) is the same number of key presses as <esc><shift>;wq<return>, but in practice, in my opinion, jk is superior to <esc>, <space>w is superior to <shift>;w<return>, <space>q is superior to <shift>;q<return>, and <space>w<space>q is superior to <shift>;wq<return>.

I think most people don't know that instead of :wq or :q! they can just ZZ and ZQ

or just :x

While I agree with most of this...

Who has trouble with ":x"? It's no more keystrokes than any other editor uses. I guess if you are in insert mode it's `esc :x`. I suppose you could bind a single keystroke in normal mode, but it's not that big a deal.

Multicursor would be fantastic. Macro goes pretty far to supporting what you do with multi cursor but falls a little short.

As an ex-Sublime and ex-VSCode user, I realized that macros and Visual Block mode covers all my use cases for multicursor functionality.

y and p are better suited to vim usage than control c v I'm not sure what shortcuts you want similar to other tools.

Leaving vim is easy :x if you want to save your work :q if you don't need to :q! if you want to discard all changes to a file These are 3 different operations with the 2 common cases taking 2 characters.

Ultimately if you just wanted different defaults you could trivially provide it as a plugin to vim.

This isn't an app I'm likely to use much (Team EMACS :) but as someone learning Rust, it's great to see the code for a full application out there. Kudos to the authors. :)

I don't think amp point is that Vim is too hard but that some commons scenarios are not staightforward in Vim (make easy things easy, and more difficult things a little bit harder).

I think the aim is really to have a battery included terminal modal text editor (with some common Vi bindings)

I think its pretty common to mention which language a project is using. I don't see anything on that website embellishing it unnecessarily. Looking at another project, sqlite, it mentions the language used in the first line of its home page. Interestingly, vim.org mentions nowhere what language its based on, but google hilites that it is based on C.

sqlite is a programming library, with an API for C: what language it is written in/for is one of the most important things about its existence... probably second only to what it does.

It's written in Rust.

Reply on news.ycombinator.com