Re: Org table: emphasizing calculated cell

[Jarmo Hurri]

Greetings Norwid.

Norwid Behrnd  writes:

> Let's use your idea to use /multiple table formulae/.  Contrasting to
> your attempt, I don't mind to go the extra mile and to run a cheap
> computation twice for a result already in hand.  As a MWE 
>
> ```
> | quantity  |  value |
> | A |  1 |
> | B |  3 |
> | ratio A/B | *0.33* |
> | ratio + 1 |   1.33 |
>
> #+TBLFM: @4$2 = @2/@3; *%.2f* :: @5$2 = @2/@3 + 1; %.2f
> ```

Thanks, that is indeed a working approach. As you suspected, I would go
an extra mile or ten to avoid repeating formulae. ;)

Have fun and stay safe,

Jarmo

Re: Org table: emphasizing calculated cell

[Jarmo Hurri]

Nick Dokos  writes:

> Jarmo Hurri  writes:
>> This solution seems to change the contents of a cell, not only its
>> formatting. So the following, where I try to increase the value of "C"
>> by one, leads to an error:
>>
>> ```
>> | quantity | value  |
>> |--+|
>> | A| 1  |
>> | B| 3  |
>> |--+|
>> | *C*  | *0.33* |
>> | D| #ERROR |
>>
>> #+TBLFM: @4$2=@-2/@-1; *%.2f*::@5$2=@-1+1
>> ```
>>
>> I wonder if there is a way around this effect?
>
> The error here is that `*0.33*' is no longer a string that can be
> converted to a number, so the calculator barfs.

Yes, that is obvious. The underlying question is whether it is possible
to cleanly separate presentation from contents. Here they are mixed.

All the best,

Jarmo

Re: Org table: emphasizing calculated cell

[Samuel Wales]

out of curiosity, do common spreadsheets implement the feature of
distinguishing calculated results from entered values?  i find myself
wanting that too, but don't know if that desire is unusual.


On 8/27/21, Nick Dokos  wrote:
> Jarmo Hurri  writes:
>
>> Greetings Norwid.
>>
>> Norwid Behrnd  writes:
>>
>>> try extending the format of the table formula with asterisks, i.e.
>>>
>>> ```
>>> | quantity |  value |
>>> |--+|
>>> | A|  1 |
>>> | B|  3 |
>>> |--+|
>>> | *C*  | *0.33* |
>>>
>>> #+TBLFM:  @4$2=@-2/@-1; *%.2f*
>>> ```
>>>
>>> Subsequently, issue the call ```C-c *``` for an update while the
>>> cursor is within the table.  This approach works well enough for me
>>> (equally for emphasis with enclosing forward slashes, or underscores)
>>> in Emacs' native display (backed by elpa-org 9.4.0) as well as for a
>>> subsequent export into .html and display (e.g., in Firefox), or .tex.
>>
>> Excellent, this is a working solution for the basic case. Much
>> appreciated!
>>
>> This solution seems to change the contents of a cell, not only its
>> formatting. So the following, where I try to increase the value of "C"
>> by one, leads to an error:
>>
>> ```
>> | quantity | value  |
>> |--+|
>> | A| 1  |
>> | B| 3  |
>> |--+|
>> | *C*  | *0.33* |
>> | D| #ERROR |
>>
>> #+TBLFM: @4$2=@-2/@-1; *%.2f*::@5$2=@-1+1
>> ```
>>
>> I wonder if there is a way around this effect?
>>
>
> The error here is that `*0.33*' is no longer a string that can be converted
> to a number,
> so the calculator barfs.
>
> TUrn on formula debugging with `C-c {' and try evaluating it.
>
> --
> Nick
>
> "There are only two hard problems in computer science: cache
> invalidation, naming things, and off-by-one errors." -Martin Fowler
>
>
>


-- 
The Kafka Pandemic

Please learn what misopathy is.
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html

Re: Org table: emphasizing calculated cell

[Nick Dokos]

Jarmo Hurri  writes:

> Greetings Norwid.
>
> Norwid Behrnd  writes:
>
>> try extending the format of the table formula with asterisks, i.e.
>>
>> ```
>> | quantity |  value |
>> |--+|
>> | A|  1 |
>> | B|  3 |
>> |--+|
>> | *C*  | *0.33* |
>>
>> #+TBLFM:  @4$2=@-2/@-1; *%.2f*
>> ```
>>
>> Subsequently, issue the call ```C-c *``` for an update while the
>> cursor is within the table.  This approach works well enough for me
>> (equally for emphasis with enclosing forward slashes, or underscores)
>> in Emacs' native display (backed by elpa-org 9.4.0) as well as for a
>> subsequent export into .html and display (e.g., in Firefox), or .tex.
>
> Excellent, this is a working solution for the basic case. Much
> appreciated!
>
> This solution seems to change the contents of a cell, not only its
> formatting. So the following, where I try to increase the value of "C"
> by one, leads to an error:
>
> ```
> | quantity | value  |
> |--+|
> | A| 1  |
> | B| 3  |
> |--+|
> | *C*  | *0.33* |
> | D| #ERROR |
>
> #+TBLFM: @4$2=@-2/@-1; *%.2f*::@5$2=@-1+1
> ```
>
> I wonder if there is a way around this effect?
>

The error here is that `*0.33*' is no longer a string that can be converted to 
a number,
so the calculator barfs.

TUrn on formula debugging with `C-c {' and try evaluating it.

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: ob-lilypond.el doesn't generate midi files

[Nick Dokos]

Michael Maurer  writes:

> On Thu, 26 Aug 2021 at 21:54, Nick Dokos  wrote:

>>
>> Michael Maurer  writes:
>>
>> > On Thu, 26 Aug 2021 at 15:03, Jonathan Gregory  wrote:
>> >>
>> >> Hi
>> >>
>> >> On 26 Aug 2021, Michael Maurer wrote:
>> >>
>> >> > I've installed lilypond and customized ob-lilypond to use the
>> >> > appropriate helper programs, but although it generates & shows
>> >> > pdfs just fine, generating a midi file it does not. I execute
>> >> > tangle on the codeblock, and all I get is "No midi file
>> >> > generated so can't play!". org-version 9.4.6 emacs 27.2 Win 10
>> >>
>> >> Can you also send a MWE of the code you're using to generate the
>> >> score?
>> >>
>> >
>> > I used a test file I copied over from Frescobaldi
>> >
>> > #+begin_src lilypond :file test.pdf
>> > \version "2.18.2"
>> > \score {
>> > \drums {
>> >   \time 2/4
>> >   sn16 sn8 sn16 sn8 sn8:32 ~
>> >   sn8 sn8 sn4:32 ~
>> >   sn4 sn8 sn16 sn16
>> >   sn4 r4
>> > }
>> >   \layout { }
>> >   \midi { }
>> > }
>> > #+end_src
>> >
>> > In Frescobaldi this gets me both midi-output and pdf. In Emacs with
>> > org it does say "Midi output to test.midi", but then there's that "no
>> > midi file generated" message.
>> >
>>
>> What happens if you save the contents of the source block into a file
>> and run lilypond on the file from the command line?
>>
>
> Both pdf and midi files get generated. Btw, ob-lilypond does generate
> the midi file as well, it just doesn't want to play it/recognize it.
> Maybe it's related to what helper app I've configured to open it? (but
> why that doesn't make sense, it's vlc btw).
>
>

Oh, I thought that it did not generate a midi file at all. So you are
saying that the midi file *is* produced and you *can* play it from the
command line with vlc, correct?

If that's the case, check the value of the variable
`org-babel-lilypond-midi-command' and see what happens when you invoke
that command on the midi file. In my case, the command is `xdg-open'
(I'm using Gnome on Fedora 33) and it opens Banshee to play it which
fails because of missing codecs. I installed the missing codecs and
`xdg-open foo.midi' sends the file to Banshee which can play it fine.

Also check if `org-babel-lilypond-arrange-mode' is t or nil: behavior
is very different depending on that.

Final thought: `xdg-open' starts whatever app it is supposed to run
in the background and returns immediately. That may cause problems with
babel. I still don't get anything when processing the file in babel.

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: Bug: Unintended column added to table [9.4.6 (9.4.6-gab9f2a @ /home/user/.emacs.d/elpa/org-9.4.6/)]

[Ihor Radchenko]

spect...@mail.com writes:

> In a preexisting org table, hitting  can add a new, unintended column
>
> Bug: After the 2nd iteration, org adds a unintended new column. Further 
> iteration adds more columns.

Confirmed

The problem appears somewhere inside org-table-justify-field-maybe

Best,
Ihor

Re: ob-lilypond.el doesn't generate midi files

[Michael Maurer]

On Thu, 26 Aug 2021 at 21:54, Nick Dokos  wrote:
>
> Michael Maurer  writes:
>
> > On Thu, 26 Aug 2021 at 15:03, Jonathan Gregory  wrote:
> >>
> >> Hi
> >>
> >> On 26 Aug 2021, Michael Maurer wrote:
> >>
> >> > I've installed lilypond and customized ob-lilypond to use the
> >> > appropriate helper programs, but although it generates & shows
> >> > pdfs just fine, generating a midi file it does not. I execute
> >> > tangle on the codeblock, and all I get is "No midi file
> >> > generated so can't play!". org-version 9.4.6 emacs 27.2 Win 10
> >>
> >> Can you also send a MWE of the code you're using to generate the
> >> score?
> >>
> >
> > I used a test file I copied over from Frescobaldi
> >
> > #+begin_src lilypond :file test.pdf
> > \version "2.18.2"
> > \score {
> > \drums {
> >   \time 2/4
> >   sn16 sn8 sn16 sn8 sn8:32 ~
> >   sn8 sn8 sn4:32 ~
> >   sn4 sn8 sn16 sn16
> >   sn4 r4
> > }
> >   \layout { }
> >   \midi { }
> > }
> > #+end_src
> >
> > In Frescobaldi this gets me both midi-output and pdf. In Emacs with
> > org it does say "Midi output to test.midi", but then there's that "no
> > midi file generated" message.
> >
>
> What happens if you save the contents of the source block into a file
> and run lilypond on the file from the command line?
>

Both pdf and midi files get generated. Btw, ob-lilypond does generate
the midi file as well, it just doesn't want to play it/recognize it.
Maybe it's related to what helper app I've configured to open it? (but
why that doesn't make sense, it's vlc btw).

Re: pygments support

[Juan Manuel Macías]

Hi Yuchen,

I only know this one, but haven't tried it:

https://github.com/or/pygments-orgmode-lexer

Best regards,

Juan Manuel

Yuchen Pei writes:

> Hello,
>
> I was playing with my cgit setup when I noticed that pygments does not
> support org mode syntax highlighting[1].
>
> Just wondering if anyone has worked on it, or if there's any
> "unofficial" org mode component (lexer?), before I go ahead and 
> try to write my own.
>
> [1]: https://pygments.org/languages/

pygments support

[Yuchen Pei]

Hello,

I was playing with my cgit setup when I noticed that pygments does 
not support org mode syntax highlighting[1].


Just wondering if anyone has worked on it, or if there's any 
"unofficial" org mode component (lexer?), before I go ahead and 
try to write my own.


[1]: https://pygments.org/languages/

--
Best,
Yuchen

PGP Key: 47F9 D050 1E11 8879 9040  4941 2126 7E93 EF86 DFD0
  


signature.asc
Description: PGP signature

Re: how to get multi-line author in ODT export?

[Eric S Fraga]

Juan Manuel,

thank you very much.  This is both very useful and ever so simple!  I
did have to set org-export-allow-bind-keywords for this to work (in case
others wonder why nothing seems to happen ;-)).

Thanks again,
eric

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.6-628-g366444
: Latest paper written in org: https://arxiv.org/abs/2106.05096

Re: bug#48199: 28.0.50; [POSSIBLY SOLVED] Org mode surprisingly usurps Calendar key binding

[tomas]

On Fri, Aug 27, 2021 at 08:42:22AM +0200, tomas wrote:
> On Fri, Aug 27, 2021 at 05:37:40AM +0200, Lars Ingebrigtsen wrote:

[...]

> > I can't reproduce this with "emacs -Q", or after visiting etc/ORG-NEWS,
> > with the current Emacs trunk.
> 
> FWIW, I've seen that problem too, but it seems fixed now (I'm running
> currently commit fba64e1697174369b87e3de0c189a0fb0963c49c).

It seems the Org folks have already taken care of it. And myself (blush)
was somehow involved in that [1].

Cheers

[1] https://lists.gnu.org/archive/html/emacs-orgmode/2021-06/msg00458.html

 - t


signature.asc
Description: Digital signature

Bug: Refiling insert extra spaces at beginning of inline-tasks headlines [9.4.6 (9.4.6-12-gdcc3a8-elpaplus @ ~/.config/emacs/elpa/org-plus-contrib-20210823/)]

[Vincent Chouraki]

Hello everyone,

When refiling a headline that contains an inlinetask, extra spaces are 
inserted between the beginning of line and the inlinetask headline. The 
number of spaces inserted seems to depend on the difference in depths 
between the current and "refiled" depth of the headline.


For example, starting from :

# BEGIN EXAMPLE

* Notes
** Notes from meeting 1
* Notes from meeting 2
*** TODO do this
*** END

# END EXAMPLE

Refiling to "* Notes" should results in

# BEGIN EXAMPLE

* Notes
** Notes from meeting 1
** Notes from meeting 2
*** TODO do this
*** END

# END EXAMPLE

But results instead in

# BEGIN EXAMPLE

* Notes
** Notes from meeting 1
** Notes from meeting 2
 *** TODO do this
 *** END

# END EXAMPLE

Best regards,

Vincent

Emacs  : GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 
3.22.30, cairo version 1.15.10)

 of 2021-08-26
Package: Org mode version 9.4.6 (9.4.6-12-gdcc3a8-elpaplus @ 
~/.config/emacs/elpa/org-plus-contrib-20210823/)

bug#48199: 28.0.50; Org mode surprisingly usurps Calendar key binding

[Yuchen Pei]

Lars Ingebrigtsen  writes:


Yuchen Pei  writes:

This bug seems to be still around, as it just happened to 
me. Steps

to
reproduce:

- Build a recent version e.g. commit efaed29f3d with `make`
- ./src/emacs
- M-x calendar RET
- i

results in "command-execute: Wrong type argument: commandp,
org-agenda-diary-entry".  Can anyone else reproduce it?


I can't reproduce this with "emacs -Q", or after visiting 
etc/ORG-NEWS,

with the current Emacs trunk.


You are right.  I add `-Q` to the emacs invocation and the problem 
is gone.  I'm gonna try to re-archive this bug.


--
Best,
Yuchen

PGP Key: 47F9 D050 1E11 8879 9040  4941 2126 7E93 EF86 DFD0
  


signature.asc
Description: PGP signature

bug#48199: 28.0.50; Org mode surprisingly usurps Calendar key binding

[Yuchen Pei]

Looks like this email hadn't go through before I unarchived the 
bug.  Apologies for any duplicate messages.

Yuchen Pei  writes:

This bug seems to be still around, as it just happened to 
me. Steps to

reproduce:

- Build a recent version e.g. commit efaed29f3d with `make`
- ./src/emacs
- M-x calendar RET
- i

results in "command-execute: Wrong type argument: commandp,
org-agenda-diary-entry".  Can anyone else reproduce it?



--
Best,
Yuchen

PGP Key: 47F9 D050 1E11 8879 9040  4941 2126 7E93 EF86 DFD0
  


signature.asc
Description: PGP signature

Re: bug#48199: 28.0.50; Org mode surprisingly usurps Calendar key binding

[tomas]

On Fri, Aug 27, 2021 at 05:37:40AM +0200, Lars Ingebrigtsen wrote:
> Yuchen Pei  writes:
> 
> >> This bug seems to be still around, as it just happened to me. Steps
> >> to
> >> reproduce:
> >>
> >> - Build a recent version e.g. commit efaed29f3d with `make`
> >> - ./src/emacs
> >> - M-x calendar RET
> >> - i
> >>
> >> results in "command-execute: Wrong type argument: commandp,
> >> org-agenda-diary-entry".  Can anyone else reproduce it?
> 
> I can't reproduce this with "emacs -Q", or after visiting etc/ORG-NEWS,
> with the current Emacs trunk.

FWIW, I've seen that problem too, but it seems fixed now (I'm running
currently commit fba64e1697174369b87e3de0c189a0fb0963c49c).

Cheers
 - t


signature.asc
Description: Digital signature