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

171–174 of 174 posts

Re: Amp – A complete text editor for the terminal

#171

Post by em-bee »

wasted_intel wrote: post #170
em-bee wrote: post #169

Earlier quoted context omitted.

also, i developed a plugin for vim that compiles code for me and sends the output to a second buffer. sure i can make that work with tmux. codewise it would even be easier, but only if i can trust the user to put all the pieces together for themselves. if i want to build an end-user friendly package, the whole thing suddenly becomes a lot more complex: it's no longer enough to say: load this into vim and you are done…

It's possible to run a command in another tmux pane; I forget the specific syntax but I've tested this in the past and it works. The only thing the editor needs is a task runner (this is a planned feature for Amp); the task that's run is prefixed with the tmux command that triggers it in another pane. The only thing that's bespoke to tmux is knowing which pane to target; you'd need to collect that from the user on th…

i would split the current pane by default, and allow the user to define the whole tmux command used to splitting. (that way they can even replace tmux with something else that works instead.

Re: Amp – A complete text editor for the terminal

#172

Post by em-bee »

jolmg wrote: post #139
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.

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…

i switched away from emacs, and learned vi just because of that. to many servers with different versions of unix to make it worth the effort to install a different editor or customize its configuration.

Re: Amp – A complete text editor for the terminal

#173

Post by em-bee »

wasted_intel wrote: post #155
josteink wrote: post #7

Maybe choose another name? I mean: Good luck trying to out-SEO Google re-using their own term[1] :) [1] https://www.ampproject.org/

I actually came up with the name before Google announced that project, so I'm going to be stubborn and stick with it. :)

the thing that came to mind for me when i saw the name is winamp. that's quite a bit older...

Re: Amp – A complete text editor for the terminal

#174

Post by carlmr »

jimsmart wrote: post #167
wasted_intel wrote: post #129

Earlier quoted context omitted.

I've mostly built Amp to fit into my workflow, which is unix line-endings & ASCII/UTF-8 at the moment. Not opposed to alternative encodings, but I think that's a non-trivial addition. Amp uses a gap buffer under the hood and avoiding segmenting multi-byte UTF-8 graphemes/grapheme clusters was tricky. It's definitely possible, it just hasn't been a priority, yet .

Arguably this is somewhat of a kludge(?), but one option (which would involve less coding than making the engine work with different encodings) would be to use readers/writers to support other formats, and keep using UTF-8 internally. UTF-16BE/LE and UTF-32, plus Windows CPs, are all really easy to do like this — probably others too. (Note that depending on the range of codepoints used in files using these encodings,…

I agree, especially as UTF-8 is standard inside Rust. Also the encoding library would make it easy enough to support other formats.

I'm not sure if the editor streams or loads into RAM right now. If it already loads into RAM this is a tiny change.

https://crates.io/crates/encoding

Line endings should also be unproblematic.

Post reply on HN