Best way to implement Keywords feature

Best way to implement Keywords feature

[Alan E. Davis]

[-- Attachment #1.1: Type: text/plain, Size: 538 bytes --]

In some cases, a single headword entry can relate to a large number of
topics.  I have tried dealing with longer tag lists: automatic adjustment of
tags column (on this list a little utility was posted:
org-adjust-tags-column-reset-tags.  I THINK that a keyword list may allow
more freedom to cross-index, especially if it is easy to use.

Can someone suggest a way to implement a keywording system, perhaps with a
custom agenda search?  Or have others dealt with this issue in innovative
ways?

I would appreciate any ideas.

Alan Davis

[-- Attachment #1.2: Type: text/html, Size: 569 bytes --]

[-- Attachment #2: Type: text/plain, Size: 204 bytes --]

_______________________________________________
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

Re: Best way to implement Keywords feature

[Samuel Wales]

Don't know what you are referring to exactly, but if it is like the
following, there are several ideas.

  * computer
    * apple
  * garden
    * apple

The problem is that there will be two apples in the agenda.

One such solution is to use header-line-format to display olpath.

-- 
Q: How many CDC "scientists" does it take to change a lightbulb?
A: You only think it's dark. [CDC has denied ME/CFS for 25 years]
=================================================================
Retrovirus: http://www.wpinstitute.org/xmrv/xmrv_qa.html

Re: Best way to implement Keywords feature

[Alan E. Davis]

[-- Attachment #1.1: Type: text/plain, Size: 1169 bytes --]

On Thu, Nov 5, 2009 at 10:58 PM, Samuel Wales <samologist@gmail.com> wrote:

>
>
> One such solution is to use header-line-format to display olpath.
>
> I don't understand this.

In scientific/academic publications, one often sees a list of Keywords in
the topmatter.  That being said, I am not certain how people use them.
There are often a dozen or more.

I have had to throttle back my use of tags, to avoid long header lines.
Also, tags are limited to head lines, only.

I would like to implement a secondary list of keywords, that might be
searched in an agenda search.  I don't know whether properties would be
appropriate, although I understand properties can slow the system down.
Don't know.   Probably something similar to properties.

So, for example, if I am taking notes and indexing video clips or PDFs, a
larger number of keywords would enable me to retrieve them in a less
structured, free form manner.  A custom agenda search would be perfect.

Probably barking up a tree.  Probably just better use of tags would solve
this problem.   Keywords, though, could be implemented outside of
headlines.  Maybe I should just use more headlines.

Thanks.

Alan

[-- Attachment #1.2: Type: text/html, Size: 1519 bytes --]

[-- Attachment #2: Type: text/plain, Size: 204 bytes --]

_______________________________________________
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

Re: Best way to implement Keywords feature

[Samuel Wales]

We are talking about different things.  Your thread, so I will bow out.

For your topic, I just add words.  Then I use m-x org-agenda s.

-- 
Q: How many CDC "scientists" does it take to change a lightbulb?
A: You only think it's dark. [CDC has denied ME/CFS for 25 years]
=================================================================
Retrovirus: http://www.wpinstitute.org/xmrv/xmrv_qa.html

Re: Best way to implement Keywords feature

[Giovanni Ridolfi]

--- Gio 5/11/09, Alan E. Davis <lngndvs@gmail.com> ha scritto:
> In some cases, a single headword entry can
> relate to a large number of topics.  I have tried dealing
> with longer tag lists: automatic adjustment of tags column
> (on this list a little utility was posted: 
> org-adjust-tags-column-reset-tags.  I THINK that a keyword
> list may allow more freedom to cross-index, especially if it
> is easy to use.

What about properties?

* computer
    * apple
:PROPERTIES:
:Keyword: Power PC
:END:
  * garden
    * apple
:PROPERTIES:
:Keyword: Golden Delicious
:END:

> 
> Can someone suggest a way to implement a keywording system,
> perhaps with a custom agenda search?  

Recently something was posted regarding 
custom search and :PROPERTIES:.

However you can already search for keywords in Agenda,
please, refer the section of the manual:
"Keyword search"

> Or have others dealt
> with this issue in innovative ways?

I think that everything is already there ;-)

cheers
Giovanni

Re: Best way to implement Keywords feature

[Alan E. Davis]

[-- Attachment #1.1: Type: text/plain, Size: 495 bytes --]

Thank you Samuel

On Thu, Nov 5, 2009 at 11:40 PM, Samuel Wales <samologist@gmail.com> wrote:

> For your topic, I just add words.  Then I use m-x org-agenda s.
>
> This is pretty close to what I have in mind.  And I see there are several
possible routes, a couple of which seem amenable to a custom agenda command.

I think what I want to do is use a search for a Keyword marker (such as
"KEYWORDS::") then do the secondary search for the specific keyword.

Thank you for the suggestion.

Alan

[-- Attachment #1.2: Type: text/html, Size: 848 bytes --]

[-- Attachment #2: Type: text/plain, Size: 204 bytes --]

_______________________________________________
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

Re: Best way to implement Keywords feature

[Renzo Been :-)]

Alan E. Davis <lngndvs <at> gmail.com> writes:

> Thank you Samuel
> Samuel Wales <samologist <at> gmail.com> wrote:
> 
> For your topic, I just add words.  Then I use m-x org-agenda s.
> 
> This is pretty close to what I have in mind.  And I see there are several
> possible routes, a couple of which seem amenable to a custom agenda
> command.I think what I want to do is use a search for a Keyword marker
> (such as "KEYWORDS::") then do the secondary search for the specific
> keyword. Thank you for the suggestion.Alan

Hi Alan,

Another way to set-up keywords could be by using categories. It's a rather
old-fashioned way of using org-mode... But you don't need long lines of tags or
properties... See the example below.

-----

* Topic 1
#+CATEGORY: keyword1
<2009-11-06 Fri>
* Topic 2
#+CATEGORY: keyword3 keyword3
<2009-11-07 Sat>

-----

When opening an agenda view, the agenda will look like this. No searching
needed... 

-----

Month-agenda (W45-W49):
Friday      6 November 2009
  keyword1:   Topic 1
Saturday    7 November 2009
  keyword3 keyword3:Topic 2

-----

Hope this helps,
Renzo

Re: Re: Best way to implement Keywords feature

[Giovanni Ridolfi]

--- Ven 6/11/09, Renzo Been :-) <swangdoodles@gmail.com> ha scritto:
> Hi Alan,
> 
> Another way to set-up keywords could be by using
> categories. 
=:-<

> It's a rather
> old-fashioned way of using org-mode... [smnip]
> * Topic 1
> #+CATEGORY: keyword1
> <2009-11-06 Fri>
> * Topic 2
> #+CATEGORY: keyword3 keyword3
> <2009-11-07 Sat>

Please, Renzo, do *not* promote deprecated behaviours:

Manual: 10.4.1 Categories
"For backward compatibility, the following also works: if there
are *several such lines in a file*, each specifies the category for the
text below it.  The first category also applies to any text before the
first CATEGORY line.  However, using this method is _strongly_
deprecated"

(first emphasis is mine)

Using  :PROPERTIES: is the right way to handle such
issue.

Thanks,
Giovanni

Re: Best way to implement Keywords feature

[Paul Mead]

Giovanni Ridolfi <giovanni.ridolfi@yahoo.it> writes:

>
> What about properties?
>
> * computer
>     * apple
> :PROPERTIES:
> :Keyword: Power PC
> :END:
>   * garden
>     * apple
> :PROPERTIES:
> :Keyword: Golden Delicious
> :END:
>
>
> However you can already search for keywords in Agenda,
> please, refer the section of the manual:
> "Keyword search"
Giovanni

I can't find anything in the manual which does anything other than
search for TODO keywords, and this functionality would be pretty useful
to me - can you point to the section number?

Thanks
Paul

Re: Best way to implement Keywords feature

[Matt Lundin]

Paul Mead <paul.d.mead@googlemail.com> writes:

> Giovanni Ridolfi <giovanni.ridolfi@yahoo.it> writes:
>
>>
>> What about properties?
>>
>> * computer
>>     * apple
>> :PROPERTIES:
>> :Keyword: Power PC
>> :END:
>>   * garden
>>     * apple
>> :PROPERTIES:
>> :Keyword: Golden Delicious
>> :END:
>>
>>
>> However you can already search for keywords in Agenda,
>> please, refer the section of the manual:
>> "Keyword search"
> Giovanni
>
> I can't find anything in the manual which does anything other than
> search for TODO keywords, and this functionality would be pretty useful
> to me - can you point to the section number?

http://orgmode.org/manual/Matching-tags-and-properties.html

- Matt

Re: Best way to implement Keywords feature

[Paul Mead]

Matt Lundin <mdl@imapmail.org> writes:

>
> http://orgmode.org/manual/Matching-tags-and-properties.html
>
> - Matt
>
Thanks Matt, although that allows me to search for a single property (if
I use 'Keyword' as an example, this will return a match if I search for
'Keyword="example"'. It doesn't, however work if I want to use more that
one keyword.

For example, if I set a property 'Keyword: keyword1 keyword2' and search for
'Keyword="example1"' org doesn't find it.

I guess what I'm looking for here is an 'extended tag' function, so that
I can give a heading as many tags as are required for searching but
without cluttering up the line itself. I find that if there are more
than two or three short tags, the line get unneccesarily messy. 

Are there other ways that I've missed that would allow this sort of
thing?

Thanks
Paul

Re: Best way to implement Keywords feature

[Matthew Lundin]

Paul Mead <paul.d.mead@googlemail.com> writes:

> Matt Lundin <mdl@imapmail.org> writes:
>
>>
>> http://orgmode.org/manual/Matching-tags-and-properties.html
>>
>> - Matt
>>

> Thanks Matt, although that allows me to search for a single property (if
> I use 'Keyword' as an example, this will return a match if I search for
> 'Keyword="example"'. It doesn't, however work if I want to use more that
> one keyword.
>
> For example, if I set a property 'Keyword: keyword1 keyword2' and search for
> 'Keyword="example1"' org doesn't find it.

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

Re: Best way to implement Keywords feature

[Paul Mead]

Matthew Lundin <mdl@imapmail.org> 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!)

Thanks
Paul

Re: Best way to implement Keywords feature

[Matthew Lundin]

Paul Mead <paul.d.mead@googlemail.com> writes:

> Matthew Lundin <mdl@imapmail.org> 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

Re: Best way to implement Keywords feature

[Paul Mead]

Matthew Lundin <mdl@imapmail.org> writes:

>
> 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
>
Hopefully there's a better way, but thanks for now. I've shortened the
'Keyword' property to 'kw' to reduce typing in the meantime!

Thanks
Paul

Re: Re: Best way to implement Keywords feature

[Darlan Cavalcante Moreira]

At Mon, 09 Nov 2009 07:27:19 -0500,
Matthew Lundin <mdl@imapmail.org> wrote:
> 
> Paul Mead <paul.d.mead@googlemail.com> writes:
> 
> > Matthew Lundin <mdl@imapmail.org> 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

Re: Best way to implement Keywords feature

[Martin Pohlack]

Alan E. Davis wrote:
> In some cases, a single headword entry can relate to a large number of
> topics.  I have tried dealing with longer tag lists: automatic
> adjustment of tags column (on this list a little utility was posted:
> org-adjust-tags-column-reset-tags.  I THINK that a keyword list may
> allow more freedom to cross-index, especially if it is easy to use.
> 
> Can someone suggest a way to implement a keywording system, perhaps with
> a custom agenda search?  Or have others dealt with this issue in
> innovative ways?
> 
> I would appreciate any ideas.

I still have the feeling that tags are the way to go.  Searching etc.
already works with tags.  Their disadvantage seems to be that lines get
cluttered if many tags are used.

Maybe this can be solved with two approaches:
* In agendas, one could have a filter for which tags to show / hide.
  This would be useful otherwise too, as it would allow to hide context
  tags in already defined agendas.

  org-agenda-hide-tags-regex

  For example, all my contexts start with "@", so I would set it to be
  "^@work$" to hide redundant information in my work agendas, or use
  "^@" to remove all context information from a specific agenda.

* For plain view, could we have a soft newline between tags and content
  for an item (like in long-lines-mode)?
  Tags would be shown on a new line (with indentation etc.) but would be
  stored on the same line in files?

  For example, the file content ("\" added by me, should be one long
  line):

*** TODO test1      :keyword1:keyword2:keyword3:keyword4:keyword5:  \
keyword6:keyword7:keyword8:keyword9:keyword10:keyword11:

  Is shown like this in org-mode:

*** TODO test1
    :keyword1:keyword2:keyword3:keyword4:keyword5:keyword6:keyword7:
     keyword8:keyword9:keyword10:keyword11:

Cheers,
Martin Pohlack

Re: Best way to implement Keywords feature

[Martin Pohlack]

[-- Attachment #1: Type: text/plain, Size: 1707 bytes --]

Hi All,

Martin Pohlack wrote:
> Alan E. Davis wrote:
>> In some cases, a single headword entry can relate to a large number of
>> topics.  I have tried dealing with longer tag lists: automatic
>> adjustment of tags column (on this list a little utility was posted:
>> org-adjust-tags-column-reset-tags.  I THINK that a keyword list may
>> allow more freedom to cross-index, especially if it is easy to use.
>>
>> Can someone suggest a way to implement a keywording system, perhaps with
>> a custom agenda search?  Or have others dealt with this issue in
>> innovative ways?
>>
>> I would appreciate any ideas.
> 
> I still have the feeling that tags are the way to go.  Searching etc.
> already works with tags.  Their disadvantage seems to be that lines get
> cluttered if many tags are used.
> 
> Maybe this can be solved with two approaches:
> * In agendas, one could have a filter for which tags to show / hide.
>   This would be useful otherwise too, as it would allow to hide context
>   tags in already defined agendas.
> 
>   org-agenda-hide-tags-regex
> 
>   For example, all my contexts start with "@", so I would set it to be
>   "^@work$" to hide redundant information in my work agendas, or use
>   "^@" to remove all context information from a specific agenda.
> 
> * For plain view, could we have a soft newline between tags and content
>   for an item (like in long-lines-mode)?
>   Tags would be shown on a new line (with indentation etc.) but would be
>   stored on the same line in files?
> 
>   For example, the file content ("\" added by me, should be one long
>   line):

Please find attached a patch that implements tag filtering for agenda views.

Feedback welcome.

Cheers,
Martin

[-- Attachment #2: hide-tags-in-agenda.patch --]
[-- Type: text/x-patch, Size: 2883 bytes --]

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index 708b193..e146bc0 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -1202,6 +1202,14 @@ When non-nil, this must be the number of minutes, e.g. 60 for one hour."
   :group 'org-agenda-line-format
   :type 'boolean)
 
+(defcustom org-agenda-hide-tags-regexp nil
+  "Regular expression used to fitler away specific tags in agenda views.
+Nil means hide no tags."
+  :group 'org-agenda-line-format
+  :type '(choice
+	  (const  :tag "Hide none" nil)
+	  (string :tag "Regexp   ")))
+
 (defcustom org-agenda-remove-tags nil
   "Non-nil means, remove the tags from the headline copy in the agenda.
 When this is the symbol `prefix', only remove tags when
@@ -4507,9 +4515,20 @@ Any match of REMOVE-RE will be removed from TXT."
   (save-match-data
     ;; Diary entries sometimes have extra whitespace at the beginning
     (if (string-match "^ +" txt) (setq txt (replace-match "" nil nil txt)))
-    (when org-agenda-show-inherited-tags
-      ;; Fix the tags part in txt
-      (setq txt (org-agenda-add-inherited-tags txt tags)))
+    ;; filter tags here
+    (when org-agenda-hide-tags-regexp
+      (setq tags (apply 'append (mapcar
+                                 (lambda (x)
+                                   (if (string-match org-agenda-hide-tags-regexp x)
+                                       nil
+                                     (list x)))
+                                 tags))))
+    ;; Fix the tags part in txt
+    (if org-agenda-show-inherited-tags
+        (setq txt (org-agenda-add-inherited-tags txt tags))
+      (when org-agenda-hide-tags-regexp
+        (setq txt (org-agenda-add-local-tags txt tags))))
+    
     (let* ((category (or category
 			 org-category
 			 (if buffer-file-name
@@ -4640,6 +4659,24 @@ Any match of REMOVE-RE will be removed from TXT."
 	'extra extra
 	'dotime dotime))))
 
+(defun org-agenda-add-local-tags (txt tags)
+  "Remove tags string from TXT, and add non-inherited list of tags.
+Inherited tags in TAGS are ignored."
+  (if (string-match (org-re "\\([ \t]+\\)\\(:[[:alnum:]_@:]+:\\)[ \t]*$") txt)
+      (setq txt (substring txt 0 (match-beginning 0))))
+  (when tags
+    ;; drop inherited tags
+    (let ((mytags (apply 'append (mapcar
+                                  (lambda (x)
+                                    (if (get-text-property 0 'inherited x)
+                                        nil
+                                      (list x)))
+                                  tags))))
+      ;; continue with remainder
+      (when (> (length mytags) 0)
+        (setq txt (concat txt " :" (mapconcat (lambda (x) x) mytags ":") ":" )))))
+  txt)
+
 (defun org-agenda-add-inherited-tags (txt tags)
   "Remove tags string from TXT, and add complete list of tags.
 The new list includes inherited tags.  If any inherited tags are present,

[-- Attachment #3: Type: text/plain, Size: 204 bytes --]

_______________________________________________
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

Re: Best way to implement Keywords feature

[Carsten Dominik]

Hi Martin,

I have finally applied a modified version of you patch.  Thanks!

What I modified is this:

1. Your patch did remove the matching tags from the tag list itself,  
and not
    only from the agenda display line.  Tis had the consequence that  
secondary
    tag filtering on such tags would no longer work.  I think it is  
better
    if that still does work.

2. You can now both add the inherited tags, and remove some tags, not
    just one or the other.

Thanks!

- Carsten

On Nov 10, 2009, at 3:47 PM, Martin Pohlack wrote:

> Hi All,
>
> Martin Pohlack wrote:
>> Alan E. Davis wrote:
>>> In some cases, a single headword entry can relate to a large  
>>> number of
>>> topics.  I have tried dealing with longer tag lists: automatic
>>> adjustment of tags column (on this list a little utility was posted:
>>> org-adjust-tags-column-reset-tags.  I THINK that a keyword list may
>>> allow more freedom to cross-index, especially if it is easy to use.
>>>
>>> Can someone suggest a way to implement a keywording system,  
>>> perhaps with
>>> a custom agenda search?  Or have others dealt with this issue in
>>> innovative ways?
>>>
>>> I would appreciate any ideas.
>>
>> I still have the feeling that tags are the way to go.  Searching etc.
>> already works with tags.  Their disadvantage seems to be that lines  
>> get
>> cluttered if many tags are used.
>>
>> Maybe this can be solved with two approaches:
>> * In agendas, one could have a filter for which tags to show / hide.
>>  This would be useful otherwise too, as it would allow to hide  
>> context
>>  tags in already defined agendas.
>>
>>  org-agenda-hide-tags-regex
>>
>>  For example, all my contexts start with "@", so I would set it to be
>>  "^@work$" to hide redundant information in my work agendas, or use
>>  "^@" to remove all context information from a specific agenda.
>>
>> * For plain view, could we have a soft newline between tags and  
>> content
>>  for an item (like in long-lines-mode)?
>>  Tags would be shown on a new line (with indentation etc.) but  
>> would be
>>  stored on the same line in files?
>>
>>  For example, the file content ("\" added by me, should be one long
>>  line):
>
> Please find attached a patch that implements tag filtering for  
> agenda views.
>
> Feedback welcome.
>
> Cheers,
> Martin
> diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
> index 708b193..e146bc0 100644
> --- a/lisp/org-agenda.el
> +++ b/lisp/org-agenda.el
> @@ -1202,6 +1202,14 @@ When non-nil, this must be the number of  
> minutes, e.g. 60 for one hour."
>   :group 'org-agenda-line-format
>   :type 'boolean)
>
> +(defcustom org-agenda-hide-tags-regexp nil
> +  "Regular expression used to fitler away specific tags in agenda  
> views.
> +Nil means hide no tags."
> +  :group 'org-agenda-line-format
> +  :type '(choice
> +	  (const  :tag "Hide none" nil)
> +	  (string :tag "Regexp   ")))
> +
> (defcustom org-agenda-remove-tags nil
>   "Non-nil means, remove the tags from the headline copy in the  
> agenda.
> When this is the symbol `prefix', only remove tags when
> @@ -4507,9 +4515,20 @@ Any match of REMOVE-RE will be removed from  
> TXT."
>   (save-match-data
>     ;; Diary entries sometimes have extra whitespace at the beginning
>     (if (string-match "^ +" txt) (setq txt (replace-match "" nil nil  
> txt)))
> -    (when org-agenda-show-inherited-tags
> -      ;; Fix the tags part in txt
> -      (setq txt (org-agenda-add-inherited-tags txt tags)))
> +    ;; filter tags here
> +    (when org-agenda-hide-tags-regexp
> +      (setq tags (apply 'append (mapcar
> +                                 (lambda (x)
> +                                   (if (string-match org-agenda- 
> hide-tags-regexp x)
> +                                       nil
> +                                     (list x)))
> +                                 tags))))
> +    ;; Fix the tags part in txt
> +    (if org-agenda-show-inherited-tags
> +        (setq txt (org-agenda-add-inherited-tags txt tags))
> +      (when org-agenda-hide-tags-regexp
> +        (setq txt (org-agenda-add-local-tags txt tags))))
> +
>     (let* ((category (or category
> 			 org-category
> 			 (if buffer-file-name
> @@ -4640,6 +4659,24 @@ Any match of REMOVE-RE will be removed from  
> TXT."
> 	'extra extra
> 	'dotime dotime))))
>
> +(defun org-agenda-add-local-tags (txt tags)
> +  "Remove tags string from TXT, and add non-inherited list of tags.
> +Inherited tags in TAGS are ignored."
> +  (if (string-match (org-re "\\([ \t]+\\)\\(:[[:alnum:]_@:]+:\\) 
> [ \t]*$") txt)
> +      (setq txt (substring txt 0 (match-beginning 0))))
> +  (when tags
> +    ;; drop inherited tags
> +    (let ((mytags (apply 'append (mapcar
> +                                  (lambda (x)
> +                                    (if (get-text-property 0  
> 'inherited x)
> +                                        nil
> +                                      (list x)))
> +                                  tags))))
> +      ;; continue with remainder
> +      (when (> (length mytags) 0)
> +        (setq txt (concat txt " :" (mapconcat (lambda (x) x) mytags  
> ":") ":" )))))
> +  txt)
> +
> (defun org-agenda-add-inherited-tags (txt tags)
>   "Remove tags string from TXT, and add complete list of tags.
> The new list includes inherited tags.  If any inherited tags are  
> present,
> _______________________________________________
> 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

- Carsten