Hello! I have .org files with "#+FILETAGS: ARCHIVE" headers. I want items from these .org files to be hidden by default from results of "org-agenda" -> "s Search for keywords" by default. This is not the case, unfortunately. Calling "org-agenda-archives-mode" in agenda view also ignores items from .org files with "#+FILETAGS: ARCHIVE" and does not hide them. Both "org-agenda" -> "s Search for keywords" and "org-agenda-archives-mode" only hide items, which have :ARCHIVE: tag assigned to them or to their parents. Items from .org files with "#+FILETAGS: ARCHIVE" are still shown in agenda view. They are shown as having ":ARCHIVE::" tag and I could hide them by calling "org-agenda-filter" -> "-archive". But this is manual effort every time. Ideally I'd want to: 1. When calling "org-agenda" -> "s Search for keywords" both (a) items with :ARCHIVE: tag and (b) all items from .org files with "#+FILETAGS: ARCHIVE" are hidden by default 2. Calling "org-agenda-archives-mode" in agenda view will also show/hide items from .org files with "#+FILETAGS: ARCHIVE" *How the above could be done, please?* I run org version 20200511 on GNU Emacs 26.3 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.20.8) of 2020-04-25 Thank you!
George Sokolsky writes: > I have .org files with "#+FILETAGS: ARCHIVE" headers. > > I want items from these .org files to be hidden by default from results > of "org-agenda" -> "s Search for keywords" by default. > > This is not the case, unfortunately. [...] I'd guess that it's uncommon to try to set the ARCHIVE tag at the file level, as file-level archiving is already dealt through org-archive-location and friends. These standard files can optionally be included with vA (or C-u M-x org-agenda-archives-mode). > *How the above could be done, please?* I don't see a built-in way to do it, though I think the patch below may be sufficient to provide the behavior you want. It doesn't consider any of the tag inheritance variables, but that's probably okay given that those aren't considered for handling :ARCHIVE: subtrees either. -- >8 -- Subject: [PATCH] agenda: Consider FILETAGS for archive skipping * lisp/org-agenda.el (org-agenda-skip): Consider skipping all entries in a file if org-archive-tag is set via FILETAGS. --- lisp/org-agenda.el | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index 9c73d0d6c..8ed5e402d 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -4082,8 +4082,10 @@ (defun org-agenda-skip () (when (or (save-excursion (goto-char p) (looking-at comment-start-skip)) (and org-agenda-skip-archived-trees (not org-agenda-archives-mode) - (get-text-property p :org-archived) - (org-end-of-subtree t)) + (or (and (get-text-property p :org-archived) + (org-end-of-subtree t)) + (and (member org-archive-tag org-file-tags) + (goto-char (point-max))))) (and org-agenda-skip-comment-trees (get-text-property p :org-comment) (org-end-of-subtree t)) -- 2.26.2
[-- Attachment #1: Type: text/plain, Size: 2455 bytes --] Hi, I support George view. A working ARCHIVE tag on file level would be consistent and very useful. To be archived is a property of the content of a file, not of it's file name. Having to store the file name on a variable is a complicated and poor workaround. The file name may change. Still the content should stay archived. Regards, Michael Kyle Meyer <kyle@kyleam.com> schrieb am So., 17. Mai 2020, 07:34: > George Sokolsky writes: > > > I have .org files with "#+FILETAGS: ARCHIVE" headers. > > > > I want items from these .org files to be hidden by default from results > > of "org-agenda" -> "s Search for keywords" by default. > > > > This is not the case, unfortunately. > [...] > > I'd guess that it's uncommon to try to set the ARCHIVE tag at the file > level, as file-level archiving is already dealt through > org-archive-location and friends. These standard files can optionally > be included with vA (or C-u M-x org-agenda-archives-mode). > > > *How the above could be done, please?* > > I don't see a built-in way to do it, though I think the patch below may > be sufficient to provide the behavior you want. It doesn't consider any > of the tag inheritance variables, but that's probably okay given that > those aren't considered for handling :ARCHIVE: subtrees either. > > -- >8 -- > Subject: [PATCH] agenda: Consider FILETAGS for archive skipping > > * lisp/org-agenda.el (org-agenda-skip): Consider skipping all entries > in a file if org-archive-tag is set via FILETAGS. > --- > lisp/org-agenda.el | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el > index 9c73d0d6c..8ed5e402d 100644 > --- a/lisp/org-agenda.el > +++ b/lisp/org-agenda.el > @@ -4082,8 +4082,10 @@ (defun org-agenda-skip () > (when (or > (save-excursion (goto-char p) (looking-at comment-start-skip)) > (and org-agenda-skip-archived-trees (not > org-agenda-archives-mode) > - (get-text-property p :org-archived) > - (org-end-of-subtree t)) > + (or (and (get-text-property p :org-archived) > + (org-end-of-subtree t)) > + (and (member org-archive-tag org-file-tags) > + (goto-char (point-max))))) > (and org-agenda-skip-comment-trees > (get-text-property p :org-comment) > (org-end-of-subtree t)) > -- > 2.26.2 > > > [-- Attachment #2: Type: text/html, Size: 3220 bytes --]
Thank you very much Kyle for the patch you provided!
I had to apply it manually on the latest org-20200518 (line numbers
changed in this new version or me too lame) - the patch seem to fix the
below problem and works just fine!
IMHO using "#+FILETAGS: ARCHIVE" is one of legitimate ways of applying
ARCHIVE tag to items in org. As such I'd love the below patch included
into the official org distribution. I'm trying to add Bastien into
recepients of this e-mail - or could anyone please help with commiting
the below code into the org repository?
Thank you,
George
Kyle Meyer <kyle@kyleam.com> writes:
> George Sokolsky writes:
>
>> I have .org files with "#+FILETAGS: ARCHIVE" headers.
>>
>> I want items from these .org files to be hidden by default from results
>> of "org-agenda" -> "s Search for keywords" by default.
>>
>> This is not the case, unfortunately.
> [...]
>
> I'd guess that it's uncommon to try to set the ARCHIVE tag at the file
> level, as file-level archiving is already dealt through
> org-archive-location and friends. These standard files can optionally
> be included with vA (or C-u M-x org-agenda-archives-mode).
>
>> *How the above could be done, please?*
>
> I don't see a built-in way to do it, though I think the patch below may
> be sufficient to provide the behavior you want. It doesn't consider any
> of the tag inheritance variables, but that's probably okay given that
> those aren't considered for handling :ARCHIVE: subtrees either.
>
> -- >8 --
> Subject: [PATCH] agenda: Consider FILETAGS for archive skipping
>
> * lisp/org-agenda.el (org-agenda-skip): Consider skipping all entries
> in a file if org-archive-tag is set via FILETAGS.
> ---
> lisp/org-agenda.el | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
> index 9c73d0d6c..8ed5e402d 100644
> --- a/lisp/org-agenda.el
> +++ b/lisp/org-agenda.el
> @@ -4082,8 +4082,10 @@ (defun org-agenda-skip ()
> (when (or
> (save-excursion (goto-char p) (looking-at comment-start-skip))
> (and org-agenda-skip-archived-trees (not org-agenda-archives-mode)
> - (get-text-property p :org-archived)
> - (org-end-of-subtree t))
> + (or (and (get-text-property p :org-archived)
> + (org-end-of-subtree t))
> + (and (member org-archive-tag org-file-tags)
> + (goto-char (point-max)))))
> (and org-agenda-skip-comment-trees
> (get-text-property p :org-comment)
> (org-end-of-subtree t))
Hi George,
thanks for your patch!
George Sokolsky <sokolgeo@posteo.net> writes:
> I'm trying to add Bastien into recepients of this e-mail - or could
> anyone please help with commiting the below code into the org
> repository?
Anyone with write access to the repository can apply it.
If you plan to make regular contributions and do not need your patches
to be reviewed on the list anymore, we can grant you write access, but
there is no such need for occasional patches.
Cheers,
--
Bastien
For avoidance of doubt - this is Kyle's patch, not mine (thank you Kyle!)
Bastien, do you mean that this patch will be in the next weekly org build on melpa?
Thank you
George
Bastien <bzg@gnu.org> writes:
> Hi George,
>
> thanks for your patch!
>
> George Sokolsky <sokolgeo@posteo.net> writes:
>
>> I'm trying to add Bastien into recepients of this e-mail - or could
>> anyone please help with commiting the below code into the org
>> repository?
>
> Anyone with write access to the repository can apply it.
>
> If you plan to make regular contributions and do not need your patches
> to be reviewed on the list anymore, we can grant you write access, but
> there is no such need for occasional patches.
>
> Cheers,
Hi George, George Sokolsky <sokolgeo@posteo.net> writes: > For avoidance of doubt - this is Kyle's patch, not mine (thank you > Kyle!) Sorry for the confusion, I thought you were asking for permission to commit the patch directly yourself. Kyle can of course apply it when he wants. > Bastien, do you mean that this patch will be in the next weekly org > build on melpa? If the patch gets applied soon, it will be available on the Org ELPA package. I don't know about MELPA. Best, -- Bastien
Kyle, could you please apply the patch to the org repository?
Thank you
George
Bastien <bzg@gnu.org> writes:
> Hi George,
>
> George Sokolsky <sokolgeo@posteo.net> writes:
>
>> For avoidance of doubt - this is Kyle's patch, not mine (thank you
>> Kyle!)
>
> Sorry for the confusion, I thought you were asking for permission to
> commit the patch directly yourself. Kyle can of course apply it when
> he wants.
>
>> Bastien, do you mean that this patch will be in the next weekly org
>> build on melpa?
>
> If the patch gets applied soon, it will be available on the Org ELPA
> package. I don't know about MELPA.
>
> Best,
George Sokolsky writes: > I had to apply it manually on the latest org-20200518 (line numbers > changed in this new version or me too lame) - the patch seem to fix the > below problem and works just fine! The patch was against the master branch (specifically 9bc0cc7fb), not the maint branch which is the source of the ELPA archive. > IMHO using "#+FILETAGS: ARCHIVE" is one of legitimate ways of applying > ARCHIVE tag to items in org. I think this statement is a reply to me saying that "I'd guess that it's uncommon to try to set the ARCHIVE tag at the file level [because...]". To be clear, that didn't contain a claim one way or the other about whether "#+FILETAGS: ARCHIVE" is a legitimate way to apply an archive tag. But based on me taking the time to look into a code change, it probably doesn't surprise you that my first thought was "hmph, yeah, seems like that _should_ work". George Sokolsky later writes: > Kyle, could you please apply the patch to the org repository? I sent out the patch so that others have the opportunity to provide feedback on it as well as your initial message. If no one does (which is fine), at some point in the next few days I'll revisit the patch, maybe inspect the surrounding code a bit more, and apply it (assuming I don't end up convincing myself that it's a bad idea or needs more work).
George Sokolsky writes:
> Kyle, could you please apply the patch to the org repository?
Applied (5e2490bdf).
[-- Attachment #1: Type: text/plain, Size: 214 bytes --] Thank you Kyle On May 21, 2020 5:05:10 AM GMT+02:00, Kyle Meyer <kyle@kyleam.com> wrote: >George Sokolsky writes: > >> Kyle, could you please apply the patch to the org repository? > >Applied (5e2490bdf). [-- Attachment #2: Type: text/html, Size: 596 bytes --]
Hi George, George Sokolsky <sokolgeo@posteo.net> writes: > I have .org files with "#+FILETAGS: ARCHIVE" headers. Shouldn't it be "#+FILETAGS: :ARCHIVE:" instead? (Note the columns.) > I want items from these .org files to be hidden by default from results > of "org-agenda" -> "s Search for keywords" by default. > > This is not the case, unfortunately. Can you be so kind as to test with latest Org from maint or master? Thanks, -- Bastien
Bastien writes: > George Sokolsky <sokolgeo@posteo.net> writes: > >> I have .org files with "#+FILETAGS: ARCHIVE" headers. > > Shouldn't it be "#+FILETAGS: :ARCHIVE:" instead? > > (Note the columns.) Despite being the documented form, org-set-regexps-and-options will handle entries "tag1 [tag2 ...]" as well: (cl-mapcan (lambda (value) (cl-mapcan (lambda (k) (org-split-string k ":")) (split-string value))) (cdr (assoc "FILETAGS" alist))) >> I want items from these .org files to be hidden by default from results >> of "org-agenda" -> "s Search for keywords" by default. >> >> This is not the case, unfortunately. > > Can you be so kind as to test with latest Org from maint or master? Earlier this week I applied the patch from a sibling message of this thread (5e2490bdf), so maint and master no longer behave as initially reported (hopefully :>).
Kyle Meyer <kyle@kyleam.com> writes: > Bastien writes: > >> George Sokolsky <sokolgeo@posteo.net> writes: >> >>> I have .org files with "#+FILETAGS: ARCHIVE" headers. >> >> Shouldn't it be "#+FILETAGS: :ARCHIVE:" instead? >> >> (Note the columns.) > > Despite being the documented form, org-set-regexps-and-options will > handle entries "tag1 [tag2 ...]" as well: > > (cl-mapcan (lambda (value) > (cl-mapcan > (lambda (k) (org-split-string k ":")) > (split-string value))) > (cdr (assoc "FILETAGS" alist))) Indeed, space-separated list of tags is handled correctly as well by the org, despite columns-separated being the official form: https://orgmode.org/manual/Tag-Inheritance.html >>> I want items from these .org files to be hidden by default from results >>> of "org-agenda" -> "s Search for keywords" by default. >>> >>> This is not the case, unfortunately. >> >> Can you be so kind as to test with latest Org from maint or master? > > Earlier this week I applied the patch from a sibling message of this > thread (5e2490bdf), so maint and master no longer behave as initially > reported (hopefully :>). I happily confirm that org 20200525 behaves correctly. Thank you George