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 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?
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
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
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
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
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 after @samp{[} to -complete link abbreviations. You may also define a func
Re: [O] links-9.0 v3
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 #'org-open-at-point >> "fil
Re: [O] tables: sum columns only in certain ranges of rows
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
> 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
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
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. You're right, they need to
Re: [O] links-9.0 v3
> > 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?
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
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
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?
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
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"
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
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
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
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