Open tombh opened 6 years ago
This isn't as easy as it might seem at first glance. Sure it's easy to implement G, gg and commands like that, but the devil is in the detail.
Vimium is really an excellent extension that I'm using and I'd hope that browsh can provide a way to integrate such extensions instead of reinventing the wheel.
Ah yes, very good point about using an existing extension. So this relates to: #45
Even just being able to use h,j,k,l and G, gg commands would be a really nice start. The link-hit mode that Vimium uses would probably be tricky, but why not start with just letting h,j,k,l double as arrow keys? That's actually how I expected browsh to work when I first fired it up and was a little surprised when it didn't.
Sure, that would be a good start because that already introduces the concept of modes, which is the entire basis of Vim
~As Vim 8 comes with a built-in terminal, maybe that's the better way?~ bullshit, sorry
I don't suppose Vim 8 will understand how to identify an anchor tag, or focus input boxes.
This would be a game changer! Hopping from a tmux pane with vim to another with Browsh would make me a lot faster.
vimium key bindings would be best.
Here is my list of essential vimium bindings:
Navigating the page: j Scroll down k Scroll up gg Scroll to the top of the page G Scroll to the bottom of the page d Scroll a half page down u Scroll a half page up h Scroll left l Scroll right r Reload the page yy Copy the current URL to the clipboard p Open the clipboard's URL in the current tab P Open the clipboard's URL in a new tab gu Go up the URL hierarchy gU Go to root of current URL hierarchy i Enter insert mode v Enter visual mode gi Focus the first text input on the page f Open a link in the current tab F Open a link in a new tab yf Copy a link URL to the clipboard
vomnibar: o Open URL, bookmark or history entry O Open URL, bookmark or history entry in a new tab T Search through your open tabs e, ge Edit the current URL gE Edit the current URL and open in a new tab
Using find: / Enter find mode n Cycle forward to the next find match N Cycle backward to the previous find match
Navigating history: H Go back in history L Go forward in history
Manipulating tabs: t Create new tab J, gT Go one tab left K, gt Go one tab right ^ Go to previously-visited tab g0 Go to the first tab g$ Go to the last tab yt Duplicate current tab x Close current tab X Restore closed tab
I copied this list from vimium's help page and removed features that I consider non-essential. Most of the keybindings are indeed very useful and therefore I kept them. Most of them aren't hard to implement either.
If vim-like mode are introduce, I strongly advice to implement a way to change the binding because every plugins I've tested on Firefox have at least one bind that is really weird. For example, Vimium and "x" to close a Tab. So easy to close it by accident when it's only one key. Personnally, I always remap it to "dd" like deleting a line in Vim.
@dannycolin Agreed.
:+1: on this.
Or, even more generally (but not solving the modal issue), configurable keybindings.
Related to this, if the UI and rendering are seperate modules, it would help not just with adding vim mode bindings, but with things like using this to render HTML email inside Mutt, etc etc.
Just a little update: I noticed that @gotbletu has had some success with the Vim Vixen extension in getting keyboard navigation to work: https://www.youtube.com/watch?v=HZq86XfBoRo&feature=youtu.be&t=514 I wonder if this a good enough base to explore as formal solution? Obviously there are currently some issues, but would it be less work to fix these issues and piggy back off the work of an existing Vim mode, rather than build a native Vim mode from scratch?
@cl3wis That's a really, really good point - an excellent framing of the problem.
@snoblenet Is that already possible with Browsh's HTML service? If you run browsh -http-server
then you can pass URLs to localhost:4333/http://example.com
with a special header and it will return plain text. See here for the docs: https://www.brow.sh/docs/in-browser-usage/
Regarding closed issued #152 and #154: Keyboard navigation of links would be part of any implementation of a vim mode. It's one of the main reasons for wanting a vim mode in the first place. The choice of whether to use home row keys or numbers for this is an implementation detail and should be user configurable.
Responding to @ArniDagur question: yes we first need to design a method for distinguishing gg
from a repeated g
, g
. I suspect this will be a combination of being in a certain mode, namely similar to Vim's normal mode and using a specific timeout, after which a subsequent keypress is consider another command.
I'm currently working on this feature and will upload a merge request in the coming days and weeks.
The basic navigation features like h, j, k, l, H, J, K, L, G, d, u, t, gg and so forth are working, so I'm actually working on some advanced features and most importantly I want to implement a find mode.
I've implemented many vimium features now, and most importantly I'm currently working on a port of vimium's own link hinting algorithm, which seems to be coming along nicely. I'm excited to release this code as soon as possible, but there are still a few things to do. The find mode is working except for a scrolling issue I have to solve. I can assure everybody that'll upload a merge request sooner than later. I haven't really implemented visual or caret mode yet, I think those modes can be implemented later.
I got sidetracked, so this has taken longer than anticipated. I just pushed a new branch vim-mode-experimental that you can build and have fun with. The basic vim navigation works, searching works except that it's not automatically scrolling to the right position yet, link hinting generally works and you can also select input boxes using it, there's a basic caret mode (don't know how useful that is).
There's much more I wanted to get done for this navigation mode, some parts feel hacky and others aren't finished like the search feature.
Key bindings can't be configured yet, however it's straightforward to change it directly in the code in config.go.
Please give it a try and report any issues you have.
When you try the vim-mode-experimental branch, you'll notice that it's not only a vim-mode, but rather the default way for navigating. Other text-based browsers also use vim like navigation per default, so we might want to do the same. The keybindings will eventually be configurable, of course.
Any update on this? It would be very useful for those of us who use a TTY and can't have a mouse driver. Thank you :)
This is definitely one of the most important new features. I just still haven't had time to get back on Browsh
Also why simply adding this extension doesn't work? https://addons.mozilla.org/en-CA/firefox/addon/vimium-ff/
It seems to be successfully added to extensions.json
for Browsh's firefox-profile, yet keybindings doesn't recognised.
I mean it should in theory work. I don't have any intuition why it wouldn't. I'm curious myself why it doesn't work. I think it wouldn't be as good, because its UI would have to be parsed by the Browsh engine. The idea in #439 is definitely the best approach.
It pains me every time I think about this feature, and how much work other people have put into this, and how I still haven't merged it.
It pains me every time I think about this feature, and how much work other people have put into this, and how I still haven't merged it.
It is definitely a desirable feature. The whole reason I (and probably many others) am interested in brow.sh is to use in a tty/fbterm where there is no mouse, so Vi mode is a must for that use case.
Any updates on this?
Can someone please detail how to build from source to use the vim-mode-experimental
branch? I can not get interfacer/contrib/build_browsh.sh
to work anymore in golang 19.
Any updates? This seemed to be in progress 5 years ago, was it dropped as a feature? Having vimium like browser experience in my terminal would be a game changer, and brow.sh seems to be the closest someone has gotten to that. If anyone else is interested a bounty could be introduced
I would also love to get this working. I'm using qutebrowser and although I love the idea of browsh, using vim-key bindings is just way too good. would love to see this implemented!
maybe, it's better to implement like this: https://github.com/fathyb/carbonyl/issues/178
to make it work on vim, i think it lacks only one very basic feature: communicate with carbonyl from external process, by something like Language Server Protocol
here's the main thoughts:
- run carbonyl in background, without UI (by vim's job, or similars for other editors, etc)
- by something like :
carbonyl --server --width=80 --height=30
- communicate with carbonyl, by stdio or socket (like LSP)
- page op : load page, refresh, etc
- mouse touch : scaled with terminal size, sending touched position
- keyboard input : sending pressed keys
- carbonyl render the output, to stdout
- vim got the output, and render it in vim's way
by achieving this, i think it is also possible to solve many ssh related issue (like https://github.com/fathyb/carbonyl/issues/124, https://github.com/fathyb/carbonyl/issues/140), users can wrap carbonyl by their own shell or editor, to adapt more envs
We can take the lead from something like: https://vimium.github.io/