Re: [O] Bug: Table formula does not copy time interval correctly [8.2.10 (release_8.2.10 @ /usr/share/emacs/25.0.94/lisp/org/)]

[Rares Vernica]

Michael Brand  writes:

> Hi Rares
>
> On Mon, Jul 4, 2016 at 6:28 PM, Rares Vernica  wrote:
>
>> | [2016-07-03 Sun]--[2016-07-04 Mon] | 1d | d   |
>> | [2016-07-03 Sun]--[2016-07-05 Tue] | 2d | 2 d |
>> #+TBLFM: $3=$2
>
> A Calc formula interprets field values as a symbolic expressions to
> calculate with. To copy literally one needs a Lisp formula:
>
> | [2016-07-03 Sun]--[2016-07-04 Mon] | 1d | 1d |
> | [2016-07-03 Sun]--[2016-07-05 Tue] | 2d | 2d |
>
> #+TBLFM: $3 = '(identity $2)

That did the trick, thanks!

Just to clarify, how would you fix this:

| [2016-07-05 Tue]--[2016-07-06 Wed] | 1d | vsum(d) |
| [2016-07-06 Wed]--[2016-07-07 Thu] | 1d | 2 d |
#+TBLFM: $3=vsum(@1$-1..@0$-1)

Notice the "vsum(d)" instead of the expected "1 d". How would you add
"identity" here?

Thanks!
Rares

[O] Computing dates in properties?

[Jay Iyer]

Hi,
Is it possible to perform simple calculations in properties like in the
example below?  If so, please provide pointers.
Thanks,
-jay

** Headline 1
:PROPERTIES:
:CUSTOM_ID: headline_1
:DATE: [2016-07-07 Thu]
:END:

** Headline 2
:PROPERTIES:
:CUSTOM_ID: headline_2
*:DATE: [date from headline 1 + 3 days]*
:END:

Re: [O] org-mode habit consistency graph not displaying

[Brenda Butler]

Thanks for this answer.

Unfortunately it didn't work for me.  But when I have more time I will
investigate further.  This gives me a hint as to what
(next-single-property-change (point-min) 'org-habit-p)) does and the
environment it assumes.

bjb


On Thu, Jul 7, 2016 at 11:29 PM, Josiah Schwab  wrote:

> Hello Brenda,
>
> > When I started using org-mode from elpa, the habit consistency graph
> > stopped showing. I was using a version of org-mode that comes with
> > debian before, with emacs 23 and the graph showed.
>
> When I upgraded to org 8.3, my org-habits did not display correctly,
> because the PROPERTY drawer where the habit style was indicated came
> after the LOGBOOK in my org files.
>
> After using org-repair-property-drawers
>
>   http://orgmode.org/Changes.html
>
> my habits returned to their previous appearance.
>
> Hope that helps,
> Josiah
>
>

Re: [O] org-mode habit consistency graph not displaying

[Josiah Schwab]

Hello Brenda,

> When I started using org-mode from elpa, the habit consistency graph
> stopped showing. I was using a version of org-mode that comes with
> debian before, with emacs 23 and the graph showed.

When I upgraded to org 8.3, my org-habits did not display correctly,
because the PROPERTY drawer where the habit style was indicated came
after the LOGBOOK in my org files.

After using org-repair-property-drawers 

  http://orgmode.org/Changes.html

my habits returned to their previous appearance.

Hope that helps,
Josiah

[O] org-mode habit consistency graph not displaying

[Brenda J. Butler]

I have a question up at stackoverflow:

https://stackoverflow.com/questions/38031463/org-mode-habit-consistency-graph-not-displaying



Here is the content of the question and update:

org-version 8.3.4 (elpa package, 20160530)
emacs 24.4.1 (Debian package, Installed: 24.4+1-4.1~bpo70+1)

When I started using org-mode from elpa, the habit consistency graph
stopped showing. I was using a version of org-mode that comes with
debian before, with emacs 23 and the graph showed.

I'm a beginner in emacs lisp, but anyway I tried stepping through the
org-agenda-list function and found the org-agenda-finalize function
where the org habit graph is supposed to be inserted via the
org-habit-insert-consistency-graphs function. But it skips over that
function, probably because this expression returns false:

(next-single-property-change (point-min) 'org-habit-p))

At this point, I don't know what to do to make habits show. This is
the first time I've looked at org-mode code, I don't know what the
above test is for.

Help, please?

UPDATE: 2016-06-25. I upgraded the org-mode package to elpa, 20160620
(still org-version 8.3.4). Still have the same behaviour. I am getting
the package from elpa.gnu.org.

UPDATE 2: 2016-07-02: I did try pressing K (for
org-habit-toggle-habits). It didn't change the contents of the buffer
visibly. I also tried refreshing the buffer after typing K. And
repeating the experiment, in case the K put emacs in the wrong mode
the first time.


Thanks for whatever help you can send ...

bjb

Re: [O] links-9.0 v3

[John Kitchin]

Here are the new revisions that implement the previous solution you
suggested and that incorporate the commit merges as far as I can see.
WDYT?


commit 290213ef3eee86175d5a6b15c7b6173afd0c1616
Author: John Kitchin 
Date:   Tue Jul 5 10:38:42 2016 -0400

Update the contrib manual

diff --git a/contrib/orgmanual.org b/contrib/orgmanual.org
index e48ae97..07d9e8d 100644
--- a/contrib/orgmanual.org
+++ b/contrib/orgmanual.org
@@ -3300,12 +3300,16 @@ can define them in the file with
   ,#+LINK: googlehttp://www.google.com/search?q=%s
 #+end_src
 
-{{{noindent}}} In-buffer completion (see [[Completion]]) can be used after
-{{{samp([)}}} to complete link abbreviations.  You may also define a
-function ~org-PREFIX-complete-link~ that implements special (e.g.,
-completion) support for inserting such a link with {{{kbd(C-c C-l)}}}.
-Such a function should not accept any arguments, and return the full
-link with prefix.
+{{{noindent}}} In-buffer completion (see [[Completion]]) can be used
+after {{{samp([)}}} to complete link abbreviations.  You may also
+define a function that implements special (e.g., completion) support
+for inserting such a link with {{{kbd(C-c C-l)}}}.  Such a function
+should not accept any arguments, and return the full link with
+prefix.  You can set the link completion function like this:
+
+#+BEGIN_SRC emacs-lisp
+(org-link-set-parameter "type" :complete #'some-completion-function)
+#+END_SRC
 
 ** Search options
:PROPERTIES:
@@ -16998,10 +17002,9 @@ description when the link is later inserted into an 
Org buffer with
 {{{kbd(C-c C-l)}}}.
 
 When it makes sense for your new link type, you may also define a
-function ~org-PREFIX-complete-link~ that implements special (e.g.,
-completion) support for inserting such a link with {{{kbd(C-c C-l)}}}.
-Such a function should not accept any arguments, and return the full
-link with prefix.
+function that implements special (e.g., completion) support for
+inserting such a link with {{{kbd(C-c C-l)}}}.  Such a function should
+not accept any arguments, and return the full link with prefix.
 
 ** Context-sensitive commands
:PROPERTIES:
@@ -19181,8 +19184,8 @@ from the list of stored links.  To keep it in the list 
later use, use a
 triple {{{kbd(C-u)}}} prefix argument to {{{kbd(C-c C-l)}}}, or
 configure the option ~org-keep-stored-link-after-insertion~.
 
-[fn:37] This works by calling a special function
-~org-PREFIX-complete-link~.
+[fn:37] This works if a function has been defined in the :complete
+property of a link in ~org-link-parameters~.
 
 [fn:38] See the variable ~org-display-internal-link-with-indirect-buffer~.
 

commit 8e51c2ff4b37524dcc489d58a6769fd8430c5593
Author: John Kitchin 
Date:   Tue Jul 5 10:31:30 2016 -0400

Update NEWS with link announcement

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 9909910..6ff7442 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -353,6 +353,8 @@ first footnote.
 *** The ~org-block~ face is inherited by ~src-blocks~
 This works also when =org-src-fontify-natively= is non-nil.  It is also
 possible to specify per-languages faces.  See the manual for details.
+*** Links are now customizable
+Links can now have custom colors, tooltips, keymaps, display behavior, etc... 
Links are now centralized in ~org-link-parameters~.
 ** New functions
 *** ~org-next-line-empty-p~
 It replaces the deprecated ~next~ argument to ~org-previous-line-empty-p~.

commit 246539109bac10f8de227adbc491bdeb94e80ba0
Author: John Kitchin 
Date:   Tue Jul 5 10:29:07 2016 -0400

Update the texinfo for link parameters documentation

diff --git a/doc/org.texi b/doc/org.texi
index e92788f..f962a58 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -3711,11 +3711,11 @@ them with @key{up} and @key{down} (or @kbd{M-p/n}).
 valid link prefixes like @samp{http:} or @samp{ftp:}, including the prefixes
 defined through link abbreviations (@pxref{Link abbreviations}).  If you
 press @key{RET} after inserting only the @var{prefix}, Org will offer
-specific completion support for some link types@footnote{This works by
-calling a special function @code{org-PREFIX-complete-link}.}  For
-example, if you type @kbd{file @key{RET}}, file name completion (alternative
-access: @kbd{C-u C-c C-l}, see below) will be offered, and after @kbd{bbdb
-@key{RET}} you can complete contact names.
+specific completion support for some link types@footnote{This works if a
+completion function is defined in the :complete property of a link in
+@var{org-link-parameters}.}  For example, if you type @kbd{file @key{RET}},
+file name completion (alternative access: @kbd{C-u C-c C-l}, see below) will
+be offered, and after @kbd{bbdb @key{RET}} you can complete contact names.
 @orgkey C-u C-c C-l
 @cindex file name completion
 @cindex completion, of file names
@@ -3887,10 +3887,13 @@ can define them in the file with
 
 @noindent
 In-buffer completion (@pxref{Completion}) can be used 

Re: [O] links-9.0 v3

[John Kitchin]

Let me preface my reply that I think your last suggestion:

>   (org-link-get-parameter (if app (concat type "+" app) type) :follow)

Is the thing to do for this set of changes for now. I think it would
wrap up this set of changes. I will send a new set of diffs that
implement this shortly after this mail.

I have some other responses below because there are some things I don't
totally understand yet.

Nicolas Goaziou writes:

> John Kitchin  writes:
>
>>> Here is the gotcha. `type' is "file", not "file+sys" or "file+emacs",
>>> so, when checking `dedicated-function' first, we cannot tell the
>>> difference between "file+sys" and "file+emacs".
>>
>> I don't follow this. Why can't these be three types?
>
> The type is "file". "sys" or "emacs" are indications about how to follow
> them. "docview" is also an indication, but it really points to a "file".
>
>> They define 3 different follow actions right? Those are basically
>> equal to pressing RET, C-u RET and C-u C-u RET on a link. We could
>> just define three :follow functions, and one :export function for
>> them.
>
> It doesn't mean they cannot have an entry in `org-link-parameters'.
> Actually they should.
>
> However `org-link-protocols' keys are applications, not types. So

I don't understand what you mean here. The contents of org-link
protocols (in master) looks a lot like a list of (link-type :follow
:export), e.g.

#+BEGIN_SRC emacs-lisp :results code
(assoc "bbdb" org-link-protocols)
#+END_SRC

#+RESULTS:
#+BEGIN_SRC emacs-lisp
("bbdb" org-bbdb-open org-bbdb-export)
#+END_SRC

There doesn't seem to be a "sys" or "emacs" defined in
org-link-protocols in master. So there is no dedicated function being
called as far as I can tell.

#+BEGIN_SRC emacs-lisp :results code
(assoc "sys" org-link-protocols)
#+END_SRC

#+RESULTS:
#+BEGIN_SRC emacs-lisp
nil
#+END_SRC

>  (org-link-get-parameter type :follow)
>
> is not a drop-in replacement for
>
>   (nth 1 (assoc app org-link-protocols))

I see that these are not the same, since type != app.

With app, this would try to look up (org-link-get-parameter "sys"
:follow), which currently would return nil. That seems consistent with
what is currently in master too. I concede that if a "sys" link was
defined it would do something, but that isn't currently the case AFAICT.
Your solution solves this nicely though.

>> With the patches I sent, the three types actually work as they used to,
>> e.g. file:some.pptx opens the powerpoint file in emacs (not convenient
>> ;), file+sys:some.pptx opens it in powerpoint. This seems to be because
>> org-element-context (via org-element-link-parser) sees file+sys and
>> file+emacs as a file type.
>
> Which is correct.
>
>> Overall, this is an inconsistency to me. On one hand, we need file+sys
>> and file+emacs in org-link-parameters so that they are built into the
>> link regexps (or they would have to be hard-coded in the function that
>> makes the regexp.
>
> [...]
>
>> On the other hand, the org-open-at-point
>> function bypasses the link properties, so it is not possible to change
>> the :follow function for file+sys and file+emacs.
>
> Of course it is possible. I suggested two solutions already.
>
>>> One solution is to swap the logic order. First, if app is non-nil, we
>>> use it. If it isn't, we look after `dedicated-function'.
>>>
>>> Another solution is to add an optional parameter to the signature of
>>> the :follow function, which would be the "app" (e.g. "emacs", "sys",
>>> "docview"...) to use. I tend to think this solution is slightly better,
>>> since it doesn't require to hard-code logic in `org-open-at-point'.
>>>
>>> WDYT?
>>
>> I am not crazy about this solution,
>
> Which one? I suggested two of them.
I was referring to the optional parameter, although I reconsider it
here.  I don't understand how does the "application" get to the
follow functions of links other than file+sys and file+emacs. It seems
like we would need to allow type+application:path as a link syntax and
extend the link-parser to get the application. Right now it looks like
the parser only adds application properties to file type links.

>
>> since it only applies to one type of link,
>
> Does it? Every type can benefit from this change, i.e. instead of
> calling follow function with a single argument, it is called with two,
> the second one being the application (e.g., "sys", "emacs"...) or nil.

I don't mind this (it makes links more flexible after all ;) OTOH, we
would have to "register" each type+application for the link regexp, and
then each type can have its own follow function, so it seems unnecessary
to me.

I would leave this on the table for future consideration, but consider
it outside the current scope of this set of changes. I think with your
final suggestion it isn't necessary to consider this now. 

>
>> and I can't see how to use it for other follow functions. It would be
>> better IMO to define :follow functions maybe like this:
>>
>> "file" :follow 

Re: [O] tables: sum columns only in certain ranges of rows

[Nick Dokos]

Michael Brand  writes:

> Hi Uwe
>
> On Mon, Jul 4, 2016 at 9:12 PM, Uwe Brauer  wrote:
>
>> Is the a simple way to tell a org-table that
>> it adds say two columns in a certain way $4=0.2*($2+$3)
>> but only for certain values of the row. I hoped that
>> a hline would help but it does not the row containing Taylor
>> is treated in the same way as row 1 to 4.
>>
>>
>> | Row | Name   | E1 | E2 | Res |
>> |-++++-|
>> |   1 | Smith  |  1 |  2 | 0.6 |
>> |   2 | Miller |  2 |  1 | 0.6 |
>> |   3 | Meyer  |  1 |  4 |  1. |
>> |   4 | Wilson |  2 |  1 | 0.6 |
>> |-++++-|
>> |   5 | Taylor |  1 |  2 | 0.6 |
>> |-++++-|
>> #+TBLFM: $1=@#-1::$5=0.2*($3+$4)
>>
>>
>> So what is the most comfortable to obtain what I want?
>
> Depending on what you want you can use $5 = if($1 != 5, 0.2*($3+$4),
> string("")). See also some other examples with if in the Org manual.
>
> Michael
>
>

This seems to work:

--8<---cut here---end--->8---
#+TBLFM: $1=@#-1::@2$5..@5$5=0.2*($3+$4)
--8<---cut here---end--->8---

-- 
Nick

Re: [O] Using property values in source code blocks

[Joon Ro]

> Date: Thu, 7 Jul 2016 08:48:03 -0700
> From: ccbe...@ucsd.edu
> To: joon...@outlook.com
> Subject: Re: [O] Using property values in source code blocks
> CC: emacs-orgmode@gnu.org
> 
> On Wed, 6 Jul 2016, Joon Ro wrote:
> 
> >
> >
> >
> >> I have no idea what you are asking.
> >>
> 
> [snip]
> 
> > I'm sorry if my explanation was not clear, but the original example I 
> > provided shows exactly what I wanted to do:
> 
> And my response showed how to do it: you construct a src block with a 
> noweb reference that places the *results* of evaluating another src block 
> in the code (or comment). The src block in the named in the noweb 
> reference handles retrieving the property value, viz.
> 
> --8<---cut here---end--->8---
> 
> * Subtree
> :PROPERTIES:
> :DUMMY: Value
> :END:
> 
> #+NAME: get-property
> #+BEGIN_SRC emacs-lisp :var prop="prop"
> (car (org-property-values prop))
> #+END_SRC
> 
> #+BEGIN_SRC shell :noweb yes
> 
> echo <>
> 
> #+END_SRC
> 
> #+RESULTS:
> : Value
> 
> --8<---cut here---end--->8---
> 
> 
> See
> 
>(info "(org) Noweb reference syntax")
> 
> 
> Chuck
> 

I see. I must have misunderstood that example. I will try that - thank you so 
much!

  

Re: [O] Using property values in source code blocks

[Charles C. Berry]

On Wed, 6 Jul 2016, Joon Ro wrote:






I have no idea what you are asking.



[snip]

I'm sorry if my explanation was not clear, but the original example I 
provided shows exactly what I wanted to do:


And my response showed how to do it: you construct a src block with a 
noweb reference that places the *results* of evaluating another src block 
in the code (or comment). The src block in the named in the noweb 
reference handles retrieving the property value, viz.


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

* Subtree
:PROPERTIES:
:DUMMY: Value
:END:

#+NAME: get-property
#+BEGIN_SRC emacs-lisp :var prop="prop"
(car (org-property-values prop))
#+END_SRC

#+BEGIN_SRC shell :noweb yes

echo <>

#+END_SRC

#+RESULTS:
: Value

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


See

  (info "(org) Noweb reference syntax")


Chuck

Re: [O] links-9.0 v3

[Nicolas Goaziou]

John Kitchin  writes:

>> Here is the gotcha. `type' is "file", not "file+sys" or "file+emacs",
>> so, when checking `dedicated-function' first, we cannot tell the
>> difference between "file+sys" and "file+emacs".
>
> I don't follow this. Why can't these be three types?

The type is "file". "sys" or "emacs" are indications about how to follow
them. "docview" is also an indication, but it really points to a "file".

> They define 3 different follow actions right? Those are basically
> equal to pressing RET, C-u RET and C-u C-u RET on a link. We could
> just define three :follow functions, and one :export function for
> them.

It doesn't mean they cannot have an entry in `org-link-parameters'.
Actually they should.

However `org-link-protocols' keys are applications, not types. So

  (org-link-get-parameter type :follow)

is not a drop-in replacement for

  (nth 1 (assoc app org-link-protocols))

> With the patches I sent, the three types actually work as they used to,
> e.g. file:some.pptx opens the powerpoint file in emacs (not convenient
> ;), file+sys:some.pptx opens it in powerpoint. This seems to be because
> org-element-context (via org-element-link-parser) sees file+sys and
> file+emacs as a file type.

Which is correct.

> Overall, this is an inconsistency to me. On one hand, we need file+sys
> and file+emacs in org-link-parameters so that they are built into the
> link regexps (or they would have to be hard-coded in the function that
> makes the regexp.

[...]

> On the other hand, the org-open-at-point
> function bypasses the link properties, so it is not possible to change
> the :follow function for file+sys and file+emacs.

Of course it is possible. I suggested two solutions already.

>> One solution is to swap the logic order. First, if app is non-nil, we
>> use it. If it isn't, we look after `dedicated-function'.
>>
>> Another solution is to add an optional parameter to the signature of
>> the :follow function, which would be the "app" (e.g. "emacs", "sys",
>> "docview"...) to use. I tend to think this solution is slightly better,
>> since it doesn't require to hard-code logic in `org-open-at-point'.
>>
>> WDYT?
>
> I am not crazy about this solution,

Which one? I suggested two of them.

> since it only applies to one type of link,

Does it? Every type can benefit from this change, i.e. instead of
calling follow function with a single argument, it is called with two,
the second one being the application (e.g., "sys", "emacs"...) or nil.

> and I can't see how to use it for other follow functions. It would be
> better IMO to define :follow functions maybe like this:
>
> "file" :follow #'org-open-at-point
> "file+sys" :follow (lambda (_) (org-open-at-point '(4)))
> "file+emacs" :follow (lambda (_) (org-open-at-point '(16)))
>
> and make them be honored in org-open-at-point. Then we could eliminate
> the logic code in org-open-at-point.

You may be misunderstanding the problem. 

The issue is that `org-open-at-point', at the moment, cannot call
the :follow function for "file+emacs" or "file+sys" since the common
type is "file", even if `org-link-parameters' distinguish them. IOW the
first :follow function would always be called.

Also, `org-open-at-point' shouldn't be part of a follow function, since
`org-open-at-point' calls follow functions. It can call `org-open-file',
tho, as currently done in `org-open-at-point'.

Actually, I can think of a third solution, which may well follow the
path of least resistance. Instead of calling

  (org-link-get-parameter type :follow)

we would call

  (org-link-get-parameter (if app (concat type "+" app) type) :follow)

and get the appropriate follow function. This solution is local to
`org-open-at-point', but I don't think other places need :follow
function.

>>>(let ((data (assoc type org-link-parameters)))
>>> -(if data
>>> -   (cl-loop for (key val) on parameters by #'cddr
>>> -do
>>> -(setf (cl-getf (cdr data) key)
>>> -  val))
>>> +(if data (setcdr data (org-combine-plists (cdr data) parameters))
>>>(push (cons type parameters) org-link-parameters)
>>>(org-make-link-regexps)
>>>(org-element-update-syntax
>>
>> This change can be merged with `org-link-set-parameters' definition.
>
> I am not sure how to do that. It is like a hunk in one commit that I
> want to move to another commit.

I would edit the commit defining `org-link-set-parameters' and install
that change there. Then, upon rebasing, I would make sure this change is
preserved.

>>> +(defcustom org-link-parameters
>>> +  '(("http") ("https") ("ftp") ("mailto")
>>> +("file" :complete 'org-file-complete-link)
>>> +("file+emacs") ("file+sys")
>>> +("news") ("shell") ("elisp")
>>> +("doi") ("message") ("help"))
>>
>> See above about "file+emacs" and "file+sys", which are not valid types.
>
> Those either need to be here for link regexps, or hard-coded somewhere
> else though.

Re: [O] links-9.0 v3

[John Kitchin]

>
> That's great. I realized there's one gotcha left.
>
>>(let* ((option (org-element-property :search-option link))
>>   (app (org-element-property :application link))
>>   (dedicated-function
>> -  (nth 1 (assoc app org-link-protocols
>> +  (org-link-get-parameter type :follow)))
>>  (if dedicated-function
>
> Here is the gotcha. `type' is "file", not "file+sys" or "file+emacs",
> so, when checking `dedicated-function' first, we cannot tell the
> difference between "file+sys" and "file+emacs".

I don't follow this. Why can't these be three types? They
define 3 different follow actions right? Those are basically equal to
pressing RET, C-u RET and C-u C-u RET on a link. We could just define
three :follow functions, and one :export function for them.

With the patches I sent, the three types actually work as they used to,
e.g. file:some.pptx opens the powerpoint file in emacs (not convenient
;), file+sys:some.pptx opens it in powerpoint. This seems to be because
org-element-context (via org-element-link-parser) sees file+sys and
file+emacs as a file type.

Overall, this is an inconsistency to me. On one hand, we need file+sys
and file+emacs in org-link-parameters so that they are built into the
link regexps (or they would have to be hard-coded in the function that
makes the regexp. E.g. (cons "coderef" (org-link-types)) is already done
that way for some reason). On the other hand, the org-open-at-point
function bypasses the link properties, so it is not possible to change
the :follow function for file+sys and file+emacs.

> One solution is to swap the logic order. First, if app is non-nil, we
> use it. If it isn't, we look after `dedicated-function'.
>
> Another solution is to add an optional parameter to the signature of
> the :follow function, which would be the "app" (e.g. "emacs", "sys",
> "docview"...) to use. I tend to think this solution is slightly better,
> since it doesn't require to hard-code logic in `org-open-at-point'.
>
> WDYT?

I am not crazy about this solution, since it only applies to one type of
link, and I can't see how to use it for other follow functions. It would be
better IMO to define :follow functions maybe like this:

"file" :follow #'org-open-at-point
"file+sys" :follow (lambda (_) (org-open-at-point '(4)))
"file+emacs" :follow (lambda (_) (org-open-at-point '(16)))

and make them be honored in org-open-at-point. Then we could eliminate
the logic code in org-open-at-point.

>
>>(let ((data (assoc type org-link-parameters)))
>> -(if data
>> -(cl-loop for (key val) on parameters by #'cddr
>> - do
>> - (setf (cl-getf (cdr data) key)
>> -   val))
>> +(if data (setcdr data (org-combine-plists (cdr data) parameters))
>>(push (cons type parameters) org-link-parameters)
>>(org-make-link-regexps)
>>(org-element-update-syntax
>
> This change can be merged with `org-link-set-parameters' definition.

I am not sure how to do that. It is like a hunk in one commit that I
want to move to another commit.

>
>> +(defcustom org-link-parameters
>> +  '(("http") ("https") ("ftp") ("mailto")
>> +("file" :complete 'org-file-complete-link)
>> +("file+emacs") ("file+sys")
>> +("news") ("shell") ("elisp")
>> +("doi") ("message") ("help"))
>
> See above about "file+emacs" and "file+sys", which are not valid types.

Those either need to be here for link regexps, or hard-coded somewhere
else though. Speaking of which, should coderef be a link type, so it can
be removed as a hard-coded string that I referenced above?

> Regards,


-- 
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] org-beamer: How to leave a block?

[Nicolas Goaziou]

Hello,

Florian Lindner  writes:

> Hello,
>
> I have
>
> *** MATLAB vs. PETSc:B_quote:
> :PROPERTIES:
> :BEAMER_env: quote
> :END:
> some lengthy quote
>
> from the manual
>
> Now I want to put the "from the manual" below the quote environment, not 
> inside, like that:
>
> \begin{frame}
> \begin{quote} %% MATLAB vs. PETSc
> some lengthy quote
> \end{quote}
> from the manual
> \end{frame}
>
> How can I achieve that which org-mode beamer, i.e. leave a block?

See "ignoreheading" environment to close blocks, or simply

  #+begin_quote
  some lengthy quote
  #+end_quote

Regards,

-- 
Nicolas Goaziou

Re: [O] Problem with eldoc and Python

[Nicolas Goaziou]

Hello,

Fabrice Popineau  writes:

> Here a 2 very small patches for contrib/lisp/org-eldoc.el

Applied, with changes to commit messages. Thank you.

Regards,

-- 
Nicolas Goaziou

Re: [O] Problem with eldoc and Python

[Fabrice Popineau]

Here a 2 very small patches for contrib/lisp/org-eldoc.el

Regards,

Fabrice



2016-07-06 23:27 GMT+02:00 Nicolas Goaziou :

> Fabrice Popineau  writes:
>
> > The problem is that the byte code comes from Python mode.
> > I solved the problem with this:
> >
> > $ diff -uw contrib/lisp/org-eldoc.el contrib/lisp/org-eldoc.el
> > --- contrib/lisp/org-eldoc.el   2016-02-29 11:13:22.330099500 +0100
> > +++ contrib/lisp/org-eldoc.el   2016-07-04 07:11:10.466144400 +0200
> > @@ -155,7 +155,8 @@
> >   (string= lang "golang")) (when (require 'go-eldoc nil t)
> >
> >  (go-eldoc--documentation-function)))
> > (t (let ((doc-fun
> > (org-eldoc-get-mode-local-documentation-function lang)))
> > -(when (fboundp doc-fun) (funcall doc-fun
> > +(when (or (and (symbolp doc-fun) (fboundp doc-fun))
> > + (functionp doc-fun)) (funcall doc-fun
>
> Wouldn't
>
>   (when (functionp doc-fun) (funcall doc-fun))
>
> be enough?
>
> Also, would you provide a patch for this?
>
> Thank you.
>
> Regards,
>


0001-The-doc-fun-object-may-be-a-function-object-and-not-.patch
Description: Binary data


0001-When-inserting-a-new-src-block-the-language-may-not-.patch
Description: Binary data

[O] org-beamer: How to leave a block?

[Florian Lindner]

Hello,

I have

*** MATLAB vs. PETSc:B_quote:
:PROPERTIES:
:BEAMER_env: quote
:END:
some lengthy quote

from the manual

Now I want to put the "from the manual" below the quote environment, not 
inside, like that:

\begin{frame}
\begin{quote} %% MATLAB vs. PETSc
some lengthy quote
\end{quote}
from the manual
\end{frame}

How can I achieve that which org-mode beamer, i.e. leave a block?

Thanks,
Florian

Re: [O] [ox-publish, patch] More flexible sitemaps

[Rasmus]

Hi,

Sorry about the slow reply.  Sometimes there's not enough time.

Nicolas Goaziou  writes:

>> +  (unless (or (file-directory-p file) (directory-name-p file))
>
> What is `directory-name-p'?

Oh, it's new in Emacs-25.  Thanks for pointing that out!



The following is about the index function, which is the most "difficult"
part.

>> +  (let* ((org-inhibit-startup t)
>> + (visiting (find-buffer-visiting file))
>> + (buffer (or visiting (find-file-noselect file)))
>> + (case-fold-search t))
>> +(with-current-buffer buffer
>> +  ;; protect local variables in open buffers
>> +  (org-export-with-buffer-copy
>> +   (let* ((backends (append (list nil)
>> +(mapcar 'org-export-backend-name
>> +
>> org-export-registered-backends)))
>> +  (value (cl-loop for backend in backends
>> +  when (org-no-properties
>> +(org-element-interpret-data
>> + (plist-get (org-export-get-environment backend)
>> +prop)))
>> +  return it)))
>
> Return value of `org-element-interpret-data' is never nil so the loop
> always returns the first back-end.
>
> In any case, this is sub-optimal since common keywords are retrieved for
> each back-end. Also, two back-ends could use the same keyword, with
> different values (e.g., using `parsed' or not).
>
> One option could be to change the policy about keywords in ox.el and
> move KEYWORDS and SUBTITLE there. Unfortunately, there is still a change
> to miss some cases.
>
> Another option would be to provide BACKEND to sitemap-function. I think
> it can be backward-compatible if we make it an optional argument.

I obviously agree with your criticism.  It’s not obvious how to do this
properly.

If we provide a backend we’d have to move the index preparation to
beginning of each export process as :publishing-function can be a list.
Also, I’m not sure how we’d know about the backend.  Before the exporting
starts, we at most know the names of the functions right?  If one of the
publishing functions is anonymous we don’t even have that.

Perhaps the best way is to move keywords back to ox, though I’d rather opt
for something else.

>> + ;; Call function to build sitemap based on files and the project-plist.
>> + (let* ((style (or (plist-get project-plist :sitemap-style) 'tree))
>> +(fun (intern (format "org-publish-org-sitemap-as-%s" style
>
> Side note : I think this is a bit too smart. It prevents, e.g., from
> grepping for a function name. Maybe 
>
>   (if (eq style 'something) #'... #')
>
> would be better.

The point is that it should be easy to supply your own functions.  All
sorts of requirements for the index/sitemap could come up, and it is
important to not limit to the tree-style and the flat-style.  I might want
to provide an index ordered by keywords, say.

Perhaps styles should be stores in an alist with elements like

(STYLE STYLE-FUNCTION) ? 

>> +@item @code{:sitemap-preamble}
>> +@item @code{:sitemap-postamble}
>> +@tab Preamble and postamble for sitemap.  Useful for inserting
>> +@code{#+OPTIONS}, footers etc.  See @code{org-publish-sitemap-preamble}
>> +for details.
>
> I don't understand the "useful for inserting @code{#+OPTIONS}" part.
> Maybe some examples could be useful. This part of the manual is rather
> terse.

It might be useful to suppress the printing of the title or the author or
similar.

Rasmus

-- 
I feel emotional landscapes they puzzle me

[O] Bug? Date calculation in table fail with locale "de"

[Ulrich J. Herter]

Dear Orgers,

Is this a bug? I'm trying to do some date calculations in a table,
however, when on German language settings I'm getting the following:

| <2016-07-07 Do> | <2016-07-08 Fr> | #ERROR |
#+TBLFM: $3=$2-$1

Debugger output:
Substitution history of formula
Orig:   ?
$xyz->  $2-$1
@r$c->  $2-$1
$1->(<2016-07-08 Fri>)-(<2016-07-07 Do>)
^
Error:  Bad word in date: "Do"

There is no difference when using "date($1)...".
When doing "date" on each individually it works as expected. 

| <2016-07-07 Do> | <2016-07-08 Fr> | 736152 | 736153 | 1 |
#+TBLFM: $3=date($1)::$4=date($2)::$5=$4-$3


Also, putting the locale to LANG="us_US.UTF8" and the dates in US
format, I do NOT get the error and the examples run fine.

My emacs version is GNU Emacs 24.5.1 Org version 8.3.4 (release_8.3.4-
99-ga8e4a3).

Any ideas how to fix this?

Thanks
Uli

Re: [O] Adding [fragile] to a LaTeX Beamer slide

[Florian Lindner]

Am 06.07.2016 um 22:49 schrieb Nicolas Goaziou:
> Hello,
> 
> Florian Lindner  writes:
> 
>> How can I add a fragile option to the frame
> 
> You can set :BEAMER_OPT property accordingly.

Great, works:

:PROPERTIES:
:BEAMER_OPT: fragile
:END:

Just one more question, btw. When I used this property syntax:

#+PROPERTY: BEAMER_OPT fragile

The only difference is that this property would be inherited to children?


>> or make the BEGIN_src block use the lstlisting environment?
> 
> See `org-latex-listings'.

Works fine by setting:

(setq org-latex-listings t
  org-latex-packages-alist '(("" "listings") ("" "color"


Thanks for your help!

Florian

Re: [O] links-9.0 v3

[Nicolas Goaziou]

Hello,

John Kitchin  writes:

> I think I have addressed these. Revised commits appended and at 
> https://github.com/jkitchin/org-mode/tree/link-9.0-v3.
>
> The new org-link-set-parameters function you suggested works fine as far
> as I can tell. WDYT?

That's great. I realized there's one gotcha left.

> (let* ((option (org-element-property :search-option link))
>(app (org-element-property :application link))
>(dedicated-function
> -   (nth 1 (assoc app org-link-protocols
> +   (org-link-get-parameter type :follow)))
>   (if dedicated-function

Here is the gotcha. `type' is "file", not "file+sys" or "file+emacs",
so, when checking `dedicated-function' first, we cannot tell the
difference between "file+sys" and "file+emacs".

One solution is to swap the logic order. First, if app is non-nil, we
use it. If it isn't, we look after `dedicated-function'.

Another solution is to add an optional parameter to the signature of
the :follow function, which would be the "app" (e.g. "emacs", "sys",
"docview"...) to use. I tend to think this solution is slightly better,
since it doesn't require to hard-code logic in `org-open-at-point'.

WDYT?

>(let ((data (assoc type org-link-parameters)))
> -(if data
> - (cl-loop for (key val) on parameters by #'cddr
> -  do
> -  (setf (cl-getf (cdr data) key)
> -val))
> +(if data (setcdr data (org-combine-plists (cdr data) parameters))
>(push (cons type parameters) org-link-parameters)
>(org-make-link-regexps)
>(org-element-update-syntax

This change can be merged with `org-link-set-parameters' definition.

> +(defcustom org-link-parameters
> +  '(("http") ("https") ("ftp") ("mailto")
> +("file" :complete 'org-file-complete-link)
> +("file+emacs") ("file+sys")
> +("news") ("shell") ("elisp")
> +("doi") ("message") ("help"))

See above about "file+emacs" and "file+sys", which are not valid types.

Regards,

-- 
Nicolas Goaziou

Re: [O] tables: sum columns only in certain ranges of rows

[Michael Brand]

Hi Uwe

On Mon, Jul 4, 2016 at 9:12 PM, Uwe Brauer  wrote:

> Is the a simple way to tell a org-table that
> it adds say two columns in a certain way $4=0.2*($2+$3)
> but only for certain values of the row. I hoped that
> a hline would help but it does not the row containing Taylor
> is treated in the same way as row 1 to 4.
>
>
> | Row | Name   | E1 | E2 | Res |
> |-++++-|
> |   1 | Smith  |  1 |  2 | 0.6 |
> |   2 | Miller |  2 |  1 | 0.6 |
> |   3 | Meyer  |  1 |  4 |  1. |
> |   4 | Wilson |  2 |  1 | 0.6 |
> |-++++-|
> |   5 | Taylor |  1 |  2 | 0.6 |
> |-++++-|
> #+TBLFM: $1=@#-1::$5=0.2*($3+$4)
>
>
> So what is the most comfortable to obtain what I want?

Depending on what you want you can use $5 = if($1 != 5, 0.2*($3+$4),
string("")). See also some other examples with if in the Org manual.

Michael

Re: [O] Bug: Table formula does not copy time interval correctly [8.2.10 (release_8.2.10 @ /usr/share/emacs/25.0.94/lisp/org/)]

[Michael Brand]

Hi Rares

On Mon, Jul 4, 2016 at 6:28 PM, Rares Vernica  wrote:

> | [2016-07-03 Sun]--[2016-07-04 Mon] | 1d | d   |
> | [2016-07-03 Sun]--[2016-07-05 Tue] | 2d | 2 d |
> #+TBLFM: $3=$2

A Calc formula interprets field values as a symbolic expressions to
calculate with. To copy literally one needs a Lisp formula:

| [2016-07-03 Sun]--[2016-07-04 Mon] | 1d | 1d |
| [2016-07-03 Sun]--[2016-07-05 Tue] | 2d | 2d |
#+TBLFM: $3 = '(identity $2)

Michael