call `literate-calc-mode' again after enable it will cause this error
This small patch fix it.

@@ -287,7 +287,8 @@ The exact timeout is determined by `literate-calc-mode-idle-time'."
 
 (defun literate-calc--exit ()
   "Clean up hooks & overlays."
-  (cancel-timer literate-calc--idle-timer)
+  (when literate-calc--idle-timer
+	(cancel-timer literate-calc--idle-timer))
   (remove-hook 'after-change-functions #'literate-calc--async-eval-buffer t)
   (literate-calc-clear-overlays))

Hi,

Nice package.

Here is a function you might want to include :

(defun literate-calc-mode-inhibit-in-latex ()
  "Return non-nil if point is in a latex fragment or environment."
  (and (derived-mode-p #'org-mode)
       (memq (org-element-type (org-element-context))
             '(latex-fragment latex-environment))))

Otherwise, literate-calc-minor-mode interacts with latex fragments and environments.

Also, could it be possible to add a literate-calc-eval-region interactive function ?

Regards

I'm trying to package this for guix but guix won't let me package this if it throws a warning during byte compiling.

The warning is this:

In literate-calc-insert-results:
literate-calc-mode.el:171:29:Warning: reference to free variable
    ‘literate-calc-minor-mode’

Moving the definition of literate-calc-minor-mode above this line makes the warning go away.

This is on Emacs 26.3 if that makes an difference.

This package is the coolest! Ever since hearing about a mac app Soulver, I've yearned for a free literate calculator for linux. So thank you for having the vision of combining the powerhouse that is calc and making a well-working implementation. :)

I immediately made this helper function to have quick access to a quick scribble when needed.

  (defun pop-calculator ()
    (interactive)
    (switch-to-buffer (get-buffer-create "*literate-calc*"))
    (literate-calc-mode))

But now to the question. Please keep in mind that I am not a calc expert so I am partly thinking about a feature request but also like to hear about what calc the backend can do here without any further development.

I like making lists and summing them up. Traditionally a job for org tables or perhaps the ses-mode, I like the fluency of a list within free text.

But understandably we don't have a multiline support so we're left with these approaches:

a = 10 => a: 10
a = a + 10 => a: 20
a = a + 20 => a: 40

b = [1 2 4] => b: [1, 2, 4]

= a => 40
= vsum(b) => 7

Perhaps I just don't necessarily like the repeated use of the variable name. += would be an obvious idea to consider. I thought about other kinds of multiline supports for vectors but inline comments are valuable to me and now things would definitely get too complex and unpredictable.

Maybe the purpose of this ticket is just to say thanks for a great library.

I think it would be useful to compare this mode with embedded calc mode, in the README and perhaps explain why you would use this instead. I think one obvious difference might be support for spaces in variable names.

(calc) Embedded Mode

Here is a list of use cases loosely related to exporting.

• Copying the result of a calculation
• Showing how a result was computed to other people that do not have literate-calc-mode. Two possible export methods:
  • Sharing the literate-calc-mode file with the results
  • Putting the literate-calc-mode file with the results in the clipboard
• Surround computation by more context written in an existing format, like markdown or org-mode

If I try to export an org source code block with literate-calc-mode and I happen to have a variable in it, I get an lisp error during htmlization.

For example, if I export this org file

#+begin_src literate-calc
Pi = 3.14159
#+end_src

I get:

Lisp error: (args-out-of-range "Pi " 0 12)

Btw. I was able to workaround this by setting literate-calc-font-lock-defaults to nil:

# -*- literate-calc-font-lock-defaults: nil -*-
#+begin_src literate-calc
Pi = 3.14159
#+end_src

Like this:

Multiplication and division have the same calculation priotiry, so it should gives 16 even without explicit parentheses, but it seems multiplications are calculated first then the division...

This is an amazing package, thank you for the great idea and implementation. For readability, I think it would be great if the package showed the result with thousand separator. Would you consider this improvement?

Thank you

I truly love this little thing. I wanted it to hook with org-mode so I added this little hook.
(add-hook 'org-mode-hook 'literate-calc-minor-mode) but this causes org-mode buffer files to be extremely lagging. In fact, it is lagging each time I enabled the minor-mode. Anyone else experiencing this issue? Is this expected?

Thanks for this great work.

Hi,

Sometimes when doing binary arithmetic, it is useful to be able to see the output formatted in different bases, such as base 16 or base 2.

I have implemented this feature into literate-calc-mode locally, and I was wondering if you would be open to such a feature. If so, I can make a PR!

Summary:

• New custom literate-calc-mode-radix with a default value of 10
  • This value is passed into calc-eval for the option calc-number-radix
• New interactive function literate-calc-set-radix, which sets the radix of the current buffer and reruns 'literate-calc--async-eval-buffer

Example with radix set to 2:

Example with radix set to 16

Potential Problem

Sometimes, when writing a literate-calc-mode file, I want to have the computer do a quick calculation for me. That calculation is not to stay in the final document.

pizzaPrice = 10 euros
deliveryPrice = 2 euros

pizzaPrice + (deliveryPrice / 3)

That last line would be an example of this "quick calculation". Problem: the program doesn't display the result of this line. I need to assign the result of this calculation to a temporary variable in order to get the result (before immediately deleting it).

Possible solutions

• Display the result for any calculation in the file
• Display the result any line that ends with a specific set of character, for instance "=>"

Hi,

tried to calculate the Greatest Common Divisor of two integers, and noticed this:

when I remove the comment from the third line:

seems to be some parsing bug, can you please confirm?

Hey there!

I'm using this with org mode and I'd like to avoid matching lines that are in certain illegal contexts, like org source blocks. It's easy to hack around this with advice but it would be nice to add an extension point.

What do you think about adding a custom hook that gets called for each line to test whether to inhibit evaluation? You could ship with a default implementation too, which would improve the out-of-the-box experience. Happy to whip up a PR to sketch this out.

I was attempting to create a polymode for literate-calc so I can embed it into any mode without having to use the minor mode and without the "session" leaking across.

I ran into some issues and posted in the Polymode github: polymode/polymode#313, in case you have any insight into how I can do this.

First off, thank you soooooo much for making this!!

I was a huge user of Calca previously and basically, this if you hadn't have built this I would have had to myself. I've been testing the minor mode today and love it. I am taking a look at your code later to figure out how you did it. =] This rocks. (only tried it with my old markdown Calca files so far. Also, supporting most of the features in Calca would be baller if you need some extra roadmap ideas.)

One thing that would be amazing in order to support more ordered, thoughtful files would be to support the => as an trigger on calculaton on the last previous variable you've defined a formula for (ie the last thing_to_calculate = this + that.+ other things) even if it spans multiple lines.).
Eg.

Food            = 150 * Months * Days
                => 36,000 (derived from literate-calc package)

instead of

Food            = 150 * Months * Days => Food: 36,000. (derived)

I'd also suggest that that would also work better than having every line provide a solution to each declaration (right now I have lines that look like this:

Months         		= 8. => Months: 8
Days			= 30 => Days: 30
Working Days	        = 20 => Working Days: 20

from ol Calca formulas.

But just wanted to say thank you so much for your work on this. I had this as a project I really needed to get to towards the end of the year, so am ecstatic someone has beat me to it. \o/

Variable names that are sub-strings of functions destroy the functions.

= abs(-2)
ab = 3
= abs(-2)

I'd suggest an option to disable the short writing that omits the * character.

I'm not sure if the setting should be enabled or disabled by default:

• default omitting enabled: formulas omiting the char don't work as expected any more, but the error is obvious and easily fixed by adding the `*-
• default omitting disabled: formulas work, but functions fail in odd looking ways. Harder to "debug" as a user.

Anyways, no critical bug. It's easily detected and worked around.

On emacs 28 (if that matters) the literate-calc-remove-results command does not work on results containing negative numbers like = 1 - 2 => -1.

Could it work with lists?
For example:

- a = 10
- b = 20
- = a+b

Thanks for your nice package.

fb39084 introduced a fix for #15 but seems to have broken the package by being too restrictive in what variable name we can use.

Example test that fails (after the fix but worked before) to show the issue:

;; FAIL (seems to be because of year in the name)
(ert-deftest literate-calc-mode-test/overlapping-names-2-test ()
  (with-temp-buffer
    (literate-calc-mode)
    (insert "yearlyfoo = 25\nbar=yearlyfoo * 2")
    (literate-calc-insert-results)
    (should (equal "yearlyfoo = 25 => yearlyfoo: 25\nbar=yearlyfoo * 2 => bar: 50"
                   (buffer-string)))))

This prevent using any identifier (like year) as part of variable names, which is a problem that I have encountered frequently trying to use literate-calc-mode, so I reverted my local version to before the fix for #15.

Hi! Thank you so much for Literate Calc Mode. It's very cool!

I started to use it to calculate service fees for my clients. Something like:

weeks = 5 days => weeks: 5 days

Contract duration = 5 weeks => Contract duration: 25 days
Time off = 3 days => Time off: 3 days
Work time = Contract duration - Time off => Work time: 22 days
Cost = 1000 EUR / days => Cost: 1,000 EUR / days
Fee = Cost * Work time => Fee: 22,000 EUR days / days

It's really nice to use multiple words for variables. Makes it much more suitable for non-technical recepients of my invoices. However the bottom line is not so nice when it comes to units (EUR days / days). It's possible to wrap it in usimplify, but then the calculation is not so friendly for non-programmers:

Fee = usimplify (Cost * Work time) => Fee: 22,000 EUR

Is there a way to always apply usimplify to the results? I tried to set the calc-simplify-mode to units, but it doesn't seem to have any effect.

(setq-local calc-simplify-mode 'units)

Related issue: #27

Anyway, thank you so much!

I tried to turn on literate-calc-minor-mode in org-mode files and found that it broke org-capture.
When I try to capture, I would get the error message "Match data clobbered by buffer modification hooks."

The problem appears to be a failure to wrap the body of your literate-calc--eval-buffer in save-match-data, as in this similar issue:

https://emacs.stackexchange.com/questions/38800/match-data-clobbered-by-buffer-modification-hooks

The problem went away when I removed literate-calc-minor-mode from my org-mode hook.

Very nice facility, by the way. Thanks for contributing!

Complex units are handled incorrectly, for example:

  Weight = 1.3oz/yd^2
  Area = 2m^2
  Total Weight = Weight * Area

Should result in 3.109 oz, but actual output is 0.2166 oz / (d^2 m^2).

Note that the initial value is already incorrect, the first line shows => Weight: 0.4333 oz/d^2.

As comparison, (calc-eval "1.3oz/yd^2") results in 1.3 oz / yd^2, and (calc-eval "(1.3oz/yd^2) * (2m^2)") in 2.6 oz m^2 / yd^2, which is correct.

How can we convert units?
I've done it using usimplify like in the readme:

Surface = 5000000 mm^2
=usimplify(1 m^2 + Surface - 1 m^2) => 5 m^2

Is there a better way?

Best regards

1. After an insert into buffer, would be nice to have a command to clear the results (i.e., the => stuff) and allow revision, and if a region is active limit the clearing to the region.

2. Unless you're constrained by calc, allow variable names to have digits in them, e.g., Price1, Price2, and perhaps underscores, Price_1 and Price_2

3. Allow variables from lines with inserted results to continue to participate in calculations, now they seem to be "deactivated."

4. Real kick-ass addition to Emacs, many thanks Sulami!

Hi this package seems awesome but I've run into one problem.

I have (setq org-log-done 'time) in my config and when I have literate-calc-minor-mode enabled then marking an org TODO item done gives the following message:

org-todo: Match data clobbered by buffer modification hooks

and no timestamp is inserted.

Hello! Firstly, thanks for literate-calc-mode! It's a great package!

Anyway, I've been having an issue with the following:

Gas Range = [ 30.00 .. 45.00 ) => Gas Range: [30. .. 45.)
Gas Spending Per Month = Gas Range * 2 => Gas Spending Per Month: [60. .. 90.)
Gas Spending Yearly = Gas Spending Per Month * 12 => Gas Spending Yearly: 12 Gas Spending Per Month

Not sure why the following is happening on the third line. Some info:

Where I'm using this: Org-mode

literate-calc-mode verions: 20230612.2332

Emacs version: 30.0.50

I get an error where using the literate-calc-mode command:

In toplevel form:
literate-calc-mode.el:37:1: Error: Invalid function: org-assert-version

Hi @sulami,

Thanks for writing this package! I'm using it to do end of the month finance stuff with my girlfriend 🙂

I noticed that literate-calc-insert-result doesn't insert the fully evaluated results, which are shown in the overlays. Here is an example:

a = 1
b = 1
c = a + b
d = b + c
e = c + d

The overlay shows fully evaluated, concrete results:

while literate-calc-insert-result shows:

I'm using Emacs 28.0.50 on macOS and literate-calc-mode 20200525.1416.

Please let me know if you need more details.

Hi. Thanks for your nice package. It is amusing.

I would like export its results to make reports using the calcs, is it possible? Not all operations, but some of them, the results I find relevant.

Best regards

Stricter syntax requirements would be good to avoid treating =emphasis= highlights as calc statements. I see

treat =emphasis= highlights `=> treat: emphasis`