Re: babel output seems to drop anything before % (in session)

[John Corless]

Confirmed

Daniele,

I was able to reproduce the behavior you described.  Using the test case...

#+BEGIN_SRC shell script :results output
ping -c 1 127.0.0.1
#+END_SRC

... the results output matches what I get in a bash shell.  But if you add
the :session to the header args like this...

#+BEGIN_SRC shell script :results output :session test
ping -c 1 127.0.0.1
#+END_SRC

... the output line that includes "0% packet loss" gets truncated to after
the "%" sign.

I tested with 9.4.5.

John


On Wed, May 5, 2021 at 10:19 AM Daniele Pizzolli  wrote:

>
> Hello,
>
> Try to execute a few times the following and see the output corrupted in
> the line:
>
> #+BEGIN_EXAMPLE
> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
> #+END_EXAMPLE
>
> #+PROPERTY: header-args:shell
> #+PROPERTY: header-args:shell+ :results output verbatim :wrap src text
> :session test
>
> #+NAME: ping
> #+BEGIN_SRC shell
> ping -c 1 127.0.0.1
> #+END_SRC
>
> I tried to write a test (now with the :expected-result :failed), that
> hit the problem both in main and master (applies fine to both).
>
> I was not able to fix it, but hopefully the tests are still useful for
> somebody more knowledgeable!
>
> Thanks for you suggestion/fix!
>
> Best,
> Daniele
>
>

ob-fortran fixes to column position 6 and subroutine keywords

[pietru]

ob-fortran treats code highlighting as "fortran 77" code, starting highlighting
from column position 6.  Can this be changed to use free format?

Also the following call fails, meaning that currently you cannot use
keywords.

call system_clock(cnt_mx=count_max, cnt_rt=count_rate)

Re: prettify-symbols-mode in org agenda?

[Ihor Radchenko]

William Xu  writes:

> I think I'm still seeing the issue. For example, if i change (M-x
> org-agenda-todo) a TODO item into next state ONGOING, which i have made
> prettified:
>
>   (push '("ONGOING" . "" ) prettify-symbols-alist)
>
> So far so good. But as soon as I call org-agenda-redo-all, after the
> agenda is refreshed, it changes back to text 'ONGOING'. 

I was able to reproduce using prettify-symbols-mode (though not using
pretty-symbols-mode). Should be fixed now in the attached patch.

Best,
Ihor

>From 46d6c93cd59d56959e0835c958e3c822aa5308d6 Mon Sep 17 00:00:00 2001
Message-Id: <46d6c93cd59d56959e0835c958e3c822aa5308d6.1620267219.git.yanta...@gmail.com>
From: Ihor Radchenko 
Date: Tue, 4 May 2021 20:33:10 +0800
Subject: [PATCH] Make sure that fontification is preserved in agenda

* lisp/org-macs.el (org-string-width): Refactor old code and add
optional argument to return pixel width.  The old code used manual
parsing of text properties to find which parts of string are visible.
The new code defers this work to Emacs display engine via
`window-text-pixel-size'.  The visibility settings of current buffer
are taken into account.

(org--string-from-props): Removed.  It was only used by old
`org-string-width' code.

(org-buffer-substring-fontified): New function. Like
`buffer-substring', but make sure that the substring is fontified.

(org-looking-at-fontified): New function.  Like `looking-at', but make
sure that the match is fontified.

* lisp/org.el (org-get-heading): Make sure that heading is fontified.

(org--get-local-tags, org-get-tags, org-scan-tags): Add optional
argument `fontified'.  When non-nil, the returned tags are fontified.

* lisp/org-agenda.el (org-agenda-get-todos, org-agenda-get-progress,
org-agenda-get-deadlines, org-agenda-get-scheduled,
org-agenda-fix-displayed-tags, org-search-view, org-agenda-get-todos,
org-agenda-get-timestamps, org-agenda-get-sexps,
org-agenda-get-deadlines, org-agenda-get-progress,
org-agenda-get-blocks, org-tags-view, org-agenda-list, org-todo-list,
org-agenda-highlight-todo): Make sure that fontification is the same
with original Org buffers.  All the buffer-substring and match-data
queries are changed to ensure that region of interest is fontified.
Also, preserve composition properties, used i.e. by
`prettify-symbols-mode'.  The composition is usually set to be removed
on text change, so we do the changes inside
`with-silent-modifications'.

(org-agenda-align-tags): Use pixel width and (space . :align-to)
'display property to align tags in agenda.

Preserve fontification and composition of headlines and tags in
agenda.  If the headlines/tags are not yet fontified when building
agenda, make sure that they are fontified in the original Org mode
buffers first.

In addition, tags alignment is now done pixel-wise to avoid alignment
issues with variable-pitch symbols that may appear in fontified Org
mode buffers.  The alignment is utilising :align-to specification,
which means that the alignment will be automatically updated as the
agenda buffer is resized.
---
 lisp/org-agenda.el | 126 +-
 lisp/org-macs.el   | 134 +++--
 lisp/org.el|  36 
 3 files changed, 171 insertions(+), 125 deletions(-)

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index 4c34ca5fe..546a03bc3 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -3984,7 +3984,7 @@ (defun org-agenda-finalize ()
 		  (put-text-property (point-at-bol) (point-at-eol)
  'tags
  (org-with-point-at mrk
-   (org-get-tags
+   (org-get-tags nil nil t
 	(setq org-agenda-represented-tags nil
 	  org-agenda-represented-categories nil)
 	(when org-agenda-top-headline-filter
@@ -,9 +,12 @@ (defun org-agenda-list ( arg start-day span with-hour)
 	(put-text-property s (1- (point)) 'org-today t))
 	  (setq rtnall
 		(org-agenda-add-time-grid-maybe rtnall ndays todayp))
-	  (when rtnall (insert ;; all entries
-			(org-agenda-finalize-entries rtnall 'agenda)
-			"\n"))
+  (with-silent-modifications
+;; Composition property in entries may be self-destructed
+;; on change.  Suppress the self-destruction.
+	(when rtnall (insert ;; all entries
+			  (org-agenda-finalize-entries rtnall 'agenda)
+			  "\n")))
 	  (put-text-property s (1- (point)) 'day d)
 	  (put-text-property s (1- (point)) 'org-day-cnt day-cnt)))
   (when (and org-agenda-clockreport-mode clocktable-start)
@@ -4778,10 +4781,11 @@ (defun org-search-view ( todo-only string edit-at)
   (and (eq org-agenda-show-inherited-tags t)
    (or (eq org-agenda-use-tag-inheritance t)
 	   (memq 'todo org-agenda-use-tag-inheritance
-			  tags (org-get-tags nil (not inherited-tags))
+			  tags (org-get-tags
+nil (not inherited-tags) t)
 			  txt (org-agenda-format-item
    ""
-   

Re: ob-fortran behaviour

[Christopher Dimech]

There exists no problem with fortran.

My brain was not open because u(i) gets beyond its bounds.

> Sent: Thursday, May 06, 2021 at 11:09 AM
> From: "Christopher Dimech" 
> To: "Eric S Fraga" 
> Cc: "Org Mode List" 
> Subject: ob-fortran behaviour
>
> Fortran is behaving in a weird way
>
>   #+BEGIN_SRC fortran
> program matrx_vectr_mult
> implicit none
>
> integer :: m, n, i, j, k
> real :: a(5,3), u(3), v(5), rsum
>
> m = 5;  n = 3
> a = 0.0;  u = 0.0;  v = 0.0
>
> k = 0
> do j = 1, n
>   do i = 1, m
> k = i + j
> a(i,j) = real(k)
> u(i) = real(3*i)
>   end do
> end do
>
> do i = 1, m
>   rsum = 0.0
>   do j = 1, n
> rsum = (a(i,j) * u(j)) + rsum
>   end do
>   v(i) = rsum
> end do
>
> write (*,*) "a * *", " * ", "u", " * ", "v"
> write (*,*) a(1,:), "*", u(1), "*", v(1)
> write (*,*) a(2,:), "*", u(2), "*", v(2)
> write (*,*) a(3,:), "*", u(3), "*", v(3)
> write (*,*) a(4,:), "* * *", v(4)
> write (*,*) a(5,:), "* * *", v(5)
>
> print *, "---"
> write (*,*) a
>
>   end program
> #+END_SRC
>
> #+RESULTS:
> |a |* |   * | *   |   u | *   | v | | | | | | 
> | | |
> | 12.0 |  3.0 | 4.0 | *   | 3.0 | *   |  90.0 | | | | | | 
> | | |
> | 15.0 |  4.0 | 5.0 | *   | 6.0 | *   | 114.0 | | | | | | 
> | | |
> |  4.0 |  5.0 | 6.0 | *   | 9.0 | *   |  96.0 | | | | | | 
> | | |
> |  5.0 |  6.0 | 7.0 | *   |   * | *   | 114.0 | | | | | | 
> | | |
> |  6.0 |  7.0 | 8.0 | *   |   * | *   | 132.0 | | | | | | 
> | | |
> |  --- |  | | | | |   | | | | | | 
> | | |
> | 12.0 | 15.0 | 4.0 | 5.0 | 6.0 | 3.0 |   4.0 | 5.0 | 6.0 | 7.0 | 4.0 | 5.0 | 
> 6.0 | 7.0 | 8.0 |
>
>
> -
> Christopher Dimech
> General Administrator - Naiad Informatics - GNU Project (Geocomputation)
> - Geophysical Simulation
> - Geological Subsurface Mapping
> - Disaster Preparedness and Mitigation
> - Natural Resource Exploration and Production
> - Free Software Advocacy
>
>

ob-fortran behaviour

[Christopher Dimech]

Fortran is behaving in a weird way

  #+BEGIN_SRC fortran
program matrx_vectr_mult
implicit none

integer :: m, n, i, j, k
real :: a(5,3), u(3), v(5), rsum

m = 5;  n = 3
a = 0.0;  u = 0.0;  v = 0.0

k = 0
do j = 1, n
  do i = 1, m
k = i + j
a(i,j) = real(k)
u(i) = real(3*i)
  end do
end do

do i = 1, m
  rsum = 0.0
  do j = 1, n
rsum = (a(i,j) * u(j)) + rsum
  end do
  v(i) = rsum
end do

write (*,*) "a * *", " * ", "u", " * ", "v"
write (*,*) a(1,:), "*", u(1), "*", v(1)
write (*,*) a(2,:), "*", u(2), "*", v(2)
write (*,*) a(3,:), "*", u(3), "*", v(3)
write (*,*) a(4,:), "* * *", v(4)
write (*,*) a(5,:), "* * *", v(5)

print *, "---"
write (*,*) a

  end program
#+END_SRC

#+RESULTS:
|a |* |   * | *   |   u | *   | v | | | | | |   
  | | |
| 12.0 |  3.0 | 4.0 | *   | 3.0 | *   |  90.0 | | | | | |   
  | | |
| 15.0 |  4.0 | 5.0 | *   | 6.0 | *   | 114.0 | | | | | |   
  | | |
|  4.0 |  5.0 | 6.0 | *   | 9.0 | *   |  96.0 | | | | | |   
  | | |
|  5.0 |  6.0 | 7.0 | *   |   * | *   | 114.0 | | | | | |   
  | | |
|  6.0 |  7.0 | 8.0 | *   |   * | *   | 132.0 | | | | | |   
  | | |
|  --- |  | | | | |   | | | | | |   
  | | |
| 12.0 | 15.0 | 4.0 | 5.0 | 6.0 | 3.0 |   4.0 | 5.0 | 6.0 | 7.0 | 4.0 | 5.0 | 
6.0 | 7.0 | 8.0 |


-
Christopher Dimech
General Administrator - Naiad Informatics - GNU Project (Geocomputation)
- Geophysical Simulation
- Geological Subsurface Mapping
- Disaster Preparedness and Mitigation
- Natural Resource Exploration and Production
- Free Software Advocacy

Re: [wip-cite-new] New natbib processor

[Bruce D'Arcus]

On Wed, May 5, 2021 at 5:25 PM Bruce D'Arcus  wrote:

> Now I did the real test: would LaTeX -> PDF work.
>
> Answer: not ATM.

Probably user error, as I've not compiled bibtex + latex documents in
a long time.

But it doesn't appear the bib file specified in the org file gets
passed to the latex output.

Bruce

Re: [wip-cite-new] New natbib processor

[Bruce D'Arcus]

On Wed, May 5, 2021 at 2:08 PM Bruce D'Arcus  wrote:

> I did some basic testing, and it seems to work well in general ...

That was just looking at the citation output, of course.

Now I did the real test: would LaTeX -> PDF work.

Answer: not ATM.

Here's my minimal document:


[cite/text/alt:see ;@mann-68]

[cite//alt/caps:@mann-68]

[cite//full:@mann-68]

[cite//caps:@mann-68]

#+cite_export: natbib
#+bibliography: test.bib


... but when I run the export, I get an "undefined citation" error.

The key is correct, as is the file name, which is in the same directly
as the test file.

What am I missing?

Bruce

Re: [wip-cite-new] New natbib processor

[Bruce D'Arcus]

BTW, if anyone else wants to test this but wasn't sure how, I put
together this little gist with a minimal init and instructions.

https://gist.github.com/bdarcus/2645f99363fc47ddab2aae24c5d9e66c

Bruce

Re: orgbabel with fortran code

[pietru]

Perhaps we can have a crack at ob-fortran again, considering you have had
some successes.  With the motivation that this could drive some more work 
on the code if useful.  Would some hacking time of a few days bo possible 
to you?  We can then compile a brief report and send it.  

Thank you so very much Arne.

> Sent: Thursday, May 06, 2021 at 7:50 AM
> From: "Dr. Arne Babenhauserheide" 
> To: pie...@caramail.com
> Cc: emacs-orgmode@gnu.org
> Subject: Re: orgbabel with fortran code
>
> pie...@caramail.com writes:
> 
> > Have you got exomples with fortran code yourself?  I would like to 
> > scrutinise them. 
> 
> I have this, but I no longer know whether it actually executes fortran
> inline or only tangles it:
> 
> https://www.draketo.de/files/2017-04-10-Mo-fortran-commandline-tool.org
> https://www.draketo.de/files/surprises.org
> 
> From
> https://www.draketo.de/english/free-software/fortran
> https://www.draketo.de/light/english/fortran-surprises
> 
> Best wishes,
> Arne
> -- 
> Unpolitisch sein
> heißt politisch sein
> ohne es zu merken
> Message-ID: <87h7jh2qh7@web.de>
>

Re: orgbabel with fortran code

[pietru]

> Sent: Thursday, May 06, 2021 at 8:53 AM
> From: "Dr. Arne Babenhauserheide" 
> To: pie...@caramail.com
> Cc: emacs-orgmode@gnu.org
> Subject: Re: orgbabel with fortran code
>
> 
> pie...@caramail.com writes:
> 
> > Have seen yon also use ob-latex.  Have tried to display equations but was 
> > not
> > successful.  I would be grateful with some help on that Arne.
> 
> Where did you try to use ob-latex? I mainly use latex-export (and quite a
> large amount of it).

It is supposed to work, so tried to crack it.  Could be useful an attempts 
could drive some improvements.



 
> Best wishes,
> Arne
> -- 
> Unpolitisch sein
> heißt politisch sein
> ohne es zu merken
>

Re: orgbabel with fortran code

[pietru]

Have had a first go with your code

I wrote the following, then went inside the code and slammed "C-c C-c" 

#+BEGIN_SRC fortran :tangle fortran-comline.f90
program cli
  implicit none ! no implicit declaration: all variables must be declared
  character(1000) :: arg
  
  call get_command_argument(1, arg) ! result is stored in arg, see 
  ! https://gcc.gnu.org/onlinedocs/gfortran/GET_005fCOMMAND_005fARGUMENT.html
  
  if (len_trim(arg) == 0) then ! no argument given
  write (*,*) "Call me --world!"
  else
  if (trim(arg) == "--world") then
  call get_command_argument(2, arg)
  if (len_trim(arg) == 0) then
  arg = "again!"
  end if
  write (*,*) "Hello ", trim(arg)
  ! trim reduces the fixed-size array to non-blank letters
  end if
  end if
end program
#+END_SRC

And then I wrote this, went inside the code and slammed "C-c C-c" 

#+BEGIN_SRC sh :results output :exports both
  gfortran -std=gnu -O3 fortran-comline.f90 -o fortran-comline
  ./fortran-comline
  ./fortran-comline --world World
  ./fortran-comline --world
#+END_SRC

But I am getting some major whining

/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/Scrt1.o: In function 
`_start':
(.text+0x20): undefined reference to `main'
collect2: error: ld returned 1 exit status
sh: 2: ./fortran-comline: not found
sh: 3: ./fortran-comline: not found
sh: 4: ./fortran-comline: not found



> Sent: Thursday, May 06, 2021 at 7:50 AM
> From: "Dr. Arne Babenhauserheide" 
> To: pie...@caramail.com
> Cc: emacs-orgmode@gnu.org
> Subject: Re: orgbabel with fortran code
>
> pie...@caramail.com writes:
> 
> > Have you got exomples with fortran code yourself?  I would like to 
> > scrutinise them. 
> 
> I have this, but I no longer know whether it actually executes fortran
> inline or only tangles it:
> 
> https://www.draketo.de/files/2017-04-10-Mo-fortran-commandline-tool.org
> https://www.draketo.de/files/surprises.org
> 
> From
> https://www.draketo.de/english/free-software/fortran
> https://www.draketo.de/light/english/fortran-surprises
> 
> Best wishes,
> Arne
> -- 
> Unpolitisch sein
> heißt politisch sein
> ohne es zu merken
> Message-ID: <87h7jh2qh7@web.de>
>

Re: orgbabel with fortran code

[Dr. Arne Babenhauserheide]

pie...@caramail.com writes:

> Have seen yon also use ob-latex.  Have tried to display equations but was not
> successful.  I would be grateful with some help on that Arne.

Where did you try to use ob-latex? I mainly use latex-export (and quite a
large amount of it).

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: orgbabel with fortran code

[pietru]

Have seen yon also use ob-latex.  Have tried to display equations but was not
successful.  I would be grateful with some help on that Arne.

Regards
Pete


> Sent: Thursday, May 06, 2021 at 7:50 AM
> From: "Dr. Arne Babenhauserheide" 
> To: pie...@caramail.com
> Cc: emacs-orgmode@gnu.org
> Subject: Re: orgbabel with fortran code
>
> pie...@caramail.com writes:
> 
> > Have you got exomples with fortran code yourself?  I would like to 
> > scrutinise them. 
> 
> I have this, but I no longer know whether it actually executes fortran
> inline or only tangles it:
> 
> https://www.draketo.de/files/2017-04-10-Mo-fortran-commandline-tool.org
> https://www.draketo.de/files/surprises.org
> 
> From
> https://www.draketo.de/english/free-software/fortran
> https://www.draketo.de/light/english/fortran-surprises
> 
> Best wishes,
> Arne
> -- 
> Unpolitisch sein
> heißt politisch sein
> ohne es zu merken
> Message-ID: <87h7jh2qh7@web.de>
>

Re: orgbabel with fortran code

[Christopher Dimech]

I can tell you that I used Fortran for much of my secret underwater surveillance
work.  Richard Stallman doesn't like it and we butt heads.  But you should know
that I come from area known as Afro-Asia.  I always win. 


> Sent: Thursday, May 06, 2021 at 7:50 AM
> From: "Dr. Arne Babenhauserheide" 
> To: pie...@caramail.com
> Cc: emacs-orgmode@gnu.org
> Subject: Re: orgbabel with fortran code
>
> pie...@caramail.com writes:
> 
> > Have you got exomples with fortran code yourself?  I would like to 
> > scrutinise them. 
> 
> I have this, but I no longer know whether it actually executes fortran
> inline or only tangles it:
> 
> https://www.draketo.de/files/2017-04-10-Mo-fortran-commandline-tool.org
> https://www.draketo.de/files/surprises.org
> 
> From
> https://www.draketo.de/english/free-software/fortran
> https://www.draketo.de/light/english/fortran-surprises
> 
> Best wishes,
> Arne
> -- 
> Unpolitisch sein
> heißt politisch sein
> ohne es zu merken
> Message-ID: <87h7jh2qh7@web.de>
> 

-
Christopher Dimech
General Administrator - Naiad Informatics - GNU Project (Geocomputation)
- Geophysical Simulation
- Geological Subsurface Mapping
- Disaster Preparedness and Mitigation
- Natural Resource Exploration and Production
- Free Software Advocacy

Re: Multiple calc commands with orgbabel

[pietru]

> Sent: Thursday, May 06, 2021 at 4:39 AM
> From: "Eric S Fraga" 
> To: "Matt Price" 
> Cc: pie...@caramail.com, "Org Mode List" 
> Subject: Re: Multiple calc commands with orgbabel
>
> On Wednesday,  5 May 2021 at 11:11, Matt Price wrote:
> > Can you explain how you get calc embedded mode working in org? I have
> > never used it and it sounds interesting, but I don't understand what
> > hte delimiters are.
>
> Sure.  Here is a mini-tutorial! :-) I recently gave an interactive talk
> on embedded Calc...
>
> The out-of-the-box settings for Emacs embedded mode are such that any
> line surrounded by empty lines (i.e. couple of blank lines before and
> after) can be interpreted as an expression to evaluate by Calc using
> "C-x * u".  You do not need to place these expressions in any src block.
>
> The detection can be somewhat fragile so extra blank lines are sometimes
> necessary for some reason.
>
> For instance, copy the following few lines to a text buffer and type
> "C-x * u" on each line in turn:
>
> --8<---cut here---start->8---
>
>
> x := 180 =>
>
>
> y := sin(x / 4) =>
>
>
> z := 2 y^2 =>
>
>
> --8<---cut here---end--->8---
>
> The general format for an embedded calc expression is
>
>var := expression => value
>
> where only "expression" is required.  If you don't have "=>", evaluating
> the expression will replace the expression with its value.
>
> If you have lines as above, with assignments and values after the actual
> expression, you can then go back to the first line and change the value,
> say to 90, type "C-x *u" on that line again and all of them should
> update.
>
> The calculations can involve calculus (derivatives, integration), linear
> algebra, and units.  Calc is actually an incredibly powerful (and
> relatively unknown) computer algebra system hiding within Emacs.

Calc is a great piece of work.  Has it been long that work was done on it?

> The variables that could be customised to have org specific recognition
> would be calc-embedded-open-formula and calc-embedded-close-formula.  It
> might be useful for the community to think about whether org should have
> org specific settings for these variables.  I actually define settings
> for org so that only lines that look like this:
>
> #+calc: expression
>
> are interpreted (without requiring empty lines around such lines)
> [1].  I then have code for processing these lines on export to LaTeX to
> present the equations and results in a more accessible way as I use
> embedded calc a lot for teaching (beamer slides).
>
> Final note: the info manual for embedded Calc mode emphasises editing
> the expressions and interacting with Calc while doing so.  I find that
> method of working rather confusing, tiring, and unproductive (for my use
> case) so I write the calc lines using normal editing and only "update"
> the expressions to get the results.  YMMV, of course.
>
> Let me know if this helped at all,
> eric
>
>
> Footnotes:
> [1] it would be nice to have some generic way to hijack C-c C-c on such
>  lines to do what I want, e.g. calc-embedded-update-formula.
>
> --
> : Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-395-g82fbdd
>
>

Re: orgbabel with fortran code

[Dr. Arne Babenhauserheide]

pie...@caramail.com writes:

> Have you got exomples with fortran code yourself?  I would like to scrutinise 
> them. 

I have this, but I no longer know whether it actually executes fortran
inline or only tangles it:

https://www.draketo.de/files/2017-04-10-Mo-fortran-commandline-tool.org
https://www.draketo.de/files/surprises.org

From
https://www.draketo.de/english/free-software/fortran
https://www.draketo.de/light/english/fortran-surprises

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken
Message-ID: <87h7jh2qh7@web.de>


signature.asc
Description: PGP signature

[PATCH] Added two extra symbols to org-entities

[Atlas Cove]

Hello! I am finally making my first small contribution to org-mode!

I've added both U+0130, "LATIN CAPITAL LETTER I WITH DOT ABOVE" 'İ' & U+0131, "LATIN SMALL 
LETTER DOTLESS I", "ı",
accessed with '\Idot{}' and '\inodot{}'.

I'm unsure if I've got the Latin-1 encoding down, so I've included it in a 
*.diff file as well.

From 414f32ac09774649cb5ddca5ffd551ff9900db29 Mon Sep 17 00:00:00 2001
From: Atlas48 
Date: Wed, 5 May 2021 19:37:43 +0100
Subject: [PATCH] Add the Turkic dotted and dotless 'i' to the list of special
 symbols. TINYCHANGE

---
 lisp/org-entities.el | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lisp/org-entities.el b/lisp/org-entities.el
index eb098993b..0861274f8 100644
--- a/lisp/org-entities.el
+++ b/lisp/org-entities.el
@@ -114,6 +114,8 @@ packages to be loaded, add these packages to `org-latex-packages-alist'."
  ("igrave" "\\`{i}" nil "" "i" "ì" "ì")
  ("Iacute" "\\'{I}" nil "" "I" "Í" "Í")
  ("iacute" "\\'{i}" nil "" "i" "í" "í")
+ ("Idot" "\\.{I}" nil "" "I" "İ" "İ")
+ ("inodot" "\\i" nil "" "i" "ı" "ı")
  ("Icirc" "\\^{I}" nil "" "I" "Î" "Î")
  ("icirc" "\\^{i}" nil "" "i" "î" "î")
  ("Iuml" "\\\"{I}" nil "" "I" "Ï" "Ï")
--
2.31.1

diff --git a/lisp/org-entities.el b/lisp/org-entities.el
index eb098993b..0861274f8 100644
--- a/lisp/org-entities.el
+++ b/lisp/org-entities.el
@@ -114,6 +114,8 @@ packages to be loaded, add these packages to `org-latex-packages-alist'."
  ("igrave" "\\`{i}" nil "" "i" "ì" "ì")
  ("Iacute" "\\'{I}" nil "" "I" "Í" "Í")
  ("iacute" "\\'{i}" nil "" "i" "í" "í")
+ ("Idot" "\\.{I}" nil "" "I" "İ" "İ")
+ ("inodot" "\\i" nil "" "i" "ı" "ı")
  ("Icirc" "\\^{I}" nil "" "I" "Î" "Î")
  ("icirc" "\\^{i}" nil "" "i" "î" "î")
  ("Iuml" "\\\"{I}" nil "" "I" "Ï" "Ï")

Re: [PATCH] ox-publish.el: Speed up org-publish-cache-file-needs-publishing

[Emily Bourke]

Hi Bastien,

> thanks for the patch and sorry to reactivate this old thread.

No problem, thanks for getting in touch - the reminder is appreciated.

> Did you find time to make the tests and, perhaps, to update the patch?

I'm afraid I haven't had a chance to look at this any further since my last 
email. I'll try to find some time this week.

Best wishes,
Emily

Re: wip-cite status question and feedback

[Bruce D'Arcus]

On Wed, May 5, 2021 at 2:15 PM M. ‘quintus’ Gülker
 wrote:

> I wonder, can the placement of the footnote not just be left to the
> author...? I have the impression that something is being
> over-engineered here with the attempt to automate this, but maybe this
> is just me.

The use case is for users who may author with the expectation of using
one style for output (for example, author-date), but then find they
have to use another (say note-based).

It's not super common, since most scholars operate in fields where
practices are more-or-less consistent.

Scientists, for example, do not use note-based styles, and humanities
people do not use numeric ones.

But people (like me) who, for example, work at the borders of the
humanities and social sciences, can be required to switch among very
different styles. For example, they may submit a manuscript to one
journal that uses an author-date style, and it gets rejected there,
and then submit to another journal which is note-based.

So it is somewhat rare, but is not a purely hypothetical requirement.

Without this, the user would have to modify their entire document to
adjust the formatting, which is a hassle.

It's also not a hypothetical solution, as it's already implemented in
solutions like pandoc, and works well there.

But that currently works correctly for the "American" rules only,
which is why Denis put in an issue there for that, and why he has
weighed in here.

Hope that explains.

Bruce

Re: wip-cite status question and feedback

[M . ‘quintus’ Gülker]

Am 05. Mai 2021 um 09:46 Uhr -0400 schrieb Bruce D'Arcus:
> We found three rules:
> 
> 1. what Chicago calls "American"
> 2. what it calls "British"
> 3. French (though Denis is still confirming how these work in actual books)
> 
> The output in each, when formatting as a note:
> 
> 1. A sentence ending in a "cited quote."[1]
> 2. A sentence ending in a "cited quote".[1]
> 3. A sentence ending in a "cited quote[1]."

While I have never seen it stated authoritatively somewhere, in German
it appears to be common to use 1) if the terminal period is in the
cited source, and 2) if it is not, that is, just being exact in
quoting. As a result, both variants can occur in the same document,
because it depends on the cited source.

3) is doubtful in German. It would mean that there is a footnote 1 in
the cited source, but there is not reference for the cited source.
Correct it would have to be

4) A sentence ending in a "cited quote¹"³.

or

5) A sentence ending in a "cited quote¹".³

If the cited quote referenced by footnote 3 indeed does have a
footnote 1 in that position. That being said, I never saw such a
construction.

At least, that are the rules I recall from my school time and which I
used ever since with nobody complaining.

I wonder, can the placement of the footnote not just be left to the
author...? I have the impression that something is being
over-engineered here with the attempt to automate this, but maybe this
is just me.

  -quintus

-- 
Dipl.-Jur. M. Gülker | https://mg.guelker.eu |For security:
Passau, Germany  | kont...@guelker.eu| () Avoid HTML e-mail
European Union   | PGP: see homepage | /\ http://asciiribbon.org

Re: [wip-cite-new] New natbib processor

[Bruce D'Arcus]

On Wed, May 5, 2021 at 10:53 AM Nicolas Goaziou  wrote:

> As a reminder, to test it, you (require 'oc-natbib) to register the
> processor, and add "#+cite_export: natbib" in your document (or set
> `org-cite-export-processor' to (natbib)).

I did some basic testing, and it seems to work well in general, though
natbib folks will have to report on how well the sub-styles work, in
terms of mapping them to the natbib commands.

Attaching a screenshot with a few input/output variations, and at the
bottom is what the style selection UI I came up with for
bibtex-actions looks like.

Bruce

Re: prettify-symbols-mode in org agenda?

[William Xu]

Ihor Radchenko  writes:

>>> The only issue I still see, is that when you org-agenda-redo-all, or
>>> org-agenda-log-mode (which triggers org-agenda-redo-all), the
>>> prettify gets lost again. Maybe org-buffer-substring-fontified call is
>>> also required somewhere during org-agenda-redo-all? 
>>
>> I managed to reproduce it. This time, I went through all the agenda.el
>> and updated places where the strings are fetched from Org buffers into
>> agenda. The updated patch is attached.
>
> Still forgot to update fontification in agenda tags view. Yet another
> update...

I think I'm still seeing the issue. For example, if i change (M-x
org-agenda-todo) a TODO item into next state ONGOING, which i have made
prettified:

  (push '("ONGOING" . "" ) prettify-symbols-alist)

So far so good. But as soon as I call org-agenda-redo-all, after the
agenda is refreshed, it changes back to text 'ONGOING'. 

Apart from this, it works pretty well. 

-- 
William

Re: Notes about citations in Org (part 3)

[Bruce D'Arcus]

On Wed, May 5, 2021 at 12:59 PM Maxim Nikulin  wrote:
>
> On 04/05/2021 23:59, Nicolas Goaziou wrote:
> >
> > Is the default \cite{key} command (without any other package) used? I'm
> > not sure we should provide it since we are working towards more complete
> > solutions.
>
> In some fields simple "[3,7]" citations are traditional.

How do you achieve such output, with which formats, packages, commands?

For example, do you get that with the default \cite command in latex,
assuming the right bst file?

Something else?

Bruce

Re: [PATCH] Use cache in org-up-heading-safe

[Maxim Nikulin]

On 04/05/2021 22:08, Ihor Radchenko wrote:


While testing another patch for agenda fontification, I noticed that
agenda can spend up to half!! time doing org-up-heading-safe. Mostly
inside queries for inherited tags and properties.

I managed to make org-up-heading-safe up to 50x faster using position
cache.


I have not tested the patch due to I do not use agenda. My interest was 
stimulated solely by my attempts to make org-refile-get-targets faster.


I consider it as an improvement. I have noticed the only thing that must 
be fixed: comments with old variant of the function. Reaction to my 
other comments is optional.


In org-agenda.el org-up-heading-safe function is called only from 
org-find-top-headline. So the purpose of the dance with backward 
searches is to get top level headings. My expectation is that scan 
through the whole buffer and storing result in a structure that allows 
binary search of position (array, red-black tree, etc) may be even faster.


Alternatively lazily obtained position of top heading could be stored in 
cache to reduce number of iterations on org-find-top-line.



+(let ((level-cache (gethash (point) org--up-heading-cache)))
+  (if (and level-cache
+   (eq (buffer-chars-modified-tick) org--up-heading-cache-tick))


If buffer-chars-modified-tick is faster than gethash then reordering 
might result in very slight improvement of performance.



+;; Parent is inside accessible part of the buffer.
+(progn (goto-char level-cache)
+   (funcall outline-level)))


I do not see any reason why outline level can not be cached in pair with 
position.



+  (let (result)
+(setq result


I am not a lisp guru, so from my point of view this can be reduced to
(let ((result ...


+(format "^\\*\\{1,%d\\} " level-up) nil t)


\t as an alternative to " " is used in org-refile.el,
e.g. "^\\*+[ \t]+". Unsure which variant is canonical one and I see that 
regexp is taken from original function, so no regression is expected.



+;; (defun org-up-heading-safe ()
+;;   "Move to the heading line of which the present line is a subheading.


Clean-up here is required, other notes may be ignored.

Re: Multiple calc commands with orgbabel

[Tom Gillespie]

Here is a quick and dirty implementation that more or less does what
you want (I think). The if t would probably need to be replaced by a
value that corresponded to an option that indicated that ob-calc
should resolve all expressions on the stack. This isn't really an
issue of return value, it is due to the fact that ob-calc makes
stateful modifications to calc. If you want a stateless (idempotent?)
ob-calc block you would need to do something like this as well, and
then you would need an option to discard the additional values instead
of retruning them as I do here. Best!
Tom
diff --git a/lisp/ob-calc.el b/lisp/ob-calc.el
index 39ebce100..e2102feca 100644
--- a/lisp/ob-calc.el
+++ b/lisp/ob-calc.el
@@ -48,6 +48,7 @@
   "Execute a block of calc code with Babel."
   (unless (get-buffer "*Calculator*")
 (save-window-excursion (calc) (calc-quit)))
+  (let ((unpopped 0))
   (let* ((vars (org-babel--get-vars params))
 	 (org--var-syms (mapcar #'car vars))
 	 (var-names (mapcar #'symbol-name org--var-syms)))
@@ -58,12 +59,14 @@
  vars)
 (mapc
  (lambda (line)
+   (setq unpopped (1+ unpopped)) ; ICK
(when (> (length line) 0)
 	 (cond
 	  ;; simple variable name
 	  ((member line var-names) (calc-recall (intern line)))
 	  ;; stack operation
 	  ((string= "'" (substring line 0 1))
+   (setq unpopped (- unpopped 2))
 	   (funcall (lookup-key calc-mode-map (substring line 1)) nil))
 	  ;; complex expression
 	  (t
@@ -89,9 +92,17 @@
 	 (split-string (org-babel-expand-body:calc body params) "[\n\r]"
   (save-excursion
 (with-current-buffer (get-buffer "*Calculator*")
-  (prog1
-(calc-eval (calc-top 1))
-(calc-pop 1)
+  (if t
+  (let ((out
+ (cl-loop for i from 1 to unpopped
+  do (message "%S %S" unpopped calc-stack)
+  collect (calc-eval (calc-top 1))
+  do (calc-pop 1
+(message "%S" out)
+(mapcar #'list (reverse out)))
+(prog1
+(calc-eval (calc-top 1))
+(calc-pop 1)))
 
 (defun org-babel-calc-maybe-resolve-var (el)
   (if (consp el)

Re: Multiple calc commands with orgbabel

[Tom Gillespie]

Looking at ob-calc there is a call to calc-push-list. Knowing the
length of that list (i.e. the number of arguments) it should be
possible to inspect calc-stack to retrieve the other values on the
stack from the current block. You can see this if you run M-:
calc-stack. This would probably need a specialized result type if it
were implemented. Best,
Tom

On Wed, May 5, 2021 at 8:33 AM  wrote:
>
>
> Example
>
> (require 'ob-calc)
>  (org-babel-do-load-languages
>  'org-babel-load-languages
>  '( (calc . t) )
>
>  calc.org 
>
> # To execute, place cursor point on a line, then hit "C-c * u" hard with no 
> harm.
>
> #+name: Simplifying Formulas
> #+begin_src calc
>
> simplify((x + y) (x + y)) =>
>
> simplify(a x^2 b / (c x^3 d)) =>
>
> simplify((4 x + 6) / (8 x)) =>
>
> simplify((1 + 2 i) (3 + 4 i)) =>
>
> simplify(5 + i^2 + i - 8 i) =>
>
> simplify((1, 2) + (3, 4)) =>
>
> simplify((1, 2) (3, 4)) =>
>
> #+end_src
>
>
>
> Sent: Thursday, May 06, 2021 at 3:11 AM
> From: "Matt Price" 
> To: "Org Mode List" 
> Cc: pie...@caramail.com
> Subject: Re: Multiple calc commands with orgbabel
> Can you explain how you get calc embedded mode working in org? I have never 
> used it and it sounds interesting, but I don't understand what hte delimiters 
> are.
>
> On Wed, May 5, 2021 at 2:35 AM Eric S Fraga  wrote:
>>
>> On Wednesday,  5 May 2021 at 07:46, pie...@caramail.com wrote:
>> > Have been trying to execute multiple calc commands, but when I
>> > evaluate the calc expressions, I get just one result.
>>
>> ob-calc returns the top element of the stack when finished and this will
>> be the result of the last operation in the src block.  I don't think
>> there's any way around this.
>>
>> I use embedded Calc for this reason.  You could rewrite your equations
>> as simple lines (separated by empty lines from the surroundings) and
>> evaluate each in turn with "C-x * u":
>>
>> fsolve(x 2 + x = 4, x) => x = 1.333
>>
>> fsolve([x + y = a, x - y = b], [x, y]) => [x = a + (b - a) / 2, y = (a - b) 
>> / 2]
>>
>> I added the "=>" at the end of each expression so that the result is
>> shown to the right instead of replacing the expression itself (default
>> embedded Calc behaviour).
>>
>> --
>> : Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-395-g82fbdd
>>

Re: Notes about citations in Org (part 3)

[Maxim Nikulin]

On 04/05/2021 23:59, Nicolas Goaziou wrote:


Is the default \cite{key} command (without any other package) used? I'm
not sure we should provide it since we are working towards more complete
solutions.


In some fields simple "[3,7]" citations are traditional. A couple of 
randomly picked examples:

https://www.osapublishing.org/oe/fulltext.cfm?uri=oe-29-10-15413=450715
https://arxiv.org/abs/2105.01093

Personally, I do not mind to have a hint (e.g. a tooltip) if format 
allows such features, e.g.
[13]

Re: Multiple calc commands with orgbabel

[Eric S Fraga]

On Wednesday,  5 May 2021 at 11:11, Matt Price wrote:
> Can you explain how you get calc embedded mode working in org? I have
> never used it and it sounds interesting, but I don't understand what
> hte delimiters are.

Sure.  Here is a mini-tutorial! :-) I recently gave an interactive talk
on embedded Calc...

The out-of-the-box settings for Emacs embedded mode are such that any
line surrounded by empty lines (i.e. couple of blank lines before and
after) can be interpreted as an expression to evaluate by Calc using
"C-x * u".  You do not need to place these expressions in any src block.

The detection can be somewhat fragile so extra blank lines are sometimes
necessary for some reason.

For instance, copy the following few lines to a text buffer and type
"C-x * u" on each line in turn:

--8<---cut here---start->8---


x := 180 =>


y := sin(x / 4) => 


z := 2 y^2 => 


--8<---cut here---end--->8---

The general format for an embedded calc expression is

   var := expression => value
   
where only "expression" is required.  If you don't have "=>", evaluating
the expression will replace the expression with its value.

If you have lines as above, with assignments and values after the actual
expression, you can then go back to the first line and change the value,
say to 90, type "C-x *u" on that line again and all of them should
update.

The calculations can involve calculus (derivatives, integration), linear
algebra, and units.  Calc is actually an incredibly powerful (and
relatively unknown) computer algebra system hiding within Emacs.

The variables that could be customised to have org specific recognition
would be calc-embedded-open-formula and calc-embedded-close-formula.  It
might be useful for the community to think about whether org should have
org specific settings for these variables.  I actually define settings
for org so that only lines that look like this:

#+calc: expression

are interpreted (without requiring empty lines around such lines)
[1].  I then have code for processing these lines on export to LaTeX to
present the equations and results in a more accessible way as I use
embedded calc a lot for teaching (beamer slides).

Final note: the info manual for embedded Calc mode emphasises editing
the expressions and interacting with Calc while doing so.  I find that
method of working rather confusing, tiring, and unproductive (for my use
case) so I write the calc lines using normal editing and only "update"
the expressions to get the results.  YMMV, of course.

Let me know if this helped at all,
eric


Footnotes:
[1] it would be nice to have some generic way to hijack C-c C-c on such
 lines to do what I want, e.g. calc-embedded-update-formula.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-395-g82fbdd

Re: [PATCH] tangling seems to have broken today

[Sébastien Miquel]

Hi Bastien,

The issue is that currently tangling a single block by calling
`org-babel-tangle` with a prefix argument fails. This is unrelated to
the earlier thread today, but was introduced by my original commit
a2cb9b853d.

Unfortunately, fixing it requires some refactorisation to avoid code
duplication. To keep the patch as simple as possible, I have
introduced a new helper function, I hope this is okay.

I have tested the attached patch with the uses cases shown so far, as
well as my own and the org test suite.

I apologise again for the troubles.

--
Sébastien Miquel

>From 69be5864d9c936396317d81b6c39ddb166ac45d6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= 
Date: Wed, 5 May 2021 17:45:09 +0200
Subject: [PATCH] ob-tangle.el: Fix single block tangle

lisp/ob-tangle.el (org-babel-tangle-single-block): Fix the result when
`only-this-block' is `t' to match what is expected by
`org-babel-tangle'.
(org-babel-effective-tangled-filename): Extract the
computation of filename of tangled src block.
(org-babel-tangle-collect-blocks): Use `org-babel-effective-tangled-filename'.
---
 lisp/ob-tangle.el | 34 ++
 1 file changed, 22 insertions(+), 12 deletions(-)

diff --git a/lisp/ob-tangle.el b/lisp/ob-tangle.el
index 8af03b11a..562776ae8 100644
--- a/lisp/ob-tangle.el
+++ b/lisp/ob-tangle.el
@@ -350,6 +350,22 @@ that the appropriate major-mode is set.  SPEC has the form:
 	   (org-fill-template
 		org-babel-tangle-comment-format-end link-data)

+(defun org-babel-effective-tangled-filename (buffer-fn src-lang src-tfile)
+  "Return effective tangled filename of a source-code block.
+BUFFER-FN is the name of the buffer, SRC-LANG the language of the
+block and SRC-TFILE is the value of the :tangle header argument,
+as computed by `org-babel-tangle-single-block'."
+  (let ((base-name (cond
+((string= "yes" src-tfile)
+ ;; Use the buffer name
+ (file-name-sans-extension buffer-fn))
+((> (length src-tfile) 0) src-tfile)))
+(ext (or (cdr (assoc src-lang org-babel-tangle-lang-exts)) src-lang)))
+(when base-name
+  ;; decide if we want to add ext to base-name
+  (if (and ext (string= "yes" src-tfile))
+  (concat base-name "." ext) base-name
+
 (defun org-babel-tangle-collect-blocks ( lang-re tangle-file)
   "Collect source blocks in the current Org file.
 Return an association list of language and source-code block
@@ -378,17 +394,8 @@ be used to limit the collected code blocks by target file."
 	;; file name.
 	(let* ((block (org-babel-tangle-single-block counter))
(src-tfile (cdr (assq :tangle (nth 4 block
-		   (base-name (cond
-			   ((string= "yes" src-tfile)
-;; buffer name
-(file-name-sans-extension
- (nth 1 block)))
-			   ((> (length src-tfile) 0) src-tfile)))
-		   (ext (or (cdr (assoc src-lang org-babel-tangle-lang-exts)) src-lang))
-		   (file-name (when base-name
-;; decide if we want to add ext to base-name
-(if (and ext (string= "yes" src-tfile))
-(concat base-name "." ext) base-name)))
+		   (file-name (org-babel-effective-tangled-filename
+   (nth 1 block) src-lang src-tfile))
 		   (by-fn (assoc file-name blocks)))
 	  (if by-fn (setcdr by-fn (cons (cons src-lang block) (cdr by-fn)))
 		(push (cons file-name (list (cons src-lang block))) blocks)))
@@ -482,7 +489,10 @@ non-nil, return the full association list to be used by
 		  (org-trim (org-remove-indentation body)))
 		comment)))
 (if only-this-block
-	(list (cons src-lang (list result)))
+(let* ((src-tfile (cdr (assq :tangle (nth 4 result
+   (file-name (org-babel-effective-tangled-filename
+   (nth 1 result) src-lang src-tfile)))
+  (list (cons file-name (list (cons src-lang result)
   result)))

 (defun org-babel-tangle-comment-links ( info)
-- 
2.31.1

Please help by becoming a Worg maintainer

[Bastien]

Dear all,

https://orgmode.org/worg/ is the community-driven documentation effort
for anything related to Org.

It is full of useful information but it needs some more maintainance.

I'm looking for someone who could take this in charge by helping when
possible.  Of course, we can have several maintainers, but we need one
in charge.

If you want to help occasionally, that's welcome too (please send me
an email with the username you want on https://code.orgmode.org) but
beware that the more occasional help Worg receives the more it needs
to be driven by someone -- so please consider first stepping up as a
maintainer first.

Here is a list of tasks to supervise:

- Update obsolete documentation
- Remove obsolete contents
- Clean up the directory structure
- Enhance the CSS stylesheet (make it responsive)
- List useful Org modules (not all of them, there are too many)
- List parsers
- List other tools
- Keep https://orgmode.org/worg/doc.html up to date

... and more if you enjoy it.

Thanks!

-- 
 Bastien

Re: [wip-cite-new] New natbib processor

[Bastien]

"Bruce D'Arcus"  writes:

> On Wed, May 5, 2021 at 10:53 AM Nicolas Goaziou  
> wrote:
>
>> Another thread! Yay!
>
> We should be close to the finish line!

We should boost our media coverage for such efforts :)

Joke aside, thank you both very much for keeping the ball rolling,
it's nice to see this area stabilizing, I'm sure it'll be a great
addition for Org 9.5.

-- 
 Bastien

Re: Multiple calc commands with orgbabel

[pietru]

 

Example

 

(require 'ob-calc)

 (org-babel-do-load-languages
 'org-babel-load-languages
 '( (calc . t) )

 

 calc.org 

 

# To execute, place cursor point on a line, then hit "C-c * u" hard with no harm.

 

#+name: Simplifying Formulas
#+begin_src calc

simplify((x + y) (x + y)) =>

simplify(a x^2 b / (c x^3 d)) =>

simplify((4 x + 6) / (8 x)) =>

simplify((1 + 2 i) (3 + 4 i)) =>

simplify(5 + i^2 + i - 8 i) =>

simplify((1, 2) + (3, 4)) =>

simplify((1, 2) (3, 4)) =>

#+end_src

 

 

 

Sent: Thursday, May 06, 2021 at 3:11 AM
From: "Matt Price" 
To: "Org Mode List" 
Cc: pie...@caramail.com
Subject: Re: Multiple calc commands with orgbabel


Can you explain how you get calc embedded mode working in org? I have never used it and it sounds interesting, but I don't understand what hte delimiters are. 
 


On Wed, May 5, 2021 at 2:35 AM Eric S Fraga  wrote:

On Wednesday,  5 May 2021 at 07:46, pie...@caramail.com wrote:
> Have been trying to execute multiple calc commands, but when I
> evaluate the calc expressions, I get just one result.

ob-calc returns the top element of the stack when finished and this will
be the result of the last operation in the src block.  I don't think
there's any way around this.

I use embedded Calc for this reason.  You could rewrite your equations
as simple lines (separated by empty lines from the surroundings) and
evaluate each in turn with "C-x * u":

fsolve(x 2 + x = 4, x) => x = 1.333

fsolve([x + y = a, x - y = b], [x, y]) => [x = a + (b - a) / 2, y = (a - b) / 2]

I added the "=>" at the end of each _expression_ so that the result is
shown to the right instead of replacing the _expression_ itself (default
embedded Calc behaviour).

--
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-395-g82fbdd
 

Re: [wip-cite-new] New natbib processor

[Bruce D'Arcus]

On Wed, May 5, 2021 at 10:53 AM Nicolas Goaziou  wrote:

> Another thread! Yay!

We should be close to the finish line!

> I just added a new `natbib' processor in "wip-cite-new" branch, in the
> file "oc-natbib.el"

Awesome!

> However, I'm not convinced by them [sub-styles].
>
> On the bright side, sub-styles can be put in any order, so we're
> avoiding combinatorial explosion of commands.
>
> However, they do not play well with shortcuts. For example, if shortcut
> for "caps" is "C" and "full" is "F",
>
>   [cite/text/caps/full:...] is equivalent to [cite/t/C/f:...]
>
> which is not great.

I'm just going to focus on these points.

The question comes down to whether to support sub-styles or not, and
if yes, what the syntax should be.

I think it makes more sense to include them because otherwise you end
up with an insanely long list of styles, which won't map well onto
different kinds of output formats.

E.g. biblatex users will want like 20 commands available, which won't
all work with other formats.

Also consider that for processors, they're going to have to map those
internally to something like styles+sub-styles anyway.

So I think sub-styles are good for users and developers alike.

Syntax?

I see your point on short-cuts; maybe your previous idea would work
better; a plus-separated list?

[cite:t/a+f+c]

... and the full names:

[cite:text/alt+full+caps]

Even if not perfect, I think it's a small price to pay for the benefits.

Bruce

Re: prettify-symbols-mode in org agenda?

[Ihor Radchenko]

> William Xu  writes:
>> The only issue I still see, is that when you org-agenda-redo-all, or
>> org-agenda-log-mode (which triggers org-agenda-redo-all), the
>> prettify gets lost again. Maybe org-buffer-substring-fontified call is
>> also required somewhere during org-agenda-redo-all? 
>
> I managed to reproduce it. This time, I went through all the agenda.el
> and updated places where the strings are fetched from Org buffers into
> agenda. The updated patch is attached.

Still forgot to update fontification in agenda tags view. Yet another
update...

>From ffc418abbf3169424ccfda059e7456dc33613a38 Mon Sep 17 00:00:00 2001
Message-Id: 
From: Ihor Radchenko 
Date: Tue, 4 May 2021 20:33:10 +0800
Subject: [PATCH] Make sure that fontification is preserved in agenda

* lisp/org-macs.el (org-string-width): Refactor old code and add
optional argument to return pixel width.  The old code used manual
parsing of text properties to find which parts of string are visible.
The new code defers this work to Emacs display engine via
`window-text-pixel-size'.  The visibility settings of current buffer
are taken into account.

(org--string-from-props): Removed.  It was only used by old
`org-string-width' code.

(org-buffer-substring-fontified): New function. Like
`buffer-substring', but make sure that the substring is fontified.

(org-looking-at-fontified): New function.  Like `looking-at', but make
sure that the match is fontified.

* lisp/org.el (org-get-heading): Make sure that heading is fontified.

(org--get-local-tags, org-get-tags, org-scan-tags): Add optional
argument `fontified'.  When non-nil, the returned tags are fontified.

* lisp/org-agenda.el (org-agenda-get-todos, org-agenda-get-progress,
org-agenda-get-deadlines, org-agenda-get-scheduled,
org-agenda-fix-displayed-tags, org-search-view, org-agenda-get-todos,
org-agenda-get-timestamps, org-agenda-get-sexps,
org-agenda-get-deadlines, org-agenda-get-progress,
org-agenda-get-blocks, org-tags-view): Make sure that fontification is
the same with original Org buffers.

(org-agenda-highlight-todo): Preserve composition property used,
i.e. by `prettify-symbols-mode'.  The composition is usually set to be
removed on text change, so we do the changes inside
`with-silent-modifications'.

(org-agenda-align-tags): Use pixel width and (space . :align-to)
'display property to align tags in agenda.

Preserve fontification and composition of headlines and tags in
agenda.  If the headlines/tags are not yet fontified when building
agenda, make sure that they are fontified in the original Org mode
buffers first.

In addition, tags alignment is now done pixel-wise to avoid alignment
issues with variable-pitch symbols that may appear in fontified Org
mode buffers.  The alignment is utilising :align-to specification,
which means that the alignment will be automatically updated as the
agenda buffer is resized.
---
 lisp/org-agenda.el |  96 ++--
 lisp/org-macs.el   | 134 +++--
 lisp/org.el|  36 
 3 files changed, 150 insertions(+), 116 deletions(-)

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index 4c34ca5fe..47cb7a936 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -3984,7 +3984,7 @@ (defun org-agenda-finalize ()
 		  (put-text-property (point-at-bol) (point-at-eol)
  'tags
  (org-with-point-at mrk
-   (org-get-tags
+   (org-get-tags nil nil t
 	(setq org-agenda-represented-tags nil
 	  org-agenda-represented-categories nil)
 	(when org-agenda-top-headline-filter
@@ -4778,10 +4778,11 @@ (defun org-search-view ( todo-only string edit-at)
   (and (eq org-agenda-show-inherited-tags t)
    (or (eq org-agenda-use-tag-inheritance t)
 	   (memq 'todo org-agenda-use-tag-inheritance
-			  tags (org-get-tags nil (not inherited-tags))
+			  tags (org-get-tags
+nil (not inherited-tags) t)
 			  txt (org-agenda-format-item
    ""
-   (buffer-substring-no-properties
+   (org-buffer-substring-fontified
 beg1 (point-at-eol))
    level category tags t))
 			(org-add-props txt props
@@ -5001,7 +5002,9 @@ (defun org-tags-view ( todo-only match)
 		(widen))
 		  (setq rtn (org-scan-tags 'agenda
 	   matcher
-	   org--matcher-tags-todo-only))
+	   org--matcher-tags-todo-only
+   nil
+   'fontify))
 		  (setq rtnall (append rtnall rtn
   (org-agenda--insert-overriding-header
 (with-temp-buffer
@@ -5562,7 +5565,8 @@ (defun org-agenda-get-todos ()
 	  ts-date-pair (org-agenda-entry-get-agenda-timestamp (point))
 	  ts-date (car ts-date-pair)
 	  ts-date-type (cdr ts-date-pair)
-	  txt (org-trim (buffer-substring (match-beginning 2) (match-end 0)))
+	  txt (org-trim (org-buffer-substring-fontified
+

babel output seems to drop anything before % (in session)

[Daniele Pizzolli]

Hello,

Try to execute a few times the following and see the output corrupted in
the line:

#+BEGIN_EXAMPLE
1 packets transmitted, 1 received, 0% packet loss, time 0ms
#+END_EXAMPLE

#+PROPERTY: header-args:shell
#+PROPERTY: header-args:shell+ :results output verbatim :wrap src text :session 
test

#+NAME: ping
#+BEGIN_SRC shell
ping -c 1 127.0.0.1
#+END_SRC

I tried to write a test (now with the :expected-result :failed), that
hit the problem both in main and master (applies fine to both).

I was not able to fix it, but hopefully the tests are still useful for
somebody more knowledgeable!

Thanks for you suggestion/fix!

Best,
Daniele

>From 897ae50cf055d459d741c90f8de94dd56a8eb3d9 Mon Sep 17 00:00:00 2001
From: Daniele Pizzolli 
Date: Wed, 5 May 2021 17:00:28 +0200
Subject: [PATCH 1/1] Add disabled test for % in babel shell output

---
 testing/lisp/test-ob-shell.el | 29 +
 1 file changed, 29 insertions(+)

diff --git a/testing/lisp/test-ob-shell.el b/testing/lisp/test-ob-shell.el
index 0aadb355d..a42cc3d77 100644
--- a/testing/lisp/test-ob-shell.el
+++ b/testing/lisp/test-ob-shell.el
@@ -106,6 +106,35 @@ ob-comint.el, which was not previously tested."
 	   "#+BEGIN_SRC sh :results output :var l='(1 2)\necho ${l}\n#+END_SRC"
 	   (org-trim (org-babel-execute-src-block))
 
+(ert-deftest ob-shell/percent-simple ()
+  "Test percent in output."
+  (should
+   (equal "one 0% two\ntree 0% four"
+	  (org-test-with-temp-text
+	   "#+BEGIN_SRC bash :results output verbatim\necho one 0% two\necho tree 0% four\n#+END_SRC"
+	   (org-trim (org-babel-execute-src-block)
+  (should
+   (equal "five 0% two\ntree 0% four"
+	  (org-test-with-temp-text
+	   "#+BEGIN_SRC bash :results output verbatim\necho five 0% two\necho tree 0% four\n#+END_SRC"
+	   (org-trim (org-babel-execute-src-block))
+
+(ert-deftest ob-shell/percent-session ()
+  "Test percent in output for session.
+
+At the second iteration the string before % is dropped."
+  :expected-result :failed
+  (should
+   (equal "one 0% two\ntree 0% four"
+	  (org-test-with-temp-text
+	   "#+BEGIN_SRC bash :results output verbatim :session sess\necho one 0% two\necho tree 0% four\n#+END_SRC"
+	   (org-trim (org-babel-execute-src-block)
+  (should
+   (equal "five 0% six\nseven 0% eight"
+	  (org-test-with-temp-text
+	   "#+BEGIN_SRC bash :results output verbatim :session sess\necho five 0% six\necho seven 0% eight\n#+END_SRC"
+	   (org-trim (org-babel-execute-src-block))
+
 (provide 'test-ob-shell)
 
 ;;; test-ob-shell.el ends here
-- 
2.29.2

Re: Multiple calc commands with orgbabel

[Matt Price]

Can you explain how you get calc embedded mode working in org? I have never
used it and it sounds interesting, but I don't understand what hte
delimiters are.

On Wed, May 5, 2021 at 2:35 AM Eric S Fraga  wrote:

> On Wednesday,  5 May 2021 at 07:46, pie...@caramail.com wrote:
> > Have been trying to execute multiple calc commands, but when I
> > evaluate the calc expressions, I get just one result.
>
> ob-calc returns the top element of the stack when finished and this will
> be the result of the last operation in the src block.  I don't think
> there's any way around this.
>
> I use embedded Calc for this reason.  You could rewrite your equations
> as simple lines (separated by empty lines from the surroundings) and
> evaluate each in turn with "C-x * u":
>
> fsolve(x 2 + x = 4, x) => x = 1.333
>
> fsolve([x + y = a, x - y = b], [x, y]) => [x = a + (b - a) / 2, y = (a -
> b) / 2]
>
> I added the "=>" at the end of each expression so that the result is
> shown to the right instead of replacing the expression itself (default
> embedded Calc behaviour).
>
> --
> : Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-395-g82fbdd
>
>

[wip-cite-new] New natbib processor

[Nicolas Goaziou]

Hello,

Another thread! Yay!

I just added a new `natbib' processor in "wip-cite-new" branch, in the
file "oc-natbib.el"

--8<---cut here---start->8---
This library registers the `natbib' citation processor, which provides
the "export" capability for citations.

The processor relies on "natbib" LaTeX package. As such it ensures that
the package is properly required in the generated document. More
precisely, it will use any "\\usepackage{natbib}" command already
present in the document (e.g., through `org-latex-packages-alist'), or
insert one using options defined in `org-cite-natbib-options'.

It supports the following citation styles, in addition to the default
author-year format: "text" or "t", "author" or "a", "year" or "y".

It also supports the following sub-styles: "caps", "alt", and
"full".

Bibliography accepts any style supported by natbib package.
--8<---cut here---end--->8---

As noted, this processor implements "sub-styles", i.e. additional styles
separated with forward slash character. E.g.,

  [cite/text/alt/full:...]  => \citealt*{...}

  [cite//alt/caps:...]  => \Citealp{...}   (// means default style)

However, I'm not convinced by them. 

On the bright side, sub-styles can be put in any order, so we're
avoiding combinatorial explosion of commands.

However, they do not play well with shortcuts. For example, if shortcut
for "caps" is "C" and "full" is "F",

  [cite/text/caps/full:...] is equivalent to [cite/t/C/f:...]

which is not great. Also it introduces ambiguities in style inheritance.
For example, if I add

  #+cite_export: natbib plainnat text

would 

  [cite//alt/caps:...]

mean

  [cite/text/alt/caps:...]   (i.e., \Citealt{...})

or really

  [cite//alt/caps:]  (i.e., \Citealp{...})

?

I'd favor keeping only one level for styles is more reasonable. It means
implementing one style for each variant, e.g., "text-alt-caps" where the
order matters ("text-caps-alt" may not be supported), but it permits
more compact shortcuts, e.g., "Alt" for "text-alt-caps"). It also
eschews the inheritance pitfall above.

Also, completion front-ends can alleviate the burden of memorizing all
those styles.

Anyway, for now it's sub-styles. Please let me know what you think about
them, and about the processor, in general. I couldn't test it much
because the test bibliography I have is apparently "not compatible with
author-year citations".

As a reminder, to test it, you (require 'oc-natbib) to register the
processor, and add "#+cite_export: natbib" in your document (or set
`org-cite-export-processor' to (natbib)).

Regards,
-- 
Nicolas Goaziou

Re: Notes about citations in Org (part 3)

[Nicolas Goaziou]

Hello,

András Simonyi  writes:

> this is just to indicate that I've started to look into the
> wip-cite-new branch with an eye on updating citeproc-org to use the
> new API -- everything seems to be working perfectly, thanks again for
> this, Nicholas! One issue I also noticed is the separation of citation
> style and bibliography style, which does not exist in CSL.
> Accordingly, it would be nice to have ways of specifying a single
> style for both of them (both in the Org syntax and in the Liisp API),
> if this is not possible already.

I don't think this is necessary. 

My (is it mine actually? I can't tell with all the discussions going on)
choice of "style" name for citations and bibliography may be
unfortunate. Actually citations/bibliography styles do not have to match
a known style in CSL. More precisely, the bibliography style is probably
close to what is expected by CSL, but I see citations styles more as
internal variants.

For example, one processor could implement an "draft" citation style
where the citation is in the document, but it isn't even processed
during export. So I think the single style you're talking about is
really the bibliography style.

Does that make sense?

Regards,
-- 
Nicolas Goaziou

Re: tangling seems to have broken today

[Eric S Fraga]

On Wednesday,  5 May 2021 at 14:17, Sébastien Miquel wrote:
> Eric S Fraga writes:
>> I was using org-babel-tangle.  Although, in this case, with C-u before
>> to tangle just the particular block.
> Indeed, I have broken this. I'll provide a patch, shortly.

Thank you!  And I should have given full details earlier. 

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-395-g82fbdd

Re: tangling seems to have broken today

[Sébastien Miquel]

Eric S Fraga writes:

I was using org-babel-tangle.  Although, in this case, with C-u before
to tangle just the particular block.

Indeed, I have broken this. I'll provide a patch, shortly.

--
Sébastien Miquel

Re: Notes about citations in Org (part 3)

[Nicolas Goaziou]

Hello,

"Bruce D'Arcus"  writes:

> On Tue, May 4, 2021 at 12:59 PM Nicolas Goaziou  
> wrote:
>
>> AFAIU, the idea is to use styles from you wiki. However, sub-styles are
>> not mentioned. They could be "full" for the starred variants, "caps" for
>> the capitalized ones, and "alt" for those without parenthesis, so one
>> could write:
>
> "Alt" and "full" I understand.
>
> By "caps", you're referring to the biblatex variants?

I'm referring to \Citep vs. \citep natbib variants.
>
> Does this basically mean "force initial capitalization"?

Indeed.

Regards,
-- 
Nicolas Goaziou

Re: Question about citation processors [wip-cite branch]

[Nicolas Goaziou]

Hello,

Joost Kremers  writes:

> The docstring talks about a "citation object", and the "citation or citation
> reference object at point". Do I assume correctly that these are structures as
> returned by =org-element-parse-buffer=?

That's correct. The citation contains the global prefix and suffix, each
reference contains the local prefix and suffix, and the citation key.

You can then use functions like `org-cite-get-references' and
`org-cite-key-boundaries' on them, in addition to usual
`org-element-property'.

Regards,
-- 
Nicolas Goaziou

Re: tangling seems to have broken today

[Eric S Fraga]

On Wednesday,  5 May 2021 at 13:54, Sébastien Miquel wrote:
> What command are you using ?
>
> Running `org-babel-tangle` works for me with latest master using your
> example.

I was using org-babel-tangle.  Although, in this case, with C-u before
to tangle just the particular block.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-395-g82fbdd

Re: tangling seems to have broken today

[Sébastien Miquel]

Hi Eric, Timothy,

Eric S Fraga writes:

I can no longer tangle with a given file name.  The error I get
indicates that the tangling procedure is looking at the first line of
the actual code block.

What command are you using ?

Running `org-babel-tangle` works for me with latest master using your
example.


--
Sébastien Miquel

Re: Bug: [PATCH] org-babel-tangle: persmission denied when tangling [9.4.5 (9.4.5-gbc2659 @ /home/n/.emacs.d/straight/build/org/)]

[No Wayman]

Sébastien Miquel  writes:

Here's another patch, to be applied on top of the previous one, 
that

fixes this.

The specific case you mention can also be achieved by setting 
the
:tangle argument to `yes`: in this case, the tangled file name 
is

computed using the buffer file name and changing the extension
according to the src block language.


Thanks for the tip. I probably added that years ago and haven't 
changed it.

Updated to keep things simple.

Thank you again for the report, and sorry for breaking 
everything.



Thanks for the patches. Tested them and everything seems to be 
working OK.

Re: wip-cite status question and feedback

[Bruce D'Arcus]

On Sun, May 2, 2021 at 6:18 PM Bruce D'Arcus  wrote:

> On Sun, May 2, 2021 at 5:59 PM Denis Maier  wrote:
>
> > I'm thinking whether this could make the system more flexible and
> > adaptable.
>
> We'd still need to discuss details of course (like including sensible
> defaults, etc.) if this were possible, but Denis and I agree that
> having a second optional parameter as a function would be ideal.

If this is NOT practical, just to summarize what we've learned/concluded:

Assuming this basic example:

A sentence ending in a "cited quote" [cite:doe].

We found three rules:

1. what Chicago calls "American"
2. what it calls "British"
3. French (though Denis is still confirming how these work in actual books)

The output in each, when formatting as a note:

1. A sentence ending in a "cited quote."[1]
2. A sentence ending in a "cited quote".[1]
3. A sentence ending in a "cited quote[1]."

Note: Nicolas' POC correctly handles case 1.

Can be hard to see the nuances, but note that all three move the
punctuation, and remove the space between quote and note mark.

The difference is how they reassemble these components; in particular
where they put that trailing punctuation (period, etc.), and where
they put the note mark.

1. move punctuation inside quote
2. move punctuation outside quote
3. move note mark AND then punctuation inside quote

It could be they each need a boolean parameter, similar to what I
suggested earlier.

Then "American" (current) could be:

- punctuation-inside-quote t
- mark-inside-quote nil

"British" could be:

- punctuation-inside-quote nil
- mark-inside-quote nil

And "french":

- punctuation-inside-quote t
- mark-inside-quote t

But a potential (?) problem with this is one couldn't specify the
relative order of punctuation and note mark.

So Denis had an idea to simply allow the order of those components to
be configured, something like this (the lisp is probably wrong, but it
demonstrates the idea):

`(final-punct trailing-punct closing-quotation citation)

I think that covers current status.

So what to do?

Bruce

PS - we know, this seems a lot of effort for what seems a corner case.
But there will be some users for which this matters a lot.

Re: tangling seems to have broken today

[Bastien]

Timothy  writes:

> I'd just like to chime in to note that I am also experiencing this
> issue.

Thanks, I guess Sébastien will be able to fix it.

If you and Eric can find how to fix this while addressing the original
issue Sébastien was trying to resolve, feel free to go ahead.

-- 
 Bastien

Re: tangling seems to have broken today

[Timothy]

I'd just like to chime in to note that I am also experiencing this issue.

Eric S Fraga  writes:

> I note that the git log shows a commit which affects tangling: 501b2a191
>
> I can no longer tangle with a given file name.  The error I get
> indicates that the tangling procedure is looking at the first line of
> the actual code block.  For instance, if I have
>
> #+begin_src org
>   ,#+begin_src julia :exports none :results output :tangle "svfmon.jl"
> using DigitalFilter
> ...
>   ,#+end_src
> #+end_src
>
> the error message when trying to tangle says:
>
> Wrong type argument: listp, "using DigitalFilter
>
> followed by the full src block in the *Messages* buffer.  So it seems
> that the search for the file name is using the contents of the block.
>
> Switching to the wip-cite-new branch (since I'm playing with that in any
> case) solves the problem for me so no panic.
>
> thank you,
> eric

tangling seems to have broken today

[Eric S Fraga]

I note that the git log shows a commit which affects tangling: 501b2a191

I can no longer tangle with a given file name.  The error I get
indicates that the tangling procedure is looking at the first line of
the actual code block.  For instance, if I have

#+begin_src org
  ,#+begin_src julia :exports none :results output :tangle "svfmon.jl"
using DigitalFilter
...
  ,#+end_src
#+end_src

the error message when trying to tangle says:

Wrong type argument: listp, "using DigitalFilter

followed by the full src block in the *Messages* buffer.  So it seems
that the search for the file name is using the contents of the block.

Switching to the wip-cite-new branch (since I'm playing with that in any
case) solves the problem for me so no panic.

thank you,
eric

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-505-g0a651b

Re: Notes about citations in Org (part 3)

[Eric S Fraga]

On Wednesday,  5 May 2021 at 05:37, Bruce D'Arcus wrote:
> Does it have any more commands than \cite and \nocite?

Vanilla LaTeX has only \cite and \nocite (page 74ff of the original book
by Leslie Lamport).

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-503-g501b2a

Re: Notes about citations in Org (part 3)

[Denis Maier]

Am 05.05.2021 um 11:37 schrieb Bruce D'Arcus:



On Wed, May 5, 2021, 1:48 AM Eric S Fraga > wrote:


On Tuesday,  4 May 2021 at 18:59, Nicolas Goaziou wrote:
 > Is the default \cite{key} command (without any other package) used?

Yes, it is.  But I wouldn't be able to tell you anything about relative
frequency etc.


Does it have any more commands than \cite and \nocite?

Bruce



I don't think so.

Denis

Re: Notes about citations in Org (part 3)

[Bruce D'Arcus]

On Wed, May 5, 2021, 1:48 AM Eric S Fraga  wrote:

> On Tuesday,  4 May 2021 at 18:59, Nicolas Goaziou wrote:
> > Is the default \cite{key} command (without any other package) used?
>
> Yes, it is.  But I wouldn't be able to tell you anything about relative
> frequency etc.
>

Does it have any more commands than \cite and \nocite?

Bruce

>

bug#47088: org-w3m: handle w3m-image link information

[Bastien]

Boruch Baum  writes:

> Attached is a patch that adds to function `org-w3m-copy-for-org-mode'
> support for w3m-image links. Note that because function
> `org-make-link-string' is used for constructing the buffer substring to
> be copied, w3m's special face to distinguish an image link is not
> transfered.

Thanks, it looks good.

Can you try updating the patch against Org's upstream repository at
https://code.orgmode.org/bzg/org-mode/?

Note that the file is lisp/ol-w3m.el there.

-- 
 Bastien

Re: Multiple calc commands with orgbabel

[pietru]

> Sent: Wednesday, May 05, 2021 at 7:59 PM
> From: "Eric S Fraga" 
> To: pie...@caramail.com
> Cc: emacs-orgmode@gnu.org
> Subject: Re: Multiple calc commands with orgbabel
>
> On Wednesday,  5 May 2021 at 09:26, pie...@caramail.com wrote:
> > Does anybody has some experience using calc for factoring, matrix
> > computation and taking derivatives.  The manual overwhelmed me.
>
> You might be better off asking on the Emacs help list as this is rather
> off-topic for the org mailing list.

Fair enough.

> --
> : Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-503-g501b2a
>

Re: Multiple calc commands with orgbabel

[Eric S Fraga]

On Wednesday,  5 May 2021 at 09:26, pie...@caramail.com wrote:
> Does anybody has some experience using calc for factoring, matrix
> computation and taking derivatives.  The manual overwhelmed me.

You might be better off asking on the Emacs help list as this is rather
off-topic for the org mailing list.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-503-g501b2a

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

[Bastien]

Bastien  writes:

> Various discussions convinced me that `org-adapt-indentation' should
> be nil by default.

It is now, as of commit 0a651b746.

Thank you all very much for your feedback on this.

-- 
 Bastien

Re: Multiple calc commands with orgbabel

[pietru]

Does anybody has some experience using calc for factoring, matrix computation 
and
taking derivatives.  The manual overwhelmed me.


> Sent: Wednesday, May 05, 2021 at 7:23 PM
> From: "Eric S Fraga" 
> To: "Dr. Arne Babenhauserheide" 
> Cc: pie...@caramail.com, emacs-orgmode@gnu.org
> Subject: Re: Multiple calc commands with orgbabel
>
> On Wednesday,  5 May 2021 at 09:12, Dr. Arne Babenhauserheide wrote:
> > could you try the header :results output?
>
> Doesn't make any difference as Calc itself does not actually output
> anything.  All results are put on the stack.
>
> --
> : Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-503-g501b2a
>

Re: orgbabel with fortran code

[pietru]

> Sent: Wednesday, May 05, 2021 at 7:20 PM
> From: "Eric S Fraga" 
> To: pie...@caramail.com
> Cc: "help Emacs Orgmode" 
> Subject: Re: orgbabel with fortran code
>
> On Wednesday,  5 May 2021 at 09:14, pie...@caramail.com wrote:
> > The code is fantastic, but how may I run it exactly?  Using "C-c C-c"
> > tells me "'C-c C-c' can do nothing useful here".
>
> You may need to evaluate (require 'ob-fortran) in your init files.

Yes, have done that.

> --
> : Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-503-g501b2a
>
>

Re: orgbabel with fortran code

[pietru]

Have you got exomples with fortran code yourself?  I would like to scrutinise 
them. 
 
> Sent: Wednesday, May 05, 2021 at 7:14 PM
> From: "Dr. Arne Babenhauserheide" 
> To: pie...@caramail.com
> Cc: emacs-orgmode@gnu.org
> Subject: Re: orgbabel with fortran code
>
> 
> pie...@caramail.com writes:
> 
> > Have been looking to find some examples on using orgbabel with fortran code
> > but have not found information.
> 
> Fortran is listed as supported on
> https://orgmode.org/worg/org-contrib/babel/languages/index.html
> so I would hope that the standard tipps there apply.
> 
> Best wishes,
> Arne
> -- 
> Unpolitisch sein
> heißt politisch sein
> ohne es zu merken
>

Re: Multiple calc commands with orgbabel

[Eric S Fraga]

On Wednesday,  5 May 2021 at 09:12, Dr. Arne Babenhauserheide wrote:
> could you try the header :results output?

Doesn't make any difference as Calc itself does not actually output
anything.  All results are put on the stack.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-503-g501b2a

Re: Multiple calc commands with orgbabel

[pietru]

I still get the lost result

#+begin_src calc :results output
  fsolve(x*2+x=4,x)
  fsolve([x + y = a, x - y = b],[x,y])
#+end_src

#+RESULTS:
: [x = a + (b - a) / 2, y = (a - b) / 2]




> Sent: Wednesday, May 05, 2021 at 7:12 PM
> From: "Dr. Arne Babenhauserheide" 
> To: pie...@caramail.com
> Cc: emacs-orgmode@gnu.org
> Subject: Re: Multiple calc commands with orgbabel
>
> 
> pie...@caramail.com writes:
> 
> > Have been trying to execute multiple calc commands, but when I evaluate the 
> > calc
> > expressions, I get just one result.
> 
> could you try the header :results output?
> 
> Best wishes,
> Arne
> -- 
> Unpolitisch sein
> heißt politisch sein
> ohne es zu merken
>

Re: orgbabel with fortran code

[Eric S Fraga]

On Wednesday,  5 May 2021 at 09:14, pie...@caramail.com wrote:
> The code is fantastic, but how may I run it exactly?  Using "C-c C-c"
> tells me "'C-c C-c' can do nothing useful here".

You may need to evaluate (require 'ob-fortran) in your init files.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-503-g501b2a

Re: orgbabel with fortran code

[pietru]

> Sent: Wednesday, May 05, 2021 at 6:52 PM
> From: "Eric S Fraga" 
> To: pie...@caramail.com
> Cc: "help Emacs Orgmode" 
> Subject: Re: orgbabel with fortran code
>
> On Wednesday,  5 May 2021 at 08:37, pie...@caramail.com wrote:
> > Make a function and then run it with different values.
>
> Have a look at the attachment.  Doesn't create a /function/ in the
> Fortran sense but shows how you can definitely call some code with
> different values.

Thank you so very much, I will check it out.

> That's about all I can help with as it's been years since I used Fortran
> (although I did cut my teeth on Fortran 66... ;-)).

Is there anyone in particular who would know some more things about fortran
in org-babel?

> --
> : Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-395-g82fbdd
>

Re: orgbabel with fortran code

[pietru]

The code is fantastic, but how may I run it exactly?  Using "C-c C-c"
tells me "'C-c C-c' can do nothing useful here".

> Sent: Wednesday, May 05, 2021 at 6:52 PM
> From: "Eric S Fraga" 
> To: pie...@caramail.com
> Cc: "help Emacs Orgmode" 
> Subject: Re: orgbabel with fortran code
>
> On Wednesday,  5 May 2021 at 08:37, pie...@caramail.com wrote:
> > Make a function and then run it with different values.
>
> Have a look at the attachment.  Doesn't create a /function/ in the
> Fortran sense but shows how you can definitely call some code with
> different values.
>
> That's about all I can help with as it's been years since I used Fortran
> (although I did cut my teeth on Fortran 66... ;-)).
>
> --
> : Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-395-g82fbdd
>

Re: Multiple calc commands with orgbabel

[Dr. Arne Babenhauserheide]

pie...@caramail.com writes:

> Have been trying to execute multiple calc commands, but when I evaluate the 
> calc
> expressions, I get just one result.

could you try the header :results output?

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: orgbabel with fortran code

[Dr. Arne Babenhauserheide]

pie...@caramail.com writes:

> Have been looking to find some examples on using orgbabel with fortran code
> but have not found information.

Fortran is listed as supported on
https://orgmode.org/worg/org-contrib/babel/languages/index.html
so I would hope that the standard tipps there apply.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: Bug: [PATCH] org-babel-tangle: persmission denied when tangling [9.4.5 (9.4.5-gbc2659 @ /home/n/.emacs.d/straight/build/org/)]

[Bastien]

Sébastien Miquel  writes:

> Here's another patch, to be applied on top of the previous one, that
> fixes this.

Applied, thanks.

-- 
 Bastien

Re: orgbabel with fortran code

[Eric S Fraga]

On Wednesday,  5 May 2021 at 08:37, pie...@caramail.com wrote:
> Make a function and then run it with different values.

Have a look at the attachment.  Doesn't create a /function/ in the
Fortran sense but shows how you can definitely call some code with
different values.

That's about all I can help with as it's been years since I used Fortran
(although I did cut my teeth on Fortran 66... ;-)).

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-395-g82fbdd
* testing ob fortran
#+name: ftest
#+begin_src fortran :var m=20 :var n=30 :results output
  real, dimension(m,n) :: a
  real, dimension(n,m) :: c
  real, dimension(m) :: b
  integer :: i
  print *, m, n
  a = reshape( (/ (real(i), i=1,m*n) /), (/ m, n /) )
  b = (/ (2*i, i=1,m) /)
  c = reshape( a, (/ n, m /) )
  print *, b
#+end_src

#+results: ftest
: 20  30
: 2.   4.   6.   8.   10.000   12.000   14.000   16.000   18.000   20.000   22.000   24.000   26.000   28.000   30.000   32.000   34.000   36.000   38.000   40.000

#+results:
: 2.   4.   6.   8.   10.000   12.000   14.000   16.000   18.000   20.000   22.000   24.000   26.000   28.000   30.000   32.000   34.000   36.000   38.000   40.000

#+call: ftest(m=10,n=40)

#+results:
: 10  40
: 2.   4.   6.   8.   10.000   12.000   14.000   16.000   18.000   20.000

#+call: ftest(m=20,n=10)

#+results:
: 20  10
: 2.   4.   6.   8.   10.000   12.000   14.000   16.000   18.000   20.000   22.000   24.000   26.000   28.000   30.000   32.000   34.000   36.000   38.000   40.000

Re: Bug: [PATCH] org-babel-tangle: persmission denied when tangling [9.4.5 (9.4.5-gbc2659 @ /home/n/.emacs.d/straight/build/org/)]

[Sébastien Miquel]

No Wayman writes:

Another related bug to the changes:

I have the :tangle header-arg set to evaluate some elisp to return the 
file name:


org-babel no longer interprets this elisp. It is being used literally 
as the file name:

e.g.

Wrote /home/n/.emacs.d/(concat (file-name-sans-extension 
(buffer-file-name)) ".el") 

Here's another patch, to be applied on top of the previous one, that
fixes this.

The specific case you mention can also be achieved by setting the
:tangle argument to `yes`: in this case, the tangled file name is
computed using the buffer file name and changing the extension
according to the src block language.


Thank you again for the report, and sorry for breaking everything.

--
Sébastien Miquel

>From b7c5103fdd05c3d30805ebcc5084ef82c44cd8ff Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= 
Date: Wed, 5 May 2021 08:31:43 +0200
Subject: [PATCH] ob-tangle.el: (org-babel-tangle-collect-blocks): Use correct
 tangle name

* lisp/ob-tangle.el: (org-babel-tangle-collect-blocks): Use correct
tangle name.

The :tangle header argument might be some elisp, to be evaluated.
---
Range-diff:
-:  - > 1:  b7c5103fd ob-tangle.el: (org-babel-tangle-collect-blocks): Use correct tangle name

 lisp/ob-tangle.el | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lisp/ob-tangle.el b/lisp/ob-tangle.el
index 96a4ef049..8af03b11a 100644
--- a/lisp/ob-tangle.el
+++ b/lisp/ob-tangle.el
@@ -377,6 +377,7 @@ be used to limit the collected code blocks by target file."
 	;; Add the spec for this block to blocks under its tangled
 	;; file name.
 	(let* ((block (org-babel-tangle-single-block counter))
+   (src-tfile (cdr (assq :tangle (nth 4 block
 		   (base-name (cond
 			   ((string= "yes" src-tfile)
 ;; buffer name
-- 
2.31.1

Re: Multiple calc commands with orgbabel

[pietru]

> Sent: Wednesday, May 05, 2021 at 6:41 PM
> From: "Eric S Fraga" 
> To: pie...@caramail.com
> Cc: "help Emacs Orgmode" 
> Subject: Re: Multiple calc commands with orgbabel
>
> On Wednesday,  5 May 2021 at 08:40, pie...@caramail.com wrote:
> >> ob-calc returns the top element of the stack when finished and this will
> >> be the result of the last operation in the src block.  I don't think
> >> there's any way around this.
> >
> > Is the top stack element just with ob-calc?
>
> I am not sure what you are asking here.  Other languages do not have the
> concept of a stack necessarily.  However, for other languages, there is
> often the option to have the results be "output" instead of "value".

I understand, thank you.

>
> --
> : Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-395-g82fbdd
>
>

Re: Bug: org-babel-tangle: persmission denied when tangling [9.4.5 (9.4.5-gbc2659 @ /home/n/.emacs.d/straight/build/org/)]

[Bastien]

Hi Sébastien,

Sébastien Miquel  writes:

> It reverts a part of a2cb9b853: permissions are no longer set before writing
> to the tangled file.

Applied to master, thanks a lot.

-- 
 Bastien

Re: Multiple calc commands with orgbabel

[Eric S Fraga]

On Wednesday,  5 May 2021 at 08:40, pie...@caramail.com wrote:
>> ob-calc returns the top element of the stack when finished and this will
>> be the result of the last operation in the src block.  I don't think
>> there's any way around this.
>
> Is the top stack element just with ob-calc?

I am not sure what you are asking here.  Other languages do not have the
concept of a stack necessarily.  However, for other languages, there is
often the option to have the results be "output" instead of "value".


-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-395-g82fbdd

Re: Multiple calc commands with orgbabel

[pietru]

> Sent: Wednesday, May 05, 2021 at 6:33 PM
> From: "Eric S Fraga" 
> To: pie...@caramail.com
> Cc: "help Emacs Orgmode" 
> Subject: Re: Multiple calc commands with orgbabel
>
> On Wednesday,  5 May 2021 at 07:46, pie...@caramail.com wrote:
> > Have been trying to execute multiple calc commands, but when I
> > evaluate the calc expressions, I get just one result.
>
> ob-calc returns the top element of the stack when finished and this will
> be the result of the last operation in the src block.  I don't think
> there's any way around this.

Is the top stack element just with ob-calc?

> I use embedded Calc for this reason.  You could rewrite your equations
> as simple lines (separated by empty lines from the surroundings) and
> evaluate each in turn with "C-x * u":
>
> fsolve(x 2 + x = 4, x) => x = 1.333
>
> fsolve([x + y = a, x - y = b], [x, y]) => [x = a + (b - a) / 2, y = (a - b) / 
> 2]
>
> I added the "=>" at the end of each expression so that the result is
> shown to the right instead of replacing the expression itself (default
> embedded Calc behaviour).

Will check it out, thanks.

> --
> : Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-395-g82fbdd
>
>

Re: orgbabel with fortran code

[pietru]

Make a function and then run it with different values.

> Sent: Wednesday, May 05, 2021 at 6:24 PM
> From: "Eric S Fraga" 
> To: pie...@caramail.com
> Cc: "help Emacs Orgmode" 
> Subject: Re: orgbabel with fortran code
>
> On Wednesday,  5 May 2021 at 07:41, pie...@caramail.com wrote:
> > Have been looking to find some examples on using orgbabel with fortran code
> > but have not found information.
>
> What is it you wish to do?
> --
> : Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-395-g82fbdd
>
>

Re: Multiple calc commands with orgbabel

[Eric S Fraga]

On Wednesday,  5 May 2021 at 07:46, pie...@caramail.com wrote:
> Have been trying to execute multiple calc commands, but when I
> evaluate the calc expressions, I get just one result.

ob-calc returns the top element of the stack when finished and this will
be the result of the last operation in the src block.  I don't think
there's any way around this.

I use embedded Calc for this reason.  You could rewrite your equations
as simple lines (separated by empty lines from the surroundings) and
evaluate each in turn with "C-x * u":

fsolve(x 2 + x = 4, x) => x = 1.333

fsolve([x + y = a, x - y = b], [x, y]) => [x = a + (b - a) / 2, y = (a - b) / 2]

I added the "=>" at the end of each expression so that the result is
shown to the right instead of replacing the expression itself (default
embedded Calc behaviour).

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-395-g82fbdd

Re: orgbabel with fortran code

[Eric S Fraga]

On Wednesday,  5 May 2021 at 07:41, pie...@caramail.com wrote:
> Have been looking to find some examples on using orgbabel with fortran code
> but have not found information.

What is it you wish to do?  
-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-395-g82fbdd

Re: Notes about citations in Org (part 3)

[Eric S Fraga]

On Tuesday,  4 May 2021 at 21:04, András Simonyi wrote:
> One issue I also noticed is the separation of citation
> style and bibliography style, which does not exist in CSL.
> Accordingly, it would be nice to have ways of specifying a single
> style for both of them (both in the Org syntax and in the Liisp API),
> if this is not possible already.

And to add that the default LaTeX citation support also does not
separate citation style from bibliography style, both being defined by
the single \bibliographystyle{} command.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-395-g82fbdd