The ProvideLanguageServiceAttribute class has been with us for many years now. At least since it shipped as source code in the Visual Studio 2005 SDK. With more than two dozen properties, it’s easy to get lost trying to figure out which ones are meaningful and/or useful, and which ones are safe to ignore.
Assembly versioning for strong-named assemblies is a notoriously difficult topic, but once understood becomes straightforward to work with. In this post, I’ll cover two features I recently started incorporating into my projects to ensure the versioning rules for the project are properly observed prior to releasing packages.
Validating the strong name of assemblies prior to publication
The Visual Studio 2010 SDK introduced the new class FileExtensionToContentTypeDefinition. This post is all about why I no longer use/export this class, and what I now do instead. The steps in this post only associate specific, known extension(s) with a content type. Further integration into the user-customizable File Types settings and Open With… features requires additional work described in my answer to this Stack Overflow question: Supporting user-specified file extensions in custom Visual Studio language service.
The following requirements led me away from this attribute.
IVsCodeWindowManager (beyond the scope of this article).IVsCodeWindowManager, you must provide an implementation of IVsLanguageInfo.IVsLanguageInfo, the GetFileExtensions and GetLanguageName methods of that interface will be used instead of the values given to FileExtensionToContentTypeDefinition.To maximize your ability to support the full range of Visual Studio features in your extension, you can take the following steps to register your new language or file type.
Package.[PackageRegistration(UseManagedResourcesOnly = true)] [InstalledProductRegistration("#110", "#111", "1.0")] [Guid("your guid here")] public class ExamplePackage : Package { } |
IVsLanguageInfo.This is actually pretty simple.
IVsLanguageInfo implementationRegister the IVsLanguageInfo implementation using the ProvideLanguageServiceAttribute and ProvideLanguageExtensionAttribute registration attributes. Override the Package.Initialize method to provide the implementation. Here is the updated ExamplePackage class.
ContentTypeDefinition.NOTE: Since we are not using a custom editor factory, the content type name used here must match the language name used as the 2nd argument to ProvideLanguageExtensionAttribute above.
Tunnel Vision Labs is currently working on extending the Java Language Support extension for Visual Studio to include a complete source-level debugger. If you are interested in testing an alpha build of this debugger, please contact Tunnel Vision Labs for more information.
In this post, I’ll talk a bit about the current state of the extension and the features currently supported by the debugger.
Current features of the debugger include:
In our opinion, this is hands-down the coolest feature of our debugger.
Today I’m releasing a small utility for quickly viewing GraphViz (DOT) files which I’ve used many times over the past year. The project source is hosted on GitHub.
This extension integrates a modified version of the standalone ZGRViewer into the NetBeans IDE. When a GraphViz file (*.dot or *.gv) file is opened, a plain text editor is presented along with “Source” and “Visual” buttons on the document’s tool bar. When the document is saved, the plugin uses GraphViz to generate an SVG for the file which can be viewed by clicking the “Visual” button. Further changes to the graph may be made by switching back to the “Source” view. Note: if changes are made to the source file, the visual graph is only updated after the file is saved.
Here is an example from editing Block.dot in the ANTLR 4 runtime documentation. The “Visual” pane for this file is shown above.
This extension requires the following to be installed separately.
After installation, if the dot executable is not in your system path, you’ll need to configure the path to dot before using the plugin. In the editor options under the Miscellaneous section is a GraphViz tab. Here is an example configuration on the Directories tab:
You may also wish to enable anti-aliasing on the Visualizer tab:
This post is derived from an email I sent to the NetBeans mailing last month. Some of the implementation details refer to specific items in the NetBeans codebase, but the general algorithms apply to any number of applications.
In the past I alluded to spending a great deal of time thinking about ways to improve the performance and usefulness of a code completion feature. This algorithm is complicated but ends up producing consistent, predictable behavior. It truly excels with COMPLETION_AUTO_POPUP_DELAY set to 0 and low-latency implementations of AsyncCompletionTask.query, but still performs better than alternatives when latencies are observable.
To start with, a couple definitions from the subject line:
I noticed that Ctrl+Enter deletes the current identifier before calling CompletionItem.defaultAction. Iāll refer to the behavior of Ctrl+Enter as Extend because it extends the completion to the end of the current identifier. Iāll refer to the behavior of Enter as No-Extend.
For this post, Iām examining the following questions:
As part of my continued work on ANTLRWorks 2, I have modified the Editor Code Completion module to support everything described in this email without any breaking API changes relative to the current specification 1.28. In addition to preserving API compatibility, my current implementation exactly follows the existing code completion behavior if a developer does not explicitly override it. The changes are available with patches (unfortunately multiple patches as I tweaked a few things) as an RFE in Bug 204867 in the NetBeans Bugzilla.
The difference is present because the current algorithm cannot reliably answer question #2.
From what I can tell, the code completion algorithm uses this feature to compensate for not keeping track of information available when the completion was invoked. For example, suppose you are trying to complete the identifier getStuff, and the following currently present. For reference, assume this is columns 0 before the āgā through 5 after the ātā.
getSt
When code completion (Ctrl+Space) is invoked at positions p=0 or p=5, the user expects the behavior of Enter. When the code completion is invoked at positions 0<p<5, the user expects the behavior of Ctrl+Enter. Also note that at position p=5, the algorithms of Enter and Ctrl+Enter are equivalent.
Using the example from Part 2, itās clear that the current selection algorithm used in the completion dropdown does not properly handle the Extend behavior, because it only considers the text before the caret when selecting an item. When the completion algorithm in invoked in Extend mode, all of the text of the current identifier should be considered when choosing the default selection.
If the code selection algorithm of Part 3 is implemented, then the user will encounter major problems under the current filtering algorithm. In addition, it should be immediately apparent that the current filtering algorithm is crippled because it is fully incapable of handling even the simplest misspellings when completion is invoked at the end of an identifier (position p=5 in the previous example). While I do not believe the following rules are ideal for all situations, I designed them to be easily implemented and feel similar to the current rules while preserving the ability to support the selection mode of Part 3 as well as handling many misspelling cases.
In No-Extend mode with no misspellings before the caret, these rules produce exactly the same result as the current implementation. In No-Extend mode with misspellings present before the caret, these rules prevent having an empty (useless) dropdown appear. Unfortunately, if the user attempting to complete getShell types getSt and presses Ctrl+Enter, the filtering above would result in only showing getStuff. The solution is adding the following rule which has much larger ramifications.
To allow even more convenient typing, the filtering algorithm can be updated to also allow the following.
Currently instant substitution only operates if the filtered list has a single item in it. It also only works if the caret is located at the end of an identifier, and when the prefix is a case-sensitive match. The current algorithm is in CompletionImpl.requestShowCompletionPane. This algorithm would need to be updated as follows.
It should be clear that if the filtering rules are relaxed per the advanced rules in Part 4 (especially Part 4.1), the current selection algorithm of first prefix match will do a poor job of choosing items the user is trying to complete. The following selection rules are prioritized for ideal behavior, but an implementation may use variations for efficiency as long as the variations result in predictable behavior (typically restricted to performance related simplifications to rules 1 and 9).
Unless otherwise specified, character matches are case-insensitive. While the user has an option to explicitly disable case-insensitive matching, if all of the rules from this email are in place then that option will negatively impact code completion usefulness.
If semantics are tracked as well as the actual inserted text (e.g. for Java an MRU list of ElementHandle instead of String), then a weighting algorithm should be used to balance between text inserted more recently and having a full semantic match. One possible way to handle this is having one MRU that tracks semantic elements and one that tracks strings. In the semantic element list make sure there are never 2 items present which are valid within the same context, then always prefer a semantic match over a plain string match. The net impact of considering semantics is very cool, but hard to explain the nuances (the end user will just see it as the algorithm always knowing what to type).
In theory, a weighting algorithm could also be used to provide a hybrid of the Validity and Recently Used selection steps. At this point I have not considered the specifics of such a feature.
The C# language service Visual Studio 2010 implements several items described in this post. For users with access to Visual Studio 2010 with a C# project, the following is a list of some of the differences between it and the algorithms above.
Visual Studio 11 apparently includes an additional fuzzy logic selection feature, which Iām really hoping they properly inserted between the Word Boundary and Validity steps of the selection algorithm (fingers crossed).
Iāve been working on Visual Studio 2010 extensibility for some time now, and I must say that creating a tool window was not the easiest task in the world.
The original goal of this project was creating an MEF service that allowed exporting classes implementing IToolWindowProvider, and have the service manage the creation of the tool windows and their entries on the View > Other Windows menu. This worked, but had several drawbacks that eventually led to the conclusion that this was the wrong approach. First and foremost, this method forced the assemblies providing tool windows to load even when the tool windows werenāt visible. The performance implications of this rule out using MEF as a general solution to this problem. That said, here are some other ālittle thingsā that I didnāt have worked out in the MEF solution:
Here is an outline of the general process of creating a new tool window. Following the outline, Iāll explain in detail what each step requires.
Iām basing this off of the VSIX project, because itās a nice clean project template. Itās also beneficial because users that already have a VSIX project can easily add a tool window to it.
For this part, you can create any control derived directly or indirectly from System.Windows.Control.
This helper class handles most of the code required for providing a tool window. You can download WpfToolWindowPane.cs here.
The last step is adding a command to the View > Other Windows menu so your tool window can be opened.
Open the MyProject.vsct file and fill it with the following. Use the same Guid for guidMyProjectPackage as you used for the MyProjectPackage class. For the other two placeholders, create new Guids.
< ?xml version="1.0" encoding="utf-8" ?> <commandtable xmlns="http://schemas.microsoft.com/VisualStudio/2005-10-18/CommandTable"> <extern href="vsshlids.h"/> <commands package="guidMyProjectPackage"> <buttons> <button guid="guidMyProjectPackageCmdSet" id="cmdidShowToolName" priority="0x100" type="Button"> <!--<Icon guid="guidShowToolNameCmdBmp" id="bmpShowToolName"/>--> <strings> <buttontext>Tool Name</buttontext> </strings> </button> </buttons> <!--<Bitmaps> <bitmap guid="guidShowToolNameCmdBmp" href="Resources\ToolIcon.png" usedList="bmpShowToolName"/> --> </commands> <commandplacements> <commandplacement guid="guidMyProjectPackageCmdSet" id="cmdidShowToolName" priority="0x100"> <parent guid="guidSHLMainMenu" id="IDG_VS_WNDO_OTRWNDWS1" /> </commandplacement> </commandplacements> <symbols> <guidsymbol name="guidMyProjectPackage" value="{00000000-0000-0000-0000-000000000000}" /> <guidsymbol name="guidMyProjectPackageCmdSet" value="{00000000-0000-0000-0000-000000000000}"> <idsymbol name="cmdidShowToolName" value="0x2001" /> </guidsymbol> <!--<GuidSymbol name="guidShowToolNameCmdBmp" value="{00000000-0000-0000-0000-000000000000}"> <idsymbol name="bmpShowToolName" value="1" /> --> </symbols> </commandtable> |
Add a class named Constants to your project to make the Guids you used in the command table accessible to your code.
internal static class Constants { public const int ToolWindowCommandId = 0x2001; public const string MyProjectPackageCmdSet = "{00000000-0000-0000-0000-000000000000}"; public static readonly Guid GuidMyProjectPackageCmdSet = new Guid(MyProjectPackageCmdSet); } |
Open the MyProjectPackage class. Add a new attribute to provide your tool window: [ProvideToolWindow(typeof(ToolNameToolWindowPane))]. Add the following code to the body of the class:
protected override void Initialize() { base.Initialize(); WpfToolWindowPane.ProvideToolWindowCommand<ToolNameToolWindowPane>(this, Constants.GuidMyProjectPackageCmdSet, Constants.ToolWindowCommandId); } |
I originally sent this to the ANTLR interest group, but figured it would make for a decent post here as well.
I’ll start with a couple fundamental concepts. First, there are three key things that get parsed in an IDE:
Second, the very nature of writing code results in semantically incorrect (invalid) code *almost always*, and syntactically incorrect code most of the time. Very often, the code is in a state that it can’t even be lexed by the language’s lexer. It is critical for each of the above cases to absolutely minimize the impact on the ability to provide meaningful coding assistance. This point is the fundamental reason I believe incremental lexers and parsers are significantly less valuable to an IDE than is often believed.
Here are several things to remember about each of the three "parsables".
Syntax highlighting is the only item above that requires a real-time component. The syntax highlighter must be able to perform a standard view update in less than 20ms for any character input. The easiest way to accomplish this is writing a "lightweight" lexer that, given any input that starts at a token boundary can tokenize the remaining text. The backing engine for my current syntax highlighters maintains a list of lines that do not start with a token boundary – for many languages this occurs for the 2nd and following lines of a multi-line comment. I can start lexing at any line in the entire document as long as it isn’t contained in this list, and can stop under a similar condition (the stop condition is slightly more complicated so I’ll leave it out). *The primary syntax highlighter must not perform any form of semantic analysis of the result.* A secondary highlighting component can asynchronously add highlighting to semantic elements such as semantic definitions, references, or other names.
Here are some basic things I do to improve the performance of the syntax highlighter’s lexer:
For any block of language code that does not affect other open documents (such as the body of functions in C), don’t validate the contents of a block. For C, this could mean parsing the body of a method as:
body:block
block:'{' (~('{'|'}') | block)* '}';
Often, all you care about are the declarations and definition headers. This sort of "loose" parsing prevents most syntax errors in the body of methods from impacting the availability of the key information – references to the declarations are usable at other points in code. Further improvements can be made by forcing a block termination when a keyword is found that cannot appear in the block, but since this can cause some unexpected results and offers relatively low "bang for the buck", I recommend holding off on this approach.
One of the most difficult aspects of an "intelligent" IDE is how to handle files while they are being edited. In designing an appropriate attack on the problem, it’s important to identify the types of information you can gather and for each: 1) Categorize it, 2) Give it a difficulty rating, 3) What can you do with it, and 4) Prioritize it. I’ll give several examples along with how you might leverage each to improve the overall usefulness of the IDE. Note that all of the below are performed asynchronously using a parameterized deferred action strategy described in a section below.
I decided to address this separately from the above. Here are the governing factors an auto-complete feature:
Core strategy: This is not complete, but gives a general idea of the initial approach that gives quite tolerable results.
Start at the cursor and read tokens in reverse "until they no longer affect the current location". For c-like languages, this means reading identifiers, periods, arrows (->), and parenthesis with arbitrary contents and nesting.
The result can generally be parsed as a postfix expression; the parser should be able to built an AST for just that postfix expression without any additional context.
Evaluate the AST against its previously cached context – use the buffer-mapped span of the enclosing language elements to evaluate the visibility of elements as you manually walk the expression’s AST. At each step, generate a list of visible elements, and select the appropriate item before continuing. At the end, you’ll have a list of accessible items at the point auto-complete was triggered – match that against any text the user has already typed and either fill in the single result or present a dropdown.
(only one example here so far)
Due to the way the unopened file parser skips parsing function bodies, it tends to be extremely fast. When it fails to parse a document, due to say a syntactically incorrect field declaration, you don’t want your opened files to stop showing navigation information. Upon failure, the opened file strategy can fall back to using an ANTLR fragment parser to locate the headers of language elements (class, field, or function definitions), from that information you can infer the scope of each element, and generally identify most or all of the items declared in a document.
After identifying elements by name and their "span" in the document, you’ll want to keep a list of the information around in case future edits render both of the above parsing methods unusable. When the header portion of a language element is deleted as part of a document edit, the element can be immediately removed from the cached list of elements located in the current file. Further, if the previous element had an inferred termination due to mismatched braces, its span can immediately be expanded to include any remaining portion of the original span of the removed language element. The cache relies on [buffer span mapping] to properly track the current location of each language element as edits are applied to the document.
Any time the IDE tries to offer information about a language element in an opened file, the information is checked against that documents cache for potential updates (for example, Go To Definition should always go to the correct location, even if a large block of text was pasted above the definition).
This strategy is basically a modified, asynchronous "dirty" flag based trigger for an arbitrary action. The strategy addresses several goals:
Here’s the basic implementation:
With the addition of Jump Lists to the taskbar in Windows 7, I couldnāt pass up creating a new root folders solution to leverage this organization on the Start Menu. By combining WPF and .NET 4ās new Windows Shell APIs, the result was remarkably simple. Iāve included the source code in the archive below if you want to see the details.
To use the application:
Here is the configuration application and the result:
As some people have noticed, the Visual Studio 2010 SDK doesn’t have great support for the Output Window from MEF extensions. This post aims to change that. Like several other components I’m writing about, I hope to provide this one in a “general extensibility helper” that could be installed separately from extensions that use it so its features can be shared among them.
There are a couple goals here:
I’ll start with the usage (since that’s the interface people will normally see) and follow it with the implementation.
Now this is easy.
First you import the IOutputWindowService:
Then you use it to get an output window, which you can write to:
If you want to write to one of the standard panes, pass one of the following to TryGetPane:
IOutputWindowPane and IOutputWindowService interfacesIOleServiceProvider
