Re: [O] [babel] return file from R

2016-01-19 Thread Andreas Leha
Hi Chuck,

"Charles C. Berry"  writes:
> On Tue, 19 Jan 2016, Andreas Leha wrote:
>
>> Hi Chuck,
>>
>
> [snip]
>
>> I've tested your patch and it seems to work.  But it does seem to need
>> an analogous change in org-babel-R-evaluate-session to also cure blocks
>> with ':session'.
>>
>
> Correct. I committed a patch like this and added a test
>

Thanks!

Andreas




Re: [O] [babel] return file from R

2016-01-19 Thread Charles C. Berry

On Tue, 19 Jan 2016, Andreas Leha wrote:


Hi Chuck,



[snip]


I've tested your patch and it seems to work.  But it does seem to need
an analogous change in org-babel-R-evaluate-session to also cure blocks
with ':session'.



Correct. I committed a patch like this and added a test

Thanks,

Chuck




Re: [O] Exporting Source Blocks with Symbols

2016-01-19 Thread Grant Rettke
Thank you for sharing your solution.

My current solution: avoid the issue entirely and don't use Unicode in
your source code, use pretty-mode instead:
https://github.com/akatov/pretty-mode

A future option: switch from PDFLaTeX to XeLaTeX of LuaLaTeX.

Both are great. The latter is ideal, and does the "right thing" for
just about every language out there and if it doesn't, it is added
quickly.
Sincerely,

Grant Rettke


On Sun, Jan 17, 2016 at 2:10 PM, Michael Gauland  wrote:
> Just following up with my solution, in case anyone else is interested
> (thanks to John Kitchin for pointing me in the right direction). First, I
> should note that 'µ' exported correctly because I was using the unicode
> element 'MICRO SYMBOL' instead of 'GREEK SMALL LETTER MU' (which looks the
> same, but doesn't export).
>
> The 'listings' package can only handle 8-bit characters, but you can tell it
> to escape to LaTeX. The code block below adds a hook to escape the
> characters I'm interested in, and adds the listing option to identify the
> escape character (a symbol I've never used for anything else).
>
> This code could certainly be improved, but it serves my needs, and may be
> useful as a starting point for anyone trying to do something similar.
> --Michael Gauland
>
> #+BEGIN_SRC emacs-lisp :session :results value silent :exports none
> ;; Set up a filter to preserve greek symbols in code blocks
> (setq org-export-filter-src-block-functions
>   (list
> (lambda (text backend info)
>(replace-regexp-in-string "\\([σβ]\\)" "§$\\1$§" text
>
> (setq org-latex-listings-options '(("escapechar" "§")))
> #+END_SRC
>



[O] How to install CDLaTeX in emacs24, on Windows 7?

2016-01-19 Thread vendo.li...@libero.it
Hello, I'm having trouble understanding in which directory to download the 
cdlatex.el script that Mr. Dominik wrote. I'm on Windows 7, emacs 24, my AUCTEX 
version is 11.88 and I also have Org-mode 8.2 and yasnippet installed.
When I give the command M-x org-cdlatex-mode, Emacs responds "Cannot open load 
file: no such file or directory, cdlatex". I've also tried adding the following 
lines into my .emacs file but to no avail.
(autoload 'org-cdlatex-mode "cdlatex.el" "Enter org-cdlatex mode" 
t)(add-hook 'org-mode-hook 'turn-on-org-cdlatex)
I'm not the only person experiencing this odd behavior, infact please check 
this stackexchange thread: 
http://emacs.stackexchange.com/questions/19614/org-cdlatex-doesnt-work.
Can someone please confirm that yasnippet and org-cdlatex-mode are not 
incompatible?Do I need to download the script from ELPA as I did with other 
packages? I cannot find this script in the list of packages that come up if I 
type M-x list-packages. How can I fix this problem, I really would like to use 
org-cdlatex-mode under Org-mode. Thanks in advance!

Re: [O] FSF copyright assignment

2016-01-19 Thread Christopher Allan Webber
Rasmus writes:

> Arun Isaac  writes:
>
>> How long does FSF copyright assignment typically take? I sent a request
>> around 2 weeks ago (on December 26), but haven't received a reply yet.
>>
>> Does it usually take this long? Should I resend my copyright
>> assignment request?
>
> Are you talking about a physical letter or an email requesting to get the
> form?  If the latter, I think you can ping them again.  Though, it was
> just holiday, so they might have a backtrack.
>
> Rasmus

I believe there is now also a GPG based signature option available in
many cases for copyright assignment.  It may be worth asking about.



Re: [O] Tables: remote reference fails with umlaut (and in other cases)

2016-01-19 Thread Stefan Huchler
Nick Dokos  writes:

> Eric S Fraga  writes:
>
> You are missing a quote:
>
> #+TBLFM: $1='(identity remote(2016-01-19-srctbl,@@#$1))
>
> works for me.
>
> Org-mode version 8.3.3 (release_8.3.3-456-g164555)
>
> --
> Nick



Wow,

that was an eye opener for me, first it lets me use/refer to german
umlauts, second I can use by this method full power of elisp on the
data:

#+TBLFM: $3='(nth 1 (split-string remote(addresstable, @@#$6) "@"))

extracts the hostname from a mail adress f...@bar.com -> bar.com.

it maybe makes even some kind of table data joining possible, failed
there on a tea-shopping database I tried to do in the past.

so thanks.




[O] Bug: org-resolve-clocks should not iterate over non-agenda org files [8.3.3 (8.3.3-elpaplus @ /home/dfeich/.emacs.d/elpa/org-plus-contrib-20160108/)

2016-01-19 Thread Derek Feichtinger
Hi

org-resolve-clock loops over all open org buffers for detecting open
clocks (using function org-files-list). Is this really intended? I think
it should just loop over the org-agenda-files.

I was working on an extension for clocking and was recording my testing
results
into a separate org file. I also had put there examples of
various clock lines to test regexps against. The example clock lines
effectively prevented me from clocking in to a task from my normal
agenda files.

Since org has so many usages, I think it should not be assumed that each
org buffer is related to the agenda functionality.

Best regards,
Derek


Re: [O] bug#22399: org-mode fontification

2016-01-19 Thread Rasmus
Hi Kyle,

Kyle Meyer  writes:

>> I just have one concern, which is pretty theoretical.  Isn’t it bad to
>> define the alias to be font-lock-ensure since this is an existing function
>> and people would have clear expectations of what they are calling?  I
>> realize that there’s no Emacs-25 that will not have this function (which
>> is why it’s very theoretical).
>
> I agree, but, like you, I'm not sure it will matter in practice.  Again,
> this was the solution that was already in Org's repo at the time I
> backported Emacs's 6711a21f1.  However, it's easy enough to switch to
> using an org-font-lock-ensure variant that avoids these issues, so I
> will do that (in an updated patch and on Org's maint).

Thanks.

Kyle Meyer  writes:

>> However, it's easy enough to switch to using an org-font-lock-ensure
>> variant that avoids these issues, so I will do that (in an updated
>> patch and on Org's maint).
>
> I've attached updated patches against emacs-25.  If these are applied to
> the Emacs repo, I'll backport the new font-lock-ensure alias to Org's
> maint.

Looks good, thanks.

Rasmus

-- 
Er du tosset for noge' lårt!




Re: [O] Tables: remote reference fails with umlaut (and in other cases)

2016-01-19 Thread Michael Brand
Hi Karl

On Tue, Jan 19, 2016 at 4:29 PM, Karl Voit  wrote:

> I never understood the @@#-syntax anyway. On [1] I referenced to [2].

Please see the Org manual for @# and $#. Thus @@#$1 is substituted
with @1$1, @2$1, @3$1 etc. depending on the row it is evaluated on.
@1$$# becomes @1$1, @1$2 etc.

> [1] 
> https://github.com/novoid/org-mode-workshop/blob/master/featureshow/org-mode-teaser.org#1131-referencing-example-with-detailed-explanation

Do you remember that some time ago I reminded you about a patch that I
had sent you privately to align your above URL with the change about how
to copy fields in the Org manual?

Michael



[O] bug#22399: org-mode fontification

2016-01-19 Thread Kyle Meyer
Kyle Meyer  writes:

[...]

> However, it's easy enough to switch to using an org-font-lock-ensure
> variant that avoids these issues, so I will do that (in an updated
> patch and on Org's maint).

I've attached updated patches against emacs-25.  If these are applied to
the Emacs repo, I'll backport the new font-lock-ensure alias to Org's
maint.

>From d9a8014e3919c328bf2b6acbe9d9127f3b06b5e1 Mon Sep 17 00:00:00 2001
From: Kyle Meyer 
Date: Tue, 19 Jan 2016 12:53:04 -0500
Subject: [PATCH 1/2] org-compat: Fix font-lock-ensure alias

* lisp/org/org-compat.el (org-font-lock-ensure): Fix check for
font-lock-ensure.  Make compatibility function's arguments optional to
match with font-lock-ensure's.  (Bug#22399)
---
 lisp/org/org-compat.el | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lisp/org/org-compat.el b/lisp/org/org-compat.el
index 6403d4d..cf6aafc 100644
--- a/lisp/org/org-compat.el
+++ b/lisp/org/org-compat.el
@@ -479,9 +479,9 @@ org-no-popups
   (not (null pos)
 
 (defalias 'org-font-lock-ensure
-  (if (fboundp 'org-font-lock-ensure)
+  (if (fboundp 'font-lock-ensure)
   #'font-lock-ensure
-(lambda (_beg _end) (font-lock-fontify-buffer
+(lambda (&optional _beg _end) (font-lock-fontify-buffer
 
 (defun org-floor* (x &optional y)
   "Return a list of the floor of X and the fractional part of X.
-- 
2.7.0

>From 7b2e8cd23ee5326ca2b0845bed8a5d111a2a3b17 Mon Sep 17 00:00:00 2001
From: Kyle Meyer 
Date: Tue, 19 Jan 2016 12:53:22 -0500
Subject: [PATCH 2/2] org-src: Use font-lock-fontify-buffer for blocks

* lisp/org/org-src.el (org-src-font-lock-fontify-block): Use
font-lock-fontify-buffer because font-lock-ensure does not display
source block fonts.

This corresponds to 003a0f10695f035e844d844eacb1a86a6d2df934 in the Org
repo.
---
 lisp/org/org-src.el | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/lisp/org/org-src.el b/lisp/org/org-src.el
index 8e06aaa..5548f52 100644
--- a/lisp/org/org-src.el
+++ b/lisp/org/org-src.el
@@ -916,7 +916,9 @@ org-src-font-lock-fontify-block
 	(delete-region (point-min) (point-max))
 	(insert string " ") ;; so there's a final property change
 	(unless (eq major-mode lang-mode) (funcall lang-mode))
-(org-font-lock-ensure)
+	;; Avoid `font-lock-ensure', which does not display fonts in
+	;; source block.
+	(font-lock-fontify-buffer)
 	(setq pos (point-min))
 	(while (setq next (next-single-property-change pos 'face))
 	  (put-text-property
-- 
2.7.0


--
Kyle


Re: [O] Tables: remote reference fails with umlaut (and in other cases)

2016-01-19 Thread Nick Dokos
Eric S Fraga  writes:

> On Tuesday, 19 Jan 2016 at 14:10, Karl Voit wrote:
>> Hi!
>>
>> Either I found a bug when referring to other table rows or I don't
>> understand the behavior of following example tables. My expectation
>> was that the first column of the second table is exactly the same as
>> the first column of the first table:
>>
>> #+NAME: 2016-01-19-srctbl
>> | Testdata |
>>
>> |--|
>> | foobar   |
>> | fooübar  |
>> | fooßbar  |
>> | 1er  |
>> | 23,42|
>> | 23.42|
>>
>> | Result   | Expected Result | Comparison |
>> |--+-+|
>> | foobar   | foobar  | OK |
>> | #ERROR   | fooübar | fail   |
>> | #ERROR   | fooßbar | fail   |
>> | er   | 1er | fail   |
>> | 23.42| 23.42   | OK |
>> | (23, 42) | 23,42   | probably fail? |
>>
>> #+TBLFM: $1=remote(2016-01-19-srctbl,@@#$1)
>>
>> Thanks for clearing things up!
>
> I cannot get this to work either but I do think you want to enclose the
> remote() within (identity) to copy values and not try to evaluate an
> expression, as noted in the info page:
>
> $1=(identity remote(2016-01-19-srctbl,@@#$1))
>
> Also, I don't think you want an indirection using #.
>
> But I cannot get this to work so I could be completely off base...

You are missing a quote:

#+TBLFM: $1='(identity remote(2016-01-19-srctbl,@@#$1))

works for me.

Org-mode version 8.3.3 (release_8.3.3-456-g164555)

--
Nick




Re: [O] Tables: remote reference fails with umlaut (and in other cases)

2016-01-19 Thread Stefan Huchler
Karl Voit  writes:

> #+NAME: 2016-01-19-srctbl
> | Testdata |
> |--|
> | foobar   |
> | fooübar  |
> | fooßbar  |
> | 1er  |
> | 23,42|
> | 23.42|
>
> | Result   | Expected Result | Comparison |
> |--+-+|
> | foobar   | foobar  | OK |
> | #ERROR   | fooübar | fail   |
> | #ERROR   | fooßbar | fail   |
> | er   | 1er | fail   |
> | 23.42| 23.42   | OK |
> | (23, 42) | 23,42   | probably fail? |
> #+TBLFM: $1=remote(2016-01-19-srctbl,@@#$1)

Yes I have that problem, too. the last number is strange. I had the
problem that I used 45.000 as the german seperator for thousends and it
interpreted it as dezimal english "." so you have to put the string into
"" to mark it as string the result sadly still has the "" around it but
it makes kind of sense. the german umlauts just fail/error here too.

would happy to have here a solution sadly org tables fail for me for
most tasks because it only works useful good with calculations and
numbers, if you dont learn R and maybe use there some magic.

Sorry dont want to be negative but run against many walls and got not
very satisfactory answers to it, most of the time something like WONTFIX
or ITSNOTABUGITSAFEATURE as answer.




[O] Bug: [bisected] note from clocking out is above :LOGBOOK: drawer [8.3.3 (release_8.3.3-469-g2e7716 @ /home/grfz/src/org-mode/lisp/)]

2016-01-19 Thread Gregor Zattler

Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.  You don't know how to make a good report?  See

 http://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org-mode mailing list.


Notes produced when clocking out with org-log-note-clock-out set
will be placed above the clock line instead below the clock line.
In my heavily customized sessions the notes show up on the
previos line respective to the clock line.  Without
customizations (see below) they end up above the :LOGBOOK:
drawer.

ECM:
emacs24 -Q -nw -L /home/grfz/src/org-mode/lisp/ --eval "(require 'org)"  --eval 
'(setq org-log-note-clock-out t)' /tmp/test.org

now add a heading, clock in, clock out, write something as a note,
do C-c C-c to finish note taking.  Result:

* heading
  - note
  :LOGBOOK:
  CLOCK: [2016-01-19 Di 16:22]--[2016-01-19 Di 16:22] =>  0:00
  :END:



This is with
Package: Org-mode version 8.3.3 (release_8.3.3-469-g2e7716 @ 
/home/grfz/src/org-mode/lisp/)

Emacs version doesn't matter (tested with
- GNU Emacs 24.5.1 (x86_64-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 
2015-10-24 on trouble, modified by Debian
and
- Emacs  : GNU Emacs 25.0.50.15 (x86_64-pc-linux-gnu, GTK+ Version 3.18.6) of 
2016-01-19


I git bisected this:

8ddc7314b801b48dff5c246c0954c67021b145f9 is the first bad commit
commit 8ddc7314b801b48dff5c246c0954c67021b145f9
Author: Nicolas Goaziou 
Date:   Tue Jan 12 21:28:32 2016 +0100

Store notes outside drawers at a correct location

* lisp/org.el (org-log-beginning): Move to an appropriate location even
when `org-log-state-notes-insert-after-drawers' is nil and notes are
not stored within a drawer.

Reported-by: swfl...@flintfam.org (Samuel W. Flint)


:04 04 82c4d500315fa5ea5e4e1968e633bfac078f2e6a 
a4fee4c6e2e140cbba8b3fb16513b269b1f9cfe0 M  lisp


Thanks for your attention, Gregor



Re: [O] bug#22399: org-mode fontification

2016-01-19 Thread Kyle Meyer
Rasmus  writes:

> Kyle Meyer  writes:

[...]

>> The first patch replaces the font-lock-ensure compatibility alias from
>> 6711a21f1 with the one currently used in the Org repo (from commit
>> e6883dd03).  The new alias is limited to being called with no
>> arguments, but, at the moment, no Org code calls font-lock-ensure with
>> any arguments.
>
> I just have one concern, which is pretty theoretical.  Isn’t it bad to
> define the alias to be font-lock-ensure since this is an existing function
> and people would have clear expectations of what they are calling?  I
> realize that there’s no Emacs-25 that will not have this function (which
> is why it’s very theoretical).

I agree, but, like you, I'm not sure it will matter in practice.  Again,
this was the solution that was already in Org's repo at the time I
backported Emacs's 6711a21f1.  However, it's easy enough to switch to
using an org-font-lock-ensure variant that avoids these issues, so I
will do that (in an updated patch and on Org's maint).

--
Kyle



Re: [O] Tables: remote reference fails with umlaut (and in other cases)

2016-01-19 Thread Karl Voit
Hi Eric,

* Eric S Fraga  wrote:
> On Tuesday, 19 Jan 2016 at 14:10, Karl Voit wrote:
>>
>> #+NAME: 2016-01-19-srctbl
>> | Testdata |
>> |--|
>> | foobar   |
>> | fooübar  |
>> | fooßbar  |
>> | 1er  |
>> | 23,42|
>> | 23.42|
>>
>> | Result   | Expected Result | Comparison |
>> |--+-+|
>> | foobar   | foobar  | OK |
>> | #ERROR   | fooübar | fail   |
>> | #ERROR   | fooßbar | fail   |
>> | er   | 1er | fail   |
>> | 23.42| 23.42   | OK |
>> | (23, 42) | 23,42   | probably fail? |
>>
>> #+TBLFM: $1=remote(2016-01-19-srctbl,@@#$1)
>
> I cannot get this to work either but I do think you want to enclose the
> remote() within (identity) to copy values and not try to evaluate an
> expression, as noted in the info page:
>
> $1=(identity remote(2016-01-19-srctbl,@@#$1))

| Result   | Expected Result |
|--+-|
| identity(foobar) | foobar  |
| #ERROR   | fooübar |
| #ERROR   | fooßbar |
| identity(er) | 1er |
| identity(23, 42) | 23.42   |
| identity(23.42)  | 23,42   |
#+TBLFM: $1=(identity remote(2016-01-19-srctbl,@@#$1))

> Also, I don't think you want an indirection using #.

I never understood the @@#-syntax anyway. On [1] I referenced to [2].

> But I cannot get this to work so I could be completely off base...

Interesting. I thought I am using only standard Org functionality here.

I'm using the most current Git maint version, btw.

[1] 
https://github.com/novoid/org-mode-workshop/blob/master/featureshow/org-mode-teaser.org#1131-referencing-example-with-detailed-explanation
[2] http://orgmode.org/worg/org-hacks.html#field-coordinates-in-formulas

-- 
mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode:
   > get Memacs from https://github.com/novoid/Memacs <

https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github




Re: [O] [babel] return file from R

2016-01-19 Thread Andreas Leha
Hi Chuck,

Thanks for following that up.  And sorry for the long delay.


"Charles C. Berry"  writes:
> On Thu, 17 Dec 2015, Andreas Leha wrote:
>
>> Hi all,
>>
>> I think there is a bug in the handling of results of R src blocks.  What
>> is the suggested way to make an R block return a link to a file?  The
>> obvious way appends a newline character to the file link (which is
>> broken because of that).
>>
>> Here is an example:
>> --8<---cut here---start->8---
>> #+NAME: TESTSRC
>> #+BEGIN_SRC R :results file
>>  a <- file.path("junk", "test.org")
>>  a
>> #+END_SRC
>>
>> #+RESULTS: TESTSRC
>> [[file:junk/test.org
>> ]]
>>
>> --8<---cut here---end--->8---
>
>
> That *is* the suggested way, and it will work in (say) emacs-lisp. The
> problem for `:results value' (the default) is that a newline is added
> to the result by `org-babel-R-evaluate-external-process'.
>
> This *might* be the fix, but I do not have time to check it thoroughly:
>
> diff --git a/lisp/ob-R.el b/lisp/ob-R.el
> index f72cd95..f660bbd 100644
> --- a/lisp/ob-R.el
> +++ b/lisp/ob-R.el
> @@ -397,7 +397,7 @@ last statement in BODY, as elisp."
>   (org-babel-result-cond result-params
> (with-temp-buffer
>   (insert-file-contents tmp-file)
> - (buffer-string))
> + (org-babel-chomp (buffer-string) "\n"))
> (org-babel-import-elisp-from-file tmp-file '(16)))
>   column-names-p)))
>  (output (org-babel-eval org-babel-R-command body
>
>
> In the meanwhile, you can work around by using `:results output' and
> wrapping the result in cat().
>

Using the ':results output' work around won't work on most of my code
blocks as these are typically longer and more verbose.  So, that really
is just a work-around.

I've tested your patch and it seems to work.  But it does seem to need
an analogous change in org-babel-R-evaluate-session to also cure blocks
with ':session'.

--8<---cut here---start->8---
diff --git a/lisp/ob-R.el b/lisp/ob-R.el
index f72cd95..193548e 100644
--- a/lisp/ob-R.el
+++ b/lisp/ob-R.el
@@ -397,7 +397,7 @@ last statement in BODY, as elisp."
(org-babel-result-cond result-params
  (with-temp-buffer
(insert-file-contents tmp-file)
-   (buffer-string))
+   (org-babel-chomp (buffer-string) "\n"))
  (org-babel-import-elisp-from-file tmp-file '(16)))
column-names-p)))
 (output (org-babel-eval org-babel-R-command body
@@ -431,7 +431,7 @@ last statement in BODY, as elisp."
(org-babel-result-cond result-params
  (with-temp-buffer
(insert-file-contents tmp-file)
-   (buffer-string))
+   (org-babel-chomp (buffer-string) "\n"))
  (org-babel-import-elisp-from-file tmp-file '(16)))
column-names-p)))
 (output
--8<---cut here---end--->8---


Regards,
Andreas




Re: [O] Tables: remote reference fails with umlaut (and in other cases)

2016-01-19 Thread Eric S Fraga
On Tuesday, 19 Jan 2016 at 14:10, Karl Voit wrote:
> Hi!
>
> Either I found a bug when referring to other table rows or I don't
> understand the behavior of following example tables. My expectation
> was that the first column of the second table is exactly the same as
> the first column of the first table:
>
> #+NAME: 2016-01-19-srctbl
> | Testdata |
>
> |--|
> | foobar   |
> | fooübar  |
> | fooßbar  |
> | 1er  |
> | 23,42|
> | 23.42|
>
> | Result   | Expected Result | Comparison |
> |--+-+|
> | foobar   | foobar  | OK |
> | #ERROR   | fooübar | fail   |
> | #ERROR   | fooßbar | fail   |
> | er   | 1er | fail   |
> | 23.42| 23.42   | OK |
> | (23, 42) | 23,42   | probably fail? |
>
> #+TBLFM: $1=remote(2016-01-19-srctbl,@@#$1)
>
> Thanks for clearing things up!

I cannot get this to work either but I do think you want to enclose the
remote() within (identity) to copy values and not try to evaluate an
expression, as noted in the info page:

$1=(identity remote(2016-01-19-srctbl,@@#$1))

Also, I don't think you want an indirection using #.

But I cannot get this to work so I could be completely off base...
-- 
: Eric S Fraga (0xFFFCF67D), Emacs 24.5.1, Org release_8.3.3-449-gd85ff3



[O] Tables: remote reference fails with umlaut (and in other cases)

2016-01-19 Thread Karl Voit
Hi!

Either I found a bug when referring to other table rows or I don't
understand the behavior of following example tables. My expectation
was that the first column of the second table is exactly the same as
the first column of the first table:

#+NAME: 2016-01-19-srctbl
| Testdata |
|--|
| foobar   |
| fooübar  |
| fooßbar  |
| 1er  |
| 23,42|
| 23.42|

| Result   | Expected Result | Comparison |
|--+-+|
| foobar   | foobar  | OK |
| #ERROR   | fooübar | fail   |
| #ERROR   | fooßbar | fail   |
| er   | 1er | fail   |
| 23.42| 23.42   | OK |
| (23, 42) | 23,42   | probably fail? |
#+TBLFM: $1=remote(2016-01-19-srctbl,@@#$1)

Thanks for clearing things up!

-- 
mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode:
   > get Memacs from https://github.com/novoid/Memacs <

https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github




Re: [O] bug#22399: org-mode fontification

2016-01-19 Thread Phillip Lord
Kyle Meyer  writes:

> Kyle Meyer  writes:
>> Rasmus  writes:
>>
>> [...]
>>
>>> Note, this change only lives it the Emacs version of Org.  It was added in
>>> this commit:
>>>
>>>6711a21f1125c0047c56eb266eb374c1ec90a967
>
> [...]
>
>>
>> This commit was backported in Org commit d81e6b5, and then followed up
>> by c115c7b (org-compat: Use different font-lock-ensure alias,
>> 2015-07-26), which defined the alias as
>>
>> (unless (fboundp 'font-lock-ensure)
>>   (defalias 'font-lock-ensure 'font-lock-fontify-buffer))
>
> I've attached two patches against emacs-25 that would get the Org and
> Emacs repos in similar states wrt font-lock-ensure.
>
> The first patch replaces the font-lock-ensure compatibility alias from
> 6711a21f1 with the one currently used in the Org repo (from commit
> e6883dd03).  The new alias is limited to being called with no
> arguments, but, at the moment, no Org code calls font-lock-ensure with
> any arguments.
>
> The second patch reverts a part of 6711a21f1 that modified
> org-src-font-lock-fontify-block to use font-lock-ensure rather than
> font-lock-fontify-buffer.  In this particular case, using
> font-lock-ensure instead of font-lock-fontify-buffer fails to
> highlight the source block.


I've tested these on emacs-25 and can confirm that they solve the
problem.

Thanks!

Phil



[O] Port ob-lisp.el to use SLY as an option to evaluate.

2016-01-19 Thread numbch...@gmail.com
I found ob-lisp.el use SLIME by default to evaluate lisp code. I want to
use SLY to evaluate lisp code. How to change it? I found the file ob-lisp.el
is short. I tried to change slime to sly.

But it is not customizable. I hope to define a defcustom for it. So that
user can customize it. But I don't know how to apply this into code. For
example, I define a custom like this:

```

(defcustom org-babel-lisp-default-implement "slime")
((defcustom org-babel-lisp-implements
   '("slime" "sly")
   "A list of Lisp implements."
   :group 'org-babel
   :version "24.1"
   ;; FIXME: reference code example.
   :type listp))
```


Then in file ob-lisp.el. Has some places use slime. I want to make
them adapt to upper defcustom value. like concate string from value or
something else.

```
(declare-function slime-eval "ext:slime" (sexp &optional package))
(defun org-babel-execute:lisp (body params)
  "Execute a block of Common Lisp code with Babel."
  (require 'slime)
  (org-babel-reassemble-table
   (let ((result
  (funcall (if (member "output" (cdr (assoc :result-params params)))
   #'car #'cadr)
   (with-temp-buffer
 (insert (org-babel-expand-body:lisp body params))
 (slime-eval `(swank:eval-and-grab-output
```



[stardiviner] GPG key ID: 47C32433
IRC(freeenode): stardiviner Twitter:  @numbchild
Key fingerprint = 9BAA 92BC CDDD B9EF 3B36  CB99 B8C4 B8E5 47C3 2433
Blog: http://stardiviner.github.io/


Re: [O] Losing trust in Org: stable org-mode releases and unit tests for basic functionality

2016-01-19 Thread Marco Wahl
Hi Karl,

> * Marco Wahl  wrote:
>>
>> Further I think you can improve Org's reliability (and your perception
>> on it) by investing more energy into Org.  Obviously you already do
>> invest energy into Org as your contributions on this list show.  You
>> cold go ahead and start reading Org's code, writing tests, etc.  Each
>> action would give you more confidence with Org.
>
> I can follow your thoughts here.

> Unfortunately, my elisp knowledge is still to basic to think of
> writing ERT tests for my typical use-cases and add them to
> org-mode/testing/list/* :-(

Hopefully you will find time to dig into elisp!

> I was not able to even locate a simple "mark a simple recurring todo
> as done"-test in the current testset. Is it true, that there is no
> such test so far?

I also could not find such test.  This means potential for more tests.


Best wishes,
-- 
Marco Wahl
GPG: 0x49010A040A3AE6F2




Re: [O] bug#22399: org-mode fontification

2016-01-19 Thread Rasmus
Kyle Meyer  writes:

> I've attached two patches against emacs-25 that would get the Org and
> Emacs repos in similar states wrt font-lock-ensure.

Thanks Kyle.

> The first patch replaces the font-lock-ensure compatibility alias from
> 6711a21f1 with the one currently used in the Org repo (from commit
> e6883dd03).  The new alias is limited to being called with no
> arguments, but, at the moment, no Org code calls font-lock-ensure with
> any arguments.

I just have one concern, which is pretty theoretical.  Isn’t it bad to
define the alias to be font-lock-ensure since this is an existing function
and people would have clear expectations of what they are calling?  I
realize that there’s no Emacs-25 that will not have this function (which
is why it’s very theoretical).  Also, if the alias were ever to point to
font-lock-fontify-buffer, the signature would change compared to the
expected signature of font-lock-ensure.

These considerations are probably too theoretical to consider further,
though.

> The second patch reverts a part of 6711a21f1 that modified
> org-src-font-lock-fontify-block to use font-lock-ensure rather than
> font-lock-fontify-buffer.  In this particular case, using
> font-lock-ensure instead of font-lock-fontify-buffer fails to
> highlight the source block.

Cool!

Cheers,
Rasmus

-- 
May contains speling mistake




[O] org-mode on HN

2016-01-19 Thread edward sillador
Hello, I just want to let you know that org-mode is currently
being discussed on HN
https://news.ycombinator.com/item?id=10925655