haberdashpi / vscode-modal-keys Goto Github PK

I have a fresh install of VSCODE (1.66.2) and ModalKeys. I imported the VIM preset to try it, and I immediately encountered an issue. I cannot go back to normal mode using the escape key when I enter visual mode, pressing "v" again works however. Also, since the search function behaves in selection mode, pressing N or n after entering a search query will select the area between the occurrence of the query and the point where the query was made. This behavior cannot also be canceled using the escape key.

I tried ModalEdit and both issues are fine on it

FIX: see final comment by @haberdashPI for a fix. Remaining task is to improve the documentation.

I wish to define key [space bar] in normal mode :
1. if current char is space (' ') : delete right spaces (until any other char)
2. else : insert a space char (just like type keys [i], [space], [escape])

I can't figure out 2. by below :

    "normal:: ": {
        if: "__char == ' ' ",
        then: ["cursorWordStartRightSelect", "deleteLeft", "modalkeys.enterNormal"],
        // else: [
        //      {
        //         "modalkeys.typeKeys": {"keys": "i "},
        //      },
        //     "modalkeys.enterNormal"
        // ]
    },

any solution ? thanks~

for the store

After this is resolved, bump the version and publish the updates from #60

right now it actually edits the document

I think this is something about when normalMode resets the selection. Probably an issue with async behavior in vscode commands.

Sorry if I've just missed this, but I don't see anything in the docs about how to map keys that aren't printable. Specifically, I'd like to map <backspace> in normal mode. In addition, it might be nice to map keys with modifiers, eg <ctrl-a>

Some of the commands/vars are outdated (e.g. __selecting doesn't exist).

Hi there, do you have any plans to publish to the vsc marketplace or is this more of a private project?

Currently the count is ignored when applying an operator in vim preset

I think this is because __count doesn't pass through typeKeys: conclusion, yes, this is right, and it isn't trivial to fix because there's the interposing v command. Would need some way to take specify which command takes the count. Easier to change how vim.js presets works. typeKeys just isn't very good (it's a "vim"-ish way to solve the problem). Should use the javascript power that the extension allows for.

Type: Bug

Maybe I'm doing something wrong, but it seems that the modalkeys.startInNormalMode setting doesn't do anything for me. The editor still starts in normal mode even when it is set to false

Fwiw I also tried the setting "modalkeys.startMode": "insert", introduced in #60, to no avail

Extension version: 0.10.4
VS Code version: Code 1.71.0 (784b0177c56c607789f9638da7b6bf3230d47a8c, 2022-09-01T07:25:38.437Z)
OS version: Darwin x64 21.5.0
Modes:
Sandboxed: No

vsliv368:30146709
vsreu685:30147344
python383:30185418
vspor879:30202332
vspor708:30202333
vspor363:30204092
vslsvsres303:30308271
pythonvspyl392:30443607
vserr242:30382549
pythontb:30283811
vsjup518:30340749
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
vscorecescf:30445987
pythondataviewer:30285071
vscod805:30301674
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
cmake_vspar411:30557514
vsaa593:30376534
pythonvs932:30410667
cppdebug:30492333
vscaac:30438847
pylanb8912:30545647
vsclangdf:30486550
c4g48928:30535728
hb751961:30553087
dsvsc012cf:30540253
azure-dev_surveyone:30548225
i497e931:30553904

VSCodeVim is far faster in this case; what's going on here?

We could troubleshoot by throttling a SSH host.

• Consider closing #47
• doc update slows things down?
• too many round trips?

• Get search registers working
• Fix bug where search backwards shows the wrong highlight range

in ModalEdit, below define can press "ah" to goto start of line, can press "al" to goto end of line,
when press "a" (not yet press h or l), it can show "[h,l]LineBgn, LineEnd" in status bar for tip,
how can I do such custom tip in ModalKeys ?

        "a": {
            "help": "[h,l]LineBgn, LineEnd",   //<-----------
            "h": {
                "command": "cursorMove",
                "args": "{ to: 'wrappedLineFirstNonWhitespaceCharacter', select: __selecting }"
            },
            "l": {
                "command": "cursorMove",
                "args": "{ to: 'wrappedLineEnd', select: __selecting }"
            },
        },

thanks~~

When now that we support show captured keys, search repeats the text (because there was already a separate status bar for show search text

This would be pretty easy to do using a scientific color map, and make the extension more accessable. The number of viable shades would be a little less: we'd need to cycle through colors.

It's time to take this prototype, consolidate the lessons learned and build something more stable and reliable.

Objectives

The new design should:

1. Use a key-binding import strategy (similar to before): a succinct script that describes everything about the keybindings the user wants to add, allowing for easy documentation

2. Not override type command (unlike before): instead the keybindings script from above generates some text the user can copy paste to their keyboard settings (which can be opened for the user, and a message can pop up to explain what to do). Should be informed by the design of https://github.com/71/dance.

   • For multi-key bindings, these can add to some queue internal to the extension, and each key would be a single command. In this way the state of multi-key bindings can be managed by the extension and we can show the proper state in the keyboard help.
   • This allows all of the commands to be accessible from the command palette

3. Implement tests: like dance, we can test each command to verify that things work as expected.

4. Have a command that passes through and records commands. This makes any existing command work with the logic in this extension so, e.g. an edit operations can be recorded, even if the keybinding doesn't change.

   • There should be some easy way to copy-paste the contents of e.g. default keybindings, add the passthrough wrapper, and then paste the revised contents into the keyboard settings. This will allow more commands to work with the macro recording.

5. Be easy to read and maintain. Ideally this is a project that others can contribute to with ease. Right now it's got some rough edges, even if the documentation is relatively thorough thanks to it's original creator.

An open question I have is whether I need to recreate all the functionality that dance has or just create what would be a complimentary extension that fills in the gaps that I want to fill. I'm leaning towards building my own because there are some aspects of the design of the code there that I think are hard to follow to a new reader, and my hope is that in making a fresh write I can build something that is easier to make sense of (but strongly influenced by that design).

Note that, even if I do build my own, it would be wise to not try and re-invent the wheel when it comes creating a test suite, since there seems to be a lot of work put into that for dance.

Right now, key commands can contain arbitrary javascript using eval, which is slow / dangerous.

Possible alternatives:

• https://silentmatt.com/javascript-expression-evaluator
• https://ericsmekens.github.io/jsep/
• https://github.com/TomFrost/Jexl

This will require finalizing vscode-seleciton-utilities first

Need this to make vim presets more fully features

There's some issue where non-normal modes use normal mode in macro replay.

use the events for document changes (but how to disentangle with normal-mode effects)

Allowing for self-documenting key maps

The keymap format would be improved by

• making it even more uniform
• keeping the keymap somewhere other than settings (since it is not really a format to directly edit anymore

Whatever we do needs to support the old format as well.

If a command takes a long time to run you can get errors about a two concatenated key sequences not being a command. This is because the queue of keys pressed is not cleared until a command is complete. Should be possible to clear this queue sooner I think.

The action is delete the built docs for some reason

(sorry, this is my misunderstand)

Conclusion: this is too radical a change to implement in the old repo. The plan will be to implement this as a new extension, and convert the current extension to a "maintenance mode", and direct users to this new extension.

• File Ingest
  • initial file insertion
  • file validation
  • unit tests
  • comments / organization
• modalkeys.setMode
  • state
  • UX
  • UX tests
• modalkeys.do
  • execution
  • flag handling
  • computeArg handling
  • unit tests
• modalkeys.prefix
  • state
  • UX
  • UX tests
• modalkeys.repeat
  • recording
  • repeat action
  • repeat last action selection
  • UX tests
• modalkeys.updateCount
  • state
  • UX
  • UX tests

Right now these are implicit and do not say when a string will be evaluated as JavaScript

I hope to implement Helix's selecting style:

• When you press 'w' you select till a word end; when you press 'w' again, you will cancel the current selection and select the next word.
• When you press 'v' and enter visual mode, you will select multiple words as you press 'w's.

This seems not possible in modal-keys, since any selection would enter visual mode. Is it possible to only enter visual mode explicitly?

Thanks!

Env
macOS 10.14.6
vsc 1.56.2
ModalKeys "2.1"

Observation
I'm unable to import the vim.js preset after installing ModalKeys from a vsix file.
The log states

Validating keybindings in 'settings.json'...
ERROR: Missing valid normal mode keybindings. Keybindings not updated.
Validation completed successfully.

Steps to reproduce
Install ModalKeys, have no settings for modalkeys configured in your settings.json, try to import vim.js

How to reproduce the error:

1. Create a directory with name, temp1
2. Invoke ModalKeys: Import Preset binding and select temp1 as the folder
3. Rename temp1 to temp2
4. Invoke ModalKeys: Import Preset binding again and see the error.

• implement the documentation feature of the bindings format #38
• create a panel view container and view to display keybinding help
  • display keyboard
  • display command on the keyboard
  • display commands when webview first initializes
  • double check that even when output error doesn't overwrite, webview initializes properly
  • fix undefined doc pieces
  • clear keymap view if no doc exists for new keymap
  • handle non-normal keymodes
  • make sure more keys in doc sequences are cleared (e.g. labels for base normal mode show up if there's nothing overwriting them)
  • clear commands when in capture mode
  • label numbers
  • color code by command type
  • fix bug with different modes
  • fix bug with return
  • define command to reveal keymap
  • keep focus on editor when opening keymap
  • add a legend for the color code
    • add a new property for keybinding files (and settings) that describes each 'kind'
    • add a section to the detail hover that displays this information
  • add hovers with the detailed info
• fix bug in doc display following count
• populate vim help
• reference keymap in error messages (when there's a missing keybinding)
• create a welcome page intro to the helpmaps
• debug missing 'j and 'k bindings
• import and document my bindings
• update vim's bindings (from preferences)
• populate my bindings' help
• update documentation
• update README

Note: I reinstalled the plugin and couldn't reproduce the issue. ModalKeys is working as expected.

Keeping this issue, incase some other user encounters it.

When I press Ctrl+c to copy a text from Insert mode, it enters the Normal mode, I expected it to remain in Insert mode.
When I press Ctrl+c from Normal mode, and then press i to trigger modalkeys.enterInsert, it doesn't go into Insert mode, and I have to press a to enter Insert mode. My keybinding file only has one command i.e modalkeys.enterInsert

Steps to reproduce Insert to Normal mode on ctrl+c:

1. Keybinding file:

module.exports = {
    "keybindings": {
        "i": "modalkeys.enterInsert"  
    },
}

2. Enter Insert Mode, screenshot below:
   

3. Select a text and hit Ctrl+c, it goes to combination of Insert and Normal. (I am confused why there are two modes in status bar.)
   In this mode keys like w do not get entered into editor i.e we are not in Insert Mode
   

Steps to reproduce breakage of modalkeys.enterInsert

1. From Normal mode, select a text and hit Ctrl+c.
2. type i to get into Insert Mode. It goes to combination of (Insert, Normal)
   
3. Insert mode doesn't work as expected.

This scenario cannot be reproduced using Ctrl+a or Ctrl+v
To workaround this behavior, I setup my AHK to send Ctrl+Insert when hit with Ctrl+c

The code has gotten crufty and overly stateful. Once all the main features I want are added I need to do a round of code cleanup.

The search command does not get properly recorded.

Right now there are things that are special about visual mode and normal mode: these should eventually be refactored out into generic hooks that can be run for any mode, with sensible defaults.

Follow the guide here to enable both web and still support the file stuff we want when in VSCode proper.

Todo:

• Figure out how to handle importing/exporting bindings from vscode.dev
• Either resolve #47 or wait for microsoft/vscode#138413 to move from Insiders to Release

Treat master as stable, and PRs as development. Keep PR docs in a separate folder of the gh-pages branch.

It's the log for ModalEdit right now.

This will allow both macros and repeat commands to use insert mode modifications.

Use the events for document changes (but how to disentangle with normal-mode effects)

I really like the concept of vscode-modal-keys, maybe if we have build-in kakoune and helix keymaps, that will be very nice.

https://docs.helix-editor.com/keymap.html

https://github.com/mawww/kakoune#3-basic-interaction

It's a cleaner, and simpler setup than webpack, so long as it actually works.

The first version will simply record the command history and allow it to be replayed (ignoring record and replay events during replay to avoid infinite loops). Should also display an indicator in the status bar when a macro is being recorded.

• If there is no keymap, any keys you type should pop a dialog letting you know about this
• Regardless, if a binding doesn't exist the error message should direct you to defining a binding
• Make it easy to create a copy of a preset file
• The vim keybindings should be more comprehensive and well tested (dog-food it!)
• Handle missing extensions in a keymap more gracefully

It seems that variables are only interpolated at the top level of an argument dict. For example, the following doesn't work as expected:

module.exports = {
  keybindings: {
    d: {
      "modalkeys.captureChar": {
        acceptAfter: 1,
        executeAfter: {
          "cursorless.command": {
            version: 2,
            action: {
              name: "setSelection",
              args: [],
            },
            targets: [
              {
                type: "decoratedSymbol",
                symbolColor: "default",
                character: "__captured",
              },
            ],
            usePrePhraseSnapshot: false,
          },
        },
      },
    },
  },
};

I was expecting it to interpolate the "__captured" that is nested several levels deep.

If this is not something you'd like to support, do you know of an easy workaround that doesn't involve me creating an extension just to expose a command to wrap the command?

Cool extension btw!