thread-based email index, search, and tagging https://git.notmuchmail.org/git/notmuch/atom?h=master 2024-04-06T18:03:45Z 2024-04-06T18:03:45Z Mohsin Kaleem mohkale@kisara.moe 2024-03-10T18:57:41Z urn:sha1:cd89065dc36e36b22a2a53832d2cac9b06fba41c The new notmuch-search-hide-excluded option allows users to configure whether to show or hide excluded messages (as determined by search.exclude_tags in the local notmuch config file). It defaults to true for now to maintain backwards-compatibility with how notmuch-{search,tree} already worked. New commands notmuch-search-toggle-hide-excluded and notmuch-tree-toggle-exclude have also been added. They toggle the value of notmuch-search-hide-excluded for the search in the current search or tree buffer. It's bound to "i" in the respective keymaps for these modes. Lastly I've amended some calls to notmuch-tree and notmuch-unthreaded which didn't pass through the buffer local value of notmuch-search-oldest-first (and now notmuch-search-exclude). Examples of where I've done this include: + notmuch-jump-search + notmuch-tree-from-search-current-query + notmuch-unthreaded-from-search-current-query + notmuch-tree-from-search-thread A new test file for Emacs has been added which covers the usage of the new `notmuch-search-hide-excluded' option and interactively hiding or showing mail with excluded tags. These test cover the basic usage of the `notmuch-search-toggle-hide-excluded' command in notmuch-search, notmuch-tree and notmuch-unthreaded searches. These tests also cover the persistence of the current value of the hide-excluded mail option as a user switches from between these different search commands. [1]: id:87ilxlxsng.fsf@kisara.moe Amended-by: db, fix indentation in T461-emacs-search-exclude.sh 2021-08-30T00:42:58Z Jonas Bernoulli jonas@bernoul.li 2021-07-19T11:31:06Z urn:sha1:f01df47ce11f67dfe746f9b2bb3a4384d1c9ced0 2021-08-30T00:42:32Z Jonas Bernoulli jonas@bernoul.li 2021-07-19T11:31:05Z urn:sha1:27c8e377e450706fd7f21a15888da277658c48ee 2021-08-05T11:58:30Z Protesilaos Stavrou info@protesilaos.com 2021-07-17T08:30:18Z urn:sha1:c37c99126d4bf6909399d84455063e0ff0ee9b59 The intent of the 'notmuch-jump-key' face is to allow users/themes to differentiate the text of the minibuffer prompt from the keys that are associated with jump actions. Commit 5cc106b0 correctly introduced the 'notmuch-jump-key' face for keys, but mistakenly applied it to the prompt as well. 2021-06-27T15:28:54Z Protesilaos Stavrou info@protesilaos.com 2021-05-21T16:55:31Z urn:sha1:5cc106b0e3e53f56b189ef067753ea5f29cb4243 The minibuffer-prompt face that was used before made it impossible to differentiate between two distinct UI elements: (i) the prompt's text which itself cannot be acted upon, (ii) the actionable keys used to jump to searches/tags. The use of a named face, notmuch-jump-key, makes it possible for users or theme developers to apply properties that are specific to each of those two cases. In the interest of backward compatibility, the new face inherits from minibuffer-prompt. 2021-01-15T10:46:38Z Jonas Bernoulli jonas@bernoul.li 2021-01-10T14:01:07Z urn:sha1:9ca1f945d9f5030600dc14ffff10d4dad14db4ca We need to load `cl-lib' at run-time because we use more from it than just macros. Never-the-less many, but not all libraries required it only at compile-time, which we got away with because at least some libraries already required it at run-time as well. We use `cl-lib' and (currently to a lesser extend) `pcase' throughout the code-base, which means that we should require these features in most libraries. In the past we tried to only require these features in just the libraries that actually need them, without fully succeeding. We did not succeed in doing so because that means we would have to check every time that we use a function from these features whether they are already being required in the current library. An alternative would be to add the `require' forms at the top of every library but that is a bit annoying too. In order to make sure that these features are loaded when needed but also to keep the noise down we only require them in "notmuch-lib.el", which most other libraries require, and in most of the few libraries that do not do so, namely "notmuch-draft.el", "notmuch-message.el" and "notmuch-parser.el". ("coolj.el", "make-deps.el", various generated libraries, and "notmuch-compat.el" are left touched.) 2021-01-15T10:38:00Z Jonas Bernoulli jonas@bernoul.li 2021-01-13T17:37:50Z urn:sha1:16b2db0986ce0ed7c420a69d0a98bb41e9ca4bd8 2021-01-13T11:16:23Z Jonas Bernoulli jonas@bernoul.li 2021-01-10T14:00:48Z urn:sha1:0067a43ea2ee554eafed1e1300a71259cd6b6a6d The previous commit switched to lexical-binding but without dealing with the new warnings about unused lexical arguments and variables. This commit deals with most of them, in most cases by either removing leftover bindings that are actually unnecessary, or by marking certain arguments as "known to be unused" by prefixing their names with "_". In the case of the functions named `notmuch-show-insert-...' the amount of silencing that is required is a bit extreme and we might want to investigate if there is a better way. In the case of `notmuch-mua-mail', ignoring CONTINUE means that we do not fully follow the intended behavior described in `compose-mail's doc-string. 2021-01-13T11:16:04Z Jonas Bernoulli jonas@bernoul.li 2021-01-10T14:00:47Z urn:sha1:fc4cda07a9afbbb545dcc6cd835ca697f6ef2a1b Doing so causes many new compile warnings. Some of these warnings concern genuine changes in behavior that have to be addressed right away. Many other warnings are due to unused variables. Nothing has changed here, except that the byte-compiler can now detect these pre-existing and harmless issues. We delay addressing these issues so that we can focus on the important ones here. A third group of warnings concern arguments that are not actually used inside the function but which cannot be removed because the functions signature is dictated by some outside convention. Silencing these warning is also delayed until subsequent commits. 2021-01-13T11:10:27Z Jonas Bernoulli jonas@bernoul.li 2021-01-10T14:00:46Z urn:sha1:2ca941163da06aed564dab1990fb333fd7457ec2 `outline-minor-mode' treats comments that begin with three or more semicolons as headings. That makes it very convenient to navigate code and to show/hide parts of a file. Elips libraries typically have four top-level sections, e.g.: ;;; notmuch.el --- run notmuch within emacs... ;;; Commentary:... ;;; Code:... ;;; notmuch.el ends here In this package many libraries lack a "Commentary:" section, which is not optimal but okay for most libraries, except major entry points. Depending on how one chooses to look at it, the "... ends here" line is not really a heading that begins a section, because it should never have a "section" body (after all it marks eof). If the file is rather short, then I left "Code:" as the only section that contains code. Otherwise I split the file into multiple sibling sections. The "Code:" section continues to contain `require' and `declare-function' forms and other such "front matter". If and only if I have split the code into multiple sections anyway, then I also added an additional section named just "_" before the `provide' form and shortly before the "...end here" line. This section could also be called "Back matter", but I feel it would be distracting to be that explicit about it. (The IMO unnecessary but unfortunately still obligatory "... ends here" line is already distracting enough as far as I am concerned.) Before this commit some libraries already uses section headings, some of them consistently. When a library already had some headings, then this commit often sticks to that style, even at the cost inconsistent styling across all libraries. A very limited number of variable and function definitions have to be moved around because they would otherwise end up in sections they do not belong into. Sections, including but not limited to their heading, can and should be further improved in the future.