* Re: Re: Adding tags, grouping tags
2010-10-15 5:55 ` Noorul Islam K M
@ 2010-10-15 8:29 ` Karl Maihofer
2010-10-15 8:35 ` Carsten Dominik
0 siblings, 1 reply; 11+ messages in thread
From: Karl Maihofer @ 2010-10-15 8:29 UTC (permalink / raw
To: emacs-orgmode
Noorul Islam K M <noorul@noorul.com> schrieb:
> I have something like this shamelessly copied from Bernt's doc.
>
> (setq org-tag-alist (quote ((:startgroup)
> ("@errand" . ?e)
> ("@office" . ?o)
> ("@home" . ?h)
> (:endgroup)
> ("PHONE" . ?p)
> ("NEXT" . ?n)
> ("WAITING" . ?w)
> ("HOME" . ?H)
> ("ORG" . ?O))))
Thanks for your reply! Correct me if I'm wrong, but doesn't this
"only" effect that if you add the tag @office, than add the tag @home,
the first will be deleted automatically? This is not the kind of
grouping what I am looking for. For me it should - by the way - be
possible to add several tags of the same group.
I'd like to use the same selection keys for different tags. For
example I have the following groups:
Group "people":
- Key "h" -> Holger
- Key "o" -> Otto
Group "contexts":
- Key "h" -> @home
- Key "o" -> @office
To make this possible I think it is necessary to be able to select the
group in the first step, and then the tag you want to assign - as it
is possible for agenda groups.
Any ideas?
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Re: Adding tags, grouping tags
2010-10-15 8:29 ` Karl Maihofer
@ 2010-10-15 8:35 ` Carsten Dominik
2010-10-15 8:52 ` Karl Maihofer
0 siblings, 1 reply; 11+ messages in thread
From: Carsten Dominik @ 2010-10-15 8:35 UTC (permalink / raw
To: Karl Maihofer; +Cc: emacs-orgmode
On Oct 15, 2010, at 10:29 AM, Karl Maihofer wrote:
>
> Noorul Islam K M <noorul@noorul.com> schrieb:
>> I have something like this shamelessly copied from Bernt's doc.
>>
>> (setq org-tag-alist (quote ((:startgroup)
>> ("@errand" . ?e)
>> ("@office" . ?o)
>> ("@home" . ?h)
>> (:endgroup)
>> ("PHONE" . ?p)
>> ("NEXT" . ?n)
>> ("WAITING" . ?w)
>> ("HOME" . ?H)
>> ("ORG" . ?O))))
>
> Thanks for your reply! Correct me if I'm wrong, but doesn't this
> "only" effect that if you add the tag @office, than add the tag
> @home, the first will be deleted automatically? This is not the kind
> of grouping what I am looking for. For me it should - by the way -
> be possible to add several tags of the same group.
>
> I'd like to use the same selection keys for different tags. For
> example I have the following groups:
>
> Group "people":
> - Key "h" -> Holger
> - Key "o" -> Otto
I use TAB and then completion for people. Otherwise you run into
trouble with two people starting with the same name, trusting your
system too far....
- Carsten
>
> Group "contexts":
> - Key "h" -> @home
> - Key "o" -> @office
>
> To make this possible I think it is necessary to be able to select
> the group in the first step, and then the tag you want to assign -
> as it is possible for agenda groups.
>
> Any ideas?
>
>
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
- Carsten
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Re: Adding tags, grouping tags
2010-10-15 8:35 ` Carsten Dominik
@ 2010-10-15 8:52 ` Karl Maihofer
2010-10-15 14:43 ` Ilya Shlyakhter
0 siblings, 1 reply; 11+ messages in thread
From: Karl Maihofer @ 2010-10-15 8:52 UTC (permalink / raw
To: Carsten Dominik; +Cc: emacs-orgmode
Hi Carsten!
Carsten Dominik <carsten.dominik@gmail.com> schrieb:
>> Group "people":
>> - Key "h" -> Holger
>> - Key "o" -> Otto
>
> I use TAB and then completion for people. Otherwise you run into
> trouble with two people starting with the same name, trusting your
> system too far....
Yes, this may be a risk. But the people group was only an example. The
main reason for me pre-defining the tags and using selection keys is
that I use org to archive documents. I'd like to assign tags to this
documents: (1) the names of clients the documents belong to (2) tags
describing the contents ot the files. To make sure that I do not use
different tags for the same thing, it is important to see a list of
the used tags when assigning them. So I have to use pre-defined tags
and selections keys. Do you know what I mean?
Besides that I have tags in other contexts, e.g. GTD-related tags etc.
So it would be very useful to be able to group the tags as it is
possible for agenda commands.
Thanks!
Karl
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Re: Adding tags, grouping tags
2010-10-15 14:43 ` Ilya Shlyakhter
@ 2010-10-16 5:32 ` Carsten Dominik
2010-10-16 19:26 ` Robert Horn
0 siblings, 1 reply; 11+ messages in thread
From: Carsten Dominik @ 2010-10-16 5:32 UTC (permalink / raw
To: Ilya Shlyakhter; +Cc: emacs-orgmode
On Oct 15, 2010, at 4:43 PM, Ilya Shlyakhter wrote:
> Karl Maihofer <ignoramus <at> gmx.de> writes:
>> Besides that I have tags in other contexts, e.g. GTD-related tags
>> etc.
>> So it would be very useful to be able to group the tags as it is
>> possible for agenda commands.
>
> I think that a way to define logical groups of tags (or even a
> hierarchy of tags
> -- say with a subtree of tag names?) would be a very useful addition.
I can see that this could be useful - but the code is
not in any way prepared to do this, so this would be pretty hard
to implement.
- Carsten
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Re: Adding tags, grouping tags
2010-10-16 5:32 ` Carsten Dominik
@ 2010-10-16 19:26 ` Robert Horn
2010-10-16 20:09 ` Carsten Dominik
0 siblings, 1 reply; 11+ messages in thread
From: Robert Horn @ 2010-10-16 19:26 UTC (permalink / raw
To: emacs-orgmode
On 10/16/2010 01:32 AM, Carsten Dominik wrote:
>
> On Oct 15, 2010, at 4:43 PM, Ilya Shlyakhter wrote:
>
>> Karl Maihofer <ignoramus <at> gmx.de> writes:
>>> Besides that I have tags in other contexts, e.g. GTD-related tags etc.
>>> So it would be very useful to be able to group the tags as it is
>>> possible for agenda commands.
>>
>> I think that a way to define logical groups of tags (or even a
>> hierarchy of tags
>> -- say with a subtree of tag names?) would be a very useful addition.
>
> I can see that this could be useful - but the code is
> not in any way prepared to do this, so this would be pretty hard
> to implement.
>
Is it worth exploring use of the properties drawer? The tags in org are
a fairly simple and thus limited structure. The properties drawer can
have a lot more structure with a more controlled environment.
R Horn
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Re: Adding tags, grouping tags
2010-10-16 19:26 ` Robert Horn
@ 2010-10-16 20:09 ` Carsten Dominik
0 siblings, 0 replies; 11+ messages in thread
From: Carsten Dominik @ 2010-10-16 20:09 UTC (permalink / raw
To: rjhorn; +Cc: emacs-orgmode
On Oct 16, 2010, at 9:26 PM, Robert Horn wrote:
> On 10/16/2010 01:32 AM, Carsten Dominik wrote:
>>
>> On Oct 15, 2010, at 4:43 PM, Ilya Shlyakhter wrote:
>>
>>> Karl Maihofer <ignoramus <at> gmx.de> writes:
>>>> Besides that I have tags in other contexts, e.g. GTD-related tags
>>>> etc.
>>>> So it would be very useful to be able to group the tags as it is
>>>> possible for agenda commands.
>>>
>>> I think that a way to define logical groups of tags (or even a
>>> hierarchy of tags
>>> -- say with a subtree of tag names?) would be a very useful
>>> addition.
>>
>> I can see that this could be useful - but the code is
>> not in any way prepared to do this, so this would be pretty hard
>> to implement.
>>
> Is it worth exploring use of the properties drawer? The tags in org
> are
> a fairly simple and thus limited structure. The properties drawer can
> have a lot more structure with a more controlled environment.
I don't think I understand what you mean here. How would that help?
- Carsten
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Re: Adding tags, grouping tags
@ 2010-10-23 15:15 Robert Horn
2010-10-24 14:06 ` Christian Moe
2010-10-25 6:18 ` Carsten Dominik
0 siblings, 2 replies; 11+ messages in thread
From: Robert Horn @ 2010-10-23 15:15 UTC (permalink / raw
To: emacs-orgmode
On 10/16/10 4:09 PM, Carsten Dominik wrote:
>
> On Oct 16, 2010, at 9:26 PM, Robert Horn wrote:
>
>> On 10/16/2010 01:32 AM, Carsten Dominik wrote:
>>>
>>> On Oct 15, 2010, at 4:43 PM, Ilya Shlyakhter wrote:
>>>
>>>> Karl Maihofer <ignoramus <at> gmx.de> writes:
>>>>> Besides that I have tags in other contexts, e.g. GTD-related tags etc.
>>>>> So it would be very useful to be able to group the tags as it is
>>>>> possible for agenda commands.
>>>>
>>>> I think that a way to define logical groups of tags (or even a
>>>> hierarchy of tags
>>>> -- say with a subtree of tag names?) would be a very useful addition.
>>>
>>> I can see that this could be useful - but the code is
>>> not in any way prepared to do this, so this would be pretty hard
>>> to implement.
>>>
>> Is it worth exploring use of the properties drawer? The tags in org are
>> a fairly simple and thus limited structure. The properties drawer can
>> have a lot more structure with a more controlled environment.
>
> I don't think I understand what you mean here. How would that help?
>
> - Carsten
My first thought was just to deal with visual clutter and parsing
headaches. Encoding standards like IDv3 have a large list of tags and
tags with values that are encoded and hidden in MP3 files. The display
is controlled by application. This is very much like the drawer
behavior in org. So putting tags into drawers would deal with the
clutter associated with having a great many tags on one item.
The next level would be to have org aware of the tag structure. This
would mean having a vocabulary description that describes the tags.
The vocabulary can be described as:
Top level: Context, e.g., GTD
Level 1: TagA
Level 2: TagB, a kind of TagA
Level 3: TagC, a kind of TagB
Level 1: TagD
etc
Usually Tags are unique with in a context, but might collide between
contexts. So I might find the tag "TASK" used in different contexts.
Multiple tags can occur within a context, so something might have TagA
and TagD, and the presence of a lower level tag implies the higher level
tags. So TagC would imply TagB and TagA in the example above.
This is a simplification of full ontological structures that can be
expressed in a language like OWL, but it is one that people can grasp
and use easily. It meets most needs. The music and photographic
standards and their easy usage indicates this.
The vocabulary description could easily be done with some lisp
customization, the way it is done for task states, or it could be in an
org file. Both ways have their advantages.
For each tag you can have a list of pairs of context+tag to keep tags
unique. Appending these as text to each line introduces a lot of visual
clutter and parsing headaches. I would put these into drawers to reduce
the visual clutter and manage duplication. For the tag descriptions I
would have another location that has the full structure of tags, so that
a friendly display selection could be used that reflects the hierarchy.
A tag assignment similar to the IDO selection of levels within an org
hierarchy would make sense. Perhaps an org structure would make sense
for the vocabulary.
A simpler tag that means "look in the tags drawer" would keep the text
file readable and let the agenda processing deal with extracting and
displaying. Non agenda views of the org file would just have the "look
in tags drawer" tag. The viewing options would need to recognize this to
control how the drawer tags are displayed.
R Horn
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Re: Adding tags, grouping tags
2010-10-23 15:15 Re: Adding tags, grouping tags Robert Horn
@ 2010-10-24 14:06 ` Christian Moe
2010-10-25 6:18 ` Carsten Dominik
1 sibling, 0 replies; 11+ messages in thread
From: Christian Moe @ 2010-10-24 14:06 UTC (permalink / raw
To: rjhorn; +Cc: emacs-orgmode, Carsten Dominik
>>>> On Oct 15, 2010, at 4:43 PM, Ilya Shlyakhter wrote:
(...)
>>>>> I think that a way to define logical groups of tags (or even a
>>>>> hierarchy of tags
>>>>> -- say with a subtree of tag names?) would be a very useful addition.
>>>>
>>> On 10/16/2010 01:32 AM, Carsten Dominik wrote:
>>>> I can see that this could be useful - but the code is
>>>> not in any way prepared to do this, so this would be pretty hard
>>>> to implement.
I would also find it useful, though I appreciate that it won't be easy.
Some of the same purpose is already served by #+PROPERTY: xyz_ALL
lines (a kind of tag group) and by tag inheritance (acting like a
structured vocabulary in certain contexts, like a notes file
structured by topic). But none of this provides the full functionality
of structured vocabularies. The Drupal taxonomy module is a nice example.
>> On Oct 16, 2010, at 9:26 PM, Robert Horn wrote:
>>> Is it worth exploring use of the properties drawer? The tags in org are
>>> a fairly simple and thus limited structure. The properties drawer can
>>> have a lot more structure with a more controlled environment.
>>>
> On 10/16/10 4:09 PM, Carsten Dominik wrote:
>> I don't think I understand what you mean here. How would that help?
>>
On 10/23/10 5:15 PM, Robert Horn wrote:
> My first thought was just to deal with visual clutter and parsing
> headaches. Encoding standards like IDv3 have a large list of tags and
> tags with values that are encoded and hidden in MP3 files. The display
> is controlled by application. This is very much like the drawer
> behavior in org. So putting tags into drawers would deal with the
> clutter associated with having a great many tags on one item.
But that's not new, that's what we have now -- the ability to hide
away tags in a drawer by making them property values.
Isn't the point rather that properties are named? If Org gets a
vocabulary structure, it could be restricted to certain named
properties. There would be no need to look up the vocabulary tree for
tags (which would remain 'flat' keywords by definition), nor for other
properties than those defined as having a structured vocabulary. This
might save on performance, as well as spare the user some confusion.
To build on the example in the Info pages:
*** Goldberg Variations
:PROPERTIES:
:Title: Goldberg Variations
:Composer: J.S. Bach
:Artist: Glenn Gould
:Instrument: Piano
:Publisher: Deutsche Grammophon
:NDisks: 1
:END:
Here :Instrument: would be the only property with a vocab structure,
part of which might look something like
* Instrument
** Strings
*** Lutes
*** Harps
*** Zithers
**** Piano
** Wind
** Percussion
So, this item would be one of the matches for a search for
`Instrument=Strings'.
>
> The next level would be to have org aware of the tag structure. This
> would mean having a vocabulary description that describes the tags.
> The vocabulary can be described as:
>
> Top level: Context, e.g., GTD
> Level 1: TagA
> Level 2: TagB, a kind of TagA
> Level 3: TagC, a kind of TagB
> Level 1: TagD
> etc
>
> Usually Tags are unique with in a context, but might collide between
> contexts. So I might find the tag "TASK" used in different contexts.
> Multiple tags can occur within a context, so something might have TagA
> and TagD, and the presence of a lower level tag implies the higher level
> tags. So TagC would imply TagB and TagA in the example above.
As long as only properties can have structured vocabularies, and not
tags, the context will be given by the property name, helping avoid
term collisions; a meteorologist could search his CD collection with
`instrument=wind' and his research notes with `measurement=wind'
without getting them mixed up. (This, again, is what we have today.)
> The vocabulary description could easily be done with some lisp
> customization, the way it is done for task states, or it could be in an
> org file. Both ways have their advantages.
Agree. Since Org is so great for structured lists, thoguh, it would be
really tempting to use an Org file to define vocabularies, e.g. as in
the Goldberg Variations example above.
> For each tag you can have a list of pairs of context+tag to keep tags
> unique. Appending these as text to each line introduces a lot of visual
> clutter and parsing headaches. I would put these into drawers to reduce
> the visual clutter and manage duplication.
Again, this is what is achieved by restricting this functionality to
properties.
What is not achieved, I'm afraid, is making it any easier to implement
the feature on top of existing code.
Yours,
Christian Moe
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Re: Adding tags, grouping tags
2010-10-23 15:15 Re: Adding tags, grouping tags Robert Horn
2010-10-24 14:06 ` Christian Moe
@ 2010-10-25 6:18 ` Carsten Dominik
2010-10-25 11:14 ` Robert Horn
1 sibling, 1 reply; 11+ messages in thread
From: Carsten Dominik @ 2010-10-25 6:18 UTC (permalink / raw
To: rjhorn; +Cc: emacs-orgmode
Hi,
I have the feeling that there are really two strands of
discussion going on here.
1. A two-level or even hierarchical way to *enter* *normal* tags,
i.e. tags that are specified in the headline of a node.
2. A complex new structure that would somehow utilize properties to
crease a tag-like parallel structure that can be used in searches.
Is this a correct view of what is being discussed?
- Carsten
On Oct 23, 2010, at 5:15 PM, Robert Horn wrote:
> On 10/16/10 4:09 PM, Carsten Dominik wrote:
>>
>> On Oct 16, 2010, at 9:26 PM, Robert Horn wrote:
>>
>>> On 10/16/2010 01:32 AM, Carsten Dominik wrote:
>>>>
>>>> On Oct 15, 2010, at 4:43 PM, Ilya Shlyakhter wrote:
>>>>
>>>>> Karl Maihofer <ignoramus <at> gmx.de> writes:
>>>>>> Besides that I have tags in other contexts, e.g. GTD-related
>>>>>> tags etc.
>>>>>> So it would be very useful to be able to group the tags as it is
>>>>>> possible for agenda commands.
>>>>>
>>>>> I think that a way to define logical groups of tags (or even a
>>>>> hierarchy of tags
>>>>> -- say with a subtree of tag names?) would be a very useful
>>>>> addition.
>>>>
>>>> I can see that this could be useful - but the code is
>>>> not in any way prepared to do this, so this would be pretty hard
>>>> to implement.
>>>>
>>> Is it worth exploring use of the properties drawer? The tags in
>>> org are
>>> a fairly simple and thus limited structure. The properties drawer
>>> can
>>> have a lot more structure with a more controlled environment.
>>
>> I don't think I understand what you mean here. How would that help?
>>
>> - Carsten
>
> My first thought was just to deal with visual clutter and parsing
> headaches. Encoding standards like IDv3 have a large list of tags and
> tags with values that are encoded and hidden in MP3 files. The display
> is controlled by application. This is very much like the drawer
> behavior in org. So putting tags into drawers would deal with the
> clutter associated with having a great many tags on one item.
>
> The next level would be to have org aware of the tag structure. This
> would mean having a vocabulary description that describes the tags.
> The vocabulary can be described as:
>
> Top level: Context, e.g., GTD
> Level 1: TagA
> Level 2: TagB, a kind of TagA
> Level 3: TagC, a kind of TagB
> Level 1: TagD
> etc
>
> Usually Tags are unique with in a context, but might collide between
> contexts. So I might find the tag "TASK" used in different contexts.
> Multiple tags can occur within a context, so something might have TagA
> and TagD, and the presence of a lower level tag implies the higher
> level
> tags. So TagC would imply TagB and TagA in the example above.
>
> This is a simplification of full ontological structures that can be
> expressed in a language like OWL, but it is one that people can grasp
> and use easily. It meets most needs. The music and photographic
> standards and their easy usage indicates this.
>
> The vocabulary description could easily be done with some lisp
> customization, the way it is done for task states, or it could be in
> an
> org file. Both ways have their advantages.
>
> For each tag you can have a list of pairs of context+tag to keep tags
> unique. Appending these as text to each line introduces a lot of
> visual
> clutter and parsing headaches. I would put these into drawers to
> reduce
> the visual clutter and manage duplication. For the tag descriptions I
> would have another location that has the full structure of tags, so
> that
> a friendly display selection could be used that reflects the
> hierarchy.
> A tag assignment similar to the IDO selection of levels within an org
> hierarchy would make sense. Perhaps an org structure would make sense
> for the vocabulary.
>
> A simpler tag that means "look in the tags drawer" would keep the text
> file readable and let the agenda processing deal with extracting and
> displaying. Non agenda views of the org file would just have the "look
> in tags drawer" tag. The viewing options would need to recognize
> this to
> control how the drawer tags are displayed.
>
> R Horn
>
> _______________________________________________
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Re: Adding tags, grouping tags
2010-10-25 6:18 ` Carsten Dominik
@ 2010-10-25 11:14 ` Robert Horn
2010-10-26 17:17 ` Karl Maihofer
0 siblings, 1 reply; 11+ messages in thread
From: Robert Horn @ 2010-10-25 11:14 UTC (permalink / raw
To: Carsten Dominik; +Cc: emacs-orgmode, rjhorn
On 10/25/2010 02:18 AM, Carsten Dominik wrote:
> Hi,
>
> I have the feeling that there are really two strands of
> discussion going on here.
>
> 1. A two-level or even hierarchical way to *enter* *normal* tags,
> i.e. tags that are specified in the headline of a node.
>
> 2. A complex new structure that would somehow utilize properties to
> crease a tag-like parallel structure that can be used in searches.
>
> Is this a correct view of what is being discussed?
>
I think so.
My impression is that the present normal tags are approaching their
limit. A multi-level normal tag will probably be longer text, and one
core assumption of normal tags is that it is reasonable to display them
and simply append them to the end of the headline text. With longer
tags and multiple tag contexts I expect this to soon cause problems that
are much more severe than just the problem of tag specification.
Since there exists the properties capability, a more complex structure
that is used in searches and display could be built upon that.
R Horn
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Re: Adding tags, grouping tags
2010-10-25 11:14 ` Robert Horn
@ 2010-10-26 17:17 ` Karl Maihofer
0 siblings, 0 replies; 11+ messages in thread
From: Karl Maihofer @ 2010-10-26 17:17 UTC (permalink / raw
To: emacs-orgmode
Carsten wrote:
>> 2. A complex new structure that would somehow utilize properties to
>> crease a tag-like parallel structure that can be used in searches.
I think it is a interesting idea to use properties for an "extended"
use of tags.
My first attempt to implement my use of tags to organize my documents
in orgmode:
* Title of the memo :ATTACH:
:PROPERTIES:
:Attachments: Memo.pdf
:ID: e77dc30e-53c4-4dde-b451-e2g8aa8964c
:Topic_ALL: Topic1 Topic2 Topic3
:Client_ALL: Client1 Client2 Client3
:Topic:
:Client:
:END:
I use an org-capture template that gives me the structure above to
save new entries to my orgmode-based collection of documents. In the
example above the name of the property item is something like a tag
group. This enables me to insert tags easily (I can use "C-c C-x p Cl
TAB RET" and then scroll through the possible values defined by *_ALL
using the arrow keys). But since the client-entry can only have one
value, the memo can concern different topics... but the property
"Topic" can only have one value, of course.
I think it would not be nice to use "topic_one", "topic_two" and
"topic_three" as properties to be prepared for these cases where an
entry can have more than one value.
Any ideas on how to realize multible tags (being in the same group)
per entry using the properties function?
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2010-10-26 17:18 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-10-23 15:15 Re: Adding tags, grouping tags Robert Horn
2010-10-24 14:06 ` Christian Moe
2010-10-25 6:18 ` Carsten Dominik
2010-10-25 11:14 ` Robert Horn
2010-10-26 17:17 ` Karl Maihofer
-- strict thread matches above, loose matches on Subject: below --
2010-10-14 18:22 Karl Maihofer
2010-10-15 5:55 ` Noorul Islam K M
2010-10-15 8:29 ` Karl Maihofer
2010-10-15 8:35 ` Carsten Dominik
2010-10-15 8:52 ` Karl Maihofer
2010-10-15 14:43 ` Ilya Shlyakhter
2010-10-16 5:32 ` Carsten Dominik
2010-10-16 19:26 ` Robert Horn
2010-10-16 20:09 ` Carsten Dominik
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.