Skip to content

MORE MOTIONS#288

Open
philocalyst wants to merge 7 commits intoglide-browser:mainfrom
philocalyst:more-motions
Open

MORE MOTIONS#288
philocalyst wants to merge 7 commits intoglide-browser:mainfrom
philocalyst:more-motions

Conversation

@philocalyst
Copy link
Copy Markdown
Contributor

  • There was a ton of motions that I wanted to exist in Glide, but didn't yet.
  • I saw the release of the claude-code source, which (I heard, I actually don't use LMAO) has a really good Vim motions engine in TS, just like Glide! So I ported the ones I wanted here.
  • This brings:
    • Find
    • Till
    • Go to end
    • Go to beginning
    • A lot more text objects
    • Numbered repeats.

AS A FOLLOW UP QUESTION:
Is it in Glide's scope to support other input methods, like Helix or Emacs bindings? Would be a MUCH larger PR, but interesting to me.

why do i never see these
@RobertCraigie
Copy link
Copy Markdown
Member

So I ported the ones I wanted here.

Thank you!

From a quick skim of the changes here, the main thing missing is adding tests (e.g. https://github.com/glide-browser/glide/blob/main/src/glide/browser/base/content/test/motions/browser_normal_motions.ts), would you be up for adding tests?

Is it in Glide's scope to support other input methods, like Helix or Emacs bindings? Would be a MUCH larger PR, but interesting to me.

Input methods that operate entirely differently (helix) are not in scope right now, that would just be too much work.

Supporting an emacs mode out of the box is something I'd be interested in providing in the future though as it should mostly just be figuring out the right keymaps instead of changing the operating model (afaik I am not super familiar with emacs).

@philocalyst
Copy link
Copy Markdown
Contributor Author

Long-term... When I was developing this I ran into this project: https://docs.rs/modalkit/latest/modalkit/.

Would Glide be open to instrumenting with it? Because I know NAPI bindings could be created, and then upon integration would provide a complete emacs AND vim set. Notably, one that we wouldn't have to mantain, as opinions here are particular. Also makes the long-run viabilitiy of newer schools of keybinding thought more feasible to integrate.

@RobertCraigie
Copy link
Copy Markdown
Member

yeah I am definitely open to outsourcing the motions implementation. the reasons I didn't go with that originally were mainly around concerns that it'd make customising motions more difficult and I just have no idea what that API would look like.

but that said, I think that was a mistake, customising that deep is likely pretty niche and I'm sure we could figure something out if we really need to.

@philocalyst
Copy link
Copy Markdown
Contributor Author

philocalyst commented Apr 23, 2026 via email

@RobertCraigie
Copy link
Copy Markdown
Member

Firefox have their own system for calling into compiled code from JS so we should piggy back off of whatever their setup is, I haven't personally done this before so I'm not sure what it looks like exactly.

Having some amount of rust code in the tree is totally good with me. Although I haven't looked into the options here, how confident are you that modalkit would be a good choice? is there anything potentially better?

@philocalyst
Copy link
Copy Markdown
Contributor Author

philocalyst commented Apr 23, 2026

There's actually hundreds of motion implementations, but modalkit specifically is ideal because it's made to go beyond just input motions, but whole-application modal keybindings, which fits the bill for an application like Glide. I'm confident in it specifically because it's being picked-up by Nushell see here and used in iamb.

Very exciting, I'll do some research later.

@RobertCraigie
Copy link
Copy Markdown
Member

Ah interesting, excited to see what it could look like!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants