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

131–140 of 174 posts

Re: Amp – A complete text editor for the terminal

#131

Post by wting »

etrautmann wrote: post #127
lunchables wrote: post #111

Earlier quoted context omitted.

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

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

Re: Amp – A complete text editor for the terminal

#132

Post by jolmg »

wasted_intel wrote: post #125
MaxBarraclough wrote: post #107

Earlier quoted context omitted.

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…

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 -z. I get that this is less than ideal if you're used to the suspend action col…

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

Re: Amp – A complete text editor for the terminal

#133

Post by [deleted] »

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…

[deleted]

Re: Amp – A complete text editor for the terminal

#134

Post by craftyguy »

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

Re: Amp – A complete text editor for the terminal

#135

Post by craftyguy »

easytiger wrote: post #31

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

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

Re: Amp – A complete text editor for the terminal

#136

Post by superflyguy »

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…

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.

Re: Amp – A complete text editor for the terminal

#137

Post by jolmg »

edanm wrote: post #71
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`.

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.

> "change forward" [...] 'cf'

"change find", you mean.

Re: Amp – A complete text editor for the terminal

#138

Post by wasted_intel »

jolmg wrote: post #132
wasted_intel wrote: post #125

Earlier quoted context omitted.

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 -z. I get that this is less than ideal if you're used to the suspend action col…

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

Re: Amp – A complete text editor for the terminal

#139

Post by jolmg »

lunchables wrote: post #111
tbrock wrote: 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…

>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 or :e %:s?local?global? 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.

Re: Amp – A complete text editor for the terminal

#140

Post by edanm »

jolmg wrote: post #137
edanm wrote: post #71

Earlier quoted context omitted.

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.

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

Post reply on HN