[Proposal] Call UpdateJumplist only if the settings changed

[lhecker]

"You can't just detect whether the settings file changed." Haha, file hash goes brrr.

---

Jokes aside, what do you all think about this? Will this work?

This would be part of #5907 and depends on #13686.

Validation Steps Performed

• Seems to work as expected in my limited testing ✅

[zadjii-msft]

Other thought from teams:

• on a first ever launch, this will still generate the jumplist as we're creating the window, right? Like, we still want to defer that until after StartupState::Initialized

[DHowett]

What happens if the user restarts their PC, but the settings file hasn't changed? Does the shell remember their jumplist from last time?

Jumplists are durable across restarts, for sure.

[lhecker]

What happens if the user restarts their PC, but the settings file hasn't changed? Does the shell remember their jumplist from last time?

I tested it and it works fine.

on a first ever launch, this will still generate the jumplist as we're creating the window, right? Like, we still want to defer that until after StartupState::Initialized

As mentioned "offline", I'm not convinced that this will bring noticeable improvements. One reason being that an AV like Windows Defender will have a much greater impact on us on first launch than anything we do ourselves.

But it is a convincing argument! Unfortunately I got a bit stumped now on how to best implement this... On first launch CascadiaSettings::LoadAll will write the initial settings.json to disk which will trigger AppLogic::_ReloadSettings. This happens before the UI is fully interactive, since settings are required to be present at launch and the reload is scheduled via the Dispatcher(). Even at low priority this reload happens before full interactivity is reached. Should we build some sort of system to delay _ReloadSettings during launch? I wasn't sure it would be considered worth the effort... it would require us to block a background thread with a semaphore or similar.

[zadjii-msft]

Okay idea:

In AppLogic::_ReloadSettings, we check if we're in _startupState >= Initialized.

• If we are, cool, we're past the first paint. Kick off the bg thread to update the jumplist, it's fine.
• If we aren't, we're still in the initial launch. Register a handler for page.Initialized, and then we can revoke that handler once it fires. Once we get to Initialized, the window is fully ready to go.

Thoughts?

[lhecker]

I've come up with an easier approach which doesn't need to check _startupState. Since the PR is a bit different now, I've rebased it on main.

[github-actions[bot]]

@check-spelling-bot Report

:red_circle: Please review

See the :open_file_folder: files view or the :scroll:action log for details.

Unrecognized words (1)

approximitely

To accept :heavy_check_mark: these unrecognized words as correct, run the following commands

... in a clone of the [email protected]:microsoft/terminal.git repository on the dev/lhecker/5907-jumplist-caching branch (:information_source: how do I use this?):

update_files() {
perl -e '
my $new_expect_file=".github/actions/spelling/expect/1b3d004782817ee6f36e37401853c2d25703976e.txt";
use File::Path qw(make_path);
use File::Basename qw(dirname);
make_path (dirname($new_expect_file));
open FILE, q{<}, $new_expect_file; chomp(my @words = <FILE>); close FILE;
my @add=qw('"$patch_add"');
my %items; @items{@words} = @words x (1); @items{@add} = @add x (1);
@words = sort {lc($a)."-".$a cmp lc($b)."-".$b} keys %items;
open FILE, q{>}, $new_expect_file; for my $word (@words) { print FILE "$word\n" if $word =~ /\w/; };
close FILE;
system("git", "add", $new_expect_file);
'
}

comment_json=$(mktemp)
curl -L -s -S \
-H "Content-Type: application/json" \
"https://api.github.com/repos/microsoft/terminal/issues/comments/1215021301" > "$comment_json"
comment_body=$(mktemp)
jq -r ".body // empty" "$comment_json" | tr -d "\\r" > $comment_body
rm $comment_json

patch_add=$(perl -e '$/=undef; $_=<>; if (m{Unrecognized words[^<]*</summary>\n*```\n*([^<]*)```\n*</details>$}m) { print "$1" } elsif (m{Unrecognized words[^<]*\n\n((?:\w.*\n)+)\n}m) { print "$1" };' < "$comment_body")

update_files
rm $comment_body
git add -u

Available dictionaries could cover words not in the dictionary

This includes both expected items (2868) from .github/actions/spelling/expect/alphabet.txt .github/actions/spelling/expect/expect.txt .github/actions/spelling/expect/web.txt and unrecognized words (1)

cspell:filetypes/filetypes.txt (337) covers 36 of them cspell:django/django.txt (2342) covers 23 of them cspell:html/html.txt (542) covers 22 of them cspell:aws/aws.txt (1485) covers 20 of them cspell:fullstack/fullstack.txt (181) covers 19 of them

Consider adding them using (in .github/workflows/spelling2.yml):

      with:
        extra_dictionaries:
          cspell:filetypes/filetypes.txt
          cspell:django/django.txt
          cspell:html/html.txt
          cspell:aws/aws.txt
          cspell:fullstack/fullstack.txt

To stop checking additional dictionaries, add:

      with:
        check_extra_dictionaries: ''

:pencil2: Contributor please read this

By default the command suggestion will generate a file named based on your commit. That's generally ok as long as you add the file to your commit. Someone can reorganize it later.

:warning: The command is written for posix shells. If it doesn't work for you, you can manually add (one word per line) / remove items to expect.txt and the excludes.txt files.

If the listed items are:

• ... misspelled, then please correct them instead of using the command.
• ... names, please add them to .github/actions/spelling/allow/names.txt.
• ... APIs, you can add them to a file in .github/actions/spelling/allow/.
• ... just things you're using, please add them to an appropriate file in .github/actions/spelling/expect/.
• ... tokens you only need in one place and shouldn't generally be used, you can add an item in an appropriate file in .github/actions/spelling/patterns/.

See the README.md in each directory for more information.

:microscope: You can test your commits without appending to a PR by creating a new branch with that extra change and pushing it to your fork. The check-spelling action will run in response to your push -- it doesn't require an open pull request. By using such a branch, you can limit the number of typos your peers see you make. :wink:

:clamp: If the flagged items are false positives

If items relate to a ...

• binary file (or some other file you wouldn't want to check at all).

  Please add a file path to the excludes.txt file matching the containing file.

  File paths are Perl 5 Regular Expressions - you can test yours before committing to verify it will match your files.

  ^ refers to the file's path from the root of the repository, so ^README\.md$ would exclude README.md (on whichever branch you're using).

• well-formed pattern.

  If you can write a pattern that would match it, try adding it to the patterns.txt file.

  Patterns are Perl 5 Regular Expressions - you can test yours before committing to verify it will match your lines.

  Note that patterns can't match multiline strings.

[ghost]

:tada:Windows Terminal Preview v1.16.252 has been released which incorporates this pull request.:tada:

Handy links:

• Release Notes
• Store Download