A floating window for suggestions?

[imWildCat]

Instead of adding contents in the editor for suggestions, could we use a macOS window for suggestions?

Code in the editor seems to be super disturbing.

[intitni]

I have been thinking about the same thing. Will probably give it a try after 0.5.0.

[ICULikeMac]

Great idea

[MrMage]

I've read the latest release notes and would welcome a floating window with suggestions. Personally, I would suggest placing the window below the current text cursor, similar to Xcode's own suggestions. As an alternative, if that would interfere too much with Xcode's own suggestions, to the bottom left or above the cursor could also be options.

[imWildCat]

@MrMage exactly! Similar to that of Grammarly Mac

[MrMage]

@imWildCat do you have a screenshot of that overlay for illustration? :-)

[imWildCat]

https://www.grammarly.com/desktop/mac

[ICULikeMac]

Great idea referencing the Grammarly pop up. That would work here for sure! +1.

Note: I know sometimes the suggestions are quite large, unlike what's suggested in Grammarly but I don't think that's a problem as it's either filling up space on the page under the box or contained in a clean separate box which can be accepted/rejected.

[intitni]

I think I'll try the Grammarly-like solution first, as it appears easier to implement to me. If we still want the below-cursor solution later, it shouldn't be too hard to make the switch, since the only difference is where the window is located.

[imWildCat]

Thanks man! I believe even any floating window that is draggable is good! No need to be perfect at the initial stage.

Feel free to split tasks or create GH items for known issues and ask the community to fix.

[intitni]

The first version is released in 0.8.1!

During development, I found that it's difficult to implement a suggestion window that follows the text cursor. The biggest problem is that we don't have a way to listen to the appearance and disappearance of Xcode's built-in completion panel. If we want to avoid overlapping with it, we would have to place the suggestion window in a strange position. Therefore, I think the current solution is better.

[ICULikeMac]

Wow how cool! Looks fantastic - looking forward to using it this week!!

[imWildCat]

@intitni this is huge! Thank you!

[mickael-menu]

The biggest problem is that we don't have a way to listen to the appearance and disappearance of Xcode's built-in completion panel.

I had a similar need for my plugin embedding NeoVim in Xcode. I found a workaround by:

• Observing the AX created event.
• For each AXUIElement received with created, check whether it contains a child (kAXChildrenAttribute) with an identifier (kAXIdentifierAttribute) of _XC_COMPLETION_TABLE_.
• Observing uiElementDestroyed to know when the pop-up is closed.

You can find the code here.

Hope that helps, thank you for your work on this plugin!

[intitni]

The biggest problem is that we don't have a way to listen to the appearance and disappearance of Xcode's built-in completion panel.

I had a similar need for my plugin embedding NeoVim in Xcode. I found a workaround by:

• Observing the AX created event.
• For each AXUIElement received with created, check whether it contains a child (kAXChildrenAttribute) with an identifier (kAXIdentifierAttribute) of _XC_COMPLETION_TABLE_.
• Observing uiElementDestroyed to know when the pop-up is closed.

You can find the code here.

Hope that helps, thank you for your work on this plugin!

Based on my observation, the _XC_COMPLETION_TABLE_ does not get destroyed even if I close it with the ESC key until I either move the text cursor or exit the window. Is this also what you have experienced?

[mickael-menu]

No I get the destroyed event, otherwise that would break some keys in ShadowVim. Both when accepting a completion item or using escape.

I've tested only on Xcode 14.2 though.

[mickael-menu]

Oh, and I added the created and uiElementDestroyed observers on the app's AXUIElement.

[MaksimBezdrobnoi]

Awesome update with floating window! It gave me a second chance to use Copilot! thanks)

[github-actions]

This issue is stale because it has been open for 30 days with no activity.

[github-actions]

This issue was closed because it has been inactive for 14 days since being marked as stale.