surfingkeys-conf
surfingkeys-conf copied to clipboard
Incompatible with surfingkeys 1.0
https://github.com/brookhong/Surfingkeys/wiki/Migrate-your-settings-from-0.9.74-to-1.0
Same here, have to downgrade to 0.9.74 at the moment.
https://github.com/brookhong/Surfingkeys/wiki/Migrate-your-settings-from-0.9.74-to-1.0
Thank you for the notice! I will work on this soon.
P.s. I don't really want anyone to submit a PR for this at this time because I have a lot of unmerged local changes that I need to take care of.
We can keep this open until it's fixed
Hey, just wanted to let you all know that I won't begin working on this until the Firefox version of SurfingKeys is updated to version 1.0. It's still on version 0.9.74.
(Ref https://github.com/brookhong/Surfingkeys/issues/1618)
While migrating the API interface to SurfingKeys 1.0, it may be worth mentioning that a compatibility layer can be introduced by simply pasting the following at the beginning of the SurfingKeys configuration:
const {
aceVimMap,
mapkey,
imap,
imapkey,
getClickableElements,
vmapkey,
map,
unmap,
vunmap,
cmap,
addSearchAlias,
removeSearchAlias,
tabOpenLink,
readText,
Clipboard,
Front,
Hints,
Visual,
RUNTIME
} = api;
Maybe it's worth having the build process to automatically insert this block at the beginning of the generated file, or at least document it as a manual workaround while the migration is managed properly?
Re: compatibility
Surfingkeys 1.0.3, on Firefox 96.0.2, is failing to save changes to the settings.
@BlackLight agree
@dhazel
Surfingkeys 1.0.3, on Firefox 96.0.2, is failing to save changes to the settings.
Try to uninstall and then reinstall the extension.
It happened to me as well, and I think it happens to those who had their configuration synced to Gist - SurfingKeys apparently no longer supports Gist and loads the configuration from the filesystem if it's available.
With a workaround you can still load settings from a URL. See https://github.com/brookhong/Surfingkeys/issues/1647
I’ve mostly completed the migration, will push the changes later today.
With a workaround you can still load settings from a URL. See brookhong/Surfingkeys#1647
I’ve mostly completed the migration, will push the changes later today.
Hi @b0o ! Just a friendly ping and not trying to rush you, just checking in to see if you've happened to forgot to push!
For those, who still suffers from this issue, modify gulpfile.js
:
const paths = {
+ compatibilityLayer: "compatibilityLayer.js", // For surfingkeys#1.x^ compatibility.
...
}
...
const build = () =>
src(paths.entry)
.pipe(webpackStream(webpackConfig, webpack))
.on("error", (err) => {
notify.onError({
title: `Build failure [${pkg.name}]`,
message: `${err.message.split("\n").slice(0, 1)}`,
})(err)
throw err
})
.pipe(rename(paths.scriptOut))
- .pipe(dest(paths.buildDir))
+ .pipe(dest(paths.buildDir, { append: true }))
.pipe(
notify({
title: `Build success [${pkg.name}]`,
message: "No issues",
}),
)
// For surfingkeys#1.x^ compatibility.
+ const addCompatibilityLayer = () =>
+ src(paths.compatibilityLayer)
+ .pipe(rename(paths.scriptOut))
+ .pipe(dest(paths.buildDir))
+ task("addCompatibilityLayer", addCompatibilityLayer)
- task("build", parallel("lint", build))
+ task("build", series("addCompatibilityLayer", parallel("lint", build)))
and add compatilibityLayer.js
file:
const{aceVimMap,mapkey,imap,imapkey,getClickableElements,vmapkey,map,unmap,vunmap,cmap,addSearchAlias,removeSearchAlias,tabOpenLink,readText,Clipboard,Front,Hints,Visual,RUNTIME}=api;
After that tasks from gulp will add contents of compatilibityLayer to the start of the final surfingkeys configuration file like @BlackLight suggested in https://github.com/b0o/surfingkeys-conf/issues/48#issuecomment-1024724169. It would look something like this (output of head surfingkeys.js
):
const{aceVimMap,mapkey,imap,imapkey,getClickableElements,vmapkey,map,unmap,vunmap,cmap,addSearchAlias,removeSearchAlias,tabOpenLink,readText,Clipboard,Front,Hints,Visual,RUNTIME}=api;
/*
* ATTENTION: The "eval" devtool has been used (maybe by default in mode: "development").
* This devtool is neither made for production nor for readable output files.
* It uses "eval()" calls to create a separate source file in the browser devtools.
* If you are trying to read the output file, select a different devtool (https://webpack.js.org/configuration/devtool/)
* or disable the default devtool with "devtool: false".
* If you are looking for production-ready output files, see mode: "production" (https://webpack.js.org/configuration/mode/).
*/
/******/ (() => { // webpackBootstrap
Also change addSearchAliasX
to addSearchAlias
in utils.js
for search completions to work.
Very sorry this took almost a year to fix. I've had the changes locally, but didn't get around to pushing them.
Very sorry this took almost a year to fix. I've had the changes locally, but didn't get around to pushing them.
Thank you for all your time and work on this. Hooray~~