Can't propagate highlight selections to multiple files.

[bedge]

Often one wants to see where a set of variables are used, and this may span multiple files.
If one highlights these in one file, they are not also highlighted in other open files where they occur.

While, true, one can also select and highlight the same strings in the other files, this is time consuming, and they also default to different colors. This detracts from the usefulness of the plugin.

The vim https://vim.fandom.com/wiki/Highlight_multiple_words plugin works this way and is super-useful. I still resort to using vim just for this feature, as there is nothing equivalent any of the jetbrains tools.

Even if automatically highlighting in every file is not possible, it would be useful to be able to save the highlight selections from one file and load in another.
eg:
Save the list of highlighted words and their current colors, and load in other files to get matching highlights.

[huoguangjin]

I see.

The Vim plugin you mentioned is based on text matching for highlighting, while MultiHighlight is based on syntax tree element (PSI).

Initially, MultiHighlight only highlight identifiers in a single editor, and later added the feature of synchronizing highlights in different editors of the same file. MultiHighlight does not highlight one same identifier in different editors corresponding to different files. This has the advantage of searching within only one file, which makes searching faster.

[huoguangjin]

If MultiHighlight supports cross-file highlighting, there are several issues to consider:

• Currently, MultiHighlight only records the search results (text ranges) when highlighting identifiers, without recording the original PSI elements.
  Cross-file highlighting requires recording the original PSI elements, which can be volatile and may become invalid due to code changes.
  For example, the "Find Usages" feature in IDE, it starts a timer to check if the searched PSI is still valid and updates the usage list in real-time.

• If MultiHighlight records all original PSI elements corresponding to every highlight, there are two ways for highlighting: searching within the current file or globally searching for all usages.
  Searching within the current file means that all opened editors need to be searched when each time highlighting is performed, and the recorded PSI elements also need to be searched again whenever a new editor is opened.
  Searching for all usages globally can be slow, especially in cases where the identifiers have a large number of references.

All of the above points will bring certain performance costs.

[bedge]

This has the advantage of searching within only one file, which makes searching faster.

I don't doubt that. It would be a performance hit, however, it would help with multi-file comprehension to see places that the same label is present.
In code with a lot of global context, eg: bash, as well as OO, where objects with common methods are accessible from multiple files, it's super helpful to be able to see all uses of obj.function-X() in all open windows.
This works well with the Intellij multi-file search. What would be fantastic is to integrate with the IntelliJ search as well. Even better would be to retain the colorization for some number of recently searched items.

[bedge]

Another thought on this - The syntax tree vs plaint text match explains why there are cases where this plugin doesn't highlight all instances of a string.
Is it feasible is to use this plugin source as a basis for a new variant that is a text matcher?
Granted, it's a different product that fills a different need but I think there's a need for both.