[GH-ISSUE #45] [Question] Workflow to search content in cache using external tools

kerem commented

2026-03-03 01:19:19 +03:00

Owner

Originally created by @Kabouik on GitHub (Jun 7, 2020).
Original GitHub issue: https://github.com/d99kris/nmail/issues/45

Originally assigned to: @d99kris on GitHub.

I was investigating how I could search for strings in my cached emails using third party tools until nmail has a built-in search. Of course this wouldn't allow using the search result to do any actions like forward, reply, move or delete, but at least that would be enough to find some information I'm looking for in a message.

With some scripting-fu, it should be possible to combine fzf fuzzy search with grep or ripgrep and open a new terminal to search for a string in all files of a given directory. This could go well with #42 with a custom key to call this script directly from nmail and show the new terminal to enter the string and see the results. Another way in my case (but that would be very specific to my workflow and the softwares I use) would be to open a new terminal running nnn file manager in the imap folder, and then use a plugin script to do the fuzzy search on content directly in nnn with instant text previsualization:

Here I just selected the .eml file manually, the idea would be to fuzzy search on content while in the folder. nnn already has fuzzy search built-in, but only on file names. But anyway, just an example, it's way too specific to make it the normal workflow.

There's an extra difficulty if cache encrypting is set to 1, because then we need also something like openssl enc -d -aes-256-cbc -md sha1 -in ~/.nmail/cache/imap/* prior to the string search.

This would be very hacky and shouldn't by any mean be something recommended or endorsed by nmail, but I'm just asking candidly in case you would have some ideas on how to do such a thing. While being unofficial, hacky, and dependent on other tools, it could have a use until nmail can search and show emails by itself.

Originally created by @Kabouik on GitHub (Jun 7, 2020). Original GitHub issue: https://github.com/d99kris/nmail/issues/45 Originally assigned to: @d99kris on GitHub. I was investigating how I could search for strings in my cached emails using third party tools until `nmail` has a built-in search. Of course this wouldn't allow using the search result to do any actions like forward, reply, move or delete, but at least that would be enough to find some information I'm looking for in a message. With some scripting-fu, it should be possible to combine `fzf` fuzzy search with `grep` or `ripgrep` and open a new terminal to search for a string in all files of a given directory. This could go well with #42 with a custom key to call this script directly from `nmail` and show the new terminal to enter the string and see the results. Another way in my case (but that would be very specific to my workflow and the softwares I use) would be to open a new terminal running `nnn` file manager in the ` imap` folder, and then use a plugin script to do the fuzzy search on content directly in `nnn` with instant text previsualization: ![ss-2020-06-07_162949](https://user-images.githubusercontent.com/7107523/83971551-65533200-a8cb-11ea-8352-e25a5f035fa5.png) Here I just selected the .eml file manually, the idea would be to fuzzy search on content while in the folder. `nnn` already has fuzzy search built-in, but only on file names. But anyway, just an example, it's way too specific to make it the normal workflow. There's an extra difficulty if cache encrypting is set to `1`, because then we need also something like `openssl enc -d -aes-256-cbc -md sha1 -in ~/.nmail/cache/imap/*` prior to the string search. This would be very hacky and shouldn't by any mean be something recommended or endorsed by `nmail`, but I'm just asking candidly in case you would have some ideas on how to do such a thing. While being unofficial, hacky, and dependent on other tools, it could have a use until `nmail` can search and show emails by itself.

kerem referenced this issue

2026-03-03 01:19:19 +03:00

[GH-ISSUE #47] [Enhancement] Enhancements for file and contact selection dialogs #45

kerem closed this issue

2026-03-03 01:19:20 +03:00

kerem commented

2026-03-03 01:19:20 +03:00

Author

Owner

@Kabouik commented on GitHub (Jun 7, 2020):

rga doesn't sound too bad, and it can be integrated with fzf, which avoids cluttering the terminal when there are many hits.

@Kabouik commented on GitHub (Jun 7, 2020): [`rga`](https://phiresky.github.io/blog/2019/rga--ripgrep-for-zip-targz-docx-odt-epub-jpg/) doesn't sound too bad, and it can be integrated with `fzf`, which avoids cluttering the terminal when there are many hits.

kerem commented

2026-03-03 01:19:20 +03:00

Author

Owner

@Kabouik commented on GitHub (Jun 8, 2020):

See a short, basic, example with nmail here. Here I opened the tmux pane in advance for the Asciinema cast, but the idea would be to open a new terminal or pane only when searching.

Not ideal, of course, but useable until a more elegant solution is implemented. Also, it is about 27294 faster than my other email clients, and the ability to open the file in $EDITOR is not bad.

Problems I can think of:

ripgrep and fzf dependencies; they are widely available and ripgrep speed should make it a standard at some point, but that contradicts nmail minimal style.
Relying on third party is not necessarily a good idea.
Not particularly straightforward to configure and explain to users.
It would be much better to scrap the file list at the bottom and instead show a set of headers (sender, date, object), and show only the body in the preview window at the top. I'm sure that would be possible with some sed black magic but I don't know how to do it.
Not combined with encrypted files yet (but nesting the decrypt command and the search function does not seem unfeasible, and pass could be used to convey the password?).
And yeah, no online search as you mentioned below.

Anyway, that is not meant to be an official solution, but thought it might be useful, and/or give ideas for the official implementation (no pressure).

For reference, here are the two commands I set up in ~/.bashrc to search in messages or just in headers:


# rga-fzf for nmail
fzfnmail() {
	NMAIL_DIR='~/.nmail'
	RG_PREFIX="rga --files-with-matches --smart-case --multiline --max-depth=5 -g '*.eml'"
	local file
	file="$(
		FZF_DEFAULT_COMMAND="$RG_PREFIX '$1' '$NMAIL_DIR'" \
			fzf --sort --preview="[[ ! -z {} ]] && rga --pretty --context 5 {q} {}" \
				--phony -q "$1" \
				--bind "change:reload:$RG_PREFIX {q}" \
				--preview-window="up:70%:wrap" \
				--multi \
				--keep-right
	)" &&
	echo "opening $file" &&
	$EDITOR "$file"
}

fzfnmail-headers() {
	NMAIL_DIR='~/.nmail'
	RG_PREFIX="rga --files-with-matches --smart-case --multiline --max-depth=5 -g '*.hdr'"
	local file
	file="$(
		FZF_DEFAULT_COMMAND="$RG_PREFIX '$1' '$NMAIL_DIR'" \
			fzf --sort --preview="[[ ! -z {} ]] && rga --pretty --context 5 {q} {}" \
				--phony -q "$1" \
				--bind "change:reload:$RG_PREFIX {q}" \
				--preview-window="up:70%:wrap" \
				--multi
	)" &&
	echo "opening $file" &&
	$EDITOR "$file"
}

@Kabouik commented on GitHub (Jun 8, 2020): See a short, basic, example with `nmail` [here](https://asciinema.org/a/sDnGV09aTjcQOQtu5o41MB7Je). Here I opened the `tmux` pane in advance for the Asciinema cast, but the idea would be to open a new terminal or pane only when searching. Not ideal, of course, but useable until a more elegant solution is implemented. Also, it is about 27294 faster than my other email clients, and the ability to open the file in `$EDITOR` is not bad. Problems I can think of: - `ripgrep` and `fzf` dependencies; they are widely available and `ripgrep` speed should make it a standard at some point, but that contradicts `nmail` minimal style. - Relying on third party is not necessarily a good idea. - Not particularly straightforward to configure and explain to users. - It would be much better to scrap the file list at the bottom and instead show a set of headers (sender, date, object), and show only the body in the preview window at the top. I'm sure that would be possible with some `sed` black magic but I don't know how to do it. - Not combined with encrypted files yet (but nesting the decrypt command and the search function does not seem unfeasible, and `pass` could be used to convey the password?). - And yeah, no online search as you mentioned below. Anyway, that is not meant to be an official solution, but thought it might be useful, and/or give ideas for the official implementation (no pressure). For reference, here are the two commands I set up in `~/.bashrc` to search in messages or just in headers: ```bash # rga-fzf for nmail fzfnmail() { NMAIL_DIR='~/.nmail' RG_PREFIX="rga --files-with-matches --smart-case --multiline --max-depth=5 -g '*.eml'" local file file="$( FZF_DEFAULT_COMMAND="$RG_PREFIX '$1' '$NMAIL_DIR'" \ fzf --sort --preview="[[ ! -z {} ]] && rga --pretty --context 5 {q} {}" \ --phony -q "$1" \ --bind "change:reload:$RG_PREFIX {q}" \ --preview-window="up:70%:wrap" \ --multi \ --keep-right )" && echo "opening $file" && $EDITOR "$file" } fzfnmail-headers() { NMAIL_DIR='~/.nmail' RG_PREFIX="rga --files-with-matches --smart-case --multiline --max-depth=5 -g '*.hdr'" local file file="$( FZF_DEFAULT_COMMAND="$RG_PREFIX '$1' '$NMAIL_DIR'" \ fzf --sort --preview="[[ ! -z {} ]] && rga --pretty --context 5 {q} {}" \ --phony -q "$1" \ --bind "change:reload:$RG_PREFIX {q}" \ --preview-window="up:70%:wrap" \ --multi )" && echo "opening $file" && $EDITOR "$file" } ```

kerem commented

2026-03-03 01:19:20 +03:00

Author

Owner

@d99kris commented on GitHub (Jun 9, 2020):

Thanks for sharing, this is very cool 👍

Yeah, email search is the one major feature that needs to be added next. I would not rule out using an external tool (they are likely more performant than I can implement), however - I'd like to also support searching encrypted cache, as well as IMAP search (i.e. not cached messages) - and optimally a solution would seamlessly encompass all these.

But yeah it's good inspiration to see this, and possibly it can be enabled within nmail with #42. I generally don't like navigating emails using panes, but I can see the usefulness when navigating search results. Will see if I can incorporate these concepts in the internal search support.

I've started a little on the search functionality, but so far only the IMAP side. Next is the UI, and lastly I was planning to add the local cache search.

@d99kris commented on GitHub (Jun 9, 2020): Thanks for sharing, this is very cool 👍 Yeah, email search is the one major feature that needs to be added next. I would not rule out using an external tool (they are likely more performant than I can implement), however - I'd like to also support searching encrypted cache, as well as IMAP search (i.e. not cached messages) - and optimally a solution would seamlessly encompass all these. But yeah it's good inspiration to see this, and possibly it can be enabled within nmail with #42. I generally don't like navigating emails using panes, but I can see the usefulness when navigating search results. Will see if I can incorporate these concepts in the internal search support. I've started a little on the search functionality, but so far only the IMAP side. Next is the UI, and lastly I was planning to add the local cache search.

kerem commented

2026-03-03 01:19:21 +03:00

Author

Owner

@Kabouik commented on GitHub (Jun 9, 2020):

Totally, like the simplicity of nmail and using panes would turn it into something else really. It doesn't bother me for searches because they are only punctual, I only call the extra pane/window when necessary (which the asciicast doesn't show because it cannot record new panes, I had to open it in advance). But I suppose if it was directly embedded in nmail, it would work too. Note that the functions I used above are not perfect, they don't search for new keywords if you delete one and then type a new one in the fzf interface. Yet this should, fzf definitely supports that; this is just me failing at coding the functions properly.

If the search occurs in the main window, it is important however to provide a way to get back to the current screen afterwards when closing the search. One reason for that is a frequent reason to search for old emails is we are searching for detailed information in a previous discussion when composing a new message, so it should be made easy to multitask between the current screen and the search screen/search results.

Regarding the underlying tools, ripgrep is blazzing fast and fzf allows some nice, dynamic display as you type. Their combination makes for something that is user friendly, visually appealing (and configurable) and very efficient at the same time. Those who master regex could even use their mighty powers. rga would allow searching in attachments too, but I suppose this would span a bit beyond the scope of nmail, and it would only work if people store their attachments in the nmail folder anyway because we I don't think we want nmail search to drive into other folders.

I don't know how that could integrate with IMAP search, but that's a good point I forgot indeed. I set nmail to automatically fetch headers by default and .eml when opening the messages, which is why I came up with two different search commands. Searching headers in my cache allows searching in all my emails, but of course it won't find matches in message bodies. I also used to use cache encryption but disabled it for the tests. However I don't think this would be incompatible, the decrypt command could probably be nested in the search function and the passwoord fed to it while nmail is running by pass or some other tools (?).

I'm looking forward to seeing how this will work in nmail, but I understand that it's a huge milestone which may take some time (which is why I went into local hacks in the mean time).

@Kabouik commented on GitHub (Jun 9, 2020): Totally, like the simplicity of `nmail` and using panes would turn it into something else really. It doesn't bother me for searches because they are only punctual, I only call the extra pane/window when necessary (which the asciicast doesn't show because it cannot record new panes, I had to open it in advance). But I suppose if it was directly embedded in `nmail`, it would work too. Note that the functions I used above are not perfect, they don't search for new keywords if you delete one and then type a new one in the fzf interface. Yet this should, fzf definitely supports that; this is just me failing at coding the functions properly. If the search occurs in the main window, it is important however to provide a way to get back to the current screen afterwards when closing the search. One reason for that is a frequent reason to search for old emails is we are searching for detailed information in a previous discussion when composing a new message, so it should be made easy to multitask between the current screen and the search screen/search results. Regarding the underlying tools, `ripgrep` is blazzing fast and `fzf` allows some nice, dynamic display as you type. Their combination makes for something that is user friendly, visually appealing (and configurable) and very efficient at the same time. Those who master regex could even use their mighty powers. `rga` would allow searching in attachments too, but I suppose this would span a bit beyond the scope of `nmail`, and it would only work if people store their attachments in the `nmail ` folder anyway because we I don't think we want `nmail` search to drive into other folders. I don't know how that could integrate with IMAP search, but that's a good point I forgot indeed. I set `nmail` to automatically fetch headers by default and `.eml` when opening the messages, which is why I came up with two different search commands. Searching headers in my cache allows searching in all my emails, but of course it won't find matches in message bodies. I also used to use cache encryption but disabled it for the tests. However I don't think this would be incompatible, the decrypt command could probably be nested in the search function and the passwoord fed to it while `nmail` is running by `pass` or some other tools (?). I'm looking forward to seeing how this will work in `nmail`, but I understand that it's a huge milestone which may take some time (which is why I went into local hacks in the mean time).

kerem commented

2026-03-03 01:19:21 +03:00

Author

Owner

@d99kris commented on GitHub (Aug 2, 2020):

FYI - I've now implemented basic email search functionality within nmail in commit 6b37a3b.

I have not looked any further into enabling search via external tools, but I just wanted to let you know about the built-in search added.

@d99kris commented on GitHub (Aug 2, 2020): FYI - I've now implemented basic email search functionality within `nmail` in commit 6b37a3b. I have not looked any further into enabling search via external tools, but I just wanted to let you know about the built-in search added.

kerem commented

2026-03-03 01:19:21 +03:00

Author

Owner

@Kabouik commented on GitHub (Aug 4, 2020):

Awesome. Great work, that's a huge milestone. I tried it a bit with some dummy searches and it seems to work pretty well. It can only search emails in messages that are already fetched at the moment, not from IMAP yet, is that correct?

I see there are multiple new features and options in main.conf too, I need to add them to my configuration files. Cool stuff.

@Kabouik commented on GitHub (Aug 4, 2020): Awesome. Great work, that's a huge milestone. I tried it a bit with some dummy searches and it seems to work pretty well. It can only search emails in messages that are already fetched at the moment, not from IMAP yet, is that correct? I see there are multiple new features and options in `main.conf` too, I need to add them to my configuration files. Cool stuff.

kerem commented

2026-03-03 01:19:21 +03:00

Author

Owner

@d99kris commented on GitHub (Aug 4, 2020):

Yes, it's only searching locally cached emails at the moment. I've added a command for full sync s so the user can trigger a syncing of all emails at run-time.

I have IMAP search implementation in progress, but I haven't yet figured out how to present it to users. Local search is magnitudes faster so I don't want to slow that down. I guess one option is to just have different keyboard shortcut for local vs. IMAP search. I'll need to think about this and do some testing before I can add IMAP search.

On 2020-08-04 17:28 Kabouik notifications@github.com wrote:

Awesome. Great work, that's a huge milestone. I tried it a bit with
some dummy searches and it seems to work pretty well. It can only
search emails in messages that are already fetched at the moment, not
from IMAP yet, is that correct?

--
You are receiving this because you were assigned.
Reply to this email directly or view it on GitHub:
https://github.com/d99kris/nmail/issues/45#issuecomment-668489694

@d99kris commented on GitHub (Aug 4, 2020): Yes, it's only searching locally cached emails at the moment. I've added a command for full sync `s` so the user can trigger a syncing of all emails at run-time. I have IMAP search implementation in progress, but I haven't yet figured out how to present it to users. Local search is magnitudes faster so I don't want to slow that down. I guess one option is to just have different keyboard shortcut for local vs. IMAP search. I'll need to think about this and do some testing before I can add IMAP search. On 2020-08-04 17:28 Kabouik <notifications@github.com> wrote: > Awesome. Great work, that's a huge milestone. I tried it a bit with > some dummy searches and it seems to work pretty well. It can only > search emails in messages that are already fetched at the moment, not > from IMAP yet, is that correct? > > -- > You are receiving this because you were assigned. > Reply to this email directly or view it on GitHub: > https://github.com/d99kris/nmail/issues/45#issuecomment-668489694 >

kerem referenced this issue

2026-03-03 01:19:21 +03:00

[GH-ISSUE #47] [Enhancement] Enhancements for file and contact selection dialogs #45

kerem commented

2026-03-03 01:19:21 +03:00

Author

Owner

@Kabouik commented on GitHub (Aug 4, 2020):

I thought that new command was related to this, yes. Already triggered a full-sync after noticing search was limited to cached emails.

Sounds good. Maybe you could use some kind of decision tree if it is detected that not all emails have been cached? For instance, user initiating a search with an account with partially cached messages would get this in the status bar: "1234 emails are not cached yet. Search [o]nline with IMAP (slow), update cache with a full [s]ynchronization, or [i]gnore and search in cached emails only?".

I am not sure how to deal with "prefetch_level=0|1" though, as getting this prompt all the time would get old really quick. Or there could be a "search_preset=online|offline|update-cache" option, but perhaps there is no need to clutter main.conf with an additional option if IMAP search can be implemented in a different way.

[Edit] Also not sure if the cache check should be per folder or per account. Maybe this is a question for a future version when/if the search function gets some folder options.

On 2020-08-04 16:49 Kristofer Berggren notifications@github.com wrote:

Yes, it's only searching locally cached emails at the moment. I've added a command for full sync s so the
user can trigger a syncing of all emails at run-time.

I have IMAP search implementation in progress, but I haven't yet figured out how to present it to users.
Local search is magnitudes faster so I don't want to slow that down. I guess one option is to just have
different keyboard shortcut for local vs. IMAP search. I'll need to think about this and do some testing
before I can add IMAP search.

On 2020-08-04 17:28 Kabouik notifications@github.com wrote:

Awesome. Great work, that's a huge milestone. I tried it a bit with
some dummy searches and it seems to work pretty well. It can only
search emails in messages that are already fetched at the moment, not
from IMAP yet, is that correct?

--
You are receiving this because you were assigned.
Reply to this email directly or view it on GitHub:
https://github.com/d99kris/nmail/issues/45#issuecomment-668489694

--
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/d99kris/nmail/issues/45#issuecomment-668642105

@Kabouik commented on GitHub (Aug 4, 2020): I thought that new command was related to this, yes. Already triggered a full-sync after noticing search was limited to cached emails. Sounds good. Maybe you could use some kind of decision tree if it is detected that not all emails have been cached? For instance, user initiating a search with an account with partially cached messages would get this in the status bar: "1234 emails are not cached yet. Search [o]nline with IMAP (slow), update cache with a full [s]ynchronization, or [i]gnore and search in cached emails only?". I am not sure how to deal with "prefetch_level=0|1" though, as getting this prompt all the time would get old really quick. Or there could be a "search_preset=online|offline|update-cache" option, but perhaps there is no need to clutter `main.conf` with an additional option if IMAP search can be implemented in a different way. [Edit] Also not sure if the cache check should be per folder or per account. Maybe this is a question for a future version when/if the search function gets some folder options. On 2020-08-04 16:49 Kristofer Berggren <notifications@github.com> wrote: > Yes, it's only searching locally cached emails at the moment. I've added a command for full sync `s` so the > user can trigger a syncing of all emails at run-time. > > I have IMAP search implementation in progress, but I haven't yet figured out how to present it to users. > Local search is magnitudes faster so I don't want to slow that down. I guess one option is to just have > different keyboard shortcut for local vs. IMAP search. I'll need to think about this and do some testing > before I can add IMAP search. > > On 2020-08-04 17:28 Kabouik <notifications@github.com> wrote: > > > Awesome. Great work, that's a huge milestone. I tried it a bit with > > some dummy searches and it seems to work pretty well. It can only > > search emails in messages that are already fetched at the moment, not > > from IMAP yet, is that correct? > > > > -- > > You are receiving this because you were assigned. > > Reply to this email directly or view it on GitHub: > > https://github.com/d99kris/nmail/issues/45#issuecomment-668489694 > > > > -- > You are receiving this because you authored the thread. > Reply to this email directly or view it on GitHub: > https://github.com/d99kris/nmail/issues/45#issuecomment-668642105 >

kerem commented

2026-03-03 01:19:21 +03:00

Author

Owner

@Kabouik commented on GitHub (Aug 11, 2020):

Can you tell how emails matching the search term are sorted? I noticed it's not sorted by date, so I thought it could be by relevance first and date second. I tested it by searching for a keyword that appears in a list of automatic emails (all identical), and yet the search results are still ordered by something else than date despite the identical content. Anyway I don't think relevance would be possible if xapian only looks for exact matches.

@Kabouik commented on GitHub (Aug 11, 2020): Can you tell how emails matching the search term are sorted? I noticed it's not sorted by date, so I thought it could be by relevance first and date second. I tested it by searching for a keyword that appears in a list of automatic emails (all identical), and yet the search results are still ordered by something else than date despite the identical content. Anyway I don't think relevance would be possible if `xapian` only looks for exact matches.

kerem commented

2026-03-03 01:19:21 +03:00

Author

Owner

@d99kris commented on GitHub (Aug 16, 2020):

Currently nmail uses default search result order of Xapian, which is sorting by relevance - according to https://xapian.org/docs/apidoc/html/classXapian_1_1Enquire.html at least.

Admittedly I have not evaluated how Xapian determines relevance. For a simple two term search (hello world) I suspect it ranks matches of "hello world" first, and then emails containing both "hello" and "world" and lastly emails containing either "hello" or "world". But it's just my assumption.

I'm also starting to think that it perhaps makes more sense to sort the results by date, as that's what some other emails clients do.

@d99kris commented on GitHub (Aug 16, 2020): Currently `nmail` uses default search result order of Xapian, which is sorting by **relevance** - according to https://xapian.org/docs/apidoc/html/classXapian_1_1Enquire.html at least. Admittedly I have not evaluated how Xapian determines relevance. For a simple two term search (hello world) I suspect it ranks matches of "hello world" first, and then emails containing both "hello" and "world" and lastly emails containing either "hello" or "world". But it's just my assumption. I'm also starting to think that it perhaps makes more sense to sort the results by date, as that's what some other emails clients do.

kerem commented

2026-03-03 01:19:21 +03:00

Author

Owner

@Kabouik commented on GitHub (Aug 18, 2020):

Thanks a lot. It's weird that Xapian finds a way to sort by relevance (other than date) when we use only one search term and that term is an exact match. Defaulting to date sorting could be more straightforward indeed, or alternatively add a keybinding in the search results to change the sorting (?).

Do you know if Xapian would support searching for statuses, like read/unread?

@Kabouik commented on GitHub (Aug 18, 2020): Thanks a lot. It's weird that Xapian finds a way to sort by relevance (other than date) when we use only one search term and that term is an exact match. Defaulting to date sorting could be more straightforward indeed, or alternatively add a keybinding in the search results to change the sorting (?). Do you know if Xapian would support searching for statuses, like read/unread?

kerem commented

2026-03-03 01:19:21 +03:00

Author

Owner

@d99kris commented on GitHub (Aug 18, 2020):

Hi @Kabouik - I've actually just now (few minutes ago) pushed a couple of changes (improvements I hope) to the search function. In essence they are:

Sort search results by timestamp
Remember search string when performing repeated searches
Combine search query words with AND by default

Regarding your question on searching for status, it's not very simple to support, but it's certainly possible. I understand you'd like to be able to filter to only see unread email for example?

@d99kris commented on GitHub (Aug 18, 2020): Hi @Kabouik - I've actually just now (few minutes ago) pushed a couple of changes (improvements I hope) to the search function. In essence they are: 1. Sort search results by timestamp 2. Remember search string when performing repeated searches 3. Combine search query words with `AND` by default Regarding your question on searching for status, it's not very simple to support, but it's certainly possible. I understand you'd like to be able to filter to only see unread email for example?

kerem commented

2026-03-03 01:19:21 +03:00

Author

Owner

@Kabouik commented on GitHub (Aug 18, 2020):

Nice changes, I'll pull the update on my devices tomorrow!

Yes, I was looking for a way to just show read or unread emails, and possibly restrict searches to either status, I was wondering if this could be done with Xapian, but maybe that would not be the simplest way. No hurry anyway, nmail already is already quite nice for every day use now!

@Kabouik commented on GitHub (Aug 18, 2020): Nice changes, I'll pull the update on my devices tomorrow! Yes, I was looking for a way to just show read or unread emails, and possibly restrict searches to either status, I was wondering if this could be done with Xapian, but maybe that would not be the simplest way. No hurry anyway, `nmail` already is already quite nice for every day use now!

kerem commented

2026-03-03 01:19:21 +03:00

Author

Owner

@Kabouik commented on GitHub (Sep 30, 2020):

Just wanted to say that I am impressed by how fast and efficient the local search is. My colleague looking over my shoulder when we were working on something together was impressed (and jealous) too. :]

@Kabouik commented on GitHub (Sep 30, 2020): Just wanted to say that I am impressed by how fast and efficient the local search is. My colleague looking over my shoulder when we were working on something together was impressed (and jealous) too. :]

kerem commented

2026-03-03 01:19:21 +03:00

Author

Owner

@d99kris commented on GitHub (Oct 3, 2020):

Thanks, that's great to hear! :)

On 2020-09-30 23:16 Kabouik notifications@github.com wrote:

Just wanted to say that I am impressed by how fast and efficient the
local search is. My colleague looking over my shoulder when we were
working on something togethert was impressed (and jealous) too. :]

--
You are receiving this because you were assigned.
Reply to this email directly or view it on GitHub:
https://github.com/d99kris/nmail/issues/45#issuecomment-701457599

@d99kris commented on GitHub (Oct 3, 2020): Thanks, that's great to hear! :) On 2020-09-30 23:16 Kabouik <notifications@github.com> wrote: > Just wanted to say that I am impressed by how fast and efficient the > local search is. My colleague looking over my shoulder when we were > working on something togethert was impressed (and jealous) too. :] > > -- > You are receiving this because you were assigned. > Reply to this email directly or view it on GitHub: > https://github.com/d99kris/nmail/issues/45#issuecomment-701457599 >

kerem commented

2026-03-03 01:19:21 +03:00

Author

Owner

@d99kris commented on GitHub (Jan 12, 2021):

I've been considering the support for searching cache using external tools, and although the proof of concept you provided is very impressive, I've leaning towards that this lies outside the scope of nmail. And that other features / bug fixes are more important. So I will proceed to close this issue for now. Please let me know if you have any concerns.

Separately I will be working on IMAP search, for the case when user does not have all messages locally cached.

@d99kris commented on GitHub (Jan 12, 2021): I've been considering the support for searching cache using external tools, and although the proof of concept you provided is very impressive, I've leaning towards that this lies outside the scope of nmail. And that other features / bug fixes are more important. So I will proceed to close this issue for now. Please let me know if you have any concerns. Separately I will be working on IMAP search, for the case when user does not have all messages locally cached.

kerem commented

2026-03-03 01:19:22 +03:00

Author

Owner

@d99kris commented on GitHub (Feb 27, 2021):

On a slightly related note - just wanted to share that support for finding text in message view was added in 4d4973c - the default keybindings are / for find and ? for find next.

If one is using the search function (/ in list view) to search for emails, and then opens up one of the matches, it is now possible to press ? to perform find inside the email using the same search query, and effectively find the matching occurrences within the email text (assuming plain text word / phrase search - the "in-message find" does not deal with AND, OR, +, -, etc).

@d99kris commented on GitHub (Feb 27, 2021): On a slightly related note - just wanted to share that support for finding text in message view was added in 4d4973c - the default keybindings are `/` for `find` and `?` for `find next`. If one is using the search function (`/` in list view) to search for emails, and then opens up one of the matches, it is now possible to press `?` to perform find inside the email using the same search query, and effectively find the matching occurrences within the email text (assuming plain text word / phrase search - the "in-message find" does not deal with AND, OR, +, -, etc).

kerem commented

2026-03-03 01:19:22 +03:00

Author

Owner

@Kabouik commented on GitHub (Feb 27, 2021):

That's excellent, thanks. I was sofar using my $EDITOR to perform searches within the body of emails, but this will be convenient. I will just change the default "next" keybinding to match that of my usual editor (n for next, a-n for previous).

On 2021-02-27 12:44 Kristofer Berggren notifications@github.com wrote:

On a slightly related note - just wanted to share that support for finding text in message view was added in
4d4973c - the default keybindings are / for find and ? for find next.

If one is using the search function (/ in list view) to search for emails, and then opens up one of the
matches, it is now possible to press ? to perform find inside the email using the same search query, and
effectively find the matching occurrences within the email text (assuming plain text word / phrase search -
the "in-message find" does not deal with AND, OR, +, -, etc).

--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/d99kris/nmail/issues/45#issuecomment-787060287

@Kabouik commented on GitHub (Feb 27, 2021): That's excellent, thanks. I was sofar using my $EDITOR to perform searches within the body of emails, but this will be convenient. I will just change the default "next" keybinding to match that of my usual editor (n for next, a-n for previous). On 2021-02-27 12:44 Kristofer Berggren <notifications@github.com> wrote: > On a slightly related note - just wanted to share that support for finding text in message view was added in > 4d4973c - the default keybindings are `/` for `find` and `?` for `find next`. > > If one is using the search function (`/` in list view) to search for emails, and then opens up one of the > matches, it is now possible to press `?` to perform find inside the email using the same search query, and > effectively find the matching occurrences within the email text (assuming plain text word / phrase search - > the "in-message find" does not deal with AND, OR, +, -, etc). > > -- > You are receiving this because you were mentioned. > Reply to this email directly or view it on GitHub: > https://github.com/d99kris/nmail/issues/45#issuecomment-787060287

Rows
Columns

[GH-ISSUE #45] [Question] Workflow to search content in cache using external tools #44