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.
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.
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.
> 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.
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
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.
> 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.
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.
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.
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.
- 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.
- 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.
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.
[+] [-] jchw|5 years ago|reply
edit: rust-analyzer, not rls.
[+] [-] cassepipe|5 years ago|reply
[+] [-] pitaj|5 years ago|reply
[+] [-] majewsky|5 years ago|reply
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.
[+] [-] otikik|5 years ago|reply
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.
[+] [-] eschneider|5 years ago|reply
[+] [-] cassepipe|5 years ago|reply
I think the aim is really to have a battery included terminal modal text editor (with some common Vi bindings)
[+] [-] chapium|5 years ago|reply
[+] [-] jedisct1|5 years ago|reply
[+] [-] johnchristopher|5 years ago|reply
> 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
[+] [-] laixer|5 years ago|reply
[+] [-] senkora|5 years ago|reply
https://github.com/abo-abo/avy
[+] [-] samatman|5 years ago|reply
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
[+] [-] swsieber|5 years ago|reply
[+] [-] lilyball|5 years ago|reply
[+] [-] samatman|5 years ago|reply
[+] [-] jeroenhd|5 years ago|reply
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?
[+] [-] cassepipe|5 years ago|reply
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
[+] [-] jnxx|5 years ago|reply
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.
[+] [-] atoav|5 years ago|reply
Oh and of course if the editor interacts with anything web, less exploitable buffer overflows and other memory errors come free woth it.
[+] [-] k_bx|5 years ago|reply
[+] [-] ziml77|5 years ago|reply
[+] [-] brundolf|5 years ago|reply
[+] [-] Exuma|5 years ago|reply
[+] [-] desireco42|5 years ago|reply
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.
[+] [-] chrisjharris|5 years ago|reply
[+] [-] kkoncevicius|5 years ago|reply
> 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
[+] [-] sullyj3|5 years ago|reply
[+] [-] Decabytes|5 years ago|reply
[+] [-] benbenolson|5 years ago|reply
- 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).
[+] [-] skyfaller|5 years ago|reply
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 ;-)
[+] [-] sullyj3|5 years ago|reply
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.
[+] [-] tyingq|5 years ago|reply
[+] [-] cryptoquick|5 years ago|reply
[+] [-] ogre_codes|5 years ago|reply
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.
[+] [-] dejj|5 years ago|reply
[+] [-] 3v1n0|5 years ago|reply
[+] [-] thibran|5 years ago|reply
[+] [-] sullyj3|5 years ago|reply