From 4584b61ea172e423f49ab21bd33a9e935a1a1966 Mon Sep 17 00:00:00 2001 From: "Dirk-Jan C. Binnema" Date: Wed, 8 Apr 2020 11:25:51 +0300 Subject: [PATCH] mu4e.texi: minor update --- mu4e/mu4e.texi | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/mu4e/mu4e.texi b/mu4e/mu4e.texi index 3b36298b..3294e383 100644 --- a/mu4e/mu4e.texi +++ b/mu4e/mu4e.texi @@ -3873,14 +3873,14 @@ In general, the same queries for @command{mu} and @t{mu4e} should yield the same results. If they differ, this is usually because one of the following reasons: @itemize -@item different default options: -mu4e defaults to having @t{mu4e-headers-include-related} and +@item different options: +@t{mu4e} defaults to having @t{mu4e-headers-include-related}, and @t{mu4e-headers-results-limit} set to 500. However, the command-line @command{mu find}'s corresponding @t{--include-related} is false, and there's no limit (@t{--maxnum}). @item reverse sorting: -The results may be different when only one @t{mu4e} and @command{mu -find} do not both sort their results in the same direction. +The results may be different when @t{mu4e} and @command{mu find} do +not both sort their results in the same direction. @item shell quoting issues: Depending on the shell, various shell metacharacters in search query (such as @t{*}) may be expanded by the shell before @command{mu} ever