~/camerontaylor.dev - Software

Fixing GitHub Copilot Inline Suggestions

2025-09-17T00:00:00+00:00

and other improvements to GitHub Copilot usability…

Better Inline Suggestions</a></li>

Fix Tab Completion with Terminal Suggestions</a></li> </ul>

Better Inline Suggestions</h2>
One of the most frustrated things about using GitHub Copilot has been the default behavior of inline suggestions. If I were piloting a plane, it would be very annoying if the copilot decided to reach over and grab my controls any time it pleased.
However, there are times when I do wish I had access to these suggestions, so I do not want to disable them completely.
The following shows how to disable inline suggestions by default and invoke it with an explicit keyboard shortcut.

Add the following to your VSCode user settings. This disables inline suggestions.

{</span>
</span></span>    //</span> other settings . . .
</span></span></span>
</span></span>    </span>"</span>editor.inlineSuggest.enabled"</span></span></span>:</span> </span>false</span>
</span></span>}</span></span>
</span></code></pre>
Trigger Inline Suggestions</h3>
When you wish to invoke inline suggestions, use the editor.action.inlineSuggest.trigger</code> vscode command.</p>
By default, this is bound to alt+\</code> on windows and opt+\</code> on mac.</p>
Accept Inline Suggestions</h3>
One the suggestion appears, it can be accepted as normal with tab</code>. Or, using the editor.action.inlineSuggest.acceptNextWord</code> and editor.action.inlineSuggest.acceptNextLine</code> vscode commands, the first parts of the suggestions can be accepted. These are helpful when only the first portion of the inline suggestion is desired.</p>
By default, editor.action.inlineSuggest.acceptNextWord</code> is bound to ctrl+right</code> on windows and cmd+right</code> on mac. But, editor.action.inlineSuggest.acceptNextLine</code> has no keybinding, so you will need to make a custom shortcut.</p>
</p>
Fix Tab Completion with Terminal Suggestions</h2>
GitHub Copilot includes suggestions for completing commands when using the integrated terminal in VSCode. By default, pressing tab</code> or enter</code> will execute the first command, which is annoying because tab completion is deeply ingrained in the muscle memory of anyone who uses a terminal regularly.</p>
</p>

No… I don’t want to clone a whole repo in my current project…</em></p>
</blockquote>
Setting the selection mode in user settings to "never"</code> will require first navigating to a suggestion using arrow keys.</p>
{</span>
</span></span>    //</span> other settings . . .
</span></span></span>
</span></span>  </span>"</span>terminal.integrated.suggest.selectionMode"</span></span></span>:</span> </span>"</span>never"</span></span>,</span>
</span></span>}</span></span>
</span></code></pre>

Fleet Configuration Management 2025-04-07T00:00:00+00:00 This post is also publised to the Microsoft ISE Developer Blog</a>. Introduction</h1> Recently, my team at Microsoft completed a customer engagement that involved managing edge deployments onto factory floors across geographical locations. This system needed to support existing workloads migrated from Azure IoT Hub, new workloads for processing IoT data feeds, and machine learning workloads for performing inference to ship intelligence to the edge. During this engagement, we built a system to handle this complexity using Kalypso</a> to orchestrate GitOps deployments across a fleet of arc-enabled Kubernetes clusters</a> hosting Azure IoT Operations</a> to support cloud connectivity and IoT device telemetry. This post explains the challenge of fleet configuration management, the role of an automated fleet configuration management system, and describes key considerations for building such a system. What Is Fleet Configuration Management?</h2> An automated fleet configuration management system is essential in a scenario where many workloads or applications need to be deployed and managed across a fleet of hosting platforms. This can be the case for cloud hosted platforms serving separate purposes, or edge hosted platforms where workloads need to be distributed across separate locations. Example Fleet Configuration Management Systems</h2> There are a few options for implementing a fleet configuration management system. The one that works best for a given scenario will depend on details such as the hosting platforms that they support, licensing, and operational requirements. All of these options require managing a single separate Kubernetes cluster to run the automation work of the system. Azure Kubernetes Fleet Manager</a>: This is a good choice for cloud-hosted AKS workloads and provides features for orchestrating Kubernetes cluster operations such as cluster version upgrades. A “Hub Cluster” hosts a Kubernetes controller that reconciles all of the workloads running on member clusters.</li> Rancher Fleet</a>: This is a good choice if you are using Rancher to manage your Kubernetes clusters. It is open source</a> and uses a Fleet Agent to manage individual workloads on clusters within the fleet. A “Fleet Controller Cluster” hosts a Kubernetes controller and is monitored by all of the individual fleet clusters.</li> Kalypso</a>: This is a good choice for full flexibility as it is compatible with edge or cloud-hosted clusters and works with any GitOps agents (Flux, ArgoCD, etc.). The Kalypso scheduler runs on a designated Kubernetes cluster and orchestrates pull requests to GitOps repositories that are monitored by separate GitOps clusters. See Example Architecture With Kalypso</a> below for an example architecture using Kalypso.</li> </ul> Definitions</h2> Before getting into the details, lets first define terms as they appear in this post. A fleet is a collection of hosting platforms that are managed together.</li> A workload is a piece of software that is deployed as a unit onto the fleet.</li> Configuration represents a specific permutation of settings and specifications to make an instance of a workload run correctly in the fleet.</li> </ul> Generally, a fleet is composed of many hosting platforms, and there are many workloads that are deployed, each with a unique set of configuration. The specific details will depend on what the hosting platform and workloads are, but for this post, we will use Kubernetes</a> clusters as the fleet, Helm</a> charts as workloads, and rendered Kubernetes objects (manifests)</a> as configuration. We will also assume that the workloads are deployed using GitOps</a> principles, where the configuration is stored in a Git repository and monitored by GitOps agents (e.g. Flux</a>) running on clusters in the fleet. What Problem Does Fleet Configuration Management Solve?</h1> Fleet configuration management solves a problem that only becomes apparent when managing many workloads across many clusters. This next series of diagrams outlines the problem as the number of clusters and workloads scales up from a single workload and cluster, to many workloads across many clusters. One Workload, One Cluster</h2> The simplest scenario starts with one workload being deployed into one cluster. The workload’s Kubernetes manifests are committed into a GitHub repository that is monitored by the Flux GitOps agent. When a change is made to the workload’s Kubernetes manifests, that change is detected and applied automatically in the cluster. One Workload, Many Clusters</h2> For the workload to be deployed to a fleet of Kubernetes clusters, each cluster just needs to host its own Flux agent that is configured to watch the same set of Kubernetes manifests for the workload. When a change is made to the workload’s Kubernetes manifests, that change is detected and applied by each Flux agent independently. This enables one instance of the workload to be deployed into each cluster in the fleet. However, it is usually the case that each instance of this workload needs to be configured differently. This is because clusters in a fleet will often serve different purposes, and configuration must be applied to reflect that. For example, different hostnames, workload scaling behaviors, or feature flags might need to be controlled separately for different clusters in the fleet. This can be made possible by providing multiple configurations as part of the workload’s Kubernetes manifests and modifying the Flux agents to watch their own dedicated configurations. This enables independent configuration for each instance of the workload at the cost of additional complexity for managing configuration manifests and Flux agents. Many Workloads, Many Clusters</h2> To support additional workloads, the same setup needs to be replicated. Each workload will have its own set of Kubernetes manifests that each contains configuration for each cluster in the fleet and each flux agent needs to know what configurations to watch. While this works and can be manageable for a small number of workloads and clusters, the complexity of manually creating workload configurations does not scale well as the number of workloads and clusters increases. Each workload must provide a unique set of configurations for each cluster in the fleet, and each cluster must be configured to watch the appropriate manifests. The Role of a Configuration Management System</h2> A fleet configuration management system is an automated system that aims to simplify the complexities of manually managing workload configurations for the fleet. These systems serve 3 purposes: Controlling what workloads get deployed into what clusters</li> Composing and delivering configurations for workloads onto clusters</li> Observability for inspecting what workloads are deployed on what clusters</li> </ol> Configuration management systems provide automation to reduce the amount of manual configuration from multiplicative scaling to additive scaling by the number of workloads and clusters in the fleet. This allows engineering and operations teams to easily scale the number of workloads and clusters. When a new workload or cluster is added, it only needs to be registered with the fleet configuration management system. The system will then automatically compose and deliver the appropriate configurations to the clusters in the fleet. Do I Need A Fleet Configuration Management System?</h2> Registering workloads and clusters with a fleet configuration management system requires managing higher-level deployment abstractions and managing a system that operates on these abstractions to automate configuration delivery. This adds complexity to the system and requires additional operational overhead. It is important to weigh this cost against the cost of manually curating workload configurations in your system. Example Architecture With Kalypso</h1> This is an example architecture that generalizes the architecture that we built in our recent customer engagement. For more details on getting started with Kalypso, see its GitHub repositories</a> and the following Microsoft Learn pages: Workload management in a multi-cluster environment with GitOps</a></li> Explore workload management in a multi-cluster environment with GitOps</a></li> </ul> Personas</h2> This architecture serves two personas: the Application Engineer and the Platform Engineer. There may be many different Application Engineers, one for each independent workload. The Application Engineer owns and authors workloads that run within the fleet of Kubernetes clusters. Each workload has its own independent software development lifecycle that is defined and practiced by the Application Engineer. The Platform Engineer owns and manages the Kalypso Fleet Configuration Management Cluster. This service facilitates the complexities of generating and distributing the appropriate configuration across the fleet for all workloads. Architecture Diagram</h2> System Workflow</h2> Application Engineers author changes to their workloads independently via git contributions.</li> Continuous Integration flows run independently in response to changes to workload source code.</li> Continuous Integration (CI) automatically compiles and publishes artifacts for use in deployments. For example, Docker images are built and pushed into Azure Container Registry for fleet clusters to pull from.</li> Continuous Deployment (CD) automatically compiles and publishes GitOps manifests for deployment into fleet clusters. For example, Kubernetes yaml files might get rendered and pushed to the GitHub repositories monitored by Flux agents in the fleet.</li> Platform Engineers schedule workload deployments to the fleet and coordinate generating platform dependent workload configuration. This is done via git contributions to the Platform Control Plane repository.</li> The Kalypso Scheduler running inside the management cluster automatically compiles and publishes GitOps manifests for deployment into fleet clusters. These are Kubernetes yaml files monitored by Flux agents in the fleet.</li> Flux agents in the fleet detect any changes to GitOps manifests from workloads and the platform GitOps repository.</li> Flux agents interact with their respective Kubernetes API servers to ensure that resources are provisioned in the fleet.</li> The Observability Hub running inside the management cluster monitors deployment state for all workloads across the fleet. This information is surfaced in Grafana dashboards.</li> Engineers monitor workload deployments across the fleet using deployment observability dashboards.</li> </ol> Kalypso Runbooks</h2> To learn more about how Application Engineers and Platform Engineers use this system, see the Kalypso Runbooks</a> in Kalypso’s documentation. These runbooks provide step-by-step instructions on the common Kalypso use cases and include examples for each scenario. Conclusion</h1> Fleet configuration management is a powerful tool for scaling configuration management for many different workloads across many different hosting platforms. These systems automate the tedious work of managing individual configuration files by using higher level abstractions to compose and deliver configuration to the fleet. Acknowledgements</h2> Thank you to the rest of the ISE dev crew who helped with the customer engagement that inspired this post Bindu Chinnasamy</a>, John Hauppa</a>, Uffaz Nathaniel</a>, Bryan Leighton</a>, Laura Lund</a>, and Kanishk Tantia</a>. And a special thank you to Eugene Fedorenko</a> for his expertise and guidance on using Kalypso. ISE Developer Blog</h2> This post is also publised to the Microsoft ISE Developer Blog</a>. Learning Rust and Building a CLI 2025-03-13T00:00:00+00:00 Photo by Thomas Tastet</a> on Unsplash</a> </div> Lately, I have been feeling a particularly strong itch to learn a new technology and just build something. This feeling is nothing new to me, as making stuff is my primary motivator and I am drawn to new technologies like a moth to a flame. So, I did what I do best and decided to build an over-engineered tool to solve a minor problem: managing configuration and dotfiles on my development machines. Over the course of a day, I use 3 different computers. My work MacBook, my personal MacBook, and my Windows gaming PC. On each of these computers, I install and configure the same set of software (ex: git, zsh, tmux). In order to synchronize configuration across machines, I set up a dotfiles repository</a>. With my dotfiles repository</a> cloned onto each of my computers, the problem became copying files to their expected filesystem location for the respective tools to use. This can be managed via scripts, but these scripts get tricky when files need to be slightly different for each machine. For example, on my work laptop, I want my gitconfig email address to be my work address rather than my personal one. I used this problem as an excuse to learn Rust</a> and build a CLI utility, dotpatina</a>. Dotpatina allows me to declaratively manage</a> dotfiles using handlebars templating</a> and renders diff visualizations</a> to make it clear what files need to change when I update my dotfiles repository. Here is an example of it in action: For more information about dotpatina, see the GitHub repository</a>. Being a Beginner Again</h1> I chose Rust primarily because I have never used it before. And, its performance</a> & memory safety</a> guarantees sound like it would make a fun language for future projects. My objective was to build a “production ready” (in quotes because I have no expectations that anyone other than me will use dotpatina) tool from the ground up using a new language and toolchain. I just wanted to be a beginner again, and Rust’s famously steep learning curve seemed like the perfect choice. Beginner Rust Resources</h2> Before really building anything, I started with the general Rust tutorials. rust by example</a>: Very good comprehensive language overview</li> rustlings</a>: Exercises to test Rust knowledge</li> Learn X in Y Minutes (Where X = Rust)</a>: My personal favorite website for getting familiar with a new language</li> </ol> These were good introductions and served to introduce me to cargo</a>, Rust’s toolchain, and concepts (like borrowing</a> and lifetimes</a>). Compared to learning other programming languages, Rust has great resources for gaining hands-on practice right from the start. And, many of these resources guide you through error scenarios and how to fix them. Too often, introductory material will stop after the happy path where everything works as intended. The Rust Software Development Lifecycle</h2> With Dotpatina, I didn’t just want to write the Rust code for a CLI. I wanted to write tests, publish it to a public place, and include documentation. I used Rust and cargo for running tests and formatting. This was one of my favorite parts of the Rust language because of how consistent the tooling is across cargo crates. The dotpatina create is published to crates.io</a> automatically when changes are pushed to main</a>. docs.rs</a> hosts documentation for any crates published to crates.io. But, I also included documentation hosting with GitHub pages</a>. VSCode vs Rust Rover</h3> While building dotpatina, I also tested two development environments: VSCode</a> with the rust-analyzer extension</a> and RustRover by Jetbrains</a>. Generally, I found Rust Rover to be the better experience for working directly with Rust code. It is easier to run Rust tests, cargo commands, and viewing Rust library documentation. However, the GitHub Copilot experience (details below) was better in VSCode. Learning Rust with AI Assistance</h1> After learning the basics of Rust, but before diving into Rust development, I decided to make a conscious effort to use GitHub Copilot</a> (with the o1 preview model) as an AI programming assistant. This was my first honest effort using these tools on a “real” project. So, I will summarize what I thought about GitHub Copilot with tooling that I am not an expert in. Explaining Errors</h2> My favorite use of GitHub Copilot is explaining errors. It doesn’t take long after starting a Rust program until running into your first compiler error. And, a regular part of working with Rust is dealing with the borrow checker. Since there are whole classes of compile time errors that would be runtime errors in traditional languages, it is very easy to provide error information as context to GitHub Copilot. Before too long, I found myself defaulting to GitHub Copilot to explain an error. Invoking the /explain</code> quick action is just a keyboard shortcut away, and is much quicker than copying relevant error information, searching the web, and finding a relevant (probably Stack Overflow</a>) link. The GitHub Copilot chat view shows what portion of the code was referenced and explains a few potential solutions. In this case, returning values instead of references is the suggested solution. Except… the code is already doing that. And cloning doesn’t fix the error either. So, why is this my favorite part of using GitHub Copilot? Well, because it helped me explore the error as it related to my code specifically. GitHub Copilot generally accounts for specifics to my codebase that are provided via context. When simply searching for error help online, the search results are independent of the code subject to the error. It becomes the responsibility of the programmer to translate help to their codebase. GitHub Copilot helps with this translation. In other instances of explaining and fixing errors, GitHub Copilot would provide solutions that technically worked. These technically correct solutions fell into 3 buckets (in order of frequency): Solutions that were the “best” for the job. At least to my knowledge.</li> Solutions that were not the “best”, and I had to continue iterating before settling on a final implementation.</li> Solutions that were the “best” because they were better than my initial intentions.</li> </ol> This experience did not completely replace RTFM</a> or web search. The challenge seems to be identifying and providing the proper context to GitHub Copilot to generate a helpful response. But, it has become my first line of defense against the red underlines in my IDE. Repetitive or One-Off Tasks</h2> When it comes to actually generating code, I found GitHub Copilot to be particularly helpful in 2 places: very repetitive code and one-off tasks that might be done once per project. Repetitive Code</h3> When developing software, I will almost religiously enforce DRY</a> principals. The one constant exception to this is when writing unit tests. This allows unit tests to serve as self-contained examples as well. And, debugging tests is easier without the extra layers of abstraction that reduce repeated code. In addition to the repetitive nature, unit tests often have an explicit naming pattern. For example, test names might follow the template: #[test] fn code_under_test_does_X_when_Y() { // Arrange // ... set up conditions for "Y" // Act // ... invoke "code_under_test" // Assert // ... validate "X" happened } </code></pre> The repetitive nature of unit tests and clear test naming creates perfect conditions for GitHub Copilot to generate large portions of code. In terms of pure time savings, I found this to be the most helpful use of GitHub Copilot. One-Off Tasks</h3> On the other end of the spectrum are one-off tasks. These are the tasks that happen infrequently enough that it is hard to become an “expert” in the syntax. When building Dotpatina, I created GitHub Actions workflows for continuous integration and continuous deployment. This is a one-time set up task and requires specific yaml syntax. A quick comment, and GitHub Copilot suggests the proper yaml for triggering a workflow under the desired conditions. My Concerns with AI Pair Programming</h2> Generative AI and AI Pair Programming is here to stay, and I believe Software Engineers will need to make use of this technology (where it provides real benefit) in order to stay relevant in the job market.However, I do have some concerns with generative AI’s impact on the industry. I worry about its ability to generate hidden technical debt, especially when code is not thoroughly reviewed by an expert. Even if code functions perfectly. Inefficient code is harder to maintain and makes less code less green</a>. I worry about the accessibility of programming. Learning to code had been very accessible to people, only requiring a computer and an internet connection. While there are cheaper AI pair programmers and GitHub Copilot has a free tier, it is still expensive to get “quality and quantity” use out of AI pair programmers. And, I worry that the craftsmanship of computer programming will lose value. Although admittedly, this one makes me sound like a horse in the age of the automobile. Takeaways</h1> Taking the time to learn a new programming language and complete a full end-to-end project was a fun exercise. Putting an intentional effort into using an AI pair programmer in this context let me evaluate GitHub Copilot as a tool without the pressures of deadlines or scrutiny of others. And, this has given me motivation for starting or completing other side-projects to satisfy my desire to build Software outside the context of my day job. Building on my new knowledge of Rust, I plan on exploring game development with Bevy</a> or cross-platform app development with Tauri</a>. I am also interested in evaluating Continue</a> with local Ollama models</a> as a more accessible AI pair programmer alternative. PortraitWorks 2020-01-14T00:00:00+00:00 Check out PortraitWorks</a> and download it on iOS or Android!</h4> A lot of my free time and energy has been put into developing Portrait Workshop with with the Worldspinner team, and we have launched a kickstarter</a> that will help us bring it to market. Check it out if you are looking for a great tool to build characters for games, stories, or online avatars!

Kalypso Runbooks</h2>
To learn more about how Application Engineers and Platform Engineers use this system, see the Kalypso Runbooks</a> in Kalypso’s documentation. These runbooks provide step-by-step instructions on the common Kalypso use cases and include examples for each scenario.</p>

ISE Developer Blog</h2>
This post is also publised to the Microsoft ISE Developer Blog</a>.</p>

~/camerontaylor.dev - Software

Fixing GitHub Copilot Inline Suggestions

Trigger Inline Suggestions</h3>
When you wish to invoke inline suggestions, use the `editor.action.inlineSuggest.trigger</code> vscode command.</p>`
`By default, this is bound to alt+\</code> on windows and opt+\</code> on mac.</p>`

Fleet Configuration Management

Learning Rust and Building a CLI

PortraitWorks

~/camerontaylor.dev - Software

Fixing GitHub Copilot Inline Suggestions

Trigger Inline Suggestions</h3> When you wish to invoke inline suggestions, use the editor.action.inlineSuggest.trigger</code> vscode command.</p> By default, this is bound to alt+\</code> on windows and opt+\</code> on mac.</p>

Fleet Configuration Management

Definitions</h2> Before getting into the details, lets first define terms as they appear in this post.</p>

Learning Rust and Building a CLI

PortraitWorks

Trigger Inline Suggestions</h3>
When you wish to invoke inline suggestions, use the `editor.action.inlineSuggest.trigger</code> vscode command.</p>`
`By default, this is bound to alt+\</code> on windows and opt+\</code> on mac.</p>`