Hacker News new | comments | ask | show | jobs | submit login
Amp – A complete text editor for the terminal (amp.rs)
281 points by sphinxc0re 85 days ago | hide | past | web | favorite | 165 comments



>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?


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.


> 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.


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 :)


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.


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].


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!


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!


Vim doesn't have syntax highlighting? News to me. Git and file finder is available to you by opening a new terminal tab/window and simply using git/standard unix utils. There's no need to integrate such features when you can extend a terminal into an IDE as your needs suit.


Vim has very simple highlighting, and doesn't support symbol jump; that's why ctags is an external dependency for that behaviour.

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.


Fragmentation also hurts the ecosystem. Just look at Linux distributions or desktop environments to see the effects.

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.


>> Fragmentation also hurts the ecosystem. Just look at Linux distributions or desktop environments to see the effects.

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...


Choice is a process which can hurt when it takes too long or when you lack the ability to execute the process itself or in a good manner.

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.


yup, now that I read myself again, I see my bias. For me, more developpers working on several "identical" GPL'ed software makes the viability of the GPL software better... So, well, I'm biased :-)


On the one hand, I agree. I've spent whole days just checking out software alternatives, booting new distros, DEs, hosting webapps, just to see what they were like, and it's always great fun.

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).


It definitely hurts mainstream adoption. And it also kills distribution of most commercial desktop applications.


Amp, and convention over configuration in general, don't prevent configuration, they just try to avoid it. There are a bunch of things you can configure in Amp, if you'd like: https://amp.rs/docs/#configuration


That's not really what I was doubting (I could see that). I just doubt that it's likely to not need a configuration file if I were to replace vim with it. In GP's assertion that this is the best reason to use Amp over vim, that's not really a huge benefit in the end. A config is a config is a config, or something to that effect.


Unfortunately, configuring Vim is rarely just pulling a config file. Pathogen and Vundle have made installing/tracking plug-ins easier, but unless things have changed, those tools required their own bootstrapping outside of simply being referenced in the config.

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.


All depends on your taste. My .vimrc handles ensuring that I have a plugin manager installed and that it installs those plugins on my behalf if they aren't there. And I do all of that in ~10 lines of vimL config. It's totally reasonable to have your plugin/config ensure the external binaries exist as well. The popular golang plugin has a command for that.


It ensures you have a plug-in manager installed, but it won't install it for you, right? I know that might seem like a minor nit, but if package management is considered an essential part of Vim, I'm of the mindset that it should work out of the box.

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. :)


No. I have it install the manager. Literally all I need is the .vimrc and to start vim.


I have not tried amp yet, but just as an example why I switched shell. I use fish shell because of the sane defaults. I don't want to be bothered with setting up code completion and history size.

Just install it and use it. Works.

I like projects that provide similar experience.


Yes, fish shell is a beautiful example of that philosophy! Its design documentation[0] reflects a lot of the values that drove me to create Amp.

[0] https://fishshell.com/docs/current/design.html


Also see: Ruby on Rails


Yep, another great example. :)


Yes I do. Ever use textmate or Atom? Sure you can configure a bunch of keys if you want to change them but nobody ever does.


This discussion reminds me of the classic "standards" xkcd

https://xkcd.com/927/


>and you aren’t able to just walk up to vim somewhere else

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.


I often need to use vim in servers that are not solely administered by me. It seems like bad etiquette to impose my configuration on my co-workers, so we leave it mostly unconfigured on these servers. There's also cases where I want to use vim in docker containers running web servers to debug by tracing execution in installed libraries by inserting prints and repl launching function calls, etc. It doesn't make sense to bother installing configuration each time the docker image is rebuilt, or including vim's installation and configuration in the Dockerfile.

I just do this minimal configuration on starting vim:

    :se et ai ts=2 sts=2 sw=2
Just that makes it usable enough for me to not feel a productivity loss most of the time.

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.


You're sharing accounts on servers or logging in directly as root? Either one sounds like a recipe for disaster.


Sharing a normal user account. It's not ideal, but it's not that bad either. I think you're missing a lot of context to properly judge this, but to keep it short and avoid divulging details it boils down to balancing costs, risks, and benefits. Remember you know nothing about my work. It's easy to underestimate costs, overestimate the risks, and overestimate benefits without being fully informed of the situation.


i switched away from emacs, and learned vi just because of that. to many servers with different versions of unix to make it worth the effort to install a different editor or customize its configuration.


I'd say yes; there are many times I've ssh'd into a server and wanted to do a quick edit where I don't have my vimrc; not going to bother to install it.

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.


In my routine work in an academic lab, im using 10-15 machines plus a number of GCP instances. Syncing a .dotfiles repo is a huge pain, especially when you make a small change on one machine and don’t want to push/pull ever time you want to do anything on another machine.


I fixed this problem for myself by automatically pulling down changes in the background upon opening a new terminal.

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 thought it was pretty clear actually: it works out of the box with no configuration (batteries included).

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).


> I have "set t_ti= t_te=" in my .vimrc so that the screen is not cleared when I exit

Oh wow, this is super helpful. Thank you!


wish neovim could do that too


Thanks for the tip


I use vim because I don't want the features of a "modern" text editor. My .vimrc is fairly basic at under 100 lines, and I only have a few plugins, which is mostly syntax files and syntastic.

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.


I can appreciate that. Amp's keybindings are fairly close to Vim's, so it's not like you lose the muscle memory you've built over the years.

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. ;)


> Unlike Vim, Amp doesn't provide split panes, and support isn't planned

That's a pretty big missing feature that is included in vanilla vim...


100% deferring to tmux, there. It just adds so many great features, I think it'd be a mistake to re-implement them in Amp. Paired with the fact that Amp is cheap on memory, and has native clipboard integration, this isn't as necessary as you might think; you can still move content between panes! :)


with split panes in vim i can have the same file open at two different places. can't do that with split panes in tmux.

greetings, eMBee.


Ah, you're right; thanks for clarifying!


also, i developed a plugin for vim that compiles code for me and sends the output to a second buffer.

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.


It's possible to run a command in another tmux pane; I forget the specific syntax but I've tested this in the past and it works. The only thing the editor needs is a task runner (this is a planned feature for Amp); the task that's run is prefixed with the tmux command that triggers it in another pane.

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.


i would split the current pane by default, and allow the user to define the whole tmux command used to splitting. (that way they can even replace tmux with something else that works instead.


Could make do with tmux panes I suppose, but I agree, if you're going to go head to head with Vim that's a big omission.


Why not just rely on tmux panes?


It'd prevent me using the Vim clipboard ('registers') between files. That's bad enough. It'd also prevent me using Vim macros to easily shuttle data between files.

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 has native clipboard integration, so content will carry between different instances. Configuring the register => clipboard was something I personally disliked when configuring Vim.

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! :)


> Amp has native clipboard integration, so content will carry between different instances

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?


Amp has an internal clipboard that it synchronizes to an external/native equivalent, if available. You'd still be able to copy/paste within a single Amp process, but you would lose the ability to do the same between separate processes.


Right, so in the context of this discussion, tmux panes are not a good substitute for vim windows, since you wouldn't be able to copy-paste between them unless what you were copying fit in a single pane-full.


Yes, that's correct. :)

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.


Not everybody uses tmux for one.


Author of amp here and I couldn't have explained this any better.


Even if you were someone for whom the page is clear, you might still be confused by why someone who would need to take a not insignificant amount of time getting their development machine installed and configured correctly but would balk at having to type - just once at any point during the lifetime of their laptop - a single git clone to pull down their config.

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.


There are quite a few areas where Amp diverges from Vim; minimal configuration is just one of those. It's inspired by Vim, but it's not a clone. Yes, it's modal, and yes it's a TUI app, but there's much more to these editors than that.

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"?


Finally.. the irssi of editors.

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.


As an emacs user, I have a medium sized .emacs config file. Moving from one emacs to another just imply reinstalling 2 or 3 packages and copying my emacs file. That's no hard work.

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 thought it was pretty clear actually: it works out of the box with no configuration (batteries included).

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.


I think one of the main reasons it exists is that it's written in Rust. One clue is that the TLD is .rs, plus there's been a lot of "a <type-of-program> written in Rust" lately. Which is fine; it's just an observation. I myself am going to be getting into Rust soon, hopefully.


Yes, this is definitely one reason. At the time, I was interested in working on Vim, but it's hard to make changes to a C codebase and be confident you won't introduce segfaults or subtle memory safety issues.

Rust's "hack without fear" mantra definitely applied here. :)


being written in rust might make it more appealing to develop, but it doesn't give any benefit to the user and I can't see it being a reason for someone to use this over vim


Rust programs tend to be more stable, more efficient, and more highly parallelized than equivalents written in other languages by developers of the same quality.


Again, I am not sure when is the last time vim crashed on my *nix set up. Not trying to sound unreasonable but in this argument of VIM/amp it might not be relevant.


It depends upon plugins. My Vim is quite prone to crashing but I'm fairly sure it is one of my plugins.


Yeah, more than likely. I'm down to just a handful of plugins and don't recall it crashing in the last couple of years, and I use it a lot.


False advertisement is false. Please refrain from such statements as it actually hurts the language more.


I think that that statement is true, the "tend to" and "same quality" are very important qualifiers though.


I think it's a lot easier for someone to learn a new language, or learn the benefits of a new language, by recreating something which already exists.


I usually go for irc bots when trying to learn a new language. I already know the api and the thought process which makes it easier.


> there's been a lot of "a <type-of-program> written in Rust" lately

It's the new Go.


I do wish there were more modal, terminal-based text editors that weren't so similar to Vim.

Kakoune is Vim-like, and now this.


> modal

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.”


Oh, I so disagree. Modal editing is not about the modes.

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.


I on the other hand would like to see other non-modal editors. Vim is already the best and most customizable modal editor, but does anyone know a good non-modal editor beyond basic nano?


I've been using Joe's Own Editor the past couple of years when I want to do basic view/editing in terminal (I use Sublime Text for development). Really like it because it provides syntax highlighting for a ton of file types, let's me get around with arrow keys/mouse, and gives me an easy way to look up keyboard commands I may have forgotten.

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.


You can try micro: https://micro-editor.github.io/


> Vim is already the best and most customizable modal editor

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?


You're using the emacs definition of major modes. "Modal editor" has a different meaning. Vim has three modes [1]. Emacs is not considered a modal editor, but some of its features are similar to Vim's last-line mode.

[1] https://alvinalexander.com/linux/vim-vi-mode-editor-command-...


Run Emacs in Evil mode or similar and you get modal editing inside a special editor mode. If anything, Emacs is an extra-modal editor. :)


Emacs is IDE, like Eclipse or Idea. It contains text editor, of course, but it much more than just text editor. It's not fair to compare say GEdit and Eclipse in terms of configurability, because GEdit is text editor, while Eclipse is IDE.


mcedit (part of mc) in gnome-terminal currently the best non-modal editor, AFAIK, especially when you like to use mc to navigate file system.


What an unfortunate name. All search results are for the Minecraft editor.

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.


It predates Minecraft by about a decade, I think.


Do you know about micro? https://github.com/zyedidia/micro


It is indeed quite amazing how modal editing is usually defined by vi, which does so in very specific ways, when there are alternatives (like kakoune) which really show there's a whole spectrum of possible implementations of that idea. I wish there was a modal editor with the same scope as nano which would help introducing that concept to newcomers without aiming to maximize productivity / expressiveness.


Well, nano is modal. If you press CAPS LOCK you enter "uppercase mode" :)


Sounds like navigation might be different, but the linked page is a bit cryptic:

> 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/...


This is similar to the vim-sneak plugin for Vim: https://github.com/justinmk/vim-sneak

It's very useful.


Looks similar to the Emacs Ace Jump mode too: https://www.emacswiki.org/emacs/AceJump


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


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.


> “the undo feature”

What do you mean? The persistent undo?


Yep


Love it though dev has slowed.


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

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

https://github.com/jmacdonald/amp/issues/113


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.


The [EasyMotion][0] plugin provides this. It has several modes to select where you want to jump to.

[0]:https://vimawesome.com/plugin/easymotion


This plugin is working quite well for me: https://github.com/justinmk/vim-sneak


Thanks! You can use it when defining selections, too. :)


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


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.


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


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.


I have been using Vim for several years now and I still struggle with basic-level movement commands. Like, I never remember if f-h will move me to |hello or to h|ello. If those are working for you, that is great, but I appreciate some alternatives there. The usual Vim approaches ("do vimtutor!" or "practice one new command a week!") are not working for me.


> I never remember if f-h will move me to |hello or to h|ello.

…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`.


You are probably right. Which is my point. Vim movement commands remain unintuitive to me, even after using the thing for years.


It’s extremely intuitive to me. It’s more like muscle memory than logical thinking, I think you might be thinking too analytically.


If it works for you, that is great. It doesn't work for me.


That's half-right, I think. The question is, when using a command like "change until" or "change forward", i.e. 'ct' or 'cf', what will the effect be?

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.


It's definitely exactly right, but I tried to word it in a way which didn't make me look like a know-it-all.

> 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 forward" [...] 'cf'

"change find", you mean.


Interesting! I'd always thought of it as "f"orward.

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.


In vim's usr_03.txt manual file, it says:

> 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.


Interesting. I always tend to think cursor is on top of character, not before or after it.


jump-mode as in "go to symbol"?


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.


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.


I’ve actually found the opposite - sure there’s a learning curve, but once you get used to it and it becomes second nature, Vim becomes the fastest way to convert thought to code.


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.


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


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


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.


ghcmod-vim lets you query types but I hadn't found anything that allows gotodef which is why I just went back to vscode + vim keybinds + haskero and everything just works.


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.


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...


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.


It’s a start


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


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.


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)


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

Line endings should also be unproblematic.


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?


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.


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.


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

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


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.


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


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


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


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.


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!


AUR package is fixed; feel free to give it another shot. :)


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

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.


Wat


Maybe choose another name?

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

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


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


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


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


"If it's anything like emacs or vim" is a very ambitious goal.


I actually came up with the name before Google announced that project, so I'm going to be stubborn and stick with it. :)


the thing that came to mind for me when i saw the name is winamp. that's quite a bit older...


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


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

Reads page

> modal [...] > inspired by Vim

Closes tab


> 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.


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.)


> 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`


Have you used it extensively? Why on modern keyboards? I can't stand non-modal editors now. I find them extremely limiting.


I agree about modal editing.

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.


Care to explain why you think modal editing is awful on 'modern'[0] keyboards?

0. besides adding backlights, changing build quality, and perhaps other layout options like dvorak or colemak, keyboards have not really changed in decades...




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: