Live data from Hacker News

Amp – A complete text editor for the terminal

amp.rs

111–120 of 174 posts

Re: Amp – A complete text editor for the terminal

#111
post #47
post #6

>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 o…

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

Re: Amp – A complete text editor for the terminal

#112
post #47
post #6

>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 o…

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

Re: Amp – A complete text editor for the terminal

#113

Earlier quoted context omitted.

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 t…

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.

Re: Amp – A complete text editor for the terminal

#114

Earlier quoted context omitted.

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 reason…

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

Re: Amp – A complete text editor for the terminal

#115
post #47

Earlier quoted context omitted.

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 o…

> 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 m…

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

Re: Amp – A complete text editor for the terminal

#116
post #47

Earlier quoted context omitted.

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 o…

> 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 m…

Thanks for the tip

Re: Amp – A complete text editor for the terminal

#117

Earlier quoted context omitted.

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 t…

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.

Re: Amp – A complete text editor for the terminal

#118

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…

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

Re: Amp – A complete text editor for the terminal

#119
post #104

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.

Re: Amp – A complete text editor for the terminal

#120
post #95

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
Post reply on HN