[Bug]: atuin 18.4 ignores `workspaces = true`

[peterjanes]

What did you expect to happen?

1. ~/.config/atuin/config.toml has workspaces = true
   1.1. I've never configured filter_mode or *_key_binding settings in ~/.config/atuin/config.toml.
2. Current directory contains a .git subdirectory
3. Pressing Ctrl+R starts in "WORKSPACE" mode, as in previous versions.

What happened?

Ctrl+R starts in "GLOBAL" mode. I have to press Ctrl+R three more times to get to "WORKSPACE" mode, toggling through "HOST" and "SESSION". This misbehaviour is consistent across Linux and Mac (I don't have Windows to test) and seems to have been introduced in 18.4.

Atuin doctor output

{
  "atuin": {
    "version": "18.4.0",
    "sync": {
      "cloud": true,
      "records": true,
      "auto_sync": true,
      "last_sync": "2025-01-09 18:04:29.278739 +00:00:00"
    },
    "sqlite_version": "3.46.0"
  },
  "shell": {
    "name": "bash",
    "default": "bash",
    "plugins": [
      "atuin",
      "bash-preexec"
    ],
    "preexec": "bash-preexec"
  },
  "system": {
    "os": "Darwin",
    "arch": "arm64",
    "version": "15.1",
    "disks": [
      {
        "name": "Macintosh HD",
        "filesystem": "apfs"
      },
      {
        "name": "Macintosh HD",
        "filesystem": "apfs"
      }
    ]
  }
}

{
  "atuin": {
    "version": "18.4.0",
    "sync": {
      "cloud": true,
      "records": true,
      "auto_sync": true,
      "last_sync": "2025-01-09 18:09:18.009209369 +00:00:00"
    },
    "sqlite_version": "3.46.0"
  },
  "shell": {
    "name": "bash",
    "default": "bash",
    "plugins": [
      "atuin",
      "bash-preexec"
    ],
    "preexec": "bash-preexec"
  },
  "system": {
    "os": "Fedora Linux",
    "arch": "x86_64",
    "version": "41",
    "disks": [
      {
        "name": "/dev/mapper/VolGroup00-LogVol00",
        "filesystem": "ext3"
      },
      {
        "name": "systemd-1",
        "filesystem": "autofs"
      },
      {
        "name": "/dev/sda1",
        "filesystem": "ext3"
      },
      {
        "name": "/dev/sdb1",
        "filesystem": "btrfs"
      },
      {
        "name": "/dev/sdc1",
        "filesystem": "fuseblk"
      }
    ]
  }
}

### Code of Conduct

- [X] I agree to follow this project's Code of Conduct

[MatthewNichols]

I seem to be having the same issue.

In case it is useful here is my Doctor output:

Atuin Doctor
Checking for diagnostics


Please include the output below with any bug reports or issues

{
  "atuin": {
    "version": "18.4.0",
    "sync": {
      "cloud": true,
      "records": true,
      "auto_sync": true,
      "last_sync": "2025-01-16 20:54:32.71286325 +00:00:00"
    },
    "sqlite_version": "3.46.0"
  },
  "shell": {
    "name": "zsh",
    "default": "zsh",
    "plugins": [
      "atuin"
    ],
    "preexec": "built-in"
  },
  "system": {
    "os": "Ubuntu",
    "arch": "x86_64",
    "version": "24.04",
    "disks": [
      {
        "name": "/dev/nvme0n1p2",
        "filesystem": "ext4"
      },
      {
        "name": "/dev/nvme0n1p2",
        "filesystem": "ext4"
      },
      {
        "name": "/dev/nvme0n1p1",
        "filesystem": "vfat"
      }
    ]
  }
}

[reedriley]

Possibly a regression from c5c5e9d?

[peterjanes]

Adding filter_mode = "workspace" did restore the behaviour I was looking for, so that does look like the culprit.

[MatthewNichols]

Adding filter_mode = "workspace" works for me also.

[plttn]

Unfortunately for me, my preferred behavior is control-r for host, and up arrow for workspace (acting as session if not in a git folder), and it isn't seemingly possible to replicate that at the moment.

[atuin-bot]

This issue has been mentioned on Atuin Community. There might be relevant details there:

https://forum.atuin.sh/t/use-workspace-for-up-key-or-directory-when-not-in-a-git-workspace/724/2

[c-alpha]

I just came across the forum post linked to by @atuin-bot above, and then found the present issue. I would like to achieve the same thing as the the OP of the forum post.

With these settings:

workspaces = true
[search]
filters = [ "workspace", "directory", "session", "global" ]

I get the following filter mode behaviour:

^R for the ... time	in a git repo	any other dir
first	workspace	global
second	directory	directory
third	session	session
fourth	global	global
fifth	workspace	directory
sixth	directory	session

And then the modes keep cycling through the same four (git repo) or three (other dir) values.

Inside a git repo, the behaviour is as expected per the value of search.filters.

In other directories, the skipping of the non applicable workspace seems to mess up the movement along the search.filters array, however.

That said, it might also seem worth considering, whether there should be two filter lists? search.filters sets the behaviour for ^R. But for ↑ I can set a single mode only. To get what the OP of the forum post, and my humble self would like to achieve:

I would like to keep ⌃R to use global search mode, but make the ↑ key to use workspace when possible, or directory when not.

it would seem useful to be able to specify a list of filters for shell_up_keybinding, too. As a hypothetical example, and for the sake of argument:

workspaces = true
[search]
filters = [ "global", "session", "workspace", "directory" ]
[shell_up_key_binding]
filters = [ "workspace", "directory" ]

[merc1031]

I wonder if my issue is related? #2700, either way i put out a small pr to try to address it #2703

edit:

@c-alpha with your config, i beleive the patch i am attempting above fits at least the ordering need.
I did not tackle multiple filter modes.

workspaces = true
[search]
filters = [ "workspace", "directory", "session", "global" ]

^R for the ... time	in a git repo	any other dir
first	workspace	directory
second	directory	session
third	session	global
fourth	global	directory
fifth	workspace	session
sixth	directory	global

|