Export and import customized shortcuts (partially fixed in dev) #245

zhuochun · 2014-01-02T17:25:01Z

Support export and import customized shortcuts?

Export a text file of any kind, or
Auto sync using Firefox's Sync

nogweii · 2014-01-03T18:56:42Z

I would very much love to see Sync support included as well.

I haven't looked into the documentation much for FF APIs, but as I understood it it should be as simple as flagging the various about:config settings to be synced. If it is that simple, then enabling sync on extensions.VimFx.commands.* and extensions.VimFx.hint_chars is probably enough.

EDIT: Seems like I was right. The Sync documentation documents how to flag a preference for sync. A lot of boolean true services.sync.prefs.sync.extensions.VimFx.*

akhodakivskiy · 2014-01-04T00:02:21Z

Yeah, seems trivial. There are two open questions:

We need to test this. Testing requires releasing a version with this feature.
Will wildcards work? Testing will answer this question if the documentation doesn't answer this question.

lydell · 2014-01-04T17:16:08Z

Is it possible to add services.sync.prefs.sync.extensions.VimFx.* prefs manually via about:config, just to test stuff?

akhodakivskiy · 2014-01-04T21:43:18Z

Ah right, good idea! Will test on Monday when I'm back home

noc7c9 · 2014-01-17T23:38:02Z

Might I you guys take this as a chance to implement a .vimfx file instead of export/import? This is in addition to sync of course.

lydell · 2014-01-18T10:25:28Z

Nope, no .vimfx file. A similar idea was discussed in #149, in there @akhodakivskiy sums it up:

On top of that where is this file supposed to be stored? In Extension package? How are we going to modify it? Also proper way to store customizations for users in Firefox is via standard preferences.

dvarrazzo · 2014-03-19T18:18:07Z

Would it be possible to just have a box where to configure the custom key mapping as Vimium for Chrome has? That solution is perfectly usable by people used to text files, which are the only people who would use vim-inspired keybindings, and allows porting the bindings back and forth between chromium and firefox.

bohrshaw · 2014-04-14T05:12:43Z

@dvarrazzo Vanilla text presentation of key mappings would also allow porting between multiple Firefox profiles, which is another feature request, other than syncing.

And as we rarely configure these keys after the initial setup, I think the advantages or convenience the current mapping interface provides are less than needed, especially when syncing is implemented.
But of course I still appreciate the current beauty of the mapping interface. I guess we should first figure out how to sync. Do we have any progress on this somewhat trivial problem?

lydell · 2014-04-17T16:22:14Z

I’m actually in favor of a .vimfx file now.

Personally I love text files for configuration. A text file shows you exactly what you have changed. It makes it easy to backup. It makes it easy to port to other systems, or to reinstall your system. It’s super easy to configure, because I can use vim’s super powers to do it, instead of clicking buttons and checkboxes. And I simply love plain text.
The “blacklist”, “prev patterns” and “next” patterns quickly become really difficult to edit in those one-line text inputs in the Add-ons Manager settings.
We need to invent some UI for the proposed key aliases. A text file would be a lot simper.
Same thing for the proposed custom commands.
It could be possible to implement optional per-site mappings #255 in a simple and clean way.
It allows users to extend the default settings. Users can use the default prev patterns and their own, and still get updates to the default prev patterns, for example.
Lots of VimFx users are also vim users, so they will (probably) appreciate it. It might be a barrier for less technical or non-vim users, though. Not sure how many they are.
We cannot use Firefox Sync, though. To me that is not a problem. I sync my dotfiles anyway.
I guess we have to remove the blacklist button in the button menu though, requiring manual addition of patterns to .vimfxrc instead. I don’t know how much that feature is used. Personally I don’t use blacklisting at all.

This is what I suggest:

The Add-ons Manager settings will be removed, and replaced by a single text input that sets the path to the configuration file. It defaults to ~/.vimfxrc (<drive>:/users/<user>/_vimfxrc or something on Windows). There is also a “Help” button that takes you to online documentation. There could possibly be a button that re-reads the configuration file so that you don’t have to restart Firefox each time you edit it.
The default settings are implemented as a text file too. This makes it very easy to read the defaults, and copy bits of it.
The “help” dialog will be changed to only list all commands with the current keys. No customization. The command names to use in .vimfxrc could possibly be there, too, to make it easier to remap.
The syntax should be simple and look like .vimrc. I think we should make it a superset of Vimiums mapping syntax. (That way it will be easy to sync your mappings with Vimium. I know people who use both browsers and both add-ons. Really, it would be nice to share some command names between the add-ons, too.)
Blacklisting could become an implicit feature. There could be a way to make blocks of .vimfxrc only apply on URLs matching some patterns. Then you could stick unmapAll in such a block to blacklist sites. Or you could unmap just the commands you want to (as requested in optional per-site mappings #255).

Lastly, the current key customization UI in the help dialog is not optimal, and it is buggy. I’ve been meaning to improve it, but never got around to it. That’s one of the more boring parts of VimFx. I’d rather spend time on implementing the simple configuration file and improving and adding features to VimFx, than on fixing that UI.

What do you think, @akhodakivskiy? I know that you’ve said that you want all prefs to be done the standard Firefox way, but I don’t think the standard Firefox way fits VimFx very well. JSON strings as pref values make me iffy.

bohrshaw · 2014-04-18T06:49:24Z

Manipulating plain texts is for sure more enjoyable for us Vim users. But I guess we don't need such an external configuration file. Instead, I suggest keep all customizations in a single editable text area, inside the addon's option page.

lydell · 2014-04-22T15:39:32Z

I think I’ve come up with the perfect compromise between the current customization, a plain text area of configuration and a .vimfxrc file, that let us get all the benefits of text configuration without changing the current look and feel. I’ll post my ideas soon.

lydell · 2014-04-22T18:09:29Z

I think the “help dialog” should have a tab which consists of a text area, where the user can configure VimFx.

You may of course copy and paste its contents to port your settings.
The contents of the text area is stored as a regular FireFox string setting, which means that we can use Sync. We also avoid the hassle of working with a real file somewhere in the user’s file system.
If the user wants to edit the configuration in vim (or any other text editor), he may do so using the “It’s all text!” extension.

You will still be able to customize the keyboard shortcuts (semi-)interactively, just like now.

In the “help dialog”, clicking one of the plus buttons takes you to the customization text area, and appends map | <command id> to it. The pipe character shows where the cursor would be automatically placed. <command id> is the command id of the command whose add button you pressed. This corresponds to the current behavior of opening a prompt when clicking an add button.
The customization text area has a button, which when clicked makes the next keypress in the text area not fire its default action but instead print its key name. For example, the left arrow key would not move the cursor to the left. Instead it would insert <Left> at the cursor. Pressing ctrl+shift+a would insert <c-A>. Pressing “q” would insert q. This way we achieve the “key capturing instead of string entry” feature that has been discussed before. There is also a keyboard shortcut for this button.
In the “help dialog”, clicking a shortcut no longer removes it. That has always felt a bit weird to me. Instead it takes you to the map ... directive that adds that shortcut, letting you edit or remove it. (Perhaps the text area could feature a “remove line” button/shortcut to make it easier to remove mappings.) If the shortcut you clicked was a default shortcut, unmap <command id> could be prepended instead. (Perhaps there should be a remap directive, too, that is short for unmap followed by map?)

Blacklisting using the toolbar button works like before. But instead of modifying the blacklist string setting, the configuration is modified, by adding and removing blacklist directives.

Lastly, some random notes:

Resetting thing to default simply means removing stuff from your configuration.
This approach should be nice to both people used to vim and/or text file configuration and people who prefer GUI configuration.
It will be possible to comment out parts of the configuration, instead of having to remove shortcuts or patterns.
Mappings, patterns and aliases are not easily stored and edited using “standard” Firefox prefs.
It will be possible to edit your shortcuts, instead of just removing and re-adding.
The proposal still preserves VimFx’s current feel.
It’s pretty easy to implement. I’ve got the time.

bashseb · 2014-07-02T11:13:24Z

Hello @lydell and @akhodakivskiy. Have you made up your mind about this topic?
I ran git grep sync and grep -R sync, but didn't find any update on the topic.

I'm just a normal user, so sync via firefox sync would be greatly appreciated. However, I can workaround with git dotfiles as well.

Let me also say thanks for your previous work.

lydell · 2014-07-02T15:33:31Z

Nope, we haven’t decided on anything, and haven’t implemented Firefox sync support.

My vision is this:

Save all preferences in a text format, in a single Firefox pref.
Make that Firefox pref Firefox Syncable.
Provide a text box (using the built-in CodeMirror, which means optional vim bindings support while editing) to edit the text format pref.
Power users can edit it directly (and copy and paste instead of syncing, if they wish).
You may also use the current GUIs to edit preferences. They simply make edits to the text format automatically.

I start my vacation next week, and plan to devote some more time on VimFx then.

lindhe · 2015-05-23T18:17:44Z

What's the status on this? I'd really like to be able to export/import settings, since I make extensive use of custom key bindings...

lydell · 2015-05-23T19:35:20Z

This is not a priority right now. I’d suggest looking for an add-on that can import and export Firefox prefs in general. Perhaps OPIE is a good choice.

lydell · 2015-05-24T07:09:31Z

I just realized that at least enabling Firefox Sync support for what we already have might be quick and simple. However, the MDN dkcs @evaryont linked to is now in the "Archive of obsolete content". I don't use Firefox Sync myself, so I don't know much about it. Is it no longer possible to sync add-on prefs?

akhodakivskiy · 2015-05-24T08:24:55Z

I do use Firefox Sync, and it is possible to sync add-on prefs. We just need to set up a few additional properties to enable sync, e.g. properties like services.sync.prefs.sync.extensions.vimfx.some_property_to_sync. I remember trying this back in the time, it didn't work quite well right away, but it does work well for other addons as of today.

lydell · 2015-05-24T09:04:09Z

I’m just worried because all Firefox sync docs on MDN are archived …

This commit is unfortunately very large. I do not like that, but most of the things in this commit are very closely related, which made it easier to do it this way. Help dialog =========== - It is no longer used to customize shortcuts. That's done in VimFx's settings in the Add-ons Manager instead. - Moved "enjoying/found bug" from the Help dialog and into the readme. The readme will be used as the extension description on AMO. That description is also shown in the Add-ons Manager, so users will see it when customizing VimFx. - It is no longer injected inside web pages, but in the Firefox chrome. This allows to get rid of the nasty resets in the CSS and makes it impossible for page elements to cover it. #477 - It now fills the entire page and adjusts based on your screen size. It is designed to work with lots of shortcut customization and the additon of new modes by other extensions. - Added `gulp help.html` to make it easier to style the help dialog. Settings UI =========== - Shortcuts customization is now done in VimFx's settings page in the Add-ons Manager. This keeps all settings together and makes it obvious that you can customize the shortcuts. The new UI is also more accessible. - The new UI also lets you: - Insert the default value of a pref. This is useful for the "prev/next patterns" by letting you merge in new defaults into your own customizations. - Reset to the default value. #262 - Insert the next keypress as text. The default shortcut for this is `<c-q>`. (q as in quote. vim also has this shortcut, which works like its `<c-v>`.) For example, if the user is unsure how to express `<c-enter>` (s)he could simply press `<c-q><c-enter>` and `<c-enter>` would be inserted as text. Button ====== - Now has high-resolution images. #383 - Is now implemented using CustomizableUI. #303 #349 - Greatly simplified: - If in normal mode, clicking it opens the help dialog. - Otherwise it exits the current mode returning to normal mode. This is useful if the user accidentally removes the keyboard shortcuts to exit modes, or don't know how to exit insert mode, for example. The above means that the "disable" feature has been removed. The UI to "blacklist" sites has been removed as well. See the "Removed/Changed/Addesd features" section for more info. - It is now easily stylable with user CSS. - State is no longer lost when moving a tab into a new window. #57 Removed/Changed/Added features ============================== - The "disable" feature has been completely removed. It is rather useless compared to insert mode, and sometimes trips new users up. #327 - The "blacklist" feature has been changed into an "auto-insert-mode" feature. It is basically the same, except that you can actually choose to leave the blacklisted state for a while if you feel like it. The default shortcut to leave insert (`<s-escape>`) is not likely to conflict with page shortcuts. It is possible to disable the exit shortcut on certain pages using the public API. - The "blacklist" feature has been de-emphasized. The button no longer offers any UI to blacklist and un-blacklist sites (see above). VimFx is supposed to be keyboard driven, so having a mouse-oriented UI makes no sense. Blacklisting is also a bit of an anti-feature, so we shouldn't maintain lots of UI code for it. It's simple enough to just open the Add-ons Manager and add `*currentdomain.com*` to the blacklist setting. - The "blacklist" no longer supports the `!` wild card (that matched a single character) to keep things simple. The less to explain to the user the better. If users need more advanced wildcards than the simple `*` they can use the public API (see the Public API section) which allows to use all of JavaScript's power. - The "blacklist" no longer supports the `##key1#key2` syntax to disable certain keys on certain sites. Instead a superior public API function is offered. This feature only existed in the develop branch for a while and was never released. Any users of it must manually move to the public API. - The "prev/next patterns" no longer support the `*` and `!` wildcards. Instead they are treated as regexes (which allows to use `.*` and `.` instead). This is way simpler, and more powerful. Non-technical users can just keep adding simple patterns such as "next" translated into their language without being troubled by regex syntax, while advanced users can use the full power of regex if needed. The public API may of course also be used for unlimited power. - The "blacklist" and "prev/next patterns" are no longer comma/space-separated. To keep things simple their just space-separated. Space is not a valid URL character, but a comma is, so this allows to match a URL which ends with a comma (but that is probably too rare to ever be useful). More importantly it makes the settings easier to read. Space could be part of a "prev/next pattern", though. Thanks to the above point one may use `\s` instead, which is also more robust. The prefs are automatically migrated to the new format. - The "translations" pref in about:config is no longer used. Instead you have to use the public API. This is because it is an advanced feature and next to impossible to manage as a single line of JSON. This also keeps the code simpler. The pref only existed in the develop branch for a while and was never released. Any users of it must manually move to the public API. - Most hard-coded constants have been moved into prefs, which can only be changed via about:config or the public API. For advanced users only. For example: - "prev/next patterns" attributes. #489 - "target blank prevention". #452 - Pressing `aj` used to trigger the `j` shortcut, but doesn't any longer. Since there is no `aj` shortcut (by default) nothing happens. The reason that "feature" used to exist was because there used to be no concept of a timeout. For example if you pressed `a`, went from the computer for a while, came back and pressed `/` the `a/` shortcut would be invoked, which is a bit surprising. Now there is a timeout instead, which defaults to 2 seconds. So if you type `aj` with less than 2 seconds between the key presses, nothing will happen. Otherwise the `a` partial match will be cancelled and the `j` command will be invoked. This is more like vim works. - The escape command used to be special-cased so that you could trigger it inside text boxes. Now this is done through the concept of "force keys" instead. If you add `<force>` at the beginning of a shortcut it will be available in text boxes as well. #194 Refactoring =========== - All modes are know implemented the same way. Normal mode used to be special-cased and all other modes were rather limited. - Commands and modes are now a lot more DRY. - defaults.coffee now takes care of command categorization and ordering. It is essentially the text version of the help dialog. Changing order and/or categories there automatically affects the help dialog (and the settings UI) as well. - The command matching algorithm is now much more simple and flexible. - Because the help dialog was moved into browser chrome, there is no longer any need to insert the style sheet as an `AGENT_SHEET`, which made it difficult to override it with user CSS, for example to change the font size or color of hint markers. #465 #424 #233 #220 Public API ========== Added a public API. This will be used by advanced users and by other extensions that wish to extend VimFx. It allows to: - Keep all VimFx configuration in a text file (instead of configuring it via VimFx’s GUI and storing it in Firefox’s prefs system). #245 - Add your own custom commands. #508 #490 #235 - Add site-specific options. - Disable specific keys on some sites. #255 - Do things when entering pages, such as automatically entering insert mode (this can be used instead of the "blacklist" feature) or hints mode. #408 - Set some advanced settings that cannot be set any other way. - Add new command categories. - Add new modes.

lydell · 2015-06-21T01:52:55Z

In the latest development version it is now possible to optionally configure VimFx via a config file.

No Firefox Sync support yet, though.

lydell · 2015-11-10T18:09:19Z

https://discourse.mozilla-community.org/t/how-to-sync-preferences-of-a-bootstrapped-extension-via-sync/3024/10?u=lydell:

The old Sync service was replaced with a new service that uses Firefox Accounts. I don't see any documentation around its sync feature, though.

Time won’t be spent on an obsolete feature. If anyone’s into this Firefox Accounts thing, feel free to open a new issue for it.

See #262, #245, #267, #625, #802, #713.

lydell · 2016-09-10T01:56:58Z

Import/export is now available in the development version, but no syncing.

lydell self-assigned this May 24, 2015

lydell added the enhancement label Jun 21, 2015

lydell changed the title ~~Export and import customized shortcuts~~ Export and import customized shortcuts (partially fixed in dev) Jun 21, 2015

lydell closed this as completed Nov 10, 2015

lydell mentioned this issue Nov 12, 2015

how to save prefs? does it work with sync? #267

Closed

lydell mentioned this issue Nov 24, 2015

export #625

Closed

lydell mentioned this issue Aug 27, 2016

Feature request: export/backup config settings #802

Closed

lydell added a commit that referenced this issue Sep 10, 2016

Add UI to export, import and reset all prefs

a72892b

See #262, #245, #267, #625, #802, #713.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Export and import customized shortcuts (partially fixed in dev) #245

Export and import customized shortcuts (partially fixed in dev) #245

zhuochun commented Jan 2, 2014

nogweii commented Jan 3, 2014

akhodakivskiy commented Jan 4, 2014

lydell commented Jan 4, 2014

akhodakivskiy commented Jan 4, 2014

noc7c9 commented Jan 17, 2014

lydell commented Jan 18, 2014

dvarrazzo commented Mar 19, 2014

bohrshaw commented Apr 14, 2014

lydell commented Apr 17, 2014

bohrshaw commented Apr 18, 2014

lydell commented Apr 22, 2014

lydell commented Apr 22, 2014

bashseb commented Jul 2, 2014

lydell commented Jul 2, 2014

lindhe commented May 23, 2015

lydell commented May 23, 2015

lydell commented May 24, 2015

akhodakivskiy commented May 24, 2015

lydell commented May 24, 2015

lydell commented Jun 21, 2015

lydell commented Nov 10, 2015

lydell commented Sep 10, 2016

Export and import customized shortcuts (partially fixed in dev) #245

Export and import customized shortcuts (partially fixed in dev) #245

Comments

zhuochun commented Jan 2, 2014

nogweii commented Jan 3, 2014

akhodakivskiy commented Jan 4, 2014

lydell commented Jan 4, 2014

akhodakivskiy commented Jan 4, 2014

noc7c9 commented Jan 17, 2014

lydell commented Jan 18, 2014

dvarrazzo commented Mar 19, 2014

bohrshaw commented Apr 14, 2014

lydell commented Apr 17, 2014

bohrshaw commented Apr 18, 2014

lydell commented Apr 22, 2014

lydell commented Apr 22, 2014

bashseb commented Jul 2, 2014

lydell commented Jul 2, 2014

lindhe commented May 23, 2015

lydell commented May 23, 2015

lydell commented May 24, 2015

akhodakivskiy commented May 24, 2015

lydell commented May 24, 2015

lydell commented Jun 21, 2015

lydell commented Nov 10, 2015

lydell commented Sep 10, 2016