This is an interesting request. Actually, exactly this situation was the original motivation for me to work on mei-friend (back then as plug-in package for the Atom editor): when adding a slur, you have to do this as well (select two different ids to add them at a different place in the editor).

Just to clarify your use case: You are talking about ids of elements that are not necessarily clickable/selectable in the notation pane?

One easier solution (referring to you second bullet in your solution list) could be to split the editor pane, using this CodeMirror5 functionality: https://codemirror.net/5/demo/buffers.html. This would help to keep two different locations in the editor in sight and copy/paste things easier around.

Or we could think about a mode where you click on different elements in the notation or in the editor pane and the ids of these elements are concatenated in the clipboard (or somewhere else) to later insertion.

Wow! Thanks for all your work on this tool.

Just to clarify your use case: You are talking about ids of elements that are not necessarily clickable/selectable in the notation pane?

Correct, in particular, editorial elements that wrap rendered notation elements such as <supplied>, <reg>, etc. and header elements like the children of <editorialDecl>.

One easier solution...could be to split the editor pane, using this CodeMirror5 functionality...

That's certainly a compelling idea. It would require migrating to CodeMirror 5, which is probably a good idea anyways, but would definitely be a nontrivial change.

...a mode where you click on different elements in the notation or in the editor pane...

That would address this specific issue, but my instinct is that having a smaller number of more general tools (like search and split panes) is better than a larger number of more specific tools.

Part of the reason I didn't suggest a specific solution for this request is that I personally am having trouble understanding what solution would be best for mei-friend's target users. I know what I would do in my code editor of choice (VSCode) and something more like the Atom plugin you mentioned: I'd write a slightly complicated regex to do a search, open the search results in a separate buffer, multi-cursor select all the IDs, then paste them into the header element having never scrolled away from it. But that approach only works because I'm using a powerful featureful editor that I'm spent years getting good at using, know regex, etc. etc. Part of the entire value prop of mei-friend is that it's accessible to less technical users, and I think those users need different approaches that meet them at their level of technical skill. It's definitely an interesting usability problem!

We are already using CodeMirror 5 (the new/current one is version 6), so implementing a split screen for the same encoding document should be straightforward. We just would have to think about the required UI elements.

The other point you raised, is a request that we got from some of the MEI community: have mei-friend as an extension for VSCode. We would have all the strong features that VSCode offers (code validation, editing, GitHub integration, etc.), and have the special ones that mei-friend adds (such as notation display, MIDI playback, annotation and markup highlighting, facsimile etc). However, this would require a substantial re-work of the entire codebase to modularize it in a way that part of the mei-friend code could go into the VSCode extension and the other is to have mei-friend as stand-alone app on the Web. If you have ideas how to design and achieve this, please tell us.

I'm not super well-versed with mei-friend's code, but frankly I'm skeptical about the idea that there's some core of mei-friend's functionality that could be generalized to produce a web UI and a VSCode extension. The platforms and UI needs are too different. I think it's possible that there might be some common libraries that could be extracted, but some of them probably already exist (e.g. verovio for notation rendering) so there's not much for mei-friend to do there. I suspect that a VSCode extension would be best attempted as a wholly new project.