Re: bug#59882: Multiple versions of Org in load-path problem

[Tom Gillespie]

> The state of our unloading support is not good enough to use it blindly

I have managed to use unload-feature to reload a new version of org
after the builtin version has been previously loaded, but the dance you
have to do to avoid nasty errors (and segfaults if using native comp!)
is about 100 lines of arcane footwork, and if any one step is off you
will encounter one of the many hidden landmines.

unload-feature cannot be used blindly, and there are a very large
number of side effects along the path that are not controlled which
makes any process that tries to use unload-feature brittle and hard
to debug.

https://github.com/tgbugs/orgstrap/blob/f35bccde556b0f82515e79ee69f4379469276356/ow.el#L1010-L1064
https://github.com/tgbugs/orgstrap/blob/f35bccde556b0f82515e79ee69f4379469276356/ow.el#L1073-L1177

[BUG] Org-LaTeX-export: >> and << (inside of ~code~/=verbatim=) gets exported to single monospace symbol instead of 2 monospace symbols [9.5.5 (release_9.5.5 @ /usr/share/emacs/28.2/lisp/org/)]

[Garid Z.]

I tried to export following org file (table) to PDF via
org-latex-export-to-pdf. 

* Test Org-file
|---+--+--|
| 1 | =>=  | =<=  |
| 2 | =>>= | =<<= |
| 3 | =>>>=| =<<<=|
| 4 | ==   | ==   |
| 5 | =>=  | =<=  |
| 6 | =>>= | =<<= |
|---+--+--|
| 1 | ~>~  | ~<~  |
| 2 | ~>>~ | ~<<~ |
| 3 | ~>>>~| ~<<<~|
| 4 | ~~   | ~~   |
| 5 | ~>~  | ~<~  |
| 6 | ~>>~ | ~<<~ |
|---+--+--|

Resulted PDF file has » and « symbols (maybe: U+00BB, U+00AB)
instead of 2 normal < symbols.


>From the org manual:
> Text in the code and verbatim string is not processed for Org specific
> syntax; it is exported verbatim.


So, I believe it should've exported 2 normal < symbols (verbatim), not a
single (U+00BB, U+00AB) symbol.



I think, it's a very similar case with double (or more) ==
characters in the code/verbatim. I recently reported this similar case:
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=5ac1ebaa1

Solution for this might be almost identical with the previous fix.
Maybe something like:

+(cond ((equal m ">>") ">{}>{}")
+(cond ((equal m "<<") "<{}<{}")


Best,

Garid Zorigoo



Emacs  : GNU Emacs 28.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.36, 
cairo version 1.17.6)
 of 2023-01-03
Package: Org mode version 9.5.5 (release_9.5.5 @ 
/usr/share/emacs/28.2/lisp/org/)
-- 
Garid Z.

Re: Command not found when using Org + Guix + envrc.el

[Fabio Natali]

On 2023-04-16, 10:21 -0600, "Adolfo De Unanue"  wrote:
> I am facing the same problem, hopefully some one can help us

Hi Adolfo, thanks for letting me know. It's always (somewhat) reassuring
to know that others are facing the same problem.

Good news: my issue is solved on version 0.5 of envrc.el - if you're
also on Guix, a 'guix pull && guix upgrade' might fix your problem too!

Best, cheers, Fabio.

Re: Command not found when using Org + Guix + envrc.el

[Fabio Natali]

On 2023-04-17, 10:35 +, Ihor Radchenko  wrote:
> I am unsure how and why the Org's approach is not working together
> with envrc.el. It might be helpful to add envrc devs into the loop or
> debug things yourself.

Hi Ihor,

Thanks for getting back to me.

The project's author got in touch pointing out that I was using an
out-of-date version of the software.

As a matter of fact the version of envrc.el available via my distro
(Guix) was a bit behind, but this is now fixed. I can confirm this is no
longer an issue with version 0.5 of envrc.el.

Thanks for helping, all best, Fabio.

Re: Worg: issue with org-tools page

[Karl Voit]

Hi Ihor,

* Ihor Radchenko  wrote:
> Karl Voit  writes:
>
>> Okay, that was also my idea when I saw the log file. Can somebody
>> fix ESS here or should we convert the R blocks to a different block
>> type (EXAMPLE)?
>
> I believe that I fixed the issue in
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=4929f0c55f
>
> But I am not sure if I actually did. We need to trigger WORG rebuild to
> see, I think.

I just committed a minimal change to that file which caused the CI
to re-build the page: https://builds.sr.ht/~bzg/job/975519 which
ended successfully but still shows an error:

[...]
[exporting] org-tests/index.org
[exporting] org-tools/index.org
Executing R code block at position 5304...
Cannot open load file: No such file or directory, ess-r-mode
[exporting] org-tutorials/org-R/org-R.org
[...]

https://orgmode.org/worg/org-tools/ doesn't show the current content
from the Orgdown file.

The issue still persists.

-- 
get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode:
   > get Memacs from https://github.com/novoid/Memacs <
Personal Information Management > http://Karl-Voit.at/tags/pim/
Emacs-related > http://Karl-Voit.at/tags/emacs/

Re: org-crypt fails if default key is expired while non-default key is to be used

[Karl Voit]

* Ihor Radchenko  wrote:
> Karl Voit  writes:
>
>>> Ok. What about
>>>
>>> (let ((context (epg-make-context nil t t)))
>>>   (epg-decrypt-string context (epg-encrypt-string context "test" 
>>> (epg-list-keys context org-crypt-key
>>>
>>
>> It asks me for the passphrase of the orgmode key (the correct one)
>> and prints out "test".
>
> We just followed what org-crypt does... And you see no error.
> I have no more ideas how to investigate the original failure without a
> reproducer.

Fully understand. If it was an issue that was caused just by me, the
better. Thanks for investing into that issue or non-issue anyway!

-- 
get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode:
   > get Memacs from https://github.com/novoid/Memacs <
Personal Information Management > http://Karl-Voit.at/tags/pim/
Emacs-related > http://Karl-Voit.at/tags/emacs/

Re: [BUG] ob-R tests fail on Emacs 27 since ESS commit 536b5b914a7 [9.7-pre (release_9.6.4-318-gcfe5e0.dirty @ /home/yantar92/.emacs.d/straight/build/org/)]

[Lionel Henry]

> Do note that the root cause remains on the ESS side - `run-ess-r' in
> Emacs 27, when called non-interactively, may set line splitting to
> something strange.

I think you're right. Probably we shouldn't be executing screen
options when called non-interactively and instead leave the R default
width (80).

I've opened an issue to track this:
https://github.com/emacs-ess/ESS/issues/1248

Best,
Lionel


On 4/18/23, Ihor Radchenko  wrote:
> Lionel Henry  writes:
>
>> Can you try with the latest commit please?
>> https://github.com/emacs-ess/ESS/commit/ed6c12ee3dfb1046fb030200f45e75a65b31e49e
>
> Works now. Thank you!
>
>> By the way, it looks like you're setting the width in the exported
>> initialization routine rather than just in tests. For user-facing
>> features at least you probably want to set the width to something that
>> will produce readable output.
>
> You are right. For some reason, I thought that the problem also affects
> :results value, when we want to convert ESS interactive output into
> Elisp data. But it was not the case - only :results output has been
> affected.
>
> Since we have no reason to disregard ESS output settings in :results
> output, I pushed an alternative fix that only affects tests, as you
> suggested.
>
> Do note that the root cause remains on the ESS side - `run-ess-r' in
> Emacs 27, when called non-interactively, may set line splitting to
> something strange. I am unsure if it is something that should be fixed
> on ESS side. I am also unsure if the problem does not happen in other
> Emacs versions.
>
> Fixed, on main.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=83e446ea8
>
> I also added a test for :results value when the output is long. Just in
> case.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=3c449cc43
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>

Re: [BUG] ob-R tests fail on Emacs 27 since ESS commit 536b5b914a7 [9.7-pre (release_9.6.4-318-gcfe5e0.dirty @ /home/yantar92/.emacs.d/straight/build/org/)]

[Ihor Radchenko]

Lionel Henry  writes:

> Can you try with the latest commit please?
> https://github.com/emacs-ess/ESS/commit/ed6c12ee3dfb1046fb030200f45e75a65b31e49e

Works now. Thank you!

> By the way, it looks like you're setting the width in the exported
> initialization routine rather than just in tests. For user-facing
> features at least you probably want to set the width to something that
> will produce readable output.

You are right. For some reason, I thought that the problem also affects
:results value, when we want to convert ESS interactive output into
Elisp data. But it was not the case - only :results output has been
affected.

Since we have no reason to disregard ESS output settings in :results
output, I pushed an alternative fix that only affects tests, as you
suggested.

Do note that the root cause remains on the ESS side - `run-ess-r' in
Emacs 27, when called non-interactively, may set line splitting to
something strange. I am unsure if it is something that should be fixed
on ESS side. I am also unsure if the problem does not happen in other
Emacs versions.

Fixed, on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=83e446ea8

I also added a test for :results value when the output is long. Just in
case.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=3c449cc43

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] ob-R tests fail on Emacs 27 since ESS commit 536b5b914a7 [9.7-pre (release_9.6.4-318-gcfe5e0.dirty @ /home/yantar92/.emacs.d/straight/build/org/)]

[Lionel Henry]

Can you try with the latest commit please?
https://github.com/emacs-ess/ESS/commit/ed6c12ee3dfb1046fb030200f45e75a65b31e49e

By the way, it looks like you're setting the width in the exported
initialization routine rather than just in tests. For user-facing
features at least you probably want to set the width to something that
will produce readable output.

Best,
Lionel


On 4/18/23, Ihor Radchenko  wrote:
> Lionel Henry  writes:
>
>> Thanks for looking into this. I think you're right it's probably
>> caused by ESS now setting the width on startup. In that case you could
>> fix your tests by setting `options(width = )` to some hardcoded value.
>> You could do it via `ess-r-post-run-hook`.
>
> I tried using `ess-r-post-run-hook', but it fails for some reason.
> See the attached patch.
>
> With the patch, the tests fail with
>
> Test ob-session-async-R-value-drawer condition:
> (user-error "ESS process not ready. Finish your command before trying
> again")
>
> In contrast, directly editing `ess-r-initialize' like
>   ;; (ess-execute-screen-options t)
>   (ess-command (ess-calculate-width ))
>
> does not fail and make all the tests pass.
>
> Is there anything I am missing about `ess-r-post-run-hook'?
>
>

Re: [BUG] ob-R tests fail on Emacs 27 since ESS commit 536b5b914a7 [9.7-pre (release_9.6.4-318-gcfe5e0.dirty @ /home/yantar92/.emacs.d/straight/build/org/)]

[Lionel Henry]

Hi Ihor,

Thanks for looking into this. I think you're right it's probably
caused by ESS now setting the width on startup. In that case you could
fix your tests by setting `options(width = )` to some hardcoded value.
You could do it via `ess-r-post-run-hook`.

Best,
Lionel


On 4/17/23, Ihor Radchenko  wrote:
>
> Steps to reproduce:
>
> 1. cd /path/to/org/git/repo
> 2. make test EMACS=emacs-27 BTEST_POST="-L /path/to/ESS/lisp -l ob-R -l ess
> -l ess-r-mode" BTEST_RE="async"
>
> 3 unexpected results:
>FAILED  ob-session-async-R-named-output
>FAILED  ob-session-async-R-output-drawer
>FAILED  ob-session-async-R-simple-session-async-output
>
> The tests started failing since 2023/04/04.
> https://builds.sr.ht/~bzg/job/968099
>
> I bisected the failure down to the following ESS commit:
>
> 536b5b914a75afa37ee05aa8ba0aecd0f9c9eb33
> Author: Lionel Henry 
> AuthorDate: Mon Apr 3 13:01:11 2023 +0200
> Commit: Lionel Henry 
> CommitDate: Mon Apr 3 13:01:11 2023 +0200
>
> Parent: fef059c3 Wait for process after `ess-r-post-run-hook`
> Contained:  master
> Follows:ESSRv1.8 (21)
>
> Move `ess-r` startup commands out of `ess-r-post-run-hook`
>
> They are blocking commands and the user might have added streaming
> commands to the hook.
>
> Also document why users should be careful when mixing blocking and
> streaming commands.
>
> --
>
> I am not sure what is going on as ob-R does not really use the changed
> hooks. The suspects are
>
> (ess-execute-screen-options t)
> (ess-set-working-directory default-directory)))
>
> In particular, I think that `ess-execute-screen-options' is doing
> something funny because one of the tests fails with
>
> "1:5" outputting
>
>  1 2 3
>  4 5
>
> split into two lines, which looks like some text filling problem.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>

Re: A dream?

[Adolfo De Unanue]

Hi Pedro,

Do you mind to share those slides? I am teaching too and that will help me a 
lot 
Thanks in advance

- Adolfo

On Mon, Apr 17, 2023, at 23:35, Pedro Andres Aranda Gutierrez wrote:
> > Jean Louis :
> >> Eduardo Ochs  [2023-04-16 01:45]:
> >> do you have a page in https://gnu.support/ explaining in detail how
> >> you teach Emacs to beginners? It would be nice to have something like
> >> that...
> >
> >I just tell them to do Emacs Tutorial. There is no need for page when
> >it is built-in.
> >
> >I tell them, open Emacs and do the tutorial, then let me know. Later
> >we do not talk much, we just do the work.
> 
> In addition to that, I have also collected a set of slides with suggestions 
> and
> quick answers to some of the configuration hurdles. That helps a lot (they 
> say)
> In addition, I have an article on org-mode. 
> I submitted to the (wrong) journal and never got published on paper ,-(
> That was a couple of years ago and I have continued to update it for my 
> personal
> reference. When people have specific interest in org-mode I pass 
> the lastest version in PDF and org for them to play around. The teaser for 
> this
> is any of my lecture handouts.
> 
> Best, /PA
> 
> --
> Fragen sind nicht da, um beantwortet zu werden,
> Fragen sind da um gestellt zu werden
> Georg Kreisler
> 
> Headaches with a Juju log:
> unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run a 
> leader-deposed hook here, but we can't yet

Re: Worg: issue with org-tools page

[Ihor Radchenko]

Karl Voit  writes:

> Okay, that was also my idea when I saw the log file. Can somebody
> fix ESS here or should we convert the R blocks to a different block
> type (EXAMPLE)?

I believe that I fixed the issue in
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=4929f0c55f

But I am not sure if I actually did. We need to trigger WORG rebuild to
see, I think.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [ANN] org-jami-bot

[Russell Adams]

On Mon, Apr 17, 2023 at 09:22:48PM +0200, Hanno Perrey wrote:
>
> Dear fellow org-users,
>
> I have just released two new packages that scratch an old itch of mine:
> capturing thoughts, quick notes and URLs while "on the road" with only
> my mobile phone around. Messaging myself feels most natural, so that is
> what I went with: triggering a capture via GNU Jami, the distributed
> private messenger.
>
> The first package, =jami-bot= provides something of a framework to
> handle incoming text and file messages. =org-jami-bot= provides hooks
> and functions that extend this to Org mode captures. Any text or file is
> being captured, but even simple commands (prefixed with '!') are
> possible, for example:

Hanno, this is brilliant.

I rely heavily on using XMPP notifications with my Emacs/Org setup for
appointments. I run a local program for send-xmpp to fire off messages
that alert my multiple PC's and my cell phone on my XMPP account.

I hadn't considered sending data BACK. That's awesome!

How hard would it be to port this to a message agnostic style where
other methods could be used?

I've used Jami before, but I consider it VOIP software trying to
become messenger, where XMPP is messenger trying to become VOIP. I've
had battery problems in the past with Jami, but that was back when it
was called Ring.

I may have to try and adapt this to my workflow.

Thanks for sharing!

--
Russell Adamsrlad...@adamsinfoserv.com
https://www.adamsinfoserv.com/

Re: [ANN] org-jami-bot

[Ihor Radchenko]

Hanno Perrey  writes:

> The first package, =jami-bot= provides something of a framework to
> handle incoming text and file messages. =org-jami-bot= provides hooks
> and functions that extend this to Org mode captures. Any text or file is
> being captured, but even simple commands (prefixed with '!') are
> possible, for example:
>
> #+begin_example
> !schedule monday
> buy oat milk
> #+end_example
>
> Schedules a todo entry for next monday.

Thanks for sharing!
This is pretty impressive.
Do you plan to publish these packages on ELPA?
If so, I can see the packages being referenced in
https://orgmode.org/worg/#use-effectively

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [test] org-colview/org-columns

[Ihor Radchenko]

Sławomir Grochowski  writes:

> I'm trying to better understand 'org-colview/org-columns'.
> So I wrote some tests. File in attachment.

Thanks! The tests look good to me.

> I hope the commit message is correct.
> ...
> * test-org-colview.el (test-org-colview/uncompile-format,
> test-org-colview/compile-format): Add tests for functions:
> org-columns-uncompile-format & org-columns-compile-format

Almost. You forgot `...' quotes around Elisp symbols and "." at the end
of sentence.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] ob-R tests fail on Emacs 27 since ESS commit 536b5b914a7 [9.7-pre (release_9.6.4-318-gcfe5e0.dirty @ /home/yantar92/.emacs.d/straight/build/org/)]

[Ihor Radchenko]

Lionel Henry  writes:

> Thanks for looking into this. I think you're right it's probably
> caused by ESS now setting the width on startup. In that case you could
> fix your tests by setting `options(width = )` to some hardcoded value.
> You could do it via `ess-r-post-run-hook`.

I tried using `ess-r-post-run-hook', but it fails for some reason.
See the attached patch.

With the patch, the tests fail with

Test ob-session-async-R-value-drawer condition:
(user-error "ESS process not ready. Finish your command before trying 
again")

In contrast, directly editing `ess-r-initialize' like
  ;; (ess-execute-screen-options t)
  (ess-command (ess-calculate-width ))

does not fail and make all the tests pass.

Is there anything I am missing about `ess-r-post-run-hook'?

>From 07407519d2e8de0f2925a9d2971b855fd0be86b4 Mon Sep 17 00:00:00 2001
Message-Id: <07407519d2e8de0f2925a9d2971b855fd0be86b4.1681814636.git.yanta...@posteo.net>
From: Ihor Radchenko 
Date: Tue, 18 Apr 2023 12:42:29 +0200
Subject: [PATCH] ob-R: Fix regression after ESS commit 536b5b914a7

* lisp/ob-R.el (org-babel-R--set-wide-screen-width): New function
setting fill column to large value in ESS interactive shell.
(org-babel-R-initiate-session): Override the default ESS truncation
settings.

Reported-by: Ihor Radchenko 
Link: https://orgmode.org/list/87ilduqrem.fsf@localhost
---
 lisp/ob-R.el | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/lisp/ob-R.el b/lisp/ob-R.el
index 7ea137197..9ad878370 100644
--- a/lisp/ob-R.el
+++ b/lisp/ob-R.el
@@ -39,6 +39,10 @@ (declare-function orgtbl-to-tsv "org-table" (table params))
 (declare-function run-ess-r "ext:ess-r-mode" ( start-args))
 (declare-function inferior-ess-send-input "ext:ess-inf" ())
 (declare-function ess-make-buffer-current "ext:ess-inf" ())
+(declare-function
+ ess-command "ext:ess-inf"
+ (cmd  out-buffer sleep no-prompt-check wait proc proc force-redisplay timeout))
+(declare-function ess-calculate-width "ext:ess-inf" (opt))
 (declare-function ess-eval-buffer "ext:ess-inf" (vis))
 (declare-function ess-wait-for-process "ext:ess-inf"
 		  ( proc sec-prompt wait force-redisplay))
@@ -261,7 +265,13 @@ (defun org-babel-R-assign-elisp (name value colnames-p rownames-p)
 	  (t(format "%s <- %S" name (prin1-to-string value))
 
 
+(defun org-babel-R--set-wide-screen-width ()
+  "Set large screen width in current R buffer."
+  (org-require-package 'ess-inf "ESS")
+  (ess-command (ess-calculate-width )))
+
 (defvar ess-ask-for-ess-directory) ; dynamically scoped
+(defvar ess-r-post-run-hook)
 (defun org-babel-R-initiate-session (session params)
   "If there is not a current R process then create one."
   (unless (string= session "none")
@@ -277,7 +287,10 @@ (defun org-babel-R-initiate-session (session params)
 	;; Session buffer exists, but with dead process
 	(set-buffer session))
   (org-require-package 'ess-r-mode "ESS")
-  (set-buffer (run-ess-r))
+  (let ((ess-r-post-run-hook
+ (cons #'org-babel-R--set-wide-screen-width
+   ess-r-post-run-hook)))
+(set-buffer (run-ess-r)))
 	  (let ((R-proc (get-process (or ess-local-process-name
 	 ess-current-process-name
 	(while (process-get R-proc 'callbacks)
-- 
2.40.0


-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at