Re: [O] Allowing multiple date trees in a single file

[Nicolas Goaziou]

Hello,

Carsten Dominik  writes:

> We do disagree here a bit.  This little bit of extra work just keeps the
> existing templates working.  We do not introduce a really different
> structure of the org-capture-templates.  Rather, the code introduces a new
> target type, and it makes some older target types be implemented as special
> versions of the new ones.  The old targets are no longer in the manual, any
> customize user will be switched automatically.  What remains is a small bit
> of code that makes sure that the setup of user who might have been using
> that for a long time continues to work.
>
> In my eyes, this is worth it.  Breaking something in a new version is no
> big deal for people who use Org regularly, but I am sure there are a lot of
> users out there who have not changed their setup for a long time, have not
> followed the discussions here and would be frustrated if their setup breaks
> after getting a new version of Emacs, for example.  So we can shoot a
> warning, but I would vote for just keeping this piece of code
> indefinitely.

Our sole disagreement is above duration. "forever" is a bit long and
unrealistic to me, particularly when it is about supporting undocumented
features.

I'm not suggesting to remove the conversion right now. It could be in
Org 10.0 or even Org 11.0 (As of Org 9.0.4 we still support variables
and functions deprecated since Org 8.0). But at least, at some point we
know that some compatibility layer can be removed instead of letting it
pile up indefinitely.

As a user, I expect changes to happens any time I update a software
I use to some higher major version. What I suggest is simply to send
a warning whenever a template using old methods is used, in addition to
doing the conversion. After a couple of years of seeing this message,
I'm pretty sure almost all users will have switched to the new pattern.

Anyway, I'm not going to oppose this patch just for that point. At least
you have my opinion.

> OK, no objections to a different implementation.  I am not familiar with
> pcase, looks general and useful, should learn about it.

Pattern matching is a very interesting feature, indeed. There are other
possible implementations of the same functin that do not rely on
`pcase', however. My point is more about reducing our use of `setq' at
a minimum, particularly since we moved to lexical scoping.

> Hmm, maybe I misunderstand pcase.  I was under the impression that when
> pcase does the match, it will bind the path to outline-path locally (with
> let or something similar), so that I can, in the scope of the current
> match, use setq to change the variable.
>
> Is my understanding incorrect here?

Your understanding is correct, and it is syntactically right to use
`setq' here.

However, as I pointed out above, it is better to use a let-binding over
a `setq' whenever possible since:

  1. it is faster,
  2. it makes the scope of the variable explicit.

> Well, I agree with you that we should not even have this code in here.  It
> is a hack to solve an issue I was not able to crack - maybe you can.  Let
> me explain:
>
> When I use customize to insert a template definition with the new
> file+olp+datetree target, I want the outline path to be optional.
>
> Here is the relevant part of the customize type definition:
>
>  (list :tag "File [ & Outline path ] & Date tree"
> (const :format "" file+olp+datetree)
> ,file-variants
> (repeat :tag "Outline path" :inline t
> (string :tag "Headline")))
>
> The problem is that customize sets this up assuming at least one string, in
> the customize buffer it looks like this
>
> Target location: Value Menu File [ & Outline path ] & Date tree:
> Filename   : Value Menu Literal:
> Outline path:
> INS DEL Headline:
> INS
> Template   : Value Menu String:
>
> As you can see, without the user clicking INS, there is already a string
> there. So the user would have to click DEL to make the old empty.  I
> figured people would forget all the time, therefore the hack to remove
> empty headlines.  It is critical that the outline path to be empty, because
> that is used to decide if the date trree will be on top level or under a
> heading.
>
> Do you or anyone know how to tweak customize to start out with an empty OLP
> for this application?  The we can remove that part entirely.  Otherwise, I
> am happy to make it a oneliner.

Wouldn't something like

 (choice
  (const :tag "Top level" :inline t nil)
  (repeat :tag "Outline path" :inline t
  (string :tag "Headline")))

do the job?

> I'll take a look if it does make sense and do it if it is easy.  I see it
> as a separate issue since the week tree was implemented using a copy of the
> date tree function.  But I can merge this change into the patch I am making.

Of course, this is not a blocker. This came to mind when I was reading
your patch.

>> Ideally, a 

Re: [O] Bug: org-agenda-only-exact-dates [9.0.4 (9.0.4-elpa @ c:/Users/atamulis/.emacs.d/elpa/org-20170124/)]

[Nicolas Goaziou]

Hello,

"Tamulis, Andrius"  writes:

> I had not read the docstring, but now I have, and I interpret it
> differently than you did. As, it seems, did the people who coded it.
> I want a zero value for org-deadline-warning-days, as I want no
> warnings of future deadlines. But I also do not want notification of
> deadlines that are past due, and that's not what
> org-deadline-warning-days is for.

I was talking about `org-agenda-todo-ignore-deadlines' not
`org-deadline-warning-days'.

It would only apply to deadlines with a TODO keyword, tho.

Regards,

-- 
Nicolas Goaziou

Re: [O] Behavior of `org-show-entry'

[Nicolas Goaziou]

Hello,

Kyle Meyer  writes:

> Hmm, for the reason I gave above, I don't think org-show-entry should
> change, but perhaps there should be a separate function that does
>
> (org-show-entry)
> (org-with-limited-levels (org-show-children))
>
> which is what org-cycle does for the second state listed in its
> docstring.  Or maybe there is a better way to accomplish this that I
> don't know about.

See `org-show-context' and `org-reveal'.

Regards,

-- 
Nicolas Goaziou

[O] backporting changes to exported results for collaborative editing

[Samuel Wales]

suppose you export a subtree to ascii or html, and then a bunch of
people want to help you edit it.  obviously you want the changes back
in org.

obviously the best would be if you could give them the source,
complete with comments.  but assume that they are not computer people,
and not org people, and you don't want to give them your irrelevant
comments.

also assume you also don't want to give them your irrelevant tasks and
you do not use org-export-with-tasks.

it might be that i already know the answer: just do the best you can
with diff, and request small sets of changes at a time, or request
manual instructions for changes.  but perhaps you have ideas?

-- 
The Kafka Pandemic: 

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." --- very true words by Johanna Kaiser spoken to US NIH in
conference call with Walter Koroshetz, NINDS director


Denmark: free Karina Hansen NOW.
  UPDATE 2016-10: home, but not fully free

Re: [O] backporting changes to exported results for collaborative editing

[Marcin Borkowski]

On 2017-02-07, at 02:15, Samuel Wales  wrote:

> suppose you export a subtree to ascii or html, and then a bunch of
> people want to help you edit it.  obviously you want the changes back
> in org.
>
> obviously the best would be if you could give them the source,
> complete with comments.  but assume that they are not computer people,
> and not org people, and you don't want to give them your irrelevant
> comments.
>
> also assume you also don't want to give them your irrelevant tasks and
> you do not use org-export-with-tasks.
>
> it might be that i already know the answer: just do the best you can
> with diff, and request small sets of changes at a time, or request
> manual instructions for changes.  but perhaps you have ideas?

Maybe this could be automated a bit?  Like, org -> markdown, then
people's edits, then diff generating a patch, then some tool existing
only in my dreams currently that converts the md patch to an org patch,
and then apply that patch to the original org?  For small enough
changes, that could actually work, no?

Best,

--
Marcin Borkowski

Re: [O] Feature request: lists with letters

[Rasmus]

Titus von der Malsburg  writes:

> On 2017-02-03 Fri 12:40, Eric S Fraga wrote:
>> On Friday,  3 Feb 2017 at 11:37, Titus von der Malsburg wrote:
>>
>
>> [...]
>>
>>> For me and many others, this is a very common use case.  I challenge you
>>> to implement this with current Org such that it will export correctly to
>>> HTML and PDF.  If I’m not mistaken, this is non-trivial.  If there is no
>>
>> #+begin_src org
>>   Sensation, perception, and memory are of particular
>>   interest to which group of contemporary psychologists?
>>
>>   1. psychoanalysts
>>   2. behaviorists
>>   3. humanistic psychologists
>>   4. <> cognitive psychologists
>>
>>   The correct answer is [[answer]] because 
>> #+end_src
>>
>> does the job for both LaTeX and HTML although with a number in this
>> case.  I have not tried with alphabetical enumeration.
>
> This is nice, but letters are conventionally used in many contexts and I
> think making it work with letters is much harder.

You could use this:

#+html_head: ol {list-style-type: lower-latin;}
#+latex_header: \renewcommand{\theenumi}{\alph{enumi}}

The answer link would render wrongly in html, though.  I'm don't know if
there's an easy way to get the correct "label" for a list item with
html/js.

Rasmus

-- 
Slaa Patienten ihjel, saa siger Feberen Pas

Re: [O] Feature request: lists with letters

[Titus von der Malsburg]

On 2017-02-06 Mon 15:34, Rasmus wrote:
> Titus von der Malsburg  writes:
>
>> On 2017-02-03 Fri 12:40, Eric S Fraga wrote:
>>> On Friday,  3 Feb 2017 at 11:37, Titus von der Malsburg wrote:
>>>
>>
>>> [...]
>>>
 For me and many others, this is a very common use case.  I challenge you
 to implement this with current Org such that it will export correctly to
 HTML and PDF.  If I’m not mistaken, this is non-trivial.  If there is no
>>>
>>> #+begin_src org
>>>   Sensation, perception, and memory are of particular
>>>   interest to which group of contemporary psychologists?
>>>
>>>   1. psychoanalysts
>>>   2. behaviorists
>>>   3. humanistic psychologists
>>>   4. <> cognitive psychologists
>>>
>>>   The correct answer is [[answer]] because
>>> #+end_src
>>>
>>> does the job for both LaTeX and HTML although with a number in this
>>> case.  I have not tried with alphabetical enumeration.
>>
>> This is nice, but letters are conventionally used in many contexts and I
>> think making it work with letters is much harder.
>
> You could use this:
>
> #+html_head: ol {list-style-type: lower-latin;}
> #+latex_header: \renewcommand{\theenumi}{\alph{enumi}}
>
> The answer link would render wrongly in html, though.  I'm don't know if
> there's an easy way to get the correct "label" for a list item with
> html/js.

That’s a neat hack that might come in handy at some point.  However, it
changes the bullet point to letters for /all/ ordered lists in the
document, not just for those that use letters in the org source.

I think this shows that it’s indeed too difficult to make lists with
letters although such lists are fairly common and even standard in some
areas.  A small change in the exporters could solve this issue and make
Org mode more useful.  I don’t see any downsides.

  Titus


signature.asc
Description: PGP signature

Re: [O] Sync up the org in emacs master to org maint branch?

[Phillip Lord]

John Wiegley  writes:

>> "KM" == Kaushal Modi  writes:
>
> KM> If we are able the release the new packaging method in emacs 26.x, then we
> KM> can remove org from emacs master completely, but if not, then at least as
> KM> backup we have a newer org version to go out with that release.
>
> For Emacs 26, I intend the new ELPA process to be in place, whereby "default"
> packages can be developed separately, and declare a way to get slip-streamed
> into the release tarball so users are unaware of the separate nature of their
> development.
>
> The CEDET developers have agreed to support this, and it sounds like you are
> willing to as well. If Lars is game, I'd like for Gnus to be third major
> package we do this for initially. That will reduce considerably the number of
> external files we track in Emacs.git.
>
> The precise technical details have yet to be worked out, but it shouldn't be
> too difficult. Phillip Lord has already began advance work on alternatives,
> and I've received offers of help from others to work on this new process.
>
> I think now is a good time to begin. The first step is to solidify what is
> meant by "tarball EPLA", and the means of slip-streaming a package's contents.
> This will require at least two bits:
>
>   - Some form of declaration to indicate how external files should appear in
> the tarball. In order for the first version of this scheme to be as low
> impact as possible, this should probably be done with a sexp in a data
> file, to be checked in alongside the EPLA.git import of the project.
>
>   - changes to "make dist" to integrate these files, and setup autoloading so
> their inclusion is transparent to end users.
>
> Please comment with your recommendations for the first, and supporting changes
> for the second, if anyone has ideas. Phillip, how is your work on these coming
> along?

At the moment it isn't. My original plan, if you remember, to have emacs
core load ELPA packages with package.el. This requires some minor
re-working of package.el (so that the -Q doesn't block them), some
Makefile fiddling and introducing some standards to test file location
in ELPA, so that it's possible to run ELPA tests from within core.

The alternative proposal is, essentially, to copy files into the Emacs
core build structure and move from there.

Reading the discussion reinforces my feeling that the latter is the
wrong approach, because it reinforces a distinction between packages on
ELPA and packages in core above and beyond the location that they are
stored and versioned. I can't see the advantage of doing this.

I will probably try to work a little further on my package.el solution,
although there seems little enthusiasm for this as the way forward.

Phil

Re: [O] just saw this: orgzly code source available now on github

[Kaushal Modi]

Yes, he just announced that today morning:
https://plus.google.com/+Orgzly/posts/7V4p8fMJwGx

Thanks Neven.

On Mon, Feb 6, 2017 at 11:27 AM Xebar Saram  wrote:

> Just saw this today in case anyone is interested :)
>
> https://github.com/orgzly/orgzly-android
>
> Z
>
-- 

Kaushal Modi

Re: [O] Behavior of `org-show-entry'

[Kyle Meyer]

Nicolas Goaziou  writes:

> Kyle Meyer  writes:
>
>> Hmm, for the reason I gave above, I don't think org-show-entry should
>> change, but perhaps there should be a separate function that does
>>
>> (org-show-entry)
>> (org-with-limited-levels (org-show-children))
>>
>> which is what org-cycle does for the second state listed in its
>> docstring.  Or maybe there is a better way to accomplish this that I
>> don't know about.
>
> See `org-show-context' and `org-reveal'.

Sadly, I had already seen these, and I still answered what I did :)

It seems like, with the default value of org-show-context-detail,
(org-show-context 'agenda) will show the desired view of

* a


a body

** aa...
* b

So, do you recommend that, assuming helm wants this view after jumping
to a heading, it calls (org-show-set-visibility 'local)?  Or should it
use its own key, something like (org-show-context 'helm), so that users
can customize the key in org-show-context-detail?  Or something else?

Thanks.

-- 
Kyle

Re: [O] org-time-stamp, day format

[Eric S Fraga]

On Monday,  6 Feb 2017 at 09:35, Uwe Brauer wrote:
> Hello
>
> When I use org-time-stamp. I obtain:
>
>  <2016-11-15 mar>
>
> mar is short for martes, which is the Spanish word for Tuesday. How can
> I can change that format, to any language I desire? I thought it would
> be calendar-day-name-array but this seems not to be the case.

I think you'll find that these come from the standard time format, using
%a for day of the week.  This will depend on your locale I guess?

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 26.0.50.1, Org release_9.0.4-242-g2c27b8


signature.asc
Description: PGP signature

[O] No priority cookies in html export despite setting pri:t option

[Gez]

This happens even with a fresh "portable-style" installation of emacs
and org-mode and no customisations

When I export to plain text I can see the prioity cookies,  When I
export to html there are none, even though I have created a local for
that file and changed pri:nil to pri:t

The html source file doesn't show the cookies - it's not just the html
rendering or css.

Any idea why?

Gez
Org-mode version 8.2.10
Emacs version GNU Emacs 25.1.1 (x86_64-w64-mingw32)

[O] just saw this: orgzly code source available now on github

[Xebar Saram]

Just saw this today in case anyone is interested :)

https://github.com/orgzly/orgzly-android

Z

Re: [O] Behavior of `org-show-entry'

[Eric Abrahamsen]

Nicolas Goaziou  writes:

> Hello,
>
> Kyle Meyer  writes:
>
>> Hmm, for the reason I gave above, I don't think org-show-entry should
>> change, but perhaps there should be a separate function that does
>>
>> (org-show-entry)
>> (org-with-limited-levels (org-show-children))
>>
>> which is what org-cycle does for the second state listed in its
>> docstring.  Or maybe there is a better way to accomplish this that I
>> don't know about.
>
> See `org-show-context' and `org-reveal'.

Thanks to you both -- I'll bring this up with the Helm people.

Eric

Re: [O] Sync up the org in emacs master to org maint branch?

[David Engster]

Edward John Steere writes:
>  - Suppose that Emacs 22.0 is the current release and Emacs 22.1 is then
>released; CEDET is at 
>  - we update a registry somewhere indicating that Emacs 22.0 works with
> and 22.1 works with
>
>  - When we make updates to CEDET we mark 22.1 as working with
> but we don't change that reference
>for 22.0 (or any older versions)
>  - When someone complains that there's a bug in CEDET for 22.0 we
>indicate that it's no longer supported and that they should update
>Emacs to receive updates
>
> This process would almost be the same as what you get just by bundling
> CEDET with Emacs except that:
>
>  - You can get the latest CEDET *if* you have the latest Emacs

No. We have two branches: emacs-25 and master. The CEDET from master
will usually not work on any 25.x version.

>  - The version of CEDET for any particular version of Emacs is as far as
>CEDET got before the next release of Emacs came out
>
> If this is what you were thinking of then please could you elaborate on
> what ended up being the problem which added more work.

First off, CEDET is currently *not* a package, although that notion gets
thrown around a lot. It is scattered across the Emacs code base:
lisp/cedet, admin/grammars, etc/srecode, documentation, and test
suite. All this needs to be packaged in a way so that it can be
integrated into Emacs during a normal checkout. It needs to build and
test in such a normal checkout, but also separately when installed from
ELPA, including grammar compilation. And you need this twice: one for
emacs-25, one for master, with the possiblity to merge between the two.

Then there's this "registry". No one has said how that should
work. "Submodules/Subtrees" are *not* a sufficient answer, they are just
tools. People will need to say how the *workflow* should be, including
such things like merges from stable, ChangeLog generation, AUTHORS,
NEWS, creating release tarballs, and so on. Once someone has written
this down *in detail*, we can discuss again if this indeed will make
things simpler and reduce our workload.

> I feel like there are aspects of CEDET which are still under
> development.

I hope so.

>> Well, we cannot really discuss this since there's no real plan how this
>> all should work. I can only speak from experience.
>
> We can still put ideas forward though.  Haven't come up with anything
> myself yet though.

Yes, you can, but it has a cost. Once again, the CEDET merge is stalled,
and we spend our time writing mails. I find this situation incredibly
frustrating.

>> How does CEDET, Gnus and Org affect the rest of Emacs? They strongly
>> depend on Emacs "core" (whatever exactly that is), not the other way
>> round.
>
> I believe that one of the intentions of the move is to enforce this so
> we can't build bad dependencies -- am I wrong?

I think other modes should use Semantic.

> Perhaps I'm wrong, but to my mind the package approach would afford us
> with more testing before we get to the point of another release of
> Emacs.

If you develop on Emacs 'master', you can use all the new features (like
threading and FFI), but you loose testers on 25.x. A package won't
change that.

-David

[O] Encryption

[David Diem]

Hi all,

on Android, is there a combination of either

1.a. mobileorg
b. mobileorgNG 

on the one hand and

2.a. APG
b. OpenKeyChain 
c. GPG

on the other, and 

3.a. :crypt:
b. header crypt comment

in Emacs

... that works for people here?

I have tried all (combinations) over and over.

Best wishes
David (on CyanogenMod 13 and Lineage 14 on a bacon (1+1))


 Ursprüngliche Nachricht 
Von: emacs-orgmode-requ...@gnu.org
Gesendet: 6. Februar 2017 18:00:19 MEZ
An: emacs-orgmode@gnu.org
Betreff: Emacs-orgmode Digest, Vol 132, Issue 6

Send Emacs-orgmode mailing list submissions to
emacs-orgmode@gnu.org

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.gnu.org/mailman/listinfo/emacs-orgmode
or, via email, send a message with subject or body 'help' to
emacs-orgmode-requ...@gnu.org

You can reach the person managing the list at
emacs-orgmode-ow...@gnu.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Emacs-orgmode digest..."


Today's Topics:

   1. Help checking orgcard.pdf (Kyle Meyer)
   2. Behavior of `org-show-entry' (Eric Abrahamsen)
   3. Re: Help checking orgcard.pdf (Kaushal Modi)
   4. Re: Help checking orgcard.pdf (Kyle Meyer)
   5. Re: Help checking orgcard.pdf (Kaushal Modi)
   6. Re: Help checking orgcard.pdf (Kyle Meyer)
   7. Re: Bug: org-agenda-only-exact-dates [9.0.4 (9.0.4-elpa @
  c:/Users/atamulis/.emacs.d/elpa/org-20170124/)] (Tamulis, Andrius)
   8. Re: Behavior of `org-show-entry' (Kyle Meyer)
   9. Re: Behavior of `org-show-entry' (Eric Abrahamsen)
  10. Re: Bug in clocktable report with formula % (Andreas Mueller)
  11. Re: Behavior of `org-show-entry' (Kyle Meyer)
  12. org-time-stamp, day format (Uwe Brauer)
  13. Re: Allowing multiple date trees in a single file
  (Nicolas Goaziou)
  14. Re: Behavior of `org-show-entry' (Nicolas Goaziou)
  15. Re: Bug: org-agenda-only-exact-dates [9.0.4 (9.0.4-elpa @
  c:/Users/atamulis/.emacs.d/elpa/org-20170124/)] (Nicolas Goaziou)
  16. Re: Feature request: lists with letters (Rasmus)
  17. No priority cookies in html export despite setting pri:t
  option (Gez)
  18. just saw this: orgzly code source available now on github
  (Xebar Saram)
  19. Re: Sync up the org in emacs master to org maint branch?
  (Phillip Lord)
  20. Re: just saw this: orgzly code source available now on github
  (Kaushal Modi)


--

Message: 1
Date: Sun, 05 Feb 2017 12:03:18 -0500
From: Kyle Meyer 
To: Org-mode 
Subject: [O] Help checking orgcard.pdf
Message-ID: <8760koh8o9@kyleam.com>
Content-Type: text/plain; charset="us-ascii"

Hello,

On the maint branch, doc/orgcard.tex lists the Org version as 8.2.  I'd
like to bump this to 9.

It'd be helpful if a few people could look at a topic or two that they
are familiar with and report back about whether things look up-to-date.
The card on the website [*] is still stuck at 7.8.11, so I've attached
one built from the maint branch.

Thanks.

[*] http://orgmode.org/orgcard.pdf

-- next part --
A non-text attachment was scrubbed...
Name: orgcard.pdf
Type: application/pdf
Size: 118968 bytes
Desc: not available
URL: 

-- next part --

Re: [O] org-time-stamp, day format

[Uwe Brauer]

> On Monday,  6 Feb 2017 at 09:35, Uwe Brauer wrote:

> I think you'll find that these come from the standard time format, using
> %a for day of the week.  This will depend on your locale I guess?
Hm

I am on Ubuntu 14.04 with the tcsh shell
and locale gives me

locale
LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC=es_ES.UTF-8
LC_TIME=es_ES.UTF-8
LC_COLLATE="en_US.UTF-8"
LC_MONETARY=es_ES.UTF-8
LC_MESSAGES="en_US.UTF-8"
LC_PAPER=es_ES.UTF-8
LC_NAME=es_ES.UTF-8
LC_ADDRESS=es_ES.UTF-8
LC_TELEPHONE=es_ES.UTF-8
LC_MEASUREMENT=es_ES.UTF-8
LC_IDENTIFICATION=es_ES.UTF-8
LC_ALL=

So I presume it is
LC_TIME=es_ES.UTF-8

No idea that is was set up like this do you know by change
how and where can I change that?

Thanks

Uwe 

Re: [O] Bug: org-agenda-only-exact-dates [9.0.4 (9.0.4-elpa @ c:/Users/atamulis/.emacs.d/elpa/org-20170124/)]

[Tamulis, Andrius]

I tried it - it turns out that org-agenda-todo-ignore-deadlines only 
effects the global todo list.


Andrius

On 2017-02-06 07:17, Nicolas Goaziou wrote:

Hello,

"Tamulis, Andrius"  writes:


I had not read the docstring, but now I have, and I interpret it
differently than you did. As, it seems, did the people who coded it.
I want a zero value for org-deadline-warning-days, as I want no
warnings of future deadlines. But I also do not want notification of
deadlines that are past due, and that's not what
org-deadline-warning-days is for.

I was talking about `org-agenda-todo-ignore-deadlines' not
`org-deadline-warning-days'.

It would only apply to deadlines with a TODO keyword, tho.

Regards,

[O] org-time-stamp, day format

[Uwe Brauer]

Hello

When I use org-time-stamp. I obtain:

 <2016-11-15 mar>

mar is short for martes, which is the Spanish word for Tuesday. How can
I can change that format, to any language I desire? I thought it would
be calendar-day-name-array but this seems not to be the case.

Thanks

Uwe Brauer