Amp – A complete text editor for the terminal
amp.rs
amp.rs
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?
> Fast, precise cursor movement without repetitive keystrokes or fancy expressions. Look where you'd like to move, and type the token. That's it.
Digging a bit more, I found this [1] (in addition to the normal h,j,k,l, etc.):
> 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.
> For files with syntax support, you can jump to class, method, and function definitions using symbol mode. Hit Enter in normal mode to use the symbol finder, which works identically to open mode
[1] https://github.com/jmacdonald/amp/blob/master/documentation/...
It's very useful.
It's the new Go.
Rust's "hack without fear" mantra definitely applied here. :)
Kakoune is Vim-like, and now this.
Weird statement. "Best" is up to debate, but "most customizable" is definitely Emacs.
I cannot really imagine a really good non-modal programmer's editor. Surely it should behave differently when editing Python compared to editing HTML?
[1] https://alvinalexander.com/linux/vim-vi-mode-editor-command-...
It's also fairly obtuse for non-experts. A champion non-modal editor would have a learning curve as shallow as nano but more depth that could reveal itself over time.
https://joe-editor.sourceforge.io
You can install it with your OS's package management system, and there's a Windows installer on the site.
I did adjust some of the default settings, which are configured and well documented in a .joerc file.
Bill Joy: “One of the good things about EMACS, though, is its programmability and the modelessness. Those are two ideas which never occurred to me.”
“People don't know that vi was written for a world that doesn't exist anymore.”
In a text editor, user input either writes text to the file or does something else. Every text editor let you write to files so aside from aesthetics, it's the everything else that makes each different. If keystrokes for writing are not separated from keystrokes for everything else, everything else is confined to awkward ctrl- and alt- key combos. That's why it's a good idea to put them in different 'modes' so you can perform other actions comfortably. You don't need more modes than 2. Actually, in vim, you could see command mode and the visual modes as extensions of the normal node. Modes are really just a metaphor.
> 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.
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.
Just install it and use it. Works.
I like projects that provide similar experience.
And that's just for Vimscript plug-ins. There are several situations (e.g. fuzzy file finders) where external binaries are preferable, for performance reasons. The idea is to include those directly in Amp, so that it's _only_ a configuration file that's needed, if at all.
That said, Amp doesn't have plug-in support at the moment, so it's a little unfair for me to judge Vim on that front. But if it did, the package management portion would be baked in so that you'd only need to pull your configuration file and Amp would handle the rest. :)
The best thing is to provide some sensible overridable defaults and basic functionality expected these days from a programmer's editor, such as simple project management: index files, fuzzy file finder, etc. Vim and Emacs are a pain in the butt for precisely this reason: they don't take ANY decision, they just throw the entire burden on the user. They're forgiven because they're classics, but any kind of editor launched in 2018 would be utterly ignored if it didn't have these features.
I don't think so. I've never felt that having 10 linux distributions was a problem, I just can pick between at least two super robust choices : Debain, RedHat. I can even choose between inkscape, krita, gimp. Or KDE and Gnome...
You can argue that progress would be faster if we have less choices but more choices also means more developpers...
See https://en.wikipedia.org/wiki/Overchoice and https://en.wikipedia.org/wiki/Analysis_paralysis
This is BTW no limited to OSS but AFAIK it comes from sales-research. People confronted with to many products of similar type can end in a deadlock, avoiding those products or even start to avoid the whole category.
> You can argue that progress would be faster if we have less choices but more choices also means more developpers...
More developers reinventing the wheel doesn't automatically make the wheels faster. It can mean healthy competition, but it also can mean wasted ressources. It's case by case.
On the other hand it can hurt - for example I'd like to have my main workstation running mainly one gui framework. (Or at least, most of the software). But the KDE/GTK split makes the most popular and sensible software to use for most cases pretty much evenly distributed between those two. (Though this is obviously not a major issue, just an example).
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 :)
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].
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!
As for a file finder, I'm curious how you can use a separate tab to open that in the current instance of Vim? From when I'd last used it, most folks were using Ctrl-P to solve that problem, and usually with an external indexer like fzf or ag.
And whenever I need to use somene else's emacs, it's even simpler : there's no emacs in the real world :-) (neither vim :-)) I mean those are "niche" editors, not used in huge parts of the IT world. So worrying about their ecosystem is a bit, well, exagerated, imho.
I don't use stuff like NerdTree (I used to, but ended up not liking it), and mostly just stick to the features that come with it. As such, I can be very productive without much configuration at all, which is much of the reason I used vim in the first place.
I don't want another spin of vim because I lose one of its biggest benefits: ubiquity. The further I deviate from the base configuration, the less useful having vim available everywhere is.
Amp's additional features are really geared towards project-based development, so ubiquity isn't as much of a concern; it's not meant for editing sporadic config files on your server. Vim is still a great fit for that, at least until someone gets Amp adopted into the main Ubuntu server repositories. ;)
That's a pretty big missing feature that is included in vanilla vim...
I may also want to ctrl-z Vim to run a few quick commands before resuming Vim with fg. Using tmux panes, I'd only get a small window to run those few commands, which doesn't reflect my intent. (Yes, I could use another tmux window for this, but I like this way.)
I suspect it would also mean more keystrokes.
Amp also supports suspending (hit "z" in normal mode) as I use that workflow all the time. As for the small window issue, you can "zoom" a tmux panel with <leader>-z. I get that this is less than ideal if you're used to the suspend action collapsing all panes by default (and expanding them on resume). Workflows are tricky; to each their own, I guess! :)
By "native" does that mean an X-server's clipboard? So when you're running it on a machine that has no X-server running (a typical server), there is no clipboard?
In that scenario, I would compromise by opening both files in the same Amp process and switch between them, but that's not the same as seeing both at the same time.
greetings, eMBee.
sure i can make that work with tmux. codewise it would even be easier, but only if i can trust the user to put all the pieces together for themselves.
if i want to build an end-user friendly package, the whole thing suddenly becomes a lot more complex:
it's no longer enough to say: load this into vim and you are done, but i need to check that tmux is not only available but that the editor is running inside it as well. and i have to prepare that users will ask me to make this work with screen or any other tmux alternative.
greetings, eMBee.
The only thing that's bespoke to tmux is knowing which pane to target; you'd need to collect that from the user on the first run, or allow the value to be configured.
The popular irc clients (terminal-based) like ircII used to require a lot of configuration and setup to get going. Eventually irssi appeared, with sane out of the box defaults, including a dash of color.
I always thought we needed something similar for text editors.
Is this something people do? I use a handful of machines and use git+stow for managing my vimrc. I've never had this problem where I need to "walk up to vim somewhere else" where I wouldnt just clone my dotfiles and stow my vim config. Takes all of 10 seconds and I'm up and running.
Complexity increases when you want one vimrc with many plugins to work on Windows, Linux and OS X, and both in your work and home environments.
I'm not arguing that Amp is the answer. I don't think I'd stick with vim as my daily driver if I couldn't customize it, and have the plugins I do.
Since checking on every terminal open is unnecessary, I check on a probabilistic basis based on how often the backing git repo changes (0.5% - 3%, different repos for vim, dotfiles, configs).
I just do this minimal configuration on starting vim:
:se et ai ts=2 sts=2 sw=2
EDIT: Key to that is not being so reliant on plugins, of course. I used to use a lot of plugins, but then focused on learning more of stock vim features, and doing more things in the shell. I now feel more productive without the plugins.
For example, I used to use NERDTree, but now I opt for using :e's path syntax. I don't get lost looking for files in the tree, scrolling around, opening directories. I just type stuff like :e %:h/fi<tab><enter> or :e %:s?local?global?<enter> to get straight to where I want without having to look at anything. I can probably work in vim blind-folded without a productivity loss (the only problem being remembering enough of the files I'm working on) and I find that awesome.
Actually, no. This is not clear at all looking at the website. Unless you assume that vim does not come with "batteries included", which sounds wrong to me. I for one use "raw" vim, without plugins nor configuration, and I am very happy with it.
(Strictly speaking, this is false: I have "set t_ti= t_te=" in my .vimrc so that the screen is not cleared when I exit, but I suppose this kind of fringe features are OK to be user-specified).
Oh wow, this is super helpful. Thank you!
Neovim (https://neovim.io/) makes a thing about how it's got "strong defaults" but there's got to be the least compelling reason to use it.
Newcomers to vim are generally encouraged to use it as-is and make their own config changes as and when they need to, and experienced users will have config which gets enhanced to meet whatever circumstances they're confronted with, but none of this requires a completely different editor.
That said, I think it's pretty clear one of the first things I need to add to the website is an answer to "why would I use this instead of Vim"?
Vim works out of the box (heck, even old-school vi did.) Amp seems to provide more out of the box, but also explicitly states plans a runtime and plug-in support for extensibility, so apparently it still recognizes that complete out of the box is an unattainable goal given diversity (and conflict) of user needs.
What do you mean? The persistent undo?
https://github.com/nsf/termbox/issues/117
Edit: Looks like the amp developer is taking steps to remedy this, great!
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.
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.
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
…Isn't the answer "neither"?
If the cursor is somewhere before that `h`, then doing `fh` will put the cursor on that `h`. If you want to enter insert mode before that `h`, you would press `i`, or `a` to enter insert mode after the `h`.
In the case of 'ct', you're going to delete up until the letter, whereas in 'cf', it will include the letter you're targetting.
> The question is, when using a command like "change until" or "change forward", i.e. 'ct' or 'cf', what will the effect be?
Is this a question? You answered it accurately. The behaviour is consistent here too, though the mnemonics people often use don't always make total sense.
"change find", you mean.
Is there any official reference to it standing for find? Googling has found a few unofficial references, but help doesn't appear to say either way.
> One of the most useful movement commands is the single-character search command. The command "fx" searches forward in the line for the single character x. Hint: "f" stands for "Find".
That seems official.
keymap:
normal:
W:
- "cursor::move_to_start_of_previous_token"
- "buffer::change_token"
FWIW, I'm interested in Haskell support. For jumping to definitions and showing type of expression under cursor.
I found this after a quick search: https://github.com/Microsoft/language-server-protocol/issues...
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)
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
Line endings should also be unproblematic.
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?
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.
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.
Hope that helps!
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.
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!
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!
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.
I mean: Good luck trying to out-SEO Google re-using their own term[1] :)
Reads page
> modal [...] > inspired by Vim
Closes tab
And I closed the page. Modal editing simply makes zero sense on a modern keyboard. It is 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.)
You can get vi-like navigation in bash with a simple `set -o vi`
0. besides adding backlights, changing build quality, and perhaps other layout options like dvorak or colemak, keyboards have not really changed in decades...
Humans don't generally deal well with inconsistencies. I can type on Dvorak and QWERTY, at decent speed on both, but mostly type on Dvorak. Typing QWERTY gives me a bit of mental fatigue from continuously overriding my Dvorak-typing circuitry.
I can feel a less extreme version of that mental fatigue from using modal editors. Just a growing irritation as I hit keys in the wrong mode, which happens at a fairly constant rate throughout the editing session.
I used vim for several years, and honestly, I never found anything faster for editing (though, not so much for writing, but very efficient at throwing around and manipulating anything you don't already have done.)
I don't use it for the same reason that I take the slightly-longer-but-much-less-congested route to work. The annoyance of stop-and-go traffic costs me more mentally than those extra minutes.