Re: Exporting multiple #+AUTHOR keywords

2024-02-16 Thread ypuntot
Is it related with AUTHOR property?
I am starting to add these properties to every book, and chapter of the book, 
that I study. I hope this doesn't lead to a suboptimal workflow.

Doesn't this work?

:PROPERTIES:
    :AUTHOR:   García-Ael, Cristina and Pérez-Garín, Daniel and Recio Saboya, 
Patricia
    :BTYPE:    incollection
    :BOOKTITLE: Psicología de los Grupos
    :TITLE:    Métodos y Técnicas de Investigación en Psicología de los Grupos.
  
    :PUBLISHER: UNED

    :ADDRESS:  C/ Bravo Murillo, 38; 28015; Madrid
    :INSTITUTION: UNED
    :YEAR: 2017
    :CHAPTER:  2
    :PAGES:    49-83
    :END:


Warn about shell-expansion in the docstring of org-latex-to-html-convert-command

2024-02-16 Thread Martin Edström
I've just been struggling with my custom setting for
`org-latex-to-html-convert-command` outputting many math snippets
wrong. The fault was mine: I didn't correctly shell-quote the input.
I propose to add a warning in the docstring, because many people will
trip the same problem.

The thing is that double-quotes don't work in shell commands.  I had
\"%i\", but it should've been '%i':

(setopt org-latex-to-html-convert-command "node
/home/kept/pub/texToMathML.js \"%i\"")

Math snippets that start with $, like $y = 200$ of course get
butchered into just " = 200$" because of course the first $y gets
interpreted as a shell environment variable.



[BUG] Org parser error Invalid search bound (wrong side of point) [9.7 (9.7-??-7a6bb0904 @ /Users/dougheadley/.config/emacs/.local/straight/build-29.2/org/)]

2024-02-16 Thread General discussions about Org-mode.
using org-ai seemed to cause this bug.  I wouldn't have recieved this 
error otherwise.


Never filed a bug report before.  Please ignore if this seems incomplete.



⛔ Warning (org-element): org-element--cache: Org parser error in 
2024-02-14.org::898. Resetting.

The error was: (error "Invalid search bound (wrong side of point)")
Backtrace:
" backtrace-to-string(nil)
org-element-at-point()
org-eldoc-get-src-lang()
#f(compiled-function (&rest args) \"Return breadcrumbs when on a 
headline, args for src block header-line,\\n calls other documentation 
functions depending on lang when inside src body.\" #0x16f3b50a8f808dd9>)(#f(compiled-function (string &rest plist) 
#))
apply(#f(compiled-function (&rest args) \"Return breadcrumbs when on a 
headline, args for src block header-line,\\n calls other documentation 
functions depending on lang when inside src body.\" #0x16f3b50a8f808dd9>) #f(compiled-function (string &rest plist) 
#))
org-eldoc-documentation-function(#f(compiled-function (string &rest 
plist) #))

eldoc-documentation-default()
eldoc--invoke-strategy(nil)
eldoc-print-current-symbol-info()
#()
apply(# nil)
timer-event-handler([t 0 0 50 nil #F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_13> nil idle 0 nil])

"
Please report this to Org mode mailing list (M-x org-submit-bug-report).

Emacs : GNU Emacs 29.2 (build 2, x86_64-apple-darwin23.2.0, NS 
appkit-2487.30 Version 14.2.1 (Build 23C71))

of 2024-01-24
Package: Org mode version 9.7 (9.7-??-7a6bb0904 @ 
/Users/dougheadley/.config/emacs/.local/straight/build-29.2/org/)


current state:
==
(setq
org-noter--doc-goto-location-hook '(org-noter-djvu--goto-location
org-noter-nov--goto-location
org-noter-pdf--goto-location)
org-journal-date-prefix "#+TITLE: "
org-link-elisp-confirm-function nil
org-directory "~/Network/syncthing/org"
org-after-refile-insert-hook '(save-buffer)
org-indirect-buffer-display 'current-window
org-roam-db-gc-threshold 2305843009213693951
org-crypt-key nil
org-hide-emphasis-markers t
org-bibtex-headline-format-function 'org-bibtex-headline-format-default
org-log-done 'time
org-roam-mode-hook '(+org-roam-detach-magit-section-mode-map-h
turn-on-visual-line-mode)
org-roam-dailies-capture-templates '(("d" "Default" entry "** %<%H:%M> %?"
:if-new
(file+head "%<%Y-%m-%d>.org"
"#+title: %<%Y-%m-%d>\n#+STARTUP: overview\n\n* master 
[[file:~/Network/syncthing/org/todo.org][todo]], 
[[id:0261f526-24cf-43a2-83b6-f9612334b685][job hunt]]\n* coffee time\n* 
work\n* personal\n* wrap up\n* daily journal\n")

)
)
org-load-hook '(+org-init-org-directory-h +org-init-appearance-h
+org-init-agenda-h +org-init-attachments-h
+org-init-babel-h +org-init-babel-lazy-loader-h
+org-init-capture-defaults-h +org-init-capture-frame-h
+org-init-custom-links-h +org-init-export-h
+org-init-habit-h +org-init-hacks-h +org-init-keybinds-h
+org-init-popup-rules-h +org-init-smartparens-h
+org-init-roam-h)
org-journal-find-file-fn 'find-file
org-startup-folded nil
org-babel-after-execute-hook 
'(+org-redisplay-inline-images-in-babel-result-h)

org-link-abbrev-alist '(("doomdir" . "/Users/dougheadley/.config/doom/%s")
("emacsdir" . "/Users/dougheadley/.config/emacs/%s")
("doom-repo" .
"https://github.com/doomemacs/doomemacs/%s";)
("wolfram" . "https://wolframalpha.com/input/?i=%s";)
("wikipedia" . "https://en.wikipedia.org/wiki/%s";)
("duckduckgo" . "https://duckduckgo.com/?q=%s";)
("kagi" . "https://kagi.com/search?q=%s";)
("gmap" . "https://maps.google.com/maps?q=%s";)
("gimages" . "https://google.com/images?q=%s";)
("google" . "https://google.com/search?q=";)
("youtube" . "https://youtube.com/watch?v=%s";)
("github" . "https://github.com/%s";))
org-agenda-files 
'("/Users/dougheadley/Network/syncthing/org/roam/20230912175002-job_hunt.org" 
"/Users/dougheadley/Network/syncthing/org/d.passiveobserver.org" 
"/Users/dougheadley/Network/syncthing/org/roam/20230612223054-diycloud.org" 
"/Users/dougheadley/Network/syncthing/org/20240104160254-iccesar.org" 
"/Users/dougheadley/Network/syncthing/org/todo.org" 
"/Users/dougheadley/Network/syncthing/org/20231101101832-gusto.org" 
"/Users/dougheadley/Network/syncthing/org/agenda.org")

org-journal-dir "~/Network/syncthing/org/journal/"
org-journal-date-format "%a, %Y-%m-%d"
org-capture-templates '(("d" "d.passiveobserver" entry
(file "~/Documents/org/d.passiveobserver.org")
"* TODO %?")
("g" "GitHub Link Capture" entry
(file "~/Documents/org/github.org")
"* [[%?]] Entered on %U")
("t" "Personal todo" entry
(file+headline +org-capture-todo-file "Inbox")
"* %u %?\n%i\n%a" :prepend t)
("n" "Personal notes" entry
(file+headline +org-capture-notes-file "Inbox")
"* %u %?\n%i\n%a" :prepend t)
("p" "Templates for projects")
("pt" "Project-local todo" entry
(file+headline +org-capture-project-todo-file
"Inbox")
"* TODO %?\n%i\n%a" :prepend t)
("pn" "Project-local notes" entry
(file+headline +org-capture-project-notes-file
"Inbox")
"* %U %?\n%i\n%a" :prepend t)
("pc" "Project-local changelog" entry
(file+headline +

Re: Asynchronous blocks for everything (was Re: [BUG] Unexpected result when evaluating python src block asynchronously [9.7-pre (release_9.6.17-1131-gc9ed03.dirty @ /home/yantar92/.emacs.d/straight/b

2024-02-16 Thread Bruno Barbier

Hi Matt, Jack, Ihor,

Sorry for the late reply.  Cleaning the code took me longer than
expected.


Jack Kamm  writes:

> Bruno Barbier  writes:
>
>> FWIW, I've been trying to use asynchronous blocks for everything, not
>> only the source blocks that are based on the comint mode.
>> ...
>
> Sounds interesting, a couple questions:
>
> 1. Which languages have you implemented/tested this on?

I'm not using it with official org backends (yet).  I'm using it with
several custom backends that I'm working on.  One of the backend
delegate the block executions to emacs subprocesses: so I have a kind of
asynchronous executions for free for any language, including elisp
itself.


> 2. Does it apply for sessions, nonsessions, or both?
>

The new API itself is more about how to wait for and display one block
result.  So, it's not really aware of sessions.

But, I usually try to think as "no session" as a "one shot" session
(like Matt wrote in his email).  So, in that sense, it works for both
anyway ;-)


> Also interesting, I think it's worth exploring/testing this overlay idea
> out. Does that mean that output is asynchronously printing into the Org
> buffer? It sounds cool but I wonder if it might cause problems while
> trying to edit another part of the buffer.

Currently, I've limited the progress feedback to fit on one line to
avoid anoying vertical display jumps.  When the computation is
successful, the result is inserted as usual, and, that may be annoying;
when it updates a previous result of the same height, it's ok.  Else, we
could fold it to stay on one line too (using the overlay), until the
user explicitly request to see it.

Jack Kamm  writes:
>
> That all sounds reasonable...if you work on this, let me know if you
> want any help with testing.

Thanks.  I'll definitely appreciate your help, to test the current
code with the Python backend or any other backend if you prefer.


Matt  writes:

> If I followed correctly, the topic switched to discussing async
> generally within Babel.  I've started a new thread accordingly.

Indeed. Thank you!


>  > FWIW, I've been trying to use asynchronous blocks for everything, not only 
> the source blocks that are based on the comint mode.
>
> I've been trying to figure out how to make everything async by default.  I'm 
> super interested to see what you've come up with.

Good to know.  Let's we make this happen! 


>  > I think it would be good if ob-core itself could provide an asynchronous 
> API.
>
> Fortunately or unfortunately, depending on how you look at it, Babel already 
> does.
>

> The challenge is that the Org Babel API has grown piecemeal over 14 years.  
> It's been written by several authors with limited time and knowledge.  The 
> result, while powerful and useful, is a bit of a hodgepodge.  A prime example 
> is that the concepts of "persistence" and "synchronicity" are conflated.  
> "Session" is often used to mean "asynchronous" even though the two ideas are 
> orthogonal.  Emacs provides primitives that could make non-session blocks 
> asynchronous.  It's historical accident that blocks aren't async by default.

> For me, the issue is that the Babel API needs some high level perspective in 
> order to make it consistent.

> I see the following terms as guides.  If we can separate these concepts 
> within the API, then Babel to *feel* like an API:
>
> - "Session" means a shell environment is "persistent."  Each call is executed 
> in the same environment.  State exists between calls.
>
> - "Non-session" means a shell environment is "temporary."  Each call is 
> executed in an independent environment.  State does not exist between calls.
>
> - "Synchronous" means that execution prevents the user from editing the 
> document while results are obtained.
>
> - "Asynchronous" means that execution does not prevent the user from editing 
> the document while results are obtained.

I mostly think the same.  Sessions (including the "none" session)
definitely need some generic API and some generic tests that all
backends could just reuse.

To execute Python blocks, using the proposed async API:

   - I've (re)implemented the "asynchronous with session" case (copying/pasting
 the relevant part from ob-python).
   
   - The "synchronous case" is just artificially blocking the user until
 the asynchronous result is known (which looks incredibly tricky to
 implement if even possible...).
   
   - The "no session" case is just about creating a new unique session
 and throwing it away immediately.

But, some users may rely on some particular behavior, of the current
implementations, that may be hard to implement in such a generic way.


> The use of the overlay is a really cool idea!
>
> I hesitate to say that's a good way to convey success or failure.  If a 
> process failed, I want to see the output which tells me why so that I can 
> correct it.  Or, I might actually want the failure output.  Maybe I want to 
> literally demonstrate what a code f

Re: [BUG] ox-odt messes with auto-mode-alist [9.7-pre (release_9.6.11-1090-g76468c.dirty @ /home/viz/lib/emacs/straight/build/org/)]

2024-02-16 Thread Max Nikulin

On 16/02/2024 21:57, Visuwesh wrote:


 (dolist (desc org-odt-file-extensions)
   ;; Let Emacs open all OpenDocument files in archive mode.
   (add-to-list 'auto-mode-alist
(cons (concat  "\\." (car desc) "\\'") 'archive-mode)))

Package: Org mode version 9.7-pre (release_9.6.11-1090-g76468c.dirty @ 
/home/viz/lib/emacs/straight/build/org/)


git log -1 76468c --
fatal: bad revision '76468c'

See

Ihor Radchenko. Re: [BUG] ox-odt.el overrides auto-mode-alist defaults 
[9.6.6 (release_9.6.6 @ /usr/share/emacs/29.1/lisp/org/)]

Sat, 09 Dec 2023 10:49:04 +.
https://list.orgmode.org/87plzfslb3.fsf@localhost




[BUG] ox-odt messes with auto-mode-alist [9.7-pre (release_9.6.11-1090-g76468c.dirty @ /home/viz/lib/emacs/straight/build/org/)]

2024-02-16 Thread Visuwesh


Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.  You don't know how to make a good report?  See

 https://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org mailing list.


ox-odt.el contains the following lines at the end of file:

;;; Library Initializations

(dolist (desc org-odt-file-extensions)
  ;; Let Emacs open all OpenDocument files in archive mode.
  (add-to-list 'auto-mode-alist
   (cons (concat  "\\." (car desc) "\\'") 'archive-mode)))

Is there a reason why this is done?  This breaks the expected result of
opening .odt and friends using doc-view-mode, and causes unnecessary
confusion (it is not particularly easy to find too since grepping
through Emacs for "\\.odt" fails).

Emacs  : GNU Emacs 30.0.50 (build 42, x86_64-pc-linux-gnu, X toolkit, cairo 
version 1.18.0, Xaw scroll bars)
 of 2024-01-31
Package: Org mode version 9.7-pre (release_9.6.11-1090-g76468c.dirty @ 
/home/viz/lib/emacs/straight/build/org/)



detangling with babel :var header entries

2024-02-16 Thread Fraga, Eric
Hello all,

I'm looking for some advice.  I do most (if not all) of my coding within
org, using src blocks which are tangled to create the actual code to
run.  Although I usually edit the code from within the org file, using
org-edit-special, I sometimes, when debugging, edit the tangled code
file directly.  If I do this, it's very convenient to detangle that
source file to get the original src blocks updated.  Very nice indeed.

However, if I have, as an example, a code block like this which has a
:var variable to be incorporated into the tangled code:

--8<---cut here---start->8---
#+name: init
#+begin_src julia :var version=(org-sbe tomlversion)
  lastchange = "[2024-02-16 12:54+]"
  function __init__()
  println("# My Package v$version, last change $lastchange")
  end
#+end_src
--8<---cut here---end--->8---

this gets tangled to something like this:

--8<---cut here---start->8---
# [[file:../code.org::init][init]]
version = "0.2024.211"
lastchange = "[2024-02-16 12:54+]"
function __init__()
println("# My Package v$version, last change $lastchange")
end
# init ends here
--8<---cut here---end--->8---

When I detangle, the original src block now has that version line in the
src block.  So next time I tangle, I get another version line added, ad
infinitum if I keep on tangling and detangling.

Can anybody suggest a workaround that allows me to incorporate a :var
data field in a src block but still allow to tangling/detangling to work
as it should?  I cannot think of any way and can obviously live with it
(I just have to remember to delete the spurious version lines
periodically...).

If there is no way, a feature request might be to have some way to
indicate blocks that should not be detangled?  Alternatively, a hash of
some sort on the tangled file blocks that allow detangling to easily
identify those blocks that have changed and need updating in the
original src block?  The latter might (? maybe not) make detangling a
lot faster as well... but both options are beyond my elisp-foo so cannot
implement these myself unfortunately.

Thank you,
eric

-- 
: Eric S Fraga, with org release_9.6.13-1003-g872c1b in Emacs 30.0.50