Automatic Profile Switching: Switch back to previous profile when rule no longer matches

Current behaviour is to switch profile when a rule matches, but the profile is not returned to the Default (or previous) profile when the rule no longer matches.

Example:

Profile directory rule: /Users/example/git

~ example$ cd git
git example$ cd ~

Profile changes as expected when moving into the ~/git directory, but intuitively the new profile should no longer apply and the previous profile should be restored on leaving the directory (i.e., when the rule no longer matches). This is currently not the case.

The same example holds true for host- and user-based rules.

Interesting idea: so we'd treat APS as a stack of profiles, and when the current one is no longer matched we'd pop the stack until we find one that does (or run out of stack). Seems useful and also likely to break some use cases, but now's the time to break things :)

Milestone changed to Feature complete 3.0

That's exactly what I had in mind. If current behaviour is desired for some use cases, perhaps an option would be to add a checkbox to make the profile "sticky"; once a sticky profile is selected it won't be popped if the rule no longer matches (but presumably another profile would replace it if a different rule matched).

Effectively when a sticky profile is triggered, you'd replace the current profile stack with a new one containing only the sticky profile and it becomes the new "default" for that session.

Milestone changed to Feature Complete 3.1

Milestone changed to Ship 3.0

mentioned in issue #4225

I'm not sure how to handle this case:

You have a profile for host A and a profile for host B.

If you start on A and ssh to B, then ssh from B to A, the stack should look like: A B A

If you start on A and ssh to B and then log out of B we want the stack to look like: A

These cases are indistinguishable.

I don't want the stack to grow without bound, which could happen easily if you switch profiles based on path. This algorithm might work:

TryToSwitch(host, user, path)
  configuration = (host, user, path)
  existingMatch = stack.profileWithRuleMatchingConfiguration(configuration)
  if existingMatch
    while stack.peek() != existingMatch
      stack.pop()
    SetProfile(existingMatch)
  else
    newProfile = ProfileMatchingConfiguration(configuration)
    if newProfile
      stack.push(newProfile)
      SetProfile(newProfile)

Conceptually it makes sense to think of this as a stack, but does this need to be implemented as such? I'm not familiar with the implementation of profile switching, but could one simply re-evaluate all the profile rules when the environment changes? If a profile no longer matches, presumably the next profile in the (conceptual) "stack" would still match so that would become the active profile anyway.

As your example -

SSH to A.

Set profile for A.

SSH to B.

Profile A no longer matches. Set profile B.

SSH to A. Profile B no longer matches. Set profile A.

The exception being that if you've previously applied a sticky profile, that profile isn't replaced with a new one (perhaps unless the newly matching profile is also sticky)

SSH to A.

Set profile for A.

SSH to B.

Profile A no longer matches but is sticky. Profile B not sticky; Keep profile A.

SSH to C. Profile A no longer matches but is sticky. Profile C is also sticky. Set profile C.

On second thoughts, I'm fairly sure what I described above is exactly equivalent to your proposed algorithm in terms of behaviour. Is there any benefit in keeping a history of applied profiles in the stack over re-evaluating the rules? Presumably the rules have to be checked again every time the environment changes in some way anyway?

Could this be simplified to the below, for example?

onSessionStart {
  masterProfile = defaultProfile
}

onConfigurationChange {
  newProfile = masterProfile
  profiles.each(profile) {
    if profile.matches(configuration) {
      if (profile.sticky) {
        masterProfile = profile
      }
      newProfile = profile
      break
    }
  }
  setProfile(newProfile)
}

Edit: Updated to handle a non-sticky profile overriding a sticky on temporarily

The stack is a nice bit of polish when you make a temporary change to a session.

1. ssh example.com. APS triggers and now I'm my example.com profile.
2. I increase the font size with Cmd-+. Note that doing so does not modify the profile, but only changes the session's copy of the profile. Changes made with Edit > Edit Session… do this too.
3. ssh iterm2.com. APS triggers and now I'm on my iterm2.com profile.
4. Log out of iterm2.com.
5. Thanks to the stack, I return to the example.com profile modified to have a bigger font. If there were no stack, the font would revert to its default size. I think that violates the user's expectation.

This is implemented as of commit 1999c7a0.

I don't understand the problem the sticky bit solves. Can you give me an example?

The sticky profiles were in reference to my previous comment addressing your concerns that this may break some use cases; essentially a way to retain the previous behaviour.

Yes, of course. Well, let's see if we can get away without adding yet more complexity here. At least for the use cases that I have in mind this ought to work.

Status changed to closed

mentioned in issue #4363 (closed)

I, too, am strongly interested in the feature mentioned by Matt. Specifically, that changing (say) directories will trigger APS re-evaluation. That is, events will trigger the APS evaluation without reference to a stack, per se. If no specific rules match then the default profile should be activated.

Further, under this change, it would be good if the directory matching accepted wildcarding such that subdirectories will match a wildcard like "/Users/me/workspace/acme/*", but can be overridden by more specific directory specifications. Extending my example, setting an additional profile switch for "/Users/me/workspace/acme/documentation/admin/" could override the wildcard when going to this specific directory. Specificity wins.

I find I'm unable to use the switching in it's current form. (But I think that iTerm is fantastic overall - don't get me wrong)

Thanks for reading, and cheers, S t u a r t .

@s5b I have a change to support wildcard directories in the works. It sounds like that's not sufficient for your case; can you give me an example of how?

After thinking about it some more I'm pretty sure stickiness will be really useful, so I've added it and wildcard paths in commit 5edd6291.

@gnachman Thanks for your interest and reply.

The following is the kind of scenario I'm thinking about:

Following the format promoted by ant and gradle (amongst others):

* matches a single directory; ** matches zero or more directories.

Given the following directory path templates:

1. /Users/me/workspace/acme/**
2. /Users/me/workspace/acme/build/bin
3. /Users/**/data/**
4. /**/lib
5. /usr/*

When I change to the following directory I match the directory path template:

/Users/me                                    | (default)
/Users/me/workspace/acme                     | 1.
/Users/me/workspace/acme/build/bin           | 2.
/Users/me/workspace/acme/build/bin/ext       | 1.
/Users/me/workspace/acme/scenarios/data/full | 1.(more specific than 3)
/Users/other/projects/data/tuesday           | 3.
/Users/me/workspace/acme/lib                 | 1.
/usr/local/lib                               | 4.
/Applications/myApp/content/lib              | 4.
/usr/bin                                     | 5.
/usr/local                                   | (default)```

Looks like we've got everything you need except the * vs ** distinction. Not sure how critical that is though.

@gnachman Thanks. I'll check it out, and let you know.