Re: [org-cite] issues with org-cite-make-insert-processor select-style
BTW, here's the info from the debugger:
Debugger entered--Lisp error: (error "Wrong argument type(s)")
error("Wrong argument type(s)")
org-cite-make-insert-processor(bibtex-actions-org-cite-insert
bibtex-actions-org-cite-select-style)
(org-cite-register-processor 'bibtex-actions-org-cite
:insert (org-cite-make-insert-processor
#'bibtex-actions-org-cite-insert
#'bibtex-actions-org-cite-select-style)
:follow #'bibtex-actions-org-cite-follow)
load-with-code-conversion("/home/bruce/.config/emacs/.local/straight/build-28..."
"/home/bruce/.config/emacs/.local/straight/build-28..." nil t)
require(bibtex-actions-org-cite nil nil)
On Wed, Jul 21, 2021 at 11:14 AM Bruce D'Arcus wrote:
>
> I have run into a problem in implementing a "select-style" function
> for an org-cite-insert-processor.
>
> The WIP code is here:
>
> https://github.com/bdarcus/bibtex-actions/pull/182
>
> It was running correctly yesterday morning, but now it doesn't.
>
> I have two related issues:
>
> 1. I think, but am not sure, I may have run into a bug in
> org-cite-make-insert-processor, as the function I am using for the
> select-style parameter runs correctly outside of the insert processor,
> and returns the same results as the "org-cite-basic--complete-style"
> function. But when I uncomment the parameter to use it on the org-cite
> insert processor, it not only doesn't work correctly, but Emacs won't
> even load fully.
>
> 2. The error I get "wrong type" is so general it literally took me
> hours to realize it was coming from this function; I was looking
> elsewhere for the issue.
>
> So if I'm right about a bug, obviously it would be great if that could be
> fixed.
>
> But better error handling and reporting would also be really great.
>
> Bruce
>
> PS - I"m still learning elisp, and so am not super knowledgeable about
> debugging in general. If anyone has any tips on that, that could help
> me narrow down the source of the error, that would be much
> appreciated.
Re: a repeater doesn't increment
Does enough material exist on werg tutorials that document how to get a repeater operational? That or maybe I don't understand repeaters. Had the repeater I tried to use worked correctly it would have advanced the original date by 4 weeks when that date got copied down to another cell. I selected the whole line including both verticals and perhaps this works when only a time stamp is copied. On Tue, 20 Jul 2021, Jude DaShiell wrote: > I am likely doing this wrong but will describe what has been done. > I put an agenda time stamp into a field in test.org and add +4w to the end > of the time stamp inside the >. > I get on the left of the field column on the vertical character and type > control-space to set mark. > I move to the end of the field on the > sign and type space and another > vertical to close the column entry for that field. > Next I do control-c+x+v and am told strings are copied to the kill ring. > Next I move down one line and type control-y to yank those strings out of > the kill buffer and paste them on that line. > When this is done, I expected the time stamp to increment by 4 weeks. > What happened was the same information got copied down and it didn't > increment. > What am I doing wrong? > > >
Re: setting export options in headline properties
arg. thx, Chuck. On Wed, Jul 21, 2021 at 4:25 PM Berry, Charles wrote: > Matt, > > Check (info "(org) Export Settings") > > and especially, the para near bottom: > > When exporting sub-trees, special node properties can override the > above keywords. These properties have an ‘EXPORT_’ prefix. For > example, ‘DATE’ becomes, ‘EXPORT_DATE’ when used for a specific > sub-tree. Except for ‘SETUPFILE’, all other keywords listed above have > an ‘EXPORT_’ equivalent. > > HTH, > > Chuck > > > On Jul 21, 2021, at 11:52 AM, Matt Price wrote: > > > > Hi, > > > > I'm not sure if I'm reading the documentation properly, but my > understnading is that I ought to be able to set export options as subtree > properties, and that if I do so, they should be picked up by export engines > when exporting subtrees. However, that doesn't see to be happening for me, > and from what I can tell, `org-export-get-environment` is not overriding > global values when passed the `subtreep` parameter. > > > > I tried the following with emacs -Q , which seems to confirm my issue. > Is this the expected behaviour, and if so, is there some other way for me > to set subtree-level export options? > > > > -- > > ** subtree > > :PROPERTIES: > > :SUBTITLE: testing > > :REVEAL_TITLE_SLIDE: nil > > :HTML_CONTAINER: section > > :END: > > > > > > #+begin_src emacs-lisp > > (let ((info (org-export-get-environment 'html t))) > > (string-join `(,(plist-get info :subtitle) ,(plist-get info > :html-container)) "\n") > > ) > > #+end_src > > > > #+RESULTS: > > : > > : div > > -- > > > > thanks as always! > >
Re: setting export options in headline properties
Matt, Check (info "(org) Export Settings") and especially, the para near bottom: When exporting sub-trees, special node properties can override the above keywords. These properties have an ‘EXPORT_’ prefix. For example, ‘DATE’ becomes, ‘EXPORT_DATE’ when used for a specific sub-tree. Except for ‘SETUPFILE’, all other keywords listed above have an ‘EXPORT_’ equivalent. HTH, Chuck > On Jul 21, 2021, at 11:52 AM, Matt Price wrote: > > Hi, > > I'm not sure if I'm reading the documentation properly, but my understnading > is that I ought to be able to set export options as subtree properties, and > that if I do so, they should be picked up by export engines when exporting > subtrees. However, that doesn't see to be happening for me, and from what I > can tell, `org-export-get-environment` is not overriding global values when > passed the `subtreep` parameter. > > I tried the following with emacs -Q , which seems to confirm my issue. Is > this the expected behaviour, and if so, is there some other way for me to set > subtree-level export options? > > -- > ** subtree > :PROPERTIES: > :SUBTITLE: testing > :REVEAL_TITLE_SLIDE: nil > :HTML_CONTAINER: section > :END: > > > #+begin_src emacs-lisp > (let ((info (org-export-get-environment 'html t))) > (string-join `(,(plist-get info :subtitle) ,(plist-get info > :html-container)) "\n") > ) > #+end_src > > #+RESULTS: > : > : div > -- > > thanks as always!
Re: org-cite: how to include a cite with no key?
On Tue, Jul 20, 2021 at 3:32 AM Emmanuel Charpentier < emm.charpent...@free.fr> wrote: > Le mardi 20 juillet 2021 à 02:55 -0400, Matt Price a écrit : > > Certainly citation of personal communications is common in the fields of > history and philosophy of science, where it represents an effort to > responsibly represent the source of ideas owed to other persons. > > > I don't dispute that. > > It's not really a question of whether you personally would do it; it's a > question of whether org will support a practice that exists in some > real-world contexts. > > > What I dispute is that such "non-citations" are dangling pointers, better > replaced by incises or footnotes ... or proper citations. > just wanted to say sorry if I was gouchy there. Shouldn't write emails so late at night! > > -- > Emmanuel Charpentier > >
setting export options in headline properties
Hi, I'm not sure if I'm reading the documentation properly, but my understnading is that I ought to be able to set export options as subtree properties, and that if I do so, they should be picked up by export engines when exporting subtrees. However, that doesn't see to be happening for me, and from what I can tell, `org-export-get-environment` is not overriding global values when passed the `subtreep` parameter. I tried the following with emacs -Q , which seems to confirm my issue. Is this the expected behaviour, and if so, is there some other way for me to set subtree-level export options? -- ** subtree :PROPERTIES: :SUBTITLE: testing :REVEAL_TITLE_SLIDE: nil :HTML_CONTAINER: section :END: #+begin_src emacs-lisp (let ((info (org-export-get-environment 'html t))) (string-join `(,(plist-get info :subtitle) ,(plist-get info :html-container)) "\n") ) #+end_src #+RESULTS: : : div -- thanks as always!
Re: [PATCH] bad table formula recorded in some cases
Ok, Timothy, fair enough Le 21/07/2021 à 17:07, Timothy a écrit : > Hi Thierry, > > tbanelwebmin writes: >> I don't know the intention. But the answer may lie in the comment 4 >> lines above: >>;; Don't overwrite TBLFM, we might use text properties to >>;; store stuff. >> >> In this case, the intention would be to keep the original "#+TBLFM:" >> instead of inserting a fresh new one. >> >> But we are in the else branch of (if (looking-at ...)), which means >> there was no "#+TBLFM:". And no text properties to save. Therefore we >> may safely remove this (match-string 2). > Thank you for looking into this, I'm reassured by your inference that > this change is safe to make. I'm not really one of the main > contribution-acceptors/pushers though, so I'd rather leave this for > someone like Nicolas to sign off on. > > Would you mind bumping this thread in a few weeks if nothing happens? > > Hope that's not too much of an inconvenience, > > Timothy. > >> Le 21/07/2021 à 12:50, Timothy a écrit : >>> Hi Thierry, >>> >>> Thanks for this! Looking at the change you suggest, do you know why the >>> (match-string 2) bit might have been added in the first place? I'm just >>> wondering if there might be some edge-case adversely affected by this --- >>> hence trading one bug for another :P >>> >>> -- >>> Timothy >>> >>> tbanelwebmin writes: >>> Small bug, small fix. Suppose we have a table embedded in a begin-end block. #+begin: aaa :param value | a | b | | a | b | #+end: Suppose we want to add a formula, with C-c = We end up with an incorrect result: #+begin: aaa :param value | a | 33 | | a | b | :param value $2=33 #+end: The fix: in org-table.el, line 2177, change (insert (or (match-string 2) "#+TBLFM:"))) to (insert "#+TBLFM:")) Then we get the correct result: #+begin: aaa :param value | a | 33 | | a | b | #+TBLFM: $2=33 #+end: Why? Because (match-string 2) is supposed to refer to the (looking-at) instruction 7 lines above. But (match-string 2) is in the else branch, which means that (looking-at) failed. Therefore (match-string 2) returns garbage. Thanks to Uwe Brauer for pointing to this bug.
Bug: org-deadline drops warning periods from TIME [9.4.6 (9.4.6-10-gee652a-elpaplus @ /home/fap/.emacs.d/elpa/org-plus-contrib-20210712/)]
* Reproduction Call ~org-deadline~ with a warning period like so: (org-deadline nil "<2021-07-20 Tue -1d>") ;; => DEADLINE: <2021-07-20 Tue> * Expected Deadline gets added with the warning period provided. * Actual Deadline gets added without the provided warning period. * Discussion I've opened a Emacs Stackexchange question regarding this: https://emacs.stackexchange.com/questions/66765/how-to-insert-an-org-deadline-from-lisp-with-a-warning-period/ And got told the following by Nick D: #+begin_quote I think this is a bug: the function ~org--deadline-or-schedule~ saves a repeater (e.g ~+2d~ ) and adds it back at the end, but the regexp does not match a warning period (e.g. ~-2d~) so it drops it. You should probably report it with ~M-x org-submit-bug-report~. #+end_quote * Version info Emacs : GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cairo version 1.16.0) of 2020-09-19 Package: Org mode version 9.4.6 (9.4.6-10-gee652a-elpaplus @ /home/fap/.emacs.d/elpa/org-plus-contrib-20210712/)
Re: what would cause failure in template for org capture?
On Wed, Jul 21, 2021 at 04:38:58PM +0100, Eric S Fraga wrote: > u figured why not learn edebug *now*. > > so I instrument that method, start the capture, tell edebug to go when > it stops in that function, and the capture works. And now it works > whether instrumented or not. Hey hum. A total mystery but at least it > works. So edebug fixed it? Good :-) (Now I'm hiding again under my stone ;-) Cheers - t signature.asc Description: Digital signature
Re: Comments break up a paragraph when writing one-setence-per-line
On 21/07/2021 22:22, Eric S Fraga wrote: On Wednesday, 21 Jul 2021 at 21:48, Maxim Nikulin wrote: It is at least fragile. HTML export results in separate paragraphs: Yes, I said "if exporting to LaTeX"... ;-) I am unsure, but "#+latex:" probably belongs to "Keywords" that are elements, so it should end a paragraph. If such interpretation is correct than either LaTeX exporter has a bug or syntax description should be justified. No, I don't think of it as a keyword and it cannot end a paragraph as it would then break any document that uses such constructs. Not sure what to call it but it falls into the same category as inline directives like @@latex:...@@. And, in fact, this would work as well as the first example, again failing for HTML export: ... (untested) :-) "@@backend:@@" aka Export Snippet is an "object", not "element" thus is should not start paragraph https://orgmode.org/worg/dev/org-syntax.html#Export_Snippets Though... With LaTeX you should be careful >8 One sentence is here. @@html:inline HTML@@ Second sentence. 8< Export to LaTeX: >8 One sentence is here. Second sentence. 8< "@@latex:@@" line in HTML export generates empty line but does not break the paragraph. "#+html:" construct splits paragraphs: One sentence is here. #+html: Second sentence. One sentence is here. Second sentence. I find behavior of HTML exporter more consistent but partially the difference originates in distinct interpretation of empty lines. P.S. There are two types of comments: ones that should be exported as comments and that should be completely removed. "#+latex: %" comments leak to LaTeX, though they will be stripped during generation of PDF. So depending of what format you should provide, such behavior may be acceptable or not.
Re: what would cause failure in template for org capture?
u figured why not learn edebug *now*. so I instrument that method, start the capture, tell edebug to go when it stops in that function, and the capture works. And now it works whether instrumented or not. Hey hum. A total mystery but at least it works. Maybe native compilation has something to do with this? This is me grasping at straws, mind you. I'll update if/when this problem re-asserts itself. Thanks again, eric -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4.6-598-g604bfd : Latest paper written in org: https://arxiv.org/abs/2106.05096
Re: Bug: "DEFINITION NOT FOUND" for footnote in Org manual
Maxim Nikulin writes: > It seems, the footnote was unintentionally lost in the merge commit with a lot > of conflicts due to renumbering in both branches: > > https://code.orgmode.org/bzg/org-mode/commit/9410fbe0606a53b0582cc175b2cc525d556b23fe#diff-6498bd2213e2e527d904942bb214768a1913776L21749 Many thanks for tracking that down! I'm inclined to just add back the text lost in that merge unless you'd recommend anything else. -- Timothy
Re: what would cause failure in template for org capture?
On Wednesday, 21 Jul 2021 at 11:21, Nick Dokos wrote: > FWIW, it's working for me. There was a change on July 8 having to do > with tags completion (using completing-read-multiple), which kind of supports my suspicion that it has to do with selectrum. :-( > I would probably edebug `org-capture-fille-template` and check that the > code around l.1733 in `org-capture.el' behaves as expected. Yet another reason for me to learn edebug finally... I'll see if I can find some time. Thank you, eric -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4.6-598-g604bfd : Latest paper written in org: https://arxiv.org/abs/2106.05096
Re: Comments break up a paragraph when writing one-setence-per-line
On Wednesday, 21 Jul 2021 at 21:48, Maxim Nikulin wrote: > It is at least fragile. HTML export results in separate paragraphs: Yes, I said "if exporting to LaTeX"... ;-) > I am unsure, but "#+latex:" probably belongs to "Keywords" that are > elements, so it should end a paragraph. If such interpretation is > correct than either LaTeX exporter has a bug or syntax description > should be justified. No, I don't think of it as a keyword and it cannot end a paragraph as it would then break any document that uses such constructs. Not sure what to call it but it falls into the same category as inline directives like @@latex:...@@. And, in fact, this would work as well as the first example, again failing for HTML export: --8<---cut here---start->8--- This is the first sentence. @@latex:%@@ this is the second which is commented out. And this is the third. --8<---cut here---end--->8--- Both of these rely on the fact that % is a comment character for LaTeX. For HTML, you would have to something even more ugly, as in: --8<---cut here---start->8--- This is the first sentence. @@html:@@ And this is the third. --8<---cut here---end--->8--- and if you are really masochistic, you could combine the two: --8<---cut here---start->8--- This is the first sentence. @@latex:%html:@@ And this is the third. --8<---cut here---end--->8--- (untested) :-) -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4.6-598-g604bfd : Latest paper written in org: https://arxiv.org/abs/2106.05096
Re: Bug: "DEFINITION NOT FOUND" for footnote in Org manual
On 21/07/2021 17:36, Timothy wrote: At https://orgmode.org/manual/Export-Settings.html#DOCF124 and (renumbered to "fn:123") in doc/org-manual.org, a foot- note is defined as "DEFINITION NOT FOUND": Well that certainly looks dodgy! The original footnote seems to have been added with commit e30aed8f0c62e74633f7a0398340f9bd7bdfa3cc (but personally I don't find that text very helpful). It seems, the footnote was unintentionally lost in the merge commit with a lot of conflicts due to renumbering in both branches: https://code.orgmode.org/bzg/org-mode/commit/9410fbe0606a53b0582cc175b2cc525d556b23fe#diff-6498bd2213e2e527d904942bb214768a1913776L21749
Re: what would cause failure in template for org capture?
Eric S Fraga writes:
> Hello all,
>
> I am getting this error message:
>
> org-capture: Capture abort: Unknown template placeholder: "%^G"
>
> when attempting to capture a task using this template:
>
> #+begin_src emacs-lisp
> (add-to-list 'org-capture-templates
>'("t"
> "todo"
> entry (file+headline "~/s/notes/todo.org" "refile")
> "* %^{Task} %^G\n%i%?\n%U\n"))
> #+end_src
>
> The error happens after having entered the information for the Task in
> the template so next would be the tags.
>
> This was working until recently. Both Emacs and org are up to date
> relative to their git repositories. The only change done recently in my
> configuration is a move from ivy to selectrum for completion.
FWIW, it's working for me. There was a change on July 8 having to do
with tags completion (using completing-read-multiple), but I'm running
with that change and I don't see a problem. OTOH, I'm not using
selectrum (or ivy for that matter), so the change may be interacting
badly with it.
I would probably edebug `org-capture-fille-template` and check that the
code around l.1733 in `org-capture.el' behaves as expected.
--
Nick
"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler
[org-cite] issues with org-cite-make-insert-processor select-style
I have run into a problem in implementing a "select-style" function for an org-cite-insert-processor. The WIP code is here: https://github.com/bdarcus/bibtex-actions/pull/182 It was running correctly yesterday morning, but now it doesn't. I have two related issues: 1. I think, but am not sure, I may have run into a bug in org-cite-make-insert-processor, as the function I am using for the select-style parameter runs correctly outside of the insert processor, and returns the same results as the "org-cite-basic--complete-style" function. But when I uncomment the parameter to use it on the org-cite insert processor, it not only doesn't work correctly, but Emacs won't even load fully. 2. The error I get "wrong type" is so general it literally took me hours to realize it was coming from this function; I was looking elsewhere for the issue. So if I'm right about a bug, obviously it would be great if that could be fixed. But better error handling and reporting would also be really great. Bruce PS - I"m still learning elisp, and so am not super knowledgeable about debugging in general. If anyone has any tips on that, that could help me narrow down the source of the error, that would be much appreciated.
Re: [PATCH] bad table formula recorded in some cases
Hi Thierry, tbanelwebmin writes: > I don't know the intention. But the answer may lie in the comment 4 > lines above: >;; Don't overwrite TBLFM, we might use text properties to >;; store stuff. > > In this case, the intention would be to keep the original "#+TBLFM:" > instead of inserting a fresh new one. > > But we are in the else branch of (if (looking-at ...)), which means > there was no "#+TBLFM:". And no text properties to save. Therefore we > may safely remove this (match-string 2). Thank you for looking into this, I'm reassured by your inference that this change is safe to make. I'm not really one of the main contribution-acceptors/pushers though, so I'd rather leave this for someone like Nicolas to sign off on. Would you mind bumping this thread in a few weeks if nothing happens? Hope that's not too much of an inconvenience, Timothy. > Le 21/07/2021 à 12:50, Timothy a écrit : >> Hi Thierry, >> >> Thanks for this! Looking at the change you suggest, do you know why the >> (match-string 2) bit might have been added in the first place? I'm just >> wondering if there might be some edge-case adversely affected by this --- >> hence trading one bug for another :P >> >> -- >> Timothy >> >> tbanelwebmin writes: >> >>> Small bug, small fix. >>> >>> Suppose we have a table embedded in a begin-end block. >>> >>> #+begin: aaa :param value >>> | a | b | >>> | a | b | >>> #+end: >>> >>> Suppose we want to add a formula, with C-c = >>> We end up with an incorrect result: >>> >>> #+begin: aaa :param value >>> | a | 33 | >>> | a | b | >>> :param value $2=33 >>> #+end: >>> >>> The fix: in org-table.el, line 2177, change >>> (insert (or (match-string 2) "#+TBLFM:"))) >>> to >>> (insert "#+TBLFM:")) >>> >>> Then we get the correct result: >>> >>> #+begin: aaa :param value >>> | a | 33 | >>> | a | b | >>> #+TBLFM: $2=33 >>> #+end: >>> >>> Why? Because (match-string 2) is supposed to refer to the (looking-at) >>> instruction 7 lines above. But (match-string 2) is in the else branch, >>> which means that (looking-at) failed. Therefore (match-string 2) returns >>> garbage. >>> >>> Thanks to Uwe Brauer for pointing to this bug.
Re: Comments break up a paragraph when writing one-setence-per-line
On 19/07/2021 21:03, Eric S Fraga wrote: On Friday, 16 Jul 2021 at 12:06, William Denton wrote: People who write one-sentence-per-line, have you had this problem, and if so how did you handle it? If I will be exporting to LaTeX, I do the following: --8<---cut here---start->8--- One sentence is here. #+latex: % a sentence that has been commented out. The third sentence is here and should be in the same paragraph as the first. --8<---cut here---end--->8--- The LaTeX directive is a LaTeX comment (% at the start) and so replaces what would otherwise be a blank line causing a new paragraph to start. It may not be pretty but it works just fine. It is at least fragile. HTML export results in separate paragraphs: One sentence is here. The third sentence is here and should be in the same paragraph as the first. https://orgmode.org/worg/dev/org-syntax.html#Paragraphs > Empty lines and other elements end paragraphs. I am unsure, but "#+latex:" probably belongs to "Keywords" that are elements, so it should end a paragraph. If such interpretation is correct than either LaTeX exporter has a bug or syntax description should be justified.
Re: [PATCH] bad table formula recorded in some cases
Hi Timothy I don't know the intention. But the answer may lie in the comment 4 lines above: ;; Don't overwrite TBLFM, we might use text properties to ;; store stuff. In this case, the intention would be to keep the original "#+TBLFM:" instead of inserting a fresh new one. But we are in the else branch of (if (looking-at ...)), which means there was no "#+TBLFM:". And no text properties to save. Therefore we may safely remove this (match-string 2). Thanks Timothy for taking this into account so carefully! Best Thierry Le 21/07/2021 à 12:50, Timothy a écrit : > Hi Thierry, > > Thanks for this! Looking at the change you suggest, do you know why the > (match-string 2) bit might have been added in the first place? I'm just > wondering if there might be some edge-case adversely affected by this --- > hence trading one bug for another :P > > -- > Timothy > > tbanelwebmin writes: > >> Small bug, small fix. >> >> Suppose we have a table embedded in a begin-end block. >> >> #+begin: aaa :param value >> | a | b | >> | a | b | >> #+end: >> >> Suppose we want to add a formula, with C-c = >> We end up with an incorrect result: >> >> #+begin: aaa :param value >> | a | 33 | >> | a | b | >> :param value $2=33 >> #+end: >> >> The fix: in org-table.el, line 2177, change >> (insert (or (match-string 2) "#+TBLFM:"))) >> to >> (insert "#+TBLFM:")) >> >> Then we get the correct result: >> >> #+begin: aaa :param value >> | a | 33 | >> | a | b | >> #+TBLFM: $2=33 >> #+end: >> >> Why? Because (match-string 2) is supposed to refer to the (looking-at) >> instruction 7 lines above. But (match-string 2) is in the else branch, >> which means that (looking-at) failed. Therefore (match-string 2) returns >> garbage. >> >> Thanks to Uwe Brauer for pointing to this bug.
Update Schedule for orgmode
Hi, I'm helping a scholar at my institution with his emacs/org-mode installation. As he'll would like to have automatic citations I suggested he should try the new org-cite features, but he does not really want to run the dev version. Is it already predictable when 9.5 will be released? IIUC, the new citation features will be part of 9.5, right? Best, Denis
what would cause failure in template for org capture?
Hello all,
I am getting this error message:
org-capture: Capture abort: Unknown template placeholder: "%^G"
when attempting to capture a task using this template:
#+begin_src emacs-lisp
(add-to-list 'org-capture-templates
'("t"
"todo"
entry (file+headline "~/s/notes/todo.org" "refile")
"* %^{Task} %^G\n%i%?\n%U\n"))
#+end_src
The error happens after having entered the information for the Task in
the template so next would be the tags.
This was working until recently. Both Emacs and org are up to date
relative to their git repositories. The only change done recently in my
configuration is a move from ivy to selectrum for completion.
--
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.6-598-g604bfd
: Latest paper written in org: https://arxiv.org/abs/2106.05096
Re: [PATCH] bad table formula recorded in some cases
Hi Thierry, Thanks for this! Looking at the change you suggest, do you know why the (match-string 2) bit might have been added in the first place? I'm just wondering if there might be some edge-case adversely affected by this --- hence trading one bug for another :P -- Timothy tbanelwebmin writes: > Small bug, small fix. > > Suppose we have a table embedded in a begin-end block. > > #+begin: aaa :param value > | a | b | > | a | b | > #+end: > > Suppose we want to add a formula, with C-c = > We end up with an incorrect result: > > #+begin: aaa :param value > | a | 33 | > | a | b | > :param value $2=33 > #+end: > > The fix: in org-table.el, line 2177, change > (insert (or (match-string 2) "#+TBLFM:"))) > to > (insert "#+TBLFM:")) > > Then we get the correct result: > > #+begin: aaa :param value > | a | 33 | > | a | b | > #+TBLFM: $2=33 > #+end: > > Why? Because (match-string 2) is supposed to refer to the (looking-at) > instruction 7 lines above. But (match-string 2) is in the else branch, > which means that (looking-at) failed. Therefore (match-string 2) returns > garbage. > > Thanks to Uwe Brauer for pointing to this bug.
Re: Bug: "DEFINITION NOT FOUND" for footnote in Org manual
Hi Tim, > At https://orgmode.org/manual/Export-Settings.html#DOCF124 > and (renumbered to "fn:123") in doc/org-manual.org, a foot- > note is defined as "DEFINITION NOT FOUND": Well that certainly looks dodgy! > The original footnote seems to have been added with commit > e30aed8f0c62e74633f7a0398340f9bd7bdfa3cc (but personally I > don't find that text very helpful). Do you think it would be more appropriate to update or remove the footnote? -- Timothy
