wasted_intel

Counter-anecdote: I've been running an Arch install for 2+ years with zero problems. Picking hardware that has direct kernel support will save you a bunch of headaches.

Also, a rolling release distro, which you'd think would be less stable, provides better hardware support as the kernel and firmware packages are much more recent (not to mention libraries/build dependencies). Personally, I'd never go back to a fixed-release distro.

No, it isn't. From the website:

  Sublime Text is available for Mac, Windows and Linux. One license is all you need to use Sublime Text on every computer you own, no matter what operating system it uses.

I doubt mine will be much different than others, but: 7-8 hours of sleep every night, and exercise three times a week (specifically: an hour of strength training during each session).

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.

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

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

AUR package is fixed; feel free to give it another shot. :)

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

Yep, another great example. :)

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.

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.

You've touched on an important point: taking inspiration from workflows and incorporating them into the core editor itself.

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.

[0] https://amp.rs/docs/configuration/#multiple-commands

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.

Yes, fish shell is a beautiful example of that philosophy! Its design documentation[0] reflects a lot of the values that drove me to create Amp.

[0] https://fishshell.com/docs/current/design.html

Amp has native clipboard integration, so content will carry between different instances. Configuring the register => clipboard was something I personally disliked when configuring Vim.

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 <leader>-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! :)

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

Vim has very simple highlighting, and doesn't support symbol jump; that's why ctags is an external dependency for that behaviour.

As for a file finder, I'm curious how you can use a separate tab to open that in the current instance of Vim? From when I'd last used it, most folks were using Ctrl-P to solve that problem, and usually with an external indexer like fzf or ag.

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 would be baked in so that you'd only need to pull your configuration file and Amp would handle the rest. :)

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.

Ah, you're right; thanks for clarifying!

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!

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

I can appreciate that. Amp's keybindings are fairly close to Vim's, so it's not like you lose the muscle memory you've built over the years.

Amp's additional features are really geared towards project-based development, so ubiquity isn't as much of a concern; it's not meant for editing sporadic config files on your server. Vim is still a great fit for that, at least until someone gets Amp adopted into the main Ubuntu server repositories. ;)

I know this defeats the purpose of minimal configuration, but you can define those kinds of actions fairly easily by defining keymaps that compose multiple commands[0]. For what you're after, you could do this:

  keymap:
    normal:
      W:
        - "cursor::move_to_start_of_previous_token"
        - "buffer::change_token"

You can view the default keymap right in Amp, too, as well as a list of all of the commands. Happy to entertain a PR that sets that as a default keymap going forward. :)

[0] https://amp.rs/docs/configuration/#multiple-commands

Thanks! You can use it when defining selections, too. :)

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 then switch to jump mode to move the cursor to complete the selection.

Lastly, there's simplicity in including things rather than asking new users to pick from a dizzying array of plug-in options. Rails is a good example of this: there's a lot of functionality that could have been left to 3rd-party gems, but having the framework include them by default means they'll work out of the box, and there's a single canonical solution to [sessions, templates, ORM, routing, etc].

LSP support is planned! Although, the rationale for including it is for advanced language features, like "go to method". I'd be surprised if other editors were using it for syntax highlighting. I've had to jump through hoops to keep that performant on large files. Seems like putting that in a separate process would make performance even more of a challenge.

I found this after a quick search: https://github.com/Microsoft/language-server-protocol/issues...

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 reasons. The idea is to include those directly in Amp, so that it's _only_ a configuration file that's needed, if at all.

This is an unfortunate consequence of depending on termbox, which uses Python as part of its build (waf), which unfortunately doesn't work in Python 3.7. On Arch, you need to alias python to python2 for the build to work. I'll comment on the AUR package.

As an aside, my current 0.6.0 feature is moving completely towards termion (a Rust-based, lower-level terminal lib) that'll resolve that!

Yes, this is definitely one reason. At the time, I was interested in working on Vim, but it's hard to make changes to a C codebase and be confident you won't introduce segfaults or subtle memory safety issues.

Rust's "hack without fear" mantra definitely applied here. :)