The security risks aren't worth it for me, which is a shame.
In theory someone could take nvim, compile it into WASM, and make a version that'll work without interacting with any native binaries (at the cost of some performance and nvim functionality, of course). The only big downside is that you'd lose the integration with the nvim config in your home directory, but perhaps some kind of filesystem API can help with that.
I gave firenvim a shot a few times in the past. The pain points for me were competing shortcuts between extensions (e.g. vimium) and too small realestate in most text area prompts where firenvim activated. I believe the messaging then was that you could just copy paste your nvim config over, and firenvim would use it in the browser. While I think that's true, what makes a good config in the terminal is not the same as what makes a good config in small text area prompts on most websites.
EDIT: I remembered another issue. I'm not able to use it at work because my employer doesn't allow extensions that access all data on a website.
The extension withExEditor[1] can open the editor of your choice in its own window, optionally with a different editor config file. Your editor writes to a file in /tmp and on each write, the text in the input field or area in your browser is updated with the contents of the file. This is an advantage over Tridactyl, by the way, since in Tridactyl you have to close the editor in order to update the text inside the browser.
While the effort for creating an overlay that's painted on top of the original textbox is well intended, a simpler approach would be to open a fixed size window on a fixed position that the user can configure. This way you could set it to your preference and it would work for all kinds of box sizes.
Or maybe give the option to only fall back to this fixed size, fixed position textbox if the box dimensions are smaller than a predefined size.
Yes, that's why I tried tridactyl instead in the end because I was tired to configure firenvim to look and behave like usefully. It combines vimium and firenvim in just one extension and supports having a vim-like config file in your home directory.
The documentation[1] shows examples of how to wrap configuration code and if then block so that section will only run when being triggered from the browser. You can also use this same technique to make config from your terminal that doesn't fit in the extension not appear.
I'm a long-time fan of the Wasavi extension for Chrome/Firefox/Opera, which looks quite similar in terms of user experience. Wasavi is a purely javascript implementation of the vim editing experience, so I believe ends up with a simpler executable model vs launching nvim locally & then bridging to it.
It doesn't have 100% compatibility with vim - no vimscript, for example - but it covers more than enough of the basic movement commands & mappings to be entirely productive for me. I don't know if I would write actual pages of code in it, but I gratefully use it to write long queries in the browser.
Yeah, and the Chrome store is warning about removing it from the store for some best practice violation (no doubt related to the years-since-last-commit).
It does, however, work great for me so :fingers-crossed: I can avoid re-shaving this yak for another few years.
This is great for situations where you need to edit code within an app ecosystem that won't let you dev locally.
My use-case is ServiceNow which forces us into their crappy proprietary editor.
But you do need to get good at calibrating which sites get set off by it because as others have said you don't want it going off an every little text prompt you get most likely
tridactyl has a similar feature. It let's you break out the edit-pane content
into a real vim/gvim editor (default <c-i>). There you have all your vim
environment.
I use this feature very rarely, e.g. when writing multiple lines in
comments and I am in need of the editing power of vim. For simple text input I remain in the browser ui. Getting a vim-editor in all text inputs would be too much for my taste.
I appreciate all the work you and other maintainers put into Tridactyl as it’s the best extension of its kind so far. That being said Vim-in-the-browser still sucks to this day, especially with so many webapp sites that hijack browser shortcuts and never play nice with F-navigation.
Is there a way to completely disable all regular browser shortcuts as well as all key event propagation to the sites themselves, and make Tridactyl the be-all-end-all handler for the keyboard?
For websites stealing keys from Firefox, Tridactyl has some terribly named settings called `leavegithubalone` and `leavegithubalonekeys`
If `leavegithubalone` is set to false (the default) and a website can steal a `leavegithubalonekeys` key from Firefox (usually /) then that is a Tridactyl bug. Unfortunately it is a Tridactyl bug that I do not know how to fix :)
For Firefox stealing keys from Tridactyl, you can patch Firefox without rebuilding it as this intrepid bunch describe here
Another option is the GhostText extension paired with Emacs atomic-chrome.el. I prefer that since it gives a live 2-way sync between a browser text field and an Emacs buffer, instead of going via copy-paste. Unfortunately it only works in the browser.
GhostText is a similar extension that uses your external text editor, which in some cases (especially for short messages) is a worse UI, but has a huge benefit - you won't lose your precious comment data even if all the browser/extension/editor close/crash (with an editor supporting hot exit)!
But also for larger text messages you don't get constrained by the typically small input text fields
In a dreamy ideal world this, of course, would be the kind of basic functionality that any self-respecting OS would offer - in any text input field in any app.
Another alternative is GhostText, which I like for long-form editing - it syncs your text editor with a field, so you can work in your editor. Supports vim & nvim, Sublime, and a few others.
I used to use a similar extension in Chrome called wasavi, but I got burned once too many times by bugs in extension causing me to lose all of the text I had been writing.
I have to understand something, why would I use a Big Tech gigantic c++ ultra complex software to do what a lean-ish C99+ software independent of Big Tech does?
I don’t understand the question? Firenvim is a wrapper for a real nvim instance, so you're using the same executable whether you run nvim in the terminal or browser.
definitely useful, for me personally, the use case is using it to write on lambda as the obsolescence of the old editor while the new one is still useless for me as the vim emulation is not usable. thanks, mate.
Are you saying nvim's vim emulation is insufficient for you? What are you missing?
I've had the same experience with things like vim emulation in vscode but I switched to LazyVim from vim a few months ago and it's been a smooth experience for me.
I think they mean when using the in-browser editor for lambdas in the AWS console. This will let them get actual vim usability instead of an included vim-mode thats not up to snuff.
yea mate, that's correct. when i type things on the new lambda editor then press esc, it actually lost the editor focus not the editing mode to command mode.
I tend to hit that instead of Esc everywhere I'm using a vi-like after having a weird keyboard issue that nerfed my Esc key for a while (long and uninteresting story) and then finding that Ctrl-[ was more comfortable for me anyway.
(of course that may not work at all in the lambda editor, I'm mostly using it in terminals with heirloom-ex-vi, but seems easy enough to TIAS some time)
Another option worth trying is pressing Ctrl-C. Unlike Ctrl-[, it’s not 100% equivalent to ESC (e.g. it prevents abbreviation expansion), but it does put you in normal mode without losing what you did in insert mode.
The security risks aren't worth it for me, which is a shame.
In theory someone could take nvim, compile it into WASM, and make a version that'll work without interacting with any native binaries (at the cost of some performance and nvim functionality, of course). The only big downside is that you'd lose the integration with the nvim config in your home directory, but perhaps some kind of filesystem API can help with that.
> The security risks aren't worth it for me
Care to elaborate? What security risks
Some website breaks the browser sandbox and gains access to your local neovim instance.. RCE
I gave firenvim a shot a few times in the past. The pain points for me were competing shortcuts between extensions (e.g. vimium) and too small realestate in most text area prompts where firenvim activated. I believe the messaging then was that you could just copy paste your nvim config over, and firenvim would use it in the browser. While I think that's true, what makes a good config in the terminal is not the same as what makes a good config in small text area prompts on most websites.
EDIT: I remembered another issue. I'm not able to use it at work because my employer doesn't allow extensions that access all data on a website.
The extension withExEditor[1] can open the editor of your choice in its own window, optionally with a different editor config file. Your editor writes to a file in /tmp and on each write, the text in the input field or area in your browser is updated with the contents of the file. This is an advantage over Tridactyl, by the way, since in Tridactyl you have to close the editor in order to update the text inside the browser.
[1]: https://github.com/asamuzaK/withExEditor
While the effort for creating an overlay that's painted on top of the original textbox is well intended, a simpler approach would be to open a fixed size window on a fixed position that the user can configure. This way you could set it to your preference and it would work for all kinds of box sizes.
Or maybe give the option to only fall back to this fixed size, fixed position textbox if the box dimensions are smaller than a predefined size.
Yes, that's why I tried tridactyl instead in the end because I was tired to configure firenvim to look and behave like usefully. It combines vimium and firenvim in just one extension and supports having a vim-like config file in your home directory.
The documentation[1] shows examples of how to wrap configuration code and if then block so that section will only run when being triggered from the browser. You can also use this same technique to make config from your terminal that doesn't fit in the extension not appear.
[1] https://github.com/glacambre/firenvim#building-a-firenvim-sp...
I'm a long-time fan of the Wasavi extension for Chrome/Firefox/Opera, which looks quite similar in terms of user experience. Wasavi is a purely javascript implementation of the vim editing experience, so I believe ends up with a simpler executable model vs launching nvim locally & then bridging to it.
It doesn't have 100% compatibility with vim - no vimscript, for example - but it covers more than enough of the basic movement commands & mappings to be entirely productive for me. I don't know if I would write actual pages of code in it, but I gratefully use it to write long queries in the browser.
Looks like the last commit was in August 2017. I don't see it in Firefox's add-on search.
https://github.com/akahuku/wasavi
Yeah, and the Chrome store is warning about removing it from the store for some best practice violation (no doubt related to the years-since-last-commit).
It does, however, work great for me so :fingers-crossed: I can avoid re-shaving this yak for another few years.
This is great for situations where you need to edit code within an app ecosystem that won't let you dev locally.
My use-case is ServiceNow which forces us into their crappy proprietary editor.
But you do need to get good at calibrating which sites get set off by it because as others have said you don't want it going off an every little text prompt you get most likely
Oof. I’m sorry.
From someone acquired by ServiceNow… I hope your stock options are worth it
tridactyl has a similar feature. It let's you break out the edit-pane content into a real vim/gvim editor (default <c-i>). There you have all your vim environment. I use this feature very rarely, e.g. when writing multiple lines in comments and I am in need of the editing power of vim. For simple text input I remain in the browser ui. Getting a vim-editor in all text inputs would be too much for my taste.
You might be interested to learn that Tridactyl and Firenvim use the same library to manage getting and setting text across the various JS editors
https://github.com/glacambre/editor-adapter/
I appreciate all the work you and other maintainers put into Tridactyl as it’s the best extension of its kind so far. That being said Vim-in-the-browser still sucks to this day, especially with so many webapp sites that hijack browser shortcuts and never play nice with F-navigation.
Is there a way to completely disable all regular browser shortcuts as well as all key event propagation to the sites themselves, and make Tridactyl the be-all-end-all handler for the keyboard?
For websites stealing keys from Firefox, Tridactyl has some terribly named settings called `leavegithubalone` and `leavegithubalonekeys`
If `leavegithubalone` is set to false (the default) and a website can steal a `leavegithubalonekeys` key from Firefox (usually /) then that is a Tridactyl bug. Unfortunately it is a Tridactyl bug that I do not know how to fix :)
For Firefox stealing keys from Tridactyl, you can patch Firefox without rebuilding it as this intrepid bunch describe here
https://github.com/glacambre/firefox-patches/issues/1#issuec...
You might be interested to learn that this commenter above is the (one of the?) Tridactyl maintainer :)
For emacs folks, you can use emacs-everywhere[1] to similar effect
[1] https://github.com/tecosaur/emacs-everywhere
Another option is the GhostText extension paired with Emacs atomic-chrome.el. I prefer that since it gives a live 2-way sync between a browser text field and an Emacs buffer, instead of going via copy-paste. Unfortunately it only works in the browser.
GhostText is a similar extension that uses your external text editor, which in some cases (especially for short messages) is a worse UI, but has a huge benefit - you won't lose your precious comment data even if all the browser/extension/editor close/crash (with an editor supporting hot exit)!
But also for larger text messages you don't get constrained by the typically small input text fields
In a dreamy ideal world this, of course, would be the kind of basic functionality that any self-respecting OS would offer - in any text input field in any app.
Another alternative is GhostText, which I like for long-form editing - it syncs your text editor with a field, so you can work in your editor. Supports vim & nvim, Sublime, and a few others.
Hah! That's a pretty good implementation! Cursor could just buy them...
I used to use a similar extension in Chrome called wasavi, but I got burned once too many times by bugs in extension causing me to lose all of the text I had been writing.
GhostText provides a live 2-way sync, so there’s no risk of losing anything.
I have to understand something, why would I use a Big Tech gigantic c++ ultra complex software to do what a lean-ish C99+ software independent of Big Tech does?
I don’t understand the question? Firenvim is a wrapper for a real nvim instance, so you're using the same executable whether you run nvim in the terminal or browser.
AI...
definitely useful, for me personally, the use case is using it to write on lambda as the obsolescence of the old editor while the new one is still useless for me as the vim emulation is not usable. thanks, mate.
Are you saying nvim's vim emulation is insufficient for you? What are you missing?
I've had the same experience with things like vim emulation in vscode but I switched to LazyVim from vim a few months ago and it's been a smooth experience for me.
I think they mean when using the in-browser editor for lambdas in the AWS console. This will let them get actual vim usability instead of an included vim-mode thats not up to snuff.
yea mate, that's correct. when i type things on the new lambda editor then press esc, it actually lost the editor focus not the editing mode to command mode.
See if Ctrl-[ works.
I tend to hit that instead of Esc everywhere I'm using a vi-like after having a weird keyboard issue that nerfed my Esc key for a while (long and uninteresting story) and then finding that Ctrl-[ was more comfortable for me anyway.
(of course that may not work at all in the lambda editor, I'm mostly using it in terminals with heirloom-ex-vi, but seems easy enough to TIAS some time)
Another option worth trying is pressing Ctrl-C. Unlike Ctrl-[, it’s not 100% equivalent to ESC (e.g. it prevents abbreviation expansion), but it does put you in normal mode without losing what you did in insert mode.
That is awesome! Can't wait to try it.
Does it break things?
edit-server.pl for nvim? Does it work?
[dead]