browsh-org / browsh

A fully-modern text-based browser, rendering to TTY and browsers
https://www.brow.sh
GNU Lesser General Public License v2.1
16.84k stars 409 forks source link

Vim mode #31

Open tombh opened 6 years ago

tombh commented 6 years ago

We can take the lead from something like: https://vimium.github.io/

tobimensch commented 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.

tombh commented 6 years ago

Ah yes, very good point about using an existing extension. So this relates to: #45

michaelnew commented 6 years ago

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.

tombh commented 6 years ago

Sure, that would be a good start because that already introduces the concept of modes, which is the entire basis of Vim

dertuxmalwieder commented 6 years ago

~As Vim 8 comes with a built-in terminal, maybe that's the better way?~ bullshit, sorry

tombh commented 6 years ago

I don't suppose Vim 8 will understand how to identify an anchor tag, or focus input boxes.

michaelmcmillan commented 6 years ago

This would be a game changer! Hopping from a tmux pane with vim to another with Browsh would make me a lot faster.

tobimensch commented 6 years ago

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.

dannycolin commented 6 years ago

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.

tobimensch commented 6 years ago

@dannycolin Agreed.

cl3wis commented 6 years ago

:+1: on this.

Or, even more generally (but not solving the modal issue), configurable keybindings.

snoblenet commented 6 years ago

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.

tombh commented 6 years ago

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/

tobimensch commented 6 years ago

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.

tombh commented 6 years ago

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.

tobimensch commented 5 years ago

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.

tobimensch commented 5 years ago

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.

tobimensch commented 5 years ago

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.

tobimensch commented 5 years ago

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.

dotexe1337 commented 2 years ago

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

tombh commented 2 years ago

This is definitely one of the most important new features. I just still haven't had time to get back on Browsh

arbitrary-dev commented 1 year ago

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.

tombh commented 1 year ago

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.

dotexe1337 commented 1 year ago

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.

davehouser1 commented 1 year ago

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.

Nikola-Milovic commented 1 year ago

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

emilBeBri commented 5 months ago

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!

ZSaberLv0 commented 5 days ago

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:

  1. 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
  2. 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
  3. carbonyl render the output, to stdout
  4. 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