Live data from Hacker News

Amp – A complete text editor for the terminal

amp.rs

61–70 of 174 posts

Re: Amp – A complete text editor for the terminal

#61

Earlier quoted context omitted.

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.

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.

Re: Amp – A complete text editor for the terminal

#62

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.

ctrl+W 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.

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.

Re: Amp – A complete text editor for the terminal

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

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

Re: Amp – A complete text editor for the terminal

#65
post #18
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 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 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. :)

Re: Amp – A complete text editor for the terminal

#66

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.

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.

Re: Amp – A complete text editor for the terminal

#67
post #42

Earlier quoted context omitted.

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?

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

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.

Re: Amp – A complete text editor for the terminal

#68
post #49

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!

Re: Amp – A complete text editor for the terminal

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

Re: Amp – A complete text editor for the terminal

#70

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.

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

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