Amp: Vi-like terminal editor written in Rust
amp.rs
amp.rs
edit: rust-analyzer, not rls.
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.
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.
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
I'm still curious what was special about my environment, since it seems to work for most people.
<esc> :wq
:q
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.
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
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.
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
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.
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.
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.
It lazy loads everything and supports most languages, has help throughout, and a responsive community for any issue you may encounter.
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.
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.
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 really want to like Vim again though, for Onivim (2). Looks so pretty.
yeah there's nothing like it. but vim is just so polished and the vim-keybinding ecosystem is so big.
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.
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.
I think the aim is really to have a battery included terminal modal text editor (with some common Vi bindings)
> 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.
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.
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
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 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?
Oh and of course if the editor interacts with anything web, less exploitable buffer overflows and other memory errors come free woth it.
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
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.
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.
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.
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..
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.
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.
> 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
- 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).
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 ;-)
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.
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.
"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...
I use "vim" mostly for looking at log files in the gigabyte range.