thread-based email index, search, and tagging https://git.notmuchmail.org/git/notmuch/atom?h=0.33 2021-05-15T11:31:00Z 2021-05-15T11:31:00Z David Bremner david@tethera.net 2021-05-08T12:11:11Z urn:sha1:a663783343cb992d132ecc18e4e4d4e37bbf12e9 These tests illustrate the bug reported in id:87v97ytd2s.fsf@fastmail.fm 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. 2020-08-10T00:17:06Z Jonas Bernoulli jonas@bernoul.li 2020-08-08T11:50:07Z urn:sha1:3665914f71fc7be2f537ec0ae2647f768c7f5bbe Use `cl-letf*' instead. 2020-08-10T00:16:12Z Jonas Bernoulli jonas@bernoul.li 2020-08-08T11:50:06Z urn:sha1:96baa2231882e9a9025797b1f9945ba6b2751dd4 2020-08-10T00:14:36Z Jonas Bernoulli jonas@bernoul.li 2020-08-08T11:49:55Z urn:sha1:6c84dee53193a78cf797b44d3febcc14488ea6b1 2020-08-10T00:14:36Z Jonas Bernoulli jonas@bernoul.li 2020-08-08T11:49:53Z urn:sha1:73b8f0b8d71af395667022395b6d6bb692c3aaf2 2020-08-09T23:52:34Z Jonas Bernoulli jonas@bernoul.li 2020-08-08T11:49:43Z urn:sha1:e1a700067a22214f54064c281219fbbbef87de06 2020-08-09T23:51:26Z Jonas Bernoulli jonas@bernoul.li 2020-08-08T11:49:42Z urn:sha1:09f6533c3781b61ea634790d4bad38aadf89115c Also use 'unless' in a few cases where previously 'if' was used with 'not' but without an ELSE part. 2020-07-28T11:39:58Z Jonas Bernoulli jonas@bernoul.li 2020-07-27T15:25:02Z urn:sha1:7b752e9eb479426fdf87ab10ca64fd057ee88252 The goal of this abstraction was to save space. But that failed as the result actually was that four trivial lines got replace with 15 fairly complicated lines. The opposite of what it was supposed to do. Also it made it harder to come up with the fix in the previous commit; simply grepping for the relevant symbols did not work because they get constructed at run-time instead of appearing in the source file. 2020-07-28T11:39:44Z Jonas Bernoulli jonas@bernoul.li 2020-07-27T15:25:01Z urn:sha1:d5d8846c3286ec681c3d46b3fe30d50254224208 Starting with Emacs 27 undeclared variables in evaluated interactive code uses lexical scope. This includes code passed with '--eval' as we do in the Emacs tests, which also happen to assume dynamic scope. - This can affect variables defined by libraries that we use. We let-bind such variables to change the behavior of functions which we then call with these bindings in effect. If these libraries are not loaded beforehand, then the bindings are lexical and fail to have the effect we intended. At this time only 'smtpmail' has to be loaded explicitly (for the variables let-bound in emacs_deliver_message and emacs_fcc_message). 'message' doesn't have to be loaded explicitly, because loading 'notmuch' (in 'run_emacs') already takes care of that, indirectly. - Our own testing-only variables also have to be declared explicitly. We should have done that anyway, but because of how and where these variables are used it was very easy to overlook that (i.e. it isn't something the byte-compiler ever looks at). Not so in Emacs 27 anymore; here this oversight caused four tests to fail. The numeric values of these variables get incremented by functions that we add to hooks that are run by many tests, not just the tests where we actually inspect the value and therefore take care to let- bind the values to 0 before we begin. The global values therefore have to be numeric values as well. I have chosen -100 instead of 0 as the default in case someone writes a test that inspects the value but forgets to let-bind the value. I hope that the unusual negative value that one is going to see in such a case will help debugging the issue.