Some thoughts:

1. it seems like this will only work on macOS. Is this issue affecting Windows and Linux users also?
2. From reading the issue, it sounds like the reason we have duplicate entries is because JetBrains toolbox generates one small executable that points to the actual install. Should we not then be skipping the small executable during detection? Or would there be cases when that would lead to zero IntelliJ's being detected?
3. Does this also affect Android Studio?

1. Yes, it works on macOS but won't affect Windows and Linux because it isolates in a IntelliJValidatorOnMac class specifically for macOS only. There are separate implementations for Window and Linux.
2. Yes, when I was working on the issue, I found that the validator is first looking for all possible candidate path that contains Intellij IDE, then extract and validate information from plist file. Not sure about the zero Intellij scenario, I will try to verify it.
3. Android Studio is in another plugin validator so no affect on it.

To answer 2. if there is no validator then it won't show anything form doctor.

Is it possible that a user's machine can have two installs with the same title (same version) that are both valid? Even if it's not possible now, it could be in the future.

Why not filter using install path instead?

Hi! I was trying to find another time to open another issue for what I will mention because it turns out like a rabbit hole and more issues from this. But let me try to answer your concern first:

• why not filter using the install path instead: It creates another constraint to the install path since the JetBrains Toolbox supports changing the install path. For example, if we update the location to store the installed app and it contains a keyword that we want to filter, we might remove it accidentally.
• If there are multiple installs with the same title(either IntelliJ IDEA Ultimate Edition or IntelliJ IDEA Community Edition) with the same install path and version: I would say it's a good scenario to remove it because they all provide the same information for doctor. But it needs extra care to handle possible multi-version and so on.

I see this validator in another way. It's a validator to find all correct content and reduce it based on the version, install path and plugin path. Ideally, if we can parse the right install path from the shortcut app and update it, we can expect the same result from path-based and spotlight searches. It opens up the possibility of detecting multiple app versions and its plugins version.

However, I further dug into this issue and discovered that we need to update the logic to find the correct install and plugin paths. The plugin path is also not working, and the issue I would like to open is related to this one.

The result from the path search(toolbox) can get the correct plugin version, but the spotlight one is not. It's because of the L510 on intellij_validator. The shortcut app contains the JetBrainsToolboxApp key, and the value is the actual location of the app, the same as the spotlight search. It can form a correct path to the plugin's path.

However, the result from the spotlight search depends on the keyword in the plist, and that keyword doesn't exist in the shortcut app. It helps to differentiate the result from path-based and spotlight searches. But the logic to find the correct plugin path when JetBrainsToolboxApp doesn't exist in the plist is outdated, resulting in an incorrect plugin path.

To sum up:
We might want to improve the following things:

• Install and plugin path handling
• Reduce the result based on the candidate validator's title and version or other information before returning the list

The issue is growing too much compared to the original possible solution, so I would like to work on those things separately to keep the changes minimal.

It might be too long to read, and I would like your input @andrewkolos to continue the issue 😃

Thanks for the write-up! I wouldn't be surprised that the logic around plugins doesn't work properly. I've worked on the AndroidStudioValidator recently, and I am pretty sure that class has similar issues with detecting the Dart and Flutter plugins. I agree that this is a separate issue, so please feel free to file that with the tool label.

Moving back to this issue/PR, I realize I was misremembering the issue that this is trying to fix. Indeed, we can't use the install path to filter here. In that case, should we go back to using the plist file or looking for Jetbrains Toolbox in the installation path? I think filtering on the title works, but the result could change based on the order in which we detect installations of IntelliJ.