Displaying equations with ob-latex

[Christopher Dimech]

Barry has shown how to use "C-c C-x C-l" (org-latex-preview  ARG)
to preview a latex fragment at point.

I then see no point in enclosing latex commands in "#+begin_src" and 
"#+end_src";
because one can just write any lates expression an a line such as below, them 
slamming
it with "C-c C-x C-l".

\(y = x\beta + \epsilon\)

Is there a related command that previews all equations in the buffer, rather 
than
only for a latex fragment at point.

With a bit more work ob-latex can be pleasantly improved.

Another comment is to allow the use of "plain tex", because one can then copy
from texinfo math commands. In the last few months, texinfo was greatly improved
for working with math (e.g. preview with mathjax, easy scaling with mouse 
wheel).

The same could happen with ob-latex.

> Sent: Friday, May 07, 2021 at 3:36 PM
> From: michael-franz...@gmx.com
> To: "Ihor Radchenko" 
> Cc: "Berry, Charles" , "Help Emacs Orgmode" 
> 
> Subject: Re: displaying equations with ob-latex
>
> Another downside is that you got to slam "C-c C-x C-l" for every equation one 
> writes
> in the drawer.  The solution is not very usable but at least I could display 
> equations
> as I do with texinfo from org.  But for serious work, I need to be fast.  
> Currently
> it will be frustrating enough for users.
>
> > Sent: Friday, May 07, 2021 at 3:14 PM
> > From: "Ihor Radchenko" 
> > To: michael-franz...@gmx.com
> > Cc: "Berry, Charles" , "Help Emacs Orgmode" 
> > 
> > Subject: Re: displaying equations with ob-latex
> >
> > michael-franz...@gmx.com writes:
> >
> > > Ok, I got some progress, I did "C-C C-x C-l" and got the equation.
> > >
> > > The equation in extremely small though.
> >
> > By default, it should have the same height with you text line.
> > You can change it though. I have the following snippet in my config:
> >
> > (setq org-format-latex-options
> >   (quote
> >(:foreground default :background default :scale 2.0 :justify center 
> > :html-foreground "Black" :html-background "Transparent" :html-scale 1.0 
> > :matchers
> > ("begin" "$1" "$" "$$" "\\(" "\\[";; 2x height of 
> > formulas
> >
>
>

Re: none

[Bastien]

Hi Krupal,

thanks a lot for offering to maintain Worg!  Very much appreciated,
I'm confident this is very good news for anyone relying on Worg.

Please send me an email with the username you want for an account
on https://code.orgmode.org, I will then add you as a committer.

Best,

-- 
 Bastien

Re: Multiple calc commands with orgbabel

[Bastien]

Hi Tom,

that's really kind of you!  Thanks a lot.

If other people share the last name of original authors of 
ob-* files, please raise your voice and ask for your share :)

Best,

-- 
 Bastien

Re: [IMPORTANT] The contrib/ directory now lives outside of Org's repository

[Bastien]

Hi Jonas,

thanks a lot for your guidance, I've committed your version.

Thanks!

-- 
 Bastien

Re: displaying equations with ob-latex

[michael-franzese]

Another downside is that you got to slam "C-c C-x C-l" for every equation one 
writes
in the drawer.  The solution is not very usable but at least I could display 
equations
as I do with texinfo from org.  But for serious work, I need to be fast.  
Currently
it will be frustrating enough for users.

> Sent: Friday, May 07, 2021 at 3:14 PM
> From: "Ihor Radchenko" 
> To: michael-franz...@gmx.com
> Cc: "Berry, Charles" , "Help Emacs Orgmode" 
> 
> Subject: Re: displaying equations with ob-latex
>
> michael-franz...@gmx.com writes:
>
> > Ok, I got some progress, I did "C-C C-x C-l" and got the equation.
> >
> > The equation in extremely small though.
>
> By default, it should have the same height with you text line.
> You can change it though. I have the following snippet in my config:
>
> (setq org-format-latex-options
>   (quote
>(:foreground default :background default :scale 2.0 :justify center 
> :html-foreground "Black" :html-background "Transparent" :html-scale 1.0 
> :matchers
>   ("begin" "$1" "$" "$$" "\\(" "\\[";; 2x height of 
> formulas
>

Bug: Custom Drawers - Contents show in HTML export [9.4.4 (release_9.4.4 @ /snap/emacs/current/usr/share/emacs/27.2/lisp/org/)]

[zar...@global.co.za]

--text follows this line--

Drawers as I understand them should be hidden in any output at least
that is what the build-in drawers do.

Also from what I understand is that you don't have to "declare" custom
drawers any more.

When I try to use a custom drawer and export to HTML the contents of the
drawer is
output to the resulting HTML. But not the drawer name and end tags.

Started emacs -Q to confirm behaviour.

Attached is a minimal .org to reproduce what I see. Also attached is the
exported .html file.

I am running the snap version of emacs 27.2 but I can confirm that it
also happens in org 9.3 which is in the apt version of emacs (27.1 build
1) on Ubuntu 21.04.






Emacs  : GNU Emacs 27.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.20, cairo version 1.16.0)
 of 2021-03-26
Package: Org mode version 9.4.4 (release_9.4.4 @
/snap/emacs/current/usr/share/emacs/27.2/lisp/org/)

current state:
==
(setq
 org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
 org-link-shell-confirm-function 'yes-or-no-p
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
 org-html-format-inlinetask-function
'org-html-format-inlinetask-default-function
 org-odt-format-headline-function 'org-odt-format-headline-default-function
 org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
 org-mode-hook '(#[0 "\301\211 \207" [imenu-create-index-function
org-imenu-get-tree] 2]
#[0 "\300\301\302\303\304$\207"
  [add-hook change-major-mode-hook org-show-all append local] 5]
#[0 "\300\301\302\303\304$\207"
  [add-hook change-major-mode-hook org-babel-show-result-all append local]
5]
org-babel-result-hide-spec org-babel-hide-all-hashes)
 org-odt-format-drawer-function #[514 "\207" [] 3 "\n\n(fn NAME CONTENTS)"]
 org-archive-hook '(org-attach-archive-delete-maybe)
 org-confirm-elisp-link-function 'yes-or-no-p
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-metaup-hook '(org-babel-load-in-session-maybe)
 org-bibtex-headline-format-function #[257 "\300 \236A\207" [:title] 3
"\n\n(fn ENTRY)"]
 org-latex-format-drawer-function #[514 "\207" [] 3 "\n\n(fn _ CONTENTS)"]
 org-babel-pre-tangle-hook '(save-buffer)
 org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
 org-ascii-format-drawer-function #[771 " \207" [] 4 "\n\n(fn NAME CONTENTS
WIDTH)"]
 org-agenda-loop-over-headlines-in-active-region nil
 org-occur-hook '(org-first-headline-recenter)
 org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
 org-cycle-show-empty-lines org-optimize-window-after-visibility-change)
 org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
 org-odt-format-inlinetask-function
'org-odt-format-inlinetask-default-function
 org-export-before-parsing-hook '(org-attach-expand-links)
 org-confirm-shell-link-function 'yes-or-no-p
 org-link-parameters '(("attachment" :follow org-attach-follow :complete
org-attach-complete-link)
  ("id" :follow org-id-open)
  ("eww" :follow org-eww-open :store org-eww-store-link)
  ("rmail" :follow org-rmail-open :store org-rmail-store-link)
  ("mhe" :follow org-mhe-open :store org-mhe-store-link)
  ("irc" :follow org-irc-visit :store org-irc-store-link :export
org-irc-export)
  ("info" :follow org-info-open :export org-info-export :store
org-info-store-link)
  ("gnus" :follow org-gnus-open :store org-gnus-store-link)
  ("docview" :follow org-docview-open :export org-docview-export :store
org-docview-store-link)
  ("bibtex" :follow org-bibtex-open :store org-bibtex-store-link)
  ("bbdb" :follow org-bbdb-open :export org-bbdb-export :complete
org-bbdb-complete-link :store org-bbdb-store-link)
  ("w3m" :store org-w3m-store-link) ("file+sys") ("file+emacs")
  ("shell" :follow org-link--open-shell)
  ("news" :follow
#[514 "\301\300\302 Q \"\207" ["news" browse-url ":"] 6
 "\n\n(fn URL ARG)"]
)
  ("mailto" :follow
#[514 "\301\300\302 Q \"\207" ["mailto" browse-url ":"] 6
 "\n\n(fn URL ARG)"]
)
  ("https" :follow
#[514 "\301\300\302 Q \"\207" ["https" browse-url ":"] 6
 "\n\n(fn URL ARG)"]
)
  ("http" :follow
#[514 "\301\300\302 Q \"\207" ["http" browse-url ":"] 6
 "\n\n(fn URL ARG)"]
)
  ("ftp" :follow
#[514 "\301\300\302 Q \"\207" ["ftp" browse-url ":"] 6
 "\n\n(fn URL ARG)"]
)
  ("help" :follow org-link--open-help)
  ("file" :complete org-link-complete-file)
  ("elisp" :follow org-link--open-elisp) ("doi" :follow
org-link--open-doi))
 org-latex-format-headline-function
'org-latex-format-headline-default-function
 org-link-elisp-confirm-function 'yes-or-no-p
 org-latex-format-inlinetask-function
'org-latex-format-inlinetask-default-function
 org-html-format-drawer-function #[514 "\207" [] 3 "\n\n(fn NAME CONTENTS)"]
 org-html-format-headline-function

Re: displaying equations with ob-latex

[michael-franzese]

Would people help me have a keybinding that changes the scale in
cyclic sequence, e.g. 2 3 4 5 4 3 2

Regards

> Sent: Friday, May 07, 2021 at 3:18 PM
> From: "Berry, Charles" 
> To: "michael-franz...@gmx.com" 
> Cc: "Help Emacs Orgmode" 
> Subject: Re: displaying equations with ob-latex
>
>
>
> > On May 6, 2021, at 7:39 PM, michael-franz...@gmx.com wrote:
> >
> > Ok, I got some progress, I did "C-C C-x C-l" and got the equation.
> >
>
> Great!
>
>
> > The equation in extremely small though.
> >
>
>
> Try customizing `org-format-latex-options'. The :scale element controls size. 
> I tried 2.0 and it seems like a good value for my screen.
>
> Best,
>
> Chuck
>
> >> Sent: Friday, May 07, 2021 at 1:36 PM
> >> From: "Berry, Charles" 
> >> To: "michael-franz...@gmx.com" 
> >> Cc: "Help Emacs Orgmode" 
> >> Subject: Re: displaying equations with ob-latex
> >>
> >>
> >>
> >>> On May 6, 2021, at 4:20 PM, michael-franz...@gmx.com wrote:
> >>>
> >>> After I do "C-c C-c", I just get a message saying "Code block evaluation 
> >>> complete."
> >>>
> >>
> >>
> >> Are you doing this in a buffer that has ONLY the text between the `cut 
> >> here' lines and exactly that?
> >>
> >> If not, please try it in such a buffer.
> >>
> >> It may help to copy and paste as typos in header names or values can be 
> >> unnoticed and drastically alter behavior. If your mail client reformats 
> >> text, maybe try copy and paste from the mail list archive.
> >>
> >> Also, check with point in the src block using C-c C-v C-i that the header 
> >> args got processed properly. You should see lines like these in the *Help* 
> >> buffer:
> >>
> >> :  :exportsnone
> >>
> >> :  :resultsdrawer replace
> >>
> >>
> >> If you did it in such a buffer and the buffer is unaltered but still 
> >> displays the message, I have to admit that I cannot tell from here what 
> >> the problem might be.
> >>
> >> On my setup, things behave just as outlined.
> >>
> >> When I start emacs with -q, then M-S-; (require 'ob-latex) RET, then paste 
> >> the text to *scratch* and delete the lisp comment at the top, then M-x 
> >> org-mode RET, then C-c C-c with point in the src block, answer 'y e s RET' 
> >> to the query, I get the equation displayed in the results drawer. And the 
> >> export goes OK.
> >>
> >> I am using org-version 9.4.5.
> >>
> >> HTH,
> >>
> >> Chuck
> >>
> >>
> >>
>
>
>

Re: displaying equations with ob-latex

[michael-franzese]

The default does not work very well because as I zoom the text, the equation
remains the same height.

Could this playing around with drawers be eliminated, so things will behave as 
when
using texinfo with @display using mathjax.  It also allows you to zoom in and 
out
hard without any harm.


> Sent: Friday, May 07, 2021 at 3:14 PM
> From: "Ihor Radchenko" 
> To: michael-franz...@gmx.com
> Cc: "Berry, Charles" , "Help Emacs Orgmode" 
> 
> Subject: Re: displaying equations with ob-latex
>
> michael-franz...@gmx.com writes:
>
> > Ok, I got some progress, I did "C-C C-x C-l" and got the equation.
> >
> > The equation in extremely small though.
>
> By default, it should have the same height with you text line.
> You can change it though. I have the following snippet in my config:
>
> (setq org-format-latex-options
>   (quote
>(:foreground default :background default :scale 2.0 :justify center 
> :html-foreground "Black" :html-background "Transparent" :html-scale 1.0 
> :matchers
>   ("begin" "$1" "$" "$$" "\\(" "\\[";; 2x height of 
> formulas
>

Re: displaying equations with ob-latex

[Berry, Charles]

> On May 6, 2021, at 7:39 PM, michael-franz...@gmx.com wrote:
> 
> Ok, I got some progress, I did "C-C C-x C-l" and got the equation.
> 

Great!


> The equation in extremely small though.
> 


Try customizing `org-format-latex-options'. The :scale element controls size. I 
tried 2.0 and it seems like a good value for my screen.

Best,

Chuck

>> Sent: Friday, May 07, 2021 at 1:36 PM
>> From: "Berry, Charles" 
>> To: "michael-franz...@gmx.com" 
>> Cc: "Help Emacs Orgmode" 
>> Subject: Re: displaying equations with ob-latex
>> 
>> 
>> 
>>> On May 6, 2021, at 4:20 PM, michael-franz...@gmx.com wrote:
>>> 
>>> After I do "C-c C-c", I just get a message saying "Code block evaluation 
>>> complete."
>>> 
>> 
>> 
>> Are you doing this in a buffer that has ONLY the text between the `cut here' 
>> lines and exactly that?
>> 
>> If not, please try it in such a buffer.
>> 
>> It may help to copy and paste as typos in header names or values can be 
>> unnoticed and drastically alter behavior. If your mail client reformats 
>> text, maybe try copy and paste from the mail list archive.
>> 
>> Also, check with point in the src block using C-c C-v C-i that the header 
>> args got processed properly. You should see lines like these in the *Help* 
>> buffer:
>> 
>> ::exportsnone
>> 
>> ::resultsdrawer replace
>> 
>> 
>> If you did it in such a buffer and the buffer is unaltered but still 
>> displays the message, I have to admit that I cannot tell from here what the 
>> problem might be.
>> 
>> On my setup, things behave just as outlined.
>> 
>> When I start emacs with -q, then M-S-; (require 'ob-latex) RET, then paste 
>> the text to *scratch* and delete the lisp comment at the top, then M-x 
>> org-mode RET, then C-c C-c with point in the src block, answer 'y e s RET' 
>> to the query, I get the equation displayed in the results drawer. And the 
>> export goes OK.
>> 
>> I am using org-version 9.4.5.
>> 
>> HTH,
>> 
>> Chuck
>> 
>> 
>> 

Re: displaying equations with ob-latex

[Ihor Radchenko]

michael-franz...@gmx.com writes:

> Ok, I got some progress, I did "C-C C-x C-l" and got the equation.
>
> The equation in extremely small though.

By default, it should have the same height with you text line.
You can change it though. I have the following snippet in my config:

(setq org-format-latex-options
  (quote
   (:foreground default :background default :scale 2.0 :justify center 
:html-foreground "Black" :html-background "Transparent" :html-scale 1.0 
:matchers
("begin" "$1" "$" "$$" "\\(" "\\[";; 2x height of 
formulas

Re: displaying equations with ob-latex

[michael-franzese]

Ok, I got some progress, I did "C-C C-x C-l" and got the equation.

The equation in extremely small though.

> Sent: Friday, May 07, 2021 at 1:36 PM
> From: "Berry, Charles" 
> To: "michael-franz...@gmx.com" 
> Cc: "Help Emacs Orgmode" 
> Subject: Re: displaying equations with ob-latex
>
>
>
> > On May 6, 2021, at 4:20 PM, michael-franz...@gmx.com wrote:
> >
> > After I do "C-c C-c", I just get a message saying "Code block evaluation 
> > complete."
> >
>
>
> Are you doing this in a buffer that has ONLY the text between the `cut here' 
> lines and exactly that?
>
> If not, please try it in such a buffer.
>
> It may help to copy and paste as typos in header names or values can be 
> unnoticed and drastically alter behavior. If your mail client reformats text, 
> maybe try copy and paste from the mail list archive.
>
> Also, check with point in the src block using C-c C-v C-i that the header 
> args got processed properly. You should see lines like these in the *Help* 
> buffer:
>
> : :exportsnone
>
> : :resultsdrawer replace
>
>
> If you did it in such a buffer and the buffer is unaltered but still displays 
> the message, I have to admit that I cannot tell from here what the problem 
> might be.
>
> On my setup, things behave just as outlined.
>
> When I start emacs with -q, then M-S-; (require 'ob-latex) RET, then paste 
> the text to *scratch* and delete the lisp comment at the top, then M-x 
> org-mode RET, then C-c C-c with point in the src block, answer 'y e s RET' to 
> the query, I get the equation displayed in the results drawer. And the export 
> goes OK.
>
> I am using org-version 9.4.5.
>
> HTH,
>
> Chuck
>
>
>

Re: displaying equations with ob-latex

[michael-franzese]

I get

#+RESULTS: eqn1
:results:
\(y = x\beta + \epsilon\)
:end:



> Sent: Friday, May 07, 2021 at 1:36 PM
> From: "Berry, Charles via General discussions about Org-mode." 
> 
> To: "michael-franz...@gmx.com" 
> Cc: "Help Emacs Orgmode" 
> Subject: Re: displaying equations with ob-latex
>
>
>
> > On May 6, 2021, at 4:20 PM, michael-franz...@gmx.com wrote:
> >
> > After I do "C-c C-c", I just get a message saying "Code block evaluation 
> > complete."
> >
>
>
> Are you doing this in a buffer that has ONLY the text between the `cut here' 
> lines and exactly that?
>
> If not, please try it in such a buffer.
>
> It may help to copy and paste as typos in header names or values can be 
> unnoticed and drastically alter behavior. If your mail client reformats text, 
> maybe try copy and paste from the mail list archive.
>
> Also, check with point in the src block using C-c C-v C-i that the header 
> args got processed properly. You should see lines like these in the *Help* 
> buffer:
>
> : :exportsnone
>
> : :resultsdrawer replace
>
>
> If you did it in such a buffer and the buffer is unaltered but still displays 
> the message, I have to admit that I cannot tell from here what the problem 
> might be.
>
> On my setup, things behave just as outlined.
>
> When I start emacs with -q, then M-S-; (require 'ob-latex) RET, then paste 
> the text to *scratch* and delete the lisp comment at the top, then M-x 
> org-mode RET, then C-c C-c with point in the src block, answer 'y e s RET' to 
> the query, I get the equation displayed in the results drawer. And the export 
> goes OK.
>
> I am using org-version 9.4.5.
>
> HTH,
>
> Chuck
>
>
>
>

Re: publishing does not work anymore

[Timothy]

Nick Dokos  writes:
>>   :body-only t
>>   :html-postamble: t
>>   :html-postamble-format : ""
>
> This last one seems wrong: the extra space before the colon should probably 
> not be there.
> And I'm not sure whethe the colon after the last two properties should be 
> there at all.

It shouldn't be, it should be:
#+begin_example
   :body-only t
   :html-postamble t
   :html-postamble-format ""
#+end_example

Though the last line may need to be
#+begin_example
   :html-postamble-format '((en ""))
#+end_example
or similar.

--
Timothy

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

[Ihor Radchenko]

Maxim Nikulin  writes:

> Though I still have not tested the patch, I think, it is an improvement 
> and it is helpful in its current form. I am unable to tell if it follows 
> code style.

FYI, this patch may also slightly improve the performance of
org-get-outline-path.

> My bad, you mentioned tags earlier, but I grepped org-agenda.el only.
> My new idea is that org-get-tags may have its own cache as well. Unsure 
> if it should be tried.

I am trying it now ;) No benchmarks yet, but it also provides a
subjective improvement. However, I am trying to reuse org-element-cache
for tags. org-element-cache is smart enough to update itself partially
on buffer changes. However, there are (known) bugs in org-element-cache.
I managed to track down some, but still need to test thoughtfully before
submitting upstream.

> Did you just replace gethash by avl-tree?

Yes

> Likely my idea is based on a 
> wrong assumption. I hoped that having positions of headers it is 
> possible to avoid jumps (goto-char ...) preceded or followed by regexp 
> matching almost completely. Previous header for arbitrary initial 
> position can be found using binary search through structure obtained 
> during scan.

Sorry, I cannot follow what you mean. The call to goto-char in
org-up-heading-safe is required by function docstring - we need to move
point to the parent heading.

>> +(re-search-backward
>> + (format "^\\*\\{1,%d\\} " level-up) nil t)
>> +(funcall outline-level
>
> Unsure concerning the following optimization from the point of 
> readability and reliability in respect to future modifications. Outline 
> level can be derived from the length of matched string without the 
> funcall requiring extra regexp.

I am not sure here. outline-level also consults outline-heading-alist,
though I found no references to that variable in Org mode code.
Otherwise, outline-level already reuses match-data. There is no regexp
matching there. 

P.S. I just found that hash-tables are created by reference, so we need
to call make-hash-table separately in each buffer with cache. Updated
patch attached.

>From 08a175752b14f84767a71665773aa64807606af4 Mon Sep 17 00:00:00 2001
Message-Id: <08a175752b14f84767a71665773aa64807606af4.1620316036.git.yanta...@gmail.com>
From: Ihor Radchenko 
Date: Thu, 6 May 2021 14:13:20 +0800
Subject: [PATCH] Use cache in org-up-heading-safe

* lisp/org.el (org-up-heading-safe): Use buffer-local cache to store
positions of parent headings.  The cache is invalidated when buffer
text is changed, according to `buffer-chars-modified-tick'.
(org--up-heading-cache):  Buffer-local hash-table storing the cache.
(org--up-heading-cache-tick):  The buffer modification state for
currently active `org--up-heading-cache'.

The optimisation is critical when running agenda or org-entry-get
queries using property/tag inheritance.  In such scenarios
`org-up-heading-safe' can be called thousands of times.  For example,
building todo agenda on large number of headings lead to the following
benchmark results:

Benchmark:

1. (elp-instrument-function #'org-up-heading-safe)
2. Run agenda
3. (elp-results) ;; function, # calls, total time, avg time

Without cache:
org-up-heading-safe  27555   8.4234025759  0.0003056941

With cache, first run:
org-up-heading-safe  23227   0.5300747539  2.282...e-05

With cache, second run on unchanged buffer:
org-up-heading-safe  23227   0.1447754880  6.233...e-06

The final speedup is 1-2 orders of magnitude (~15-56 times).
---
 lisp/org.el | 30 ++
 1 file changed, 26 insertions(+), 4 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 0ff13c79c..7c58f0e2e 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -20440,6 +20440,10 @@ (defun org-up-heading-all (arg)
 With argument, move up ARG levels."
   (outline-up-heading arg t))
 
+(defvar-local org--up-heading-cache nil
+  "Buffer-local `org-up-heading-safe' cache.")
+(defvar-local org--up-heading-cache-tick nil
+  "Buffer `buffer-chars-modified-tick' in `org--up-heading-cache'.")
 (defun org-up-heading-safe ()
   "Move to the heading line of which the present line is a subheading.
 This version will not throw an error.  It will return the level of the
@@ -20449,10 +20453,28 @@ (defun org-up-heading-safe ()
 because it relies on stars being the outline starters.  This can really
 make a significant difference in outlines with very many siblings."
   (when (ignore-errors (org-back-to-heading t))
-(let ((level-up (1- (funcall outline-level
-  (and (> level-up 0)
-	   (re-search-backward (format "^\\*\\{1,%d\\} " level-up) nil t)
-	   (funcall outline-level)
+(let (level-cache)
+  (unless org--up-heading-cache
+(setq org--up-heading-cache (make-hash-table)))
+  (if (and (eq (buffer-chars-modified-tick) org--up-heading-cache-tick)
+   (setq level-cache (gethash (point) org--up-heading-cache)))
+   

Re: displaying equations with ob-latex

[Berry, Charles]

> On May 6, 2021, at 4:20 PM, michael-franz...@gmx.com wrote:
> 
> After I do "C-c C-c", I just get a message saying "Code block evaluation 
> complete."
> 


Are you doing this in a buffer that has ONLY the text between the `cut here' 
lines and exactly that?

If not, please try it in such a buffer.

It may help to copy and paste as typos in header names or values can be 
unnoticed and drastically alter behavior. If your mail client reformats text, 
maybe try copy and paste from the mail list archive.

Also, check with point in the src block using C-c C-v C-i that the header args 
got processed properly. You should see lines like these in the *Help* buffer:

:   :exportsnone

:   :resultsdrawer replace


If you did it in such a buffer and the buffer is unaltered but still displays 
the message, I have to admit that I cannot tell from here what the problem 
might be.

On my setup, things behave just as outlined.

When I start emacs with -q, then M-S-; (require 'ob-latex) RET, then paste the 
text to *scratch* and delete the lisp comment at the top, then M-x org-mode 
RET, then C-c C-c with point in the src block, answer 'y e s RET' to the query, 
I get the equation displayed in the results drawer. And the export goes OK.

I am using org-version 9.4.5.

HTH,

Chuck

Re: Please help by becoming a maintainer for an Org Babel file

[Tyler Smith]

Bastien  writes:

we are looking for more maintainers of individual Org Babel 
files.




Hi,

I can volunteer to maintain ob-awk.el. I've signed my assignment 
form with FSF, and returned it to them this evening. I'll let you 
know when I'm official.


I have an account on code.orgmode.org already, but I think I only 
have access to worg.


I may also be able to maintain ob-shell.el. It is a bit more 
complex than ob-awk.el, so I'd like to hold off until I understand 
a bit better how ob works in general.


Is there any documentation for ob other than the source code?

Best,

Tyler

--
Tyler Smith
plantarum.ca

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

[Nick Savage]

I haven't opened up the code yet to take a look, but I likely will take 
a crack at some of these items in the future as low-hanging fruit 
refactoring project.


On 5/6/21 6:05 PM, Boruch Baum wrote:

(org-w3m-get-image-end): New function, for w3m-img links.

3] As mentioned in the patch, and in the commit message, there seem to
be several functioned unused in the code base that could be
candidates for removal...

 org-w3m-get-anchor-start
 org-w3m-no-prev-link-p
 org-w3m-get-prev-link-start

4] Additionally, in performing the merge I came across function
org-string-nw-p, which seems to be an unnecessary duplicate of the
emacs core function string-blank-p. It may be that historically you
once needed your own home-made functions/macros, but now that emacs
core has them, you may want to consider a refactor.

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

[Nick Savage]

So I have a patch written that doesn't completely fix the problem, but 
maybe makes enough progress that someone else can figure it out.


The issue is that comint-prompt-regexp is reading the "% " as a prompt, 
and taking everyone off before it. I've added another parameter to 
org-babel-comint-with-output in the "meta" to pass our own regexp to 
replace comint-prompt-regexp, which works except when it doesn't. The 
regexp I've added is just "\n" now, so the newline characters are removed.


The tests that Daniele added as a patch don't quite pass though with 
this. The issue is that something in the way the output is posted in the 
output buffer includes the prompt occasionally is included in a line and 
occasionally not. It seems the first time the block of code is executed, 
it is included (and therefore needs to be removed) and each other time 
it is not, so it is only the first time that it is run is not working 
properly.


This is obviously way too fragile to actually merge, but I was hoping 
the work I've done so far is enough to help someone else make progress. 
I'll probably take another stab at this tomorrow (since it's bugging 
me), but thought I'd share what I have for now.


Cheers,
Nick

On 5/6/21 8:24 AM, Ihor Radchenko wrote:

"Nicholas Savage"  writes:


I can confirm this too on the latest master.

I took a quick peek this morning, and my suspicion is that the problem is 
somewhere within org-babel-comint-with-output in lisp/ob-comint.el, but I'm not 
positive at this point.

I confirm as well. I also saw an anomaly in the comint buffer. Note that
all the output lines, except "five 0% six" are after the shell prompt.
As I remember, the code expects the result to be exactly at the prompt
line. So, for some reason the first command ("echo five 0% six") of the
second block does not get inserted at the empty line.

echo one 0% two
yantar92@yantar92-laptop ~/.data/1e/90360c-ef36-4d20-8706-990ae2530cbf $ one 0% 
two
echo tree 0% four
yantar92@yantar92-laptop ~/.data/1e/90360c-ef36-4d20-8706-990ae2530cbf $ tree 
0% four
echo 'org_babel_sh_eoe'
yantar92@yantar92-laptop ~/.data/1e/90360c-ef36-4d20-8706-990ae2530cbf $ 
org_babel_sh_eoe
yantar92@yantar92-laptop ~/.data/1e/90360c-ef36-4d20-8706-990ae2530cbf $ echo 
five 0% six
five 0% six
echo seven 0% eight
yantar92@yantar92-laptop ~/.data/1e/90360c-ef36-4d20-8706-990ae2530cbf $ seven 
0% eight
echo 'org_babel_sh_eoe'
yantar92@yantar92-laptop ~/.data/1e/90360c-ef36-4d20-8706-990ae2530cbf $ 
org_babel_sh_eoe
yantar92@yantar92-laptop ~/.data/1e/90360c-ef36-4d20-8706-990ae2530cbf $

Best,
Ihor
>From 6c7d39bfb9be38b54d23fcffbb09f1fcb96751f4 Mon Sep 17 00:00:00 2001
From: Nicholas Savage 
Date: Thu, 6 May 2021 19:17:33 -0400
Subject: [PATCH] ob-shell.el: Fix bug where shell output was incorrectly
 truncated on special characters.

* lisp/ob-comint.el (org-babel-comint-with-output): Add fifth meta
optional argument for providing a custom prompt regexp.
lisp/ob-shell.el (org-babel-sh-evaluate): Implements using new
argument to prevent incorrect truncation on special characters.

If shell output included special characters that also occasionally are
included in shell prompts, such as "#" or "%", a regexp was tripping
up on them and cutting out part of the line. As ob-shell already cuts
out the shell prompts, this was not necessary and instead we can just
use \n as the separator. Original functionality was retained for other
ob-* files in case this was necessary.
---
 lisp/ob-comint.el | 20 
 lisp/ob-shell.el  |  2 +-
 2 files changed, 13 insertions(+), 9 deletions(-)

diff --git a/lisp/ob-comint.el b/lisp/ob-comint.el
index 18d4f3c93..27ad6efd7 100644
--- a/lisp/ob-comint.el
+++ b/lisp/ob-comint.el
@@ -57,13 +57,14 @@ executed inside the protection of `save-excursion' and
 
 (defmacro org-babel-comint-with-output (meta  body)
   "Evaluate BODY in BUFFER and return process output.
-Will wait until EOE-INDICATOR appears in the output, then return
-all process output.  If REMOVE-ECHO and FULL-BODY are present and
-non-nil, then strip echo'd body from the returned output.  META
-should be a list containing the following where the last two
-elements are optional.
+Will wait until EOE-INDICATOR appears in the output, then return all
+process output.  If REMOVE-ECHO and FULL-BODY are present and non-nil,
+then strip echo'd body from the returned output.  PROMPT-REGEXP is a
+filter that, if provided, overrides the default regexp that tries to
+filter out the shell prompt.  META should be a list containing the
+following where the last three elements are optional.
 
- (BUFFER EOE-INDICATOR REMOVE-ECHO FULL-BODY)
+ (BUFFER EOE-INDICATOR REMOVE-ECHO FULL-BODY PROMPT-REGEXP)
 
 This macro ensures that the filter is removed in case of an error
 or user `keyboard-quit' during execution of body."
@@ -71,7 +72,10 @@ or user `keyboard-quit' during execution of body."
   (let ((buffer (nth 0 meta))
 	(eoe-indicator (nth 1 meta))
 	(remove-echo (nth 2 

Re: displaying equations with ob-latex

[michael-franzese]

> Sent: Friday, May 07, 2021 at 10:52 AM
> From: "Berry, Charles via General discussions about Org-mode." 
> 
> To: "michael-franz...@gmx.com" 
> Cc: "Help Emacs Orgmode" 
> Subject: Re: displaying equations with ob-latex
>
>
>
> > On May 6, 2021, at 3:08 PM, michael-franz...@gmx.com wrote:
> >
> > Did you manage to get the equations displayed, I have tried again and could 
> > not do
> > it.  It might be beneficial to give more details and some more examples on 
> > what to do.
> >
>
> Yes, the one equation was displayed as a preview.
>
> Maybe I was not clear in my directions so try this bit:
>
> --8<---cut here---start->8---
>
> 1. Copy the text between the `cut here' lines to its own org buffer.
> 2. Place cursor in the eqn1 src block.
> 3. Type ~C-c C-c~ and respond to any prompt about evaluating with ~y~.
> 4. An eqn1 results block should appear with a :results: drawer
>containing an equation in it.
> 5. Type ~C-c C-x C-l~.
> 6. The equation should be previewed in the :results: drawer.
> 7. Export to LaTeX Buffer with ~C-c C-e C-b l L y~
> 8. Only an enumerate environment and the equation should appear in the
>LaTeX buffer.
>
> #+name: eqn1
> #+begin_src latex :exports none :results drawer
>   \(y = x\beta + \epsilon\)
> #+end_src
>
> #+call: eqn1() :results latex
>
> --8<---cut here---end--->8---
>
>
>
>
> > Can I export on a window that is to right window of the code window?
>
> IIUC, the question is
>
> :  when I export (as in item 5 in the list above), will the LaTeX buffer
> :  open in a window to the right of the one containing the org buffer?
>
> This is what happens in my setup when I have the org buffer displayed in a 
> frame with just one window.
>
> But how windows are displayed depends on many factors. See (info "(emacs) 
> Windows") for some of the details. So you may need to customize or resize 
> your frame to get the same behavior.
>
>
> >  I can one use plain
> > tex commands.  Texinfo mainly supports plain tex, org mode in basically 
> > latex, so the
> > two programs do not currently work well together.
> >
>
> Um, I don't see how this gets to the original question.

It is a side problem after the task of math display is achieved.

> > Texinfo has the good feature to show equations (but only for plain tex) 
> > whereas org
> > is good with latex (but not very adept at displaying the output in an emacs 
> > window).
>
> There are probably a lot of opinions in the org community about how well org 
> handles previewing output. For me it works well. YMMV.

Surely you are right, but it is a problem of use case.  The lot of opinions 
suggest to me that
there should be various functionalities that can handle different approaches.

> HTH,
>
> Chuck
>
>

Re: displaying equations with ob-latex

[michael-franzese]

After I do "C-c C-c", I just get a message saying "Code block evaluation 
complete."

> Sent: Friday, May 07, 2021 at 10:52 AM
> From: "Berry, Charles" 
> To: "michael-franz...@gmx.com" 
> Cc: "Help Emacs Orgmode" 
> Subject: Re: displaying equations with ob-latex
>
>
>
> > On May 6, 2021, at 3:08 PM, michael-franz...@gmx.com wrote:
> >
> > Did you manage to get the equations displayed, I have tried again and could 
> > not do
> > it.  It might be beneficial to give more details and some more examples on 
> > what to do.
> >
>
> Yes, the one equation was displayed as a preview.
>
> Maybe I was not clear in my directions so try this bit:
>
> --8<---cut here---start->8---
>
> 1. Copy the text between the `cut here' lines to its own org buffer.
> 2. Place cursor in the eqn1 src block.
> 3. Type ~C-c C-c~ and respond to any prompt about evaluating with ~y~.
> 4. An eqn1 results block should appear with a :results: drawer
>containing an equation in it.
> 5. Type ~C-c C-x C-l~.
> 6. The equation should be previewed in the :results: drawer.
> 7. Export to LaTeX Buffer with ~C-c C-e C-b l L y~
> 8. Only an enumerate environment and the equation should appear in the
>LaTeX buffer.
>
> #+name: eqn1
> #+begin_src latex :exports none :results drawer
>   \(y = x\beta + \epsilon\)
> #+end_src
>
> #+call: eqn1() :results latex
>
> --8<---cut here---end--->8---
>
>
>
>
> > Can I export on a window that is to right window of the code window?
>
> IIUC, the question is
>
> :  when I export (as in item 5 in the list above), will the LaTeX buffer
> :  open in a window to the right of the one containing the org buffer?
>
> This is what happens in my setup when I have the org buffer displayed in a 
> frame with just one window.
>
> But how windows are displayed depends on many factors. See (info "(emacs) 
> Windows") for some of the details. So you may need to customize or resize 
> your frame to get the same behavior.
>
>
> >  I can one use plain
> > tex commands.  Texinfo mainly supports plain tex, org mode in basically 
> > latex, so the
> > two programs do not currently work well together.
> >
>
> Um, I don't see how this gets to the original question.
>
> > Texinfo has the good feature to show equations (but only for plain tex) 
> > whereas org
> > is good with latex (but not very adept at displaying the output in an emacs 
> > window).
>
> There are probably a lot of opinions in the org community about how well org 
> handles previewing output. For me it works well. YMMV.
>
> HTH,
>
> Chuck
>

Re: displaying equations with ob-latex

[Berry, Charles]

> On May 6, 2021, at 3:08 PM, michael-franz...@gmx.com wrote:
> 
> Did you manage to get the equations displayed, I have tried again and could 
> not do
> it.  It might be beneficial to give more details and some more examples on 
> what to do.
> 

Yes, the one equation was displayed as a preview. 

Maybe I was not clear in my directions so try this bit:

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

1. Copy the text between the `cut here' lines to its own org buffer.
2. Place cursor in the eqn1 src block.
3. Type ~C-c C-c~ and respond to any prompt about evaluating with ~y~.
4. An eqn1 results block should appear with a :results: drawer
   containing an equation in it.
5. Type ~C-c C-x C-l~.
6. The equation should be previewed in the :results: drawer.
7. Export to LaTeX Buffer with ~C-c C-e C-b l L y~ 
8. Only an enumerate environment and the equation should appear in the
   LaTeX buffer.

#+name: eqn1
#+begin_src latex :exports none :results drawer 
  \(y = x\beta + \epsilon\)
#+end_src

#+call: eqn1() :results latex

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




> Can I export on a window that is to right window of the code window?

IIUC, the question is 

:  when I export (as in item 5 in the list above), will the LaTeX buffer
:  open in a window to the right of the one containing the org buffer?

This is what happens in my setup when I have the org buffer displayed in a 
frame with just one window.

But how windows are displayed depends on many factors. See (info "(emacs) 
Windows") for some of the details. So you may need to customize or resize your 
frame to get the same behavior.


>  I can one use plain
> tex commands.  Texinfo mainly supports plain tex, org mode in basically 
> latex, so the
> two programs do not currently work well together.
> 

Um, I don't see how this gets to the original question.

> Texinfo has the good feature to show equations (but only for plain tex) 
> whereas org
> is good with latex (but not very adept at displaying the output in an emacs 
> window).

There are probably a lot of opinions in the org community about how well org 
handles previewing output. For me it works well. YMMV.

HTH,

Chuck

Re: displaying equations with ob-latex

[michael-franzese]

Did you manage to get the equations displayed, I have tried again and could not 
do
it.  It might be beneficial to give more details and some more examples on what 
to do.

Can I export on a window that is to right window of the code window?  I can one 
use plain
tex commands.  Texinfo mainly supports plain tex, org mode in basically latex, 
so the
two programs do not currently work well together.

Texinfo has the good feature to show equations (but only for plain tex) whereas 
org
is good with latex (but not very adept at displaying the output in an emacs 
window).



> Sent: Friday, May 07, 2021 at 6:14 AM
> From: "Berry, Charles via General discussions about Org-mode." 
> 
> To: "michael-franz...@gmx.com" 
> Cc: "Help Emacs Orgmode" 
> Subject: Re: displaying equations with ob-latex
>
>
>
> > On May 6, 2021, at 12:50 AM, michael-franz...@gmx.com wrote:
> >
> >
> > I am trying to use ob-latex but equations are not being displayed in emacs
> > when I try to execute with "C-c C-c".
>
> Right. This is because `:results latex replace' is the default for latex src 
> blocks and the leads to wrapping everything in a latex export block.
>
> The context inside that block is `export-block' - i.e. it is not a 
> `greater-element' and cannot contain other elements.  AFAIK, there is not 
> previewer for export blocks - latex or otherwise.
>
> The context for an equation inside a greater-element is latex-fragment. And 
> those can be rendered via `org-latex-preview'.
>
> If you want to render equations for previewing, you could put them into a 
> drawer that is not repeated in the export.
>
> To make this work, you probably want something like this
>
> #+begin_src org
>
>   ,#+name: eqn1
>   ,#+begin_src latex :exports none :results drawer
>   \(y = x\beta + \epsilon\)
>   ,#+end_src
>
>
>   Here is the equation for export:
>
>   ,#+call: eqn1() :results latex
>
> #+end_src
>
> Evaluating the latex src block (C-c C-c) will create a `results' drawer line 
> this:
>
> #+RESULTS: eqn1
> :results:
> \(y = x\beta + \epsilon\)
> :end:
>
> but the `:exports none' will strip that out on export. The call line will 
> create this on export:
>
> #+RESULTS:
> #+begin_export latex
> \(y = x\beta + \epsilon\)
> #+end_export
>
>
> HTH,
>
> Chuck
>
>
>
>
>

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

[Boruch Baum]

On 2021-05-05 10:16, Bastien wrote:
> 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.

1] Attached.

2] Here's a commit message in the Changelog style:

   2021-05-06  Boruch Baum  

* ol-w3m.el (org-w3m-copy-for-org-mode)
(org-w3m-get-next-link-start, org-w3m-get-prev-link-start):
Account for w3m-img links.
(org-w3m-get-anchor-start, org-w3m-get-prev-link-start)
(org-w3m-no-prev-link-p): Unused function notes.
(org-w3m-get-image-end): New function, for w3m-img links.

3] As mentioned in the patch, and in the commit message, there seem to
   be several functioned unused in the code base that could be
   candidates for removal...

org-w3m-get-anchor-start
org-w3m-no-prev-link-p
org-w3m-get-prev-link-start

4] Additionally, in performing the merge I came across function
   org-string-nw-p, which seems to be an unnecessary duplicate of the
   emacs core function string-blank-p. It may be that historically you
   once needed your own home-made functions/macros, but now that emacs
   core has them, you may want to consider a refactor.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0
diff --git a/ol-w3m.el b/ol-w3m.el
index ebb11ce..2738e01 100644
--- a/ol-w3m.el
+++ b/ol-w3m.el
@@ -82,26 +82,41 @@ so that it can be yanked into an Org  buffer with links working correctly."
 (setq temp-position (point))
 ;; move to next anchor when current point is not at anchor
 (or (get-text-property (point) 'w3m-href-anchor) (org-w3m-get-next-link-start))
-(if (<= (point) transform-end) ; if point is inside transform bound
-(progn
-  ;; get content between two links.
-  (when (> (point) temp-position)
-(setq return-content (concat return-content
- (buffer-substring
-  temp-position (point)
-  ;; get link location at current point.
-  (setq link-location (get-text-property (point) 'w3m-href-anchor))
-  ;; get link title at current point.
-  (setq link-title (buffer-substring (point)
- (org-w3m-get-anchor-end)))
-  ;; concat Org style url to `return-content'.
-  (setq return-content
-		(concat return-content
-			(if (org-string-nw-p link-location)
-(org-link-make-string link-location link-title)
-			  link-title
+(cond
+ ((<= (point) transform-end) ; point is inside transform bound
+   ;; get content between two links.
+   (when (> (point) temp-position)
+ (setq return-content (concat return-content
+  (buffer-substring
+   temp-position (point)
+   (cond
+((setq link-location (get-text-property (point) 'w3m-href-anchor))
+ ;; current point is a link
+ ;; (we thus also got link location at current point)
+ ;; get link title at current point.
+ (setq link-title (buffer-substring (point)
+(org-w3m-get-anchor-end)))
+ ;; concat Org style url to `return-content'.
+ (setq return-content
+   (concat return-content
+   (if (org-string-nw-p link-location)
+ (org-link-make-string link-location link-title)
+link-title
+((setq link-location (get-text-property (point) 'w3m-image))
+ ;; current point is an image
+ ;; (we thus also got image link location at current point)
+ ;; get link title at current point.
+ (setq link-title (buffer-substring (point) (org-w3m-get-image-end)))
+ ;; concat Org style url to `return-content'.
+ (setq return-content
+   (concat return-content
+   (if (org-string-nw-p link-location)
+ (org-link-make-string link-location link-title)
+link-title
+(t nil))); current point is neither a link nor an image
+ (t ; point is NOT inside transform bound
   (goto-char temp-position) ; reset point before jump next anchor
-  (setq out-bound t)))	; for break out `while' loop
+  (setq out-bound t	; for break out `while' loop
   ;; add the rest until end of the region to be copied
   (when (< (point) transform-end)
 (setq return-content
@@ -114,6 +129,7 @@ so that it can be yanked into an Org  buffer with links working correctly."
 (defun org-w3m-get-anchor-start ()
   "Move cursor to the start of current 

Re: [PATCH] Wrap LaTeX snippets in $$ with markdown export

[Nicolas Goaziou]

Hello,

Timothy  writes:

> I just thought there may be people who like me are interested in
> s for LaTeX in HTML, but not in Markdown.

Fair enough. Let's push your last patch, then.

Thank you.

Regards,
-- 
Nicolas Goaziou

Re: displaying equations with ob-latex

[Christopher Dimech]

It would please many users if ob-latex was made to behave like other code 
blocks.
One can parse and show equations in emacs using mathjax as has been recently
implemented in texinfo using @display.

Regards
Christopher



> Sent: Friday, May 07, 2021 at 6:14 AM
> From: "Berry, Charles via General discussions about Org-mode." 
> 
> To: "michael-franz...@gmx.com" 
> Cc: "Help Emacs Orgmode" 
> Subject: Re: displaying equations with ob-latex
>
>
>
> > On May 6, 2021, at 12:50 AM, michael-franz...@gmx.com wrote:
> >
> >
> > I am trying to use ob-latex but equations are not being displayed in emacs
> > when I try to execute with "C-c C-c".
>
> Right. This is because `:results latex replace' is the default for latex src 
> blocks and the leads to wrapping everything in a latex export block.
>
> The context inside that block is `export-block' - i.e. it is not a 
> `greater-element' and cannot contain other elements.  AFAIK, there is not 
> previewer for export blocks - latex or otherwise.
>
> The context for an equation inside a greater-element is latex-fragment. And 
> those can be rendered via `org-latex-preview'.
>
> If you want to render equations for previewing, you could put them into a 
> drawer that is not repeated in the export.
>
> To make this work, you probably want something like this
>
> #+begin_src org
>
>   ,#+name: eqn1
>   ,#+begin_src latex :exports none :results drawer
>   \(y = x\beta + \epsilon\)
>   ,#+end_src
>
>
>   Here is the equation for export:
>
>   ,#+call: eqn1() :results latex
>
> #+end_src
>
> Evaluating the latex src block (C-c C-c) will create a `results' drawer line 
> this:
>
> #+RESULTS: eqn1
> :results:
> \(y = x\beta + \epsilon\)
> :end:
>
> but the `:exports none' will strip that out on export. The call line will 
> create this on export:
>
> #+RESULTS:
> #+begin_export latex
> \(y = x\beta + \epsilon\)
> #+end_export
>
>
> HTH,
>
> Chuck
>
>
>
>
>

-
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

Fold/Hide inline footnotes

[Denis Maier]

Hi,
auctex has a nice feature to hide certain elements, e.g. footnotes. 
Would it be possible to include something similar in org-mode?

Best,
Denis

Re: publishing does not work anymore

[Nick Dokos]

Giuseppe Lipari  writes:


> (setq org-publish-project-alist
>    '(("fil-web"
>       :base-directory "./"
>       :base-extension "org"
>       :publishing-directory "./"
>       :preparation-function update-all-dblocks-before-exporting
>       :publishing-function org-html-publish-to-html
>       :html-extension "php"
>       :body-only t
>       :html-postamble: t
>       :html-postamble-format : ""

This last one seems wrong: the extra space before the colon should probably not 
be there.
And I'm not sure whethe the colon after the last two properties should be there 
at all.

-- 
Nick

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

Table alignment problem

[Fr Ml]

  
  
Hello,
there is an old problem with table alignment. It's mentioned here:
https://emacs.stackexchange.com/q/30495/11498

It occurs as far as I know only in 4 cases (last 4 rows):

| 2 latin
  letters | ab | (2
  glyphs)    |
  | 2 arabic letters    | من | ok (2
  glyphs) |
  | same but with 2 diacritics  | مِنْ | also
  ok  (2 glyphs)   |
  | the arabich letter ا and then ل isn't a problem | ال | also ok
  (2 glyphs)    |
  | but ل and then ا is a problem (case1)   | لا | not ok
  (it's 1 glyph) |
  | also ل and then أ (case2)   | لأ | " (it's 1
  glyph)  |
  | also ل and then إ (case3)   | لإ | " (it's 1
  glyph)  |
  | also ل and then آ (case4)   | لآ | " (it's 1
  glyph)  |

(screenshot)

In the 4 cases two letters build one single glyph and this isn't
recognized. That's the problem. 
I don't know if it's hard to solve but I've noticed for example that
orgmode handles the word  مَنْ correctly. It has only 2 glyphs even
though this word has 4 characters (2 diacritics+ 2 regular letters).
The alignment is correct (3rd row).
And unfortunately the 4 mentioned cases occurs very often in Arabic,
so the alignment would be much worse with than in the example. 
I hope this could be solved. Many thanks for the great orgmode
features and the bidi support.

(Of course I'm using a monospaced font for Arabic. And the problem
occurs also if I only use Arabic letters.)

Kind Regards
Frank

  

Re: [IMPORTANT] The contrib/ directory now lives outside of Org's repository

[Jonas Bernoulli]

Bastien  writes:

> Jonas Bernoulli  writes:
>
>> All the *ELPAs extract metadata from the "main library", which by
>> default is the library whose name matches the name of the package.
>>
>> If the name doesn't match, then it can be overridden, but some
>> main library is required, even if it does nothing but provide
>> the metadata and (provide 'org-contrib).
>>
>> I've already added "org-contrib" to the Emacsmirror, but because
>> nothing like "org-contrib.el" exists, I had to randomly pick a
>> library and as a result the package description for all of
>> "org-contrib" currently is "Org-mode Babel support for Arduino".
>>
>> Please add "org-contrib.el" containing some juicy metadata.
>
> Well, I don't know if they are *that* juicy but I just added some.
> Let me know how this look!  And thanks for the above instructions,
> that's very useful.

The commentary and summary are also part of the metadata that *ELPA and
the Emacsmirror use.  There are several additional issues and I think
it's easiest if I just show you what I think the file should look like:

---

;;; org-contrib.el --- Add-ons that are no longer distributed with Org-mode 

;; Copyright (C) 2021 Bastien Guerry

;; Author: Bastien Guerry 
;; Homepage: https://git.sr.ht/~bzg/org-contrib
;; Package-Requires: ((emacs "25.1") (org "9.4.5"))
;; Package-Version: 0.0.1
;; Keywords: org
;; SPDX-License-Identifier: GPL-3.0-or-later

;; This file is not part of GNU Emacs.

;; This program is free software: you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation, either version 3 of the License, or
;; (at your option) any later version.

;; This program is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;; GNU General Public License for more details.

;; You should have received a copy of the GNU General Public License
;; along with GNU Emacs.  If not, see .

;;; Commentary

;; This package contains add-ons to Org-mode which are not part of GNU
;; Emacs or of the official Org package.

;; ** This package receive little if no maintainance. **

;; Especially, there is no guaranty that it is compatible with the latest
;; Org stable version.  Would you would like to volunteer maintaining it?
;; If so, please send me an email at b...@gnu.org.

;; If you want to maintain only one or some of these add-ons please send
;; me an email and consider hosting the add-ons on a separate repository.

;; These files used to live in the Org repository but have been filtered
;; out of the Org 9.5 release and are stored here for archival purpose.
;; The contrib/ directory used to contain a scripts/ directory that now
;; lives on Worg: .

;;; Note:

;; This file, org-contrib.el, provides metadata for the (future)
;; org-contrib GNU ELPA package.

;;; Code:

(provide 'org-contrib)

;;; org-contrib.el ends here

Re: displaying equations with ob-latex

[Berry, Charles]

> On May 6, 2021, at 12:50 AM, michael-franz...@gmx.com wrote:
> 
> 
> I am trying to use ob-latex but equations are not being displayed in emacs
> when I try to execute with "C-c C-c".

Right. This is because `:results latex replace' is the default for latex src 
blocks and the leads to wrapping everything in a latex export block. 

The context inside that block is `export-block' - i.e. it is not a 
`greater-element' and cannot contain other elements.  AFAIK, there is not 
previewer for export blocks - latex or otherwise.

The context for an equation inside a greater-element is latex-fragment. And 
those can be rendered via `org-latex-preview'.

If you want to render equations for previewing, you could put them into a 
drawer that is not repeated in the export.

To make this work, you probably want something like this

#+begin_src org

  ,#+name: eqn1
  ,#+begin_src latex :exports none :results drawer 
  \(y = x\beta + \epsilon\)
  ,#+end_src

 
  Here is the equation for export:

  ,#+call: eqn1() :results latex

#+end_src

Evaluating the latex src block (C-c C-c) will create a `results' drawer line 
this:

#+RESULTS: eqn1
:results:
\(y = x\beta + \epsilon\)
:end:

but the `:exports none' will strip that out on export. The call line will 
create this on export:

#+RESULTS:
#+begin_export latex
\(y = x\beta + \epsilon\)
#+end_export


HTH,

Chuck

Re: How to use `open` to handle `message:*` links on macOS

[Tim Visher]

On Thu, May 6, 2021 at 1:04 PM Alexander Adolf <
alexander.ad...@condition-alpha.com> wrote:

>
> Tim Visher  writes:
>
> > [...]
> >
> > One of these days though I'm going to break the habit and move email
> > directly into Emacs. :)
>
> I was in the exact same situation as you until about half a year ago,
> which was when I decided to (finally) act on my "move email to emacs"
> task.
>
> Coincidentally I have recently released a blog post covering some of the
> basic aspects of planning the switch:
>
> https://condition-alpha.com/blog/?p=1792
>
> …
>
> The smallest, and most isolated task is perhaps configuring msmtp for
> sending mail; so why not start with that?
>
> …
>
> If you start a big all-in-one migration, and it fails, you're left with
> a big mess. Thus, doing things step-by-step with an option to revert
> each step if it doesn't work, is crucial, too.
>

Great advice and info all around! Thanks so much. :)

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

[Maxim Nikulin]

Though I still have not tested the patch, I think, it is an improvement 
and it is helpful in its current form. I am unable to tell if it follows 
code style.


Despite continuing discussion, I am unsure if it could be significantly 
better.


On 06/05/2021 21:34, Ihor Radchenko wrote:

Maxim Nikulin writes:

In org-agenda.el org-up-heading-safe function is called only from
org-find-top-headline.


That's probably not the slowest part. org-agenda also calls
org-up-heading-safe indirectly. In particular, org-get-tags is calling
org-up-heading-safe to get inherited tags. It is org-get-tags that is
taking >50% time of agenda generation in my agendas. And
org-up-heading-safe was the largest contributor to that >50% time.


My bad, you mentioned tags earlier, but I grepped org-agenda.el only.
My new idea is that org-get-tags may have its own cache as well. Unsure 
if it should be tried.



Scan through the whole buffer could be faster, but it is not always
desired. Most of Org code only need information for current headline.
Re-scanning the whole buffer would be costly.

Also, I tried to compare avl-tree with hash table. However, avl-tree
does not give much benefit for my test case of an agenda with ~12000
todo items. Since avl-tree requires much more custom code, hash table
should be better.


Did you just replace gethash by avl-tree? Likely my idea is based on a 
wrong assumption. I hoped that having positions of headers it is 
possible to avoid jumps (goto-char ...) preceded or followed by regexp 
matching almost completely. Previous header for arbitrary initial 
position can be found using binary search through structure obtained 
during scan.



+   (re-search-backward
+ (format "^\\*\\{1,%d\\} " level-up) nil t)
+   (funcall outline-level


Unsure concerning the following optimization from the point of 
readability and reliability in respect to future modifications. Outline 
level can be derived from the length of matched string without the 
funcall requiring extra regexp.


If originally this code path had 50% contribution and performance 
already becomes several times better, further optimization of this part 
does not matter.

Re: wip-cite status question and feedback

[M . ‘quintus’ Gülker]

Am 05. Mai 2021 um 14:27 Uhr -0400 schrieb Bruce D'Arcus:
> Hope that explains.

Sure, thank you! I just wanted to provide some possibly useful input.
I am not to critise these exciting efforts.

  -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: How to use `open` to handle `message:*` links on macOS

[Alexander Adolf]

Hello Tim,

Tim Visher  writes:

> [...]
> I do indeed trigger the capture by switching over to Emacs and whacking my
> org-capture keybinding (`C-c C`). I have a todo item that's been sitting in
> my list for a very long time to figure out how to move my email habits into
> emacs but I've never gotten around to it. In this case it's even worse
> because the only reason I'm using Mail.app in the first place is because my
> work email got moved to an Exchange server so I now don't have a good web
> based interface to read mail anymore like my beloved Gmail.
>
> One of these days though I'm going to break the habit and move email
> directly into Emacs. :)

I was in the exact same situation as you until about half a year ago,
which was when I decided to (finally) act on my "move email to emacs"
task.

Coincidentally I have recently released a blog post covering some of the
basic aspects of planning the switch:

https://condition-alpha.com/blog/?p=1792

IMO, a decent amount up-front planning is crucial. With notmuch, emacs's
mail message handling infrastructure, and elisp, anything is possible;
the sky is the limit. Email is too central to our daily work to start
with the defaults and see where it takes you (IMO). So think well what
your dream email workflow is, and then work towards that.

The smallest, and most isolated task is perhaps configuring msmtp for
sending mail; so why not start with that?

Importing existing mailboxes (from Apple's mail app in my case), is
another important issue (which I'll cover in a future blog post).

Once you've imported some mail, you can toy around with notmuch in
emacs, and the settings, until you get a gist of how things work, and
how far you are from your goal. Your everyday real work is still in
Apple's mail app.

Once you're confident that you'll be able to survive with your emacs
setup, then you can make the move, and stop using Apple's mail app.

If you start a big all-in-one migration, and it fails, you're left with
a big mess. Thus, doing things step-by-step with an option to revert
each step if it doesn't work, is crucial, too.


Hoping to have helped,

  --alexander

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

[Bruce D'Arcus]

On Thu, May 6, 2021 at 12:20 PM Nicolas Goaziou 
wrote:

> > I'm getting out of my depth, as I no longer use LaTeX much, but WDYT
> > about using latexmk for export -> latex -> pdf, so that bibtex and
> > such is properly run?
>
> This is controlled by `org-latex-pdf-process'; modifying it is out of
> the scope of the Org Cite library.

Makes sense.

But, and I just put this out there really for more serious LaTeX users to
advocate for this if they think it's a good idea ...

... might it be within scope of org more broadly to consider before
releasing 9.5?

Anyway, I updated my cite-init.el file to include this, and it does indeed
work as expected now.

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

Bruce

Re: About multilingual documents

[Maxim Nikulin]

On 05/05/2021 01:55, Aleksandar Dimitrov wrote:

Yeah, I know the issue, which is why I rely on XCompose for Latin
scripts. For Cyrillic, alas, that is impossible. It means that I
basically can't control Emacs while using a Cyrillic layout, which is a
pity. I have no good workaround.


Generally, the idea is to enable layout (Xkb group) per window and to 
reset layout to English if active window is Emacs. I have not tried 
recipes with managing Xkb group from emacs itself, e.g.

https://github.com/lislon/emacs-switch-lang
https://github.com/Mihara/kbd-indicator.el

Another approach it to set global hotkey and if Emacs is focused, send 
some special key event that is bound to switching of input method. I 
have some links but the pages are not in English. Personally, I have not 
fully polished my setup, however it works with some limitations. I 
started from bash script calling xdotool, xvkbd, and xprop. Then I 
realized that C code is not dramatically longer but it allows to avoid 
struggling with limitations of such tools.


Tim Cross suggested me to raise the question concerning keymaps in 
emacs-devel once more, but I still do not feel that I am ready to 
discussion of technical aspects (e.g. hotkey handling in applications 
that fixed similar issues several years ago)

https://orgmode.org/list/87r1lnvjh0@gmail.com

Re: Notes about citations in Org (part 3)

[Bruce D'Arcus]

On Thu, May 6, 2021 at 12:05 PM Maxim Nikulin  wrote:

> There is might be some uncertainty concerning handling of prefixes and
> suffixes. However my impression is that even e.g. \cite[p.~7]{key} is
> quite rare. For completeness, keys without prefixes, suffixes could be
> combined into single \cite{key1,key2}, otherwise individual \cite{key1}
> may be required with additional text in between.

You should be covered.

[cite:prefix 1 @key1 suffix 1;prefix 2 @key2 suffix2]

Bruce

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

[Nicolas Goaziou]

"Bruce D'Arcus"  writes:

> On Thu, May 6, 2021 at 10:12 AM Nicolas Goaziou  
> wrote:
>
>> You're missing the colon at the end of the keyword. Note that `org-lint'
>> warns you about it.
>
> Ugh; sorry about that.
>
> I'm getting out of my depth, as I no longer use LaTeX much, but WYDT
> about using latexmk for export -> latex -> pdf, so that bibtex and
> such is properly run?

This is controlled by `org-latex-pdf-process'; modifying it is out of
the scope of the Org Cite library.

> Regardless of the solution, right now the user will get an error with
> that export option.

I think the default value of the variable above handles BibTeX calls.

Regards,

Re: Notes about citations in Org (part 3)

[Maxim Nikulin]

On 06/05/2021 18:53, Bruce D'Arcus wrote:


Your example should just use the default org-cite citation, without
any style or sub-style.

The rest would be handled by latex/bibtex.

Right?


Yes, simple \cite{k1,k2} is mostly enough for numeric citations. E.g 
cases like separated list of references to author's works are handled by 
a customized \begin{thebibliography} and dedicated counter having some 
prefix.


There is might be some uncertainty concerning handling of prefixes and 
suffixes. However my impression is that even e.g. \cite[p.~7]{key} is 
quite rare. For completeness, keys without prefixes, suffixes could be 
combined into single \cite{key1,key2}, otherwise individual \cite{key1} 
may be required with additional text in between.

Re: Multiple calc commands with orgbabel

[Tom Gillespie]

Hi Bastien,
Given the short length of the file, the fact that I now have a
fairly good idea of how it works, and the fact that I share a last
name with the original author of calc, I would be happy to. I'll hunt
down the steps you mentioned for becoming an ob- maintainer and ping
back when they are done. Best!
Tom

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

[Maxim Nikulin]

Bastien, thank you for the fixes of electric-indent-mode, there is no 
feeling that it is necessary to choose between broken and inconvenient 
configuration options any more.


On 03/05/2021 15:06, Bastien wrote:


This might help: https://orgmode.org/worg/org-faq.html#indentation

"What is the best setup for indenting?"

I think, the something like the following should be added to the answer.
It was not obvious for me at first. Gustavo explained it in 
https://orgmode.org/list/87blfxv966@gmail.com/


Do not try to avoid or ignore indentation of heading body or properties 
drawer determined by current org-adapt-indentation and 
electric-indent-mode by pressing C-j instead of RET (or vice versa). It 
is unsure way. When you refile heading or change its level (promote or 
demote it), you may find that despite your efforts, elements are 
indented accordingly to Org mode current settings instead of your visual 
preferences. It is better to customize org-adapt-indentation.


I would suggest to mention =#+STARTUP: indent= as well as a visual 
alternative to (org-adapt-indentation t) that actually cancels its effect.


Maybe it should be stressed in the ORG-NEWS file that previously there 
were suggestion to set electric-indent-local-mode to -1 for Org buffers. 
Now it is hopefully not necessary due to bug fixes and changed defaults.


Finally, a case that might be fixed.

- item 1
  + item 2
  +← cursor is here

In this case TAB allows to cycle through indentation variants and it is 
great. Unfortunately just after RET (there are only some spaces on the 
new line) TAB fixes indentation as continuation of previous item and 
does not allow to shift left before marker is added. It is confusing at 
first since e.g. python mode is more liberal.


Is there equivalent of TAB for indentation cycle when some item text is 
added since TAB is busy for switching of item visibility?

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

[Ihor Radchenko]

Maxim Nikulin  writes:
> 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.

Thanks for the feedback!

> 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.

Oops. Fixed.

> In org-agenda.el org-up-heading-safe function is called only from 
> org-find-top-headline.

That's probably not the slowest part. org-agenda also calls
org-up-heading-safe indirectly. In particular, org-get-tags is calling
org-up-heading-safe to get inherited tags. It is org-get-tags that is
taking >50% time of agenda generation in my agendas. And
org-up-heading-safe was the largest contributor to that >50% time.

> ...  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.

Scan through the whole buffer could be faster, but it is not always
desired. Most of Org code only need information for current headline.
Re-scanning the whole buffer would be costly.

Also, I tried to compare avl-tree with hash table. However, avl-tree
does not give much benefit for my test case of an agenda with ~12000
todo items. Since avl-tree requires much more custom code, hash table
should be better.

;; No cache
;; org-up-heading-safe  180493  285.37713697  0.0015810980
;; org-up-heading-safe  134876  199.44584854  0.0014787349
;; org-up-heading-safe  134872  198.23494205  0.0014698005

;; Hash cache
;; org-up-heading-safe  180493  5.0327451709  2.788...e-05
;; org-up-heading-safe  134872  1.3568663460  1.006...e-05
;; org-up-heading-safe  134872  0.7527555679  5.581...e-06

;; AVL cache
;; org-up-heading-safe  180500  5.1044455589  2.827...e-05
;; org-up-heading-safe  134872  1.2781428280  9.476...e-06
;; org-up-heading-safe  134872  1.2866258809  9.539...e-06

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

That one is used for org-agenda-filter-by-top-headline. I do not really
use it, so I have no clue if there is much need to optimise it
specifically. Yet, caching org-up-heading-safe will indeed speed it up
as well.

>> +(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.

Sure. Done.

>> +;; 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.

Hmm. You are right. Benchmarking with and without additional caching
shows that it can give extra ~2x improvement:

;; Hash cache
;; org-up-heading-safe  180493  5.0327451709  2.788...e-05
;; org-up-heading-safe  134872  1.3568663460  1.006...e-05
;; org-up-heading-safe  134872  0.7527555679  5.581...e-06

;; Hash cache + outline-level cache
;; org-up-heading-safe  180507  4.3326449169  2.400...e-05
;; org-up-heading-safe  134872  0.4952472380  3.671...e-06
;; org-up-heading-safe  134879  0.5298789350  3.928...e-06

So, outline-level is also cached in the new version of the patch.

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

Sure.

>> +(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.

I do not know either. Actually, I wish if Org mode code base used less
literal strings and more regexp variables from org-element.el and
org.el.

Best,
Ihor

>From d40b2bbb1dc5113d3085be2fae52ebe5ac1b023d Mon Sep 17 00:00:00 2001
Message-Id: 
From: Ihor Radchenko 
Date: Thu, 6 May 2021 14:13:20 +0800
Subject: [PATCH] Use cache in org-up-heading-safe

* lisp/org.el (org-up-heading-safe): Use buffer-local cache to store
positions of parent headings.  The cache is invalidated when buffer
text is changed, according to `buffer-chars-modified-tick'.
(org--up-heading-cache):  Buffer-local hash-table storing the cache.
(org--up-heading-cache-tick):  The buffer modification state for
currently active `org--up-heading-cache'.

The optimisation is critical when running agenda or org-entry-get
queries using property/tag inheritance.  In such scenarios
`org-up-heading-safe' can be called thousands of 

Refiling All 'Terminal TODO State' Entries to a Particular Heading

[Tim Visher]

Hi Everyone,

Partly because I think it's neat and partly to ask for ways that I could
improve it I figured I'd share my latest little snippet of org elisp with
the list.

I maintain my primary TODO list as an org file with top-level headings like *
This Week, * Delegated, * Scheduled, * Deferred, etc. These all contain
TODOs or potential TODOs.

Anything I intend to work on near term I refile into * This Week and that's
then the primary heading that I'm burning down throughout my day.

I do weekly reflection/projections and 6 week reflection/projections. When
I do a weekly reflection I go through another heading * Done to remind
myself what I accomplished in the past week. When I do a 6 week
reflection/projection I review the Done heading one more time and then I
refile all the entries currently there into an * Archive heading. Then
every now and then I actually archive entries in Archive into an
*.org_archive file. * Done and * Archive are both tagged with ARCHIVE.

In an effort to start automating some of this effort I wrote the following
elisp to refile all the Level 2 entries to the Done heading:

(defun timvisher-org-refile-done-entry-position
()
  (save-excursion
(goto-char (point-min))
(re-search-forward "^\\* Done")))

(defun timvisher-org-refile-done-entry
()
  (org-refile nil
  (current-buffer)
  (list "* Done"
(buffer-file-name)
nil
(timvisher-org-refile-done-entry-position

(defun timvisher-org-refile-done-entries
()
  (interactive)
  (length
   (org-map-entries #'timvisher-org-refile-done-entry
"LEVEL=2/+DONE|+CANCELLED"
nil
'archive)))

I'm doing Level 2 only because for long running projects I tend to have a
single Level 2 heading with many subheadings representing the project's
breakdown and I don't want them to be refiled out of the project.

Opportunities for improvement would be:

   1. Is there a better way to find the * Done entry than searching for it
   every time?
   2. Am I using org-refile correctly there? It's functional but it also
   seems needlessly complicated.

Hope this finds you all well. :)

--

In Christ,

Timmy V.

https://blog.twonegatives.com
http://five.sentenc.es

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

[Bruce D'Arcus]

On Thu, May 6, 2021 at 10:12 AM Nicolas Goaziou  wrote:

> You're missing the colon at the end of the keyword. Note that `org-lint'
> warns you about it.

Ugh; sorry about that.

I'm getting out of my depth, as I no longer use LaTeX much, but WYDT
about using latexmk for export -> latex -> pdf, so that bibtex and
such is properly run?

Regardless of the solution, right now the user will get an error with
that export option.

Bruce

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

[Bastien]

Bastien  writes:

> Bastien  writes:
>
>> Various discussions convinced me that `org-adapt-indentation' should
>> be nil by default.
>
> It is now, as of commit 0a651b746.

... and I broke some tests.  Sorry for that.  I will fix this next
week, unless someone does it before me.

-- 
 Bastien

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

[Nicolas Goaziou]

"Bruce D'Arcus"  writes:

> On Thu, May 6, 2021 at 8:05 AM Nicolas Goaziou  wrote:
>
>> Your document doesn't contain a "#+print_bibliography" keyword. It is
>> responsible for adding the "\\bibliography{...}" macro. I don't think it
>> is possible to produce a PDF without it.
>
> I paste my input/output below.
>
> Shouldn't the output include ...
>
> \bibliography{test}
>
> ...?
>
> --- source ---
> [cite/text/alt:see ;@einstein]
>
> [cite//alt/caps:@einstein]
>
> [cite//full:@einstein]
>
> [cite//caps:@einstein]
>
> #+print_bibliography

You're missing the colon at the end of the keyword. Note that `org-lint'
warns you about it.

Regards,

[no subject]

[Krupal]

Hi Bastien,

I'm interested in taking 'charge' of maintenance of 'orgmode.org/worg'.

My whole life revolves around org files. I use it extensively for
personal knowledge management, appointments, lessons, project management using
TaskJuggler, Python development using literate-programming, private journals,
finance using ledger, pdfs with org-noter, org-roam etc.

Without a doubt, 'worg' has at times given me solutions which weren't
available anywhere else in the whole www. At the same time, it is very
easy to come across very outdated information over there, and certain other
pages are just a bunch of unrelated comments.

It would be an honour to be able to contribute by trying to make it more
relevant and useful for both new users and expert users alike. It is
indeed a massive repository of extremely useful information.

Kind regards,
Krupal

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

[Bruce D'Arcus]

On Thu, May 6, 2021 at 8:05 AM Nicolas Goaziou  wrote:

> Your document doesn't contain a "#+print_bibliography" keyword. It is
> responsible for adding the "\\bibliography{...}" macro. I don't think it
> is possible to produce a PDF without it.

I paste my input/output below.

Shouldn't the output include ...

\bibliography{test}

...?

--- source ---
[cite/text/alt:see ;@einstein]

[cite//alt/caps:@einstein]

[cite//full:@einstein]

[cite//caps:@einstein]

#+print_bibliography

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

--- results ---

% Created 2021-05-06 Thu 09:04
% Intended LaTeX compiler: lualatex
\documentclass[11pt]{article}
\usepackage{graphicx}
\usepackage{grffile}
\usepackage{longtable}
\usepackage{wrapfig}
\usepackage{rotating}
\usepackage[normalem]{ulem}
\usepackage{amsmath}
\usepackage{textcomp}
\usepackage{amssymb}
\usepackage{capt-of}
\usepackage{hyperref}
\author{Bruce D'Arcus}
\date{\today}
\title{}
\hypersetup{
 pdfauthor={Bruce D'Arcus},
 pdftitle={},
 pdfkeywords={},
 pdfsubject={},
 pdfcreator={Emacs 27.2 (Org mode 9.4.5)},
 pdflang={English}}
\usepackage[]{natbib}
\begin{document}

\tableofcontents

\citealt{einstein}

\Citealp{einstein}

\citep*{einstein}

\Citep{einstein}

\#+print\textsubscript{bibliography}
\end{document}

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

[Bruce D'Arcus]

On Thu, May 6, 2021 at 8:29 AM Nicolas Goaziou  wrote:
>
> Hello,
>
> "Bruce D'Arcus"  writes:
>
> > 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.
>
> I think only oc-citeproc (and oc-basic) may be targetting multiple
> output formats. I doubt it would even use styles; I assume that is
> entirely determined by the CSL file.

Actually, no; it's determined (mostly) by the processor.

A CSL style defines a single default citation layout, which the
processor modifies depending on what variants it supports.

So most of them support a citet-like option, but it's currently
implemented in the processor; not the style.

> > E.g. biblatex users will want like 20 commands available, which won't
> > all work with other formats.
>
> So you would have 20 styles, with shortcuts for the most commons. This
> is not insane, and the mapping is done only once.

In the UI I'm working on for inserting org-cite citations, I have the
small handful of styles, that users can complete.

https://github.com/bdarcus/bibtex-actions/pull/113

It's simple, and clean; the list of style fits on a single line.

Aside: no, I'm not currently planning to include sub-styles here; was
thinking to allow users to add them after if needed. But that could
change of course.

These will work across the different output formats we've discussed,
so I don't need to add different config options for different targets,
and user documents don't have to change to accommodate them.

> Styles do not need to be compatible between processors. As a reminder,
> there's the "fallback rule". According to it, each processor must:
> - provide a default styles;
> - map any unknown style to the style above.

OK, but that is only a single required default style then.

...

> > Even if not perfect, I think it's a small price to pay for the
> > benefits.
>
> I'm still not convinced by the benefits. Could you describe a situation
> where sub-styles would be really beneficial?

Say a natbib user has a document, maybe even a book, that makes common
use of the text style + some examples of sub-styles.

They want to export that document to both HTML and to PDF.

Using styles + sub-styles means she can use the same source to get
both; the first using the citeproc-org processor, and the second
oc-natbib.

Admittedly, a long list of flat styles could still accommodate this (I
think), but I go back to my UI and config point above.

Do note my suggestion on the previous message that we could simplify
sub-styles and still get these benefits. I do agree it's not necessary
to treat sub-styles as an unordered list.

WDYT of that?

Bruce

Re: displaying equations with ob-latex

[pietru]

I've got the same problem.




> Sent: Thursday, May 06, 2021 at 9:54 PM
> From: michael-franz...@gmx.com
> To: "Help Emacs Orgmode" 
> Subject: displaying equations with ob-latex
>
>
> I am trying to use ob-latex but equations are not being displayed in emacs
> when I try to execute with "C-c C-c".
>
>
>
>
>
>

Re: Bug: org-store-link uses CUSTOM_ID instead of target point [9.4.4 (release_9.4.4 @ /usr/share/emacs/27.2/lisp/org/)]

[Bastien]

Hi,

Fr Ml  writes:

> I have a problem with the function org-store-link it doesn't work as
> described in the documentation:
> https://orgmode.org/manual/Handling-Links.html
> "For Org files, if there is a '<>' at point, the link points
> to
> the target."

Fixed in maint, thanks a lot for reporting this and Ihor for
confirming the bug.

-- 
 Bastien

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

[Bruce D'Arcus]

Your other message, Nicolas, came in as I finished this, but I'll post
this anyway.

On Thu, May 6, 2021 at 8:11 AM Nicolas Goaziou  wrote:

> > I added the following to the wiki page, which I think addresses this:
> >
> > Note that `text/alt` would not make sense, as the sub-style in this case
> > would override the style.
>
> The first case means inheritance ignores sub-styles. Those are added as
> a second pass. The second case means anything with a sub-style is
> excluded from inheritance. Both make sense.
>
> Did I say I don't like sub-styles already? :)

What about a middle-ground, which would be a flat list of sub-styles, like:

- alt
- alt-caps
- alt-caps-full
- caps
- caps-full
- full

You still need to realize the "alt" options don't apply to the text
style, but this is at least simpler?

Bruce

Re: displaying equations with ob-latex

[Christopher Dimech]

I am unsure about this, but mathjax could be able to display
math format in emacs.  Never tried this in emacs though, using
ob-latex.  Had a go, but the display is not right.


> Sent: Thursday, May 06, 2021 at 9:54 PM
> From: michael-franz...@gmx.com
> To: "Help Emacs Orgmode" 
> Subject: displaying equations with ob-latex
>
>
> I am trying to use ob-latex but equations are not being displayed in emacs
> when I try to execute with "C-c C-c".
>
>
>
>
>
>

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

[Nicolas Goaziou]

Hello,

"Bruce D'Arcus"  writes:

> 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.

I think only oc-citeproc (and oc-basic) may be targetting multiple
output formats. I doubt it would even use styles; I assume that is
entirely determined by the CSL file.

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

So you would have 20 styles, with shortcuts for the most commons. This
is not insane, and the mapping is done only once.

Styles do not need to be compatible between processors. As a reminder,
there's the "fallback rule". According to it, each processor must:
- provide a default styles;
- map any unknown style to the style above.

Thanks to this, there will not be any incompatibility between documents
upon switching processors.

Agreeing on a small set of common styles is a good thing; this is what
your doing on your wiki. But there is nothing wrong to map
"text-alt-full" style to the default one in another processor. 

Of course, the default style may be unrelated to "text", but is it
a problem in practice? If you switch processor and use complex styles
(here style + sub-styles), you will need to change them anyway, because
the compatibility is so low.

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

Exactly. For developers, it doesn't make a huge difference here.

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

I'm still not convinced by the benefits. Could you describe a situation
where sub-styles would be really beneficial?

Regards,
-- 
Nicolas Goaziou

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

[Nicolas Goaziou]

Hello,

"Bruce D'Arcus"  writes:

> To come back to this 
>
> On Wed, May 5, 2021, 10:53 AM Nicolas Goaziou 
> wrote:
>
> 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 added the following to the wiki page, which I think addresses this:
>
> Note that `text/alt` would not make sense, as the sub-style in this case
> would override the style.

The first case means inheritance ignores sub-styles. Those are added as
a second pass. The second case means anything with a sub-style is
excluded from inheritance. Both make sense.

Did I say I don't like sub-styles already? :)

Regards,
-- 
Nicolas Goaziou

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

[Ihor Radchenko]

"Nicholas Savage"  writes:

> I can confirm this too on the latest master.
>
> I took a quick peek this morning, and my suspicion is that the problem is 
> somewhere within org-babel-comint-with-output in lisp/ob-comint.el, but I'm 
> not positive at this point.

I confirm as well. I also saw an anomaly in the comint buffer. Note that
all the output lines, except "five 0% six" are after the shell prompt.
As I remember, the code expects the result to be exactly at the prompt
line. So, for some reason the first command ("echo five 0% six") of the
second block does not get inserted at the empty line.

echo one 0% two
yantar92@yantar92-laptop ~/.data/1e/90360c-ef36-4d20-8706-990ae2530cbf $ one 0% 
two
echo tree 0% four
yantar92@yantar92-laptop ~/.data/1e/90360c-ef36-4d20-8706-990ae2530cbf $ tree 
0% four
echo 'org_babel_sh_eoe'
yantar92@yantar92-laptop ~/.data/1e/90360c-ef36-4d20-8706-990ae2530cbf $ 
org_babel_sh_eoe
yantar92@yantar92-laptop ~/.data/1e/90360c-ef36-4d20-8706-990ae2530cbf $ echo 
five 0% six
five 0% six
echo seven 0% eight
yantar92@yantar92-laptop ~/.data/1e/90360c-ef36-4d20-8706-990ae2530cbf $ seven 
0% eight
echo 'org_babel_sh_eoe'
yantar92@yantar92-laptop ~/.data/1e/90360c-ef36-4d20-8706-990ae2530cbf $ 
org_babel_sh_eoe
yantar92@yantar92-laptop ~/.data/1e/90360c-ef36-4d20-8706-990ae2530cbf $ 

Best,
Ihor

Re: Bug: org-insert-heading-respect-content before first heading [9.4 (9.4-19-gb1de0c-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20201019/)]

[Gustavo Barros]

Hi Bastien,

On Thu, 06 May 2021 at 08:53, Bastien  wrote:


I fixed this in the
maint branch, please let me know if you notice any weirdness.



It's looking good here now.

Thanks again.

Best,
Gustavo.

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

[Nicolas Goaziou]

Hello,

"Bruce D'Arcus"  writes:

> 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?

Your document doesn't contain a "#+print_bibliography" keyword. It is
responsible for adding the "\\bibliography{...}" macro. I don't think it
is possible to produce a PDF without it.

Regards,
-- 
Nicolas Goaziou

publishing does not work anymore

[Giuseppe Lipari]

Hello,

I have a problem with my publishing workflow. Here is the setting of my
variable org-publish-projet-alist in my init.org

(setq org-publish-project-alist
   '(("fil-web"
  :base-directory "./"
  :base-extension "org"
  :publishing-directory "./"
  :preparation-function update-all-dblocks-before-exporting
  :publishing-function org-html-publish-to-html
  :html-extension "php"
  :body-only t
  :html-postamble: t
  :html-postamble-format : ""
  )))

This worked nicely until a few days ago: starting from page.org, it would
produce page.php as expected.

Today I upgraded my system from ubuntu 18 to ubuntu 20.
I have GNU Emacs 26.3, and org-version is 9.3.1

Now, when I want to publish, it gives me the following error :


Publishing file
/home/lipari/Documents/corsi/IoT/portail/portail-master-info/portail/ue-M1S2-COA/
semainier.org using ‘org-html-publish-to-html’
org-combine-plists: Wrong type argument: plistp, (:base-directory "./"
:base-extension "org" :publishing-directory "./" :preparation-function
update-all-dblocks-before-exporting :publishing-function
org-html-publish-to-html ...)



Unfortunately, this completely breaks my long-time functioning workflow for
publishing the details of my course on the University portal.

Can someone please help me sort out the problem ?

Best,

Giuseppe Lipari


Giuseppe Lipari
CRIStAL,
Université de Lille

Re: Notes about citations in Org (part 3)

[Bruce D'Arcus]

On Thu, May 6, 2021 at 7:37 AM Maxim Nikulin  wrote:

> > For example, do you get that with the default \cite command in latex,
> > assuming the right bst file?
>
> Do you think something is wrong with such citations?

No.

I asked those questions because the focus now is on org-cite styles,
and sub-styles, and how those map to which output formats.

Your example should just use the default org-cite citation, without
any style or sub-style.

The rest would be handled by latex/bibtex.

Right?

Bruce

Re: Bug: org-insert-heading-respect-content before first heading [9.4 (9.4-19-gb1de0c-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20201019/)]

[Bastien]

Hi Gustavo,

certainly a nitpick, but I think a good one.  I fixed this in the
maint branch, please let me know if you notice any weirdness.

Thanks again,

-- 
 Bastien

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

[Nicholas Savage]

I can confirm this too on the latest master.

I took a quick peek this morning, and my suspicion is that the problem is 
somewhere within org-babel-comint-with-output in lisp/ob-comint.el, but I'm not 
positive at this point.

On Wed, May 5, 2021, at 22:35, John Corless wrote:
> 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
>> 

Re: [PATCH] tangling seems to have broken today

[Bastien]

Hi Sébastien,

Sébastien Miquel  writes:

> Unless I misunderstand what you mean, the patch seems to follow this
> style.

Yes, sorry, my bad, I was reacting to another patch.

>> I think this should be applied to the maint branch, right?  In this
>> case, the patch does not apply.  Can you check and repropose a patch
>> against maint?  Or just let me know if I'm mistaken.
> It fixes an issue introduced by a commit in master, so it should be
> applied to master.

Applied in master with commit 6e5b39acd.

>> So we're all set here?
> This should be it!

Thanks!

-- 
 Bastien

Re: Notes about citations in Org (part 3)

[Maxim Nikulin]

On 06/05/2021 00:16, Bruce D'Arcus wrote:

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?


It is default behavior. Minimal example:

--- 8< ---
\documentclass{article}
\begin{document}
New threads related to citations in Org~\cite{ml_natbib,ml_cite_org3}.

\begin{thebibliography}{9}
\bibitem{ml_cite_org3} Nicolas Goaziou. Notes about citations in Org 
(part 3).
\bibitem{ml_cite_status} Bruce D'Arcus. wip-cite status question and 
feedback.

\bibitem{ml_natbib} Nicolas Goaziou. [wip-cite-new] New natbib processor.
\end{thebibliography}
\end{document}
--- 8< ---
New threads related to citations in Org [3, 1].

References
[1] Nicolas Goaziou. Notes about citations in Org (part 3).
[2] Bruce D’Arcus. wip-cite status question and feedback.
[3] Nicolas Goaziou. [wip-cite-new] New natbib processor.
--- 8< ---

Additional packages are required to sort citations or to replace 
sequence with range.



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


Do you think something is wrong with such citations? Papers may be 
published without using of BibTeX at all. "Right" bst file depends on 
particular journal. Even between styles, that generate simple 
\bibitem{key} causing numerical citations, difference may be rather 
significant in respect to what parts of entry are formatted, in which 
order how they are emphasized, what is omitted completely and what is 
shortened.

Re: [PATCH] tangling seems to have broken today

[Sébastien Miquel]

Hi Bastien,

Bastien writes:

Also, nitpick: please don't add a full-stop at the end of the first
line of the commit message (or the subject of your patch).

Unless I misunderstand what you mean, the patch seems to follow this
style.


I think this should be applied to the maint branch, right?  In this
case, the patch does not apply.  Can you check and repropose a patch
against maint?  Or just let me know if I'm mistaken.

It fixes an issue introduced by a commit in master, so it should be
applied to master.


So we're all set here?

This should be it!


Regards,

--
Sébastien Miquel

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

[Bruce D'Arcus]

On Thu, May 6, 2021 at 6:06 AM Bruce D'Arcus  wrote:

> If I add plainnat as style to the org file, I still get the undefined
> citation error.

So two things:

1. the bib file isn't include in the latex output
2. Denis noticed bibtex doesn't seem to run; maybe the pdf output
option for latex should use latexmk?

Bruce

Re: [PATCH] tangling seems to have broken today

[Bastien]

Hi Sébastien,

Sébastien Miquel  writes:

> 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 think this should be applied to the maint branch, right?  In this
case, the patch does not apply.  Can you check and repropose a patch
against maint?  Or just let me know if I'm mistaken.

Thanks,

-- 
 Bastien

Re: Multiple calc commands with orgbabel

[Bastien]

Hi Tom,

Tom Gillespie  writes:

> Here is a quick and dirty implementation that more or less does what
> you want (I think).

Mandatory question: would you like to be ob-calc.el maintainer?

-- 
 Bastien

Re: [PATCH] tangling seems to have broken today

[Bastien]

Hi Sébastien,

Sébastien Miquel  writes:

> I apologise again for the troubles.

No problem.  So we're all set here?

Also, nitpick: please don't add a full-stop at the end of the first
line of the commit message (or the subject of your patch).

Thanks,

-- 
 Bastien

Re: [PATCH] Added two extra symbols to org-entities

[Bastien]

Hi Atlas,

Atlas Cove  writes:

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

Thank you!

Applied as commit bfc3d18b0 in the master branch.

https://orgmode.org/worg/org-contribute.html#commit-messages will tell
you more on how to prepare a proper commit message for future contribs.

Best,

-- 
 Bastien

Re: About multilingual documents

[Juan Manuel Macías]

Hi Aleksandar,

Aleksandar Dimitrov writes:
> [...]
> I must admit that I find the inline org-src notation (of which I
> didn't know yet) somewhat jarring, and certainly less pleasant to
> read. Perhaps we could use a similar mechanism to
> =org-hide-emphasis-markers= to make it more pleasant to read. [1]

You may be interested in this thread: 
https://orgmode.org/list/87a6r6avgg@gmail.com/

> I definitely agree that Org would benefit from more multilingual
> support. I'm not very experienced in emacs-lisp but would love to contribute.
>
> One problem I foresee is the translation of locales into LaTeX macros
> for either (LaTeX)-Babel or Polyglossia (which is what I use.) So a
> string like "en" or "en_UK" (which is readily understood by
> ([ai]|hun)spell) would have to be translated to the necessary
> macros. For example for Polyglossia [2] the preamble would read
>
> \setdefaultlanguage[variant=uk]{english}
>
> And then the inline commands would have to be rendered as
> \textenglish{…} or \textlang{english}{…} (probably the latter would be 
> easier.)

Since these days I had some free time, I have written this little
snippet, based on your idea. Of course, it is only a 'sketch', or a
'proof of concept'. It has obvious limitations and does not collect all
the features that your idea suggests. Here I only apply the (LaTeX)
Babel environments, but they can be easily substituted by those of
Polyglossia [1], or add both possibilities using a defcustom. I have put
two options: `:lang' and `:lang-quotes'. The second option is to use it
with the csquotes package. As I have only focused on exporting to LaTeX
I have not included support for html (or odt), but I agree with you that
it would be necessary to add some multilingual support as well for these
backends. And there's no support for inline blocks either, as the output
of the variables I've added is multiline. Anyway, it is a very hasty
sketch (maybe too hasty ;-)), but if you want to try it, I attach here a
small test document.

The code:

#+begin_src emacs-lisp
  (defun my-lang-org-backend (lang body)
(cond
 ((org-export-derived-backend-p org-export-current-backend 'latex)
  (format 
"@@latex:\\begin{otherlanguage}{%s}@@\n%s\n@@latex:\\end{otherlanguage}@@" lang 
body))
 ((or (org-export-derived-backend-p org-export-current-backend 'html)
  (org-export-derived-backend-p org-export-current-backend 'odt))
  (format "%s" body

  (defun my-lang-csquotes-org-backend (lang body)
(cond
 ((org-export-derived-backend-p org-export-current-backend 'latex)
  (format 
"@@latex:\\begin{otherlanguage*}{%s}\n\\EnableQuotes@@\n%s\n@@latex:\\end{otherlanguage*}@@"
 lang body))
 ((or (org-export-derived-backend-p org-export-current-backend 'html)
  (org-export-derived-backend-p org-export-current-backend 'odt))
  (format "%s" body

  (defun org-babel-execute:org (body params)
"Execute a block of Org code with.
  This function is called by `org-babel-execute-src-block'."
(let ((result-params (split-string (or (cdr (assq :results params)) "")))
  (lang (cdr (assq :lang params)))
  (lang-quotes (cdr (assq :lang-quotes params)))
  (body (org-babel-expand-body:org
 (replace-regexp-in-string "^," "" body) params)))
  (cond
   (lang
(my-lang-org-backend lang body))
   (lang-quotes
(my-lang-csquotes-org-backend lang-quotes body))
   ((member "latex" result-params)
(org-export-string-as (concat "#+Title: \n" body) 'latex t))
   ((member "html" result-params) (org-export-string-as  body 'html t))
   ((member "ascii" result-params) (org-export-string-as body 'ascii t))
   (t body
#+end_src

Best regards,

Juan Manuel

[1] I used Polyglossia for a while, when I migrated to XeTeX and then to
LuaTeX, and babel at that time did not support both engines. But now
Babel does give them full support and has grown so much that it has
surpassed (IMHO) to Polyglossia. I recommend taking a look at all
novelties and new functionalities that has added the current Babel
maintainer, Javier Bezos:
http://mirrors.ctan.org/macros/latex/required/babel/base/babel.pdf



langs-test.org
Description: Lotus Organizer

Re: Need help using the dev version on windows

[Bruce D'Arcus]

Not sure, but is this what you are looking for?

https://orgmode.org/worg/org-tutorials/org4beginners.html#orgc1dbe4b

On Thu, May 6, 2021 at 5:42 AM Denis Maier  wrote:
>
> Hi,
>
> in order to test the new org-cite features I've tried installing orgmode
> from the git repo.
>
> So, in my home folder
> git clone https://code.orgmode.org/bzg/org-mode.git
> cd org-mode
> make
>
> Then, I get this message ...
> ==
> = Invoke "make help" for a synopsis of make targets. =
> = Created a default local.mk template.   =
> = Setting "oldorg" as the default target.=
> = Please adapt local.mk to your local setup! =
> ==
> ... and that's it ...
> Nothing happens.
>
> What am I missing?
>
> Denis
>

displaying equations with ob-latex

[michael-franzese]

I am trying to use ob-latex but equations are not being displayed in emacs
when I try to execute with "C-c C-c".

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

[Bruce D'Arcus]

On Thu, May 6, 2021 at 3:36 AM Denis Maier
 wrote:

> Bruce has sent me his test files, and it turned out to be the bibstyle
> (humannat), which apparently isn't included in current tex distributions.
> Question: I can't see why this style should be used according to the
> minimal example Bruce has shared. Is this style added as the default
> style by the exporter? Or did you, Bruce, specify it somewhere?

If I add plainnat as style to the org file, I still get the undefined
citation error.

Here's the current file:

[cite/text/alt:see ;@einstein]

[cite//alt/caps:@einstein]

[cite//full:@einstein]

[cite//caps:@einstein]

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

displaying equations with ob-latex

[michael-franzese]

I am trying to use ob-latex but equations are not being displayed in emacs
when I try to execute with "C-c C-c".

Need help using the dev version on windows

[Denis Maier]

Hi,

in order to test the new org-cite features I've tried installing orgmode 
from the git repo.


So, in my home folder
git clone https://code.orgmode.org/bzg/org-mode.git
cd org-mode
make

Then, I get this message ...
==
= Invoke "make help" for a synopsis of make targets. =
= Created a default local.mk template.   =
= Setting "oldorg" as the default target.=
= Please adapt local.mk to your local setup! =
==
... and that's it ...
Nothing happens.

What am I missing?

Denis

Re: Moving some lisp/ob-*.el files to org-contrib - your advice?

[Bastien]

Jean Louis  writes:

> If those files have copyrights submitted, should they not end up in
> GNU ELPA?

Many of the authors for files in org-contrib did not want to assign
their copyright to the FSF.  

That's one of the reasons behind the contrib/ directory in the first
place.

Also, org-contrib in NonGNU ELPA will be a transitory package: once
all the files there find a maintainer and another place where to be
hosted, I'll delete the package and the repository.

> If there are no copyrights, then I hope maintainers would include it
> in NonGNU ELPA.
>
> Is that intention?

Yes, as a transitory stage to help people install it.

Unless someone wants to maintain all the files in org-contrib and the
NonGNU ELPA package.

-- 
 Bastien

Re: Moving some lisp/ob-*.el files to org-contrib - your advice?

[Jean Louis]

* Bastien  [2021-05-03 18:14]:
> Hi all,
> 
> Less code is less bug and less maintainance.  So I'm considering
> moving these files to the new (unmaintained) org-contrib repo at
> https://git.sr.ht/~bzg/org-contrib:
> 
> - ob-abc.el --- Org Babel Functions for ABC
> - ob-asymptote.el --- Babel Functions for Asymptote
> - ob-coq.el --- Babel Functions for Coq
> - ob-ditaa.el --- Babel Functions for ditaa
> - ob-ebnf.el --- Babel Functions for EBNF
> - ob-hledger.el --- Babel Functions for hledger
> - ob-J.el --- Babel Functions for J
> - ob-ledger.el --- Babel Functions for Ledger
> - ob-lilypond.el --- Babel Functions for Lilypond
> - ob-mscgen.el --- Babel Functions for Mscgen
> - ob-picolisp.el --- Babel Functions for Picolisp
> - ob-vala.el --- Babel functions for Vala evaluation

Personally I use ditaa


If those files have copyrights submitted, should they not end up in
GNU ELPA?

If there are no copyrights, then I hope maintainers would include it
in NonGNU ELPA.

Is that intention?


Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

Sign an open letter in support of Richard M. Stallman
https://stallmansupport.org/
https://rms-support-letter.github.io/

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

[Bruce D'Arcus]

To come back to this 

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

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 added the following to the wiki page, which I think addresses this:

Note that `text/alt` would not make sense, as the sub-style in this case
would override the style.

Bruce

Re: wip-cite status question and feedback

[Denis Maier]

Am 05.05.2021 um 20:14 schrieb 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.



Just to be clear, these are meant as examples for the three language 
specific rules outlined above.
1. is an example for the "American" style, which consistently puts 
punctuation (commas and periods) inside quotation marks even if the 
punctuation mark does not appear in the original quotation.
2. is an example for the "British" style, which seems to conform to what 
seems to be correct in German.
3. is an example for what the latex csquotes describes as "French" style 
where the footnote mark seems to be included in the quotation just 
before the punctuation mark. Yesterday, I've tried to find examples for 
this rule in French book, and I couldn't. I found this:
	- Punctuation is placed inside or outside the quotation marks depending 
on whether you're quoting a complete sentence.

- If punctuation is placed inside the quotation marks the order is: 
."[1]
- If punctuation is placed outside the quotation marks the order is: 
"[1].
- If there is no preceding quotation the order is: [1].
Maybe a native French speaker can shed some light on this?

Denis

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

[Denis Maier]

Am 05.05.2021 um 23:25 schrieb 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 has sent me his test files, and it turned out to be the bibstyle 
(humannat), which apparently isn't included in current tex distributions.
Question: I can't see why this style should be used according to the 
minimal example Bruce has shared. Is this style added as the default 
style by the exporter? Or did you, Bruce, specify it somewhere?


Denis

Re: Notes about citations in Org (part 3)

[Eric S Fraga]

On Wednesday,  5 May 2021 at 13:16, Bruce D'Arcus wrote:
> On Wed, May 5, 2021 at 12:59 PM Maxim Nikulin  wrote:
>> 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?

yes, see, for instance, first example at:

https://www.overleaf.com/learn/latex/Bibtex_bibliography_styles

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