Earlier quoted context omitted.
Could make do with tmux panes I suppose, but I agree, if you're going to go head to head with Vim that's a big omission.
Why not just rely on tmux panes?
Not everybody uses tmux for one.
Amp – A complete text editor for the terminal
101–110 of 174 posts
Re: Amp – A complete text editor for the terminal
#102Earlier 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…
Choice is a process which can hurt when it takes too long or when you lack the ability to execute the process itself or in a good manner.
See https://en.wikipedia.org/wiki/Overchoice and https://en.wikipedia.org/wiki/Analysis_paralysis
This is BTW no limited to OSS but AFAIK it comes from sales-research. People confronted with to many products of similar type can end in a deadlock, avoiding those products or even start to avoid the whole category.
> You can argue that progress would be faster if we have less choices but more choices also means more developpers...
More developers reinventing the wheel doesn't automatically make the wheels faster. It can mean healthy competition, but it also can mean wasted ressources. It's case by case.
Re: Amp – A complete text editor for the terminal
#103Earlier quoted context omitted.
You're going to get a fuzzy file finder, Git integration, syntax highlighting, symbol navigation, and and a package manager immediately available to you in those editors. None of those are available in Vim by default; that's the inspiration for Amp. There are additional perks to including things by default, too. Jump mode is a good example of that: it's integrated with its select mode. You can start a selection and t…
I don't disagree with your approach but I'd just point out, since it's a little ironic, that rust's standard library is a good example of the opposite approach!
You're absolutely right. :)
I'm going to resist adding everything but the kitchen sink to Amp. Upcoming features like tasks and language server protocol support will allow Amp to integrate with language/framework-specific tools as easily as possible, but without steering Amp towards any specific choices. I couldn't avoid that with syntax highlighting; it's just too essential (and it powers the symbol jump mode). It's definitely a balancing act!
Re: Amp – A complete text editor for the terminal
#104Jump mode isn't working for me. It highlights all the two letter codes but keeps taking me to the same place (not the code I type).
So I tried a new file and then the error message wiped out my sample text.
Also, I don't see how to switch between buffers?
Re: Amp – A complete text editor for the terminal
#105Earlier quoted context omitted.
> Unlike Vim, Amp doesn't provide split panes, and support isn't planned That's a pretty big missing feature that is included in vanilla vim...
100% deferring to tmux, there. It just adds so many great features, I think it'd be a mistake to re-implement them in Amp. Paired with the fact that Amp is cheap on memory, and has native clipboard integration, this isn't as necessary as you might think; you can still move content between panes! :)
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.
Re: Amp – A complete text editor for the terminal
#106Earlier quoted context omitted.
100% deferring to tmux, there. It just adds so many great features, I think it'd be a mistake to re-implement them in Amp. Paired with the fact that Amp is cheap on memory, and has native clipboard integration, this isn't as necessary as you might think; you can still move content between panes! :)
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!
Re: Amp – A complete text editor for the terminal
#107Earlier quoted context omitted.
Could make do with tmux panes I suppose, but I agree, if you're going to go head to head with Vim that's a big omission.
Why not just rely on tmux panes?
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 way.)
I suspect it would also mean more keystrokes.
Re: Amp – A complete text editor for the terminal
#108Earlier quoted context omitted.
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.
Unfortunately, configuring Vim is rarely just pulling a config file. Pathogen and Vundle have made installing/tracking plug-ins easier, but unless things have changed, those tools required their own bootstrapping outside of simply being referenced in the config. And that's just for Vimscript plug-ins. There are several situations (e.g. fuzzy file finders) where external binaries are preferable, for performance reason…
All depends on your taste. My .vimrc handles ensuring that I have a plugin manager installed and that it installs those plugins on my behalf if they aren't there. And I do all of that in ~10 lines of vimL config. It's totally reasonable to have your plugin/config ensure the external binaries exist as well. The popular golang plugin has a command for that.
Re: Amp – A complete text editor for the terminal
#109Jump mode isn't working for me. It highlights all the two letter codes but keeps taking me to the same place (not the code I type). So I tried a new file and then the error message wiped out my sample text. Also, I don't see how to switch between buffers?
Hmm, the jump mode issue is strange; can you please file an issue as a starting point?
As for the error message, it didn't wipe out your file; it opened a new buffer with the error message. You can switch between buffers using Tab. There's a full keymap listing available through a command called "application::display_default_keymap" that you can invoke by hitting 0 in normal mode and searching for it.
Re: Amp – A complete text editor for the terminal
#110Earlier quoted context omitted.
mcedit (part of mc) in gnome-terminal currently the best non-modal editor, AFAIK, especially when you like to use mc to navigate file system.
What an unfortunate name. All search results are for the Minecraft editor. It's also fairly obtuse for non-experts. A champion non-modal editor would have a learning curve as shallow as nano but more depth that could reveal itself over time.
It predates Minecraft by about a decade, I think.