Hacker News new | past | comments | ask | show | jobs | submit login
Amp: Vi-like terminal editor written in Rust (amp.rs)
148 points by cassepipe on April 12, 2021 | hide | past | favorite | 100 comments



At a glance, it looks like there are no provisions for supporting Language Server Protocol. That's unfortunate as I've come to use gopls, rls, tsserver and clangd quite a bit. Getting accurate autocompletion in complex situations and errors as you type are not absolutely necessary, but once you have them it's hard to go back.

edit: rust-analyzer, not rls.


True but plug-in API for better language support is apparently on the roadmap


FYI you should switch to rust-analyzer instead of RLS.


Actually, I have been using rust-analyzer, I misspoke.


You’re both right, rust-analyzer will become official RLS 2.0.


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.


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?



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.


I like that `f` jump mode:

> Press f to switch to jump mode. Elements on-screen will be prefixed with a two character jump token. Type the characters to jump to the associated element.

https://amp.rs/docs/images/jump_mode.gif


Something similar is available in vim via the easymotion plugin: https://github.com/easymotion/vim-easymotion


For those like me who had never used easymotion before this is the closest I got to replicate amp behaviour (so far) :map f <Plug>(easymotion-overwin-f2)

It doesn't highlight every word with shortcuts first. It does a search based on two characters max and then highlight the results with characters that you can press to move to the corresponding word.


Looks like an implementation of avy from emacs, very cool that they included this in the base!

https://github.com/abo-abo/avy


It's worse than avy because avy (and vim-sneak, evil-snipe et al) allow you to input the prefix char(s). Avy in general is insanely powerful, and abo-abo's set of elisp packages contain some of the most well thought out UX, held back by the rickety shell that is emacs.


Ooh this is promising.

In this particular case, when I see "written in Rust" I hear "uses the Rust ecosystem" which is quite a bit more loadbearing than just the choice of programming language.

Does anyone happen to know if it uses syntect for highlighting? I wasn't able to determine this in the amount of time I have to browse it.

If so, I will be trying this out for sure, I have custom syntax highlighting written in `.sublime-syntax` format and this would be perfect for me.

Edit: Don't want to make another top-level post and I sneaked in under the edit window.

Is there a community for this? I'm trying to get some .sublime-syntax files installed, and I can't find anything amp-specific in either .config or .local/share/

The project is somewhat underdocumented (it's okay, I expected this) and it would be helpful if there were some friendly devs whose ear I could bend as I get comfortable.

If this does exist, it would be a very good thing to link to from https://amp.rs


Looking at the dependencies on crates.io it looks like it does use syntect: https://crates.io/crates/amp/0.6.2/dependencies


Score!

Yeah that would have been the obvious place to look, huh.

I encourage anyone who is skeptical about "what if $app but Rust" to look at the crates here. Ecosystem quality is very important and Rust has good ones.

Consider that wiring together such an app in plain-old-C means inheriting the buffer overflows, memory leaks, thread unsafety, and data races, associated with each and every such library.


I'm really disappointed that the display of a terminal window with blinking cursor wasn't an actual live demo of Amp.


That would be very cool, although I would make it an image link which jumps to a live demo, just to be kinder on the user's bandwidth and CPU.


The user would download a webassembly bundle (compiled from the original Rust) and execute it, similar to most websites. It should be fine.


What's the advantage of writing an editor like this in Rust? And by advantage, I mean an advantage for me, the end user.

I'm quite pleased with neovim and I'm not planning on switching any time soon, so I guess I'm not the target audience for this tool. Then again, who is?


I don't think it makes a differences that it is written in Rust in the same way it does not really matter that Neovim has a cleaner codebase than Vim's in your everyday use of Neovim.

But maybe it will attract Rust devs who are also Vim users in the same Neovim attracted people who are versed in Lua ?

I have been using Vim for a while and learned a lot but I hate to have to configure it and the out of the box experience is really missing much. I don't want to have to have to manage something as basic as my text editor. I want a battery-included modal terminal editor that has (mostly) Vim commands and is easy to use.

Onivim2 is fast and beautiful but it's a gui and it is not finished. Kakoune looks great but I don't want to learn another set of commands as I might to have to use Vim again and don't want to "lose" my habits.

So I am really looking forward Amp 1.0


I recently learned of nvcode: https://github.com/ChristianChiarulli/nvcode. I haven’t tried it yet, but it’s another option in the pre-configured vim space that you might find interesting.


Thanks !


> What's the advantage of writing an editor like this in Rust? And by advantage, I mean an advantage for me, the end user.

None. In fact, Rust software will typically include larger and more frequent downloads for bug fixes, upgrades, and security fixes. The reason for that is that C programs, like vim, can fix bugs and security issues by updating individual dynamic libraries, which are likely to be part of the system. Rust programs can't, because they are statically linked, and this means the whole program needs to be downloaded and installed again. Also, Rust makes it much easier to manage and include library dependencies, which has the consequence that Rust programs in the long run will have an exponentially larger and deeper tree of dependencies, which means that fixes which are needed to fix some bug in a library will be more frequent. This is an effect which can be observed well for other languages like Python or Javascript with npm libraries.

That is probably fine for a web browser (which you basically need to re-install every other week anyways, and which uses auto-update for that), and might not have too much impact for a small tool, but once a program accumulates a large set of functionality and complexity (and therefore has more dependencies) let's say like Gimp, OpenOffice, VLC, or FileZilla, this is likely to become noticeable.

Another thing which might or might not be an issue is that software which is very fast-moving, and in rapid development, and adopts to breaking changes in its dependencies (as the Rust development model supports) is also a bit more likely to breaking changes in its own user interface, APIs and features. The reason for this is that with the included bundling of pinned library versions into the Rust executables, there is much less pressure to keep a stable API, as when software is composed of individual components which are used in many places with a strictly-defined API. This is actually not necessarily the case, it depends on what the software's authors promise (and keep) to its users. And breaking changes are very often an inconvenience for users; users and developers of software tend to have somewhat differnet opinions on how much friction and breakage is OK in order to get upgraded software.


I heavily disagree with most of this comment. Static linking verses dynamic linking is a trade-off, and despite the shared bandwidth disadvantage and the difficulty of replacing the dependencies of a statically-compiled binary, there are a lot of advantages - primary of which is ease of distribution. Because the binary is mostly self-contained, it's far easier to install, can work in more environments and less likely to break as time passes and the systems around it change. These advantages greatly outweigh the disadvantages when developing g the program, for self-explanatory reasons, but also when distributing it. Many developers in languages where dependencies aren't included within the built asset bundle them anyway when distributing them because of this.

In regards to your second point, I will point you to the oft-linked https://wiki.alopex.li/LetsBeRealAboutDependencies .

Finally, your third point. Although much of the ecosystem is changing at a rapid pace, core and major packages, the ones most directly depended on, have either made very strong commitments towards stability, have a proven track record of having few or no breaking changes or both. Additionally, due to the nature of the package manager (and static linking), it's very easy to freeze the churning sections of the ecosystem for your application, use the important dependencies and even patch bugs you're encountering.

Additionally, the fact that rust's ecosystem is advancing at a rapid pace means that, well, it's advancing at a rapid pace. Most packages are high-quality and useful, and many are hugely advanced from what other languages have to offer, like the serde and regex crates. This reflects on the applications built with these libraries - you're probably heard of ripgrep, originally built almost purely to test the regex crate, or JQL, built on serde_json. There are many more amazing crates than I could possibly mention, and many more software projects like OneSignal's notification systems that showcase the amazing way the projects in the Rust ecosystem have been put together.

In short, most of the downsides that you mentioned are really mostly positives, and these positives do affect the applications a lot. Rust does have negatives, but it has plenty of positives, all of which have very concrete effects.

This is a bit of a wall of text, but your first paragraph irked me. Also, Gimp, OpenOffice and VLC are already huge. I don't use FileZilla, but I would expect similar.


> Because the binary is mostly self-contained, it's far easier to install, can work in more environments and less likely to break as time passes and the systems around it change.

That can't be the whole story, otherwise we would not have operating systems, or at least, we would not have anything more than a kernel with nothing on top. There are good reasons for software to be a part of a common system, for example when you want components of the software to integrate and communicate with each other. For example, you probably do not want to log-in to each app again with the same user name.

This is different from a web browser, which, in a way, is an operating system and a platform, and requires relatively little integration with the surrounding system (in these times, often not even a PDF reader). But as a consequence, you have something which is called "inner platform effect", and I think there are few places where this term is more appropriate than in web browsers..


> Additionally, due to the nature of the package manager (and static linking), it's very easy to freeze the churning sections of the ecosystem for your application, use the important dependencies and even patch bugs you're encountering.

Bug fixes are rarely back-ported, and if one wants to use new features, it is all too common to force an upgrade onto an partially incompatible version. And it is an open secret that most software users to not like that. They do not like change because they pay most of the cost.

The right way to do this is to have instead long-term backwards-compatible, ultra-stable APIs, and do development on these. And one cannot say that this isn't possible - this is precisely what the Linux kernel does.


> In regards to your second point, I will point you to the oft-linked https://wiki.alopex.li/LetsBeRealAboutDependencies .

This is not a convincing argument. Rather, it confirms that there is a general problem: As its first example, the post points out an exemplary C++ program, RViz, that has 36 direct dependencies, and 133 total dynamic dependencies. The second example, VLC, has 495 dependencies.

Yes, it is written in C++. Does this prove that a high number of dependencies is not a problem? No. For example, here is a list of security issues in VLC (and I do not think it is exhaustive):

https://www.cvedetails.com/vulnerability-list/vendor_id-5842...

One can bet that the number of general bugs is much higher since a security issue is just a special type of bug. So, do you want to download a new image of a rust-written VLC every time there is a bug or security issue discovered in one of the dependencies? Another regular browser update just for the video player? And another regular fat download for the Rust version of vim? Perhaps on program start?

What can be clearly observed is that in larger programs, the number of dependencies is growing more or less exponentially and that is becoming, or will become, very difficult to manage within the next few years.

This is a general tendency, and it is only going to get worse. Take kubernetes: https://lwn.net/Articles/835599/, as an example. Or tensorflow. This is clearly not sustainable.

And this causes complex problems. A very easy example is what happens if you have a program which depends on two libraries, which both in turn depends on a third library, but only allow for different versions. Vendoring or bundling into static libs is not going to solve that - the only solution is a strict adherence to backwards-compatible components.

Bundling everything as static compiled-in libraries is only going to make the problem worse. It sure makes it easier to produce a program at first, but it makes it more difficult to maintain it. But maintenance is most of a program's life cycle and work included.

And the fact is that the snowballing, exponentially rising number of dependencies also will dwarf completely the effect of Rust's better memory security as a language. If the result is very good, Rust might avoid 90% of security issues. So it might have one-tent of the number of errors in the first place, but this would not help in a near future where complex applications will have more than thousand or several thousands of dependencies. One-tenth of the number of serious bugs in VLC is still a large number, for something that handles untrusted input. This just is going to become unmanageable, if it isn't already. Making it easier to include dependencies is not the solution, and including dependencies as static libraries is not helpful for end-user systems.


I guess the one advantage is, that you learned Rust really well while creating the editor?

Oh and of course if the editor interacts with anything web, less exploitable buffer overflows and other memory errors come free woth it.


It could potentially be easy to compile it together with all your extensions and configs into a single executable you can then just download on your servers/containers/whatever. I would definitely try it out (if I wasn't an Emacs user :)


I love Rust. I hate when people dismiss things as soon as they see it's written in Rust. But there's no reason for it to be a selling point here. You can have that info as one of the notes on the page, but the key selling point in the title shouldn't be that it's written in Rust.


It's a selling point if the code is more about being reading material than being a daily driver


There's nothing on here to say why this is better than just running vim in the terminal. There's literally not even a list of features or anything to highlight how this is different.


It says inspired by vim but it isn't vim compatible?

I am pretty much confused. I heard that Rust community likes to remake everything in Rust, so I guess I can put this in that bucket.

Like, we have NeoVim that is pushing the Vim boundaries. This doesn't seem to be trying to do that.

I think, as an effort, it is probably very educational to make editor. As a product, it might not be for actual Vim users. As you know Vim is plenty fast, with NeoVim unblocking operations, we have our problems and challenges solved.

Clearly Rust is fantastic language I and other devs should pay attention to and learn as it inspires people to make things.


I was thinking the same. There is some cool new stuff in this space (ie Kakoune), which probably is actually somewhat more ergonomic to use than vim/neovim. And maybe this is slightly faster than vim, although vim isn't exactly the kind of program where people complain about it being too slow. But to try to upturn the anthill for a 10% improvement in any direction, on an already excellent product, feels like a mistake.


Seems like a lot of defaults are maybe too tightly coupled with the preferences of the authors. These, for example, are weird:

> Scrolling up/down in normal mode uses the , and m keys, respectively.

> The R key can be used to copy the current file's GitHub URL

> p - Paste at the cursor, P - paste on the line above


Agree about the second one, that seems weirdly specific, but , and m for scrolling seems reasonable enough and p/P for pasting is the same as the vi family.


Does anyone know how this compares to https://github.com/redox-os/sodium besides the fact it is still being actively developed?


Tested this today.

- Opening anything larger than a megabyte causes long load times (compared to `vim` and other editors), as well as extreme lag before each cursor movement.

- The code, relying extremely heavily on various Rust libraries, is extremely difficult to read due to how it's organized: directories like "view" (which doesn't contain source code pertaining to rendering any actual characters), "models", "modes", etc.

- The "jump" feature is good in theory, but in practice is significantly slower than simply continuing to move the cursor normally, as it only works with tokens currently on the screen.

- Opening any files in the editor requires the construction of an index so that it can search for things for you. This runs seemingly-unending on both the `/home` and `/` directories.

- Does not include very many `vim` commands, and therefore shouldn't be called "vim-like." Cursor movement uses "hjkl," but otherwise, the editor is used in a very different manner.

- Does not support any plugins, extensibility, of any kind (that I could find).


Relatedly, there's an Emacs-like editor written in Rust called Zee: https://github.com/mcobzarenco/zee

Zee makes some claims about speed, "The 100 FPS editor. Cursor movement and edits render under 10ms." I do not know how to evaluate whether those claims are true.

I've become used to using Micro (written in Go) for everything: https://micro-editor.github.io/

So I haven't really used Amp or Zee much, but I do have both installed on my system just in case I get bored of Micro ;-)


Very cool, has some interesting ideas!

Things I love:

- Many common operations are a single keystroke - saving, switching buffers, opening a new buffer. Simple design choices like this make the editor feel incredibly fluid.

- Jump mode is very cool

- Using interactive search for commands and opening files

Things that I miss most coming from vim:

- text objects

- paragraph motion.

- Jumping back to the previous cursor location - often useful after a search.

Overall, I think the decision to neglect almost all motion commands in favor of focusing solely on jump mode, w/b and hjkl, is mistaken. While f is undeniably fast for many operations, there are cases where it performs terribly.

Suppose I want to move a function somewhere else. In vim, I'd probably do something like `{d}` - move to the start of the paragraph, delete til the end of the paragraph.

By contrast, Amp's jump mode kind of implicitly assumes I want to be on the start of some word. It's difficult to quickly jump to an empty line. I have to hit f, enter the character pair for the first target in the paragraph, then hit k. Then I go v, hit f again, go to the final target in the paragraph, press j, and finally hit d. That's a 3 character operation that can be performed with muscle memory, to a 10 character operation that prompts the user for input twice, both times forcing them to slow down to visually locate a point near where they actually want to go. That's a pretty massive useability regression. It'd be good to see some better navigation options for use cases like this.


Was trying to figure out why it had openssl as a dependency. Apparently it doesn't anymore: https://github.com/jmacdonald/amp/blob/8b917ac720e7513e5c5bc...


Not really into Vi, but thank you for using this name for something better than whatever Google might want to do with it.


One of the big advantages of VIM is that it's ubiquitous. This has some potentially more intuitive features, but I when I'm setting up a new system, it's not there.

It's VIM-like... but just different enough where it seems like it would be infuriating in practice if you had to even occasionally cross between the two.

I like that they chose to use an existing format for language bindings. Sublime bindings are pretty decent. Less clear is how you would integrate something like prettier. I suspect that's not even possible right now.

I like built in fuzzy search a lot (not sure I like this specific implementation, but a lot better than nothing).

I would love to see something like this, but that sticks more closely to VIM in terms of default bindings and features.


And here I am still trying to get familiar with Kakoune: https://kakoune.org/


I guess would be relevant if it was a proper vim implementation in rust, otherwise it wouldn't add anything a part from rust and immaturity.


Does it have something like vim-surround?


That's definitely a killer feature for me.


This editor is missing way too many vim helper shortcuts to claim to be vi-like, maybe vi-inspired would be better wording. That being said, the editor looks really nice and jump mode feels extremely intuitive; I might give it a full shot once they get language server support


Vim isn't vi. You don't have to have many features to be "vi like". That said, the site itself doesn't say "vi like". Their wording seems close to what you're suggesting.

"Amp is inspired by Vim's modal approach to text editing, which is reflected in several of its default key bindings. That similarity aside, there are several key differences". https://amp.rs/docs/

Edit: The amp key bindings: https://github.com/jmacdonald/amp/blob/8b917ac720e7513e5c5bc...


The title of the post says a "vi-like terminal editor," and distinguishing vi vs vim is missing the point--I'm not talking about extensive plugin support or features that are specific to vim, the base keymappings are pretty different.


The installation dependency list is missing libxcb.


It could be the default editor for RedoxOS


OK, now would someone please rewrite "gedit" in Rust, and make it stop crashing on large files.

I use "vim" mostly for looking at log files in the gigabyte range.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: