[Exporter] Why is :author a list in the communication channel?

[Exporter] Why is :author a list in the communication channel?

[Thorsten Jolitz]

Hi List, 

I wonder why the :author attribute in INFO is a list (while :email,
:creator and others are not)?

It would make sense if several authors would be collected as a list of
strings, like e.g.

,-------------------------------------
| ("Thorsten Jolitz" "Thomas Mueller")
`-------------------------------------

but I don't know how to write the #+AUTHOR: information to achieve
that.

This

,----------------------------------------
| #+AUTHOR: Thorsten Jolitz Thomas Mueller
`----------------------------------------

and other versions I tried (with comma or double quotes as separators)
always results in a single string element inside the :author list

,-----------------------------------
| ("Thorsten Jolitz Thomas Mueller")
`-----------------------------------

so why make the value a list and not a string?


-- 
cheers,
Thorsten

Re: [Exporter] Why is :author a list in the communication channel?

[Nicolas Goaziou]

Hello,

Thorsten Jolitz <tjolitz@gmail.com> writes:

> I wonder why the :author attribute in INFO is a list (while :email,
> :creator and others are not)?

:author's value is parsed, as all keywords in
`org-element-document-properties'. So its value is a secondary string,
i.e. an element without type.


Regards,

-- 
Nicolas Goaziou

Re: [Exporter] Why is :author a list in the communication channel?

[Thorsten Jolitz]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Hello,
>
> Thorsten Jolitz <tjolitz@gmail.com> writes:
>
>> I wonder why the :author attribute in INFO is a list (while :email,
>> :creator and others are not)?
>
> :author's value is parsed, as all keywords in
> `org-element-document-properties'. So its value is a secondary string,
> i.e. an element without type.

Ah, ok, so these

,---------------------------------------------------------
| org-element-document-properties is a variable defined in
| `org-element.el'.
| Its value is ("AUTHOR" "DATE" "TITLE")
`---------------------------------------------------------

are different from the others. Thanks.

--
cheers,
Thorsten

Re: [Exporter] Why is :author a list in the communication channel?

[Aaron Ecay]

Hi Thorsten,

I would have expected multiple author lines to have this effect, so that
your desired list of two authors would be generated by:
,----
| #+author: Thorsten Jolitz
| #+author: Thomas Mueller
`----

But it seems that only the last #+author line is used; previous ones are
discarded.  Maybe the :author plist entry should just be converted into
a string.  But if it remains a list to somehow support multiply-authored
documents, I think the most natural way to specify the entries is with
multiple lines as above.

--
Aaron Ecay

Re: [Exporter] Why is :author a list in the communication channel?

[Thorsten Jolitz]

Aaron Ecay <aaronecay@gmail.com> writes:

Hi Aaron,

> I would have expected multiple author lines to have this effect, so that
> your desired list of two authors would be generated by:
> ,----
> | #+author: Thorsten Jolitz
> | #+author: Thomas Mueller
> `----
>
> But it seems that only the last #+author line is used; previous ones are
> discarded.  Maybe the :author plist entry should just be converted into
> a string.  But if it remains a list to somehow support multiply-authored
> documents, I think the most natural way to specify the entries is with
> multiple lines as above.

I can confirm that behaviour ... I'm not sure if I really get the idea
of a 'typeless secondary' string as mentioned by Nicolas, but in daily
practice 

,-----------------------
| (plist-get info :author)
`-----------------------

returns a list with one string in it for me ...

-- 
cheers,
Thorsten

Re: [Exporter] Why is :author a list in the communication channel?

[Nicolas Goaziou]

Hello,

Thorsten Jolitz <tjolitz@gmail.com> writes:

> Aaron Ecay <aaronecay@gmail.com> writes:
>
> Hi Aaron,
>
>> I would have expected multiple author lines to have this effect, so that
>> your desired list of two authors would be generated by:
>> ,----
>> | #+author: Thorsten Jolitz
>> | #+author: Thomas Mueller
>> `----
>>
>> But it seems that only the last #+author line is used; previous ones are
>> discarded.  Maybe the :author plist entry should just be converted into
>> a string.  But if it remains a list to somehow support multiply-authored
>> documents, I think the most natural way to specify the entries is with
>> multiple lines as above.
>
> I can confirm that behaviour ... I'm not sure if I really get the idea
> of a 'typeless secondary' string as mentioned by Nicolas, but in daily
> practice 
>
> ,-----------------------
> | (plist-get info :author)
> `-----------------------
>
> returns a list with one string in it for me ...

Try

  #+AUTHOR: This is *Me*!

The point is that you can have Org objects within AUTHOR (or TITLE, or
DATE). See "secondary string" definition in org-element.el header.

This is orthogonal to the fact that multiple lines are not allowed. For
that, see BEHAVIOUR item in `org-export-options-alist'. In particular,
you can compare "TITLE" and "AUTHOR" entries.


Regards,

-- 
Nicolas Goaziou

Re: [Exporter] Why is :author a list in the communication channel?

[Thorsten Jolitz]

Hello,

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Thorsten Jolitz <tjolitz@gmail.com> writes:
>
>> Aaron Ecay <aaronecay@gmail.com> writes:
>>
>> Hi Aaron,
>>
>>> I would have expected multiple author lines to have this effect, so that
>>> your desired list of two authors would be generated by:
>>> ,----
>>> | #+author: Thorsten Jolitz
>>> | #+author: Thomas Mueller
>>> `----
>>>
>>> But it seems that only the last #+author line is used; previous ones are
>>> discarded.  Maybe the :author plist entry should just be converted into
>>> a string.  But if it remains a list to somehow support multiply-authored
>>> documents, I think the most natural way to specify the entries is with
>>> multiple lines as above.
>>
>> I can confirm that behaviour ... I'm not sure if I really get the idea
>> of a 'typeless secondary' string as mentioned by Nicolas, but in daily
>> practice 
>>
>> ,-----------------------
>> | (plist-get info :author)
>> `-----------------------
>>
>> returns a list with one string in it for me ...
>
> Try
>
>   #+AUTHOR: This is *Me*!
>
> The point is that you can have Org objects within AUTHOR (or TITLE, or
> DATE). See "secondary string" definition in org-element.el header.
>
> This is orthogonal to the fact that multiple lines are not allowed. For
> that, see BEHAVIOUR item in `org-export-options-alist'. In particular,
> you can compare "TITLE" and "AUTHOR" entries.

Ok, I understand, so this is all working fine just as intended. For
multiple authors one could use a workaround/convention like 

 ,------------------------------------------
 | #+author: Thorsten_Jolitz Thomas_Mueller
 `------------------------------------------

and then split the string two times (first blanks, then underscores). 

-- 
cheers,
Thorsten

Re: [Exporter] Why is :author a list in the communication channel?

[Nicolas Goaziou]

Thorsten Jolitz <tjolitz@gmail.com> writes:

> Ok, I understand, so this is all working fine just as intended. For
> multiple authors one could use a workaround/convention like 
>
>  ,------------------------------------------
>  | #+author: Thorsten_Jolitz Thomas_Mueller
>  `------------------------------------------
>
> and then split the string two times (first blanks, then underscores).

It is also possible to allow multiple author lines, by adding `space'
behaviour in `org-export-options-alist', but I'm not sure this is really
necessary.


Regards,

-- 
Nicolas Goaziou

Re: [Exporter] Why is :author a list in the communication channel?

[Nick Dokos]

Thorsten Jolitz <tjolitz@gmail.com> writes:

> Nicolas Goaziou <n.goaziou@gmail.com> writes:
>
>> ...
>> This is orthogonal to the fact that multiple lines are not allowed. For
>> that, see BEHAVIOUR item in `org-export-options-alist'. In particular,
>> you can compare "TITLE" and "AUTHOR" entries.
>
> Ok, I understand, so this is all working fine just as intended. For
> multiple authors one could use a workaround/convention like 
>
>  ,------------------------------------------
>  | #+author: Thorsten_Jolitz Thomas_Mueller
>  `------------------------------------------
>
> and then split the string two times (first blanks, then underscores). 

... or you could modify org-export-options-alist, e.g.:

  (setcar org-export-options-alist '(:author "AUTHOR" nil user-full-name space))

This is a bit too fragile as a general solution: it assumes that the
:author entry is the car of org-export-options-alist which happens to be
the case in my setup, but if you rearrange things, it might not be the
case in your setup. Doing list surgery in the general case is left as
an exercise.

Nick

Re: [Exporter] Why is :author a list in the communication channel?

[Marcin Borkowski]

Dnia 2013-11-04, o godz. 20:30:24
Nicolas Goaziou <n.goaziou@gmail.com> napisał(a):

> Thorsten Jolitz <tjolitz@gmail.com> writes:
> 
> > Ok, I understand, so this is all working fine just as intended. For
> > multiple authors one could use a workaround/convention like 
> >
> >  ,------------------------------------------
> >  | #+author: Thorsten_Jolitz Thomas_Mueller
> >  `------------------------------------------
> >
> > and then split the string two times (first blanks, then
> > underscores).
> 
> It is also possible to allow multiple author lines, by adding `space'
> behaviour in `org-export-options-alist', but I'm not sure this is
> really necessary.

It is well possible that I don't understand something here, but in some
LaTeX classes you use \author{...} many times instead of the default
\author{... \and ...}.  Maybe when exporting to such LaTeX classes,
allowing multiple #+AUTHOR: lines might make sense?

> Regards,

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University