Live data from Hacker News

Amp – A complete text editor for the terminal

amp.rs

141–150 of 174 posts

Re: Amp – A complete text editor for the terminal

#141
post #137
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.

Jeez, I think this specific comment chain illustrates one reason why the OP decided to make a new text editor. And this is why I don't use vim anymore. You have 4 people, all somewhat experienced vim users (guessing based on prior posts), who all have conflicting ideas about how to do a simple move operation.

This goes beyond "counterintuitive-ness"... After a few years working with vim, I find myself unable to easily recall how to do some basic operations. Vim is counter-retentive for me as well. Thanks OP, I'm gonna start playing with Amp now!

Re: Amp – A complete text editor for the terminal

#142
post #74
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…

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

Re: Amp – A complete text editor for the terminal

#143
post #139

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.

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…

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

Re: Amp – A complete text editor for the terminal

#144

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

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.

Re: Amp – A complete text editor for the terminal

#145
post #139

Earlier quoted context omitted.

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…

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.

Re: Amp – A complete text editor for the terminal

#146

Earlier quoted context omitted.

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

wish neovim could do that too

Re: Amp – A complete text editor for the terminal

#147
post #132

Earlier quoted context omitted.

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

Re: Amp – A complete text editor for the terminal

#148
post #140
post #137

Earlier quoted context omitted.

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

Re: Amp – A complete text editor for the terminal

#149
post #147

Earlier quoted context omitted.

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.

Post reply on HN