@vlasovskikh Thanks for your work on #105. Here's another try at an extension for providing motion-based comment actions, based off the latest master. This PR will initially serve as more discussion, however, as trying to use the <Plug> support is causing some issues that I haven't had time to fully investigate. Basically, the PR mostly works as-is, but without <Plug> maps. When I uncomment the <Plug> maps, it seems to want an extra operator before performing the action.

More concretely, when using the <Plug> map indirection:

• gcc works as expected, but it seems to also add an extra c as input, such that then hitting j will delete the current and next lines and enter insert mode)
• gcl to do a block comment around one letter will appear to only accept the l to move the cursor. A subsequent l will do the comment (but of course at this point it will be one character to the right of the one you actually wanted to comment). In fact, at this point you can enter any motion and it'll "work."
• gcip will enter insert mode and paste g@p

When directly mapping the keys to the extension handlers:

• The gc + motion in normal word works as expected
• gc in visual mode doesn't seem to do anything
• gcc behaves the same as when using <Plug>

The tests, however, all pass. These were observed by using the runIdea gradle command from within IntelliJ. The vim-surround support seems to work just fine, though, so it could be some problem in my code rather than the extension framework....

Wanted to get this up so we can start looking into the causes of these behaviors, since they'll probably need to be addressed before other extensions can be developed.

I've added the following:

1. An extension point IdeaVIM.vimExtension. for registering IdeaVim extensions. See plugin.xml and VimSurroundExtension as an example. You have to add a <vimExtension/> tag into plugin.xml and inherit from VimExtension in order to get your plugin registered and get the set <plguin-name> option working.
2. The VimExtensionFacade contains the parts of the API for extension authors that is similar to Vim.
3. Extension actions are registered via putExtensionHandlerMapping() similar to :map ... :call <your-extension-handler> in Vim.
4. If your extension handler requires an argument, use operatorfunc (available as setOperatorFunction()) and g@ as in Vim.
5. getchar() is implemented as a modal dialog that looks like Vim input line at the bottom of the editor, see getKeyStroke()
   • I'll add a unit-testable version of the modal dialog-based implementation

Next steps:

1. Add vim-surround commands with unit tests
2. Extend VimExtensionFacade according to the needs of the vim-surround port

This is an initial stab at defining semantics for replicating vim plugin behavior within IdeaVim, with some preliminary support for tpope's excellent vim-surround plugin.

I'm not sure if there's a more idiomatic way of doing stuff like this, but since I didn't hear back on my request for guidance I just went ahead and made something up.

I created a Plugin interface which contains a Registrar in which plugins register. Each plugin has an "option name" which is used to enable the plugin using the vim options syntax, eg:

  set surround

Plugins can be activated at runtime using this syntax, but I wasn't sure how to go about disabling them (I think we'd need a hook to register and de-register actions, or perhaps make a subclass of VimCommandAction that won't be automatically registered at init). I'm not sure that's a huge concern, though, as generally you set up your plugins once in your vimrc and just go.

Since plugin bindings are optional and are enabled after init via .ideavimrc, I slightly refactored ParentNode to be able to correctly handle adding new BranchNode onto a BranchNode that already has an ArgumentNode. This way, plugins can override built-in bindings as expected, as well as expand on them.

The included vim-surround port supports most of the core surroundings, but currently leaves xml/html tag support to future work, as well as (I'm sure) a few more obscure features that I wasn't aware of, but I wanted to get this PR up and get some feedback on the approach before I try to figure that one out.

Since the ys and cs motions take more than just a motion, I mimicked vim-surround's implementation and added a getChar() command to KeyHandler. While necessarily asynchronous, taking a callback, this does block other vim input processing, as expected. If there's a better way to deal with this sort of thing I'd love to hear it, but this seemed like it would prove helpful in porting other vim plugins in the future.

UPDATE: Repeat support via . for cs and ys is achieved by subclassing Argument and storing our extra arguments in it (ie, the SurroundPair object). I think this is the simplest way to support the more complex surrounds, such as that achieved by ysiwtdiv> to surround the inner word with <div></div> tags (which is not yet implemented, but I'm thinking ahead for when we figure that out).

This is my attempt to fix VIM-987.

The IDE itself does something slightly different at the moment (see here) while JComponent#processKeyBindings(KeyEvent, boolean) falls back on the "normal" key code when it finds no matching binding (I'd like to link the source here, but it seems to be only available as scrs.zip).

Because I don't know if I break something else with this change and I want to see if I get a response on IDEA-197762, I prefaced this with WIP. I the meantime I am testing this change on my system.

Any feedback would be appreciated.

no tests performed..!

Example usage:

• :nnoremap gi :action GotoImplementation<CR>
• :nnoremap gu :action FindUsages<CR>
• :nnoremap gcw :action RenameElement<CR>

Action overview: https://github.com/JetBrains/intellij-community/blob/6c6cb47c5a41025549157d64643a98a89481260d/platform/platform-resources-en/src/messages/ActionsBundle.properties

Hello team! Thank you for the amazing work on IdeaVim.

Indentation based text objects are something I've been missing quite a bit in IdeaVim and, learning that that extension is not already available, I made an implementation of this idea.

Original Vim extension of this idea: https://github.com/michaeljsmith/vim-indent-object.

I'm very new to IdeaVim's code base and I did just enough to get this feature working (since I needed it). In that context, majority of the code is copy-paste from the textobj-entire plugin. If there's anything you'd like to be changed to make it ready for merging, please let me know.

Also, I'm trying to add a test class to test this plugin, but the test fails for some weird reason I'm not able to comprehend yet. I could use some help there (if you guys are okay to merge this in now and do the test separately, I'm fine with that as well). This is probably due to my lack of knowledge in Kotlin though.

Again, thank you very much for your work and your time. I hope this extension will be available as part of IdeaVim in the future.

Experimenting with a simple ":command" interface. Allows mapping intellij custom actions to shorter commands as desired. For example ":command shell action openTerminal" to open shell instead of requiring a custom action in java code.

No unit test (as of yet). Would appreciate initial comments.

Using a non-existent key stroke is great, but ambiguous plug mappings aren't supported out of the box. Imagine you have two mappings, both of which take a motion:

More MoreMagic

You've mapped gmm to More and gmc to MoreMagic.

When you type gmc, the recursive mapping is available, and the else if (mappingInfo != null) branch can feed the mapped keys back into the system. Because these are fed as recursive, when the keys come back through, they can get the mapping to MoreMagic (which is no longer a prefix) and execute.

For gmm, when it feeds the keys for More, it is still a prefix; when a motion is inputted, it is no longer a prefix, and so it would hit the else block, feeding the keys WITHOUT recursion. So, we have to catch the case where we're no longer a prefix, but can find a mapping within the input. This seems to work pretty well, but causes "recursive records found" warnings in the console, and complaints about local history being broken. I'm not entirely sure whether this is just an idiosyncrasy of the unit test environment, or whether this would cause significant problems in the live environment. I'm hoping you have more experience here about whether that warning can be ignored, and am open to suggestions otherwise.

Also included is some prep work for -based repeat handling. Extra input sequences past the mapping are stored in a PlugInputModel which is read from in preference to the ModalInputDialog.

Pull request to add a nice feature that I was missing on IdeaVim: relative line numbers.

By setting the relativenumber option, the editor shows the line numbers relative to the caret position, allowing users to quickly jump a few lines up or down to change some text or maybe yank it.

With this feature you can just go 4j to go 4 lines down or 3k to go 3 lines up at a glance :)

This pull request solves VIM-664. If ideavimrc file exist in XDG config directory use it instead the one in home dir. Works according to XDG spec, that is it uses directory specified in XDG_CONFIG_HOME environment variable if set and ~/.config otherwise. Any feedback appreciated.

Bear with me as this is the first thing I've ever done with Intellij-IDEA plugin development.

I tested this and I believe I fixed the problem. The cause of the problem was that the code was checking if the mark was in a different file but if it was, it was using the editor of the current file to go to the line of the mark. I changed the code so that it opens the file of the mark first, then jumps to its line number.

I need a VirtualFile so that I can get the Editor to open. The Mark stores the path of the file it's in, but the path is not enough information to get a VirtualFile. I also need the "protocol" of the file. So, I had to change the structure of the Mark and add a "protocol" field to it.

I had to update the save/load logic to use this new field, too. This way, when you restart Intellij-IDEA, the marks can still be used. For old marks, I defaulted the "protocol" to the value of "file".

One thing I couldn't figure out how to do is add a test case to check that this is working correctly. This is not due to a lack of effort. In fact, I tried to write the test case first. But I have been unable to find any examples anywhere of testing multiple Editors, and that's what's involved to fix this issue. Because of this, this issue may be best used as a reference to fix the problem instead of worthy of being used in production. Either way, I'd love to know how to write such a test.

Rider supports a few other file types that are flavors of HTML/XML:

• Asp: templating language for .NET web apps, Razor's predecessor
• UXML: XML files for Unity game development
• Xaml: XML files for .NET Core UI development

I should have included these in https://github.com/JetBrains/ideavim/pull/579, but I'm not a C# guy so they're new to me. 🙂

Bumps org.eclipse.jgit from 6.1.0.202203080745-r to 6.4.0.202211300538-r.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps junit-jupiter-api from 5.8.1 to 5.9.1.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps github-api from 1.305 to 1.313.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Fixes multiple cursors with vim-surround commands cs, ds, S (but not ys).

https://user-images.githubusercontent.com/3685160/174427769-e523bc89-0040-46f1-98d3-ae8f628df4a5.mp4

I don't know if this is a good solution and there likely edge cases that break it, but I use multiple cursors every day and having at least some solution that makes vim-surround work in most cases is better than having it not work at all.

Unfortunately I have not figured out how to make ys work (I didn't even know that particular command existed until I looked at the source).

If you know of a better overall solution and/or a way to make ys work too, I'd be happy to improve this.

I also haven't added unit tests yet. I'm opening it as a draft for discussion, if / once you are happy with the implementation I will write some tests before it's merged in.