microsoft/vs-editor-api

Microsoft Visual Studio Editor API definitions

Microsoft Visual Studio Editor API

This repository contains the open source layers of the Microsoft Visual Studio editor. This includes all public API definitions and some low level implementations of the editor including the text model, text logic, and editor primitives & operations subsystems. These layers are intended for extension authors to better integrate with the editor.

With a few caveats, the layers in this repository power both Visual Studio on Windows and the Visual Studio for Mac editors. While both editors are built on this codebase, many aspects of the editor are not open source, including the WPF and Cocoa UI layers.

Visual Studio for Mac

Visual Studio for Mac 8.1 introduced a brand new native macOS text editor built on the "real" Visual Studio editor core. Central to our ongoing effort to bring parity and performance benefits to developers by leveraging and sharing more code with Visual Studio on Windows, the UI layers were ported directly from WPF to modern Cocoa.

Most notably, the Cocoa editor uses Apple's Core Text, Core Graphics, and Core Animation technologies to perform retained-mode layout and high fidelity rendering of text. Among other enhancements for and integrations with macOS, it now supports all of the macOS input methods via the NSTextInputClient protocol.

Currently, the new native editor based on Visual Studio and the legacy editor co-exist while we transition all language services away from the legacy editor. Visual Studio for Mac supports C# and XAML (in 8.2 previews) so far, but will continue to enable support for other languages over the coming releases. Please refer to the Visual Studio for Mac roadmap for details on what's next.

This diagram should help visualize the layering of Visual Studio for Mac compared to Visual Studio while the legacy editor still exists for some languages.

Caveats

In order to facilitate porting the WPF editor from Windows to macOS, some breaking changes have been made to some of the lower-level interfaces. The ongoing plan is to reconcile these differences such that there is no API difference whatsoever between the WPF and Cocoa editors.

For now, however, there are two separate sets of NuGet packages for targeting Visual Studio and Visual Studio for Mac, available in the respective sections below.

While most non-UI related interfaces are identical across WPF and Cocoa implementations of the editor, many are new yet familiar: when targeting Cocoa, ICocoa* interfaces can generally be found in place of analogous IWpf* interfaces.

Resources

The following resources should help extension authors become familiar with the editor APIs and capabilities, and are relevant to both Visual Studio and Visual Studio for Mac.

• Managed Extensibility Framework
• MEF in the Editor
• Inside the Editor
• Language Service and Editor Extension Points
• A video introduction to the editor architecture

Editor SDK Installation

Visual Studio for Mac

NuGet packages are forthcoming, but all assemblies are available to extensions for Visual Studio for Mac when using Add-in Maker. The assemblies can also be produced directly from this repository (see Building the Editor API below).

Refer to the Extending Visual Studio for Mac documentation for details.

Visual Studio (Windows)

On Windows, the Visual Studio Editor API is available via NuGet and is also installed with the Visual Studio Extension Development workload.

NuGet Package	Current Version
Microsoft.VisualStudio.CoreUtility
Microsoft.VisualStudio.Text.Data
Microsoft.VisualStudio.Text.Logic
Microsoft.VisualStudio.Text.UI

Building The Editor API

While this repository is largely intended for reference, it can produce a viable build of the lower levels of the editor. Either open VSEditorCore.sln in Visual Studio or Visual Studio for Mac and build from the IDE, or build on the command line.

Visual Studio 2019 or Visual Studio for Mac 8.0 or newer is required.

Build

Assemblies will be available in the bin/ directory at the root of the repository.

$ msbuild /restore

Package

NuGet packages may also be produced locally and will be available in the _artifacts/nuget/ directory at the root of the repository.

$ msbuild /t:Pack

Contributing

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact [email protected] with any additional questions or comments.

Pull Requests

We are generally not accepting pull requests for this repository for the core editor code at this time. Please feel free to submit pull requests for other content in this repository, including new samples.

vs-editor-api's Issues

[Modern Commanding] Custom CommandArgs Factories

In modern editor commanding CommandArgs serves as both unique command identifier and a container for command specific arguments. While most commands do not accept any input arguments and their CommandArgs don't need any command specific arguments beside text view and subject buffer, some commands do. A prime example is the TypeCharCommandArgs, which contains the typed char. Extracting that typed character and instantiating such CommandArgs is host specific (in VS it's passed via IOleCommandTarget.Exec’s pvaIn argument) and currently handled by the editor host. At the moment therefore there is no way for extenders to create a new command that accepts host specific input.

Proposed solution

Keep command handlers cross IDE and introduce the concept of host specific CommandArgs factories. Such a factory allows creating CommandArgs instances using custom logic that utilizes IDE specific command input such as typed char in TypeCharCommandArgs or command arguments when a command is called via Command Window in VS. In VS such a factory gets access to IOleCommandTarget.Exec’s nCmdexecopt and pvaIn arguments.
Other hosts will need to provide a similar functionality.

Here is a sample CommandArgs facrtory:

    [Export(typeof(IVsCommandArgsFactory))]
    [Command(typeof(ShowContextMenuCommandArgs))]
    internal class ShowContextMenuCommandArgsFactory : IVsEditorCommandArgsFactory<ShowContextMenuCommandArgs>
    {
        /// <summary>
        /// This one is used in <see cref="ICommandHandler{T}.GetCommandState(T)"/>.
        /// </summary>
        public ShowContextMenuCommandArgs CreateCommandArgs(ITextView textView, ITextBuffer subjectBuffer)
        {
            return new ShowContextMenuCommandArgs(textView, subjectBuffer);
        }

        /// <summary>
        /// This one is used in <see cref="ICommandHandler{T}.ExecuteCommand(T, CommandExecutionContext)"/>.
        /// </summary>
        public ShowContextMenuCommandArgs CreateCommandArgs(ITextView textView, ITextBuffer subjectBuffer,
            uint nCmdexecopt, IntPtr pvaIn, IntPtr pvaOut)
        {
            if (pvaIn != IntPtr.Zero)
            {
                //the coordiantes are passed as variants containing short values. The y coordinate is an offset sizeof(variant)
                //from pvaIn (which is 16 bytes)
                object xCoordinateVariant = Marshal.GetObjectForNativeVariant(pvaIn);
                object yCoordinateVariant = Marshal.GetObjectForNativeVariant(pvaIn + 16);
                short? xCoordinate = xCoordinateVariant as short?;
                short? yCoordinate = yCoordinateVariant as short?;
                if (xCoordinate.HasValue && yCoordinate.HasValue)
                {
                    return new ShowContextMenuCommandArgs(textView, subjectBuffer, xCoordinate.Value, yCoordinate.Value);
                }
            }

            return new ShowContextMenuCommandArgs(textView, subjectBuffer);
        }
    }

Note that it creates 2 instances of ShowContextMenuCommandArgs, one that doesn't contain any input and is intended to be passed to ICommandHandler.GetCommandState(T) methods and another, which does contain the input and is intended to be passed to ICommandHandler.ExecuteCommand(T, CommandExecutionContext). This weird dichotomy is required because in VS IOleCommandTarget.QueryStatus doesn't have access to command arguments.
Alternatively we could drop first method entirely and require such CommandArgs classes to have a constructor that only accepts ITextView and ITextBuffer, but I prefer to keep all factory logic in one place.

Alternative solution would be to stop treating CommandArgs as both command ID and command input input container and leave it being just command ID and add CommandInput concept. Then ICommandHandler.GetCommandState will only get CommandArgs, but ICommandHandler.ExecuteComamnd - both CommandArgs and CommandInput. That goes against current commanding design in a pretty fundamental way though.

Additionally note [Command] attribute on the factory. Unlike command handlers it doesn't make sense for CommandArgs factories to have [ContentType]/[TextView] attributes so we need some metadata to avoid loading all factories just to determine which can produce a specific CommandArgs.
Alternatively we can introduce a custom attribute for exporting CommandArgs factories:

[ExportCommandArgsFactory(typeof(ShowContextMenuCommandArgs))]
internal class ShowContextMenuCommandArgsFactory : IVsEditorCommandArgsFactory<ShowContextMenuCommandArgs>
{
...
}

[VSMac] Even/Odd quick info not displayed

The even/odd quick info does not seem to be displayed when the AsyncQuickInfoDemo.VSMac project is run in VS Mac 8.1.0.2742. The current date time information is displayed.

Async Completion API discussion

Async Completion API walkthrough

Please comment 🐱‍👤, and I will add emoji to your comment depending on my progress
👍 I will do it
🎉 Done

Table of contents:

• Basics
• When completion is available
• How to implement a language service that participates in async completion API
• How to extend a language with new completion items
• How to implement custom sorting and filtering
• How to implement the UI
• How to interact with completion
• Best practices

Basics

The API is defined in Microsoft.VisualStudio.Language nuget, in the Microsoft.VisualStudio.Language.Intellisense.AsyncCompletion namespace.
All helper types are defined in Microsoft.VisualStudio.Language.Intellisense.AsyncCompletion.Data namespace.

Completion in VS uses MEF to discover extensions. Specifically, VS is looking for exports of type IAsyncCompletionSourceProvider, IAsyncCompletionItemManagerProvider, IAsyncCompletionCommitManagerProvider and ICompletionPresenterProvider. Each export must be decorated with Name and ContentType metadata. It may be decorated with TextViewRoles and Order metadata.

In general, methods named ...Async are invoked on the background thread and are cancelable. Otherwise, methods are invoked on the UI thread.

When completion is available

Prior to starting, completion checks the following:

• IFeatureService.IsEnabled(PredefinedEditorFeatureNames.Completion)

  • IFeatureService allows features to be disabled per view or per application
  • IFeatureService allows a group of features to be disabled, e.g. "disable all popups"
  • Current and planned uses:
    • Inline Rename, for the duration of rename session
    • Multi Caret, until the two features are certified to work together
    • ReSharper, because their hacks to disable a feature don't work with the asynchronous nature of Async Completion

• Is flight "CompletionAPI" enabled in IVsExperimentationService

• IAsyncCompletionBroker.IsCompletionSupported checks if there are any

  • IAsyncCompletionSourceProviders and
  • IAsyncCompletionItemManagers for a target content type

How to implement a language service that participates in async completion API

IAsyncCompletionSource

Implement IAsyncCompletionSourceProvider that returns an instance of IAsyncCompletionSource

When user interacts with Visual Studio, e.g. by typing, the editor will see if it is appropriate to begin a completion session. We do so by calling TryGetApplicableSpan. This method is invoked on UI thread while the user is typing, therefore it is important to return promptly. Usually, you just need to make a syntactic check whether completion is appropriate at the given location. Despite being called on the UI thread, we a supply CancellationToken that you should check and respect.

If at least one IAsyncCompletionSource returned true from TryGetApplicableSpan, completion session will start and begin processing on the background thread.

We will attempt to get completion items by asynchronously calling GetCompletionContextAsync where you provide completion items.

This method will be called on all available IAsyncCompletionSources, even if they returned false from TryGetApplicableSpan.
This is to accommodate for extensions who wish to add completion items without the need to care about the language's syntax, and potential interference with the main language service.

Items from all sources will be combined and eventually displayed in the UI. The UI will call GetDescriptionAsync to build tooltips for items you provided.

IAsyncCompletionCommitManager

Implement IAsyncCompletionCommitManagerProvider that returns an instance of IAsyncCompletionCommitManager

We use this interface to determine under which circumstances to commit (insert the completion text into the text buffer and close the completion UI) a completion item.

There must be one IAsyncCompletionCommitManager available to begin completion session.

When we first create the completion session, we access the PotentialCommitCharacters property that returns characters that potentially commit completion when user types them. We access this property, therefore it should return a preallocated array.

Typically, the commit characters include space and other token delimeters such as ., (, ). Don't worry about Tab and Enter, as they are handled separately. If a character is a commit character in some, but not all situations, you must add it to this collection. Characters from available IAsyncCompletionCommitManagers are combined into a single collection for the duration of the completion session.

We maintain this list so that editor's completion feature can quickly ignore characters that are not commit characters. If user types a character found in the provided array, Editor will call ShouldCommitCompletion on the UI thread. This is an opportunity to tell whether certain character is indeed a commit character in the given location. In most cases, simply return true, which means that every character in PotentialCommitCharacters will trigger the commit behavior.

When the completion item is about to be committed, Editor calls TryCommit on available IAsyncCompletionCommitManagers. This method is also called on UI thread and offers complete access to the ITextView and ITextBuffer, so that the language service can customize the way text is entered into the buffer. This method returns CommitResult which provides two pieces of information:

1. bool that indicates whether the item was committed - if not, Editor will call TryCommit on another IAsyncCompletionCommitManager
2. CommitBehavior with instructions for how to proceed. This is used by complicated language services, and it's best to return None.

Speaking of complicated language services - TryCommit was written for these language services. In most cases, feel free to return CommitResult.Unhandled. When all IAsyncCompletionCommitManagers return CommitResult.Unhandled, Editor will simply insert the completion item into the text buffer in the appropriate location.

How to extend a language with new completion items

The async completion API allows you to create extension that adds new completion items, without concerning you with the syntax tree or how to commit the item. These questions will be delegated to the language service. You just need to
implement IAsyncCompletionSourceProvider that returns an instance of IAsyncCompletionSource

When you implement TryGetApplicableSpan, return false and leave applicableSpan as default. As long as a single language service returns true and sets the applicableSpan, completion will start. Returning false does not exclude you from participating in completion!

Implement GetCompletionContextAsync where you provide completion items. They will be added to items from other sources. Implement GetDescriptionAsync that will provide tooltips for items you provided.

How to implement custom sorting and filtering

Visual Studio provides standard sorting and filtering facilities, but you may want to provide custom behavior for ContentType and TextViewRoles of your choice.

Implement IAsyncCompletionItemManagerProvider that returns an instance of IAsyncCompletionItemManager. Decorate IAsyncCompletionItemManagerProvider with MEF metadata ContentType and optionally TextViewRoles to narrow the scope of your extension.

The completion feature in Visual Studio is represented by IAsyncCompletionSession (we'll now call it "Session"). This object is active from the moment completion is "triggered" (see TryGetApplicableSpan) until it is Dismissed (pressing Escape or clicking away from completion UI) or until a completion item is Commited. The Session object holds properties that don't drastically change throughout the lifetime of the session: it stores the ITrackingSpan where completion is happening, has a reference to the ITextView (which may be null in Cascade!) and has a PropertyBag.

Immediately after obtaining CompletionItems from IAsyncCompletionSources, the Session calls SortCompletionListAsync. Then, the Session calls UpdateCompletionListAsync and will do so as long as the user is typing. Both methods are called asynchronously and take similar paremeters which we will cover shortly.

The purpose of SortCompletionListAsync is to sort items we received from multiple IAsyncCompletionSources.
UpdateCompletionListAsync will receive this sorted list. This is merely a performance improvement so that UpdateCompletionListAsync doesn't need to sort.

The purpose of UpdateCompletionListAsync is to produce a final list of items to display in the UI, and to provide information on how to display items in the UI. All the information is bundled in FilteredCompletionModel

Important:

Let's go over the asynchronous computation model.
Suppose user is continuously typing. At every keystroke, we take a reference to the text snapshot in the editor. If we have time, we call UpdateCompletionListAsync. If user typed quickly, we won't call UpdateCompletionListAsync. Or perhaps user typed (and modified editor's contents) while you were processing UpdateCompletionListAsync.

This means that information from IAsyncCompletionSession or its reference to ITextView may be stale. This is why we maintain an immutable model that stores all important properties of the completion session. We select the relevant bits and put them into second parameter of SortCompletionListAsync and UpdateCompletionListAsync: SessionInitialData and SessionInstantenousData respectively.

We introduced these data transfer objects to keep method signatures short.

How to implement the UI

Visual Studio provides standard UI, but you may want to create a custom UI for specific ContentType or TextViewRoles. Decorate ICompletionPresenterProvider with MEF metadata to narrow the scope for your UI.

Implement ICompletionPresenterProvider that returns an instance of ICompletionPresenter

This interface represents a class that manages the user interface. When we first show the completion UI, we call the Open method, and subsequently we call the Update method. Both methods accept a single parameter of type CompletionPresentationViewModel which contains data required to render the UI. We call these methods on the UI thread.

Notice that completion items are represented by CompletionItemWithHighlight - a struct that combines CompletionItem and array of Spans that should be bolded in the UI.

Completion filters are represented by CompletionFilterWithState that combines CompletionFilter with two bools that indicate whether filter is available and whether it is selected by the user. As the user types and narrows down the list of completion items, they also narrow down list of completion filters. Unavailable completion filters are not associated with any items that are visible at the moment, and we represent them with dim icons.

The CompletionFilter itself has displayText that appears in the tooltip, accessKey which is bound to a keyboard shortcut and image to represent it in the UI.

When user clicks a filter button, create a new instance of CompletionFilterWithState by calling CompletionFilterWithState.WithSelected, then raise CompletionFilterChaned event (TODO: event's documentation is not available). Editor will recompute completion items and call Update with new data.

When user changes the selected item by clicking on it, call CompletionItemSelected event (TODO: event's documentation is not available)

Handling of Up, Down, Page Up and Page Down keys is done on the Editor's side, the UI should not handle these cases. When handling Page Up and Page Down keys, we use the ICompletionPresenterProvider.ResultsPerPage property to select appropriate item.

The completion session depends on the ICompletionPresenter to accurately report the state of the UI using the following events:

• FiltersChanged that computes new set of items to display after user changed completion filters
• CompletionItemSelected that updates the selected item after user clicked it
• CommitRequested when user double-clicked an item
• CompletionClosed when the UI is closed.

How to interact with completion

IAsyncCompletionBroker is the entry point to the completion feature:

• method TriggerCompletion is used by VS to trigger a new session
• method IsCompletionActive lets you can see if there is an active session in a given ITextView
• method GetSession gets the active session in a given ITextView or returns null.
• method IsCompletionSupported returns whether there are any available IAsyncCompletionSourceProviders for a given IContentType.

IAsyncCompletionSession exposes the following:

• property TextView which is a reference to pertinent text view
  • note its ITextSnapshot may be different from what's used during computation. See SessionInstantenousData for the correct ITextSnapshot.
• property ApplicableSpan which tracks span
  1. Whose content is used to filter completion
  2. That will be replaced by committed item
• event CompletionTriggered when completion session is triggered
• event ItemCommitted when completion commits and closes,
• event Dismissed when completion closes without committing.
• GetComputedItems method that blocks to finish computation and returns ComputedCompletionItems
• event ItemsUpdated that retruns ComputedCompletionItems after computation finished.

The ComputedCompletionItems, available from IAsyncCompletionSession.ItemsUpdated and IAsyncCompletionSession.GetComputedItems() stores:

• Items
• Suggestion item
• Currently selected item
• Whether the selected item is a suggestion item

Best practices

Best practices for completion item source

To minimize number of allocations, create icons and filters once, and use their references in CompletionItem. For example:

static readonly ImageElement PropertyImage = new AccessibleImageElement(KnownMonikers.Property.ToImageId(), "Property image");
static readonly CompletionFilter PropertyFilter = new CompletionFilter("Properties", "P", PropertyImage);
static readonly ImmutableArray<CompletionFilter> PropertyFilters = new CompletionFilter[] { PropertyFilter }.ToImmutableArray();

Tooltip windows are redrawn when clicked

Hi

I'm using the new IAsync* QuickInfo API. Thanks for the help in here.

I'm not sure where to ask for help on this issue: my tooltip windows are redrawn when UserControls are clicked.

Minimal code can be found here. This behavior can also be observed with the older QuickInfo API.

Questions: would this be the place to ask this question. How to prevent that the tooltip is redrawn, or how to debug this.

Please add more documentation around ITextViewModelProvider

It is not documented how an extension developer can create their own implementation of ITextViewModelProvider and how such implementation can be used by Visual Studio. Please add more details about this interface.

DefaultCompletionItemManager Linq Code not performant

https://github.com/microsoft/vs-editor-api/blob/61ca43c05f2254b80e87dccaf029acec3f25feb3/src/Editor/Language/Impl/Language/AsyncCompletion/DefaultCompletionItemManager.cs

Hi im writing a voice plugin for intellisense and used this as reference. The linq code for the filters seems to performs really badly. Just stepped through it and rewrote it in normal c#. 10x performance increase. not sure why though

Is there a way for an extension to detect DarkMode theme for Visual Studio 2022? We have implemented ToolTips for our extension and we can't find a way to style the ToolTips according to the VS display theme.

Visual Studio and WinForms not cross compatible

Hello. I am a programmer who uses C#/.NET with WinForms. I have heard of issues with WinForms being incompatible with MacOS and especially Linux. While at least one developer was able to get Linux working with WinForms, I don't think that program is compatible with MacOS. Even with "The Linux Update", people on Linux can't use Visual Studio itself to compile the most recent commits. It shouldn't matter the Distro of Linux being used, and both WinForms and Visual Studio should be natively cross compatible. Sure MacOS may be able to use Visual Studio but WinForms is still WIndows only. In a future update for Visual Studio, add Linux Compatibility, and if WinForms ever gets an update, that should also be cross compatible. Maybe the WinForms part shouldn't be in this Issue but I couldn't find a repository for it so I put it here.
-IonicPIxels

bottom text

Issue with git

alot of times when I am trying to push to GitHub though vs, my changes are not recognized upon saving. and once I save changes, all changes that are still not pushed are not changes anymore. if a video or image is needed to explain what i mean further I will provide one

Modern Signature Help API?

Are there any plans to do for Signature Help, what has already been done for Quick Info and Completion? i.e. something like a IAsyncSignatureHelpSource, IAsyncSignatureHelpSourceProvider, etc., built on the modern commanding APIs.

At the moment a fair amount of boilerplate is still required to create a robust implementation of signature help. It would be great to see some of this boilerplate move down from Roslyn to VS :)

Is there any future plan to open source WPF layer of this API ?

While both editors are built on this codebase, many aspects of the editor are not open source, including the WPF and Cocoa UI layers.

It is written that WPF layer of this API is not yet available as open source. Is there any plan that WPF implementation of this API will be open sourced in upcoming releases and developers can embed the vs-editor in WPF app ?

improve accessibility of the editor by output more infos over UIA

Hey Guys,
I don't know whether I am here on the right place, but I will try this.
The Editor component of VS has some accessibility problems, because some infos are not communicated over the UIA interface or are wrong.

• The Linenumbers are always characters as TextUnit, that is nice, but if you enable "show line numbers" in Visual studio, this numbers will always take in the selectedTextRange in the UIA-Framework, if you go on the begin of a line.
• the Tags like ErrorTag and other classifiers are not exposed to the UIA interface, so no screenreader can get infos about that.
• Something seems wrong with the TextRange and Move, if you enable the Line numbers, the indexes are not right or the textrange gives strange values back.

The Issues could be resolved with a custom UIA pattern and some fixes, let's try to find a solution for this problems because this would give the accessibility of the whole VS a very push forward.

all the best,
Christopher

[TextUtilities.cs] C# file contains "invalid" UTF-8 fallback sequence... and no UTF-8 BOM

Sorry, unintentionally submitted; pressed the wrong button by mistake.

Crash by exception when using the non-obsolete constructor of SuggestedActionSet

Attached is a sample solution (including the ActivityLog.xml detailing the crash) which has been created by following to the letter the instructions in:

https://github.com/MicrosoftDocs/visualstudio-docs/blob/master/docs/extensibility/walkthrough-displaying-light-bulb-suggestions.md

When using the obsolete constructor (line 90 in TestSuggestedActionsSource.cs), the extension behaves as expected.

When commenting out line 90 and using the non-obsolete constructor in line 91, the extension will throw an exception and crash VS when invoked via the keyboard shortcut.

LightBulbTest.zip

Although unrelated to this particular issue, you guys might want to include a comment somewhere that, when using nested actions in the 'Quick Actions' menu (i.e., effectively, submenus), the return collection in GetActionSetsAsync must apparently be 'Immutable'. Otherwise, undecipherable crashes take place.

Leak of ITextUndoHistory

In a few profiling analysis sessions done in VSMac, I have observed that ITextUndoHistory is being leaked in UndoHistoryRegistryImpl.histories Dictionary.

From a few quick source greps, I observe that:

• UndoHistoryRegistryImpl.RemoveHistory is only called by TextBufferUndoManager.UnregisterUndoHistory
• Nobody calls TextBufferUndoManager.UnregisterUndoHistory.

Thus, all docs will leak an UndoHistoryRegistryImpl.

Is it possible to use the editor in a Xam.Mac application?

Is it possible to use the Visual Studio Editor for mac in a Xamarin for mac application? We're currently doing our own syntax highlight and a few other stuff on top of the standard Cocoa editor, but it would be great to replace it totally by your editor.

QuickInfoSessionOption in TriggerQuickInfoAsync does not seem to work

I would like to keep a Quick Info open when the mouse moves away. Thus, when I hover my mouse over a textView I issue a Trigger:

this._quickInfoBroker.TriggerQuickInfoAsync(this._textView, triggerPoint, QuickInfoSessionOptions.None);

Yet the option QuickInfoSessionOptions does not have any observable difference between QuickInfoSessionOptions.None and QuickInfoSessionOptions.TrackMouse.

Working example can be found here.

Question: What should I do to keep a Quick Info open when the mouse moves away?

Any API to replace tooltip for a completion item?

Nowadays a tooltip will display at the right side of selected item in the AutoCompletion list.

In VS 2017, we can create a class implementing IUIElementProvider<Completion, ICompletionSession> to override The RoslynToolTipProvider, like the below code shows.

[Export(typeof(IUIElementProvider<Completion, ICompletionSession>))]
[Name(nameof(CSharpCompletionTooltip))]
//Roslyn is the default Tooltip Provider. We must override it if we wish to use custom tooltips
[Order(Before = "RoslynToolTipProvider")]
[ContentType("CSharp")]
internal sealed class CSharpCompletionTooltipProvider : IUIElementProvider<Completion, ICompletionSession>

In VS 2022, the logic is changed.
It seems that no extension point is provided to override the completion tooltip any more.
What can we do if we are to change the appearance and content of a completion tooltip?

Add support for Linux

Is there any chance you can port this to support Linux as well please. Since this has been introduced into the monodevelop repository we've been unable to build any 8.* branches on Linux. You're alienating the entire Linux community by breaking the open-source monodevelop IDE and preventing us from using it. We're stuck on the older 7.* versions which means we're not able to fully utilise the advancements being made in the dotnet world, things like Balzor just don't work properly.
Please can you show your supposed love of Linux and actually support monodevelop properly on Linux and Mac. There have been open tickets in the monodevelop repository for over 6 months trying to get this resolved.

Do there exist examples that use IAsyncQuickInfoBroker?

I like to migrate to the new IAsync* QuickInfo api, but I can't find any examples that use this new API. I'm a bit confused how to migrate the following piece of code. Is the IntellisenseController still part of the new API? Where do I call the AsyncQuickInfoBroker?

internal sealed class QuickInfoController : IIntellisenseController
    {
        private readonly IList<ITextBuffer> _subjectBuffers;
        private readonly IAsyncQuickInfoBroker _quickInfoBroker;
        private ITextView _textView;

        internal QuickInfoController(
            ITextView textView,
            IList<ITextBuffer> subjectBuffers,
            IAsyncQuickInfoBroker quickInfoBroker)
        {
            this._textView = textView;
            this._subjectBuffers = subjectBuffers;
            this._quickInfoBroker = quickInfoBroker;
            
            this._textView.MouseHover += (o, e) => {
                SnapshotPoint? point = GetMousePosition(new SnapshotPoint(this._textView.TextSnapshot, e.Position));
                if (point.HasValue)
                {
                    ITrackingPoint triggerPoint = point.Value.Snapshot.CreateTrackingPoint(point.Value.Position, PointTrackingMode.Positive);
                    if (!this._quickInfoBroker.IsQuickInfoActive(this._textView))
                    {
                        this._quickInfoBroker.TriggerQuickInfoAsync(this._textView, triggerPoint);
                    }
                }
            };
        }

Possible error in documentation of ITextViewModelProvider

In the following file:

https://github.com/microsoft/vs-editor-api/blob/master/src/Editor/Text/Def/TextUI/Editor/ITextViewModelProvider.cs

It is written that we need to use the Export attribute like this:

[Export(NameSource=typeof(ITextViewModelProvider))]

Where is this Export attribute that has a NameSource property?

wpf Control - is it available to use outside VS extensions?

I see from the readme that the wpf text editor control itself isn't open source (yet?). But is it possible to instantiate the control in a wpf app outside visual studio. The Vs text editor is amazing, and I've always wanted to use it for my own open source projects.