
Amp – A complete text editor for the terminal - sphinxc0re
https://amp.rs/
======
mario0b1
>A modal, keyboard-driven interface inspired by Vim that makes navigating and
editing text fast.

But what does it do different than vim? Having competition is good, but I
don't see any "that's why you should use amp and not vim"-reason. Where is it?

~~~
tbrock
I thought it was pretty clear actually: it works out of the box with no
configuration (batteries included).

> Amp is complete from the start.

As a long time vim user, the more advanced you get the more customized your
vimrc and plugins become and you aren’t able to just walk up to vim somewhere
else and be efficient (pairing with another vim user becomes impossible).
Shared defaults are a powerful thing! Convention over configuration.

Imagine we even both like using the nerd tree plugin but can’t agree what the
leader key should be mapped to in order to activate it: a common problem.

That’s why you see the most advanced vim users go back to a minimal vimrc
which admittedly makes it a less useful editor.

I think we can all agree vims defaults are crap and without plugins it doesn’t
have all of the features of a modern editor.

~~~
phlyingpenguin
> it works out of the box with no configuration (batteries included).

You don't really believe that, do you? Competent users tend to have
preferences. There's no need to worry about installing plugins if you have to
have a .vimrc to begin with, just have the .vimrc do the installing as well.

~~~
ronjouch
Sure, but _" Competent users tend to have preferences"_ doesn't exclude slow
evolution of sane-by-default preferences for programs part of a same class. A
newcomer text editor, say, comes in town, settles its default configuration as
the sanest of previous generations, while existing programs of the same class
are (reasonably!) stuck due to compatibility.

Which means newcomer text editors need less configuration, and users generally
staying closer to the default stable, tested configuration.

You can argue that you're part of a margin needing XYZ specific setting, or
that new programs don't necessarily make good default config choices. To me it
feels generally reasonable to believe so.

Case in point, with text editors / light IDEs. I did Sublime Text -> Atom ->
VSCode. At each step, the size of my config size decreased. Of course I still
have a VSCode settings.json, but it's twenty lines. My sublime prefs are ~100
lines, my .vimrc is hundreds :)

~~~
phlyingpenguin
The plugins you need to make Atom/VSCode great (no experience with modern
Sublime) definitely count as configuration in my book, and often come with
their own configuration load. If I sit down at a new machine, they won't be
there. Most of my .vimrc is a couple of lines per plugin configuring the
plugins, for example.

~~~
wasted_intel
You're going to get a fuzzy file finder, Git integration, syntax highlighting,
symbol navigation, _and_ and a package manager immediately available to you in
those editors. None of those are available in Vim by default; that's the
inspiration for Amp.

There are additional perks to including things by default, too. Jump mode is a
good example of that: it's integrated with its select mode. You can start a
selection and then switch to jump mode to move the cursor to complete the
selection.

Lastly, there's simplicity in including things rather than asking new users to
pick from a dizzying array of plug-in options. Rails is a good example of
this: there's a lot of functionality that could have been left to 3rd-party
gems, but having the framework include them by default means they'll work out
of the box, and there's a single canonical solution to [sessions, templates,
ORM, routing, etc].

~~~
kingosticks
I don't disagree with your approach but I'd just point out, since it's a
little ironic, that rust's standard library is a good example of the opposite
approach!

~~~
wasted_intel
You're absolutely right. :)

I'm going to resist adding everything but the kitchen sink to Amp. Upcoming
features like tasks and language server protocol support will allow Amp to
integrate with language/framework-specific tools as easily as possible, but
without steering Amp towards any specific choices. I couldn't avoid that with
syntax highlighting; it's just too essential (and it powers the symbol jump
mode). It's definitely a balancing act!

------
mariusmg
Micro is nice too
[https://github.com/zyedidia/micro](https://github.com/zyedidia/micro) (been
using it daily for a few months now).

~~~
GordonS
I recently discovered this too. I'd been using nano as my default terminal
text editor for years, but micro is a nice upgrade - I especially like the
undo feature, the syntax highlighting, and the mouse support.

~~~
WalterGR
> “the undo feature”

What do you mean? The persistent undo?

~~~
GordonS
Yep

------
craftyguy
Unfortunately this project is unbuildable on a system with Python 3.7, because
it builds termbox, which has an old version of waf that does not support
Python 3.7..

[https://github.com/nsf/termbox/issues/117](https://github.com/nsf/termbox/issues/117)

Edit: Looks like the amp developer is taking steps to remedy this, great!

[https://github.com/jmacdonald/amp/issues/113](https://github.com/jmacdonald/amp/issues/113)

------
apas
Installed it and played around for a bit. Nice work overall. Amp's jump mode
(press `f` and elements in the buffer will be prefixed with a two character
jump token) is pretty cool. Would love to see this in Vim.

~~~
michaelmrose
The irony. Easymotion was created as a better precisejump. Precisejump was
created or at least uploaded in Feb 2011.

~~~
nickspacek
It's funny isn't it. I guess I don't try hard enough to find productivity-
enhancing Vim plugins. I've tried various "Vim enhancement suites" intended to
bring a number of useful plugins and had some success, but since I can't rely
on them on new servers I find myself more often than not just using plain Vim.

Some other commenters in the thread have raised the point that having more
supported functionality out of the box is a good selling feature. To me it
seems that having it built it can (possibly) benefit from a more intentional
effort to make it cohesive, whereas with many disparate plugins you have to
encourage, force, or otherwise guide developers to build something that fits
and behaves with the rest of the platform.

~~~
wasted_intel
You've touched on an important point: taking inspiration from workflows and
incorporating them into the core editor itself.

For editing text, there's already a lot of flexibility in Amp's keymap
system[0]. As users compose more sophisticated/useful macros, we can promote
them to the default keymap, and if they're _really_ useful, we can build them
as discrete commands in Amp itself. That way, the core editor evolves to
encourage a particular workflow. It's opinionated, and it may not appeal to
everyone, but that's kind of the point.

[0] [https://amp.rs/docs/configuration/#multiple-
commands](https://amp.rs/docs/configuration/#multiple-commands)

------
throwrhebrick
I honestly don't know why people would want to navigate code using jump-
mode/easymotion. I've found it far more confusing than just searching for the
word.

~~~
vectorEQ
ctrl+W <word> enter - seems you are right :D <3 nano hahah i find more
complicated editors just distract with their fancies from what you are doing.
inputting and deleting characters.

~~~
laumars
It's just a learning curve. Over time it starts becoming second nature and you
don't even notice that you're doing it. Must like most things we do in our day
to day that are actually rather complication functions (driving, writing,
walking, etc).

What I do like about the vim keys though is the ability to delete or
copy/paste with precision by chaining hotkeys together.

Regarding your searching for a word example, unsurprisingly you can do the
same in vi (let alone vim) too:

    
    
      / - search forwards
      ? - search backwards
    

edit: It wasn't me who voted you down by the way. I know you've not complained
about it but I wanted to express that I don't agree with you getting downvoted
even though I don't agree with the content of your post.

------
CraneWorm
I think I'm too into vim to like this now. I miss more "advanced" gestures,
like: daw, caw... Not being able to edit a word without positioning caret at
the beginning feels limiting.

~~~
wasted_intel
I know this defeats the purpose of minimal configuration, but you can define
those kinds of actions fairly easily by defining keymaps that compose multiple
commands[0]. For what you're after, you could do this:

    
    
      keymap:
        normal:
          W:
            - "cursor::move_to_start_of_previous_token"
            - "buffer::change_token"
    

You can view the default keymap right in Amp, too, as well as a list of all of
the commands. Happy to entertain a PR that sets that as a default keymap going
forward. :)

[0] [https://amp.rs/docs/configuration/#multiple-
commands](https://amp.rs/docs/configuration/#multiple-commands)

~~~
CraneWorm
Thanks, I'll try it out. Maybe I'll drop you a PR if I have time :).

------
ecthiender
The documentation or the website doesn't list all the languages it supports,
especially for jump to definition. It just says all popular languages. This is
a bit concerning, because the docs also mentions no (planned) support for
plug-ins yet.

FWIW, I'm interested in Haskell support. For jumping to definitions and
showing type of expression under cursor.

~~~
Karliss
First page under symbol jump states that it is based on and can be extended
using .sublime-syntax format. At this point of time I was expecting language
server protocol support.

~~~
wasted_intel
LSP support is planned! Although, the rationale for including it is for
advanced language features, like "go to method". I'd be surprised if other
editors were using it for syntax highlighting. I've had to jump through hoops
to keep that performant on large files. Seems like putting that in a separate
process would make performance even more of a challenge.

I found this after a quick search: [https://github.com/Microsoft/language-
server-protocol/issues...](https://github.com/Microsoft/language-server-
protocol/issues/33#issuecomment-231883169)

------
carlmr
It says you only plan UTF8 support and no Windows line endings. The windows
line endings ok, and I get why in Rust it was easier with UTF8 (although there
are some good crates for handling encoding). However this seems awfully
restrictive to me.

~~~
the_clarence
It’s a start

~~~
carlmr
If it's a start it should still be planned though.

~~~
wasted_intel
I've mostly built Amp to fit into my workflow, which is unix line-endings &
ASCII/UTF-8 at the moment. Not opposed to alternative encodings, but I think
that's a non-trivial addition. Amp uses a gap buffer under the hood and
avoiding segmenting multi-byte UTF-8 graphemes/grapheme clusters was tricky.
It's definitely possible, it just hasn't been a priority, _yet_.

~~~
jimsmart
Arguably this is somewhat of a kludge(?), but one option (which would involve
less coding than making the engine work with different encodings) would be to
use readers/writers to support other formats, and keep using UTF-8 internally.

UTF-16BE/LE and UTF-32, plus Windows CPs, are all really easy to do like this
— probably others too.

(Note that depending on the range of codepoints used in files using these
encodings, they may take more memory in UTF-8 form. This usually isn't an
issue unless one is handling large files of Kanji)

~~~
carlmr
I agree, especially as UTF-8 is standard inside Rust. Also the encoding
library would make it easy enough to support other formats.

I'm not sure if the editor streams or loads into RAM right now. If it already
loads into RAM this is a tiny change.

[https://crates.io/crates/encoding](https://crates.io/crates/encoding)

Line endings should also be unproblematic.

------
speg
Jump mode isn't working for me. It highlights all the two letter codes but
keeps taking me to the same place (not the code I type).

So I tried a new file and then the error message wiped out my sample text.

Also, I don't see how to switch between buffers?

~~~
wasted_intel
Hmm, the jump mode issue is strange; can you please file an issue as a
starting point?

As for the error message, it didn't wipe out your file; it opened a new buffer
with the error message. You can switch between buffers using Tab. There's a
full keymap listing available through a command called
"application::display_default_keymap" that you can invoke by hitting 0 in
normal mode and searching for it.

~~~
the_clarence
I’m on my phone so I haven’t checked. But my biggest grip with vim/emacs is
discovery of new commands (for noobs or experts).

What are you doing to solve that?

Sublime Text fixes this by allowing you to do fuzzy search to access all the
commands (command-P). Once you find your command it also displays the keyboard
shortcut next to it so that next time you can use it instead.

~~~
wasted_intel
You can fuzzy search Amp's commands, or display a buffer with a complete
listing of all of them[0]. You can also view the default keymap[1] right in
the editor.

Hope that helps!

[0] [https://amp.rs/docs/usage/#running-
commands](https://amp.rs/docs/usage/#running-commands)

[1] [https://amp.rs/docs/configuration/#key-
bindings](https://amp.rs/docs/configuration/#key-bindings)

~~~
the_clarence
As you note in there, it isn’t really made for discovery. It’d be great if you
could see the key binding next to the name of a command when you press ‘0’.

Other feedback: fuzzy search doesn’t work well for me. For exemple if I don’t
write the folder name I can’t see the file. If I press backspace it deeted the
entire search.

It’s be great to have “press ?” Or something like that when you open the
editor. Like that you know directy how to see the key bindings.

~~~
wasted_intel
You can press "?" when you open the editor to read quick start guide. :)

As for the fuzzy search, it's working as intended. Have a look at the docs[0]
for an explanation of the matching algorithm, UX, and the reasoning behind it;
it's intentional, I promise.

Love the idea of displaying the key binding next to the command!

[0] [https://amp.rs/docs/usage/#using-the-file-
finder](https://amp.rs/docs/usage/#using-the-file-finder)

~~~
the_clarence
Fuzzy searching still doesn’t work for me. I have a path starting with lib/
and if I write “lib” there is nothing anymore

------
pkulak
That navigation method is genius. Can't wait to try this out.

------
DC-3
This looks interesting, but from either of the AUR or through Cargo directly
the build fails because of a Python StopIteration error in the termbox crate.

~~~
wasted_intel
This is an unfortunate consequence of depending on termbox, which uses Python
as part of its build (waf), which unfortunately doesn't work in Python 3.7. On
Arch, you need to alias python to python2 for the build to work. I'll comment
on the AUR package.

As an aside, my current 0.6.0 feature is moving completely towards termion (a
Rust-based, lower-level terminal lib) that'll resolve that!

------
throwaway487548
The classic ed and its visual version which is called vi are really good-
enough if done right. The central concept here is simple regexps bound to one
key commands, and that these commands compose. This is the reason why vi is
what it is.

[https://karma-engineering.com/lab/wiki/Tools/Neovim](https://karma-
engineering.com/lab/wiki/Tools/Neovim)

The only problem is that all classic vis, including vim, have been coded by
amateurs and the code is a terrible mess.

nvi was good, as far as I remember.

~~~
the_clarence
Wat

------
josteink
Maybe choose another name?

I mean: Good luck trying to out-SEO Google re-using their own term[1] :)

[1] [https://www.ampproject.org/](https://www.ampproject.org/)

~~~
albertgoeswoof
If it’s anything like emacs or vim it will surely outlive Amp and hopefully
Google as well

~~~
ilikehurdles
You say that as if it’s a challenge to outlive something Google puts out.

~~~
littlestymaar
Your comment matches surprisingly well with this other post[1] on top of HN
right now. Which is funny because your comment is 4 hours older than this
submission :).

[1]
[https://news.ycombinator.com/item?id=18509735](https://news.ycombinator.com/item?id=18509735)

------
Jyaif
They should take advantage of wasm and offer a web version.

------
lproven
Is it CUA? If so, I'm interested.

 _Reads page_

> modal [...] > inspired by Vim

 _Closes tab_

------
easytiger
> Amp is inspired by Vim's modal approach to text editing

And I closed the page. Modal editing simply makes zero sense on a modern
keyboard. It is awful.

~~~
otron
In what way is modal editing awful?

Modal editors are the only solution I've come across to what I see as the
problem with modern keyboards and editors: the inability to do everything you
want to do without moving your hands away from the home row. Intellij,
eclipse, sublime text, every "modern" non-modal editor I've used expects me to
move my hands to the arrow keys if I want to move the caret. This is a
personal gripe for me as repeatedly moving my hand back and forth between the
home row, the mouse and arrow keys triggers my RSI. At least a non-modified
bash prompt lets me navigate using some archaic control key combinations (^a:
beginning of line, ^e: end of line, ^f: forward one character, etc.)

~~~
vthriller
> At least a non-modified bash prompt lets me navigate using some archaic
> control key combinations

You can get vi-like navigation in bash with a simple `set -o vi`

