noorts / toggler Goto Github PK

As requested by a review on the JetBrains marketplace.

The current approach of managing the dictionary within the small settings window is suboptimal. I would prefer the ability to edit a JSON file directly within Rider for a more efficient process.

Being able to edit the configuration in the IDE's editor would be great indeed (with all the editing features developers are used to).

I've looked into the feasibility of this before briefly and it seemed non trivial. It would be nice to either:

1. Completely replace the current limited configuration window, keeping only the buttons that are there right now and adding a "Configure in Editor" button. Clicking the button will open the toggles configuration file in the IDE's editor. Making changes and saving the file will apply the changes.
   • There would have to be some kind of validation to make sure the toggles are unique, and to make sure the file contains an array and string only subset of JSON. It might be possible to use this plugin's already existing validation logic.
   • Note: This approach is similar to the one taken by HiDeoo's Toggler extension for VSCode.
2. Bring the editor capabilities into the current configuration window.

I personally prefer approach 1.

Note that I'd like to make sure that Toggler users do not lose their current toggles when they update to a new version that includes this functionality.

On a line indented by tabs (I tried size 2 and 4), if I don't select a word and I merely put the cursor on a word, the word searched is wrong and there's no match.

As requested by a review on the JetBrains marketplace.

It would be beneficial to include shortcuts for shuffling items up and down. When dealing with numerous suggestions, navigating through them becomes more convenient by moving both upward and downward.

This could be implemented as a simple reverse toggle action.

The current shortcut for the toggle action is Ctrl/Cmd+Shift+X. Using an additional modifier (e.g., Alt/Opt) for the reverse action might make it cumbersome to activate. However, I'll likely go with that for now anyway (so it will be Ctrl/Cmd+Shift+Alt/Opt+X). Better keybind suggestions (which do not conflict with the default IDE's keybinds) are very much welcome!

Not working in latest version ((( Idea 2022.3 Beta (Ultimate Edition)

Hi there, I have a strange one.
Clicking on a part of a togglable word is usually enough to trigger a partial match. However, this does not work on my java files. It does work on scratch file with exactly the same data. What's even stranger, it works when selecting the exact part that I want to toggle.

I can reproduce on at least 3 of our repos (Those use Maven, Spring web, Lombok, and mapstruct).
I run IntelliJ Idea 2021.2, with the following extensions:

Also, I absolutely love this extension. Thank you.

• Improve conciseness
• Add example to highlight Toggler's workings
• Link to the Toggler project board in the roadmap section
• Add contributing section
• Add default toggles to description
• Improve configuration section with code

Introduction

The plugin in its current form using the default toggles is already fast enough not to cause noticable lag. There are however parts of Toggler's implementation that can be optimised. This issue has been set up to investigate potential performance improvements.

Toggles structure

The structure used to store the toggles is a List<List<String>> (thus O(n) in terms of space complexity). Utilities have been written to parse and stringify this toggles structure into JSON. The JSON representation maps onto this structure quite well (as can be seen from the default toggles).

We should be aware that the toggles structure persists the users their personal configs. Thus changing this might be risky as users could lose their personal configs if an update changes this structure.

Current steps

The business logic found in ToggleAction.java uses the following steps to perform a toggle for each caret separately.

1. The caret temporarily expands its selection until boundary characters are found on both sides. E.g. const s|etName = 0 (with the | indicating the caret and selection) would turn into const |setName| = 0.
2. A regex pattern (that contains all the individual toggles) is built when the action is triggered allowing all carets to use the pattern to detect whether and how many toggle matches were found inside of the expanded caret selection. E.g. const |setName| = 0 would return one match if partial matching is enabled, namely set.
3. The location inside of the document where this match is found is returned to be used for replacement further down the line. E.g. this location could indicate that the match is located on line 3, from character 7 until 10.
4. The match is then used to find the next toggle. In the current implementation this means that we loop through the toggles structure until we find our match e.g.set. We then return the next word in the structure (wrapping around if the match is the last in the sublist). Finding the match its replacement using this implementation is thus an O(n) operation.
5. An API call is made to replace the match with the replacement found.
6. The caret selection (which was expanded in step 1) is restored to its original state.

Potential Improvements

The following is a list of potential improvements that can be made.

• Extract the regex pattern to the configuration logic
  • Step 2. This would make sure its only set up once and not every time the toggle action is triggered. We'd have to rebuilt the pattern upon the initialisation of the plugin and upon modification of the toggles configuration through the configuration menu.
• Replace the find next toggle O(n) logic with a hashmap implementation
  • Step 4. This would improve the time complexity from O(n) to O(1). What's still left is to figure out how to store the hashmap in relation to the current toggles structure discussed above. See the following two approaches:
    • Replacing the original toggles structure might cause breaking changes, which means users might have to migrate their configs. We might be able to write some custom code for that, but this is best avoided. This approach also means that other parts of the application will have to be updated, such as the JsonParser.
    • Having the hashmap be derived from the toggles structure will mean that changing the toggles structure will have to trigger the hashmap to also be rebuilt. The hashmap in this approach would also take up additional memory.

Hello, thanks for this plugin so far, I just wanted to share a small feature request with you:

Sometimes I am working with symbols such as add_class or addClass. It would be nice to be able to change it to remove_class or removeClass with your plugin. Sure I could add the whole word to the list in my settings, but often enough it is not just this exact combination of these two words.

Would it be possible to add the functionality to toggle parts of strings as well? Maybe only allow it if there is a underscore or a case-change present, or allow it in general for all partial matches (addclass would match too).

I'd love to here your opinion on this!

Introduction

To be able to test functionality which can't be tested through direct integration tests, we'll have to set up UI tests.

• The intellij-ui-test-robot can be used for this purpose.
• Examples
  • An example plugin using the robot can be found in the same repo.
  • The intellij-common-ui-test-library also serves an an example.

Approach

Test setup

• Set up
  • build.gradle.kts to support the robot
  • A simple UI test to verify that it works

CI/CD

We should also integrate the UI tests into the GitHub workflow.

• Add UI tests job. See the example.
• Set up separate "Tests" (the current integration ones), "UI Tests" and "Verify IDE compatibility" jobs in the test.yml to run the jobs in parallel.

Test cases

We should add tests to verify the following scenarios.

• Basic toggle action test
• Verify whether notification shows up
  • on toggle action in empty file
  • on toggle action with no match
• Configuration menu
  • Verify impact of config adjustment on subsequent toggle
  • Verify disabling of partial matching and subsequent toggle
  • (Opt) Verify Import, Export and Reset to Default functionality
  • (Opt) Verify config validation (disallow duplicate toggles, etc.)

Allow adding toggles to the configuration which are only enabled for files in certain languages.

The following is an example configuration just to get the point across. Of course with an optimal and valid JSON structure (which is backwards compatible with the current structure).

{
    "default": [
        ["byte", "short", "int", "long", "float", "double"],
        ["String", "Character"],
    ],
    "java": [
        ["public", "private", "protected"],
        ["class", "interface"],
        ["extends", "implements"],
        ["import", "export"],
    ],
    "js, jsx, ts, tsx": [
        ["const", "let", "var"],
    ]
}

See the shifter plugin for inspiration.

Hi,

I'm using the latest version of Android Studio with Kotlin. The plugin works, but can't configure settings of it because Settings/Preferences -> Tools -> Toggler doesn't exist.

I hope you can solve this.

Expand the tests to cover the plugin's main features.

Simple integration tests

• Verify multiple cursors
  • On separate words
  • On the same word
• Verify partial matching
  • Subword
  • Selection
• Verify toggle wrapping
• Verify simple case transfer