From: Samuel Wales <firstname.lastname@example.org> To: email@example.com Subject: text search and restriction lock bugs Date: Tue, 5 Sep 2017 14:42:32 -0700 [thread overview] Message-ID: <CAJcAo8tt44PEVkYGqJiG7x1m7NX9WgA9b3RaQLgqOYfa49UH8w@mail.gmail.com> (raw) recent maint. these are separate, but 1 and 3 might be related, and 1 and 2 might be related, so i hope you don't mind if i put them together. 1. is it expected behavior that if you do a restriction lock on a subtree, then do a text search, it will include matches from org-agenda-text-search-extra-files? imo it should not. 2. if you remove the restriction lock and refresh the agenda, it will produce different results. imo, should act as if the restriction lock were still in place. g should refresh with the settings that were present at invocation. sometimes you change buffer name, and run a new agenda, so that you can have 2 agendas, one restricted and one not. this makes sense if you think of refreshing as "get what i got, but take into account file /content/ changes", instead of "run again as if you ran the agenda from scratch". the restriction lock is not fontified nicely so it can be desirable to remove it for editing. 3. finally, a user will sometimes bind org-agenda-files to a list that includes some of the org-agenda-text-search-extra-files files. to avoid showing the same match twice, the user currently has to do remove-duplicates. imo the agenda could do remove-duplicates to alleviate that burden. -- The Kafka Pandemic: <http://thekafkapandemic.blogspot.com> The disease DOES progress. MANY people have died from it. And ANYBODY can get it at any time. "You’ve really gotta quit this and get moving, because this is murder by neglect." --- <http://www.meaction.net/2017/02/03/pwme-people-with-me-are-being-murdered-by-neglect>.
next reply other threads:[~2017-09-05 21:42 UTC|newest] Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-09-05 21:42 Samuel Wales [this message] 2017-09-07 13:58 ` Nicolas Goaziou 2017-09-07 22:44 ` Samuel Wales 2021-02-28 22:06 ` Samuel Wales 2021-03-27 23:02 ` Samuel Wales
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: https://www.orgmode.org/ * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAJcAo8tt44PEVkYGqJiG7x1m7NX9WgA9b3RaQLgqOYfa49UH8w@mail.gmail.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: text search and restriction lock bugs' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox: https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).