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.
AUR package is fixed; feel free to give it another shot. :)
Amp – A complete text editor for the terminal
161–170 of 174 posts
Re: Amp – A complete text editor for the terminal
#162Earlier 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…
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 i…
There are quite a few areas where Amp diverges from Vim; minimal configuration is just one of those. It's inspired by Vim, but it's not a clone. Yes, it's modal, and yes it's a TUI app, but there's much more to these editors than that.
That said, I think it's pretty clear one of the first things I need to add to the website is an answer to "why would I use this instead of Vim"?
Re: Amp – A complete text editor for the terminal
#163Earlier quoted context omitted.
I’m on my phone so I haven’t checked. But my biggest grip with vim/emacs is discovery of new commands (for noobs or experts). What are you doing to solve that? Sublime Text fixes this by allowing you to do fuzzy search to access all the commands (command-P). Once you find your command it also displays the keyboard shortcut next to it so that next time you can use it instead.
You can fuzzy search Amp's commands, or display a buffer with a complete listing of all of them[0]. You can also view the default keymap[1] right in the editor. Hope that helps! [0] https://amp.rs/docs/usage/#running-commands [1] https://amp.rs/docs/configuration/#key-bindings
As you note in there, it isn’t really made for discovery. It’d be great if you could see the key binding next to the name of a command when you press ‘0’.
Other feedback: fuzzy search doesn’t work well for me. For exemple if I don’t write the folder name I can’t see the file. If I press backspace it deeted the entire search.
It’s be great to have “press ?” Or something like that when you open the editor. Like that you know directy how to see the key bindings.
Re: Amp – A complete text editor for the terminal
#164>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…
> I thought it was pretty clear actually: it works out of the box with no configuration (batteries included).
Vim works out of the box (heck, even old-school vi did.) Amp seems to provide more out of the box, but also explicitly states plans a runtime and plug-in support for extensibility, so apparently it still recognizes that complete out of the box is an unattainable goal given diversity (and conflict) of user needs.
Re: Amp – A complete text editor for the terminal
#165Earlier quoted context omitted.
I recently discovered this too. I'd been using nano as my default terminal text editor for years, but micro is a nice upgrade - I especially like the undo feature, the syntax highlighting, and the mouse support.
> “the undo feature” What do you mean? The persistent undo?
Yep
Re: Amp – A complete text editor for the terminal
#166Earlier quoted context omitted.
You can fuzzy search Amp's commands, or display a buffer with a complete listing of all of them[0]. You can also view the default keymap[1] right in the editor. Hope that helps! [0] https://amp.rs/docs/usage/#running-commands [1] https://amp.rs/docs/configuration/#key-bindings
As you note in there, it isn’t really made for discovery. It’d be great if you could see the key binding next to the name of a command when you press ‘0’. Other feedback: fuzzy search doesn’t work well for me. For exemple if I don’t write the folder name I can’t see the file. If I press backspace it deeted the entire search. It’s be great to have “press ?” Or something like that when you open the editor. Like that yo…
You can press "?" when you open the editor to read quick start guide. :)
As for the fuzzy search, it's working as intended. Have a look at the docs[0] for an explanation of the matching algorithm, UX, and the reasoning behind it; it's intentional, I promise.
Love the idea of displaying the key binding next to the command!
Re: Amp – A complete text editor for the terminal
#167Earlier quoted context omitted.
If it's a start it should still be planned though.
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, they may take more memory in UTF-8 form. This usually isn't an issue unless one is handling large files of Kanji)
Re: Amp – A complete text editor for the terminal
#168Earlier quoted context omitted.
As you note in there, it isn’t really made for discovery. It’d be great if you could see the key binding next to the name of a command when you press ‘0’. Other feedback: fuzzy search doesn’t work well for me. For exemple if I don’t write the folder name I can’t see the file. If I press backspace it deeted the entire search. It’s be great to have “press ?” Or something like that when you open the editor. Like that yo…
You can press "?" when you open the editor to read quick start guide. :) As for the fuzzy search, it's working as intended. Have a look at the docs[0] for an explanation of the matching algorithm, UX, and the reasoning behind it; it's intentional, I promise. Love the idea of displaying the key binding next to the command! [0] https://amp.rs/docs/usage/#using-the-file-finder
Fuzzy searching still doesn’t work for me. I have a path starting with lib/ and if I write “lib” there is nothing anymore
Re: Amp – A complete text editor for the terminal
#169Earlier quoted context omitted.
with split panes in vim i can have the same file open at two different places. can't do that with split panes in tmux. greetings, eMBee.
Ah, you're right; thanks for clarifying!
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, but i need to check that tmux is not only available but that the editor is running inside it as well. and i have to prepare that users will ask me to make this work with screen or any other tmux alternative.
greetings, eMBee.
Re: Amp – A complete text editor for the terminal
#170Earlier quoted context omitted.
Ah, you're right; thanks for clarifying!
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 the first run, or allow the value to be configured.