16 ms·

Amp: Vi-like terminal editor written in Rust

148 points by cassepipe 6y ago

jchw 6y ago
At a glance, it looks like there are no provisions for supporting Language Server Protocol. That's unfortunate as I've come to use gopls, rls, tsserver and clangd quite a bit. Getting accurate autocompletion in complex situations and errors as you type are not absolutely necessary, but once you have them it's hard to go back. edit: rust-analyzer, not rls.
- cassepipe 6y ago
  True but plug-in API for better language support is apparently on the roadmap
- pitaj 6y ago
  FYI you should switch to rust-analyzer instead of RLS.
  - jchw 6y ago
    Actually, I have been using rust-analyzer, I misspoke.
    - indemnity 6y ago
      You’re both right, rust-analyzer will become official RLS 2.0.
majewsky 6y ago
Constructive criticism: As a Vim user, this website contains nothing that would convince me to actually try Amp. The only thing mentioned on there that does not apply to my Vim setup is "written in Rust". And as much as I love Rust, "written in Rust" is not a sufficient argument to get me to give up a tool that I've been living and breathing for over a decade. If, on the other hand, I'm not the target audience, the website should make that clear, e.g. "Amp is a Vi-like editor designed for people who find Vim too hard to get started with" or whatever.
- otikik 6y ago
  I am a Vim user too, but I am very different from you. Vim is my main editor. I have used it daily for years. At the beginning I didn't like it. Then I spent time on it. Configured it. Installed plugins. And I still don't like it. But then I try other editors and either I miss one feature or I start pressing j to go down or whatever. I'm Vim's hostage. This editor seems to target me personally.
  - atoav 6y ago
    Afaik what the world really needs is a vim like editor with sane defaults, partly overhauled shortcuts that are closer to other tools and some common scenarios solved in less steps (e.g. exiting the editor, multicursor stuff, ...)
    - Jtsummers 6y ago
      What would you do to shorten exiting vim? <esc> :wq Is the longest it's ever been for me and :q Is the norm if I'm in visual mode and haven't edited the buffer.
      - hojjat12000 6y ago
        I think most people don't know that instead of :wq or :q! they can just ZZ and ZQ
        cassepipe 6y ago
        or just :x
      - ckw 6y ago
        Space is my leader key, save is mapped to <leader>w, exit is mapped to <leader>q, and <esc> is mapped to jk. So nominally exiting from insert mode in an unsaved buffer (jk<space>w<space>q) is the same number of key presses as <esc><shift>;wq<return>, but in practice, in my opinion, jk is superior to <esc>, <space>w is superior to <shift>;w<return>, <space>q is superior to <shift>;q<return>, and <space>w<space>q is superior to <shift>;wq<return>.
jeroenhd 6y ago
What's the advantage of writing an editor like this in Rust? And by advantage, I mean an advantage for me, the end user. I'm quite pleased with neovim and I'm not planning on switching any time soon, so I guess I'm not the target audience for this tool. Then again, who is?
- atoav 6y ago
  I guess the one advantage is, that you learned Rust really well while creating the editor? Oh and of course if the editor interacts with anything web, less exploitable buffer overflows and other memory errors come free woth it.
- cassepipe 6y ago
  I don't think it makes a differences that it is written in Rust in the same way it does not really matter that Neovim has a cleaner codebase than Vim's in your everyday use of Neovim. But maybe it will attract Rust devs who are also Vim users in the same Neovim attracted people who are versed in Lua ? I have been using Vim for a while and learned a lot but I hate to have to configure it and the out of the box experience is really missing much. I don't want to have to have to manage something as basic as my text editor. I want a battery-included modal terminal editor that has (mostly) Vim commands and is easy to use. Onivim2 is fast and beautiful but it's a gui and it is not finished. Kakoune looks great but I don't want to learn another set of commands as I might to have to use Vim again and don't want to "lose" my habits. So I am really looking forward Amp 1.0
  - memco 6y ago
    I recently learned of nvcode: https://github.com/ChristianChiarulli/nvcode https://github.com/ChristianChiarulli/nvcode. I haven’t tried it yet, but it’s another option in the pre-configured vim space that you might find interesting.
    - cassepipe 6y ago
      Thanks !
johnchristopher 6y ago
I like that `f` jump mode: > Press f to switch to jump mode. Elements on-screen will be prefixed with a two character jump token. Type the characters to jump to the associated element. https://amp.rs/docs/images/jump_mode.gif https://amp.rs/docs/images/jump_mode.gif
- senkora 6y ago
  Looks like an implementation of avy from emacs, very cool that they included this in the base! https://github.com/abo-abo/avy https://github.com/abo-abo/avy
  - sooheon 6y ago
    It's worse than avy because avy (and vim-sneak, evil-snipe et al) allow you to input the prefix char(s). Avy in general is insanely powerful, and abo-abo's set of elisp packages contain some of the most well thought out UX, held back by the rickety shell that is emacs.
- laixer 6y ago
  Something similar is available in vim via the easymotion plugin: https://github.com/easymotion/vim-easymotion https://github.com/easymotion/vim-easymotion
  - johnchristopher 6y ago
    For those like me who had never used easymotion before this is the closest I got to replicate amp behaviour (so far) :map f <Plug>(easymotion-overwin-f2) It doesn't highlight every word with shortcuts first. It does a search based on two characters max and then highlight the results with characters that you can press to move to the corresponding word.
ogre_codes 6y ago
One of the big advantages of VIM is that it's ubiquitous. This has some potentially more intuitive features, but I when I'm setting up a new system, it's not there. It's VIM-like... but just different enough where it seems like it would be infuriating in practice if you had to even occasionally cross between the two. I like that they chose to use an existing format for language bindings. Sublime bindings are pretty decent. Less clear is how you would integrate something like prettier. I suspect that's not even possible right now. I like built in fuzzy search a lot (not sure I like this specific implementation, but a lot better than nothing). I would love to see something like this, but that sticks more closely to VIM in terms of default bindings and features.
tyingq 6y ago
Was trying to figure out why it had openssl as a dependency. Apparently it doesn't anymore: https://github.com/jmacdonald/amp/blob/8b917ac720e7513e5c5bc59697c4a995f688aae9/CHANGELOG.md#L10 https://github.com/jmacdonald/amp/blob/8b917ac720e7513e5c5bc...
lilyball 6y ago
I'm really disappointed that the display of a terminal window with blinking cursor wasn't an actual live demo of Amp.
- samatman 6y ago
  That would be very cool, although I would make it an image link which jumps to a live demo, just to be kinder on the user's bandwidth and CPU.
  - nailer 6y ago
    The user would download a webassembly bundle (compiled from the original Rust) and execute it, similar to most websites. It should be fine.
thibran 6y ago
Does it have something like vim-surround?
- sullyj3 6y ago
  That's definitely a killer feature for me.
Animats 6y ago
OK, now would someone please rewrite "gedit" in Rust, and make it stop crashing on large files. I use "vim" mostly for looking at log files in the gigabyte range.
3v1n0 6y ago
I guess would be relevant if it was a proper vim implementation in rust, otherwise it wouldn't add anything a part from rust and immaturity.
deleted 6y ago
[deleted]
hermitsings 6y ago
It could be the default editor for RedoxOS
Exuma 6y ago
There's nothing on here to say why this is better than just running vim in the terminal. There's literally not even a list of features or anything to highlight how this is different.
qw3rty01 6y ago
This editor is missing way too many vim helper shortcuts to claim to be vi-like, maybe vi-inspired would be better wording. That being said, the editor looks really nice and jump mode feels extremely intuitive; I might give it a full shot once they get language server support
- tyingq 6y ago
  Vim isn't vi. You don't have to have many features to be "vi like". That said, the site itself doesn't say "vi like". Their wording seems close to what you're suggesting. "Amp is inspired by Vim's modal approach to text editing, which is reflected in several of its default key bindings. That similarity aside, there are several key differences". https://amp.rs/docs/ https://amp.rs/docs/ Edit: The amp key bindings: https://github.com/jmacdonald/amp/blob/8b917ac720e7513e5c5bc59697c4a995f688aae9/src/input/key_map/default.yml https://github.com/jmacdonald/amp/blob/8b917ac720e7513e5c5bc...
  - qw3rty01 6y ago
    The title of the post says a "vi-like terminal editor," and distinguishing vi vs vim is missing the point--I'm not talking about extensive plugin support or features that are specific to vim, the base keymappings are pretty different.
cryptoquick 6y ago
Not really into Vi, but thank you for using this name for something better than whatever Google might want to do with it.
Decabytes 6y ago
Does anyone know how this compares to https://github.com/redox-os/sodium https://github.com/redox-os/sodium besides the fact it is still being actively developed?
kkoncevicius 6y ago
Seems like a lot of defaults are maybe too tightly coupled with the preferences of the authors. These, for example, are weird: > Scrolling up/down in normal mode uses the , and m keys, respectively. > The R key can be used to copy the current file's GitHub URL > p - Paste at the cursor, P - paste on the line above
- sullyj3 6y ago
  Agree about the second one, that seems weirdly specific, but , and m for scrolling seems reasonable enough and p/P for pasting is the same as the vi family.
desireco42 6y ago
It says inspired by vim but it isn't vim compatible? I am pretty much confused. I heard that Rust community likes to remake everything in Rust, so I guess I can put this in that bucket. Like, we have NeoVim that is pushing the Vim boundaries. This doesn't seem to be trying to do that. I think, as an effort, it is probably very educational to make editor. As a product, it might not be for actual Vim users. As you know Vim is plenty fast, with NeoVim unblocking operations, we have our problems and challenges solved. Clearly Rust is fantastic language I and other devs should pay attention to and learn as it inspires people to make things.
- chrisjharris 6y ago
  I was thinking the same. There is some cool new stuff in this space (ie Kakoune), which probably is actually somewhat more ergonomic to use than vim/neovim. And maybe this is slightly faster than vim, although vim isn't exactly the kind of program where people complain about it being too slow. But to try to upturn the anthill for a 10% improvement in any direction, on an already excellent product, feels like a mistake.
ziml77 6y ago
I love Rust. I hate when people dismiss things as soon as they see it's written in Rust. But there's no reason for it to be a selling point here. You can have that info as one of the notes on the page, but the key selling point in the title shouldn't be that it's written in Rust.
- brundolf 6y ago
  It's a selling point if the code is more about being reading material than being a daily driver
samatman 6y ago
Ooh this is promising. In this particular case, when I see "written in Rust" I hear "uses the Rust ecosystem" which is quite a bit more loadbearing than just the choice of programming language. Does anyone happen to know if it uses syntect for highlighting? I wasn't able to determine this in the amount of time I have to browse it. If so, I will be trying this out for sure, I have custom syntax highlighting written in `.sublime-syntax` format and this would be perfect for me. Edit: Don't want to make another top-level post and I sneaked in under the edit window. Is there a community for this? I'm trying to get some .sublime-syntax files installed, and I can't find anything amp-specific in either .config or .local/share/ The project is somewhat underdocumented (it's okay, I expected this) and it would be helpful if there were some friendly devs whose ear I could bend as I get comfortable. If this does exist, it would be a very good thing to link to from https://amp.rs https://amp.rs
- swsieber 6y ago
  Looking at the dependencies on crates.io it looks like it does use syntect: https://crates.io/crates/amp/0.6.2/dependencies https://crates.io/crates/amp/0.6.2/dependencies
  - samatman 6y ago
    Score! Yeah that would have been the obvious place to look, huh. I encourage anyone who is skeptical about "what if $app but Rust" to look at the crates here. Ecosystem quality is very important and Rust has good ones. Consider that wiring together such an app in plain-old-C means inheriting the buffer overflows, memory leaks, thread unsafety, and data races, associated with each and every such library.
skyfaller 6y ago
Relatedly, there's an Emacs-like editor written in Rust called Zee: https://github.com/mcobzarenco/zee https://github.com/mcobzarenco/zee Zee makes some claims about speed, "The 100 FPS editor. Cursor movement and edits render under 10ms." I do not know how to evaluate whether those claims are true. I've become used to using Micro (written in Go) for everything: https://micro-editor.github.io/ https://micro-editor.github.io/ So I haven't really used Amp or Zee much, but I do have both installed on my system just in case I get bored of Micro ;-)
dejj 6y ago
And here I am still trying to get familiar with Kakoune: https://kakoune.org/ https://kakoune.org/
benbenolson 6y ago
Tested this today. - Opening anything larger than a megabyte causes long load times (compared to `vim` and other editors), as well as extreme lag before each cursor movement. - The code, relying extremely heavily on various Rust libraries, is extremely difficult to read due to how it's organized: directories like "view" (which doesn't contain source code pertaining to rendering any actual characters), "models", "modes", etc. - The "jump" feature is good in theory, but in practice is significantly slower than simply continuing to move the cursor normally, as it only works with tokens currently on the screen. - Opening any files in the editor requires the construction of an index so that it can search for things for you. This runs seemingly-unending on both the `/home` and `/` directories. - Does not include very many `vim` commands, and therefore shouldn't be called "vim-like." Cursor movement uses "hjkl," but otherwise, the editor is used in a very different manner. - Does not support any plugins, extensibility, of any kind (that I could find).
sullyj3 6y ago
The installation dependency list is missing libxcb.
sullyj3 6y ago
Very cool, has some interesting ideas! Things I love: - Many common operations are a single keystroke - saving, switching buffers, opening a new buffer. Simple design choices like this make the editor feel incredibly fluid. - Jump mode is very cool - Using interactive search for commands and opening files Things that I miss most coming from vim: - text objects - paragraph motion. - Jumping back to the previous cursor location - often useful after a search. Overall, I think the decision to neglect almost all motion commands in favor of focusing solely on jump mode, w/b and hjkl, is mistaken. While f is undeniably fast for many operations, there are cases where it performs terribly. Suppose I want to move a function somewhere else. In vim, I'd probably do something like `{d}` - move to the start of the paragraph, delete til the end of the paragraph. By contrast, Amp's jump mode kind of implicitly assumes I want to be on the start of some word. It's difficult to quickly jump to an empty line. I have to hit f, enter the character pair for the first target in the paragraph, then hit k. Then I go v, hit f again, go to the final target in the paragraph, press j, and finally hit d. That's a 3 character operation that can be performed with muscle memory, to a 10 character operation that prompts the user for input twice, both times forcing them to slow down to visually locate a point near where they actually want to go. That's a pretty massive useability regression. It'd be good to see some better navigation options for use cases like this.

148 points by cassepipe 6y ago

jchw 6y ago

At a glance, it looks like there are no provisions for supporting Language Server Protocol. That's unfortunate as I've come to use gopls, rls, tsserver and clangd quite a bit. Getting accurate autocompletion in complex situations and errors as you type are not absolutely necessary, but once you have them it's hard to go back. edit: rust-analyzer, not rls.

cassepipe 6y ago
True but plug-in API for better language support is apparently on the roadmap
pitaj 6y ago
FYI you should switch to rust-analyzer instead of RLS.
- jchw 6y ago
  Actually, I have been using rust-analyzer, I misspoke.
  - indemnity 6y ago
    You’re both right, rust-analyzer will become official RLS 2.0.

majewsky 6y ago

Constructive criticism: As a Vim user, this website contains nothing that would convince me to actually try Amp. The only thing mentioned on there that does not apply to my Vim setup is "written in Rust". And as much as I love Rust, "written in Rust" is not a sufficient argument to get me to give up a tool that I've been living and breathing for over a decade. If, on the other hand, I'm not the target audience, the website should make that clear, e.g. "Amp is a Vi-like editor designed for people who find Vim too hard to get started with" or whatever.

otikik 6y ago
I am a Vim user too, but I am very different from you. Vim is my main editor. I have used it daily for years. At the beginning I didn't like it. Then I spent time on it. Configured it. Installed plugins. And I still don't like it. But then I try other editors and either I miss one feature or I start pressing j to go down or whatever. I'm Vim's hostage. This editor seems to target me personally.
- atoav 6y ago
  Afaik what the world really needs is a vim like editor with sane defaults, partly overhauled shortcuts that are closer to other tools and some common scenarios solved in less steps (e.g. exiting the editor, multicursor stuff, ...)
  - Jtsummers 6y ago
    What would you do to shorten exiting vim? <esc> :wq Is the longest it's ever been for me and :q Is the norm if I'm in visual mode and haven't edited the buffer.
    - hojjat12000 6y ago
      I think most people don't know that instead of :wq or :q! they can just ZZ and ZQ
      - cassepipe 6y ago
        or just :x
    - ckw 6y ago
      Space is my leader key, save is mapped to <leader>w, exit is mapped to <leader>q, and <esc> is mapped to jk. So nominally exiting from insert mode in an unsaved buffer (jk<space>w<space>q) is the same number of key presses as <esc><shift>;wq<return>, but in practice, in my opinion, jk is superior to <esc>, <space>w is superior to <shift>;w<return>, <space>q is superior to <shift>;q<return>, and <space>w<space>q is superior to <shift>;wq<return>.

jeroenhd 6y ago

What's the advantage of writing an editor like this in Rust? And by advantage, I mean an advantage for me, the end user. I'm quite pleased with neovim and I'm not planning on switching any time soon, so I guess I'm not the target audience for this tool. Then again, who is?

atoav 6y ago
I guess the one advantage is, that you learned Rust really well while creating the editor? Oh and of course if the editor interacts with anything web, less exploitable buffer overflows and other memory errors come free woth it.
cassepipe 6y ago
I don't think it makes a differences that it is written in Rust in the same way it does not really matter that Neovim has a cleaner codebase than Vim's in your everyday use of Neovim. But maybe it will attract Rust devs who are also Vim users in the same Neovim attracted people who are versed in Lua ? I have been using Vim for a while and learned a lot but I hate to have to configure it and the out of the box experience is really missing much. I don't want to have to have to manage something as basic as my text editor. I want a battery-included modal terminal editor that has (mostly) Vim commands and is easy to use. Onivim2 is fast and beautiful but it's a gui and it is not finished. Kakoune looks great but I don't want to learn another set of commands as I might to have to use Vim again and don't want to "lose" my habits. So I am really looking forward Amp 1.0
- memco 6y ago
  I recently learned of nvcode: https://github.com/ChristianChiarulli/nvcode https://github.com/ChristianChiarulli/nvcode. I haven’t tried it yet, but it’s another option in the pre-configured vim space that you might find interesting.
  - cassepipe 6y ago
    Thanks !

johnchristopher 6y ago

I like that `f` jump mode: > Press f to switch to jump mode. Elements on-screen will be prefixed with a two character jump token. Type the characters to jump to the associated element. https://amp.rs/docs/images/jump_mode.gif https://amp.rs/docs/images/jump_mode.gif

senkora 6y ago
Looks like an implementation of avy from emacs, very cool that they included this in the base! https://github.com/abo-abo/avy https://github.com/abo-abo/avy
- sooheon 6y ago
  It's worse than avy because avy (and vim-sneak, evil-snipe et al) allow you to input the prefix char(s). Avy in general is insanely powerful, and abo-abo's set of elisp packages contain some of the most well thought out UX, held back by the rickety shell that is emacs.
laixer 6y ago
Something similar is available in vim via the easymotion plugin: https://github.com/easymotion/vim-easymotion https://github.com/easymotion/vim-easymotion
- johnchristopher 6y ago
  For those like me who had never used easymotion before this is the closest I got to replicate amp behaviour (so far) :map f <Plug>(easymotion-overwin-f2) It doesn't highlight every word with shortcuts first. It does a search based on two characters max and then highlight the results with characters that you can press to move to the corresponding word.

ogre_codes 6y ago

One of the big advantages of VIM is that it's ubiquitous. This has some potentially more intuitive features, but I when I'm setting up a new system, it's not there. It's VIM-like... but just different enough where it seems like it would be infuriating in practice if you had to even occasionally cross between the two. I like that they chose to use an existing format for language bindings. Sublime bindings are pretty decent. Less clear is how you would integrate something like prettier. I suspect that's not even possible right now. I like built in fuzzy search a lot (not sure I like this specific implementation, but a lot better than nothing). I would love to see something like this, but that sticks more closely to VIM in terms of default bindings and features.

tyingq 6y ago

Was trying to figure out why it had openssl as a dependency. Apparently it doesn't anymore: https://github.com/jmacdonald/amp/blob/8b917ac720e7513e5c5bc59697c4a995f688aae9/CHANGELOG.md#L10 https://github.com/jmacdonald/amp/blob/8b917ac720e7513e5c5bc...

lilyball 6y ago

I'm really disappointed that the display of a terminal window with blinking cursor wasn't an actual live demo of Amp.

samatman 6y ago
That would be very cool, although I would make it an image link which jumps to a live demo, just to be kinder on the user's bandwidth and CPU.
- nailer 6y ago
  The user would download a webassembly bundle (compiled from the original Rust) and execute it, similar to most websites. It should be fine.

thibran 6y ago

Does it have something like vim-surround?

sullyj3 6y ago
That's definitely a killer feature for me.

Animats 6y ago

OK, now would someone please rewrite "gedit" in Rust, and make it stop crashing on large files. I use "vim" mostly for looking at log files in the gigabyte range.

3v1n0 6y ago

I guess would be relevant if it was a proper vim implementation in rust, otherwise it wouldn't add anything a part from rust and immaturity.

deleted 6y ago

[deleted]

hermitsings 6y ago

It could be the default editor for RedoxOS

Exuma 6y ago

There's nothing on here to say why this is better than just running vim in the terminal. There's literally not even a list of features or anything to highlight how this is different.

qw3rty01 6y ago

This editor is missing way too many vim helper shortcuts to claim to be vi-like, maybe vi-inspired would be better wording. That being said, the editor looks really nice and jump mode feels extremely intuitive; I might give it a full shot once they get language server support

tyingq 6y ago
Vim isn't vi. You don't have to have many features to be "vi like". That said, the site itself doesn't say "vi like". Their wording seems close to what you're suggesting. "Amp is inspired by Vim's modal approach to text editing, which is reflected in several of its default key bindings. That similarity aside, there are several key differences". https://amp.rs/docs/ https://amp.rs/docs/ Edit: The amp key bindings: https://github.com/jmacdonald/amp/blob/8b917ac720e7513e5c5bc59697c4a995f688aae9/src/input/key_map/default.yml https://github.com/jmacdonald/amp/blob/8b917ac720e7513e5c5bc...
- qw3rty01 6y ago
  The title of the post says a "vi-like terminal editor," and distinguishing vi vs vim is missing the point--I'm not talking about extensive plugin support or features that are specific to vim, the base keymappings are pretty different.

cryptoquick 6y ago

Not really into Vi, but thank you for using this name for something better than whatever Google might want to do with it.

Decabytes 6y ago

Does anyone know how this compares to https://github.com/redox-os/sodium https://github.com/redox-os/sodium besides the fact it is still being actively developed?

kkoncevicius 6y ago

Seems like a lot of defaults are maybe too tightly coupled with the preferences of the authors. These, for example, are weird: > Scrolling up/down in normal mode uses the , and m keys, respectively. > The R key can be used to copy the current file's GitHub URL > p - Paste at the cursor, P - paste on the line above

sullyj3 6y ago
Agree about the second one, that seems weirdly specific, but , and m for scrolling seems reasonable enough and p/P for pasting is the same as the vi family.

desireco42 6y ago

It says inspired by vim but it isn't vim compatible? I am pretty much confused. I heard that Rust community likes to remake everything in Rust, so I guess I can put this in that bucket. Like, we have NeoVim that is pushing the Vim boundaries. This doesn't seem to be trying to do that. I think, as an effort, it is probably very educational to make editor. As a product, it might not be for actual Vim users. As you know Vim is plenty fast, with NeoVim unblocking operations, we have our problems and challenges solved. Clearly Rust is fantastic language I and other devs should pay attention to and learn as it inspires people to make things.

chrisjharris 6y ago
I was thinking the same. There is some cool new stuff in this space (ie Kakoune), which probably is actually somewhat more ergonomic to use than vim/neovim. And maybe this is slightly faster than vim, although vim isn't exactly the kind of program where people complain about it being too slow. But to try to upturn the anthill for a 10% improvement in any direction, on an already excellent product, feels like a mistake.

ziml77 6y ago

I love Rust. I hate when people dismiss things as soon as they see it's written in Rust. But there's no reason for it to be a selling point here. You can have that info as one of the notes on the page, but the key selling point in the title shouldn't be that it's written in Rust.

brundolf 6y ago
It's a selling point if the code is more about being reading material than being a daily driver

samatman 6y ago

Ooh this is promising. In this particular case, when I see "written in Rust" I hear "uses the Rust ecosystem" which is quite a bit more loadbearing than just the choice of programming language. Does anyone happen to know if it uses syntect for highlighting? I wasn't able to determine this in the amount of time I have to browse it. If so, I will be trying this out for sure, I have custom syntax highlighting written in `.sublime-syntax` format and this would be perfect for me. Edit: Don't want to make another top-level post and I sneaked in under the edit window. Is there a community for this? I'm trying to get some .sublime-syntax files installed, and I can't find anything amp-specific in either .config or .local/share/ The project is somewhat underdocumented (it's okay, I expected this) and it would be helpful if there were some friendly devs whose ear I could bend as I get comfortable. If this does exist, it would be a very good thing to link to from https://amp.rs https://amp.rs

swsieber 6y ago
Looking at the dependencies on crates.io it looks like it does use syntect: https://crates.io/crates/amp/0.6.2/dependencies https://crates.io/crates/amp/0.6.2/dependencies
- samatman 6y ago
  Score! Yeah that would have been the obvious place to look, huh. I encourage anyone who is skeptical about "what if $app but Rust" to look at the crates here. Ecosystem quality is very important and Rust has good ones. Consider that wiring together such an app in plain-old-C means inheriting the buffer overflows, memory leaks, thread unsafety, and data races, associated with each and every such library.

skyfaller 6y ago

Relatedly, there's an Emacs-like editor written in Rust called Zee: https://github.com/mcobzarenco/zee https://github.com/mcobzarenco/zee Zee makes some claims about speed, "The 100 FPS editor. Cursor movement and edits render under 10ms." I do not know how to evaluate whether those claims are true. I've become used to using Micro (written in Go) for everything: https://micro-editor.github.io/ https://micro-editor.github.io/ So I haven't really used Amp or Zee much, but I do have both installed on my system just in case I get bored of Micro ;-)

dejj 6y ago

And here I am still trying to get familiar with Kakoune: https://kakoune.org/ https://kakoune.org/

benbenolson 6y ago

Tested this today. - Opening anything larger than a megabyte causes long load times (compared to `vim` and other editors), as well as extreme lag before each cursor movement. - The code, relying extremely heavily on various Rust libraries, is extremely difficult to read due to how it's organized: directories like "view" (which doesn't contain source code pertaining to rendering any actual characters), "models", "modes", etc. - The "jump" feature is good in theory, but in practice is significantly slower than simply continuing to move the cursor normally, as it only works with tokens currently on the screen. - Opening any files in the editor requires the construction of an index so that it can search for things for you. This runs seemingly-unending on both the `/home` and `/` directories. - Does not include very many `vim` commands, and therefore shouldn't be called "vim-like." Cursor movement uses "hjkl," but otherwise, the editor is used in a very different manner. - Does not support any plugins, extensibility, of any kind (that I could find).

sullyj3 6y ago

The installation dependency list is missing libxcb.

sullyj3 6y ago

Very cool, has some interesting ideas! Things I love: - Many common operations are a single keystroke - saving, switching buffers, opening a new buffer. Simple design choices like this make the editor feel incredibly fluid. - Jump mode is very cool - Using interactive search for commands and opening files Things that I miss most coming from vim: - text objects - paragraph motion. - Jumping back to the previous cursor location - often useful after a search. Overall, I think the decision to neglect almost all motion commands in favor of focusing solely on jump mode, w/b and hjkl, is mistaken. While f is undeniably fast for many operations, there are cases where it performs terribly. Suppose I want to move a function somewhere else. In vim, I'd probably do something like `{d}` - move to the start of the paragraph, delete til the end of the paragraph. By contrast, Amp's jump mode kind of implicitly assumes I want to be on the start of some word. It's difficult to quickly jump to an empty line. I have to hit f, enter the character pair for the first target in the paragraph, then hit k. Then I go v, hit f again, go to the final target in the paragraph, press j, and finally hit d. That's a 3 character operation that can be performed with muscle memory, to a 10 character operation that prompts the user for input twice, both times forcing them to slow down to visually locate a point near where they actually want to go. That's a pretty massive useability regression. It'd be good to see some better navigation options for use cases like this.