[HN Gopher] Amp: Vi-like terminal editor written in Rust
___________________________________________________________________
Amp: Vi-like terminal editor written in Rust
Author : cassepipe
Score : 131 points
Date : 2021-04-12 14:41 UTC (8 hours ago)
(HTM) web link (www.amp.rs)
(TXT) w3m dump (www.amp.rs)
| cryptoquick wrote:
| Not really into Vi, but thank you for using this name for
| something better than whatever Google might want to do with it.
| jeroenhd wrote:
| 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?
| k_bx wrote:
| 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 :)
| atoav wrote:
| 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.
| cassepipe wrote:
| 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
| memco wrote:
| 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.
| cassepipe wrote:
| Thanks !
| jnxx wrote:
| > 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.
| joelellis wrote:
| 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.
| lilyball wrote:
| I'm really disappointed that the display of a terminal window
| with blinking cursor wasn't an actual live demo of Amp.
| samatman wrote:
| 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.
| nailer wrote:
| The user would download a webassembly bundle (compiled from
| the original Rust) and execute it, similar to most websites.
| It should be fine.
| 3v1n0 wrote:
| 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.
| ziml77 wrote:
| 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.
| brundolf wrote:
| It's a selling point if the code is more about being reading
| material than being a daily driver
| [deleted]
| hermitsings wrote:
| It could be the default editor for RedoxOS
| jchw wrote:
| 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.
| pitaj wrote:
| FYI you should switch to rust-analyzer instead of RLS.
| jchw wrote:
| Actually, I have been using rust-analyzer, I misspoke.
| indemnity wrote:
| You're both right, rust-analyzer will become official RLS
| 2.0.
| cassepipe wrote:
| True but plug-in API for better language support is apparently
| on the roadmap
| Decabytes wrote:
| Does anyone know how this compares to https://github.com/redox-
| os/sodium besides the fact it is still being actively developed?
| johnchristopher wrote:
| 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
| senkora wrote:
| Looks like an implementation of avy from emacs, very cool that
| they included this in the base!
|
| https://github.com/abo-abo/avy
| sooheon wrote:
| 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.
| laixer wrote:
| Something similar is available in vim via the easymotion
| plugin: https://github.com/easymotion/vim-easymotion
| johnchristopher wrote:
| 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.
| samatman wrote:
| 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
| swsieber wrote:
| Looking at the dependencies on crates.io it looks like it does
| use syntect: https://crates.io/crates/amp/0.6.2/dependencies
| samatman wrote:
| 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.
| tyingq wrote:
| Was trying to figure out why it had openssl as a dependency.
| Apparently it doesn't anymore:
| https://github.com/jmacdonald/amp/blob/8b917ac720e7513e5c5bc...
| Exuma wrote:
| 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.
| ogre_codes wrote:
| 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.
| desireco42 wrote:
| 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.
| chrisjharris wrote:
| 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.
| dejj wrote:
| And here I am still trying to get familiar with Kakoune:
| https://kakoune.org/
| skyfaller wrote:
| 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 ;-)
| Animats wrote:
| 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.
| majewsky wrote:
| 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.
| eschneider wrote:
| 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. :)
| chapium wrote:
| 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.
| saurik wrote:
| 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.
| jedisct1 wrote:
| It's written in Rust.
| cassepipe wrote:
| 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)
| otikik wrote:
| 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.
| zabzonk wrote:
| Is this the right place to go into a vim war? Perhaps we
| could restrict this to a discussion of the "amp" editor.
| cjaybo wrote:
| Is a discussion of "Who is the audience for the 'amp'
| editor" not a discussion of the amp editor?
| envp wrote:
| 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
| woah wrote:
| 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
| CoastalCoder wrote:
| 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.
| justusthane wrote:
| Maybe give https://kakoune.org/ a try?
| golergka wrote:
| > 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.
| adkadskhj wrote:
| 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.
| wuxb wrote:
| 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.
| atoav wrote:
| 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, ...)
| HKH2 wrote:
| Kakoune is aimed at multicursor stuff and has relatively
| sane defaults. It shows help dialogues when pressing key
| combos too.
| rapind wrote:
| Genuinely curious why multicursor is a big deal?
| habitue wrote:
| 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
| joelellis wrote:
| 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.
| spartanatreyu wrote:
| 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.
| Jtsummers wrote:
| 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.
| hojjat12000 wrote:
| I think most people don't know that instead of :wq or :q!
| they can just ZZ and ZQ
| cassepipe wrote:
| or just :x
| ckw wrote:
| 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>.
| ogre_codes wrote:
| 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.
| anand-bala wrote:
| As an ex-Sublime and ex-VSCode user, I realized that
| macros and Visual Block mode covers all my use cases for
| multicursor functionality.
| michaelmrose wrote:
| 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.
| timothylaurent wrote:
| 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.
| Majestic121 wrote:
| 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.
| Scarbutt wrote:
| Surprisingly IdeaVim, has become pretty good.
| qw3rty01 wrote:
| 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
| tyingq wrote:
| 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...
| qw3rty01 wrote:
| 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.
| thibran wrote:
| Does it have something like vim-surround?
| kkoncevicius wrote:
| 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
___________________________________________________________________
(page generated 2021-04-12 23:02 UTC)