121–130 of 174 posts
It says you only plan UTF8 support and no Windows line endings. The windows line endings ok, and I get why in Rust it was easier with UTF8 (although there are some good crates for handling encoding). However this seems awfully restrictive to me.
It’s a start
Earlier quoted context omitted.
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.
It ensures you have a plug-in manager installed, but it won't install it for you , right? I know that might seem like a minor nit, but if package management is considered an essential part of Vim, I'm of the mindset that it should work out of the box. That said, Amp doesn't have plug-in support at the moment, so it's a little unfair for me to judge Vim on that front. But if it did , the package management portion wou…
The classic ed and its visual version which is called vi are really good-enough if done right. The central concept here is simple regexps bound to one key commands, and that these commands compose. This is the reason why vi is what it is. https://karma-engineering.com/lab/wiki/Tools/Neovim The only problem is that all classic vis, including vim, have been coded by amateurs and the code is a terrible mess. nvi was goo…
Earlier quoted context omitted.
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.
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.
Hope that helps!
Earlier quoted context omitted.
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…
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 collapsing all panes by default (and expanding them on resume). Workflows are tricky; to each their own, I guess! :)
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.
Complexity increases when you want one vimrc with many plugins to work on Windows, Linux and OS X, and both in your work and home environments.
I'm not arguing that Amp is the answer. I don't think I'd stick with vim as my daily driver if I couldn't customize it, and have the plugins I do.
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.
Earlier quoted context omitted.
> it works out of the box with no configuration (batteries included). You don't really believe that, do you? Competent users tend to have preferences. There's no need to worry about installing plugins if you have to have a .vimrc to begin with, just have the .vimrc do the installing as well.
I have not tried amp yet, but just as an example why I switched shell. I use fish shell because of the sane defaults. I don't want to be bothered with setting up code completion and history size. Just install it and use it. Works. I like projects that provide similar experience.
Earlier quoted context omitted.
It’s a start
If it's a start it should still be planned though.
Earlier quoted context omitted.
The irony. Easymotion was created as a better precisejump. Precisejump was created or at least uploaded in Feb 2011.
It's funny isn't it. I guess I don't try hard enough to find productivity-enhancing Vim plugins. I've tried various "Vim enhancement suites" intended to bring a number of useful plugins and had some success, but since I can't rely on them on new servers I find myself more often than not just using plain Vim. Some other commenters in the thread have raised the point that having more supported functionality out of the…
For editing text, there's already a lot of flexibility in Amp's keymap system[0]. As users compose more sophisticated/useful macros, we can promote them to the default keymap, and if they're really useful, we can build them as discrete commands in Amp itself. That way, the core editor evolves to encourage a particular workflow. It's opinionated, and it may not appeal to everyone, but that's kind of the point.