Fix peeked editor closing without reopening with new contents when triggered again at the same position in the same file

[lokesh-tr]

While expanding nested macros, the peeked window is supposed to appear at the same position as the previous one. The "editor.action.peekLocations" command causes the previous peeked editor to close without reopening with the new contents if invoked at the same position in the same file.

This fixes the issue by having a workaround in which we open a dummy peeked editor so that the previous peeked editor is closed, followed by opening the actual peeked editor so that, we have the peeked editor to always display at the same position in the same file while expanding a macro.

This issue is not macro expansion specific and exists in general.

Semantic Functionality and nested macro expansions PR in sourcekit-lsp where the issue was faced initially: swiftlang/sourcekit-lsp#1634 + (#1017 or swiftlang/sourcekit-lsp#1636)

---

Expansion of Swift Macros in Visual Studio Code - Google Summer Of Code 2024
@lokesh-tr @ahoppen @adam-fowler

[plemarquand]

Nice fix! I only have a few comments about internal structure and documentation.

[ahoppen]

Did you see the dummy peek window briefly flicker up or does it produce any scrolling to to the top of the file if position 1:1 is currently not in the viewport?

Also, I guess there is still a theoretical issue if you have a macro at 1:1 in the original source file and then invoke a nested expansion from there but I’d say it’s sufficiently unlikely that we don’t need to care about it because the source file probably needs to import the macro first and usually people write their import statements at the start of the file, which means that the macro can’t be at 1:1.

[lokesh-tr]

@ahoppen I don't see that flicker up since its fast, it doesn't scroll but jumps to 1:1 and then comes back to the macro expansion. People will notice something happened before the macro expansion is shown, but they won't notice what exactly happened since its fast.

And, good catch with the issue on 1:1, I am aware of it and I was writing a fix for that. I do agree that its impossible to happen in most cases, but a preventive measure is still good.

EDIT: Just fixed that 1:1 issue

[lokesh-tr]

@plemarquand I have updated it as you suggested. I am not sure if the explanation is too big, but I felt it was necessary. Please have a look and let me know if you have any other concerns.

[ahoppen]

One thought that could allow us to avoid any scrolling: How about when we want to show a peek window at line:column, we open the fake peek on line:(column-1) or line:1 if column == 0. That way we don’t actually jump to any different location.

[lokesh-tr]

@ahoppen I got the same thought few hours back, got time now... will do that now.

EDIT:
I thought of doing line = (line-1). If line == 0, we do line = 1
The last time I checked, we are not supposed to leave the line number unchanged. I will check it.

[ahoppen]

Changing the line might still result in a slight scroll if the expanded line is right at the start of the view port, I would imagine. If it’s possible to adjust the column, I would prefer that. If not, let’s go with your line proposal, it’s probably good enough.

[lokesh-tr]

I went with column one as you suggested and it works. 👍🏻

[lokesh-tr]

Ready to be merged, i guess?

Happy that merging this will make all the work which we did to be usable by everyone (who's using main) 🎉