Surfingkeys 1.0

[brookhong]

I'm refactoring the project and will release 1.0 hopefully. The goal is to

• integrate with neovim with native messaging.
• settle down the public APIs for setting snippets and document them.
• improve the build process with webpack.
• add unit tests.
• remove the Mermaid diagram generator, which is unnecessary for the extension.

So no more feature requests or bugs will be addressed for current release 0.9.74. The code change is big, and will need some little change in your setting snippets, but there will be no impact if you're a basic user which means you don't customize setting with snippets. As said, the code change is big, I can not provide the expected date of arrival now.

For anyone who is interested with the neovim integration, please see Use neovim in Google Chrome / Chromium through Surfingkeys - YouTube for how it works.

Thanks for your attention.

[gkzhb]

Will this refactoring migrate the extension to Manifest V3? Considering the chrome.tabGroups APIs rely on it.

Well, since Manifest V3 breaks TamperMonkey currently, Surfingkeys will also have to use Manifest V2 to allow to execute user scripts until Manifest V3 supports to execute user scripts.

Ref: Tampermonkey/tampermonkey#644

[aspiers]

Please can you review my suggestions for how to make this upgrade smoother? Thanks!

[aspiers]

Additionally, the documentation in the README.md has not been updated, even though 1.0.0 is already released - I suggest that in future the release is not done until the documentation is ready, otherwise this will inevitably cause more confusion. Most users are much more likely to read README.md than a page in the wiki which is hard to discover.

[brookhong]

@aspiers Thanks a lot for you great suggestions, all of them make sense.

Sorry for the confusion, though such chaos is expected and I had pined this issue for mitigation almost 3 months ago, it did make me nervous when it came, as so many people are impacted, not to mention those related issues here, there are also messages coming from different channels such as email, review comments on web store and personal IM.

The root cause is that I haven't designed those public APIs well from the very beginning, which exposed too much internal implementations and made settings snippets uncontrollable and unexpectable, and that is why it is the second goal of this refactoring.

Some hot fix is pending review on Chrome Web store now, hopefully it will fix some missing/broken APIs and make error message explicit that it is from Surfingkeys.

[aspiers]

Thanks a lot for listening @brookhong ! And as always, thanks for this incredibly awesome extension 😁

[Stvad]

FF version does not seem to be updated? I have a shared config, and I expect if I update it'd break the things in FF that runs the older version

[Stvad]

addVimMapKey does not seem to be defined in API (have been using it to remap some built-in vim behavior)

[glacambre]

@brookhong I see that you're adding "true" neovim support to Surfingkeys in v1.0. Do you still need the integration code in Firenvim, or can I remove it?

Also, I see that you re-used some of my code, would you be interested in finding a way to share code in a more permanent way? This way we could share improvements, should they happen :)

[brookhong]

@glacambre Thanks for reaching out.

No, the integration code in Firenvim side is not necessary now, please help to remove it. The reason I'm trying to reinvent the wheel is

• The integrated workflow with Firenvim is not smooth and consistent with Surfingkeys.
• Firenvim can not repeat a key when it's being held, which means user can not hold j to continuously go down a line.

Then I found vv-vim/vv: Neovim client for macOS which can repeat a key when it's being held, therefore current implementation of neovim integration basically based on two projects

• vv-vim/vv for renderring and nvim RPC event handling
• glacambre/firenvim for nvim server setup

To integrate above two parts within Surfingkeys, there are many changes in either of them, especially in vv-vim/vv. For nvim server setup, Surfingkeys/server.lua contains all the logic, it should be possible to share code in a more permanent way as most of the code are from firenvim/lua. My changes are

• customize a surfingkeys:// URI scheme for writing back to browser with rpcnotify, rather than a temporary file.
• some other minor changes for server setup
• group all modules in one for easy setup

PS: I'm not quite happy with current neovim integration in Surfingkeys now, the main drawback is the render from vv-vim/vv seems to be too heavy(it uses pixijs/pixijs as render engine) for an in-page editor so that it has a poorer performance than glacambre/firenvim, also can not be expanded to Firefox and Safari, as there are some canvas APIs not available in those browsers.

[glacambre]

Firenvim can not repeat a key when it's being held, which means user can not hold j to continuously go down a line.

Thanks for letting me know, I wasn't aware this was an issue. It seems to work fine on linux(wayland)+firefox, what OS and browser are you using? Are you using an input method?

I'll look at Surfingkeys' code in more detail and try to figure out if I could make Firenvim integrate better :).

[wll8]

feat: the same element should try to keep the same shortcut keys

Press F

Press ESC to operate the page, add an element, then press F

The same element has different shortcut keys. This results in the need to carefully observe the new shortcut keys again to perform the same function. If we can keep the same shortcut keys as much as possible on the same element, this will be a [real shortcut key], and we can even close our eyes and know what we are doing.

Is there any plan?

After the shortcut key is generated for the first time, use XPATH or SELECT PATH as the sign to save the shortcut key. When generating shortcut keys again, the same flag will first obtain shortcut keys from the saved list, and only regenerate those not in the list.