Re: Bug: Bad string comparison in org-all-archive-files (org 9.1.14)

[Nicolas Goaziou <mail@nicolasgoaziou.fr>]

Hello,

Nils Gustafsson <nils.gustafsson@bredband2.com> writes:

> I stubled upon this while trying to work out why my clocktables
> weren't behaving as expected. In one of my org files I have several
> large trees set up to use different archive files via :ARCHIVE:
> properties, and the clocktable I added with :scope file-with-archives
> seemed to be ignoring those archives.
>
> Except it worked fine when I used a default archive for the whole
> file, or added a custom one using #+ARCHIVE: instead. After some
> experimenting and digging around in the source code I've found that
> the actual problem is a bad string comparison in a function called
> org-all-archive-files in org-archive.el.
>
>
> The issue:
>
> The real problem turns out to be that org-all-archive-files does not
> do what it says on the can. It should list all archive files for the
> current buffer, but will fail to pick up archive files listed in
> :ARCHIVE: properties.
>
> To reproduce, make a new org file called temp.org (or your choice of
> name) containing something like:
>
> * Test-heading
>   :PROPERTIES:
>   :ARCHIVE: test_archive::
>   :END:
>
>
> Then create an empty file called test_archive in the same directory,
> and try calling (message "archives: %s" (org-all-archive-files)) in
> that buffer.
>
>
> Expected output: "archives: (/some/path/test_archive)"
>
> Actual output: "archives: nil"
>
>
> The cause:
>
> Specifically the error is in this part of org-all-archive-files
> starting on line 170 of org-archive.el (original indentation not
> preserved):
>
>
> (when (save-match-data
>   (if (eq (match-string 1) ":") (org-at-property-p)
>     (eq (org-element-type (org-element-at-point)) 'keyword))) ...
>
>
> That (eq (match-string 1) ":") always fails. Replacing eq with string=
> in that expression seems to restore the expected behaviour:
> org-all-archive-files no longer ignores archive files listed in
> :ARCHIVE: properties. And indeed, it resolves the clocktable issue I
> was having as well.

Indeed. I applied your fix.

Thank you for the analysis!

Regards,

-- 
Nicolas Goaziou