Changing Folders Quickly

[flatcap]

This started with an IRC user who wanted to <change-folder>, but found that typing + or = was awkward.
They wanted to just type a folder name.

Unfortunately this doesn't work because <change-folder> is effectively working in the "root directory".

My first idea was a <change-folder-relative> command.
This would allow changing folder to ../work etc.
It's a bit more efficient, but a bit clunky.

Then I remembered the CDPATH environment variable in Bash (and others).

Imagine a NeoMutt config variable:

# Search here, parent, account root
set folder_path = ". .. /"

To be really effective, the auto-completion would have to be aware of $folder_path.

[jindraj]

I'm not sure whether I'd be the target audience for this feature, so please take my words with grain of salt.
In case there are others interested in the feature and are not using only more traditional mailbox types but notmuch (which at least in my case brings the need of named-mailboxes to the scene), then it would be awesome to have this working with them also. Based on mailbox label and not only the mailbox itself.

Example:

"GMail/INBOX"                 "notmuch://?query=is:inbox AND NOT (query:lists OR query:junk OR query:others OR is:work)" \
"GMail/work/                  "notmuch://?query=is:work" \
"GMail/work/confluence"       "notmuch://?query=query:confluence" \
"GMail/work/ticketing"        "notmuch://?query=is:ticketing" \
"GMail/work/ticketing/FS"     "notmuch://?query=is:ticketing query:ticketing_freshservice" \
"GMail/work/ticketing/Jira"   "notmuch://?query=is:ticketing query:ticketing_jira" \
"archives"                    "notmuch://?query=NOT query:junk" \
"archives/today"              "notmuch://?query=NOT query:junk AND date:today" \
"archives/yesterday"          "notmuch://?query=NOT query:junk AND date:yesterday" \
"archives/this week"          "notmuch://?query=NOT query:junk AND date:this_week" \
"archives/last week"          "notmuch://?query=NOT query:junk AND date:last_week" \
"archives/this month"         "notmuch://?query=NOT query:junk AND date:this_month" \
"archives/last month"         "notmuch://?query=NOT query:junk AND date:last_month" \
"archives/this year"          "notmuch://?query=NOT query:junk AND date:this_year" \
"archives/last year"          "notmuch://?query=NOT query:junk AND date:last_year" \

Executing <change-folder-relative>../ticketing<enter> while having GMail/work/confluence mailbox opened would take us into GMail/work/ticketing. Perhaps all mailbox labes would need to be prefixed with / to "simulate" filesystem like tree pattern.

The reason is apparent, because the mailbox definition isn't necessarily prefixed with the same string as in the case of IMAP/maildir, but the mailbox label of named-mailboxes can be. Notmuch mailboxes can be defined by large amount of information: tags, dates, subjects, sender adress, adressees, mimetypes, notmuch defined queries or even custom notmuch defined headers present in the messages.

[flatcap]

Hmm... interesting

<change-folder-relative> would be hard without a real tree to navigate.
We could create one, but there's no requirement for the labels to be coherent.

$folder_path would be simpler.
Rather than using . and .., you could specify: GMail/work and archives

Though that wouldn't be as good if there were duplicate subfolders:

home/one
home/two
home/three
work/one
work/two    # Current folder
work/three

The result <change-folder>three would depend on $folder_path, not your current folder.

[thyssentishman]

What about being able to pipe all active mailboxes to an external command? This would allow the usage of tools like fzf or dmenu and the output could be captured and composed into a <change-folder><selection>

[flatcap]

Yes, we could do.
It'd be a little visually disruptive.

We have something, at an early stage of development, in #3913
The advantage of re-implenting fzf is that we could do richer searchers.

fzf works well with a list -- a single column of data.
If we wanted to use it with multiple columns of data, e.g. the Index,
we have two choices:

• Don't format -- like dumping a csv file -- an illegible mess
• Format into columns and risk truncated fields -- making searching unreliable

[thyssentishman]

fzf works well with a list -- a single column of data.

There are some fzf-powered programs like ytfzf (see screenshot below) that make use of columns (pre-formatted with column or awk for example). I could see this being useful for filtering e.g. the index based on {from, to, subject, date}. However AFAIK, you can not limit the search to one of this columns, is that what you want to do?

[flatcap]

That looks quite good, as a long as we can hide a unique id somewhere.
fzf and friends work by returning the matched string -- NeoMutt will have to work out which Email that refers to.

you can not limit the search to one of this columns, is that what you want to do?

For the simple case, no.
We'd just want a fuzzy match against the entire line.

Looking further ahead, perhaps.
Imagine being able to live-limit using NeoMutt patterns.

[thyssentishman]

That looks quite good, as a long as we can hide a unique id somewhere.
fzf and friends work by returning the matched string -- NeoMutt will have to work out which Email that refers to.

With fzf --with-nth you can specify which columns you want to have displayed. However this doesn't affect the output and the full string is returned. So for example, if we append the unique id as the last column of the index and we pipe it to fzf --with-nth=..-2, the unique id won't be visible to the user, but will be returned (with all other columns as well) when a selection is made. Then we would just have to parse the last column.

We'd just want a fuzzy match against the entire line.

Was just reading fzf's man page for the above mentioned flag and found about about the --nth flag which allows to limit the search scope to a set of columns. With this we could avoid matching the hidden unique id mentioned above.

Both of these flags depend on --delimiter which determines how the columns are split.

[flatcap]

hmm... That's sounding quite promising!

[ossilator]

this is calling for an incremental multi-search, where you just enter several partial strings which are AND-ed to filter down a selection. such a UI really only works with a drop-down, so it doesn't fit very well with mutt's traditional one-line input layout. the sidebar is inherently more "menu-like", so it fits better there. but the change-folder command also has a browser mode where this would fit.

[flatcap]

Yeah, live filtering (limiting) in the Browser and Index would be very useful.
The key-handling code just needs a bit more refactoring.