Org table: emphasizing calculated cell
Greetings. In the table below, the text in the first column of the last row is emphasized. What is (an easy way) to emphasize the calculated value in the second column of the last row? | quantity | value | |--+---| | A| 1 | | B| 3 | |--+---| | *C* | 0.33 | #+TBLFM: @4$2=@-2/@-1;%.2f All the best, Jarmo
Re: [BUG] Creating sparse tree with regexp property matches
Ah! Can't believe I didn't try that. Well, at least the docs can
benefit from my confusion.
Thanks,
On Wed, Aug 25, 2021 at 6:05 PM Daniel Fleischer wrote:
>
> On Wed, Aug 25 2021, Cassio Koshikumo wrote:
> > Hello all,
> >
> > I think there's a bug with `org-make-tags-matcher' when creating a sparse
> > tree
> > using property matching with regular expressions and "or" terms. Take the
> > example given in the manual:
> >
> > +work-boss+PRIORITY="A"+Coffee="unlimited"+Effort<2
> >+With={Sarah|Denny}+SCHEDULED>="<2008-10-11 Sat>"
> >
> > If we isolate just this part:
> >
> > +With={Sarah|Denny}
> >
> > The resulting sparse tree does not match the right
> > headings. The function generates the following `tagsmatcher':
> >
> > (progn
> > (setq org-cached-props nil)
> > (or
> >(and
> > (member
> > #("Denny" 0 5
> >(regexp t))
> > tags-list))
> >(and
> > (member "With" tags-list
> >
> > There're checks for "Denny" (as a regexp) and "With" (as a string) --- this
> > is
> > supposed to be the property name, not a search term. They are both checked
> > for
> > in `tags-list'. And, finally, "Sarah" is nowhere to be seen.
> >
> > The problem, as far as I can tell, is that splitting the input at `|' to
> > get the
> > `orterms' does not work with the regular expression the function uses to
> > find
> > the constituent parts of each term. In this example, splitting the input at
> > `|'
> > makes one side get the opening brace and the other the closing brace, while
> > the
> > regexp expects both being present. Since the regexp doesn't fully match, the
> > terms are all parsed wrong. (The function doesn't recognize "With" as
> > property
> > name, for instance.) I'm still messing with it but, for now, don't really
> > know
> > how to fix the problem. I don't 100% understand the function yet...
> >
> > Regards,
>
> Hi, the solution is that it's elisp based regex, so OR is indicated with
> \| instead of just |. It might be good idea to correct the example.
>
> Best,
>
> *Daniel Fleischer*
--
Cassio Koshikumo
Re: [BUG] Creating sparse tree with regexp property matches
On Wed, Aug 25 2021, Cassio Koshikumo wrote:
> Hello all,
>
> I think there's a bug with `org-make-tags-matcher' when creating a sparse tree
> using property matching with regular expressions and "or" terms. Take the
> example given in the manual:
>
> +work-boss+PRIORITY="A"+Coffee="unlimited"+Effort<2
>+With={Sarah|Denny}+SCHEDULED>="<2008-10-11 Sat>"
>
> If we isolate just this part:
>
> +With={Sarah|Denny}
>
> The resulting sparse tree does not match the right
> headings. The function generates the following `tagsmatcher':
>
> (progn
> (setq org-cached-props nil)
> (or
>(and
> (member
> #("Denny" 0 5
>(regexp t))
> tags-list))
>(and
> (member "With" tags-list
>
> There're checks for "Denny" (as a regexp) and "With" (as a string) --- this is
> supposed to be the property name, not a search term. They are both checked for
> in `tags-list'. And, finally, "Sarah" is nowhere to be seen.
>
> The problem, as far as I can tell, is that splitting the input at `|' to get
> the
> `orterms' does not work with the regular expression the function uses to find
> the constituent parts of each term. In this example, splitting the input at
> `|'
> makes one side get the opening brace and the other the closing brace, while
> the
> regexp expects both being present. Since the regexp doesn't fully match, the
> terms are all parsed wrong. (The function doesn't recognize "With" as property
> name, for instance.) I'm still messing with it but, for now, don't really know
> how to fix the problem. I don't 100% understand the function yet...
>
> Regards,
Hi, the solution is that it's elisp based regex, so OR is indicated with
\| instead of just |. It might be good idea to correct the example.
Best,
*Daniel Fleischer*
Re: I can't find "org-latex-toc-command"
Ypo writes: > Hi. I was trying to add a break-line after the TOC. I've search for > some help, and I found this: (setq org-latex-toc-command > "\\tableofcontents \\clearpage"). But, it seems > org-latex-toc-command doesn't exist anymore? I can't find it, but > since I am quite newbie, I am not sure if it's there or not. > It's there AFAICT: it's a variable defined in `ox-latex.el'. Maybe you looked for it as a function with `C-h f ...' rather than `C-h v ...'? Or maybe `ox-latex' is not loaded for some unfathomable reason? -- Nick "There are only two hard problems in computer science: cache invalidation, naming things, and off-by-one errors." -Martin Fowler
[BUG] Creating sparse tree with regexp property matches
Hello all,
I think there's a bug with `org-make-tags-matcher' when creating a sparse tree
using property matching with regular expressions and "or" terms. Take the
example given in the manual:
+work-boss+PRIORITY="A"+Coffee="unlimited"+Effort<2
+With={Sarah|Denny}+SCHEDULED>="<2008-10-11>"
If we isolate just this part:
+With={Sarah|Denny}
The resulting sparse tree does not match the right
headings. The function generates the following `tagsmatcher':
(progn
(setq org-cached-props nil)
(or
(and
(member
#("Denny" 0 5
(regexp t))
tags-list))
(and
(member "With" tags-list
There're checks for "Denny" (as a regexp) and "With" (as a string) --- this is
supposed to be the property name, not a search term. They are both checked for
in `tags-list'. And, finally, "Sarah" is nowhere to be seen.
The problem, as far as I can tell, is that splitting the input at `|' to get the
`orterms' does not work with the regular expression the function uses to find
the constituent parts of each term. In this example, splitting the input at `|'
makes one side get the opening brace and the other the closing brace, while the
regexp expects both being present. Since the regexp doesn't fully match, the
terms are all parsed wrong. (The function doesn't recognize "With" as property
name, for instance.) I'm still messing with it but, for now, don't really know
how to fix the problem. I don't 100% understand the function yet...
Regards,
--
Cassio
I can't find "org-latex-toc-command"
Hi. I was trying to add a break-line after the TOC. I've search for some help, and I found this: (setq org-latex-toc-command "\\tableofcontents \\clearpage"). But, it seems org-latex-toc-command doesn't exist anymore? I can't find it, but since I am quite newbie, I am not sure if it's there or not. Best regards, Ypo
Re: org-capture config broken (org-protocol URI syntax)
On 25/08/2021 19:05, Orm Finnendahl wrote: I use a custom script (dating back to a post from 2013) to capture my mutt Emails using org-capture. It worked flawlessly but stopped working some time ago (I don't exactly know, when, probably last year). Unfortunately you did not specify version of Org you are currently using. I assume the code has changed and doesn't accept the syntax of the org-protocol line any more. emacsclient org-protocol:/capture:/m/mutt:ysyuf6skfsbwt...@example.com/mail/%20%20Subject%3A%20test%0A%20%20%20%20From%3A%20Unknown%20%3Cdummy%40example.com%3E This the old style of Org protocol URI. See https://orgmode.org/manual/The-capture-protocol.html for an example of modern variant (it has typos fixed in master branch, some "?" should be "&"). I am unsure concerning order of parameters in old-style URLs. Older syntax should still be supported (a warning requesting update may be issued however), unfortunately there were some issues, see e.g. https://orgmode.org/list/s4cjck$156g$2...@ciao.gmane.io Some details: https://orgmode.org/Changes_old.html#org3da1425 (news for version 9.0) The emacsclient commmand above is generated with a perl script using uri_escape for everything after /mail/. The single slashes in the protocol line of the emacsclient command seem strange, but I couldn't find any hint in the internet how the syntax is supposed to be for a certain org-capture-template. I suggest you to update perl script to generate URI with key-value parameters in query part. Concerning number of slashes, I suppose, the following should minimize issues with desktop integration and intermediate bugs in various versions of Org org-protocol:/capture?template=X?url=URL=TITLE=BODY namely no double slash after org-protocol otherwise in some cases slash might be inserted before question mark or second colon might be dropped in old-style URI. With double slash subprotocol might be interpreted as host name causing further normalization as dropping colon that is not followed by port number or adding path "/" before query part. Such considerations however are not applied for direct invocation of emacsclient. Emacsclient considers org-protocol URI as relative path, so it prepends argument with current working directory and squashes multiple slashes into single ones. That is why it does not matter how much consequent slashes are used in emacsclient command, however desktop-wide handlers may modify URI depending on number of slashes. Latest releases should tolerate URIs with slash before question mark like org-protocol://capture/?template=X?url=URL=TITLE=BODY
org-capture config broken
Hi,
I use a custom script (dating back to a post from 2013) to capture my
mutt Emails using org-capture. It worked flawlessly but stopped
working some time ago (I don't exactly know, when, probably last
year).
I assume the code has changed and doesn't accept the syntax of the
org-protocol line any more.
I'm calling emacsclient with the following command:
emacsclient
org-protocol:/capture:/m/mutt:ysyuf6skfsbwt...@example.com/mail/%20%20Subject%3A%20test%0A%20%20%20%20From%3A%20Unknown%20%3Cdummy%40example.com%3E
It fails printing "*ERROR*: Wrong type argument: arrayp, nil" in the terminal
and posts
"Greedy org protocol handler. Killing client"
in the minibuffer.
The emacsclient commmand above is generated with a perl script using
uri_escape for everything after /mail/. The single slashes in the
protocol line of the emacsclient command seem strange, but I couldn't
find any hint in the internet how the syntax is supposed to be for a
certain org-capture-template.
Maybe someone can help to debug it? Below is my init.el configuration.
Best,
Orm
(setq org-capture-templates
(quote
(("m"
"Mail"
entry
(file+headline "~/work/gtd.org" "Incoming")
"* %^{Title}\n Source: %u, %:link\n %i"
:empty-lines 1)
;; ... more templates here ...
)))
;; ensure that emacsclient will show just the note to be edited when invoked
;; from Mutt, and that it will shut down emacsclient once finished;
;; fallback to legacy behavior when not invoked via org-protocol.
(add-hook 'org-capture-mode-hook 'delete-other-windows)
(setq my-org-protocol-flag nil)
(defadvice org-capture-finalize (after delete-frame-at-end activate)
"Delete frame at remember finalization"
(progn (if my-org-protocol-flag (delete-frame))
(setq my-org-protocol-flag nil)))
(defadvice org-capture-kill (after delete-frame-at-end activate)
"Delete frame at remember abort"
(progn (if my-org-protocol-flag (delete-frame))
(setq my-org-protocol-flag nil)))
(defadvice org-protocol-capture (before set-org-protocol-flag activate)
(setq my-org-protocol-flag t))
Re: Bug: org-src-font-lock-fontify-block should be wrapped with save-match-data [9.3.7 (9.3.7-4-gba6ca7-elpaplus @ mixed installation! /mnt/c/Users/toz/Weiterbildung/Soft/Emacs/ and /mnt/c/Users/toz/.
In my previous message I forgot to mention the subject of the initial bug report: Bug: org-src-font-lock-fontify-block should be wrapped with save-match-data [9.3.7 (9.3.7-4-gba6ca7-elpaplus @ mixed installation! /mnt/c/Users/toz/Weiterbildung/Soft/Emacs/ and /mnt/c/Users/toz/.emacs.d/elpa/org-plus-contrib-20200615/) Notice "mixed installation!". Often it is source of obscure errors. https://orgmode.org/worg/org-faq.html#mixed-install Maybe link to FAQ item should be added to bug report template when mixed installation is detected. Since mixed installation can be detected, I would consider issuing a message during loading of Org mode. On 24/08/2021 23:57, Maxim Nikulin wrote: On 23/08/2021 14:45, Timothy wrote: Thanks for your efforts. I have prepared a patch accordingly that wraps org-src-font-lock-fontify-block’s body with save-match-data (attached). > The following question may be dumb since I am not familiar how font lock works in Emacs. Is it necessary to wrap whole function? I do not see explicit operation with regexps. The only suspecting line is (org-font-lock-ensure) I think, now it is irrelevant, so just for completeness: initialization of major mode might affect match data as well (unless (eq major-mode lang-mode) (funcall lang-mode))
Re: What happened to ./contrib?
On 25/08/2021 15:07, Martin Steffen wrote: Note that the documentation https://orgmode.org/worg/org-contrib/ (still) mentions currently a directory contrib, but in my latest pulled version, it's gone (see also https://github.com/bzg/org-mode). There is a patch that should fix links to raw files on worg: https://orgmode.org/list/sc4k26$uf6$1...@ciao.gmane.io See https://orgmode.org/list/874kf4fanb@gnu.org/ or https://lists.gnu.org/archive/html/emacs-orgmode/2021-05/msg00769.html for the announce of org-contrib package: Bastien writes: You can now install org-contrib as a new NonGNU ELPA package: https://elpa.nongnu.org/nongnu/ P.S. Please, do not use "reply" to ask new question since it merges unrelated discussions into single thread. It is better to compose new message.
Re: What happened to ./contrib?
The contrib directory has been broken out into its own git repository at https://git.sr.ht/~bzg/org-contrib and the main org repository is moving to be hosted on savannah.gnu.org (I think it is mirrored there already). This is all in preparation for having the contrib extensions available as an ELPA archive in the nonGNU ELPA repository and core org being available in the GNU ELPA repository. Things are in a transition stage at present, so there is still a bit of documentation updates/fixes needed to be completed. Updates are being sent to this list. HTH Martin Steffen writes: > Hi, > > I use org-mode, having cloned the git-version, pulling freshest versions > from time to time. Without a definite schedule when I do that I don't > know exactly when the change occured that I am asking here about. > > Anyway, my Org mode version is 9.4.6 (release_9.4.6-598-g604bfd @ > > > Now: today I notices, some org-mode packages/files are missing. As said, > I don't know since when that was the case. In particular, emacs > initialization could no longer do > > (require 'ox-extra) > > since the file is gone. I looked around that not just file is no longer > part of the clone, but the hole > > contrib/lisp > > directory (which is where that one was located) is gone. > > Is there a reason for that, resp. is the functionality of ox-extra been > moved somewhere else? > > Note that the documentation > > https://orgmode.org/worg/org-contrib/ > > (still) mentions currently a directory contrib, but in my latest pulled > version, it's gone (see also https://github.com/bzg/org-mode). > > If course I can roll-back to an earlier revision or download one to get > back for instance ox-extra (which has a feature I rely on), but perhaps > there's something wrong. > > Thanks, Martin
What happened to ./contrib?
Hi, I use org-mode, having cloned the git-version, pulling freshest versions from time to time. Without a definite schedule when I do that I don't know exactly when the change occured that I am asking here about. Anyway, my Org mode version is 9.4.6 (release_9.4.6-598-g604bfd @ Now: today I notices, some org-mode packages/files are missing. As said, I don't know since when that was the case. In particular, emacs initialization could no longer do (require 'ox-extra) since the file is gone. I looked around that not just file is no longer part of the clone, but the hole contrib/lisp directory (which is where that one was located) is gone. Is there a reason for that, resp. is the functionality of ox-extra been moved somewhere else? Note that the documentation https://orgmode.org/worg/org-contrib/ (still) mentions currently a directory contrib, but in my latest pulled version, it's gone (see also https://github.com/bzg/org-mode). If course I can roll-back to an earlier revision or download one to get back for instance ox-extra (which has a feature I rely on), but perhaps there's something wrong. Thanks, Martin
