Re: [O] Regression in Org triggered from helm

[Kyle Meyer]

Kyle Meyer  writes:

> Simon Thum  writes:
>
> [...]
>
>> Arrgh - you're on the spot. That explains a lot, including my
>> difficulties with reproducing.
>>
>> It sends window-width. Increase to window(-width) and I'm done.
>>
>> But that means it's arguably Org which should be more graceful than it
>> is.
>
> I agree.  At some point, if window-width is returning a small enough
> value or if PREFIX is too long, the results of org-format-outline-path
> will be truncated to the point of being useless, but
> org-format-outline-path shouldn't choke.
>
> I'll fix it up and add some tests.

Fixed with 1c74002.  Thanks for reporting the issue.

-- 
Kyle

Re: [O] Some projects

[Matt Lundin]

Matt Price  writes:

> On Tue, Oct 27, 2015 at 9:51 AM, Rasmus  wrote:
>
>
> Aaron Ecay  writes:
>
> Indeed. I guess this is what they use:
>
> https://github.com/zotero/citeproc-node
>
> It also looks rather complex...
>
>
> FWIW, I just tried installing this on my Arch system, but it doesn't
> work with node 0.12, and I am currently unable to switch to io.js due
> to dependencies of several other projects. I guess tools like NVM can
> help with this situation, but I worry that node is currently a moving
> target and might lead to lots of platform-dependent buggy behaviour. 

Testing it now... Works fine on my Arch system. Arch's current nodejs is
4.2. As I understand it, io.js has been merged back into node 4.+

The citeproc-node server itself is not very complex. It's just a node
wrapper around citeproc-js. The big limitation, it seems to me, is that
it only accepts a json format as input. Also it seems to use html markup
in all its output formats.

Though published by the Zotero programmers, citeproc-node, I believe, is
distinct from the citeproc-js implementation in Zotero, which is a XUL
application.

Matt

Re: [O] Some projects

[Aldric Giacomoni]

On Tue, Oct 27, 2015 at 9:05 PM Matt Price  wrote:

>
>
>>
> FWIW, I just tried installing this on my Arch system, but it doesn't work
> with node 0.12, and I am currently unable to switch to io.js due to
> dependencies of several other projects. I guess tools like NVM can help
> with this situation, but I worry that node is currently a moving target and
> might lead to lots of platform-dependent buggy behaviour.
>
> FYI - io.js has merged back into node.js, so we're back to just the one
project.

Re: [O] Some projects

[Matt Lundin]

Rasmus Pank Roulund  writes:

>
> Ista Zahn  writes:
>
>> IMO pandoc is easy on Windows and OSX. It is easy on some Linux distros
>> but not all.
>
>> I use Arch LInux, where getting pandoc requires some work, but I think
>> that is an issue that the Linux distros need to work out.
>
> No it doesn't: pacman -S pandoc.

> At 25MB, a static, precompiled pandoc is probably fine, but for users of
> some OSs, such as Archlinux or even worse some OS where pandoc is not
> generally available as a precompiled package, it’s a really, really big
> dependency.  I may still be the best option, though.

The best option on arch is probably pandoc-static in the AUR. It pulls
in the very large ghc as a build dependency. However, this can be
removed after the build. Still, pandoc-static is 118 MB on my machine.
(That's bigger than emacs itself).

In an ideal world, citeproc-js + node would be the most portable.
However, as others have pointed out, the lack of a good converter from
bibtex to citeproc's json format is a drawback. By contrast,
pandoc-citeproc offers both a converter and a CSL implementation.

Matt

Re: [O] Some projects

[Matt Lundin]

Aaron Ecay  writes:
>
> - There is a difference between citations as done by latex/bibtex/etc.,
>   and those done in every other format (handled through CSL).  Assuming
>   latex users want to keep their native processing rather than
>   delegating to CSL, we need to solve the myriad small inconsistencies
>   between these two tools.  I think this is an area where it’s important
>   to get things right: users of citations generally have exacting
>   requirements.  “Approximately Chicago-style” or “almost MLA” aren’t
>   worth anything.

In my recollection, pandoc can juggle between CSL and biblatex. From the
pandoc manual:

,
| --biblatex
| 
|Use biblatex for citations in LaTeX output. This option is not for
|use with the pandoc-citeproc filter or with PDF output. It is
|intended for use in producing a LaTeX file that can be processed with
|pdflatex and bibtex or biber.
`

Perhaps someone with more experience of pandoc could assess how well it
toggles between CSL and biblatex, especially for more complicated styles
(e.g., Chicago). 

Matt

Re: [O] org-agenda-scheduled-leaders and repeating tasks

[Matt Lundin]

cesar mena  writes:

> me again :)
>
> the calculation is correct.
>
> however the face is now `org-scheduled-today, as opposed to
> `org-scheduled-previously, and the agenda sorting is wrong. instead of
> bubbling to the top (since it is so late) it is staying within the
> "scheduled today" range.

I can confirm that overdue .+ tasks now have the org-scheduled-today
face. It seems like they should have org-scheduled-previously (unless
they are habits, of course).

Matt

Re: [O] Agenda to iCal not working

[Matt Lundin]

jorge.alfaro-muri...@yale.edu (Jorge A. Alfaro-Murillo) writes:

> Ken Mankoff writes:
>
>> I'm using the examples from
>> https://www.gnu.org/software/emacs/manual/html_node/org/Exporting-Agenda-Views.html
>>  
>>
>> Specifically, 
>>
>> (setq org-agenda-custom-commands [...] 
>
>>
>> But the HTML, PS, and ICS files are not being created. If I'm
>> visiting an Org file and run (org-icalendar-export-to-ics) then the
>> ICS is generated. 
>>
>> Can someone offer advice why the ICS isn't generated when I generate
>> a specific agenda view?
>
> Setting up the agenda custom commands is not related to ical export.

In fact, it is. From the manual linked to in the original post:

"The extension of the file name determines the type of export. If it is
.html, Org mode will use the htmlize.el package to convert the buffer to
HTML and save it to this file name. If the extension is .ps,
ps-print-buffer-with-faces is used to produce Postscript output. If the
extension is .ics, iCalendar export is run export over all files that
were used to construct the agenda, and limit the export to entries
listed in the agenda. Any other extension produces a plain ASCII file."

Matt

Re: [O] Some projects

[Matt Price]

On Tue, Oct 27, 2015 at 9:03 AM, Aaron Ecay  wrote:

> Hi Rasmus,
>
> 2015ko urriak 27an, Rasmus-ek idatzi zuen:
>
> [...]
>
> >
>
> It’s unfortunate, but pandoc has the most easily adaptable CSL
> implementation for our use case, as far as I can see.  The other
> contender is Zotero (in JS, possibly with XUL-specific bits).  It would
> be good if somebody looked at what it would take for us to use Zotero’s
> implementation, just as Richard did for Pandoc.
>

You know about zotxt, right? https://github.com/egh/zotxt-emacs  It is
probably the best starting point, but is currently a little cumbersome to
set up, with several moving parts (zoterto, zotero zotxt extension,
zotxt-emacs library).  And in the end it also sort of makes use of pandoc,
too (https://github.com/egh/zotxt-emacs#for-pandoc-markdown-files)

Re: [O] Some projects

[Matt Price]

On Tue, Oct 27, 2015 at 9:51 AM, Rasmus  wrote:

> Aaron Ecay  writes:
>
>
> >
> > It’s unfortunate, but pandoc has the most easily adaptable CSL
> > implementation for our use case, as far as I can see.  The other
> > contender is Zotero (in JS, possibly with XUL-specific bits).  It would
> > be good if somebody looked at what it would take for us to use Zotero’s
> > implementation, just as Richard did for Pandoc.
>
> Indeed.  I guess this is what they use:
>
>  https://github.com/zotero/citeproc-node
>
> It also looks rather complex...
>

FWIW, I just tried installing this on my Arch system, but it doesn't work
with node 0.12, and I am currently unable to switch to io.js due to
dependencies of several other projects. I guess tools like NVM can help
with this situation, but I worry that node is currently a moving target and
might lead to lots of platform-dependent buggy behaviour.

Though I have also personally had many problems with pandoc and haskell on
this same arch linux laptop, so it could be that I just suck at system
maintenance.

[O] [PATCH] Prevent overwriting of output files from babel calls with nil result

[Éibhear]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Hi,

Here's a patch to ob-emacs-lisp.el to allow me to start generating
graphs with dot again.

Thanks,

Éibhear

- -- 
Éibhear Ó hAnluain
Dublin, Ireland.
+---++
| e-mail: eibhear@gmail.com | Web: [http://www.gibiris.org/] |
| Twitter: @eibhear | Google+: +Éibhear Ó hAnluain   |
| Mobile: +353 86 856 5666  | VoIP: sip:eibh...@linphone.org |
+---++
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlYwAPcACgkQ0ST+nPIXcQb+7QCbB9M8FNYMQM/AO9Sy57vMyjdD
TsMAn0KiaebLDLAxcbQX7OmuQvULwQ42
=wDzV
-END PGP SIGNATURE-
>From a25cd4da8791ff9bb759ba38c05ff07650555055 Mon Sep 17 00:00:00 2001
From: Eibhear O hAnluain 
Date: Tue, 27 Oct 2015 22:43:02 +
Subject: [PATCH] ob-emacs-lisp.el: Don't convert a nil result to "nil"

* ob-emacs-lisp.el (org-babel-execute:emacs-lisp): if `result' is nil
  after the execution of the emacs-lisp code, then it should be passed
  to `ob-babel-result-cond' as nil, and not converted to "nil".

When successful, `org-babel-execute:dot' returns nil, as the output is
written to a file.  Commit 041ca4b6f4c7fe1a7e7eb22e2f08ec2e08577bf9
causes the macro `org-babel-result-cond' to overwrite the file and
populate it with the text "nil". This is because the nil `result' from
the call to the emacs-lisp code is converted to "nil" in
`org-babel-execute:emacs-lisp' when calling `org-babel-result-cond'.
This patch preserves `result' as nil.

TINYCHANGE
---
 lisp/ob-emacs-lisp.el | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/lisp/ob-emacs-lisp.el b/lisp/ob-emacs-lisp.el
index 796293b..bbd3dc8 100644
--- a/lisp/ob-emacs-lisp.el
+++ b/lisp/ob-emacs-lisp.el
@@ -59,12 +59,14 @@
(org-babel-expand-body:emacs-lisp
 body params))
   (org-babel-result-cond (cdr (assoc :result-params params))
-	(let ((print-level nil)
-  (print-length nil))
-  (if (or (member "scalar" (cdr (assoc :result-params params)))
-  (member "verbatim" (cdr (assoc :result-params params
-  (format "%S" result)
-(format "%s" result)))
+	(if result
+	(let ((print-level nil)
+		  (print-length nil))
+	  (if (or (member "scalar" (cdr (assoc :result-params params)))
+		  (member "verbatim" (cdr (assoc :result-params params
+		  (format "%S" result)
+		(format "%s" result)))
+	  )
 	(org-babel-reassemble-table
 	 result
  (org-babel-pick-name (cdr (assoc :colname-names params))
-- 
2.1.4

Re: [O] Some projects

[Nicolas Goaziou]

Eric Abrahamsen  writes:

> Nicolas Goaziou  writes:
>
>> Eric Abrahamsen  writes:
>>
>>> I've tried more than once over the past couple of years to attack
>>> orgstruct mode, and been defeated every time. Largely because
>>> indentation/filling is so damn complicated (too many layers of
>>> indirection for my little brain), and orgstruct added yet another layer
>>> of indirection on top of that. I think a rewrite would not be a bad
>>> thing, and would be happy to participate.
>>
>> Basically, OrgStruct is Org with a very limited syntax, i.e., it only
>> recognizes headlines and lists. OrgStruct++ adds indentation and
>> filling.
>
> Right, I'd forgotten the distinction. I really only use orgstruct for
> plain/numbered list editing (and I guess the occasional table), and
> filling/indentation is pretty key there.
>
>> I think OrgStruct may be redefined as an outline minor mode with Org
>> bindings. This is very different from Org. Even indentation and filling
>> should be new functions since Org's recognizes context that doesn't make
>> sense in OrgStruct.
>
> Would that mean that lists and tables wouldn't be supported?

Tables are handled with OrgTbl minor mode, which is unrelated to
OrgStruct mode.

Lists would require slightly more work, but should be supported in
OrgStruct mode. It implies to advise/hook Some functions from
org-list.el (e.g., to avoid checking about context besides other items
and headlines).

Regards,

Re: [O] Some projects

[Eric Abrahamsen]

Rasmus  writes:

> Eric Abrahamsen  writes:
>
>> Right, I'd forgotten the distinction. I really only use orgstruct for
>> plain/numbered list editing (and I guess the occasional table), and
>> filling/indentation is pretty key there.
>
> AFAIK, this doesn't work in commented lines (e.g., when using orgstruct
> with init.el).

That's something I've never tried. TBH, I only use orgstruct mode when
writing emails. But there I use it quite a bit.

>>> I think OrgStruct may be redefined as an outline minor mode with Org
>>> bindings. This is very different from Org. Even indentation and filling
>>> should be new functions since Org's recognizes context that doesn't make
>>> sense in OrgStruct.
>>
>> Would that mean that lists and tables wouldn't be supported? 
>
> ATM tables are supported via orgstruct++-mode, though at list basic list
> support is provided by orgstruct-mode.

Right, but my question is about a future reworking of the library.
Nicolas mentions refactoring it onto the outline mode, which AFAIK
doesn't do lists or tables.

>> The unfortunate thing about tabulated list mode, which I otherwise
>> really like, isn't able to show multi-line list items. That really
>> crimps its usefulness in showing footnotes and annotations, since you
>> can only see the first line.  Bummer.
>
> Did you open a bug for this?

I posted a query on emacs.help, prior to opening a bug :)

 These new features aside, is there any need to do any fundamental
 refactoring? I mostly mean altering existing Org libraries to use the
 element framework, stuff like that...
>>>
>>> Of course. Refactoring (e.g., replacing `setq' with `let'), adding code
>>> comments, tests, using Element where applicable is always good. 
>>
>> Okay. I thought there might be some big chunk of Org that needed to be
>> shifted over on top of elements.
>
> There’s plenty of stuff to refactor in org.el, org-agenda.el etc.

I was fishing for something more specific, but if there aren't any
desperate necessities, I guess that's a good thing. I'll take a look.

Marcin Borkowski  writes:

> On 2015-10-27, at 19:53, Eric Abrahamsen  wrote:
>
>> I can adapt the code from org-annotate. The unfortunate thing about
>> tabulated list mode, which I otherwise really like, isn't able to show
>> multi-line list items. That really crimps its usefulness in showing
>> footnotes and annotations, since you can only see the first line.
>> Bummer.
>
> BTW: have you looked at EWOC?
>
> http://mbork.pl/2015-07-18_TLM_vs_EWOC,_or_there_and_back_again

I had not, and that was really interesting! Thanks for the link. On
balance, I'd like TLM to support this, but we'll see what people think.

E

Re: [O] Some projects

[Marcin Borkowski]

On 2015-10-27, at 19:53, Eric Abrahamsen  wrote:

> I can adapt the code from org-annotate. The unfortunate thing about
> tabulated list mode, which I otherwise really like, isn't able to show
> multi-line list items. That really crimps its usefulness in showing
> footnotes and annotations, since you can only see the first line.
> Bummer.

BTW: have you looked at EWOC?

http://mbork.pl/2015-07-18_TLM_vs_EWOC,_or_there_and_back_again

Hth,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: [O] Some projects

[Rasmus]

Eric Abrahamsen  writes:

> Right, I'd forgotten the distinction. I really only use orgstruct for
> plain/numbered list editing (and I guess the occasional table), and
> filling/indentation is pretty key there.

AFAIK, this doesn't work in commented lines (e.g., when using orgstruct
with init.el).

>> I think OrgStruct may be redefined as an outline minor mode with Org
>> bindings. This is very different from Org. Even indentation and filling
>> should be new functions since Org's recognizes context that doesn't make
>> sense in OrgStruct.
>
> Would that mean that lists and tables wouldn't be supported? 

ATM tables are supported via orgstruct++-mode, though at list basic list
support is provided by orgstruct-mode.

> The unfortunate thing about tabulated list mode, which I otherwise
> really like, isn't able to show multi-line list items. That really
> crimps its usefulness in showing footnotes and annotations, since you
> can only see the first line.  Bummer.

Did you open a bug for this?

>>> These new features aside, is there any need to do any fundamental
>>> refactoring? I mostly mean altering existing Org libraries to use the
>>> element framework, stuff like that...
>>
>> Of course. Refactoring (e.g., replacing `setq' with `let'), adding code
>> comments, tests, using Element where applicable is always good. 
>
> Okay. I thought there might be some big chunk of Org that needed to be
> shifted over on top of elements.

There’s plenty of stuff to refactor in org.el, org-agenda.el etc.

Rasmus

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

Re: [O] Some projects

[Eric Abrahamsen]

Nicolas Goaziou  writes:

> Eric Abrahamsen  writes:
>
>> I've tried more than once over the past couple of years to attack
>> orgstruct mode, and been defeated every time. Largely because
>> indentation/filling is so damn complicated (too many layers of
>> indirection for my little brain), and orgstruct added yet another layer
>> of indirection on top of that. I think a rewrite would not be a bad
>> thing, and would be happy to participate.
>
> Basically, OrgStruct is Org with a very limited syntax, i.e., it only
> recognizes headlines and lists. OrgStruct++ adds indentation and
> filling.

Right, I'd forgotten the distinction. I really only use orgstruct for
plain/numbered list editing (and I guess the occasional table), and
filling/indentation is pretty key there.

> I think OrgStruct may be redefined as an outline minor mode with Org
> bindings. This is very different from Org. Even indentation and filling
> should be new functions since Org's recognizes context that doesn't make
> sense in OrgStruct.

Would that mean that lists and tables wouldn't be supported? 

>> The one thing I like about the package (indeed, it's what the bulk of
>> the code actually does) is the ability to "pop up" a single annotation's
>> text in a small, easily-dismissed special-mode buffer. Also, to display
>> all of a buffer's annotations in a tabulated-list pop-up buffer, where
>> you can easily jump to/edit/delete the various annotations.
>>
>> Obviously Org footnotes (and future annotations) have jump there/jump
>> back capability, but for some reason I feel much more comfortable with
>> this style of browsing.
>
> Have you tried C-c ' one a footnote reference? Unlike to C-c C-o, it
> will pop-up a dedicated buffer for editing.

Hey, I didn't know about that. That's pretty nice! It's not *quite* as
no-brainer as the special-mode popups, but definitely close enough that
there's no need to write anything else.

> However, there is no global view of all footnotes. If it is useful, it
> might be nice to add one and trigger it from, e.g., to
> `org-footnote-action's menu.

I can adapt the code from org-annotate. The unfortunate thing about
tabulated list mode, which I otherwise really like, isn't able to show
multi-line list items. That really crimps its usefulness in showing
footnotes and annotations, since you can only see the first line.
Bummer.

>> These new features aside, is there any need to do any fundamental
>> refactoring? I mostly mean altering existing Org libraries to use the
>> element framework, stuff like that...
>
> Of course. Refactoring (e.g., replacing `setq' with `let'), adding code
> comments, tests, using Element where applicable is always good. 

Okay. I thought there might be some big chunk of Org that needed to be
shifted over on top of elements.

Eric

Re: [O] pdflatex not found?

[Rainer M Krug]

Peter Davis  writes:

> On 10/27/15 1:50 PM, Nick Dokos wrote:
>> Peter Davis  writes:
>>> According to 
>>> , 
>>> .profile is
>>> bash-specific. tcsh has a different set of login/session initialization 
>>> files.
>>>
>> No, it does not say that .profile is bash-specific at all: it
>> just says it's used by bash and not used by tcsh. What *is*
>> specific to bash is $HOME/.bash_profile.
>
> Sorry.
>
>> But when setting up the window environment on Linux, the various scripts
>> are executed by whatever POSIX shell is available on the system (usually
>> sh on Linux), because a POSIX shell is supposed to be part of a POSIX
>> system, so guaranteed to be available (which is not true of csh/tcsh).
>> Hence .profile is the common denominator.
>
> Yes, .profile is the common denominator ... except where it isn't.

And on OS X everything is different anyway and changes from time to time.

Cheers,

Rainer
>
> Thanks,
> -pd
>
>

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax :   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

PGP: 0x0F52F982


signature.asc
Description: PGP signature

Re: [O] pdflatex not found?

[Peter Davis]

On 10/27/15 1:50 PM, Nick Dokos wrote:

Peter Davis  writes:

According to 
, .profile is
bash-specific. tcsh has a different set of login/session initialization files.


No, it does not say that .profile is bash-specific at all: it
just says it's used by bash and not used by tcsh. What *is*
specific to bash is $HOME/.bash_profile.


Sorry.


But when setting up the window environment on Linux, the various scripts
are executed by whatever POSIX shell is available on the system (usually
sh on Linux), because a POSIX shell is supposed to be part of a POSIX
system, so guaranteed to be available (which is not true of csh/tcsh).
Hence .profile is the common denominator.


Yes, .profile is the common denominator ... except where it isn't.

Thanks,
-pd

Re: [O] pdflatex not found?

[Nick Dokos]

Peter Davis  writes:

> On 10/27/15 12:45 PM, Rainer M Krug wrote:
>
> Nick Dokos  writes:
>
> If OS X does not use $HOME/.profile to initialize the environment of 
> programs
> (even in the graphical enviroment), that seems to me to be a serious
> bug. 
> 
> Aparently it is not.
>
> According to 
> , .profile 
> is
> bash-specific. tcsh has a different set of login/session initialization files.
>

No, it does not say that .profile is bash-specific at all: it
just says it's used by bash and not used by tcsh. What *is*
specific to bash is $HOME/.bash_profile.

$HOME/.profile is used by the original Bourne shell and its descendants,
ksh and bash - Wikipedia says it's also used by zsh.  AFAIK, it is
mandated by POSIX. It is not used by csh and its descendants (they use
.login instead).

But when setting up the window environment on Linux, the various scripts
are executed by whatever POSIX shell is available on the system (usually
sh on Linux), because a POSIX shell is supposed to be part of a POSIX
system, so guaranteed to be available (which is not true of csh/tcsh).
Hence .profile is the common denominator.

--
Nick

Re: [O] pdflatex not found?

[Nick Dokos]

Rainer M Krug  writes:

> Nick Dokos  writes:
>
>> Rainer M Krug  writes:
>>
>>> Fatma Başak Aydemir  writes:
>>>
 I do not know the reasons but I had the same problem in the past on OS X.
>>>
>>> In from Yosemite onwards, programs started from the finder / spotlight /
>>> gui (however you call this) do *not* inherit from the .bashrc
>>> anymore. This caused many problems.
>>
>> I can understand not inheriting from .bashrc: shells should only use
>> that for interactive initializations (aliases and such).
>
> Right.
>
>>
>> $HOME/.profile however is another matter: it is read by a login shell
>> (in a non-graphical or console environment) and so its settings are
>> inherited by everybody started from that login shell: that's where env
>> variables are supposed to be defined and exported. Desktop environments
>> have to go to some lengths to read it and initialize things but as I
>> mentioned in my previous message, they *do* do that (on Linux - although
>> the mechanism varies by distro, hence the "mess" comment).
>>
>> If OS X does not use $HOME/.profile to initialize the environment of programs
>> (even in the graphical enviroment), that seems to me to be a serious
>> bug. 
>
> Aparently it is not.
>

They do things differently at Apple:

http://stackoverflow.com/questions/135688/setting-environment-variables-in-os-x

has some answers: imo, the launchd.conf method should be avoided (it
applies to every user), but the environment.plist method (whatever that
is) seems to be the right solution - and although it did not work for
Spotlight-launched applications (whatever Spotlight is) in 10.5, it
apparently works in 10.6 or later.

As you can imagine, all my knowledge comes from that article and
references therein: take it with the appropriate grain of salt.

Anyway, this is very far from org-mode, so maybe it should be pursued in
a different forum.

--
Nick

Re: [O] pdflatex not found?

[Peter Davis]

On 10/27/15 12:45 PM, Rainer M Krug wrote:


Nick Dokos  writes:


If OS X does not use $HOME/.profile to initialize the environment of 
programs
(even in the graphical enviroment), that seems to me to be a serious
bug.

Aparently it is not.


According to 
, 
.profile is bash-specific. tcsh has a different set of login/session 
initialization files.


-pd

Re: [O] pdflatex not found?

[Rainer M Krug]

Peter Davis  writes:

> Rainer M Krug  writes:
>
>>>
>>> Sorry. It's OS X 10.10.5, using GNU Emacs 24.5.1
>>
>> I thought so.
>>
>> OK - you have pdflatex in the terminal? If yes, you have to bring the
>> PATH from the terminal into emacs. I use
>>
>> I use the package exec-path-from-shell for this (and use-package in general):
>>
>> (use-package exec-path-from-shell
>>   :ensure t
>>   :config 
>>   (exec-path-from-shell-initialize)
>>   (exec-path-from-shell-copy-env "LC_ALL")
>>   (exec-path-from-shell-copy-env "LANG")
>>   )
>>
>> so
>> (require 'exec-path-to-shell)
>> (exec-path-from-shell-initialize)
>>
>> should do this.
>>
>
> Thanks, Rainer. This also raises a question:
>
> If I run emacs from Finder, which shell governs its behavior? I use both zsh 
> and tcsh in iTerm 2. (

To quote from the website
[[https://github.com/purcell/exec-path-from-shell]]:

,
| Motivation
| 
| Ever find that a command works in your shell, but not in Emacs?
| 
| This happens a lot on OS X, where an Emacs instance started from the GUI
| inherits a default set of environment variables.
| 
| This library works solves this problem by copying important environment
| variables from the user's shell: it works by asking your shell to print
| out the variables of interest, then copying them into the Emacs
| environment.
| 
| Compatibility
| 
| If you use a non-POSIX-standard shell such as tcsh or fish, your shell
| will be asked to execute sh as a subshell in order to print out the
| variables in a format which can be reliably parsed. sh must be a
| POSIX-compliant shell in this case.
| 
| Note that shell variables which have not been exported as environment
| variables (e.g. using the "export" keyword) may not be visible to
| `exec-path-from-shell'.
`

Maybe this helps you? I have never used anything different than bash and
never Ruby - so I can't help you there.

Cheers,

Rainer

>
> I think I have tcsh set as my default, but I haven't figured out how
> to get Ruby/Rails, etc. running from there, so I still use zsh
> for some development.)
>
> Thanks!
> -pd

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax :   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

PGP: 0x0F52F982


signature.asc
Description: PGP signature

Re: [O] pdflatex not found?

[Rainer M Krug]

Nick Dokos  writes:

> Rainer M Krug  writes:
>
>> Fatma Başak Aydemir  writes:
>>
>>> I do not know the reasons but I had the same problem in the past on OS X.
>>
>> In from Yosemite onwards, programs started from the finder / spotlight /
>> gui (however you call this) do *not* inherit from the .bashrc
>> anymore. This caused many problems.
>
> I can understand not inheriting from .bashrc: shells should only use
> that for interactive initializations (aliases and such).

Right.

>
> $HOME/.profile however is another matter: it is read by a login shell
> (in a non-graphical or console environment) and so its settings are
> inherited by everybody started from that login shell: that's where env
> variables are supposed to be defined and exported. Desktop environments
> have to go to some lengths to read it and initialize things but as I
> mentioned in my previous message, they *do* do that (on Linux - although
> the mechanism varies by distro, hence the "mess" comment).
>
> If OS X does not use $HOME/.profile to initialize the environment of programs
> (even in the graphical enviroment), that seems to me to be a serious
> bug. 

Aparently it is not.

Cheers,

Rainer
-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax :   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

PGP: 0x0F52F982


signature.asc
Description: PGP signature

Re: [O] pdflatex not found?

[Nick Dokos]

Rainer M Krug  writes:

> Fatma Başak Aydemir  writes:
>
>> I do not know the reasons but I had the same problem in the past on OS X.
>
> In from Yosemite onwards, programs started from the finder / spotlight /
> gui (however you call this) do *not* inherit from the .bashrc
> anymore. This caused many problems.

I can understand not inheriting from .bashrc: shells should only use
that for interactive initializations (aliases and such).

$HOME/.profile however is another matter: it is read by a login shell
(in a non-graphical or console environment) and so its settings are
inherited by everybody started from that login shell: that's where env
variables are supposed to be defined and exported. Desktop environments
have to go to some lengths to read it and initialize things but as I
mentioned in my previous message, they *do* do that (on Linux - although
the mechanism varies by distro, hence the "mess" comment).

If OS X does not use $HOME/.profile to initialize the environment of programs
(even in the graphical enviroment), that seems to me to be a serious
bug. 

-- 
Nick

Re: [O] pdflatex not found?

[Peter Davis]

Rainer M Krug  writes:

>>
>> Sorry. It's OS X 10.10.5, using GNU Emacs 24.5.1
>
> I thought so.
>
> OK - you have pdflatex in the terminal? If yes, you have to bring the
> PATH from the terminal into emacs. I use
>
> I use the package exec-path-from-shell for this (and use-package in general):
>
> (use-package exec-path-from-shell
>   :ensure t
>   :config 
>   (exec-path-from-shell-initialize)
>   (exec-path-from-shell-copy-env "LC_ALL")
>   (exec-path-from-shell-copy-env "LANG")
>   )
>
> so
> (require 'exec-path-to-shell)
> (exec-path-from-shell-initialize)
>
> should do this.
>

Thanks, Rainer. This also raises a question:

If I run emacs from Finder, which shell governs its behavior? I use both zsh 
and tcsh in iTerm 2. (

I think I have tcsh set as my default, but I haven't figured out how to get 
Ruby/Rails, etc. running from there, so I still use zsh
for some development.)

Thanks!
-pd

Re: [O] Agenda to iCal not working

[Jorge A. Alfaro-Murillo]

Ken Mankoff writes:

I'm using the examples from 
https://www.gnu.org/software/emacs/manual/html_node/org/Exporting-Agenda-Views.html 

Specifically, 

(setq org-agenda-custom-commands [...] 




But the HTML, PS, and ICS files are not being created. If I'm 
visiting an Org file and run (org-icalendar-export-to-ics) then 
the ICS is generated. 

Can someone offer advice why the ICS isn't generated when I 
generate a specific agenda view?


Setting up the agenda custom commands is not related to ical 
export. Have you run org-icalendar-combine-agenda-files?


--
Jorge.

Re: [O] pdflatex not found?

[Charles C. Berry]

On Mon, 26 Oct 2015, Nick Dokos wrote:


Peter Davis  writes:


Nick Dokos  writes:



Peter Davis  writes:


I'm trying to export PDF from org, but I'm getting the error:

pdflatex: Command not found. [3 times]

I've checked the definition of exec-path, and it includes
"/usr/texbin", which is where tcsh tells me the executable is.

Any ideas?



Backtrace?


Sorry. Here's the backtrace:

Debugger entered--Lisp error: (error "PDF file ./test.pdf wasn't produced")
  signal(error ("PDF file ./test.pdf wasn't produced"))
  error("PDF file ./test.pdf wasn't produced")
  org-latex-compile("./test.tex")
  #[(file) "\301!\207" [file org-latex-compile] 2]("./test.tex")
  org-export-to-file(latex "./test.tex" nil nil nil nil nil #[(file)
"\301!\207" [file org-latex-compile] 2])
  org-latex-export-to-pdf(nil nil nil nil)
  (org-open-file (org-latex-export-to-pdf nil s v b))
  (if a (org-latex-export-to-pdf t s v b) (org-open-file 
(org-latex-export-to-pdf nil s v b)))
  (lambda (a s v b) (if a (org-latex-export-to-pdf t s v b)
(org-open-file (org-latex-export-to-pdf nil s v b(nil nil nil nil)
  org-export-dispatch(nil)
  call-interactively(org-export-dispatch nil nil)
  command-execute(org-export-dispatch)

This seems less useful to me than the *Messages* buffer:



Yes, probably, but if I can get people to submit backtraces when getting
an error, we can cut down the email volume by a factor of 2.43 (making up
fictitious data to bolster my case...) In all seriousness, at least it
shows that you are not going down some strange path.

It's not clear to me why the error message in the message file is different
from the error message above though.


Debug on Error enabled globally
org-babel-exp processing...
executing Dot code block...
Wrote 
/var/folders/d4/xb7t0gbd0f97p6494kz5xzdnmlncz8/T/babel-2213VOW/ob-input-22136yU
Code block evaluation complete.
Saving file /Users/davisp/Dropbox/HMH/test.tex...
Wrote /Users/davisp/Dropbox/HMH/test.tex
Processing LaTeX file ./test.tex...
pdflatex: Command not found. [3 times]
Entering debugger...
Mark set
End of buffer

I did verify that the shell, my default of tcsh, does show pdflatex at
the right location, /usr/texbin/pdflatex



In combination, this pretty much says that org-latex-pdf-process was
called (by examining the code for org-latex-compile) and it is set to
the default value of invoking pdflatex three times (hence - probably -
the "command not found 3 times" error), so as I said the standard path.

As others have pointed out, your emacs does not know where to find
pdflatex, even though your tcsh might. If your emacs is started from a
tcsh that can find pdflatex, that would be strange; if it is started
from your desktop environment/window manager, not so much (there are
many things that could go wrong).

OTOH, if exec-path contains the directory where pdflatex resides, then
things are a bit screwy: exec-path is used by call-process, which is
used by shell-command, which is used by org-latex-compile: so pdflatex
should be found - that's a bit of a mystery.


shell-command (and call-process, I guess) seems not to use exec-path -
at least not always.

For example:

#+BEGIN_SRC emacs-lisp :results output
(shell-command "which ebrowse")
#+END_SRC

fails to find ebrowse even though exec-path leads to it.

And

#+BEGIN_SRC emacs-lisp
(shell-command "echo $PATH" "*path*")
#+END_SRC

shows what (getenv "PATH") yields - not exec-path

Give `setenv' a try.

Best,

Chuck



What happens if you say M-x shell-command RET pdflatex RET?

Somebody suggested running "which pdflatex" in your shell - what does
that say?

And you say it should be in /usr/texbin - what happens if you invoke
it with an absolute path: "/usr/texbin/pdflatex" in your shell?

--
Nick

Re: [O] pdflatex not found?

[Cook, Malcolm]

> 
 > John Kitchin  writes:
 > 
 > > This reminds me that I think I have this problem unless I open Emacs from a
 > > command line.
 > 
 > Yup - this is one way of circumvent the problem: by starting emacs from
 > the command line.

And, just to chime in late in the conversation, if your emacs was installed as 
an mac application using, say, http://emacsformacosx.com/ then you can start it 
from the command line as:

open -a /Applications/path/to/emacs

and get the environment variables you expect...

 > 
 > 
 > >
 > > On Tuesday, October 27, 2015, Nick Dokos  wrote:
 > >
 > >> Fatma Başak Aydemir > writes:
 > >>
 > >> > I do not know the reasons but I had the same problem in the past on OS 
 > >> > X.
 > >> >
 > >> > exec-path-from-shell package is a nice solution for that.
 > >> >
 > >> > https://github.com/purcell/exec-path-from-shell
 > >> >
 > >>
 > >> Just the need for a package like that indicates that something is badly
 > >> broken on OS X, I think. To be fair, it's a mess on Linux as well, but
 > >> it is possible to make sure that variables you define (and export) in
 > >> your .profile get propagated to applications started by the DE/WM. In my
 > >> current installation (Fedora 21), that is done by
 > >> /etc/X11/xinit/xinitrc-common, which does this:
 > >>
 > >> [ -r $HOME/.profile ] && . $HOME/.profile
 > >>
 > >> Maybe OS X has a "hidden" mechanism like this?
 > >>
 > >> > 27/10/15 14:43 tarihinde Peter Davis yazdı:
 > >> >> Rainer M Krug > writes:
 > >> >>
 > >> >>> Envoyé de mon iPhone
 > >> >>>
 > >>  Le 27 oct. 2015 à 01:14, Nick Dokos  >
 > >> a écrit :
 > >> 
 > >>  Peter Davis > writes:
 > >> 
 > >> > Nick Dokos > writes:
 > >>  ...
 > >>  Yes, probably, but if I can get people to submit backtraces when
 > >> getting
 > >>  an error, we can cut down the email volume by a factor of 2.43
 > >> (making up
 > >>  fictitious data to bolster my case...) In all seriousness, at least 
 > >>  it
 > >>  shows that you are not going down some strange path.
 > >> >> I think the actual number is more like 2.17, but let's not quibble.
 > >> >>
 > >>  What happens if you say M-x shell-command RET pdflatex RET?
 > >> >> Not found.
 > >> >>
 > >>  Somebody suggested running "which pdflatex" in your shell - what
 > does
 > >>  that say?
 > >> >> Still not found. However, adding it to ~/.tcshrc seems to fix the
 > >> >> problem. That makes sense, but leaves two questions:
 > >> >>
 > >> >> 1) Why am I able to run pdflatex (without specifying the path) just
 > >> >> from the shell running in a terminal window?
 > >> >>
 > >> >> 2) What's the point of defining the emacs exec-path, since I needed
 > >> >> to define the shell's PATH variable anyway?
 > >> >>
 > >>
 > >> FWIW, I never define exec-path explicitly: it is set from my $PATH when
 > >> emacs starts.
 > >>
 > >> --
 > >> Nick
 > >>
 > >>
 > >>
 > >>
 > 
 > --
 > Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
 > UCT), Dipl. Phys. (Germany)
 > 
 > Centre of Excellence for Invasion Biology
 > Stellenbosch University
 > South Africa
 > 
 > Tel :   +33 - (0)9 53 10 27 44
 > Cell:   +33 - (0)6 85 62 59 98
 > Fax :   +33 - (0)9 58 10 27 44
 > 
 > Fax (D):+49 - (0)3 21 21 25 22 44
 > 
 > email:  rai...@krugs.de
 > 
 > Skype:  RMkrug
 > 
 > PGP: 0x0F52F982

Re: [O] pdflatex not found?

[Rainer M Krug]

John Kitchin  writes:

> This reminds me that I think I have this problem unless I open Emacs from a
> command line.

Yup - this is one way of circumvent the problem: by starting emacs from
the command line.


>
> On Tuesday, October 27, 2015, Nick Dokos  wrote:
>
>> Fatma Başak Aydemir > writes:
>>
>> > I do not know the reasons but I had the same problem in the past on OS X.
>> >
>> > exec-path-from-shell package is a nice solution for that.
>> >
>> > https://github.com/purcell/exec-path-from-shell
>> >
>>
>> Just the need for a package like that indicates that something is badly
>> broken on OS X, I think. To be fair, it's a mess on Linux as well, but
>> it is possible to make sure that variables you define (and export) in
>> your .profile get propagated to applications started by the DE/WM. In my
>> current installation (Fedora 21), that is done by
>> /etc/X11/xinit/xinitrc-common, which does this:
>>
>> [ -r $HOME/.profile ] && . $HOME/.profile
>>
>> Maybe OS X has a "hidden" mechanism like this?
>>
>> > 27/10/15 14:43 tarihinde Peter Davis yazdı:
>> >> Rainer M Krug > writes:
>> >>
>> >>> Envoyé de mon iPhone
>> >>>
>>  Le 27 oct. 2015 à 01:14, Nick Dokos >
>> a écrit :
>> 
>>  Peter Davis > writes:
>> 
>> > Nick Dokos > writes:
>>  ...
>>  Yes, probably, but if I can get people to submit backtraces when
>> getting
>>  an error, we can cut down the email volume by a factor of 2.43
>> (making up
>>  fictitious data to bolster my case...) In all seriousness, at least it
>>  shows that you are not going down some strange path.
>> >> I think the actual number is more like 2.17, but let's not quibble.
>> >>
>>  What happens if you say M-x shell-command RET pdflatex RET?
>> >> Not found.
>> >>
>>  Somebody suggested running "which pdflatex" in your shell - what does
>>  that say?
>> >> Still not found. However, adding it to ~/.tcshrc seems to fix the
>> >> problem. That makes sense, but leaves two questions:
>> >>
>> >> 1) Why am I able to run pdflatex (without specifying the path) just
>> >> from the shell running in a terminal window?
>> >>
>> >> 2) What's the point of defining the emacs exec-path, since I needed
>> >> to define the shell's PATH variable anyway?
>> >>
>>
>> FWIW, I never define exec-path explicitly: it is set from my $PATH when
>> emacs starts.
>>
>> --
>> Nick
>>
>>
>>
>>

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax :   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

PGP: 0x0F52F982


signature.asc
Description: PGP signature

Re: [O] Some projects

[Rainer M Krug]

Rasmus Pank Roulund  writes:

> Hi,
>
> Ista Zahn  writes:
>
>> I disagree. pandoc supports conversion to and from org-mode.
>
> I fail to see how this is relevant for the discussion at hand.

This is not really relevant for citations discussion itself, but having
pandoc will make it easier to use it for other interesting usages -
while the java option is as far as I understand citation only.
>
>> Making pandoc a requirement will enable other useful features (e.g.,
>> "Import documents from...", alternative pandoc-based exporters etc.
>
> AFAIK, nobody is working on this.

But it would be an interesting way for the future.

Rainer


>
>> IMO pandoc is easy on Windows and OSX. It is easy on some Linux distros
>> but not all.
>
>> I use Arch LInux, where getting pandoc requires some work, but I think
>> that is an issue that the Linux distros need to work out.
>
> No it doesn't: pacman -S pandoc.
>
> The relevant question here is whether we can accept to rely on pandoc for
> CSL support.  Any other feature is irrelevant.
>
> At 25MB, a static, precompiled pandoc is probably fine, but for users of
> some OSs, such as Archlinux or even worse some OS where pandoc is not
> generally available as a precompiled package, it’s a really, really big
> dependency.  I may still be the best option, though.
>
> Rasmus

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax :   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

PGP: 0x0F52F982


signature.asc
Description: PGP signature

Re: [O] pdflatex not found?

[John Kitchin]

This reminds me that I think I have this problem unless I open Emacs from a
command line.

On Tuesday, October 27, 2015, Nick Dokos  wrote:

> Fatma Başak Aydemir > writes:
>
> > I do not know the reasons but I had the same problem in the past on OS X.
> >
> > exec-path-from-shell package is a nice solution for that.
> >
> > https://github.com/purcell/exec-path-from-shell
> >
>
> Just the need for a package like that indicates that something is badly
> broken on OS X, I think. To be fair, it's a mess on Linux as well, but
> it is possible to make sure that variables you define (and export) in
> your .profile get propagated to applications started by the DE/WM. In my
> current installation (Fedora 21), that is done by
> /etc/X11/xinit/xinitrc-common, which does this:
>
> [ -r $HOME/.profile ] && . $HOME/.profile
>
> Maybe OS X has a "hidden" mechanism like this?
>
> > 27/10/15 14:43 tarihinde Peter Davis yazdı:
> >> Rainer M Krug > writes:
> >>
> >>> Envoyé de mon iPhone
> >>>
>  Le 27 oct. 2015 à 01:14, Nick Dokos >
> a écrit :
> 
>  Peter Davis > writes:
> 
> > Nick Dokos > writes:
>  ...
>  Yes, probably, but if I can get people to submit backtraces when
> getting
>  an error, we can cut down the email volume by a factor of 2.43
> (making up
>  fictitious data to bolster my case...) In all seriousness, at least it
>  shows that you are not going down some strange path.
> >> I think the actual number is more like 2.17, but let's not quibble.
> >>
>  What happens if you say M-x shell-command RET pdflatex RET?
> >> Not found.
> >>
>  Somebody suggested running "which pdflatex" in your shell - what does
>  that say?
> >> Still not found. However, adding it to ~/.tcshrc seems to fix the
> >> problem. That makes sense, but leaves two questions:
> >>
> >> 1) Why am I able to run pdflatex (without specifying the path) just
> >> from the shell running in a terminal window?
> >>
> >> 2) What's the point of defining the emacs exec-path, since I needed
> >> to define the shell's PATH variable anyway?
> >>
>
> FWIW, I never define exec-path explicitly: it is set from my $PATH when
> emacs starts.
>
> --
> Nick
>
>
>
>

-- 
John

---
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] pdflatex not found?

[Rainer M Krug]

Nick Dokos  writes:

> Fatma Başak Aydemir  writes:
>
>> I do not know the reasons but I had the same problem in the past on OS X.
>>
>> exec-path-from-shell package is a nice solution for that.
>>
>> https://github.com/purcell/exec-path-from-shell
>>
>
> Just the need for a package like that indicates that something is badly
> broken on OS X, I think. To be fair, it's a mess on Linux as well, but
> it is possible to make sure that variables you define (and export) in
> your .profile get propagated to applications started by the DE/WM. In my
> current installation (Fedora 21), that is done by
> /etc/X11/xinit/xinitrc-common, which does this:
>
> [ -r $HOME/.profile ] && . $HOME/.profile
>
> Maybe OS X has a "hidden" mechanism like this?

Nope - this is a "feature" since Yosemite.

Cheers,

Rainer

>
>> 27/10/15 14:43 tarihinde Peter Davis yazdı:
>>> Rainer M Krug  writes:
>>>
 Envoyé de mon iPhone

> Le 27 oct. 2015 à 01:14, Nick Dokos  a écrit :
>
> Peter Davis  writes:
>
>> Nick Dokos  writes:
> ...
> Yes, probably, but if I can get people to submit backtraces when getting
> an error, we can cut down the email volume by a factor of 2.43 (making up
> fictitious data to bolster my case...) In all seriousness, at least it
> shows that you are not going down some strange path.
>>> I think the actual number is more like 2.17, but let's not quibble.
>>>
> What happens if you say M-x shell-command RET pdflatex RET?
>>> Not found.
>>>
> Somebody suggested running "which pdflatex" in your shell - what does
> that say?
>>> Still not found. However, adding it to ~/.tcshrc seems to fix the
>>> problem. That makes sense, but leaves two questions:
>>>
>>> 1) Why am I able to run pdflatex (without specifying the path) just
>>> from the shell running in a terminal window?
>>>
>>> 2) What's the point of defining the emacs exec-path, since I needed
>>> to define the shell's PATH variable anyway?
>>>
>
> FWIW, I never define exec-path explicitly: it is set from my $PATH when
> emacs starts.
>
> --
> Nick
>
>
>

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax :   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

PGP: 0x0F52F982


signature.asc
Description: PGP signature

Re: [O] pdflatex not found?

[Rainer M Krug]

Fatma Başak Aydemir  writes:

> I do not know the reasons but I had the same problem in the past on OS X.

In from Yosemite onwards, programs started from the finder / spotlight /
gui (however you call this) do *not* inherit from the .bashrc
anymore. This caused many problems. Furthermore, there seems to be a
change from emacs 24.5 to emacs 25 in this regard (this is why I had to
add

--8<---cut here---start->8---
  (exec-path-from-shell-copy-env "LC_ALL")
  (exec-path-from-shell-copy-env "LANG")
--8<---cut here---end--->8---

to my emacs.org to get the LANG in R correct.

Unfortunately I can't find the thread on the internet anymore about
these problems.


>
> exec-path-from-shell package is a nice solution for that.

This is a lovely little package and very useful.

Cheers,

Rainer

>
> https://github.com/purcell/exec-path-from-shell
>
> 27/10/15 14:43 tarihinde Peter Davis yazdı:
>> Rainer M Krug  writes:
>>
>>> Envoyé de mon iPhone
>>>
 Le 27 oct. 2015 à 01:14, Nick Dokos  a écrit :

 Peter Davis  writes:

> Nick Dokos  writes:
 ...
 Yes, probably, but if I can get people to submit backtraces when getting
 an error, we can cut down the email volume by a factor of 2.43 (making up
 fictitious data to bolster my case...) In all seriousness, at least it
 shows that you are not going down some strange path.
>> I think the actual number is more like 2.17, but let's not quibble.
>>
 What happens if you say M-x shell-command RET pdflatex RET?
>> Not found.
>>
 Somebody suggested running "which pdflatex" in your shell - what does
 that say?
>> Still not found. However, adding it to ~/.tcshrc seems to fix the problem. 
>> That makes sense, but leaves two questions:
>>
>> 1) Why am I able to run pdflatex (without specifying the path) just from the 
>> shell running in a terminal window?
>>
>> 2) What's the point of defining the emacs exec-path, since I needed to 
>> define the shell's PATH variable anyway?
>>
 And you say it should be in /usr/texbin - what happens if you invoke
 it with an absolute path: "/usr/texbin/pdflatex" in your shell?
>>> Imiight have missed it - but which OS are you using?
>> Sorry. It's OS X 10.10.5, using GNU Emacs 24.5.1
>>
>> Thanks!
>> -pd
>>

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax :   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

PGP: 0x0F52F982


signature.asc
Description: PGP signature

Re: [O] Some projects

[Ista Zahn]

On Oct 27, 2015 11:09 AM, "Rasmus Pank Roulund"  wrote:
>
> Hi,
>
> Ista Zahn  writes:
>
> > I disagree. pandoc supports conversion to and from org-mode.
>
> I fail to see how this is relevant for the discussion at hand.
>
> > Making pandoc a requirement will enable other useful features (e.g.,
> > "Import documents from...", alternative pandoc-based exporters etc.
>
> AFAIK, nobody is working on this.

Not yet :-)
>
> > IMO pandoc is easy on Windows and OSX. It is easy on some Linux distros
> > but not all.
>
> > I use Arch LInux, where getting pandoc requires some work, but I think
> > that is an issue that the Linux distros need to work out.
>
> No it doesn't: pacman -S pandoc.

Good to know, thanks! That must be fairly recent.
>
> The relevant question here is whether we can accept to rely on pandoc for
> CSL support.  Any other feature is irrelevant.

That seems like a narrow way to look at it. Of course I agree that the
topic of discussion is citations, but I don't see why the bigger picture of
what the various options provide should be ignored.

I'll be happy to see improved citation support in org regardless of the
implementation details. But I do think pandoc deserves a serious look, and
I don't think the non-citation related possibilities it opens up are
irrelevant.

>
> At 25MB, a static, precompiled pandoc is probably fine, but for users of
> some OSs, such as Archlinux or even worse some OS where pandoc is not
> generally available as a precompiled package, it’s a really, really big
> dependency.  I may still be the best option, though.
>
> Rasmus
>
> --
> And when I’m finished thinking, I have to die a lot

Re: [O] Some projects

[Rasmus Pank Roulund]

Hi,

Ista Zahn  writes:

> I disagree. pandoc supports conversion to and from org-mode.

I fail to see how this is relevant for the discussion at hand.

> Making pandoc a requirement will enable other useful features (e.g.,
> "Import documents from...", alternative pandoc-based exporters etc.

AFAIK, nobody is working on this.

> IMO pandoc is easy on Windows and OSX. It is easy on some Linux distros
> but not all.

> I use Arch LInux, where getting pandoc requires some work, but I think
> that is an issue that the Linux distros need to work out.

No it doesn't: pacman -S pandoc.

The relevant question here is whether we can accept to rely on pandoc for
CSL support.  Any other feature is irrelevant.

At 25MB, a static, precompiled pandoc is probably fine, but for users of
some OSs, such as Archlinux or even worse some OS where pandoc is not
generally available as a precompiled package, it’s a really, really big
dependency.  I may still be the best option, though.

Rasmus

-- 
And when I’m finished thinking, I have to die a lot

Re: [O] pdflatex not found?

[Nick Dokos]

Fatma Başak Aydemir  writes:

> I do not know the reasons but I had the same problem in the past on OS X.
>
> exec-path-from-shell package is a nice solution for that.
>
> https://github.com/purcell/exec-path-from-shell
>

Just the need for a package like that indicates that something is badly
broken on OS X, I think. To be fair, it's a mess on Linux as well, but
it is possible to make sure that variables you define (and export) in
your .profile get propagated to applications started by the DE/WM. In my
current installation (Fedora 21), that is done by
/etc/X11/xinit/xinitrc-common, which does this:

[ -r $HOME/.profile ] && . $HOME/.profile

Maybe OS X has a "hidden" mechanism like this?

> 27/10/15 14:43 tarihinde Peter Davis yazdı:
>> Rainer M Krug  writes:
>>
>>> Envoyé de mon iPhone
>>>
 Le 27 oct. 2015 à 01:14, Nick Dokos  a écrit :

 Peter Davis  writes:

> Nick Dokos  writes:
 ...
 Yes, probably, but if I can get people to submit backtraces when getting
 an error, we can cut down the email volume by a factor of 2.43 (making up
 fictitious data to bolster my case...) In all seriousness, at least it
 shows that you are not going down some strange path.
>> I think the actual number is more like 2.17, but let's not quibble.
>>
 What happens if you say M-x shell-command RET pdflatex RET?
>> Not found.
>>
 Somebody suggested running "which pdflatex" in your shell - what does
 that say?
>> Still not found. However, adding it to ~/.tcshrc seems to fix the
>> problem. That makes sense, but leaves two questions:
>>
>> 1) Why am I able to run pdflatex (without specifying the path) just
>> from the shell running in a terminal window?
>>
>> 2) What's the point of defining the emacs exec-path, since I needed
>> to define the shell's PATH variable anyway?
>>

FWIW, I never define exec-path explicitly: it is set from my $PATH when
emacs starts.

--
Nick

Re: [O] Can't email multipart/alternative anymore

[Aaron Ecay]

2015ko urriak 23an, Peter Davis-ek idatzi zuen:
> 
> On 10/23/15 4:44 PM, Nicolas Goaziou wrote:
>> Hello,
>> 
>> Aaron Ecay  writes:
>> 
>>> Based on the backtrace, I think that if you do M-x load-library RET
>>> ox-org RET your error should disappear.
>>> 
>>> If that’s the cause, the attached (draft) patch should give a better
>>> error message in cases like this.
>> Thank you.
>> 
>> However, `org-export-barf-if-invalid-backend' raises an error, not
>> a user-error. IOW, it doesn't need to be verbose: it is a bug if a user
>> sees it anyway.
> 
> Actually, I didn't see the barf part in the mini-buffer. All I saw there 
> was:
> 
> Unknown "nil" back-end: Aborting export

Indeed – the patch I sent was targeted at better error messages, not
at avoiding the error.  (I first tried to automatically load ox-org in
the relevant case, but that runs into circular require problems).

I could do a smaller patch which just changes the error message text
within o-e-barf-if-invalid-backend.  Or drop it if you feel it’s not
worth it.

> 
> 
> I copied the rest from *Messages*
>> I suggest to (require 'ox-org) where appropriate and fix the issue.
>> I didn't look closely at the problem so you know better than me where
>> this line should be added.
> I replied earlier, but it doesn't seem to have shown up on the list yet. 
> Explicitly loading ox-org *did* fix the problem for me, but I already have
> 
> (require 'ox-org)
> 
> in my .emacs file, so I'm not sure why that was ineffective.

As Nicolas said, it would be good to know if upgrading org fixes the
issue that you see.

Thanks,

-- 
Aaron Ecay

Re: [O] pdflatex not found?

[Rainer M Krug]

Peter Davis  writes:

> Rainer M Krug  writes:
>
>> Envoyé de mon iPhone
>>
>>> Le 27 oct. 2015 à 01:14, Nick Dokos  a écrit :
>>> 
>>> Peter Davis  writes:
>>> 
 Nick Dokos  writes:
>>> ...
>>> Yes, probably, but if I can get people to submit backtraces when getting
>>> an error, we can cut down the email volume by a factor of 2.43 (making up
>>> fictitious data to bolster my case...) In all seriousness, at least it
>>> shows that you are not going down some strange path.
>
> I think the actual number is more like 2.17, but let's not quibble.
>
>>> 
>>> What happens if you say M-x shell-command RET pdflatex RET?
>
> Not found.
>
>>> Somebody suggested running "which pdflatex" in your shell - what does
>>> that say?
>
> Still not found. However, adding it to ~/.tcshrc seems to fix the problem. 
> That makes sense, but leaves two questions:
>
> 1) Why am I able to run pdflatex (without specifying the path) just from the 
> shell running in a terminal window?
>
> 2) What's the point of defining the emacs exec-path, since I needed to define 
> the shell's PATH variable anyway?
>
>>> And you say it should be in /usr/texbin - what happens if you invoke
>>> it with an absolute path: "/usr/texbin/pdflatex" in your shell?
>>
>> Imiight have missed it - but which OS are you using?
>
> Sorry. It's OS X 10.10.5, using GNU Emacs 24.5.1

I thought so.

OK - you have pdflatex in the terminal? If yes, you have to bring the
PATH from the terminal into emacs. I use

I use the package exec-path-from-shell for this (and use-package in general):

--8<---cut here---start->8---
(use-package exec-path-from-shell
  :ensure t
  :config 
  (exec-path-from-shell-initialize)
  (exec-path-from-shell-copy-env "LC_ALL")
  (exec-path-from-shell-copy-env "LANG")
  )
--8<---cut here---end--->8---

so
--8<---cut here---start->8---
(require 'exec-path-to-shell)
(exec-path-from-shell-initialize)
--8<---cut here---end--->8---

should do this.

Cheers,

Rainer


>
> Thanks!
> -pd

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax :   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

PGP: 0x0F52F982


signature.asc
Description: PGP signature

Re: [O] Some projects

[Ista Zahn]

On Tue, Oct 27, 2015 at 9:42 AM, Rasmus  wrote:
> Hi,
>
> Rainer M Krug  writes:
>
>> I don't know which OS you are using, but just checking on
>> [[https://github.com/jgm/pandoc/releases/1.15.1]] and
>> [[https://github.com/jgm/pandoc/releases/tag/1.15.1.1]]:
>>
>> Windows: 19.7 MB
>> Mac: 27.9 MB
>> Deb: 20.2 MB
>>
>> The 1600MB must be including LaTeX?
>
> Nope, but something like 100 haskell libraries and ghc.  I guess it’s not
> build in a static way?
>
> It’s much smaller on Debian, approx. 25Mb.  (I should switch to Fedora
> full-time).
>
>> In General, I like the idea of using the Pandoc approach, as Pandoc
>> provides a very useful framework for all kinds of conversions (and I
>> don't like java...)
>
> Your first argument refers to a side effect (to us), and it is irrelevant
> IMO.

I disagree. pandoc supports conversion to and from org-mode. Making
pandoc a requirement will enable other useful features (e.g., "Import
documents from...", alternative pandoc-based exporters etc. IMO pandoc
is easy on Windows and OSX. It is easy on some Linux distros but not
all. I use Arch LInux, where getting pandoc requires some work, but I
think that is an issue that the Linux distros need to work out. In
short, pandoc is extremely useful for org-mode users, and not only for
citations. I think pandoc is the way to go.

  Java run easily everywhere, easily, and if you use mathml for some
> of your documents, you’re likely already using a jar file with Org.
>
> That being said, it suggest that Pandoc /can/ be packed in a sensible way,
> which is good.
>
> Rasmus
>
> --
> A page of history is worth a volume of logic
>

Re: [O] org-reveal questions

[Eric S Fraga]

On Sunday, 25 Oct 2015 at 18:01, Matt Price wrote:

[...]

> could you file this as a bug report on github, and then post the URL? I'll
> try to figure out the issue and fix it. I'm a slow coder and actually don't
> use the #+HTML: directive, but have a ninterest in getting better.

Done: http://github.com/yjwen/org-reveal/issues/164
-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.2, Org release_8.3.2-209-gba4d33

Re: [O] org-crypt & multiple recipients

[Eric S Fraga]

On Monday, 26 Oct 2015 at 14:45, Nick Anderson wrote:

[...]

> But I guess I don't understand why there would have to be a header for
> each recipient (other than current implementation limitations with
> org-crypt).
>
> Currently the CRYPTKEY property identifies the email address or KEY that
> you want to encrypt for. If I have multiple of the same property the one
> that is listed first seems to be used.
>
> What if there were a CRYPTKEYS property that took a space separated list
> of keys or emails?

The logic, AFAIK, is that the main text is encrypted with a so-called
session key.  The key for this is then encrypted for each recipient
using their public key and only they can decrypt (with their private
key) this element, called a header.  Therefore, if you have multiple
recipients, you need multiple headers, i.e. multiple copies of the
session key each encrypted for a single recipient.

I hope this makes sense.

No matter how you do it, encrypting some text for multiple recipients
using PKI requires multiple copies of something, whether the original
text or a key used to encrypt that text.
-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.2, Org release_8.3.2-209-gba4d33

Re: [O] Links in comments

[Eric S Fraga]

On Monday, 26 Oct 2015 at 14:13, Kaushal Modi wrote:
> Hi all,
>
> I am sending this out again in the event someone knowing a solution to it
> can comment.

I don't know a solution.  If I do C-u C-x = with the cursor on the link
in a comment line, there is only one face shown.  Semantically, the line
is a comment and the whole point of comments is that they are not parsed
for any further meaning.  Representing the line, therefore, using the
comment face throughout makes sense.

Whether it's what *you* want or not is another issue, of course ;-)

I suggest changing your usage?  If you want links to be visible, they
should be in the main text?  Even within a COMMENT section say?
-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.2, Org release_8.3.2-209-gba4d33

Re: [O] pdflatex not found?

[Fatma Başak Aydemir]

I do not know the reasons but I had the same problem in the past on OS X.

exec-path-from-shell package is a nice solution for that.

https://github.com/purcell/exec-path-from-shell

27/10/15 14:43 tarihinde Peter Davis yazdı:

Rainer M Krug  writes:


Envoyé de mon iPhone


Le 27 oct. 2015 à 01:14, Nick Dokos  a écrit :

Peter Davis  writes:


Nick Dokos  writes:

...
Yes, probably, but if I can get people to submit backtraces when getting
an error, we can cut down the email volume by a factor of 2.43 (making up
fictitious data to bolster my case...) In all seriousness, at least it
shows that you are not going down some strange path.

I think the actual number is more like 2.17, but let's not quibble.


What happens if you say M-x shell-command RET pdflatex RET?

Not found.


Somebody suggested running "which pdflatex" in your shell - what does
that say?

Still not found. However, adding it to ~/.tcshrc seems to fix the problem. That 
makes sense, but leaves two questions:

1) Why am I able to run pdflatex (without specifying the path) just from the 
shell running in a terminal window?

2) What's the point of defining the emacs exec-path, since I needed to define 
the shell's PATH variable anyway?


And you say it should be in /usr/texbin - what happens if you invoke
it with an absolute path: "/usr/texbin/pdflatex" in your shell?

Imiight have missed it - but which OS are you using?

Sorry. It's OS X 10.10.5, using GNU Emacs 24.5.1

Thanks!
-pd



--

Fatma Başak Aydemir
PhD Student at ICT International Doctoral School
Department of Information Engineering and Computer Science
University of Trento
Skype: fatmabasak.aydemir
E-mail: ayde...@disi.unitn.it

Re: [O] Some projects

[Rasmus]

Aaron Ecay  writes:

> You have to write java to use it, which is a big negative (at least for
> me).  Last time I think we concluded that the CLI interface it exposes
> is not adequate (though I actually started off trying to use it).

I see.  That's probably the reason.

> There’s also the issue that it is just a bundling of citeproc-js with
> some java libraries (js interpreter, bibtex processor, ...), so someone
> who tries to extend it actually has to know both java and js.

Another drawback.

Pure JS (or perhaps Haskell?) is probably more accessible then.  FWIW,
there's a couple of libraries that promise to read bibtex on npm, though I
haven’t tried any of those. 

https://www.npmjs.com/search?q=bibtex

>> Do we WANT to depend on Pandoc?  I would say "no".  In my OS, where we
>> finally got a binary distribution of pandoc, the size of pandoc is still
>> 1600Mb!  I don’t know if this is representative of other systems, though.
>> E.g. what is the size of pandoc+deps in Debian?
>
> It’s unfortunate, but pandoc has the most easily adaptable CSL
> implementation for our use case, as far as I can see.  The other
> contender is Zotero (in JS, possibly with XUL-specific bits).  It would
> be good if somebody looked at what it would take for us to use Zotero’s
> implementation, just as Richard did for Pandoc.

Indeed.  I guess this is what they use:

 https://github.com/zotero/citeproc-node

It also looks rather complex...

Rasmus

-- 
9000!

Re: [O] pdflatex not found?

[Peter Davis]

Rainer M Krug  writes:

> Envoyé de mon iPhone
>
>> Le 27 oct. 2015 à 01:14, Nick Dokos  a écrit :
>> 
>> Peter Davis  writes:
>> 
>>> Nick Dokos  writes:
>> ...
>> Yes, probably, but if I can get people to submit backtraces when getting
>> an error, we can cut down the email volume by a factor of 2.43 (making up
>> fictitious data to bolster my case...) In all seriousness, at least it
>> shows that you are not going down some strange path.

I think the actual number is more like 2.17, but let's not quibble.

>> 
>> What happens if you say M-x shell-command RET pdflatex RET?

Not found.

>> Somebody suggested running "which pdflatex" in your shell - what does
>> that say?

Still not found. However, adding it to ~/.tcshrc seems to fix the problem. That 
makes sense, but leaves two questions:

1) Why am I able to run pdflatex (without specifying the path) just from the 
shell running in a terminal window?

2) What's the point of defining the emacs exec-path, since I needed to define 
the shell's PATH variable anyway?

>> And you say it should be in /usr/texbin - what happens if you invoke
>> it with an absolute path: "/usr/texbin/pdflatex" in your shell?
>
> Imiight have missed it - but which OS are you using?

Sorry. It's OS X 10.10.5, using GNU Emacs 24.5.1

Thanks!
-pd

Re: [O] Some projects

[Rasmus]

Hi,

Rainer M Krug  writes:

> I don't know which OS you are using, but just checking on
> [[https://github.com/jgm/pandoc/releases/1.15.1]] and
> [[https://github.com/jgm/pandoc/releases/tag/1.15.1.1]]:
>
> Windows: 19.7 MB
> Mac: 27.9 MB
> Deb: 20.2 MB
>
> The 1600MB must be including LaTeX?

Nope, but something like 100 haskell libraries and ghc.  I guess it’s not
build in a static way?

It’s much smaller on Debian, approx. 25Mb.  (I should switch to Fedora
full-time).

> In General, I like the idea of using the Pandoc approach, as Pandoc
> provides a very useful framework for all kinds of conversions (and I
> don't like java...)

Your first argument refers to a side effect (to us), and it is irrelevant
IMO.  Java run easily everywhere, easily, and if you use mathml for some
of your documents, you’re likely already using a jar file with Org.

That being said, it suggest that Pandoc /can/ be packed in a sensible way,
which is good.

Rasmus

-- 
A page of history is worth a volume of logic

Re: [O] Some projects

[Richard Lawrence]

Hi Rasmus and all,

Rasmus  writes:

> I would feel more comfortable relying on a JS library.  Perhaps it’s also
> easier to find people who are willing to work on/knows JS over the long
> haul...

Yes, I agree with both you and Aaron here.  JS is easier to distribute
and probably easier to find people to maintain.

>> OTOH, pandoc-citeproc includes a bibtex parser; we’d need to write a JS
>> one and wire it up to citeproc-js.  When I looked (quite some time ago),
>> there did not seem to be any good bibtex parsing libraries in JS (and
>> several third-rate ones).
>
> Bibtex support is essential, of course.
>
> Can someone remind me why citeproc-java isn’t good?  AFAIR, it has a
> bibtex parser.  But probably it lacks in some other dimension...

My recollection is that its command-line tool is not all that flexible,
and thus getting it to produce the kind of output we'd need requires
writing and maintaining Java, which no one really wanted to do.  Also, I
think the thought of firing up the JVM to process citations in an Org
document seemed a little...expensive.

Best,
Richard

Re: [O] Some projects

[Rainer M Krug]

Rasmus  writes:

> Aaron Ecay  writes:
>
>> Hi Richard, hi all,
>>
>> 2015ko urriak 26an, Richard Lawrence-ek idatzi zuen:
>>> 
>>
>> [...]
>>
 I was working on this rather intensively at one time, but I had to stop
 because other aspects of life intruded.  I have just been coming back
 towards a situation where I can imagine myself having some (still small,
 but non-zero) chunks of time to devote to working on org.  So I hope I
 will be able to pick this back up, but (regrettably) I’m not able to
 make any promises.
 
 Based on my recollection, here’s what the problems were when I stopped:
 
 - The only “off the shelf”-capable citation processing library that we
 found last time is in Haskell, which introduced some difficulties for
 distributing the resulting tool.  I know some projects
 (e.g. git-annex) are written in Haskell and distributed as static
 binaries for windows/mac/linux/etc.  We’d need to figure out how to do
 this, or find another citation processing library in an
 easier-to-distribute language.
>>> 
>>> Yes, this is my understanding, too.  In particular, there does not seem
>>> to be an Elisp CSL library, and it would be a lot of work to write one.
>>> 
>>> The other CSL library that looks complete and usable is citeproc-js; but
>>> like the Haskell library (pandoc-citeproc) it would need to be wrapped
>>> somehow so that it can talk with Org.
>>> 
>>> It should be relatively straightforward for someone who knows Javascript
>>> to write such a wrapper, if anyone wants to work on that.  But this does
>>> not really solve the problem with distribution.  
>>
>> It solves many of the hard problems though.  Node.js is distributed
>> as a binary for many platforms.  We’d just have to direct users to
>> install this in the “normal way,” and use the installed binary to
>> interpret the JS source.  Whereas for haskell we’d be stuck building
>> the binary ourselves, worrying about static linking/dll hell/32-bit
>> dinosaurs/any of a half-dozen other problems that I don’t really
>> understand.
>
> I would feel more comfortable relying on a JS library.  Perhaps it’s also
> easier to find people who are willing to work on/knows JS over the long
> haul...
>
>> OTOH, pandoc-citeproc includes a bibtex parser; we’d need to write a JS
>> one and wire it up to citeproc-js.  When I looked (quite some time ago),
>> there did not seem to be any good bibtex parsing libraries in JS (and
>> several third-rate ones).
>
> Bibtex support is essential, of course.
>
> Can someone remind me why citeproc-java isn’t good?  AFAIR, it has a
> bibtex parser.  But probably it lacks in some other dimension...
>
>> OT3rdH, responding to Matt’s message
>> ,
>>
>>> The disadvantage is that, from what I can tell, the javascript
>>> implementation is the canonical version of citeproc, and the place where
>>> improvements are pushed first.  So, for instance, if one wanted to
>>> implement an org-syntax output format for citeproc, citeproc-js would be
>>> the most likely project to support that work.
>>
>> Pandoc can output org syntax, so it may be that we can just link with
>> the main pandoc haskell library as well as pandoc-citeproc and solve
>> this ourselves, without needing upstream support.
>
> Do we WANT to depend on Pandoc?  I would say "no".  In my OS, where we
> finally got a binary distribution of pandoc, the size of pandoc is still
> 1600Mb!  I don’t know if this is representative of other systems, though.
> E.g. what is the size of pandoc+deps in Debian?

I don't know which OS you are using, but just checking on
[[https://github.com/jgm/pandoc/releases/1.15.1]]  and 
[[https://github.com/jgm/pandoc/releases/tag/1.15.1.1]]:

Windows: 19.7 MB
Mac: 27.9 MB
Deb: 20.2 MB

The 1600MB must be including LaTeX?

In General, I like the idea of using the Pandoc approach, as Pandoc
provides a very useful framework for all kinds of conversions (and I
don't like java...)

Nevertheless, I would be happy with whatever is used to implement
proper citation support.

Cheers,

Rainer

>
> Rasmus

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax :   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

PGP: 0x0F52F982


signature.asc
Description: PGP signature

Re: [O] Some projects

[Aaron Ecay]

Hi Rasmus,

2015ko urriak 27an, Rasmus-ek idatzi zuen:

[...]

> 
> Can someone remind me why citeproc-java isn’t good?  AFAIR, it has a
> bibtex parser.  But probably it lacks in some other dimension...

You have to write java to use it, which is a big negative (at least for
me).  Last time I think we concluded that the CLI interface it exposes
is not adequate (though I actually started off trying to use it).

There’s also the issue that it is just a bundling of citeproc-js with
some java libraries (js interpreter, bibtex processor, ...), so someone
who tries to extend it actually has to know both java and js.

> Do we WANT to depend on Pandoc?  I would say "no".  In my OS, where we
> finally got a binary distribution of pandoc, the size of pandoc is still
> 1600Mb!  I don’t know if this is representative of other systems, though.
> E.g. what is the size of pandoc+deps in Debian?

It’s unfortunate, but pandoc has the most easily adaptable CSL
implementation for our use case, as far as I can see.  The other
contender is Zotero (in JS, possibly with XUL-specific bits).  It would
be good if somebody looked at what it would take for us to use Zotero’s
implementation, just as Richard did for Pandoc.

-- 
Aaron Ecay

Re: [O] Some projects

[Rasmus]

Aaron Ecay  writes:

> Hi Richard, hi all,
>
> 2015ko urriak 26an, Richard Lawrence-ek idatzi zuen:
>> 
>
> [...]
>
>>> I was working on this rather intensively at one time, but I had to stop
>>> because other aspects of life intruded.  I have just been coming back
>>> towards a situation where I can imagine myself having some (still small,
>>> but non-zero) chunks of time to devote to working on org.  So I hope I
>>> will be able to pick this back up, but (regrettably) I’m not able to
>>> make any promises.
>>> 
>>> Based on my recollection, here’s what the problems were when I stopped:
>>> 
>>> - The only “off the shelf”-capable citation processing library that we
>>> found last time is in Haskell, which introduced some difficulties for
>>> distributing the resulting tool.  I know some projects
>>> (e.g. git-annex) are written in Haskell and distributed as static
>>> binaries for windows/mac/linux/etc.  We’d need to figure out how to do
>>> this, or find another citation processing library in an
>>> easier-to-distribute language.
>> 
>> Yes, this is my understanding, too.  In particular, there does not seem
>> to be an Elisp CSL library, and it would be a lot of work to write one.
>> 
>> The other CSL library that looks complete and usable is citeproc-js; but
>> like the Haskell library (pandoc-citeproc) it would need to be wrapped
>> somehow so that it can talk with Org.
>> 
>> It should be relatively straightforward for someone who knows Javascript
>> to write such a wrapper, if anyone wants to work on that.  But this does
>> not really solve the problem with distribution.  
>
> It solves many of the hard problems though.  Node.js is distributed
> as a binary for many platforms.  We’d just have to direct users to
> install this in the “normal way,” and use the installed binary to
> interpret the JS source.  Whereas for haskell we’d be stuck building
> the binary ourselves, worrying about static linking/dll hell/32-bit
> dinosaurs/any of a half-dozen other problems that I don’t really
> understand.

I would feel more comfortable relying on a JS library.  Perhaps it’s also
easier to find people who are willing to work on/knows JS over the long
haul...

> OTOH, pandoc-citeproc includes a bibtex parser; we’d need to write a JS
> one and wire it up to citeproc-js.  When I looked (quite some time ago),
> there did not seem to be any good bibtex parsing libraries in JS (and
> several third-rate ones).

Bibtex support is essential, of course.

Can someone remind me why citeproc-java isn’t good?  AFAIR, it has a
bibtex parser.  But probably it lacks in some other dimension...

> OT3rdH, responding to Matt’s message
> ,
>
>> The disadvantage is that, from what I can tell, the javascript
>> implementation is the canonical version of citeproc, and the place where
>> improvements are pushed first.  So, for instance, if one wanted to
>> implement an org-syntax output format for citeproc, citeproc-js would be
>> the most likely project to support that work.
>
> Pandoc can output org syntax, so it may be that we can just link with
> the main pandoc haskell library as well as pandoc-citeproc and solve
> this ourselves, without needing upstream support.

Do we WANT to depend on Pandoc?  I would say "no".  In my OS, where we
finally got a binary distribution of pandoc, the size of pandoc is still
1600Mb!  I don’t know if this is representative of other systems, though.
E.g. what is the size of pandoc+deps in Debian?

Rasmus

-- 
Lasciate ogni speranza o voi che entrate: siete nella mani di'machellaio

Re: [O] Some projects

[Aaron Ecay]

Hi Richard, hi all,

2015ko urriak 26an, Richard Lawrence-ek idatzi zuen:
> 

[...]

>> I was working on this rather intensively at one time, but I had to stop
>> because other aspects of life intruded.  I have just been coming back
>> towards a situation where I can imagine myself having some (still small,
>> but non-zero) chunks of time to devote to working on org.  So I hope I
>> will be able to pick this back up, but (regrettably) I’m not able to
>> make any promises.
>> 
>> Based on my recollection, here’s what the problems were when I stopped:
>> 
>> - The only “off the shelf”-capable citation processing library that we
>> found last time is in Haskell, which introduced some difficulties for
>> distributing the resulting tool.  I know some projects
>> (e.g. git-annex) are written in Haskell and distributed as static
>> binaries for windows/mac/linux/etc.  We’d need to figure out how to do
>> this, or find another citation processing library in an
>> easier-to-distribute language.
> 
> Yes, this is my understanding, too.  In particular, there does not seem
> to be an Elisp CSL library, and it would be a lot of work to write one.
> 
> The other CSL library that looks complete and usable is citeproc-js; but
> like the Haskell library (pandoc-citeproc) it would need to be wrapped
> somehow so that it can talk with Org.
> 
> It should be relatively straightforward for someone who knows Javascript
> to write such a wrapper, if anyone wants to work on that.  But this does
> not really solve the problem with distribution.  

It solves many of the hard problems though.  Node.js is distributed
as a binary for many platforms.  We’d just have to direct users to
install this in the “normal way,” and use the installed binary to
interpret the JS source.  Whereas for haskell we’d be stuck building
the binary ourselves, worrying about static linking/dll hell/32-bit
dinosaurs/any of a half-dozen other problems that I don’t really
understand.

OTOH, pandoc-citeproc includes a bibtex parser; we’d need to write a JS
one and wire it up to citeproc-js.  When I looked (quite some time ago),
there did not seem to be any good bibtex parsing libraries in JS (and
several third-rate ones).

OT3rdH, responding to Matt’s message
,

> The disadvantage is that, from what I can tell, the javascript
> implementation is the canonical version of citeproc, and the place where
> improvements are pushed first.  So, for instance, if one wanted to
> implement an org-syntax output format for citeproc, citeproc-js would be
> the most likely project to support that work.

Pandoc can output org syntax, so it may be that we can just link with
the main pandoc haskell library as well as pandoc-citeproc and solve
this ourselves, without needing upstream support.

-- 
Aaron Ecay

Re: [O] Some projects

[Nicolas Goaziou]

Eric Abrahamsen  writes:

> I've tried more than once over the past couple of years to attack
> orgstruct mode, and been defeated every time. Largely because
> indentation/filling is so damn complicated (too many layers of
> indirection for my little brain), and orgstruct added yet another layer
> of indirection on top of that. I think a rewrite would not be a bad
> thing, and would be happy to participate.

Basically, OrgStruct is Org with a very limited syntax, i.e., it only
recognizes headlines and lists. OrgStruct++ adds indentation and
filling.

I think OrgStruct may be redefined as an outline minor mode with Org
bindings. This is very different from Org. Even indentation and filling
should be new functions since Org's recognizes context that doesn't make
sense in OrgStruct.

> The one thing I like about the package (indeed, it's what the bulk of
> the code actually does) is the ability to "pop up" a single annotation's
> text in a small, easily-dismissed special-mode buffer. Also, to display
> all of a buffer's annotations in a tabulated-list pop-up buffer, where
> you can easily jump to/edit/delete the various annotations.
>
> Obviously Org footnotes (and future annotations) have jump there/jump
> back capability, but for some reason I feel much more comfortable with
> this style of browsing.

Have you tried C-c ' one a footnote reference? Unlike to C-c C-o, it
will pop-up a dedicated buffer for editing.

However, there is no global view of all footnotes. If it is useful, it
might be nice to add one and trigger it from, e.g., to
`org-footnote-action's menu.

> These new features aside, is there any need to do any fundamental
> refactoring? I mostly mean altering existing Org libraries to use the
> element framework, stuff like that...

Of course. Refactoring (e.g., replacing `setq' with `let'), adding code
comments, tests, using Element where applicable is always good. 

Regards,

Re: [O] subject tree listing from publish

[Greg O'Keefe]

Thanks Christian,

I am currently using index to create the closest thing I can to what I
want.  It looks like the below.  The big problem is that there are a max of
3 levels, the top level which is the first character of the second.

Could I do any better than this without writing something new?

Greg

C
computing-methodologies
adversarial plan recognition

D
document-management-and-text-processing
 bibliographies using org-mode

On Thu, Oct 22, 2015 at 9:40 PM, Christian Moe 
wrote:

>
> For a listing by a hierarchy of subject, I think the index system does
> what you want and is the only approach that does what you want out of
> the box. But if I understand correctly, you already have an index, and
> want this to be a separate listing?
>
> Yours,
> Christian
>
>
> Greg O'Keefe writes:
>
> > Hi,
> >
> > I keep a directory of notes as .org files, and use publish to generate
> > .html from them.  This produces sitemap.html - a table of the #+TITLEs,
> and
> > theindex.html built from #+INDEX entries I have added.
> >
> > I would like a third summary .html page which lists the notes organised
> in
> > a tree by subject classification, where the subject classification is
> > something like the ACM Computing Subject Classification or the Dewey
> > Decimal system, or some cut-down version of these.
> >
> > The result would look a bit like this, where the _underlined_ items are
> > links to notes.
> >
> > Information Technology
> > Software and its Engineering
> > Modelling Languages
> > _Dynamic Logic for UML Sequence Diagrams_
> > Computing Methodologies
> > Knowledge Representation
> > _Translating ACL to FOL_
> >
> > Reading the  manual, it looks like I could use TAGS to give the notes
> > subjects, and use these to do searches over the whole project in emacs.
> > This, and the way theindex.html is produced by including a simple looking
> > theindex.inc text file makes me think that the solution may not be very
> > hard. However, my lisp is very weak :-(
> >
> > Any suggestions or code most welcome!
> >
> > Cheers,
> >
> > Greg
>
>