Re: Bug: Can’t assign to hline relative reference
This seems to be related to: https://emacs.stackexchange.com/questions/15185/cant-assign-to-hline-relative-reference There seem to be restrictions regarding hline-relative-references within table-formulas. If change 'I' and 'II' for 1 and 2 on the very left of the formula, it works (keeping the other hline-relative parts) . If I stay with the former I get the same error as you (emacs 26.1, orgmode 9.1.9, Debian stable). I hope this can help, Daniel Am 21. Oktober 2020 03:14:10 MESZ schrieb Dante Catalfamo : >Hello, > >I'm trying to create a table where the third column between two hlines >is set by a formula referencing the second column. > >Here is an example: > >| a | b | c | >|---+---+| >| row 1 | 12.00 | 144.00 | >| row 2 | | 23.00 | >|---+---+| >| sum | 12.00 | 167.00 | >#+TBLFM: @I$3..II$3=if($2 != 0, 12*$2, >$3);%.2f::@4$2=vsum(@I..II);%.2f::@4$3=vsum(@I..II);%.2f > >When I try to calculate this table however, I get the error "Can’t >assign to hline relative reference". > >Why is this now allowed? This seems like a fairly mundane use of a >table to me. It is explicitly disabled in the source, but without >explanation, and searching the mailing list doesn't turn up many >answers. > >Is there a recommended way to handle a situation like this? > >Could this feature be fixed? > >Thank you, >Dante -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
Re: [O] source-block 'uncomment-region' comments out a second time
M-; is definitely what I've been searching for! Thanks for the advice, Daniel "Berry, Charles" writes: > My bad. See inline. > >> On Apr 24, 2019, at 8:45 AM, Daniel Herzig wrote: >> >> Hi! >> >> "Berry, Charles" writes: >> >>>> On Apr 22, 2019, at 3:49 AM, Daniel Herzig >>>> wrote: >>>> >>>> I found a minor problem when editing source code blocks. I am on >>>> Org-Mode 8.2.10 that comes with Emacs 25.1.1 on Debian. >>> >>> With more modern versions (9.2.3, for example), the behavior you describe >>> does not occur. >>> > > > I should have said M-; behaves as you would expect. > > But it runs `org-comment-dwim' when in an org-mode buffer. > > Outside of org-mode it runs `comment-dwim' which calls on > `(un)comment-region'. > > >>> viz., (un)commenting is language aware in the org buffer (as well as in the >>> edit buffer). >>> >>> HTH, >>> >>> Chuck >> >> Thanks for your hint. >> >> I just upgraded to 9.2.3 through org/elpa -- but the situation seems to have >> gotten even worse in my case. Not only (un)comment-region in a >> source-code block of the main .org-file (not inside the edit-buffer) still >> do the >> same thing (commenting *OUT*) -- now the commands even comment out the >> first part of the next line after the marked region, resulting in >> tearing this line apart. >> > > Right. I confirm this. > > So the advice is to use `org-comment-dwim' (which silently does `comment-dim' > in an edit buffer). > > HTH, > > Chuck
Re: [O] source-block 'uncomment-region' comments out a second time
Hi! "Berry, Charles" writes: >> On Apr 22, 2019, at 3:49 AM, Daniel Herzig wrote: >> >> I found a minor problem when editing source code blocks. I am on >> Org-Mode 8.2.10 that comes with Emacs 25.1.1 on Debian. > > With more modern versions (9.2.3, for example), the behavior you describe > does not occur. > > viz., (un)commenting is language aware in the org buffer (as well as in the > edit buffer). > > HTH, > > Chuck Thanks for your hint. I just upgraded to 9.2.3 through org/elpa -- but the situation seems to have gotten even worse in my case. Not only (un)comment-region in a source-code block of the main .org-file (not inside the edit-buffer) still do the same thing (commenting *OUT*) -- now the commands even comment out the first part of the next line after the marked region, resulting in tearing this line apart. Anyway, I'll stick with the new version, as code-highlighting is way better than in 8.2.10 (and keep un/commenting a thing for the edit-buffer solely). Cheers, Daniel
[O] source-block 'uncomment-region' comments out a second time
Hi all! I found a minor problem when editing source code blocks. I am on Org-Mode 8.2.10 that comes with Emacs 25.1.1 on Debian. My source code block looks something like: #+BEGIN_SRC sh :shebang abc :tangle xyz do this do that and that #+END_SRC If I enter the block with C-c ' and comment out a region like: do this do that with M-x comment-region, everything works as expected, i.e.: # do this # do that From outside the source-code editor it looks like this now (indentation ignored): #+BEGIN_SRC sh :shebang abc :tangle xyz # do this # do that and that #+END_SRC Sometimes I like to make changes to the code without entering the block with C-c ' -- but if I mark: # do this # do that from outside and hit M-x uncomment-region, my source-code block turns into this: #+BEGIN_SRC sh :shebang abc :tangle xyz # # do this # # do that and that #+END_SRC I just tried -- it does not make a difference which command I use on the region (comment-region or uncomment-region) from outside, it will comment out as often as I use one of them (IF I just tried 3 levels). Inside the C-c ' environment everything is top and working as expected. It's clear that this kind of workflow is not intended, and I usually work inside C-c ' for obvious reasions. I just pointing at it, as in this case 'comment-region' and 'uncomment-region' seem to do the same, which is somewhat unexpected. Best regards, Daniel
Re: [O] passing string to sh source code block
Sorry, I found my mistake. I'll post it anyway, maybe it's of use to someone. My path contains spaces, so I had to change the code a bit (see below). Daniel Herzig writes: > Hi! > > I am trying to pass a path to an org-source-codeblock using the :var tag > in the header: > > #+BEGIN_SRC sh :var directory="/x/y/z" > cd directory > ls > #+END_SRC #+BEGIN_SRC sh :var directory="/x/y/z" cd "$directory" ls #+END_SRC Like this it works as needed. > The output of the ls command shows that I obviously stay in the location > of my .org file (not "/x/y/z") -- is there a way to pass the path to the > source > codeblock, without having to enter the path inside the block? > > Any hint appreciated, thanks in advance, > > cheers, > Daniel
[O] passing string to sh source code block
Hi! I am trying to pass a path to an org-source-codeblock using the :var tag in the header: #+BEGIN_SRC sh :var directory="/x/y/z" cd directory ls #+END_SRC The output of the ls command shows that I obviously stay in the location of my .org file (not "/x/y/z") -- is there a way to pass the path to the source codeblock, without having to enter the path inside the block? Any hint appreciated, thanks in advance, cheers, Daniel
Re: [O] org-sbe: error when passing strings as parameters to/from Python blocks
Karl Voit writes: > Hi! Hi! > > I want to test/use Python with org-sbe: > > #+NAME: classificationfm > #+BEGIN_SRC python :exports none :var prob :var impact > > result = "" > if prob == 'high' and impact == 'high': > return 'A' > if prob == 'low' and impact == 'high': > return 'B' > if prob == 'high' and impact == 'low': > return 'C' > if prob == 'low' and impact == 'low': > return 'D' > return 'undefined' > #+END_SRC > After some trying I found that the variables as set in the source-code header need standard values set: #+NAME: classificationfm #+BEGIN_SRC python :var prob="high" :var impact="high" if prob == "high" and impact == "high": return "A" if prob == "low" and impact == "high": return "B" if prob == "high" and impact == "low": return "C" if prob == "low" and impact == "low": return "D" #+END_SRC If I don't set them I get exactly the same errors as you. Like this I get the following: | prob | impact | class | |--++---| | high | high | A | | low | high | B | | high | low| C | | low | low| D | #+TBLFM: @2$3..@>$3='(org-sbe classificationfm (prob $$1) (impact $$2)) Evaluation is being asked for each line then. > (Yes, I should move to elif and the Python code might be coded with > less characters in general: this should not be the point here ;-) ) > > | prob | impact | class | > |--++| > | high | high | #ERROR | > | low | high | #ERROR | > | high | low| #ERROR | > | low | low| #ERROR | > > #+TBLFM: @2$3..@>$3='(org-sbe "classificationfm" (prob $1) (impact $2)) > > I'd expect to get the values of the "class" table column: A, B, C, D > instead of #ERROR. > > > Reading the manual, I found: > | NOTE: By default, string variable names are interpreted as > | references to source-code blocks, to force interpretation of a > | cell’s value as a string, prefix the identifier a "$" (e.g.,"$$2" > | instead of "$2" or "$@2$2" instead of "@2$2"). > > Therefore, I tried the following lines ... > > #+TBLFM: @2$3..@>$3='(org-sbe "classificationfm" (prob "$1") (impact "$2")) > #+TBLFM: @2$3..@>$3='(org-sbe "classificationfm" (prob $$1) (impact $$2)) > > #+TBLFM: @2$3..@>$3='(org-sbe "classificationfm" (prob "$$1") (impact "$$2")) > ... all with same error in the result. > > > My setup: Org mode version 9.1.6 on GNU Emacs 26.0.90 and GNU Emacs 25.1.1 > > > I started a reddit thread[1]. In this thread, somebody was posting > this table showing the error: > > #+NAME: myfunc > #+BEGIN_SRC python :var n="1" > > return "ok" > #+END_SRC > > | 10.3 | 9 | -18 | a | 14 | 11 | 1 | > | ok | ok | ok | #ERROR | ok | ok | ok | > > #+TBLFM: @2='(org-sbe myfunc (n @1)) > > > However, using the comment from the manual about strings, I > prepended the reference with "$" ... > > | 10.3 | 9 | -18 | a | 14 | 11 | 1 | > | ok | ok | ok | ok | ok | ok | ok | > > #+TBLFM: @2='(org-sbe mytestfunc (n $@1)) > > ... which now looks OK ;-) > > > So, back to the initial situation: what is my error or do we have a > bug in Org? > > > [1] > https://www.reddit.com/r/orgmode/comments/b0ll1v/embedding_python_code_in_table_formula/ I hope this helps, I'm on orgmode 8.2.1 here. Cheers, Daniel
Re: [O] org-export links to html
Perfect, thank you! Daniel Nicolas Goaziou writes: > Hello, > > Daniel Herzig writes: > >> I'm facing an interesting issue here (emacs 25.1 & orgmode 8.2.10) when >> exporting an org-file to html. >> >> In my file there is a link to the original org-file itself (the one I'm >> working on), written as 'file:/x/y/file.org'. When exporting to .pdf, >> .odt, or text, >> it correctly expands to 'file:///x/y/file.org', but when I export it to >> .html, the link expands as 'file:///x/y/file.html'. >> >> Does anyone have a hint, how to avoid this behaviour? > > See `org-html-link-org-files-as-html'. > > Regards,
[O] org-export links to html
Hi! I'm facing an interesting issue here (emacs 25.1 & orgmode 8.2.10) when exporting an org-file to html. In my file there is a link to the original org-file itself (the one I'm working on), written as 'file:/x/y/file.org'. When exporting to .pdf, .odt, or text, it correctly expands to 'file:///x/y/file.org', but when I export it to .html, the link expands as 'file:///x/y/file.html'. Does anyone have a hint, how to avoid this behaviour? Thanks, Daniel
