Re: [O] Bleeding edge in elpa

[Achim Gratz]

Richard Y. Kim writes:
> # server.mk has the elpaplus makefile target
> echo " include mk/server.mk" >> Makefile
[…]
> # Undo the change made above
> git checkout Makefile

You know, local.mk was introduced specifically so you wouldn't have to
do anything like that.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: [O] Citation syntax: a revised proposal

[Aaron Ecay]

Hello all,

I’ve pushed an update to my branch.  The major change is to use
citeproc-java for the generation of the bibliography and the parsing of
names.  The former is straightforward.  For the latter, I have created a
CSL file which outputs author-year citations in an easy-to-parse format.
These are then slurped by org, and used to fill in printf-style
templates.  Some people mentioned using citations as generated by
citeproc-java directly.  However, I don’t believe this is reliable since
(as also mentioned), it is difficult to control whether a certain style
uses parentheses around a citation or not, whether the citation is
capitalized*, the insertion of prefixes/suffixes within the parentheses,
etc.  So I think the only solution is to implement the formatting of the
in-text portion of citations ourselves, and use citeproc-java only to
extract authors and years.

* NB neither my branch nor the parser currently handles capitalized
  citations either.

Using citeproc gives us for free sophisticated disambiguation of authors
that share a last name (by adding first initial) or works by the same
author in the same year (by adding a letter suffix to the year).

My code still does not implement numeric or footnote citations.

It’s hard to keep straight all of the traffic in citation-related
threads.  I’ll try to respond to what I see as the major points raised,
but I apologize if I inadvertently skip something.

Some people have talked about supporting other CSL processors.  I don’t
see much utility in that, since CSL is a standard that all processors
should implement faithfully.  I judge the java implementation to be the
most complete and cross-platform.  With respect to Zotero, it is possible,
through the “lookup” facility I’ve implemented, to implement fetching of
bibliography data from Zotero.  I merely do not want to talk to Zotero (or
other tools) for the *formatting* of the data.

Rasmus  writes about the
insertion of punctuation by biblatex.  I’ve noticed it too, and it’s a
thorny problem.  Perhaps the best and easiest solution is to say that
org-latex documents must do \renewcommand{\postnotedelim}{} in their
preamble.  (Thanks also to Rasmus for discussion of points I raised in
previous mails about reftex and org syntax.  I have no specific reply
but the responses were all extremely helpful.  I haven’t had time to act
on any of them because I’ve been concentrating on citeproc support.)

I haven’t updated the branch to the new multicitation syntax yet, but
thanks as always to Nicolas for working on it.  I think that is next on
my list, along with getting biblatex support completely ironed out.

I have not had much time to study Vaidheeswaran’s jabref integration
code.  In any case I would be hesitant to do so until there is
confirmation of the code’s copyright status, since he(?) sometimes posts
to the mailing list using an email address belonging to Jambunathan,
who at some points in the past was not willing to provide copyright
assignment.  However, it would be good to know:
1. Is any important functionality lost by using citeproc-java as the CSL
   processor, rather than jabref?
2. Is it possible to support for implement importing citations from
   jabref through the “lookup types” facility in my code?
3. How are citations formatted for export to ODT?  An example of the
   ODT/XML code for something like “as demonstrated by Smith (2015)”,
   where “Smith (2015)” has whatever fancy formatting a citation is
   expected to have in ODT, would be helpful.

I’m sorry that I do not have enough time to both work on the code and
participate very much in the discussion.  But reading it has been quite
helpful to me in creating the code, so thank you all.

Finally, the attachments demonstrate the output from ascii export of a
sample document + bibliography (in org-bibtex format).

Aaron Ecay





1 Section one
=

  Here is a citation (Smith 2015) .

  Here is another with parens J. Doe (2016b).

  Here is one with a prefix and suffix (see Smith 2015 and other such
  works).

  Here is one with a prefix and suffix and parens see Smith (2015 and
  other such works).

  Here’s a citation to demonstrate the disambiguation of names: (B. Doe
  2016) .

  And the disambiguation of years: (J. Doe 2016a) .


2 Bibliography
==

  Currently the bibliography keyword doesn’t create its own section.

  - Doe, Bill. 2016. “Work Three.”
  - Doe, Jane. 2016a. “Work Two Bis.”
  - ———. 2016b. “Work Two.”
  - Smith, John. 2015. “Work One.”


doc.org
Description: Lotus Organizer


bib.org
Description: Lotus Organizer

--
Aaron Ecay

Re: [O] [PATCH] Re: autoloads not working correctly for org-table.el?

[Eric Abrahamsen]

Eric Abrahamsen  writes:

> Eric Abrahamsen  writes:
>
>> Eric S Fraga  writes:
>>
>>> On Wednesday,  4 Mar 2015 at 17:28, Eric Abrahamsen wrote:
>>>
>>> [...]
>>>
 I'm still seeing an issue where, if I start right off typing a big
 paragraph of text at the top of the message (no salutation or anything),
 all the lines *after* the first line are indented by one tab. Subsequent
 paragraphs are unaffected.
>>>
>>> Hi Eric,
>>>
>>> I had this problem for a long time.  It disappeared a some time ago now
>>> and I have no idea why.  However, while I had the problem, I trained
>>> myself to always start an email (that was not a response like this one)
>>> with some form of salutation!  More polite as well as avoiding the bug
>>> :)
>>
>> Well, sure :) I guess I'll try being politer!
>>
>> I just poked around a little bit, edebugging
>> `org-adaptive-fill-function'. I looked at the call to
>> `fill-context-prefix' two-thirds of the way down. I tested this with the
>> last email I sent, and I see that calling `org-adaptive-fill-function'
>> on the first paragraph results in `fill-context-prefix' being called
>> with the arguments 1 (the post-affiliated arg), and 447 (the end
>> position of the first paragraph). The result of that call is a tab.
>>
>> If I move to the second paragraph and do the same thing, the
>> post-affiliated arg was 447, and the end position is 475. The result of
>> that call was nil, which is probably what I wanted.
>>
>> My value of adaptive-fill-regexp, in this case is:
>>
>> "\\(\\([ ]*[_.[:word:]]+>+\\|[   ]*[]>|]\\)+\\)[ ]*\\|[
>> ]*\\([-–!|#%;>*·•‣⁃◦]+[  ]*\\)*"
>>
>> I will poke further as time allows. I don't know much about filling (and
>> have never understood what "post-affiliated" actually means), but assume
>> I can eventually get to the bottom of it...
>>
>> E
>
> It looks like the problem was that all the message headers are parsed as
> though they were part of the first paragraph of message body text. Why
> that should result in a secondary TAB indent I don't know, but
> regardless, Org probably should only be looking at the message body, and
> nothing else.
>
> The attached patch is a hack that adds the `mail-header-separator'
> regexp to the `org-element-paragraph-separate' regexp. That means it
> will only work for paragraphs, so there might still be weirdness if a
> message body starts with a list or what have you.
>
> Perhaps a better solution would be to narrow to the body of the message
> before doing the fill prefix calculation.
>
> Eric

And just for the heck of it, here's another patch that does it with
narrowing.

E

>From c51cdb35453ae8c2964508fc1e98b89e6c709abb Mon Sep 17 00:00:00 2001
From: Eric Abrahamsen 
Date: Tue, 10 Mar 2015 11:03:23 +0800
Subject: [PATCH] Narrow to message body when filling in message mode

* lisp/org.el (org-adaptive-fill-function): Only take the message body
  into account when calculating the fill prefix.
---
 lisp/org.el | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/lisp/org.el b/lisp/org.el
index c566152..cf952ad 100755
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -23015,6 +23015,12 @@ matches in paragraphs or comments, use it."
 	  ((looking-at org-outline-regexp)
 	   (throw 'exit (make-string (length (match-string 0)) ?\s))
 (org-with-wide-buffer
+ (when (derived-mode-p 'message-mode)
+   (save-excursion
+	 (goto-char (point-min))
+	 (when (re-search-forward mail-header-separator)
+	   (narrow-to-region
+	(line-beginning-position 2) (point-max)
  (unless (org-at-heading-p)
(let* ((p (line-beginning-position))
 	  (element (save-excursion
-- 
2.3.2

[O] [PATCH] Re: autoloads not working correctly for org-table.el?

[Eric Abrahamsen]

Eric Abrahamsen  writes:

> Eric S Fraga  writes:
>
>> On Wednesday,  4 Mar 2015 at 17:28, Eric Abrahamsen wrote:
>>
>> [...]
>>
>>> I'm still seeing an issue where, if I start right off typing a big
>>> paragraph of text at the top of the message (no salutation or anything),
>>> all the lines *after* the first line are indented by one tab. Subsequent
>>> paragraphs are unaffected.
>>
>> Hi Eric,
>>
>> I had this problem for a long time.  It disappeared a some time ago now
>> and I have no idea why.  However, while I had the problem, I trained
>> myself to always start an email (that was not a response like this one)
>> with some form of salutation!  More polite as well as avoiding the bug
>> :)
>
> Well, sure :) I guess I'll try being politer!
>
> I just poked around a little bit, edebugging
> `org-adaptive-fill-function'. I looked at the call to
> `fill-context-prefix' two-thirds of the way down. I tested this with the
> last email I sent, and I see that calling `org-adaptive-fill-function'
> on the first paragraph results in `fill-context-prefix' being called
> with the arguments 1 (the post-affiliated arg), and 447 (the end
> position of the first paragraph). The result of that call is a tab.
>
> If I move to the second paragraph and do the same thing, the
> post-affiliated arg was 447, and the end position is 475. The result of
> that call was nil, which is probably what I wanted.
>
> My value of adaptive-fill-regexp, in this case is:
>
> "\\(\\([  ]*[_.[:word:]]+>+\\|[   ]*[]>|]\\)+\\)[ ]*\\|[
> ]*\\([-–!|#%;>*·•‣⁃◦]+[   ]*\\)*"
>
> I will poke further as time allows. I don't know much about filling (and
> have never understood what "post-affiliated" actually means), but assume
> I can eventually get to the bottom of it...
>
> E

It looks like the problem was that all the message headers are parsed as
though they were part of the first paragraph of message body text. Why
that should result in a secondary TAB indent I don't know, but
regardless, Org probably should only be looking at the message body, and
nothing else.

The attached patch is a hack that adds the `mail-header-separator'
regexp to the `org-element-paragraph-separate' regexp. That means it
will only work for paragraphs, so there might still be weirdness if a
message body starts with a list or what have you.

Perhaps a better solution would be to narrow to the body of the message
before doing the fill prefix calculation.

Eric

>From cb65e1b8adad54e6fc72c1eddb79efa644abbfc0 Mon Sep 17 00:00:00 2001
From: Eric Abrahamsen 
Date: Tue, 10 Mar 2015 10:08:24 +0800
Subject: [PATCH] Change paragraph boundaries in message mode

* lisp/org.el (org-adaptive-fill-function): The value of
  `mail-header-separator' should count as a paragraph separator.
---
 lisp/org.el | 5 +
 1 file changed, 5 insertions(+)

diff --git a/lisp/org.el b/lisp/org.el
index c566152..4f32e35 100755
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -23017,6 +23017,11 @@ matches in paragraphs or comments, use it."
 (org-with-wide-buffer
  (unless (org-at-heading-p)
(let* ((p (line-beginning-position))
+	  (org-element-paragraph-separate
+	   (if (derived-mode-p 'message-mode)
+		   (concat org-element-paragraph-separate
+			   "\\|" mail-header-separator)
+		 org-element-paragraph-separate))
 	  (element (save-excursion
 			 (beginning-of-line)
 			 (org-element-at-point)))
-- 
2.3.2

Re: [O] Multiple (identical) RESULTS blocks of one code block?

[Aaron Ecay]

Hi Rainer,

2015ko martxoak 9an, Rainer M Krug-ek idatzi zuen:
>
> Hi
>
> Consider the following:
>
> --8<---cut here---start->8---
> * The calculation
> #+NAME: testcode :exports both

It looks like you’ve tried to put a header argument into the name.  Is
it merely an accident?  I ask because...

> #+begin_src R  :session test
> runif(10)
> #+end_src
>
>
> * summary of the results
> First time
> #+RESULTS: testcode :exports both
> |  0.772744940361008 |
> |  0.170518629485741 |
> | 0.0833237133920193 |
> |  0.149035625392571 |
> |  0.698798568220809 |
> |  0.627075897762552 |
> |  0.177144371205941 |
> | 0.0476319056469947 |
> |  0.289851602632552 |
> | 0.0296813279855996 |
>
> * and another
> testthingy
> #+RESULTS: testcode :exports both

...here it reoccurs, in identical format.  This is fine, interpreted
as just a weird block name (and not as an actual header argument).
But if you’re trying to allow the header arguments to vary for the two
result blocks I don’t think it will be very nice.  (It would require
re-evaluating the code block for each different combination of header
arguments, which would give unexpected behavior in the case of side
effects, etc. etc.)

Maybe it’s not very important, but I just figured I’d ask for
clarification.

Thanks,

--
Aaron Ecay

Re: [O] Bleeding edge in elpa

[Richard Y. Kim]

tftor...@tftorrey.com (T.F. Torrey) writes:

> I wonder how much effort it would take to copy onto my own machine the
> scripts on the server that package the git maint version into an ELPA
> version, and modify them to package master instead.  Probably not much.

The shell script below is what I use to create my own org-plus-contrib
ELPA package.

Rather than relying on elpa.gnu.org, melpa.org, orgmode.org/elpa, etc.,
I've been creating my own packages over the past year or so.  This way I
know exactly which packages are installed in not only my emacs, but my
colleagues who use my packages.  So far this has worked out great for
me.


#!/bin/sh

# This script builds org-plus-contrib-MMDD.tar ELPA package from the git
# clone of org-mode.

if [ ! -f mk/server.mk ]; then
  echo "Current directory must be org-mode root directory"
  exit 1
fi

# Where to install the tarballs 
SERVROOT=$HOME/public_html/elpa/orgmode

# server.mk has the elpaplus makefile target
echo " include mk/server.mk" >> Makefile

make SERVROOT=$SERVROOT elpaplus elpaplus-up

# Undo the change made above
git checkout Makefile
rm -f archive-contents

# $SERVROOT/org-plus-contrib-MMDD.tar
# should now be created with today as value of MMDD.

Re: [O] Bleeding edge in elpa

[Aaron Ecay]

Hi Terry,

2015ko martxoak 9an, "T.F. Torrey"-ek idatzi zuen:
>
> Hello,
>
> Rasmus  writes:
>
>> As I think somebody said, the correct "fix" to this problem is more
>> frequent released.  I'm sure Bastien would appreciate help with this.
>> Do you want to volunteer?
>
> If the goal is to have the latest and greatest version of Org available via
> ELPA (for all the reasons some people use ELPA instead of git), there
> are two obvious options:
>
> 1. Org could have a stable release every month or so.
>
> 2. The Org server could be configured to automatically package the
> master version of Org every day, as the maint version is now.
>
> Option 1 is widely regarded as the best choice.  However, it requires a
> lot of actual, repeated human effort.  As Debian repeatedly
> demonstrates, this is very hard to do, even once.  If option 1 could be
> done, it would already be done.
>
> Option 2 would be a one-time (mostly) human effort, and the daily work
> would be automated.

But what would not be automated is the actual human effort that goes into
making a release: writing NEWS and documentation for new features, testing
for regressions, generating the emacs Changelog files, merging changes
from emacs trunk back into to org code base, merging org code into emacs
trunk, ...  Someone still has to do all those things eventually.  Or not,
and the quality of org as a software product suffers.

--
Aaron Ecay

Re: [O] Citation syntax: Underscore MUST(?) be allowed in cite keys?

[Richard Lawrence]

Hi Eric and all,

Eric S Fraga  writes:

> On Monday,  9 Mar 2015 at 09:05, Richard Lawrence wrote:
>
>> Another option would be to allow clause-ending punctuation in all keys,
>> but introduce some kind of optional syntax to express `this key ends
>
> No, please no!  I would say that the majority of my citations are at the
> end of sentences...  I would end up having to use this additional syntax
> frequently.  I'd rather use syntax to disambiguate the less frequent
> cases and keys with punctuation are those (for me, at least).

I feel the same as you do about this, so here's one more thought for the
thread.  How about this alternative?

We keep the existing syntax for keys, which disallows key-ending
punctuation, but we also allow a second style of key, in which curly
braces surround the key name proper, like:

  @{Doe1999}

Then we can conceivably allow any character at all between the braces,
including punctuation (except `}', which is also a restriction on LaTeX
keys).  That means this type of key should be able to accommodate just
about anything the future may bring.

The opening `{' immediately after the `@' will make this type of key
easy for the parser to distinguish from the first type, and the closing
`}' makes the end of the key unambiguous with respect to following
punctuation.

Tools that insert keys from citation managers can check whether a key
respects the brace-less syntax, and offer to insert it using the second
style when it doesn't.  Or they could be configured to always use this
style, if the user prefers.

And anyone who doesn't need to disambiguate keys from punctuation can
use the brace-less style, which (in my opinion) is easier to read and
type.

What do people think?  

Best,
Richard

Re: [O] Citation syntax: Underscore MUST(?) be allowed in cite keys?

[Rasmus]

Richard Lawrence  writes:

> Oh dear, you're right.  Where do that initial comma and space come from?
> I guess BibLaTeX inserts them automatically?  Does that happen in all
> styles?

The default value is determined by \postnotedelim.  So assuming spaces not
stripped \renewcommand{\postnotedelim}{} would probably work in most
cases.  More fancily one could check the next space like xspace.  There's
a mighty cool example using higher level functions here:

  
http://tex.stackexchange.com/questions/125358/automating-processing-of-trailing-punctuation-if-any-for-hyperlinks

> From what I can see, Pandoc does not implicitly insert punctuation like
> this:
>
>   As @Fenner2012a [, cf. sec. 2] showed ...
>
> renders as
>
>   As Fenner (2012, cf. sec. 2) showed ...

I prefer the biblatex behavior then.

> Can you turn off the automatic addition of commas in BibLaTeX by setting
> something in the preamble?

Preamble or using \AtNextCite

> If so, would that be the right solution here?  It might be easier to
> remove punctuation on the LaTeX side than to get other backends to
> duplicate LaTeX's implicit punctuating behavior.

Perhaps.  Either looks like the famous can of worms.  I guess we should
promote the option above in the manual and that's it.


-- 
However beautiful the theory, you should occasionally look at the evidence

Re: [O] [PATCH] Adding a BEAMER_HEADER_EXTRA tag, allows short titles, etc.

[Rasmus]

Hi Matthew,

Matthew Gidden  writes:

Thanks for the patch.

> I ran into the issue that many others have cited: an inability to add short
> titles, etc., to org-mode-generated Beamer presentations [1, 2, 3]. This
> patch allows such capability through a BEAMER_HEADER_EXTRA tag, which is
> placed after title, author, etc., but before `\begin{document}`.  Short
> titles, for example, can now be added via
>
> ```
> #+BEAMER_HEADER_EXTRA: \title[A Short Title]{ \inserttitle }
> ```

>From you patch, it seems that you want to adds something akin
to #+LATEX_HEADER or #+LATEX_HEADER_EXTRA.  IOW there's no formatting
going on and these lines expect raw latex code.

Could you not get the same by using org-latex-classes?  Or at the latex
level solution could presumably be archived with etoolbox.  Anyway,
another keyword doesn't hurt anybody.

—Rasmus

-- 
It was you, Jezebel, it was you

Re: [O] [PATCH] Adding a BEAMER_HEADER_EXTRA tag, allows short titles, etc.

[Matthew Gidden]

HI Nic,



On Mon, Mar 9, 2015 at 6:19 PM, Nicolas Goaziou 
wrote:

> Hello,
>
> Matthew Gidden  writes:
>
> > I ran into the issue that many others have cited: an inability to add
> short
> > titles, etc. to org-mode-generated Beamer presentations [1, 2, 3]. This
> > patch allows such capability through a BEAMER_HEADER_EXTRA tag, which is
> > placed after title, author, etc., but before `\begin{document}`.  Short
> > titles, for example, can now be added via
> >
> > ```
> > #+BEAMER_HEADER_EXTRA: \title[A Short Title]{ \inserttitle }
> > ```
>
> Thanks for the patch.
>
> BEAMER_HEADER_EXTRA is not a good name, as LATEX_HEADER_EXTRA means
> something entirely different. If it's just about short titles, we could
> add a BEAMER_SHORT_TITLE keyword.
>
> However what is in the "etc." above?

In many outerthemes (i.e., the beamer header and footer formatting), the
"short" version of title, author, institution, and date are used. While
this is the (my) primary use case I can think of, the positioning
BEAMER_HEADER_EXTRA serves as final preamble
injection point. I just reread your discussion with Sebastien [1] and agree
the proposed name is bad.

>From what I can tell, the current ox-beamer.el does not support beamer's
institution macor or the short version of title, author, institution or
date. I can think of two options to get around this:

   - do not use #+Title, etc., and simply use BEAMER_HEADER or similar
   - use #+Title plus something like this patch to inject fixes *after*
   \title

As a user, I prefer the latter, because it maximizes the portability of my
code (so I can use something like org-reveal [2]).

Another option would be to simply move BEAMER_HEADER to inject code where I
have implemented BEAMER_HEADER_EXTRA. That would provide the same
functionality with a reasonable name. I still need to better format my
commit message (I forgot to before submitting), so I can make any other
updates that are deemed necessary.

Let me know what you (and others) think.

Cheers,
Matt

[1] http://comments.gmane.org/gmane.emacs.orgmode/78582
[2]
http://orgmode.org/worg/org-tutorials/non-beamer-presentations.html#sec-6

>
>
> Regards,
>
> --
> Nicolas Goaziou
>



-- 
Matthew Gidden
Ph.D. Candidate, Nuclear Engineering
The University of Wisconsin -- Madison
Ph. 225.892.3192

Re: [O] Internal Links with Spaces

[John Kitchin]

I think you need to set

(setq org-id-link-to-org-use-id 'create-if-interactive)

Then the usual C-c l and C-c C-l should work to store links and insert
them.

It might be worth noting though, that in my experience, this is most
useful for links within a file, or to files in your agenda list. org does not
have a good way to find an id in a non-agenda file if that file is not
already open. Although there should be a .org-id-locations file
somewhere that stores this mapping of id to file. I have not experienced
100% success with this.

Also, you have to be a little cautious about copying a headline to
another place, because then you have two ids in different places.

anyway, the point is try it out and see if it works for you ;)

Jacob Gerlach writes:

> On Mon, Mar 9, 2015 at 10:38 AM, Leo Ufimtsev  wrote:
>> On the side, if of any help:
>>
>> I generally use ID's for linking to headings.
>> The benefit is that headings can be re-named safley and links still work.
>
> A great suggestion. I wasn't aware of the feature, and renaming safety
> is a great benefit while also solving my space problem.
>
> I don't suppose there's a trick to automatically update descriptions
> for links whose target has been renamed?
>
> When exploring this, I found the function org-id-store-link. This
> seemed like what I wanted - it creates a custom ID if one doesn't
> exist, but it doesn't actually store a link (or at least, it wasn't
> available when I then ran org-insert-link). The docstring is pretty
> light, but it seems like this might be a bug. Is this the expected
> behavior?
>
> Thanks for the pointer in any case.
>
> Regards,
> Jake

--
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu

Re: [O] [PATCH] Adding a BEAMER_HEADER_EXTRA tag, allows short titles, etc.

[Nicolas Goaziou]

Hello,

Matthew Gidden  writes:

> I ran into the issue that many others have cited: an inability to add short
> titles, etc. to org-mode-generated Beamer presentations [1, 2, 3]. This
> patch allows such capability through a BEAMER_HEADER_EXTRA tag, which is
> placed after title, author, etc., but before `\begin{document}`.  Short
> titles, for example, can now be added via
>
> ```
> #+BEAMER_HEADER_EXTRA: \title[A Short Title]{ \inserttitle }
> ```

Thanks for the patch. 

BEAMER_HEADER_EXTRA is not a good name, as LATEX_HEADER_EXTRA means
something entirely different. If it's just about short titles, we could
add a BEAMER_SHORT_TITLE keyword.

However what is in the "etc." above?


Regards,

-- 
Nicolas Goaziou

Re: [O] Citation syntax: Underscore MUST(?) be allowed in cite keys?

[Richard Lawrence]

Rasmus  writes:

> Richard Lawrence  writes:
>
>> Suppose you often write citations like:
>>
>>   [cite: See @Doe99, and references therein, for more.]
>>
>> [...]  and rendered like:
>>
>>   See Doe (1999), and references therein, for more.
>  
> This is slightly OT, but it comes up frequently enough that it's worth
> pointing out.  Assuming we were to handle notes as biblatex (which would
> be the better thing to do IMO), the output of:
>
>  [cite: See @Doe99, and references therein, for more.]
> Aka: \textcite[See][, and references therein, for more.]{Doe99}
>
> is
>
> Aksn et al. (See 2006, , and references therein, for more.)
>  ^^

Oh dear, you're right.  Where do that initial comma and space come from?
I guess BibLaTeX inserts them automatically?  Does that happen in all
styles?

>From what I can see, Pandoc does not implicitly insert punctuation like
this:

  As @Fenner2012a [, cf. sec. 2] showed ...

renders as

  As Fenner (2012, cf. sec. 2) showed ...
  
Can you turn off the automatic addition of commas in BibLaTeX by setting
something in the preamble?  If so, would that be the right solution
here?  It might be easier to remove punctuation on the LaTeX side than
to get other backends to duplicate LaTeX's implicit punctuating
behavior.

Best,
Richard

[O] [PATCH] Adding a BEAMER_HEADER_EXTRA tag, allows short titles, etc.

[Matthew Gidden]

Hi folks,

I ran into the issue that many others have cited: an inability to add short
titles, etc., to org-mode-generated Beamer presentations [1, 2, 3]. This
patch allows such capability through a BEAMER_HEADER_EXTRA tag, which is
placed after title, author, etc., but before `\begin{document}`.  Short
titles, for example, can now be added via

```
#+BEAMER_HEADER_EXTRA: \title[A Short Title]{ \inserttitle }
```

Something like this appears to have been in the original org-beamer.el, but
was not present in the current master HEAD ox-beamer.el. If the
community/BD deems this to be worthy, I'd be happy to clean it up as needed.

Cheers,
Matt

[1] http://comments.gmane.org/gmane.emacs.orgmode/57450
[2] https://lists.gnu.org/archive/html/emacs-orgmode/2011-01/msg00176.html
[3]
http://stackoverflow.com/questions/26760125/org-mode-beamer-how-to-create-a-short-title-author-date


-- 
Matthew Gidden
Ph.D. Candidate, Nuclear Engineering
The University of Wisconsin -- Madison
Ph. 225.892.3192
From e666fc06512dad866a10dd763c3d42117dfff31f Mon Sep 17 00:00:00 2001
From: Matthew Gidden 
Date: Mon, 9 Mar 2015 16:25:15 -0500
Subject: [PATCH] adds a BEAMER_HEADER_EXTRA tag that can be used to inject
 code after title, author, etc. but before \begin{document}

---
 lisp/ox-beamer.el | 23 ++-
 1 file changed, 14 insertions(+), 9 deletions(-)

diff --git a/lisp/ox-beamer.el b/lisp/ox-beamer.el
index e10d36c..d15e5b0 100644
--- a/lisp/ox-beamer.el
+++ b/lisp/ox-beamer.el
@@ -239,7 +239,8 @@ Return overlay specification, as a string, or nil."
 (:beamer-font-theme "BEAMER_FONT_THEME" nil nil t)
 (:beamer-inner-theme "BEAMER_INNER_THEME" nil nil t)
 (:beamer-outer-theme "BEAMER_OUTER_THEME" nil nil t)
-(:beamer-header-extra "BEAMER_HEADER" nil nil newline)
+(:beamer-header "BEAMER_HEADER" nil nil newline)
+(:beamer-header-extra "BEAMER_HEADER_EXTRA" nil nil newline)
 (:beamer-environments-extra nil nil org-beamer-environments-extra)
 (:beamer-frame-default-options nil nil org-beamer-frame-default-options)
 (:beamer-outline-frame-options nil nil org-beamer-outline-frame-options)
@@ -826,7 +827,7 @@ holding export options."
 		  (plist-get info :latex-header))
 		 (org-element-normalize-string
 		  (plist-get info :latex-header-extra))
-		 (plist-get info :beamer-header-extra)
+		 (plist-get info :beamer-header)
 	  info)))
  ;; 3. Insert themes.
  (let ((format-theme
@@ -866,16 +867,20 @@ holding export options."
(format "\\date{%s}\n" (org-export-data date info)))
  ;; 7. Title
  (format "\\title{%s}\n" title)
- ;; 8. Hyperref options.
+ ;; 8. Beamer-header-extras
+ (let ((beamer-header-extra (plist-get info :beamer-header-extra)))
+   (when beamer-header-extra
+	 (format "%s\n" (plist-get info :beamer-header-extra
+ ;; 9. Hyperref options.
  (when (plist-get info :latex-hyperref-p)
(format "\\hypersetup{\n  pdfkeywords={%s},\n  pdfsubject={%s},\n  pdfcreator={%s}}\n"
 	   (or (plist-get info :keywords) "")
 	   (or (plist-get info :description) "")
 	   (if (not (plist-get info :with-creator)) ""
 		 (plist-get info :creator
- ;; 9. Document start.
+ ;; 10. Document start.
  "\\begin{document}\n\n"
- ;; 10. Title command.
+ ;; 11. Title command.
  (org-element-normalize-string
   (cond ((not (plist-get info :with-title)) nil)
 	((string= "" title) nil)
@@ -884,7 +889,7 @@ holding export options."
 			   org-latex-title-command)
 	 (format org-latex-title-command title))
 	(t org-latex-title-command)))
- ;; 11. Table of contents.
+ ;; 12. Table of contents.
  (let ((depth (plist-get info :with-toc)))
(when depth
 	 (concat
@@ -896,16 +901,16 @@ holding export options."
 	(format "\\setcounter{tocdepth}{%d}\n" depth))
 	  "\\tableofcontents\n"
 	  "\\end{frame}\n\n")))
- ;; 12. Document's body.
+ ;; 13. Document's body.
  contents
- ;; 13. Creator.
+ ;; 14. Creator.
  (let ((creator-info (plist-get info :with-creator)))
(cond
 	((not creator-info) "")
 	((eq creator-info 'comment)
 	 (format "%% %s\n" (plist-get info :creator)))
 	(t (concat (plist-get info :creator) "\n"
- ;; 14. Document end.
+ ;; 15. Document end.
  "\\end{document}")))
 
 
-- 
1.9.1

Re: [O] Citation syntax: Underscore MUST(?) be allowed in cite keys?

[Rasmus]

Richard Lawrence  writes:

> Suppose you often write citations like:
>
>   [cite: See @Doe99, and references therein, for more.]
>
> [...]  and rendered like:
>
>   See Doe (1999), and references therein, for more.
 
This is slightly OT, but it comes up frequently enough that it's worth
pointing out.  Assuming we were to handle notes as biblatex (which would
be the better thing to do IMO), the output of:

 [cite: See @Doe99, and references therein, for more.]
Aka: \textcite[See][, and references therein, for more.]{Doe99}

is

Aksn et al. (See 2006, ,and references therein, for more.)

To get "See Doe (1999), and references therein, for more." one would
write:

  See @doe99, and references therein, for more.
Or:   See \textcite{doe99}, and references therein, for more.

The output of [(cite): See @Doe99, and references therein, for more.] is

  (See Doe 1999, ,and references therein, for more)
or:   \parencite[See][,and references therein, for more]{doe99}

—Rasmus

-- 
This space is left intentionally blank
\documentclass{article}
\usepackage[style=authoryear]{biblatex}
\addbibresource{biblatex-examples.bib}
\begin{document}
\textcite[See][,and references therein, for more.]{aksin}\par
\textcites(pre)(post)[See][,and references therein, for more.]{aksin}[See][,and references therein, for more.]{angenendt}\par
\parencite[See][,and references therein, for more.]{aksin}\par
\parencites(pre)(post)[See][,and references therein, for more.]{aksin}[See][,and references therein, for more.]{angenendt}\par
\end{document}

Re: [O] Internal Links with Spaces

[Jacob Gerlach]

On Mon, Mar 9, 2015 at 10:38 AM, Leo Ufimtsev  wrote:
> On the side, if of any help:
>
> I generally use ID's for linking to headings.
> The benefit is that headings can be re-named safley and links still work.

A great suggestion. I wasn't aware of the feature, and renaming safety
is a great benefit while also solving my space problem.

I don't suppose there's a trick to automatically update descriptions
for links whose target has been renamed?

When exploring this, I found the function org-id-store-link. This
seemed like what I wanted - it creates a custom ID if one doesn't
exist, but it doesn't actually store a link (or at least, it wasn't
available when I then ran org-insert-link). The docstring is pretty
light, but it seems like this might be a bug. Is this the expected
behavior?

Thanks for the pointer in any case.

Regards,
Jake

Re: [O] [bug?] org-repair-property-drawers does not repair whole file

[Gregor Zattler]

Hi Nicolas, org-mode developers and users,
* Nicolas Goaziou  [09. Mar. 2015]:
> Gregor Zattler  writes:
> I see invalid property drawers, e.g.,
> 
>   > :PROPERTIES:
>   > :Xxxx: Xxx, xx Xxx  xx:xx:xx +
>   > :Xxxx: Xxx Xx 
>   > :Xxx-XX: 
>   > :Xxx: XXX XXX - XX xx xx.xx. - Xx xx. xx:xx
>   > :Xx: Xx Xx , Xxx Xx , 
> Xx  Xx , X X , X 
> X  , X Xxxx , X 
> Xxxx  , Xxx Xx , Xxx X 
> Xxxx  , Xxxx Xxxx , Xxx X  
> , Xx Xxx , Xxx X  
> , X Xx , Xxx X  
> , Xxxx Xxxx , X Xxxx  
> 
>   > :Xxxx: X XXXxxx,
>   >xx xx.x. xxx xxx xxx X xxx XXX.

[... 17 lines deleted ...]
>   >Xxx
>   > :END:
> 
> A property drawer can contain only node properties, and there is one
> node property per line.

As you might guess this part represents an email, the multi line
node being the message body.  How would one incorporate such
info in proper org-mode syntax?  Since as of now I do not query
the name=value pairs this is no strict necessity for me.

Is there a syntax checker for org-mode files?

> Ill-formed property drawers were not moved.

Thanks for your explanation and time spent, Gregor

Re: [O] Citation syntax: Underscore MUST(?) be allowed in cite keys?

[Eric S Fraga]

On Monday,  9 Mar 2015 at 08:44, Thomas S. Dye wrote:

[...]

> No, you have it right and clearly have a use for shortcuts.  If you want
> to type shortcut citations yourself, then the choice is either to accept
> some kind of terminator, e.g. {}, or a restriction that citation keys
> not end in punctuation characters.

Well, I think it's important to consider user interface issues.  Simple
things should be simple to do and common activities likewise.  Only if
there is a conflict should we need to choose.  Given that most citations
are unlikely to end in punctuation, the easy to use syntax should be for
the majority cases and should not need to cater for punctuation.

I would hate to have to type {} at the end of every simple citation,
especially as I suffer from RSI and those characters are particularly
annoying...

> It's been years since I've actually typed in a citation.  Reftex and
> Ebib both do a flawless job and I rely on them completely now.
> Shortcuts aren't useful in this work flow.

True but this doesn't obviate the need to consider non-automated input.

In any case, none of the decisions need affect me should I dislike the
solution actually implemented in the end.  That's the great thing about
org and plain text!

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org 
release_8.3beta-843-ga5f1a3.dirty

Re: [O] Bleeding edge in elpa

[T.F. Torrey]

Achim Gratz  writes:

> The version of package manager that people most likely use today always
> choses the latest version from _any_ archive available when you update.
> You can't tell it to consider some archive more authoritative than
> another or that it should stick with whatever source archive the package
> was originally installed from.

Of course.  My explanation was worded poorly, because instead of
sleeping I was wasting my time supporting someone else's request to be
able to get the latest version of Org via ELPA.

>> The current daily builds are here:
> […]
>
> That sort of contorsionist gymnastics defeats the whole point of having
> a package manager in the first place.  If every package would have to do
> that we'd all end up juggling dozens of archives in our config files.

The guidance for using Org via ELPA is already to "add the
Orgmode.org/elpa archive" (paraphrased).  Changing that to "add
Orgmode.org/elpa-stable for the stable version or
Orgmode.org/elpa-unstable for the bleeding edge version" is suddenly
contortionist gymnastics?  Really?  Compared to using git?

>> If the next version of Emacs breaks Org out of core into the GNU ELPA
>> package archive, things can be even easier:  Keep the stable version in
>> the GNU package archive, and keep the unstable version in the archive on
>> the orgmode.org server.
>
> I wouldn't hold my breath.  At the moment that mechanism by which to do
> that is certainly not in place and there's no agreement on what it
> should look like.

Agreement or not, something will be done.  Already the mechanisms are in
place that put the maint version in both locations.  The biggest
obstacle I to this that I see is that developers tend to hate the
package manager and love git.

>> (And personally, I think the "contrib" parts should either be merged
>> into the core or split into separate packages, but that's another can of
>> worms.)
>
> if you want to move things into core, clean those files up, create tests
> and get the copyrights assignmed to the FSF by their authors and propose
> their inclusion.
>
> If you want separate packages, I'm quite certain that this needs further
> modifications at least to some of the files.  The current mode of
> operation is that they should be compiled together with the rest of Org
> and no checks are made if they work if installed sepaerately.  Some of
> them likely do, others probably not.

Yes, either choice would be an effort.

However, there is currently the problem that some packages depend on
org, and others on org-plus-contrib, which cause both to be installed
(without some controtionist gymnastics).  IMHO, the Org package at
Orgmode.org/elpa should either always include contrib, as the git
repository does, or split the contrib part into an org-contrib package
that depends on org.

All the best,
Terry
-- 
T.F. Torrey

Re: [O] Citation syntax: Underscore MUST(?) be allowed in cite keys?

[Richard Lawrence]

Hi Tom and all,

"Thomas S. Dye"  writes:

> The problem is limited to the shortcut citations and doesn't affect the
> [cite: ...] form, which can be expected to work without modification
> wherever it is placed IIUC.

Actually, it occurs to me now that this might even affect the [cite:
...] form, depending on how you use the prefix and suffix text.

Suppose you often write citations like:

  [cite: See @Doe99, and references therein, for more.]

For readability's sake, I would hope this would be parsed by default as:
  - prefix: 'See '
  - key: 'Doe99'
  - suffix: ', and references therein, for more.'

and rendered like:

  See Doe (1999), and references therein, for more.

I can imagine similar cases at least for periods, colons, and
semi-colons (though those would have to be written as entities here), so
maybe we cannot avoid this problem just by changing or removing the
shortcut syntax.

Best,
Richard

Re: [O] Citation syntax: Underscore MUST(?) be allowed in cite keys?

[Thomas S. Dye]

Eric S Fraga  writes:

> On Monday,  9 Mar 2015 at 07:49, Thomas S. Dye wrote:
>
> [...]
>
>> Do you have a use for the shortcuts?  I doubt I'd use them.
>
> Wouldn't the shortcut be the most attractive to use generally unless you
> have need for the extra capability of the full [cite:] syntax?
>
> The vast majority of my citations, e.g. in a paper I am writing right
> now in org, are of the form [[cite:blah-etal-2010a]] and it would be
> much easier to type @blah-etal-2010a.  I seldom, if ever, have pre or
> post text in my citations.
>
> Or have I misunderstood something in this *very* long thread?  (which I
> have been following as a lurker so far... :)

No, you have it right and clearly have a use for shortcuts.  If you want
to type shortcut citations yourself, then the choice is either to accept
some kind of terminator, e.g. {}, or a restriction that citation keys
not end in punctuation characters.

It's been years since I've actually typed in a citation.  Reftex and
Ebib both do a flawless job and I rely on them completely now.
Shortcuts aren't useful in this work flow.

All the best,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com

Re: [O] Bleeding edge in elpa

[Achim Gratz]

T.F. Torrey writes:
> The package manager can only handle one version of a package *per
> archive*, so instead use one archive per version.

The version of package manager that people most likely use today always
choses the latest version from _any_ archive available when you update.
You can't tell it to consider some archive more authoritative than
another or that it should stick with whatever source archive the package
was originally installed from.

> The current daily builds are here:
[…]

That sort of contorsionist gymnastics defeats the whole point of having
a package manager in the first place.  If every package would have to do
that we'd all end up juggling dozens of archives in our config files.

> If the next version of Emacs breaks Org out of core into the GNU ELPA
> package archive, things can be even easier:  Keep the stable version in
> the GNU package archive, and keep the unstable version in the archive on
> the orgmode.org server.

I wouldn't hold my breath.  At the moment that mechanism by which to do
that is certainly not in place and there's no agreement on what it
should look like.

> (And personally, I think the "contrib" parts should either be merged
> into the core or split into separate packages, but that's another can of
> worms.)

if you want to move things into core, clean those files up, create tests
and get the copyrights assignmed to the FSF by their authors and propose
their inclusion.

If you want separate packages, I'm quite certain that this needs further
modifications at least to some of the files.  The current mode of
operation is that they should be compiled together with the rest of Org
and no checks are made if they work if installed sepaerately.  Some of
them likely do, others probably not.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: [O] Citation syntax: Underscore MUST(?) be allowed in cite keys?

[Eric S Fraga]

On Monday,  9 Mar 2015 at 07:49, Thomas S. Dye wrote:

[...]

> Do you have a use for the shortcuts?  I doubt I'd use them.

Wouldn't the shortcut be the most attractive to use generally unless you
have need for the extra capability of the full [cite:] syntax?

The vast majority of my citations, e.g. in a paper I am writing right
now in org, are of the form [[cite:blah-etal-2010a]] and it would be
much easier to type @blah-etal-2010a.  I seldom, if ever, have pre or
post text in my citations.

Or have I misunderstood something in this *very* long thread?  (which I
have been following as a lurker so far... :)

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org 
release_8.3beta-843-ga5f1a3.dirty

Re: [O] Citation syntax: Underscore MUST(?) be allowed in cite keys?

[Thomas S. Dye]

Aloha Eric,

Eric S Fraga  writes:

> On Monday,  9 Mar 2015 at 09:05, Richard Lawrence wrote:
>
> [...]
>
>> Another option would be to allow clause-ending punctuation in all keys,
>> but introduce some kind of optional syntax to express `this key ends
>
> No, please no!  I would say that the majority of my citations are at the
> end of sentences...  I would end up having to use this additional syntax
> frequently.  I'd rather use syntax to disambiguate the less frequent
> cases and keys with punctuation are those (for me, at least).

The problem is limited to the shortcut citations and doesn't affect the
[cite: ...] form, which can be expected to work without modification
wherever it is placed IIUC.

Do you have a use for the shortcuts?  I doubt I'd use them.

All the best,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com

Re: [O] Citation syntax: Underscore MUST(?) be allowed in cite keys?

[Eric S Fraga]

On Monday,  9 Mar 2015 at 09:05, Richard Lawrence wrote:

[...]

> Another option would be to allow clause-ending punctuation in all keys,
> but introduce some kind of optional syntax to express `this key ends

No, please no!  I would say that the majority of my citations are at the
end of sentences...  I would end up having to use this additional syntax
frequently.  I'd rather use syntax to disambiguate the less frequent
cases and keys with punctuation are those (for me, at least).

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org 
release_8.3beta-843-ga5f1a3.dirty

Re: [O] [bug?] org-repair-property-drawers does not repair whole file

[Nicolas Goaziou]

Gregor Zattler  writes:

> No.  I removed the line numbers so that the stars of the headings
> are at the first column and invoced `org-repair-property-drawers'
> in the same way as described above.  The buffer remains
> unmodified and the output is `nil'.

I cannot reproduce it.

>> Is it possible to have access to the file? You might want to hide
>> contents first with the following function
>> 
>> (defun scramble-contents ()
>
> Yes.  I scrambled it with your function, changed tags (which were
> not scrambled by `scramble-contents') and obfuscated clock lines.
> The result is attached.

I see invalid property drawers, e.g.,

  > :PROPERTIES:
  > :Xxxx: Xxx, xx Xxx  xx:xx:xx +
  > :Xxxx: Xxx Xx 
  > :Xxx-XX: 
  > :Xxx: XXX XXX - XX xx xx.xx. - Xx xx. xx:xx
  > :Xx: Xx Xx , Xxx Xx , 
Xx  Xx , X X , X 
X  , X Xxxx , X 
Xxxx  , Xxx Xx , Xxx X Xxxx 
 , Xxxx Xxxx , Xxx X  
, Xx Xxx , Xxx X  
, X Xx , Xxx X  
, Xxxx Xxxx , X Xxxx  

  > :Xxxx: X XXXxxx,
  >xx xx.x. xxx xxx xxx X xxx XXX.
  >Xxx xxx xxx  Xxxx xxx,  xxx Xx xxx 
X ,
  >x xxx Xxxx xx :
  >XXX xX
  >XXX xXxxx
  >XXX xXx
  >XXX xXxx xxx X - Xxx xx xxx  
xx
  >X xxx ? (Xxx x XX)
  >XXX xXxxx xxx Xxxx xxx Xx xxx Xx 
(Xxx x XX)
  >XXX xX xxx Xxx /Xxx 
 xxx XX xxx
  >XXX (Xxx x XX)
  >XXX xX xxx XXX-XXX (Xx!)  xxx 
 Xxx
  >xxx XXX (Xxx x XX)
  >XXX xX
  >Xxx xxx xxx,  xxx xx Xxxx  xxx X xx 
(xx. xx:xx,
  >xxx Xx xxx  xxx).
  >Xxx  xxx Xx, xxx xxx x (xxx)  x xxx.
  >X X xxx xxx xx Xx.
  >Xxx
  > :END:

A property drawer can contain only node properties, and there is one
node property per line.

Ill-formed property drawers were not moved.

Regards,

Re: [O] Citation syntax: Underscore MUST(?) be allowed in cite keys?

[Thomas S. Dye]

Richard Lawrence  writes:

> Hi Tom and all,
>
> "Thomas S. Dye"  writes:
>
>> Richard Lawrence  writes:
>>
>>>  But my opinion probably shouldn't count for much on this
>>> point, because I don't use a citation manager myself (I use org-bibtex),
>>> and I write my own keys.
>>
>> Oh my.  This is a lot to keep in your head as a bibliographic database
>> grows.  The one I've created with my colleagues over the last two
>> decades has more than 5,000 entries.
>
> Yes, I realize this method probably isn't going to scale well in the
> long run, but it's working for me for now.  The vast majority of my keys
> are just the author's last name plus the year.  I just write a key like
> that when I add something to my reading list, and fix the rare duplicate
> cases as necessary.
>
> (Just to explain why it makes sense to me to do it this way: I used to
> work in a psychology lab, where I had to write a lot of little programs
> to do data analysis.  The worst part of that job was always dealing with
> malformed, missing, and otherwise-corrupt data captured by someone else.
> Since then, my attitude has always been that it's much easier to correct
> that data at the point where it's captured than figure out what to do
> with it somewhere further down the processing pipeline, after the reason
> *why* it is malformed has been lost.  In the context of this discussion,
> that translates to: a work doesn't get a key in my reading list unless I
> have complete citation information for it.  Sometimes I put items on my
> reading list that I don't have citation data for yet, but I don't do
> org-bibtex-create-in-current-entry on that item until I have the
> citation data and can assign it a key.)
>

We've had a couple dozen contributors to our bibliography over the
years.  Initially, we assigned keys by hand but we found this led to
very many duplicate entries.  Generating keys has helped a lot in this
situation because most duplicates are caught when we merge the
project-specific database, which has already been edited, with the
central one.

>>> I don't disagree, but I think there is an empirical question that needs
>>> to be answered here: within the keys people actually use, how many do
>>> not conform to the syntax?  Of those that don't, do they represent
>>> `normal' cases or not?
>>
>> A good friend of mine is a military historian who writes books
>> describing how the Army habitually plans to fight the last war over
>> again, then has to adapt hurriedly when the next war turns out to be
>> different.  It strikes me that basing core features of the citation
>> syntax on the software users happen to be using today is a bit like
>> this--at some point the design of the system will prove unprepared for
>> new developments.
>>
>> I think Vaidheeswaran C's example of a citation scraped off the internet
>> with Zotero should carry a lot of weight.  This kind of thing is bound
>> to happen more and more as authors increasingly harvest citation
>> information on-line (my generation typically looks on this with horror,
>> but we'll be swept aside).
>
> That's a fair point.  
>
>> I kind of like Rasmus' idea to make the citation insertion routines
>> aware of punctuation and use a full citation where a shortcut would
>> introduce ambiguities.
>
> That would work for me.  Like Rasmus, I don't particularly like the idea
> of letting the syntax of keys vary in the shortcut case and the full
> citation case, but if the only difference is whether or not they can end
> in clause-ending punctuation, maybe this is the least-bad option.
>
> Another option would be to allow clause-ending punctuation in all keys,
> but introduce some kind of optional syntax to express `this key ends
> here'.  This could be used to disambiguate the key from any following
> punctuation in those cases where this is needed.  Perhaps something like
> '{}', since even LaTeX won't allow '}' at the end of a key, or maybe
> just '\'.  Thus, in these examples:
>
>   This is an in-text citation, as was shown by @Doe99{}. The next sentence.
>   This is an in-text citation, as was shown by @Doe99\. The next sentence.
>
> the key would be parsed as `Doe99', but in this example:
>
>   This is an in-text citation, where @Doe is mentioned mid-sentence.
>
> the key would be parsed as `Doe'.
>
> What do you think?  

The {} terminator is used elsewhere in Org mode, so it might be the
least bad option in this instance.

All the best,
Tom

-- 
T.S. Dye & Colleagues, Archaeologists
735 Bishop St, Suite 315, Honolulu, HI 96813
Tel: 808-529-0866, Fax: 808-529-0884
http://www.tsdye.com

Re: [O] Multiple (identical) RESULTS blocks of one code block?

[Nicolas Goaziou]

Hello,

Rainer M Krug  writes:

> Consider the following:
>
> * The calculation
> #+NAME: testcode :exports both
> #+begin_src R  :session test
> runif(10)
> #+end_src
>
>
> * summary of the results
> First time
> #+RESULTS: testcode :exports both
> |  0.772744940361008 |
> |  0.170518629485741 |
> | 0.0833237133920193 |
> |  0.149035625392571 |
> |  0.698798568220809 |
> |  0.627075897762552 |
> |  0.177144371205941 |
> | 0.0476319056469947 |
> |  0.289851602632552 |
> | 0.0296813279855996 |
>
> * and another
> testthingy
> #+RESULTS: testcode :exports both
>
>
> If I update the calculation, the first results block is updated, but
> not the second one. I would like to have two RESULTS blocks which
> are both updated when the code block is evaluated.
>
> Is this possible?

It isn't, but I think it is a reasonable expectation. Would you like to
provide a patch for that?


Regards,

-- 
Nicolas Goaziou

Re: [O] Bleeding edge in elpa

[T.F. Torrey]

Hello,

Sebastien Vauban  writes:

>> As Grant pointed out, it’s a lot more convenient working inside Emacs
>> for switching between versions and such.
>
> How do you switch between versions in ELPA?  IIUC, you only get the
> latest version, and if that one is not right, you're kind of stuck: you
> can't reinstall the previous version via the interface. Or maybe I have
> to learn something new?

Only one version per package name is allowed, so with everything in one
archive it won't currently work.

However, with smaller archives each holding one version, it becomes
possible.

For instance, to get the latest package of the main version of Org,
enable the Orgmode.org/elpa archive.  To go back to the slightly older,
perhaps more stable version in the GNU archive, remove the
Orgmode.org/elpa archive from your archive configuration, uninstall Org,
then reinstall it, and you will get the version from the GNU archive,
which will now be the latest one the packages system can find.

It's kind of a hack, sure, but until the package system is upgraded to
handle dependence on multiple versions of the same package, it works.
It would probably be inconvenient to do this for every package, but I
don't mind doing it for major packages like Org.

HTH,
Terry
--
T.F. Torrey

Re: [O] Citation syntax: Underscore MUST(?) be allowed in cite keys?

[Richard Lawrence]

Hi Tom and all,

"Thomas S. Dye"  writes:

> Richard Lawrence  writes:
>
>>  But my opinion probably shouldn't count for much on this
>> point, because I don't use a citation manager myself (I use org-bibtex),
>> and I write my own keys.
>
> Oh my.  This is a lot to keep in your head as a bibliographic database
> grows.  The one I've created with my colleagues over the last two
> decades has more than 5,000 entries.

Yes, I realize this method probably isn't going to scale well in the
long run, but it's working for me for now.  The vast majority of my keys
are just the author's last name plus the year.  I just write a key like
that when I add something to my reading list, and fix the rare duplicate
cases as necessary.

(Just to explain why it makes sense to me to do it this way: I used to
work in a psychology lab, where I had to write a lot of little programs
to do data analysis.  The worst part of that job was always dealing with
malformed, missing, and otherwise-corrupt data captured by someone else.
Since then, my attitude has always been that it's much easier to correct
that data at the point where it's captured than figure out what to do
with it somewhere further down the processing pipeline, after the reason
*why* it is malformed has been lost.  In the context of this discussion,
that translates to: a work doesn't get a key in my reading list unless I
have complete citation information for it.  Sometimes I put items on my
reading list that I don't have citation data for yet, but I don't do
org-bibtex-create-in-current-entry on that item until I have the
citation data and can assign it a key.)

>> I don't disagree, but I think there is an empirical question that needs
>> to be answered here: within the keys people actually use, how many do
>> not conform to the syntax?  Of those that don't, do they represent
>> `normal' cases or not?
>
> A good friend of mine is a military historian who writes books
> describing how the Army habitually plans to fight the last war over
> again, then has to adapt hurriedly when the next war turns out to be
> different.  It strikes me that basing core features of the citation
> syntax on the software users happen to be using today is a bit like
> this--at some point the design of the system will prove unprepared for
> new developments.
>
> I think Vaidheeswaran C's example of a citation scraped off the internet
> with Zotero should carry a lot of weight.  This kind of thing is bound
> to happen more and more as authors increasingly harvest citation
> information on-line (my generation typically looks on this with horror,
> but we'll be swept aside).

That's a fair point.  

> I kind of like Rasmus' idea to make the citation insertion routines
> aware of punctuation and use a full citation where a shortcut would
> introduce ambiguities.

That would work for me.  Like Rasmus, I don't particularly like the idea
of letting the syntax of keys vary in the shortcut case and the full
citation case, but if the only difference is whether or not they can end
in clause-ending punctuation, maybe this is the least-bad option.

Another option would be to allow clause-ending punctuation in all keys,
but introduce some kind of optional syntax to express `this key ends
here'.  This could be used to disambiguate the key from any following
punctuation in those cases where this is needed.  Perhaps something like
'{}', since even LaTeX won't allow '}' at the end of a key, or maybe
just '\'.  Thus, in these examples:

  This is an in-text citation, as was shown by @Doe99{}. The next sentence.
  This is an in-text citation, as was shown by @Doe99\. The next sentence.

the key would be parsed as `Doe99', but in this example:

  This is an in-text citation, where @Doe is mentioned mid-sentence.

the key would be parsed as `Doe'.

What do you think?  

Best,
Richard

Re: [O] Beamer Hello World Help Request

[Eric S Fraga]

On Sunday,  8 Mar 2015 at 10:47, Matthew Gidden wrote:
> FWIW, I was a complete noob and was exporting to a Latex PDF (C-c C-e l p)
> instead of a Beamer PDF (C-c C-e l P). Sorry for spamming the list!

No worries!  I still do this every now and again... :(  Glad you figured
it out.
-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org 
release_8.3beta-843-ga5f1a3.dirty

Re: [O] Internal Links with Spaces

[Leo Ufimtsev]

On the side, if of any help: 

I generally use ID's for linking to headings. 
The benefit is that headings can be re-named safley and links still work. 

There is an org-module called 'org-id', which when enabled in conjunction with 
the variable 
below allows you to automatically generate a unique id for the heading when you 
press C-c l and link to it with C-c C-l. 

This exports nicley also. E.g here is a unique anchor link to one of those 
unique ID's: 
http://leoufimtsev.github.io./org/swt-dev.html#ID-a636a35d-6100-4f6a-974c-6bbeedc0f2a2
 

(org-id-link-to-org-use-id (quote create-if-interactive-and-no-custom-id)) 

'(org-modules 
(quote 
(org-id ... 

Leo Ufimtsev | Intern Software Engineer @ Eclipse Team 


- Original Message -

From: "Jacob Gerlach"  
To: "Org-mode"  
Sent: Monday, March 9, 2015 9:05:40 AM 
Subject: [O] Internal Links with Spaces 

Hi List, 

I'd like to re-raise the issue discussed here . In short, storing and inserting 
an internal link to a headline containing spaces using org-store-link and 
org-insert-link causes export to fail because the space is "hexified" into %20. 

It seems like the thread died because hexifying links to support external URL's 
conflicted with internal links containing spaces with no clear path forward. 

Am I missing further discussion where this was resolved? 

If not, is a fix still possible or is this a "won't fix" because of the clash 
with external links? 

If it's "won't fix", is it possible for me to advise org-insert-link (or some 
other function) or configure some other individual hack to work around the 
problem? I never use org-insert-link for URL's, so I'd be glad to blindly stop 
hexifying even if it breaks that functionality. 

Regards, 
Jake 

Re: [O] Multiple (identical) RESULTS blocks of one code block?

[Sebastien Vauban]

John Kitchin wrote:
> Rainer M Krug writes:
>>
>> Consider the following:
>>
>> * The calculation
>> #+NAME: testcode :exports both
>> #+begin_src R  :session test
>> runif(10)
>> #+end_src
>>
>>
>> * summary of the results
>> First time
>> #+RESULTS: testcode :exports both
>> |  0.772744940361008 |
>> |  0.170518629485741 |
>> | 0.0833237133920193 |
>> |  0.149035625392571 |
>> |  0.698798568220809 |
>> |  0.627075897762552 |
>> |  0.177144371205941 |
>> | 0.0476319056469947 |
>> |  0.289851602632552 |
>> | 0.0296813279855996 |
>>
>> * and another
>> testthingy
>> #+RESULTS: testcode :exports both
>>
>> If I update the calculation, the first results block is updated, but
>> not the second one. I would like to have two RESULTS blocks which
>> are both updated when the code block is evaluated.
>>
>> Is this possible?
>
> I don't believe this is possible out of the box. The first RESULTS block
> from the beginning of the buffer will be updated, and not the others.
>
> You might be able to use a hook function to do this [...].

Another solution is to use the `echo' [1] code block to copy whatever
contents where you want it...

Best regards,
  Seb

[1] http://orgmode.org/cgit.cgi/org-mode.git/plain/doc/library-of-babel.org

-- 
Sebastien Vauban

[O] Internal Links with Spaces

[Jacob Gerlach]

Hi List,

I'd like to re-raise the issue discussed here
. In short, storing
and inserting an internal link to a headline containing spaces using
org-store-link and org-insert-link causes export to fail because the space
is "hexified" into %20.

It seems like the thread died because hexifying links to support external
URL's conflicted with internal links containing spaces with no clear path
forward.

Am I missing further discussion where this was resolved?

If not, is a fix still possible or is this a "won't fix" because of the
clash with external links?

If it's "won't fix", is it possible for me to advise org-insert-link (or
some other function) or configure some other individual hack to work around
the problem? I never use org-insert-link for URL's, so I'd be glad to
blindly stop hexifying even if it breaks that functionality.

Regards,
Jake

Re: [O] Multiple (identical) RESULTS blocks of one code block?

[John Kitchin]

I don't believe this is possible out of the box. The first RESULTS block
from the beginning of the buffer will be updated, and not the others.

You might be able to use a hook function to do this, something like:

#+BEGIN_SRC emacs-lisp
(defun update-results () (interactive)
  ;; get name of src block
  (let ((name (org-element-property :name (org-element-at-point)))
(results))
(when name
  (org-element-map (org-element-parse-buffer) 'fixed-width
(lambda (object)
  (if results
  ;; replace value in block
  (setf
   (buffer-substring
(org-element-property :begin  object)
(org-element-property :end  object))
   results)
;; set results
(setq results
  (buffer-substring
   (org-element-property :begin  object)
   (org-element-property :end  object)
#+END_SRC


#+BEGIN_SRC emacs-lisp
(add-hook 'org-babel-after-execute-hook 'update-results)
#+END_SRC

This worked on a small test example, but I did not test it
thoroughly. your mileage might vary ;)


Rainer M Krug writes:

> Hi
>
> Consider the following:
>
> --8<---cut here---start->8---
> * The calculation
> #+NAME: testcode :exports both
> #+begin_src R  :session test
> runif(10)
> #+end_src
>
>
> * summary of the results
> First time
> #+RESULTS: testcode :exports both
> |  0.772744940361008 |
> |  0.170518629485741 |
> | 0.0833237133920193 |
> |  0.149035625392571 |
> |  0.698798568220809 |
> |  0.627075897762552 |
> |  0.177144371205941 |
> | 0.0476319056469947 |
> |  0.289851602632552 |
> | 0.0296813279855996 |
>
> * and another
> testthingy
> #+RESULTS: testcode :exports both
>
> --8<---cut here---end--->8---
>
> If I update the calculation, the first results block is updated, but
> not the second one. I would like to have two RESULTS blocks which
> are both updated when the code block is evaluated.
>
> Is this possible?
>
> Thanks,
>
> Rainer

--
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu

Re: [O] Citation syntax: Underscore MUST(?) be allowed in cite keys?

[Stefan Nobis]

Vaidheeswaran C  writes:

> By saying "bibtex is not a requirement",

I said "exporting to bibtex". You talked about Zotero but showed a
bibtex entry. Therefore exporting from Zotero to bibtex may not
be a requirement, there may be a direct interface to Zotero,
eventually.

We are at the start of the development, we are currently CUTTING EDGE!
Therefore tool support (hopefully including guides to configure
citation managers) will evolve in the future.

My main point is: You found a single example that *may* be a problem
with the current syntax. But there are multiple software packages
involved (Zotero, Zotero to bibtex exporter, org-mode, etc.). The
citation syntax will never be able to handle all of the possible
problems in a longer chain of tools. Sometimes its better to fix a
problem at the start of in the middle of this chain.

IMHO it's a good idea to constrain the syntax for keys a little bit
(no whitespace, no arbitrary unicode character, no punctuation at the
end etc.). If in some cases the default configuration of the involved
tools will create invalid keys, than the configuration should be fixed
instead of dropping constraints for the key syntax.

> I hope you don't mean to imply that bibtex users are any less
> blessed or less holy or that their needs wouldn't be "readily"
> catered to.

I am a bibtex user. :)

I want to say, that it is impossible to accomodate for all the
citations managers with any possible configurations of them. Sometimes
we have to state: This case is not supported, please adjust your
configuration.

-- 
Until the next mail...,
Stefan.

Re: [O] [bug?] org-repair-property-drawers does not repair whole file

[Gregor Zattler]

Hi Nicolas,
* Nicolas Goaziou  [08. Mar. 2015]:
> Gregor Zattler  writes:
> 
>> Sadly no: I reapplied `org-repair-property-drawers' on my org
>> file with no customisation at all:
>>
>> emacs-snapshot -Q -nw -L /home/grfz/src/org-mode/lisp/ file.org 
>> ~/src/org-mode/etc/ORG-NEWS
>>
>> I loaded `org-repair-property-drawers' from
>> ~/src/org-mode/etc/ORG-NEWS and executed it in file.org.  Result
>> is ’(nil nil nil nil nil nil nil nil nil nil nil nil ... )’ and
>> the buffer file.org remains unmodified.
> 
> Doesn't the function fix the "anon" file you sent?

No.  I removed the line numbers so that the stars of the headings
are at the first column and invoced `org-repair-property-drawers'
in the same way as described above.  The buffer remains
unmodified and the output is `nil'.

> Is it possible to have access to the file? You might want to hide
> contents first with the following function
> 
> (defun scramble-contents ()

Yes.  I scrambled it with your function, changed tags (which were
not scrambled by `scramble-contents') and obfuscated clock lines.
The result is attached.

Thanks for looking into this, but if it’s only me: It would be
not much work to clean up the file by hand.

Gregor


scrambled.org.gz
Description: application/gzip

Re: [O] Citation syntax: Underscore MUST(?) be allowed in cite keys?

[Rasmus]

Vaidheeswaran C  writes:

> Believe me, if I had quick access to pandoc-hs, there would be a
> ox-pandoc-citeproc already in the tree by now.

My opinion would be to perhaps not put too much energy into anything
Haskell.  It's extremely annoying when you don't have the luxury of
prebuild packages.  E.g. on Arch there's no prebuild pandoc and ghc is
800MB!  Extrapolating from git-annex getting the right dependencies (down
to version-number, sometimes) seem like a mess with cabal.

—Rasmus

-- 
C is for Cookie

Re: [O] Citation syntax: a revised proposal

[Vaidheeswaran C]

On Monday 09 March 2015 04:10 PM, Sebastien Vauban wrote:
> What is <<<...>>>?

(info "(org) Radio targets")

Re: [O] Citation syntax: Underscore MUST(?) be allowed in cite keys?

[Vaidheeswaran C]

On Monday 09 March 2015 03:19 PM, Stefan Nobis wrote:
> Vaidheeswaran C  writes:
> 
>> On Monday 09 March 2015 02:27 PM, Stefan Nobis wrote:
> 
>>> IMHO keys with lots of ??? in them are a sign of a data problem.
>>> Therefore the author should solve the root cause.
> 
>> Not in the specific case that I cited. The Bib entry is a pointer to
>> a website.
> 
> I would say, even a website needs a date (in this case: date last
> seen). :)
> 
> IMHO here you are mixing two different things: We already talked about
> direct support for Zotero as a backend, CSL etc. Therefore exporting
> to bibtex is not a requirement. 

When you say requirement, it is a good idea to say "requirement to
which parties or requirement in which context".

I am running Debian Squeeze.  The pandoc that gets bundled with this
debian version doesn't support citeproc stuff.  IIRC, to upgrade to
recent pandoc I would have to update one of the core haskell
libraries.  I am reluctant to upgrade my debian.  Believe me, if I had
quick access to pandoc-hs, there would be a ox-pandoc-citeproc already
in the tree by now.  (No I am not joking.)

The spririt of Free Software (and definitely Emacs) is to ACCOMODATE
MULTIPLE SIMULTANEOUS implementations of same functionality.  One good
example is a todo-mode.el (which ships by default on Emacs).  I would
venture to say, obsoleting a package is taboo.

By saying "bibtex is not a requirement", I hope you don't mean to
imply that bibtex users are any less blessed or less holy or that
their needs wouldn't be "readily" catered to.

(My intention is NOT to fight with you.  I am merely emphasizing that
pandoc/haskell is a recent development and there are some practical
problems associated with making THIS CUTTING EDGE package a
REQUIREMENT that other ORG USERS MUST depend on.  You can call me a
lazy bum!)

> Maybe the best way is to add a new export module to Zotero for even
> better org integration and handle correct keys in this module?
> 
> IMHO it's the job of the citation manager to generate sane keys, not
> the job of org to accept arbitrary keys.
> 
>> If you had shared how I can configure Zotero to leave out the
>> question marks that would have been the most helpful comment from
>> your side.
> 
> I'm not a Zotero expert, I even don't use it. But with a quick look at
> Google I found this:
> 
>   http://curiousjason.com/zoterotobibtex.html
> 
> (in the Firefox profile there is a configuration file
> zotero/translators/BibTeX.js that needs to be edited; the above source
> is from 2010 - maybe today there is a GUI to edit this setting).

Thanks.

Re: [O] Babel: RESULTS for no value

[Jarmo Hurri]

Greetings Charles.

"Charles C. Berry"  writes:

>> To achieve this behaviour, I have set
>>
>> (defvar org-babel-default-header-args:processing
>>  '((:results . "html") (:exports . "results"))
>>  "Default arguments when evaluating a Processing source block.")
>
> I think you can replace
>
> : (:results . "html")
>
> with
>
> : (:results . (or (and org-export-current-backend "html")  "none"))
>
> in your defvar and get the desired result.

Yes indeed, brilliant. Not being familiar with all the internals it was
difficult for me to know what to check and when the test can be
evaluated.

Thanks!

Jarmo

Re: [O] Citation syntax: a revised proposal

[Sebastien Vauban]

Hello Nicolas,

Nicolas Goaziou wrote:
> Honestly, Org is already full of cryptic symbols, e.g., {{{...}}}
> @@...@@, <<<>>>, <<...>>, and so on. This is not worse than the
> rest of Org.

What is <<<...>>>?

PS- Not easy to search for that in the Org manual in Emacs: neither <<
nor <<< are in the index, though I know about the first one (Noweb).

PPS- Before, I could use C-s to go through pages which would contain
 <<. Now, I don't know if that's because of a change on my side,
 that does not work anymore...

Best regards,
  Seb

-- 
Sebastien Vauban

[O] Multiple (identical) RESULTS blocks of one code block?

[Rainer M Krug]

Hi

Consider the following:

--8<---cut here---start->8---
* The calculation
#+NAME: testcode :exports both
#+begin_src R  :session test
runif(10)
#+end_src


* summary of the results
First time
#+RESULTS: testcode :exports both
|  0.772744940361008 |
|  0.170518629485741 |
| 0.0833237133920193 |
|  0.149035625392571 |
|  0.698798568220809 |
|  0.627075897762552 |
|  0.177144371205941 |
| 0.0476319056469947 |
|  0.289851602632552 |
| 0.0296813279855996 |

* and another
testthingy
#+RESULTS: testcode :exports both

--8<---cut here---end--->8---

If I update the calculation, the first results block is updated, but
not the second one. I would like to have two RESULTS blocks which
are both updated when the code block is evaluated.

Is this possible?

Thanks,

Rainer

-- 
Rainer M. Krug
email: Rainerkrugsde
PGP: 0x0F52F982


signature.asc
Description: PGP signature

Re: [O] Citation syntax: Underscore MUST(?) be allowed in cite keys?

[Stefan Nobis]

Vaidheeswaran C  writes:

> On Monday 09 March 2015 02:27 PM, Stefan Nobis wrote:

>> IMHO keys with lots of ??? in them are a sign of a data problem.
>> Therefore the author should solve the root cause.

> Not in the specific case that I cited. The Bib entry is a pointer to
> a website.

I would say, even a website needs a date (in this case: date last
seen). :)

IMHO here you are mixing two different things: We already talked about
direct support for Zotero as a backend, CSL etc. Therefore exporting
to bibtex is not a requirement. If you use bibtex as the primary
source and Zotero only as a tool to fetch references from the web,
then its easy to edit the key in bibtex.

Maybe the best way is to add a new export module to Zotero for even
better org integration and handle correct keys in this module?

IMHO it's the job of the citation manager to generate sane keys, not
the job of org to accept arbitrary keys.

> If you had shared how I can configure Zotero to leave out the
> question marks that would have been the most helpful comment from
> your side.

I'm not a Zotero expert, I even don't use it. But with a quick look at
Google I found this:

  http://curiousjason.com/zoterotobibtex.html

(in the Firefox profile there is a configuration file
zotero/translators/BibTeX.js that needs to be edited; the above source
is from 2010 - maybe today there is a GUI to edit this setting).

-- 
Until the next mail...,
Stefan.

Re: [O] Citation syntax: Underscore MUST(?) be allowed in cite keys?

[Vaidheeswaran C]

On Monday 09 March 2015 02:27 PM, Stefan Nobis wrote:

> IMHO keys with lots of ??? in them are a sign of a data problem.
> Therefore the author should solve the root cause.

@misc{center_for_history_and_new_media_zotero_,
title = {Zotero {Quick} {Start} {Guide}},
url = {http://zotero.org/support/quick_start_guide},
author = {{Center for History and New Media}},
annote = {Welcome to Zotero!View the Quick Start Guide to learn how to
begin collecting, managing, citing, and sharing your research
sources.Thanks for installing Zotero.}
}

Not in the specific case that I cited.  The Bib entry is a pointer to
a website.  Insisting on a YEAR field for a website address seems a
bit absurd to me.  The problem is not the "data problem" but the
"problem" could be in the "the inherent nature of the object that is
cited".

My argument is: "Stock LaTeX exporter does it, so Org should also
follow suit".  This argument is difficult to beat without resorting to
vague generalities and hand waves.

When I discuss a problem with a specific example, I would like the
participants to pay attention to the DETAILS of the specific example
and make their comments relevant to the example being discussed.

If you had shared how I can configure Zotero to leave out the question
marks that would have been the most helpful comment from your side.

Anyways

Re: [O] Bleeding edge in elpa

[Sebastien Vauban]

Nikolai Weibull wrote:
> On Sat, Mar 7, 2015 at 3:47 PM, Xavier Maillard  wrote:
>> Nikolai Weibull  writes:
>
>>> Would it be of interest to anyone else if the bleeding edge version
>>> was available via elpa?
>
>> Isn't it already available via M-x package interface ?
>
> No, only the version based on the maint branch is available via elpa.
>
>> I'd rather use git (I really do not like the package stuff).
>
> As Grant pointed out, it’s a lot more convenient working inside Emacs
> for switching between versions and such.

How do you switch between versions in ELPA?  IIUC, you only get the
latest version, and if that one is not right, you're kind of stuck: you
can't reinstall the previous version via the interface. Or maybe I have
to learn something new?

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [O] Citation syntax: Underscore MUST(?) be allowed in cite keys?

[Stefan Nobis]

t...@tsdye.com (Thomas S. Dye) writes:

> It strikes me that basing core features of the citation syntax on
> the software users happen to be using today is a bit like this--at
> some point the design of the system will prove unprepared for new
> developments.

I don't think this is a big problem. We are talking about citation
managers, that already have to interface to different word processors.
They have to be configurable. Also, I don't think it makes any sense
for developers of citation engines to generate keys with random signs.

On the other hand, if we want to be really liberal in terms of keys,
we must allow whitespace, arbitrary unicode values etc. In this case,
its a hard problem to delimit the key because any character we use as
delimiter (like <>, ``, "", etc.) may be used inside the key.

So some constraints for the key are always necessary. I don't know
every citation manager out there but I'm quite confident that all of
them are quite configurable and that keys containing whitespace or
ending in punctuation characters are really corner cases that could
and should be handled in the citation manager.

IMHO keys with lots of ??? in them are a sign of a data problem.
Therefore the author should solve the root cause.

-- 
Until the next mail...,
Stefan.

Re: [O] Bleeding edge in elpa

[T.F. Torrey]

Hello,

Achim Gratz  writes:

> It doesn't get any easier than it already is.  Having both a stable and
> an unstable version of Org avilable via ELPA is a non-starter for the
> simple reason that the package manager can't deal with the versioning
> problems this would introduce.

I think this is not only not a "non-starter", I think it is very easy
with the existing package manager.

The package manager can only handle one version of a package *per
archive*, so instead use one archive per version.

The current daily builds are here:

http://orgmode.org/elpa/

To allow choosing between stable (maint) and unstable (master), put the
package archives here instead:

Stable: http://orgmode.org/elpa-stable/

Unstable: http://orgmode.org/elpa-unstable/

Then, just add-to-list 'package-archives whichever flavor you want.

(And actually, to do away with the current conflict between the org and
org-plus-contrib packages, each of those should be in a separate
archive as well.)

If the next version of Emacs breaks Org out of core into the GNU ELPA
package archive, things can be even easier:  Keep the stable version in
the GNU package archive, and keep the unstable version in the archive on
the orgmode.org server.

(And personally, I think the "contrib" parts should either be merged
into the core or split into separate packages, but that's another can of
worms.)

All the best,
Terry
--
T.F. Torrey

Re: [O] Bleeding edge in elpa

[T.F. Torrey]

Hello again,

Rasmus  writes:

>> I want to collaborate on Org files with my wife and parents,
> ^^^
> 
> Do you?  It sounds cool!

It's complicated.

I've convinced my parents to begin writing memoir-type books, and my
wife works in non-profit, where good books are always good solutions.  I
push them toward using plain text files for the benefits we all know,
and because I can turn the files into epub books, Kindle books, and PDF
print books using my custom Org export code.

I would love to introduce them to the awesomeness of Org.  I think they
could work in Emacs, and I'm sure they could handle updating things via
ELPA, but I'm also pretty sure that the sight of git would send them
screaming all the way back to Microsoft Word.

At the same time, I don't want to use or write my custom code for an old
version of Org, and the files produced by the maint and master versions
of Org are slightly incompatible.

So.  The current process is for them to use Markdown formatting in their
plain-text files.  At least these can be converted with a quick script
(and Calibre's ebook-convert) to epub, Kindle, and pdf versions.  These
are okay, but not great.  For "final" versions, I will need to convert
the Markdown down Org using Pandoc, then do the pretty exports using my
Manuscript package.  This is not a solution.  This is a labor-intensive,
error-prone hack.

I would so much prefer to get them into Emacs and Org.  And I could, if
the master version was availble through ELPA.

>> In a real-world situation, I want to collaborate on Org files with my
>> wife and parents, and I want to use the current best version of Org
>> (which has significant improvements to #+INCLUDE that I use), but I do
>> not want to try to install git on their Windows machines,
>
> I agree.  I have the same problem when I build documents (via CI) on a
> remote Debian server where I don't want to mess around with anything more
> than what comes with Emacs by default.

This is another great use-case for an ELPA version of the git master.

>> Serious Org users are already forced to install and run git to use the
>> master version, and whatever the dangers, the practice is almost
>> completely without problems.  A "bleeding edge" ELPA would merely make
>> that simpler.
>
> I understand that in Emacs 25 Org, Company, Gnus, CEDET and maybe a couple
> of other packages will move to GNU ELPA and thus separate release channels
> (these packages will still be bundled with Emacs).  This means we can push
> out new versions easily, making more frequent releases more attractive.
> Again, if you want to help out with preparing releases just let the list
> and Bastien now.

I'm looking forward to this new arrangement (though it will be
interesting when, AFAIK, Gnus still doesn't have a workflow through
ELPA).  However, I don't see how this will make it easier to push out
new stable releases.  That still has the inherent problem that making
something called a "stable" version takes a lot of human effort.

I wonder how much effort it would take to copy onto my own machine the
scripts on the server that package the git maint version into an ELPA
version, and modify them to package master instead.  Probably not much.
I could host that on my own server, or maybe upload it to Melpa.  I
think I will look into that.

All the best,
Terry
--
T.F. Torrey

Re: [O] Bleeding edge in elpa

[T.F. Torrey]

Hello again,

Achim Gratz  writes:

> Rasmus writes:
>> I agree.  I have the same problem when I build documents (via CI) on a
>> remote Debian server where I don't want to mess around with anything more
>> than what comes with Emacs by default.
>
> You can use a tarball and the support for manual builds, described in:
> http://orgmode.org/worg/dev/org-build-system.html#sec-7

I think there is even an existing way to automate the whole process,
isn't there?  Org is awesome.

But still, we were looking for an ELPA solution, not just a different
workaround.

>> I understand that in Emacs 25 Org, Company, Gnus, CEDET and maybe a couple
>> of other packages will move to GNU ELPA and thus separate release channels
>> (these packages will still be bundled with Emacs).  This means we can push
>> out new versions easily, making more frequent releases more
>> attractive.
>
> None of this is going to lift one core limitation of package manager:
> "there can be only one".  It doesn't support packages that subsume other
> packages, so "org-whatever" is totally different from "org" and would be
> installed together when referenced by dependencies even though it makes
> no sense.

I wrote in my other e-mail that the limit is one per archive, but I
don't think that's technically true.  I think you can actually have as
many as you want, even from the same archive, but only the one with the
newest date (actually, greatest file name) will be installed.

So, to make all the packages that depend on Org use the unstable version
rather than the stable version, add-to-list 'package-archives the
unstable archive rather than the stable archive.

And if you want to keep have both the GNU archive and the Orgmode.org
archive in your package-archives, and you want to have the unstable
version from Orgmode.org installed instead of the stable version from
the GNU archive, no problem:  The one in the GNU archive has an older
date because the unstable one on the Orgmode.org server gets updates
every day, and thus the package manager will select that one to install.

IIUC,
Terry
--
T.F. Torrey

Re: [O] Bleeding edge in elpa

[T.F. Torrey]

Hello,

Rasmus  writes:

> As I think somebody said, the correct "fix" to this problem is more
> frequent released.  I'm sure Bastien would appreciate help with this.
> Do you want to volunteer?

If the goal is to have the latest and greatest version of Org available via
ELPA (for all the reasons some people use ELPA instead of git), there
are two obvious options:

1. Org could have a stable release every month or so.

2. The Org server could be configured to automatically package the
master version of Org every day, as the maint version is now.

Option 1 is widely regarded as the best choice.  However, it requires a
lot of actual, repeated human effort.  As Debian repeatedly
demonstrates, this is very hard to do, even once.  If option 1 could be
done, it would already be done.

Option 2 would be a one-time (mostly) human effort, and the daily work
would be automated.

So, if the goal is to have the latest and greates version of Org
available via ELPA (and it should be), option 2 is the only one that is
possible in the real world, so that's the one we should set up.

All the best,
Terry
--
T.F. Torrey

Re: [O] Zotero csl file that uses parenthetical style for citations

[Vaidheeswaran C]

On Monday 09 March 2015 12:04 PM, Thomas S. Dye wrote:

> I'm happy to have you here and look forward to your contributions to Org
> mode. I hope you enjoy the community as much as I do.  I think Org mode
> rocks.

Thanks a lot.