Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Amp – A complete text editor for the terminal

amp.rs

Post reply on HN
Print view View original

71–80 of 174 posts

Re: Amp – A complete text editor for the terminal

#71

Post by edanm »

yakshaving_jgt wrote: post #37
otikik wrote: post #35

Earlier quoted context omitted.

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

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.

Re: Amp – A complete text editor for the terminal

#72

Post by rerx »

lake99 wrote: post #45
rerx wrote: post #42

Earlier quoted context omitted.

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

Re: Amp – A complete text editor for the terminal

#73

Post by mywtfmp3 »

yakshaving_jgt wrote: post #37
otikik wrote: post #35

Earlier quoted context omitted.

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

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

Re: Amp – A complete text editor for the terminal

#74

Post by wiz21c »

oblio wrote: post #60
phlyingpenguin wrote: post #53

Earlier quoted context omitted.

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

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

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

Re: Amp – A complete text editor for the terminal

#75

Post by wiz21c »

tbrock wrote: post #47
mario0b1 wrote: 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…

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.

Re: Amp – A complete text editor for the terminal

#76

Post by sy7ar »

otikik wrote: post #43
yakshaving_jgt wrote: post #37

Earlier quoted context omitted.

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

Re: Amp – A complete text editor for the terminal

#77

Post by littlestymaar »

ilikehurdles wrote: post #10
albertgoeswoof wrote: post #9

Earlier quoted context omitted.

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

Re: Amp – A complete text editor for the terminal

#78

Post by oblio »

wiz21c wrote: post #74
oblio wrote: post #60

Earlier quoted context omitted.

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

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

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

Re: Amp – A complete text editor for the terminal

#79

Post by petepete »

gdfasfklshg4 wrote: post #58
__Joker wrote: post #54

Earlier quoted context omitted.

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.

Re: Amp – A complete text editor for the terminal

#80

Post by wasted_intel »

phlyingpenguin wrote: post #66
wasted_intel wrote: post #59

Earlier quoted context omitted.

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.

Post reply on HN