Re: [O] problem with org-capture

[Matt Lundin]

Eric S Fraga  writes:

> Hello again,
>
> at the risk of again raising an issue that is actually my fault :-(, I
> am having a problem with org-capture.  I have been using the same
> templates for yonks but, all of a sudden, my templates don't work.  For
> instance,
>
> #+begin_src emacs-lisp
>   (setq org-capture-templates
> '(("t" "todo" entry (file+datetree "~/s/notes/tasks.org")
>"* TODO %^{Task} %^G\nSCHEDULED: %t\n%i%?")))
> #+end_src
>
> I do not get prompted for the task nor asked for tags.
>
> I do see that there have been changes recently to org-capture and a few
> emails flying by regarding recursive captures but I didn't think they
> applied to my use cases...  I could be wrong.
>
> Any pointers to what I need to change to get things working again would
> be most welcome!

I can confirm this bug. None of the prompt shortcuts work in capture
templates. For instance, the following capture template...

(setq org-capture-templates
  '(("a" "Appointment" entry
 (file "~/org/inbox.org") "* %^{Appt}\n %^t%?\n %U\n %i")))

...simply inserts the following in a buffer without any prompts or
expansion...

* %^{Appt}
 %^t
 [2015-12-01 Tue 14:51]

The problematic commit is the one having to do with recursive todos:

bd3a2cbf2f69d4de5ad7d41893bf418e91c23fb2

Best,
Matt

Re: [O] problem with org-capture

[Eric S Fraga]

On Tuesday,  1 Dec 2015 at 14:51, Matt Lundin wrote:

[...]

> I can confirm this bug. None of the prompt shortcuts work in capture
> templates. For instance, the following capture template...

Whew!  I was really worried I'd done some silly again... :-)

And I did check with emacs -Q for once!

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.2, Org release_8.3.2-355-g18f083

Re: [O] Moving from org-mode 6.33/7.9.3 to 8.3.2

[Nicolas Goaziou]

Hello,

Steve Moreau  writes:

> - In the past, what I could see with the standard 'M-x fill-region' over
> paragraphs or lists with empty lines between each inner items, was probably
> performed thanks to several calls to org-fill-paragraph.

I don't think so. `fill-region' uses `fill-region-as-paragraph', which
does its own thing. AFACT, it never calls `fill-paragraph-function',
i.e., `org-fill-paragraph'.

> - There are no unit tests, nor past discussions about how different text
>   block contents should be filled with this new function

`org-fill-paragraph' is heavily tested in `test-org/fill-paragraph'.
`org-fill-region' is expected to behave as if `org-fill-paragraph' is
called on every element in the region.

Regards,

-- 
Nicolas Goaziou

Re: [O] [PATCH] ox-html.el: Remove superflous whitespace

[Nicolas Goaziou]

Hello,

Ruben Maher  writes:

> * lisp/ox-html.el: Remove superfluous whitespace from meta tags, put
>   there by `org-html--buld-meta-info' and `org-html--build-head'.
>   `org-html-close-tag' already inserts a space, so it is not necessary
>   to add another.  Previously these affected tags would look like
>   .
>
> TINYCHANGE

Applied. Thank you.

Regards,

-- 
Nicolas Goaziou

Re: [O] [PATCH] ox-html.el: Add lang attribute to html tag

[Nicolas Goaziou]

Hello,

Ruben Maher  writes:

> * lisp/ox-html.el (org-html-template): Add lang attribute to exported
>   html tag.  Some features of the CSS Text Module (Level 3) require this
>   attribute to be present (for example, so that the browser knows how to
>   hyphenate the text). For more info, please take a look here:
>   https://drafts.csswg.org/css-text-3/#languages
>
> TINYCHANGE

Applied. Thank you.

Regards,

-- 
Nicolas Goaziou

Re: [O] asynchronous python code blocks in org-mode

[Tom]

On Mon, Nov 30, 2015 at 1:06 PM, John Kitchin 
wrote:

> I have not thought about sessions and asynchronous execution. It would
> mean a queue and a different way to pass code to the process, which I
> have not thought through yet. What to do when there are dependencies for
> example,...
>

A good way of converting synchronous into asynchronous code is to use
futures/promises. Usually, that's done via data structures, but within
Emacs buffers, it could be done via text strings.

How might that work? org-babel-execute:python could wait for, say, 0.1 sec
for an immediate result. If the computation doesn't finish within that
time, it returns a "future", a magic string like
"org_mode_future_result(1234) ###MAGIC###". This would then get inserted as
output into the org-mode buffer. Later, when the actual result becomes
available from the subprocess, that invokes a callback on the org-python
mode buffer and replaces tihs magic string with the actual result, and
dequeues and executes the next command if necessary.

(Picking a Python-parseable expression would even allow futures to be used
in some other Python computations as if it were an actual value.)

I think that would allow much of the current API to remain in place.
Obviously, some things simply can't work. For example,
org-babel-reassemble-table expects an actual result, not a future; such
post-processing would have to move to a hook function, which probably would
be cleaner anyway.

Tom

Re: [O] problem with org-capture

[Nicolas Goaziou]

Hello,

Eric S Fraga  writes:

> at the risk of again raising an issue that is actually my fault :-(, I
> am having a problem with org-capture.  I have been using the same
> templates for yonks but, all of a sudden, my templates don't work.  For
> instance,
>
> #+begin_src emacs-lisp
>   (setq org-capture-templates
> '(("t" "todo" entry (file+datetree "~/s/notes/tasks.org")
>"* TODO %^{Task} %^G\nSCHEDULED: %t\n%i%?")))
> #+end_src
>
> I do not get prompted for the task nor asked for tags.

Fixed. Thank you.


Regards,

-- 
Nicolas Goaziou

Re: [O] Using orgstruct-mode (or just org-cycle) in emacs-lisp-mode

[Thorsten Jolitz]

Jonas Bernoulli  writes:

Hi List,

> Aaron Ecay  writes:
>
>> Thorsten Jolitz wrote the outshine library
>
> I know. I used it for a while and contributed a few commits.  But I
> pretty much only used the cycling functionality at the time and when
> I discovered that `org-cycle' worked for that too, I stopped using
> outshine.  It also felt a bit like re-inventing the wheel.
>
>> Sadly it’s not actively maintained ATM, but I believe it still works
>> fine,

When I was a heavy outshine user myself it was feature rich and very
stable, and I think it still should be.  So being unmaintained does not
mean you can or should not use it, it only means that I did not add any
new features the last year (and sometimes miss a bug report,
unfortunately). But the three libraries of the outshine-suite
(outshine.el, outorg.el and navi-mode.el) already have so many features
that even the main author could not remember all of them ...

> That's a bit of an understatement; if I remember correctly Thorsten
> stopped using Emacs.

Its true that events in my life kicked me out of the (enjoyable) Emacs
universe, but now I actually use Emacs again once in a while, and hope
more frequently in the future.

>> and it may be an alternative route towards the features you are
>> looking for.
>
> Well currently I am just using `org-cycle' + `outline-minor-mode', which
> works well enough for now.  But eventually I would like to also start
> using Org's navigational commands.  Unfortunately `orgstruct-mode' only
> supports org-like headings (;; * heading\n;; ** subheadng) and not
> standard Emacs headings (;;; heading\n subheading).  I hope someone
> teaches `orgstruct-mode' to support the latter too.  Otherwise I will
> probably give `outshine' another chance.

When there are problems with orgstruct - while waiting for a new
implementation based on outline-minor-mode, why not use an existing,
much more powerfull and very stable alternative based on
outline-minor-mode?

When writing an org-minor-mode (orgstruct, outshine, ...) the most
frequent FAQ is by definition:

"I want Org-mode feature XYZ in org-minor-mode too."

The org-minor-mode author then figures out quickly that

 - Org-mode is not a library engineered for reuse by other
   applications. Org functions do many things, and its often hard or
   impossible to just call them for a result or even copy them
   for reuse.
 - he does not want to rewrite Org-mode

My solution for outshine was 

,[ C-h f outshine-use-outorg RET ]
| outshine-use-outorg is a Lisp function in `outshine.el'.
| 
| (outshine-use-outorg FUN  WHOLE-BUFFER-P  FUNARGS)
| 
| Use outorg to call FUN with FUNARGS on subtree or thing at point.
| 
| FUN should be an Org-mode function that acts on the subtree or
| org-element at point. Optionally, with WHOLE-BUFFER-P non-nil,
| `outorg-edit-as-org' can be called on the whole buffer.
| 
| Sets the variable `outshine-use-outorg-last-headline-marker' so
| that it always contains a point-marker to the last headline this
| function was called upon.
`

With this function potentially all Org-mode commands can easily be made
available in outshine. In practise, some Org functions are really tricky
and need some extra care, but many work out of the box.

Here is what I more or less implemented already. Especially clocking was
tricky, don't remember if it really worked in the end:

,
| 39 matches for "^[[:space:]]*(def[maus][^eltu][a-z]*\*? " in buffer: 
outshine.el
|  30:(defun outshine-deadline ( arg)
|  40:(defun outshine-export-dispatch ( arg)
|  59:(defun outshine-insert-link ()
|  67:(defun outshine-open-at-point ( whole-buffer-p arg 
reference-buffer)
|  84:(defun outshine-set-tags-command ()
|  97:(defun outshine-schedule ( arg)
| 108:(defun outshine-todo ( arg)
| 148:(defun outshine-time-stamp-inactive ( arg)
| 213:(defun outshine-priority ()
| 228:(defun outshine-time-stamp ( arg)
| 254:(defun outshine-toggle-fixed-width ()
| 260:(defun outshine-toggle-comment ()
| 304:(defun outshine-sort-entries ( arg)
| 366:(defun outshine-previous-block ()
| 373:(defun outshine-next-block ()
| 379:(defun outshine-insert-last-stored-link ()
| 571:(defun outshine-toggle-checkbox ( arg)
| 596:(defun outshine-clock-in ()
| 606:(defun outshine-clock-goto ()
| 625:(defun outshine-next-link ()
| 632:(defun outshine-clock-out ()
| 644:(defun outshine-previous-link ()
| 651:(defun outshine-clock-cancel ()
| 662:(defun outshine-clock-report ( arg)
| 732:(defun outshine-timer-pause-or-continue ( arg)
| 738:(defun outshine-timer-item ()
| 744:(defun outshine-timer ()
| 750:(defun outshine-timer-start ()
| 756:(defun outshine-timer-cancel-timer ()
| 762:(defun outshine-timer-set-timer ()
| 768:(defun outshine-agenda-set-restriction-lock ( arg)
| 780:(defun outshine-agenda-remove-restriction-lock ( 
include-org-p)

Re: [O] Fwd: Citation processing via Zotero + zotxt

[Matt Lundin]

Matt Price  writes:

> On Sat, Nov 28, 2015 at 3:16 PM, Richard Lawrence
>  wrote:

> I know that many people (perhaps especially the `power users' who
> have been active in the citations discussion so far) prefer to
> maintain their reference database without the aid of a GUI
> reference manager like Zotero. I still think Zotero + zotxt is the
> best option for non-LaTeX citation processing, even for these
> folks. The ease of installation (and removal) of the required
> programs alone makes it worth it, even if you never actually
> populate a Zotero database. So given what I know at the moment, I
> think our efforts would best be directed at making the in-progress
> org-cite library communicate with Zotero via zotxt. What do you
> think?
>
> Best,
> Richard
>
> [1] https://www.zotero.org/
> [2] https://gitlab.com/egh/zotxt/
> [3] See the bibliographyEndpoint function in:
> https://gitlab.com/egh/zotxt/blob/master/extension/bootstrap.js
> [4] https://gitlab.com/egh/zotxt-emacs
>
> I love Zotxt. my only concern is for those people who run a remote
> Emacs. If, say, you run emacs on a server that you access by ssh, it
> will not be possible to process your citations with org. 
>
> I personally don't use this method, though I have occasionally had to
> work off of a server via some randome computer when my laptop breaks
> down. For me, this is a veyr rare case. Is there anyone on the list
> who might actually be negatively affected by this? 

I do have a remote emacs installation that I use occasionally, but not
enough to make this a concern.

One question (based on complete ignorance of either zotero or zotxt) is
whether those of us who maintain bibtex databases solely in emacs would
have to interact with the zotero GUI. Let's say I have a bib file and an
org document containing citations. Would everything place transparently
in the background without ever having to interact with zotero? Can
zotero query a bib file without requiring the user manually to
import/export the database?

Thanks,
Matt

Re: [O] asynchronous python code blocks in org-mode

[John Kitchin]

Tom writes:

> On Mon, Nov 30, 2015 at 1:06 PM, John Kitchin 
> wrote:
>
>> I have not thought about sessions and asynchronous execution. It would
>> mean a queue and a different way to pass code to the process, which I
>> have not thought through yet. What to do when there are dependencies for
>> example,...
>>
>
> A good way of converting synchronous into asynchronous code is to use
> futures/promises. Usually, that's done via data structures, but within
> Emacs buffers, it could be done via text strings.
>
> How might that work? org-babel-execute:python could wait for, say, 0.1 sec
> for an immediate result. If the computation doesn't finish within that
> time, it returns a "future", a magic string like
> "org_mode_future_result(1234) ###MAGIC###". This would then get inserted as
> output into the org-mode buffer. Later, when the actual result becomes
> available from the subprocess, that invokes a callback on the org-python
> mode buffer and replaces tihs magic string with the actual result, and
> dequeues and executes the next command if necessary.

This is basically what happens now, I insert a uuid that gets replaced by
a callback function.  A session is doable I think as you describe. Its
not a high-priority for me though. I feel like it would eventually be
necessary to have some queue management functions, e.g. what to do if
you run a block twice? or want to cancel a run, etc... How to make sure
dependencies are correct, e.g. you can start a second block before the
first block finishes, but it is queued. etc...

> (Picking a Python-parseable expression would even allow futures to be used
> in some other Python computations as if it were an actual value.)
>
> I think that would allow much of the current API to remain in place.
> Obviously, some things simply can't work. For example,
> org-babel-reassemble-table expects an actual result, not a future; such
> post-processing would have to move to a hook function, which probably would
> be cleaner anyway.
>
> Tom

--
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

[O] a post-processing export hook?

[John Kitchin]

Hi all,

I tried using org-export-before-parsing-hook to modify an org-file prior
to export to replace some regular expressions with html.

I ran into the following issue. For short substitutions,
@@html:replacement@@ worked fine. If the replacement text got too long,
this broke. I did wrap it in a #+begin_html: block, but that introduced
line breaks that were undesireable. The replacement text was long
because I had a large tool tip to put on some text.

I ended up doing a post-process like this:

(with-current-buffer (org-html-export-as-html)
  (org-process-key-bindings 'html)
  (org-process-emacs-commands 'html)
  (write-file "blog.html")
  (browse-url "blog.html"))

But, I wondered if there should be a post-export hook? I can see some
challenge for pdf export, for example. The hook should run after the
latex export, not after the pdf is made.

I could have used a filter on a paragraph, which is where most of the
things I was modifying were. Is there some other way I could have done
this?


--
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] ox-html.el: Add lang attribute to html tag

[Ruben Maher]

Thank you Nicolas!

[O] missing frame title using org beamer export

[mypostgtd]

- issue: org mode beamer export ignored all frame titles

I've tried searching online for couple of hours, but couldn't find a solution. 
Can someone please advise? 

- debug trials and observations

1. The same org file works fine in org-mode version 7.8.08.

However, in org version 8.3.2, the frame titles are missing

2. I tried to add following to the .emacs, but it didn't seem to help.
[source: http://emacs-fu.blogspot.com/2009/10/
writing-presentations-with-org-mode-and.html]

;; allow for export=>beamer by placing

;; #+LaTeX_CLASS: beamer in org files
(unless (boundp 'org-latex-classes)
  (setq org-latex-classes nil))
(add-to-list 'org-latex-classes
 ;; beamer class, for presentations
 '("beamer"
   "\\documentclass\[8pt\]\{beamer\}\n
   \\mode<{{{beamermode}}}>\n
   \\usethemebeamertheme\n
   \\usecolorthemebeamercolortheme\n
   \\beamertemplateballitem\n
   \\setbeameroption{show notes}
   \\usepackage[utf8]{inputenc}\n
   \\usepackage[T1]{fontenc}\n
   \\usepackage{hyperref}\n
   \\usepackage{color}
   \\usepackage{listings}
   \\lstset{numbers=none,language=[ISO]C++,tabsize=4,
   frame=single,
   basicstyle=\\small,
   showspaces=false,showstringspaces=false,
   showtabs=false,
   keywordstyle=\\color{blue}\\bfseries,
   commentstyle=\\color{red},
   }\n
   \\usepackage{verbatim}\n
   \\institutebeamerinstitute\n  
\\subjectbeamersubject\n"
   ("\\section{%s}" . "\\section*{%s}")
   ("\\subsection\{%s\}" . "\\subsection*\{%s\}")
   ("\\subsubsection\{%s\}" . "\\subsubsection*\{%s\}")
   ("\\paragraph\{%s\}" . "\\paragraph*\{%s\}")
   
;; ("\\begin{frame}[fragile]\\frametitle{%s}"
;;  "\\end{frame}"
;;  "\\begin{frame}[fragile]\\frametitle{%s}"
;;  "\\end{frame}")
))

- org file contents

#+STARTUP: beamer
#+OPTIONS: H:3 num:t toc:t \n:nil @:t ::t |:t ^:t -:t f:t *:t <:t
#+LaTeX_CLASS: beamer
#+LaTeX_CLASS_OPTIONS: [presentation, smaller]
#+BEAMER_THEME: Rochester
#+BEAMER_COLOR_THEME: 
#+BEAMER_FRAME_LEVEL: 3

#+TITLE: Test Frame title
#+AUTHOR:  dummy
#+DATE:  \today

#+LANGUAGE:  en

* Section 1
** SubSection 1.1
*** Slide 1.1.1 frame title
- blah blah I am first frame content
- content itme 2
*** Slide 1.1.2 frame title
- dummy
* Section 2
** SubSection 2.1
*** Slide 2.1.1 frame title
- blah blah I am first frame content
- content itme 2
*** Slide 2.1.2 frame title
- block 1
  - item 1
  - item 2 
- block 2

- to debug, I used a fresh .emacs file, with minimum settings as below:

(custom-set-variables
 ;; custom-set-variables was added by Custom.
 ;; If you edit it by hand, you could mess it up, so be careful.
 ;; Your init file should contain only one such instance.
 ;; If there is more than one, they won't work right.
 '(org-beamer-frame-level 3)
 '(org-export-backends (quote (ascii beamer html icalendar latex org
(custom-set-faces
 ;; custom-set-faces was added by Custom.
 ;; If you edit it by hand, you could mess it up, so be careful.
 ;; Your init file should contain only one such instance.
 ;; If there is more than one, they won't work right.
 )

- As shown in the .tex file, the exported file is missing all frame titles.

\documentclass[presentation, smaller]{beamer}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{fixltx2e}
\usepackage{graphicx}
\usepackage{grffile}
\usepackage{longtable}
\usepackage{wrapfig}
\usepackage{rotating}
\usepackage[normalem]{ulem}
\usepackage{amsmath}
\usepackage{textcomp}
\usepackage{amssymb}
\usepackage{capt-of}
\usepackage{hyperref}
\author{dummy}
\date{\today}
\title{Test Frame title}
\hypersetup{
 pdfauthor={dummy},
 pdftitle={Test Frame title},
 pdfkeywords={},
 pdfsubject={},
 pdfcreator={Emacs 24.3.2 (Org mode 8.3.2)}, 
 pdflang={English}}
\begin{document}

\maketitle
\tableofcontents


\section{Section 1}
\label{sec:orgheadline4}
\subsection{SubSection 1.1}
\label{sec:orgheadline3}
\subsubsection{Slide 1.1.1 frame title}
\label{sec:orgheadline1}
\begin{itemize}
\item blah blah I am first frame content
\item content itme 2
\end{itemize}
\subsubsection{Slide 1.1.2 frame title}
\label{sec:orgheadline2}
\begin{itemize}
\item dummy
\end{itemize}
\section{Section 2}
\label{sec:orgheadline8}
\subsection{SubSection 2.1}
\label{sec:orgheadline7}
\subsubsection{Slide 2.1.1 frame title}
\label{sec:orgheadline5}
\begin{itemize}
\item blah blah I am first frame content
\item content itme 2
\end{itemize}
\subsubsection{Slide 2.1.2 frame title}
\label{sec:orgheadline6}
\begin{itemize}
\item block 1
\begin{itemize}
\item item 1
\item item 2
\end{itemize}
\item block 2
\end{itemize}
\end{document}

Re: [O] Jumping between source blocks in a file

[Martin Yrjölä]

Hi Andrew!

Andrew Kirkpatrick writes:

> If this is deemed useful, I'm happy to make changes suitable for
> inclusion in the project.

Thanks for sharing! I would certainly want these functions included in
org-mode by default. They streamline at least my literate programming
workflow substantially.

Cheers,
Martin

Re: [O] Error "No :file header argument given" - minor bug?

[Loris Bennett]

"Loris Bennett"  writes:

> "Loris Bennett"  writes:
>
>> Hi,
>>
>> At the beginning of each month I generate a plot via a CALL to a block
>> of R code:
>>
>> #+CALL: code;plot_usage_historical_facet(type="users")
>>
>> The type is used as part of the name of the output file.  Today I got
>> the error:
>>
>> user-error: No :file header argument given; cannot create graphical result.
>>
>> I have certainly updated Org since the last time I tried to create the
>> plot and am now running version 8.3.2 (8.3.2-39-gd537a3-elpaplus).
>>
>> Is this (new) behaviour expected?  If, so what do I have to do to
>> generate a plot file with a name which is dependent on an argument?
>
> Looking at my code again, I think I may have been mistaken and this may
> never have worked as I describe above.
>
> Thus the question should be:
>
> Is it possible to have a variable as part of the :file specification?

To answer my own question:

Probably not, but in my case it isn't necessary.

In my R code I have:

  ggsave(filename=paste0("./usage_",type,"_historical_facet.pdf"),plot=p)

and this produces, as desired, an output file where the file name
depends on the argument passed by CALL, e.g.

  #+CALL: code;plot_usage_historical_facet(type="users")

What threw me was that you still need ':file' header but the name
specified there is irrelevant, e.g.

  #+HEADER: :file tmp.pdf

When the block is evaluated, the file I want with the correct,
argument-dependent name is created.  However I also get 'tmp.pdf', but
this file just seems to be an empty PDF shell without any pages.

So this seems to be a minor bug.  Maybe ':file' should be able to take
a value which indicates that the name of the file will come from within
the block.

Cheers,

Loris

-- 
This signature is currently under construction.

Re: [O] Moving from org-mode 6.33/7.9.3 to 8.3.2

[Samuel Wales]

whenever something doesn't fill, i enable filladapt.el.

Re: [O] Fwd: Citation processing via Zotero + zotxt

[Matt Price]

On Tue, Dec 1, 2015 at 10:51 AM, Richard Lawrence <
richard.lawre...@berkeley.edu> wrote:

> Hi Eric and all,
>
> Eric S Fraga  writes:
>
> > On Tuesday,  1 Dec 2015 at 07:12, Matt Price wrote:
> >> I love Zotxt. my only concern is for those people who run a remote
> Emacs.
> >> If, say, you run emacs on a server that you access by ssh, it will not
> be
> >> possible to process your citations with org.
> >
> > I'm not sure I understand this.
> >
> > Is the implication that one will need to be connected to the Internet to
> > be able to export citations?  If so, this is not good.
>
> No, you should not need to be connected to the Internet.  As I envision
> things, Emacs will just speak to the Zotero installation on the local
> machine.  That's what zotxt does now.  So, there should be no problem as
> long as Firefox, Zotero and zotxt are running on the same machine that
> is running Emacs.
>
> I suppose the concern is that someone running a remote Emacs is likely
> doing so on a machine that does not have a GUI...and hence may not have
> Firefox installed, and consequently won't have Zotero or zotxt.  In that
> case, citation processing would have to go another route.
>

This is the scenario I was envisioning, thank you both for clarifying.

>
> Are there a lot of people in that situation?
>

... and this is precisely the question I meant to ask.

>
> Best,
> Richard
>

Re: [O] Citation processing via Zotero + zotxt

[Matt Price]

On Tue, Dec 1, 2015 at 9:36 AM, Rasmus  wrote:

> Hi Richard,
>
> First, thank you for looking into this.  I learned something new from this
>
> > Pretty much all the other options we have talked about seem like they
> > will require multi-step, non-trivial installation procedures ("First
> > install {Node.js/Haskell/JVM ...}, then install
> > {citeproc-node/pandoc-citeproc/citeproc-java...}, then install our
> > wrapper script...").  Updating could require other manual operations of
> > similar complexity.  Avoiding that kind of procedure will make citations
> > a lot more usable from Org for everyone.
>
> I think this is *very* important.
>
I totally agree.



> > 2) It is quite complete.
> >
> > Previously, I thought that it would be a similar amount of work to
> > communicate with Zotero from Emacs as any of the other CSL
> > implementations out there.  However, after looking at zotxt a bit more
> > closely, I discovered that it has an (undocumented) API endpoint [3]
>
> This sounds amazing, but also dangerous.  Do you know whether stabilizing
> the API has been discussed upstream?
>

I think the API Richard is referring to is *zotxt's* API, not Zotero's. So
"upstream" is a very short distance to an underground spring under our
house (Erik Hetzner).
The somewhat more widely-used Better Bibtex plugin also has provides an API
to the Zotero database (https://zotplus.github.io/better-bibtex/cayw.html).
In either case, it probably would be relatively easy to provide patches to
the maintainer if we run into trouble.


>
> > that pretty much does exactly what we need: it accepts a list of
> > citation objects, and returns a list of formatted citations and a
> > formatted bibliography, which can be inserted into the exported
> > document.
>
> Could you give an example of the sort of input you give?  I.e. is it based
> on keys?  From my bibtex-centric world view I imagine something like:
>
>I send key or pointer @K to a DB entry as well as a CSL-file pointer C,
>and maybe a desired output format F.  I get a string back that is the
>formatting of the data behind @K formatted according to the rules in C,
>adapted to F.
>
> Is that correct?  If so, does it support html, text and odt?
>
> Right now, IIUC, zotxt accepts only a *style name*, not a CSL file -- it
will locate the CSL file in the Zotero style list.  It supports html and
text output formats, as well as the QuickKey syntax used by the ODF-scan
zotero plugin (https://github.com/Zotero-ODF-Scan/zotero-odf-scan). My
understanding is that providing fully-formed odt syntax is difficult,
because  of the structure of the odt file, which I guess wants a bunch of
metadata that isn't trivial to provide.  The recommended path right now is
to run ODF-scan on the odt from libreoffice -- it's an annoying extra step
that I was hoping to be able to avoid, but am not competent to program:

https://forums.zotero.org/discussion/29308/7/rtfodf-scan-for-zotero/#Comment_226799

> This endpoint still needs a little bit of work, to generalize it and
> > make it easier to get the data in the format we need.  (That is probably
> > why it is undocumented in the README.) But it requires much less work
> > than I thought it would, and much less work than it would be to get a
> > full-featured setup with something like citeproc-node.
>
> This is a very strong argument.
>
> At some point Matt talked about adding support for org citation syntax in
> citeproc-js.  Would this be advantageous if going this route?  I guess not.
>

Depends on whether you want to be able to request org-mode syntax from
zotero. Zotero uses citation-js internally; changes we make to citation-js
will eventually percolate up to zotero, and it's not impossible to replace
zotero's citeproc with one's own copy (even I can do it).

>
> >
>


> IMO we can leverage zotero as a tool, but we cannot enforce it as a
> bibliography manager.
>

yes

>
> > I still think Zotero + zotxt is the best option for non-LaTeX
> > citation processing, even for these folks.  The ease of installation
> > (and removal) of the required programs alone makes it worth it, even if
> > you never actually populate a Zotero database.  So given what I know at
> > the moment, I think our efforts would best be directed at making the
> > in-progress org-cite library communicate with Zotero via zotxt.  What do
> > you think?
>
> +1, though re zotxt we should make sure Erik would want to move it to
> GELPA.
>

Basically I'm enthusiastic and glad you are taking up the challenge, since
matt's programming:snail's pace :: snail's pace:leopard run

[O] Error "No :file header argument given"

[Loris Bennett]

Hi,

At the beginning of each month I generate a plot via a CALL to a block
of R code:

#+CALL: code;plot_usage_historical_facet(type="users")

The type is used as part of the name of the output file.  Today I got
the error:

user-error: No :file header argument given; cannot create graphical result.

I have certainly updated Org since the last time I tried to create the
plot and am now running version 8.3.2 (8.3.2-39-gd537a3-elpaplus).

Is this (new) behaviour expected?  If, so what do I have to do to
generate a plot file with a name which is dependent on an argument?

Cheers,

Loris

-- 
This signature is currently under construction.

Re: [O] Citation processing via Zotero + zotxt

[Ramon Diaz-Uriarte]

On Tue, 01-12-2015, at 01:32, John Kitchin  wrote:
> Martin Yrjölä writes:
>
>> Maybe two way sync between BibTeX and Zotero would be sufficient for
>> power users? I know there is already automatic exporters to BibTex for
>> Zotero, but some work needs to be done to make it a two-way sync.
>
> I am personally skeptical of this, having "translated" Endnote libraries
> to Bibtex and back. The simple stuff mostly works, but accented names,
> chemical formulas, and many other things tend to not translate very well.


In addition, Zotero users often organize their references using
collections, tags, and "related" (and the first two I find essential, both
with Zotero itself and when using Zotero in a tablet). Some of these (e.g.,
collections, tags) might be synced/translated from BibTeX into Zotero
though not always reliably. And trying to get these to work reliably is
probably too much work.


Best,

R.


-- 
Ramon Diaz-Uriarte
Department of Biochemistry, Lab B-25
Facultad de Medicina
Universidad Autónoma de Madrid 
Arzobispo Morcillo, 4
28029 Madrid
Spain

Phone: +34-91-497-2412

Email: rdia...@gmail.com
   ramon.d...@iib.uam.es

http://ligarto.org/rdiaz

Re: [O] interaction between org-latex-custom-lang-environments and name when exporting to latex

[Alan Schmitt]

On 2015-11-30 14:11, Rasmus  writes:

>> +  :group 'org-export-latex
>> +  :type '(repeat
>> +  (list
>> +   (symbol :tag "Language name")
>> +   (string :tag "Environment name or format string")))
>
> I don't know if the strings have to the same width, but I assume you
> tested it before hand.  For me at least this is the only way to evaluate
> Custom changes.

I assume it has to be the same size because it looks like this:

Hide org-latex-custom-lang-environments:
INS DEL List:
Language name: nil
Environment name or format string: 

I'll apply the patch.

Best,

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7
Athmospheric CO₂ (Updated November 29, 2015, Mauna Loa Obs.): 400.37 ppm


signature.asc
Description: PGP signature

[O] problem with org-capture

[Eric S Fraga]

Hello again,

at the risk of again raising an issue that is actually my fault :-(, I
am having a problem with org-capture.  I have been using the same
templates for yonks but, all of a sudden, my templates don't work.  For
instance,

#+begin_src emacs-lisp
  (setq org-capture-templates
'(("t" "todo" entry (file+datetree "~/s/notes/tasks.org")
   "* TODO %^{Task} %^G\nSCHEDULED: %t\n%i%?")))
#+end_src

I do not get prompted for the task nor asked for tags.

I do see that there have been changes recently to org-capture and a few
emails flying by regarding recursive captures but I didn't think they
applied to my use cases...  I could be wrong.

Any pointers to what I need to change to get things working again would
be most welcome!

thanks,
eric

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.2, Org release_8.3.2-355-g18f083

Re: [O] Org-babel shell evaluate with session does not return results

[Giri Prashanth]

Thank you for testing, I have

Org-mode version 8.3.2 (8.3.2-37-gd45217-elpa @
~/.emacs.d/elpa/org-20151123/)
with Emacs version GNU Emacs 24.5.1 (x86_64-apple-darwin13.4.0, NS
apple-appkit-1265.21) of 2015-04-10 on builder10-9.porkrind.org

I am on MAC OS X with emacs from http://emacsforosx.com

Thank you,
-GP


On Sat, Nov 28, 2015 at 11:17 AM, Grant Rettke 
wrote:

> On Thu, Nov 19, 2015 at 12:28 PM, Giri Prashanth
>  wrote:
> > Any reason why org babel execute for shell with session does not
> terminate ?
> > Thank you very much in advance for any response,
>
> Just ran this code and got the following results...
>
> #+NAME: 4AFF24E4-43CF-4FFF-A9E9-4896630C977D
> #+BEGIN_SRC shell :session test
> echo foo
> #+END_SRC
>
> #+RESULTS: 4AFF24E4-43CF-4FFF-A9E9-4896630C977D
> #+BEGIN_EXAMPLE
> | foo |
> #+END_EXAMPLE
>
> Org version from Git: “8.3.2”
>
> Emacs version: “24.5.1”
>
> What versions are you on?
>



-- 
-giri

Re: [O] Fwd: Citation processing via Zotero + zotxt

[Eric S Fraga]

On Tuesday,  1 Dec 2015 at 07:12, Matt Price wrote:
> I love Zotxt. my only concern is for those people who run a remote Emacs.
> If, say, you run emacs on a server that you access by ssh, it will not be
> possible to process your citations with org.

I'm not sure I understand this.

Is the implication that one will need to be connected to the Internet to
be able to export citations?  If so, this is not good.  I do much, often
most, of my writing while off-line (long train journeys every day).  It
would be quite intrusive to my writing habits to have to ensure that I
can connect to prepare actual exported documents.

For most, this may not be an issue so obviously my concern should not
derail any progress etc. but I am probably not alone...  Clarification,
in any case, would be welcome.

thanks,
eric
-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.2, Org release_8.3.2-355-g18f083

Re: [O] Fwd: Citation processing via Zotero + zotxt

[Richard Lawrence]

Hi Eric and all,

Eric S Fraga  writes:

> On Tuesday,  1 Dec 2015 at 07:12, Matt Price wrote:
>> I love Zotxt. my only concern is for those people who run a remote Emacs.
>> If, say, you run emacs on a server that you access by ssh, it will not be
>> possible to process your citations with org.
>
> I'm not sure I understand this.
>
> Is the implication that one will need to be connected to the Internet to
> be able to export citations?  If so, this is not good.

No, you should not need to be connected to the Internet.  As I envision
things, Emacs will just speak to the Zotero installation on the local
machine.  That's what zotxt does now.  So, there should be no problem as
long as Firefox, Zotero and zotxt are running on the same machine that
is running Emacs.

I suppose the concern is that someone running a remote Emacs is likely
doing so on a machine that does not have a GUI...and hence may not have
Firefox installed, and consequently won't have Zotero or zotxt.  In that
case, citation processing would have to go another route.

Are there a lot of people in that situation?
 
Best,
Richard

Re: [O] Error "No :file header argument given"

[Loris Bennett]

"Loris Bennett"  writes:

> Hi,
>
> At the beginning of each month I generate a plot via a CALL to a block
> of R code:
>
> #+CALL: code;plot_usage_historical_facet(type="users")
>
> The type is used as part of the name of the output file.  Today I got
> the error:
>
> user-error: No :file header argument given; cannot create graphical result.
>
> I have certainly updated Org since the last time I tried to create the
> plot and am now running version 8.3.2 (8.3.2-39-gd537a3-elpaplus).
>
> Is this (new) behaviour expected?  If, so what do I have to do to
> generate a plot file with a name which is dependent on an argument?

Looking at my code again, I think I may have been mistaken and this may
never have worked as I describe above.

Thus the question should be:

Is it possible to have a variable as part of the :file specification?

Cheers,

Loris

-- 
This signature is currently under construction.

[O] Fwd: Citation processing via Zotero + zotxt

[Matt Price]

On Sat, Nov 28, 2015 at 3:16 PM, Richard Lawrence <
richard.lawre...@berkeley.edu> wrote:

> Hi everyone,
>
> For the past few days, I've been looking more closely at using the
> combination of Zotero [1] with Erik Hetzner's zotxt plugin [2] as a
> means of processing citations when exporting to non-LaTeX backends.  I
> am now thinking that this is probably our best option, but I'd like to
> know what other people think before I sink a lot of work into it.
>
> Here are the reasons I think this is the best option:
>
> 1) It is really easy for users.
>
> For those unfamiliar, Zotero is a reference manager, and zotxt is a
> Zotero plugin that makes it easier to work with Zotero from plain text
> documents.  Both are Firefox plugins, which means they can be installed
> by a non-technical user with a couple of clicks.  It also means that
> users get updates automatically.  I think this is *really* important.
>
> Pretty much all the other options we have talked about seem like they
> will require multi-step, non-trivial installation procedures ("First
> install {Node.js/Haskell/JVM ...}, then install
> {citeproc-node/pandoc-citeproc/citeproc-java...}, then install our
> wrapper script...").  Updating could require other manual operations of
> similar complexity.  Avoiding that kind of procedure will make citations
> a lot more usable from Org for everyone.
>
> Also, unlike the other options, Zotero is a full-featured reference
> manager, not just a batch processor.  So we as users get a useful piece
> of software with a simple installation procedure; the other options
> require a complex installation procedure for a less-useful program.
>
> 2) It is quite complete.
>
> Previously, I thought that it would be a similar amount of work to
> communicate with Zotero from Emacs as any of the other CSL
> implementations out there.  However, after looking at zotxt a bit more
> closely, I discovered that it has an (undocumented) API endpoint [3]
> that pretty much does exactly what we need: it accepts a list of
> citation objects, and returns a list of formatted citations and a
> formatted bibliography, which can be inserted into the exported
> document.
>
> This endpoint still needs a little bit of work, to generalize it and
> make it easier to get the data in the format we need.  (That is probably
> why it is undocumented in the README.) But it requires much less work
> than I thought it would, and much less work than it would be to get a
> full-featured setup with something like citeproc-node.
>
> Erik has also written a package for communicating with zotxt from Emacs,
> zotxt-emacs [4], which is available on MELPA.  This package already
> contains a lot of useful functions for querying the Zotero database and
> inserting reference data into documents, including links in Org
> documents.  I think it would be pretty straightforward to extend this
> package to provide a nice UI for writers who are inserting citations
> into Org documents, including search-based lookups of keys, etc.
> Perhaps org-ref could also be taught to communicate with zotxt (with or
> without zotxt-emacs) without too much work.
>
> 3) It uses citeproc-js.
>
> In previous discussions, I think we agreed that it would be best for us
> to use citeproc-js as a CSL processor, since it is the `canonical' CSL
> implementation, as opposed to pandoc-citeproc or citeproc-java.  Zotero
> just uses citeproc-js internally to process citations, so it meets this
> requirement.
>
>
> I know that many people (perhaps especially the `power users' who have
> been active in the citations discussion so far) prefer to maintain their
> reference database without the aid of a GUI reference manager like
> Zotero.  I still think Zotero + zotxt is the best option for non-LaTeX
> citation processing, even for these folks.  The ease of installation
> (and removal) of the required programs alone makes it worth it, even if
> you never actually populate a Zotero database.  So given what I know at
> the moment, I think our efforts would best be directed at making the
> in-progress org-cite library communicate with Zotero via zotxt.  What do
> you think?
>
> Best,
> Richard
>
> [1] https://www.zotero.org/
> [2] https://gitlab.com/egh/zotxt/
> [3] See the bibliographyEndpoint function in:
> https://gitlab.com/egh/zotxt/blob/master/extension/bootstrap.js
> [4] https://gitlab.com/egh/zotxt-emacs
>
> I love Zotxt. my only concern is for those people who run a remote Emacs.
If, say, you run emacs on a server that you access by ssh, it will not be
possible to process your citations with org.

I personally don't use this method, though I have occasionally had to work
off of a server via some randome computer when my laptop breaks down.  For
me, this is a veyr rare case. Is there anyone on the list who might
actually be negatively affected by this?

Re: [O] Citation processing via Zotero + zotxt

[Rasmus]

Hi Richard,

First, thank you for looking into this.  I learned something new from this
post.

Richard Lawrence  writes:

> 1) It is really easy for users.

I generally don’t buy the arguments a reference manager being nice per
see.

Also, last I checked Zotero also existed as a standalone manager.  If this
also works re your points below, using Zotero is a non-issue.  There
exists a plugin to keep a bibtex file up to date.  I don’t know if it’s
two way, though.

> For those unfamiliar, Zotero is a reference manager, and zotxt is a
> Zotero plugin that makes it easier to work with Zotero from plain text
> documents.  Both are Firefox plugins, which means they can be installed
> by a non-technical user with a couple of clicks.  It also means that
> users get updates automatically.  I think this is *really* important.

I don’t think this is relevant.

> Pretty much all the other options we have talked about seem like they
> will require multi-step, non-trivial installation procedures ("First
> install {Node.js/Haskell/JVM ...}, then install
> {citeproc-node/pandoc-citeproc/citeproc-java...}, then install our
> wrapper script...").  Updating could require other manual operations of
> similar complexity.  Avoiding that kind of procedure will make citations
> a lot more usable from Org for everyone.

I think this is *very* important.

> Also, unlike the other options, Zotero is a full-featured reference
> manager, not just a batch processor.  So we as users get a useful piece
> of software with a simple installation procedure; the other options
> require a complex installation procedure for a less-useful program.

I don’t think this is relevant.

> 2) It is quite complete.
>
> Previously, I thought that it would be a similar amount of work to
> communicate with Zotero from Emacs as any of the other CSL
> implementations out there.  However, after looking at zotxt a bit more
> closely, I discovered that it has an (undocumented) API endpoint [3]

This sounds amazing, but also dangerous.  Do you know whether stabilizing
the API has been discussed upstream?

> that pretty much does exactly what we need: it accepts a list of
> citation objects, and returns a list of formatted citations and a
> formatted bibliography, which can be inserted into the exported
> document.

Could you give an example of the sort of input you give?  I.e. is it based
on keys?  From my bibtex-centric world view I imagine something like:

   I send key or pointer @K to a DB entry as well as a CSL-file pointer C,
   and maybe a desired output format F.  I get a string back that is the
   formatting of the data behind @K formatted according to the rules in C,
   adapted to F.

Is that correct?  If so, does it support html, text and odt?

> This endpoint still needs a little bit of work, to generalize it and
> make it easier to get the data in the format we need.  (That is probably
> why it is undocumented in the README.) But it requires much less work
> than I thought it would, and much less work than it would be to get a
> full-featured setup with something like citeproc-node.

This is a very strong argument.

At some point Matt talked about adding support for org citation syntax in
citeproc-js.  Would this be advantageous if going this route?  I guess not.

> Erik has also written a package for communicating with zotxt from Emacs,
> zotxt-emacs [4], which is available on MELPA.  This package already
> contains a lot of useful functions for querying the Zotero database and
> inserting reference data into documents, including links in Org
> documents.  I think it would be pretty straightforward to extend this
> package to provide a nice UI for writers who are inserting citations
> into Org documents, including search-based lookups of keys, etc.
> Perhaps org-ref could also be taught to communicate with zotxt (with or
> without zotxt-emacs) without too much work.

I guess we’d need to convince Erik to move it to GELPA.  Fortunately (from
that point of view), neither zotxt nor zotxt-emacs seems to have too many
contributors.

> 3) It uses citeproc-js.
>
> In previous discussions, I think we agreed that it would be best for us
> to use citeproc-js as a CSL processor, since it is the `canonical' CSL
> implementation, as opposed to pandoc-citeproc or citeproc-java.  Zotero
> just uses citeproc-js internally to process citations, so it meets this
> requirement. 

Indeed.

> I know that many people (perhaps especially the `power users' who have
> been active in the citations discussion so far) prefer to maintain their
> reference database without the aid of a GUI reference manager like
> Zotero.

I think this solves part of that issue.  Again it could be a dangerous
solution.  Alternatively, perhaps it’s possible to feed-in a bibtex file
to Zotero via an API.  This would also limit the damage.

IMO we can leverage zotero as a tool, but we cannot enforce it as a
bibliography manager.

> I still think Zotero + zotxt is 

[O] fixmee / syntax-ppss

[Jeremy Hankins]

I recently started using org-mode, so forgive me if this is covered
somewhere that I missed.  But I'm trying to use fixmee.el with org-mode;
it works by finding "fixme" tags in comments, but it's not finding
anything in my orgmode files.  I've traced the problem to the fact that
syntax-ppss fails to accurately report that it's in a comment.

So position point inside a comment in an org file and eval:

(nth 4 (syntax-ppss))

It should (?) report t, but it's giving me nil.

-- 
Jeremy Hankins