From mboxrd@z Thu Jan 1 00:00:00 1970 From: Darlan Cavalcante Moreira Subject: Re: Re: Best way to implement Keywords feature Date: Mon, 09 Nov 2009 11:26:48 -0300 Message-ID: <4af826ad.8702be0a.3f0a.684b@mx.google.com> References: <7bef1f890911051442h28d45647h4f128a241d4e0116@mail.gmail.com> <427836.88344.qm@web28316.mail.ukl.yahoo.com> <87tyx5tg2x.fsf@gmail.com> <87vdhkvq0x.fsf@gmail.com> <87hbt4k1o3.fsf@gmail.com> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N7VCz-0004TA-Pf for emacs-orgmode@gnu.org; Mon, 09 Nov 2009 09:27:05 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N7VCv-0004ST-37 for emacs-orgmode@gnu.org; Mon, 09 Nov 2009 09:27:05 -0500 Received: from [199.232.76.173] (port=35724 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N7VCv-0004SQ-0t for emacs-orgmode@gnu.org; Mon, 09 Nov 2009 09:27:01 -0500 Received: from mail-yx0-f191.google.com ([209.85.210.191]:64381) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N7VCu-0004tL-Kv for emacs-orgmode@gnu.org; Mon, 09 Nov 2009 09:27:00 -0500 Received: by yxe29 with SMTP id 29so2975576yxe.14 for ; Mon, 09 Nov 2009 06:26:58 -0800 (PST) In-Reply-To: List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Matthew Lundin Cc: Paul Mead , org-mode At Mon, 09 Nov 2009 07:27:19 -0500, Matthew Lundin wrote: > > Paul Mead writes: > > > Matthew Lundin writes: > > > >> > >> It will if you use brackets to perform a regexp match. E.g., > >> > >> Keyword={example1} > >> > >> (...assuming the property is "Keyword: example1 example2".) > >> > >> From the manual page above: > >> > >> ,---- > >> | * If the comparison value is enclosed in curly braces, a regexp match > >> | is performed, with '=' meaning that the regexp matches the property > >> | value, and '<>' meaning that it does not match. > >> `---- > >> > >> Best, > >> Matt > > > > That's great, but what if I need to match *both* example1 and example2 > > in a search? I tried a few things but didn't find anything that > > works. > > > > Ideally, I'd be able to specify several keywords in a search on the > > fly. > > > > (I'm sorry if there's a regexp that matches multiple keywords that I > > don't know - it's a skill which I find keeps presenting surprises!) > > Perhaps some regexp expert will come along and show us the way, but, for > now, you could search for entries that contain both keywords by entering > the following tags/properties search: > > Keyword={example1}+Keyword={example2} > > Best, > Matt > > > _______________________________________________ > Emacs-orgmode mailing list > Remember: use `Reply All' to send replies to the list. > Emacs-orgmode@gnu.org > http://lists.gnu.org/mailman/listinfo/emacs-orgmode I'd like to make a feature request on this. I like to include tags in a task with the name of a person the task is related to in order to find the task easily when the person wants to talk about it. I don't need to see these tags in the agenda view. I only need them for searching. This is the same problem discussed here and while Keyword={someone}+Keyword={someone else} may work, it is not as convenient as the usual tags. One idea implementing "hidden tags" that should work exactly as the normal tags for searching, but stored in a HIDDEN_TAGS property. To indicate that there are hidden tags a short tag could be added (similar to the ATTACH tag to indicate that there are attachments). If the user types "T" in the agenda view the hidden tags should be showed in addition to the regular ones. The manual says that accessing TODO, LEVEL, and CATEGORY is fast. Therefore, I understand that it is possible to access the HIDDEN_TAGS fast it it intended to, right? One example with such feature would be ,---- | * TODO Some task :HIDDEN:RegularTag:AnotherOne: | :PROPERTIES: | :HIDDEN_TAGS: :AHiddenTag:AnotherHiddenTag: | :END: `---- Maybe we should use a smaller tag (even a single single letter with a different face) instead of HIDDEN to indicate that there are hidden tags. At last, We need a way to tell org which tags should be hidden when specifying org-tag-persistent-alist. If the user inputs a tag that is not in org-tag-persistent-alist then maybe C-u C-c C-c could set it as a hidden tag and "realign all tags in the current buffer" changed to C-u C-u C-c C-c. Would this be hard to implement? - Darlan