Release notes are being generated automatically and will be added to this release shortly. If they haven't appeared within a few hours, ping the Aspire team.
Full commit: 70b33bcb5f64c75e3ab6f57616545f35bd43dc81
Release notes are being generated automatically and will be added to this release shortly. If they haven't appeared within a few hours, ping the Aspire team.
Full commit: 70b33bcb5f64c75e3ab6f57616545f35bd43dc81
Most software systems do not fail because they were poorly written on day one. They fail because they become too expensive to change on day one thousand.
If you spend serious time in GitHub Copilot CLI, you've probably had that moment. You're deep in a session, things are moving fast, and suddenly you hit context compaction out of nowhere. The /context and /usage commands help, but they interrupt your flow. What if the information was just there, all the time, without you having to ask?
That's exactly where the statusline command can help: a persistent, live bar at the bottom of your CLI session that shows whatever your script prints — token usage, context percentage, current model, cost estimates, session duration, and more.
Once it's running, it looks something like this:
█████░░░░░ 50% 64.0k/128.0k | ✱ Sonnet 4.5 | ~$0.04 | ⏱️ 00:12:34
This guide walks you through the full setup from scratch, including a "hello world" sanity check. In a follow-up post we’ll tweak the result to example above.
Status: Custom status line support requires experimental features enabled in Copilot CLI. You can enable these with
/experimental on
Start Copilot CLI, then use the built-in command to open the status line configuration:
/statusline
Now you can enable multiple elements in your status line. For example, we’ll add information about the context window size and daily quota:
Our statusline now looks like this:
That’s a good starting point. But if these tweaks above are not sufficient, you can choose custom from the list.
Now we can configure a custom command that will be executed. To configure this command, go to %USERPROFILE%/.copilot/settings.json and add the statusLine configuration:
{
"statusLine": {
"type": "command",
"command": "statusline.cmd"
}
}
PowerShell scripts aren't directly executable on Windows, so we’ll use an intermediate statusline.cmd that invokes our Powershell script:
pwsh -NoProfile -ExecutionPolicy Bypass -File "%~dp0statusline-script.ps1"
Use pwsh (PowerShell 7+) rather than powershell.exe — it starts significantly faster, which matters because Copilot CLI will time out your script if it takes too long.
-NoProfile is also essential — without it, PowerShell loads your full profile on every single status line update, adding noticeable latency.
Before building anything real, confirm the wiring works with the simplest possible script:
Write-Host "Hello from PowerShell status line!"
Run /restart inside Copilot CLI. If you see the message in the status bar after your next prompt, everything is connected correctly. This one-liner separates configuration problems from script problems — worth doing before going further.
Copilot CLI pipes a JSON payload to your script via stdin after each model response. To see exactly what you're working with in your version of the CLI, temporarily replace the script with this:
#Requires -Version 7
$payload = $input | ConvertFrom-Json
Write-Host "Payload: $($payload | ConvertTo-Json -Compress)"
Restart and run a prompt. The full JSON will appear in the status bar. This payload is your data source for everything that you want to show.
The /statusline custom command is a small feature with a high leverage ratio. Once it's running, you stop thinking about context and cost and just work. The setup is roughly four steps: enable experimental features, open /statusline to toggle the custom option, wire up the config, write a simple test script, then you are ready to build the real thing.
We’ll continue tomorrow…
The Win32 TreeView control in the common controls library provides two ways of sorting elements.
TVM_SORTCHILDREN: Sorts children alphabetically by name.TVM_SORTCHILDRENCB: Sorts children via custmm callback.The custom callback is provided the lParam of the two tree items being compared. But what if you want to sort by a combination of both the text and the lParam? How do you get both?
There are two general designs for using UI controls that represent collections.
One model is for the UI control to be the data repository. Everything you need to know about the item resides in the UI control, somewhere in its name, its check state, its selection state, whatever. If you need to know something about an item, you ask the UI control for the information.
The second model is for the data repository to be some sort of object that itself does not have any UI. (This is known in the biz as a “data model”.) You then construct UI elements to be the representation of those objects.
Windows controls generally lean toward the data model approach because there is usually a lot of information about an item that is not present in its UI representation. The data model approach also allows for optimizations in which where very large collections of items create UI elements only for the items that are visible on screen. You can see this in the XAML ListView control as well as in the classic Win32 ListView control when placed into owner-data mode.
For the controls in the common controls library, the general pattern is to provide a place to store a pointer-sized value that is not shown in the UI, typically called “item data” or just lParam. Here is where you store a pointer to the data model object that the UI object represents.
Okay, so let’s look at the TreeView sort methods again.
The TVM_SORTCHILDRENCB message takes a callback which is passed the lParams of two items to compare. The theory is that these lParams are pointers to larger data structures that describe the item, and you use those larger data structures to decide the ordering of the two items.
The TVM_SORTCHILDREN message doesn’t take a callback. It is a convenience method for the case where you are just sorting by name, so it uses the already-available name assigned to the item.
The case where you would need both is the case where the lParam is not enough to recover the name, either because it’s a pointer to a structure that doesn’t include a name, or because it’s not a pointer at all.
I can imagine running into this case if the only information you need to track for each TreeView item is its name and a pointer-sized piece of data. You put the name in the TreeView item text and the other data in the lParam. This plan works great until you need to sort the items, and your sort comparison function wants access to both pieces of data.
The solution is to switch to a data model pattern. Allocate a structure for each TreeView item and put the string and additional data in that structure. (Alternatively, you could just be sneaky and have the structure be the HTREEITEM and the additional data. Then you can recover the string by using the TVM_GETITEM message.)
Bonus chatter: In theory, the TVM_SORTCHILDRENCB could have passed the HTREEITEMs to the callback. The callback could then use the HTREEITEM to obtain both the string and the lParam. I suspect this didn’t happen because most callback functions would just ask for the lParam from the HTREEITEM, TVM_SORTCHILDRENCB is doing you a favor and saving you a bunch of work by giving you the thing you probably wanted in the first place.
The post The classic TreeView control lets me sort by name or by lParam, but why not both? appeared first on The Old New Thing.
We compare past tense and present tense in fiction, exploring the advantages and disadvantages of each and asking the question: which works best for your story?
Different tenses suit different stories, certain genres, and various authors’ styles. The tense you choose should also suit the personality of your main viewpoint character.
The boy looked up. The girl with the butterfly tattoo on her wrist twisted on the lawn and smiled at him. Her hair spread out like spilt milk on the grass. He knew he loved her and he did not care if she knew. He wanted to carve her name into the clear sky that framed the edges of the park.
If you have a protagonist who thinks about what will happen next, who makes plans and considers risks, who is calculating, and driven by reason, the past tense would a good fit. Writing a story in past tense allows you to manipulate time, to reveal, and to conceal events.
Past-tense fiction creates a more subtle kind of suspense where we may know the outcome of the story but we want to know how and why we ended up there. This is good for more cerebral, reflective characters. This example can be used as a memory, layered with knowledge of how the story ends.
Great past-tense fiction allows readers who are more comfortable with the format to experience the story in a nuanced, thoughtful way.
The boy looks up. The girl with the butterfly tattoo on her wrist twists on the sun splattered lawn and smiles at him. Her hair spreads out like spilt milk on the grass. He’s lost and he knows she knows, but he doesn’t care. He wants to carve her name into the clear sky that frames the edges of the park.
If you have a protagonist who lives in the moment, who is impulsive, foolhardy/brave, and driven by emotions, the present tense could be the perfect vehicle. The present lets the reader see the character’s world in all its immediacy and allows him or her to experience the character’s growth and dilemmas as they happen.
Present-tense fiction creates a kind of suspense where no one knows the outcome. The second example could be written as a memoir or a coming-of-age story. There is a sense of anticipation and excitement that is not there when we use the past tense.
Great present-tense fiction allows writers to use texture – by truly engaging the senses – and explore possibilities, hopes, and fears in a uniquely present manner.
Memoirs, Young Adult, Literary Fiction, and many of the traditional genres are also being written in present tense.
The present tense is edgier. The reader has to agree to live the journey moment by moment with the characters. There is no guarantee that the story will even have an ending. It is easier to use unreliable narrators in the present tense. Many readers are uncomfortable with present tense stories.
You can use the past tense in any genre. It is the easiest way to tell a story, because it places it in a time frame. It has already happened and it gives the reader a sense of comfort that somebody has lived to tell the tale. Most of us, including many older readers, are happiest with this format.
Sometimes your choice of viewpoint dictates your choice of tense. Stories can be written in first, second, or third person. Read my post, Mastering Point Of View In Writing, to find out more.
Ultimately, neither past nor present tense is better. Different tenses suit different stories, genres, and writing styles. The right choice depends on the kind of experience you want to create and should also reflect the personality and perspective of your main viewpoint character.

by Amanda Patterson
© Amanda Patterson
If you enjoyed this blogger’s writing, read:
Top Tip: Sign up for our free daily writing links.
The post Past Tense Or Present Tense: Which Works Best For Your Story? appeared first on Writers Write.
The last day of Google I/O is over. I got to host a wonderful panel discussion, attending a couple of sessions, and meet some great people.
[blog] A new era for AI Search. These are some of the biggest changes to the Search experience that we’ve made in decades. More here.
[blog] Gemini for Science: AI experiments and tools for a new era of discovery. Some fantastic things here for those doing scientific work.
[blog] Introducing Managed Agents in the Gemini API. This is the next thing I get hands-on with. It’s a powerful way to create and run agents from a single API call. For enterprise users too!
[blog] Bring any idea to life: Google AI Studio at I/O 2026. Create Android apps? Integrate with assets in Workspace? Build on the go in a mobile app? Sheesh, Google AI Studio is becoming a real powerhouse.
[blog] We’re introducing new ways to design in real time with Stitch. People are already using this service en masse, and this will only increase that.
[blog] Introducing Agent Executor, Google’s distributed Agent Runtime. Don’t miss this one. It’s an open source engine for running agents anywhere.
[blog] 3 Hyped AI PM Archetypes + 1 We’re Missing. Instead of completely resetting the product manager role (or eliminating it entirely), maybe the right path is the fourth laid out here.
[article] GitHub scales back bug bounties, reminds users security is their responsibility too. Fair, but I hope we don’t lose effort and rewards for those doing truly meaningful security work!
[blog] The Flutter missing link: Why full-stack Dart changes everything. JavaScript was popular before Node came into the picture, but seemed to explode in usage after people could unify the front and back end. Might have the same impact on Flutter, thanks to Dart.
[blog] From Kubernetes Dev Setup to Production: What Actually Changes. What does it mean to be “production-grade”? This piece takes a good look at some of the things you’d need to do.
[article] Blackstone, Google launch new compute-as-a-service venture. A new TPU cloud is coming for people wanting compute-as-a-service.
Want to get this update sent to you every day? Subscribe to my RSS feed or subscribe via email below: