Re: How to disable completely org-persist

[tomas]

On Sat, Dec 31, 2022 at 02:29:43AM +0100, Angelo Graziosi wrote:
> 
> > Il 30/12/2022 18:42 Colin Baxter ha scritto:
> > 
> >  
> > > Angelo Graziosi writes:
> > 
> > > tomas wrote:
> > >> there is now a defvar `org-element-cache-persistent'
> > 
> > > Ah! didn't knew that..
> > 
> > > Setting
> > 
> > > (setq org-element-cache-persistent nil)
> > 
> > > seems to work..
> > 
> > Indeed, although I'm not yet convinced that org-persist directories wont
> > eventually start showing up in /tmp!
> 
> I fear that sooner or later it will reappear somewhere.. 

Hm. I'm sure people are accepting patches?

Having persistence "centralised" in an org-persist facility
should make it easier for you (or me) to control what happens.

Otherwise, each exporter might be creating files everywhere.

Perhaps it would make sense to state the goals in more
detail. I can see many "aspects":

 - "I don't want my ~/.emacs.d/ littered beyond my explicit
   control"
 - "I don't have (nor want to have) XDG directories"
 - "I don't want things in /tmp" [1]
 - "I don't want my Emacs's session state to spill to
   persistent media"

What is it what you (or me, or anyone) wants to achieve?

Cheers

[1] Currently I see two directories in /tmp made by my emacs
   session: some `babel-...', which seems to be made at Org mode
   load (before any babel things are invoked), and `emacs1000'
   (I start Emacs as a server, so that's where the socket goes)
   
-- 
t


signature.asc
Description: PGP signature

[BUG] Checkbox item is broken in html export with table content [9.6 (9.6-??-bed47b437 @ /Users/hw/.emacs.d/.local/straight/build-28.1/org/)]

[nunnery-09-bayside]

The HTML Export is a bit broken when the checkbox item has table
content. See the HTML exporting difference between section A and B in follow 
code. (also attached a screenshot below)

#+BEGIN_SRC org
* A
1. [ ] test
2. [ ] foo
3. [ ] bar

* B
a. [ ] foo
b. [ ] bar

   | a | b | c |
   |---+---+---|
   | 1 | 1 | 1 |
   | 2 | 2 | 2 |
#+END_SRC

Emacs  : GNU Emacs 28.1 (build 2, aarch64-apple-darwin21.6.0, NS appkit-2113.60 
Version 12.5 (Build 21G72))
of 2022-08-12
Package: Org mode version 9.6 (9.6-??-bed47b437 @ 
/Users/hw/.emacs.d/.local/straight/build-28.1/org/)

Re: Export Org with Org concept -- Re: Problems with C-c C-e file.org,

[Jean Louis]

* Eduardo Ochs  [2022-12-31 04:11]:
> Hi Jean Louis,
> 
> did you solve your problem? Did you find a way to replace the
> blocking code by something else?

Of course, for me personally, I have fully solved it, you can see
video here:

https://gnu.support/files/emacs/packages/rcd-org-export/2022-12-20-19:33:59.ogv

And I will add over time the detection of any possible export backend
that I may find. What export backends is available, it will be
detected and then automatically expanded like Org headings for it, and
what user does not want, shall be detected and not shown.

I think that original code for Org came into existance before 10+
years as back then there were maybe just few keybindings, maybe just
2-3 keybindings. So it was all about pure export.

Over the time Org developed the need for toggling of options such as:

** Export Options

- [ ] Export body only - [b]
- [ ] Export only current subtree - [s]
- [ ] Export asynchronously - [a]
- [ ] Export visible only - [v]
- [ ] Force publishing - [f]

then other backends appeared. And that caused over time that users did
not have any more just 2-3 keys, but it became a full screen now, with
variables to be toggled. 

By the way, the above heading "Export Options" I could freely copy
from the RCD Org Export interface, while something like that is
impossible when using M-x org-export-dispatch function or "C-c C-e"

Nobody in 10 years looked how it can be improved, so people just kept
adopting it.

 really does not and cannot
fit in the primary frame where there was only few keys to export Org.

The arguments that come up are that user has to toggle variables
shortly before export, maintenance problems, etc. 

Ihor mentioned few possible modes like ediff, that is similar or
blocking to Org Export dispatch screen -- but in reality is not. I
have inspected ediff menu buffer and found I can inspect any key, I
can move to other windows, my Emacs with ediff was not blocked. It was
not relevant comparison.

> I stumbled on exactly the same problem some months ago, and it drove
> me nuts:
> 
> https://lists.gnu.org/archive/html/emacs-orgmode/2021-12/msg00674.html Edrx 1
> https://lists.gnu.org/archive/html/emacs-orgmode/2022-02/msg00098.html Ihor 2
> https://lists.gnu.org/archive/html/emacs-orgmode/2022-02/msg00106.html Edrx 3
> https://lists.gnu.org/archive/html/emacs-orgmode/2022-02/msg00111.html Ihor 4
> http://angg.twu.net/e/org.e.html#org-export-dispatch

Yes, and when there is one of users speaking about it, there are maybe
hundreds of others who stumble upon it and probably never come back. 

> My conclusion was that Org is much harder to learn than I thought.
> It's easy to learn if:
> 
>   1) you're a "user", or
>   2) you know a lot about debugging Emacs, or
>   3) the developers like your questions.

I know that Eli does not use Org. And many people using Org are not
developers, apparently they master Org useful functions. 

We could say there are very simply Org functions and more complex.

Simplicity lies in this example:

* My heading

My text

** DONE My subheading
   CLOSED: [2022-12-31 Sat 08:44]

** TODO My subheading

- [ ] My task
- [ ] My task

When just few Org elements are used it is simple. Org documentation
talks about all the other more complex functions. 

Back to export, why use a buffer for export that does not even look
like Org bufer? 

When we list the now available number of Org export backends, it is
already huge list. It simply is not any more compatible to the idea
before 10 years when somebody used 2-3 keys to export Org.

And the code complexity is unbelievable to me. It is tangled in the
manner how I am personally not used to when using Lisp or Scheme. My I
like shorter functions, each doing something, but Org functions like
`org-export--dispatch-ui' is 176 lines.

That function tries to add functionality to Org that already exists
when user defines derived modes with key bindings.

You can inspect the package I made for that:

GNU Emacs package: rcd-org-export.el -- use Org to export Org:
https://gnu.support/gnu-emacs/packages/GNU-Emacs-package-rcd-org-export-el-use-Org-to-export-Org-76272.html

But then later I made RCD Dashboard that generalizes the concepts from
that package:

GNU Emacs package: rcd-dashboard.el -- Tool to build Emacs dashboards:
https://gnu.support/gnu-emacs/packages/GNU-Emacs-package-rcd-dashboard-el-Tool-to-build-Emacs-dashboards-76668.html

Then I started making similarly RCD Org Agenda interface:

GNU Emacs package: rcd-org-agenda-dashboard.el -- RCD Org Agenda Dashboard:
https://gnu.support/gnu-emacs/packages/GNU-Emacs-package-rcd-org-agenda-dashboard-el-RCD-Org-Agenda-Dashboard-76669.html

I can add options to it later.

> My holidays have just started, and I'm planning to work on (2).

There could be eev buffer to export Org, and such buffer need not be
blocking.

Solving toggling of variables is easy:

- it should be derived mode, it could also be Org mode

Instead of following:

** Export 

Re: How to disable completely org-persist

[Ihor Radchenko]

Angelo Graziosi  writes:

>> Indeed, although I'm not yet convinced that org-persist directories wont
>> eventually start showing up in /tmp!
>
> I fear that sooner or later it will reappear somewhere.. 
>
> When it showed up few week ago, I found that setting and added it to the init 
> file but that time it didn't solved the issue. That folder showed up even 
> with that setting.. Instead now it seems to fix the issue hmm.. I wouldn't 
> want it to be a Pyrrhic victory!

I may indeed reappear somewhere.
As I stated in my last message and the commits, we now have the
following:

1. For emacs -Q, the folder, if created, is removed upon closing Emacs
   It may still stay if you do something like kill -9 (I can't do much
   about this scenario).
   Note that this situation is rather unlikely scenario. You need to do
   something manually with emacs -Q.
2. For normal emacs usage, the folder is created only when it is needed
   If you set org-element-cache-persistent to nil, Org may still use
   org-persist for other purposes, like LaTeX previews or caching remote
   images during export.
3. As I suggested in my other message, if you don't like (2), set
   `org-persist-directory' to the location that does not bother you.

   Alternatively, you can use
   https://github.com/emacscollective/no-littering that will organize
   .emacs.d closer to XDG schema.

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

Re: [BUG] warning message for straight-use-package [9.6 (9.6-gb2adb6 @ /Users/stephen/.emacs.d/straight/build/org/)]

[Richard Kim]

Stephen Eglen  writes:

> Checking the source, I see line 77 of org-macs.el has
>
>  (straight-use-package 'org)
>
> so I'm not sure what the fix is, but does anyone have any ideas on
> providing a warning that uses the correct quote character?

The correct character is the usual 7-bit single quote, i.e., the line
you have here correct.

My straight.el setup is done in early-init.el rather than in .emacs. I
also have (straight-use-package 'org) in early-init.el to make sure that
org version I want (which is the one installed by straight.el) is used.
I've had this setup for years, and I have never run into another org
mode getting installed by package.el to cause problems.

search in org-sparse-tree for multiple files

[Eric Chun]

Hi,
I can't seem to use the M-g M-n keys to jump to occurrences in sparse tree 
search for second org file within same Emacs window.
If I search first file by pressing C-c / r  RET and then search second 
file by pressing C-c / r  RET, I'm not able to jump to occurrences in 
that second file by pressing M-g M-n.  I get a message saying "No more matches" 
even though there are matches.  If I close the first file buffer, then I am 
able to use M-g M-n to jump to occurrences in the second file.
Does anybody know what I may be missing?
I'm using org mode version 9.6 in Emacs 28.2 on CentOS7.

Re: LaTeX tutorial (focused on what Org exports) ??

[Thomas S. Dye]

David Masterson  writes:


Anyone have a recommendation for a LaTeX tutorial that would
(especially) help me understand the LaTeX exported by Org and 
how to
enhance what is exported (new document classes, etc.).  I don't 
want to
bore you all with a lot of questions, so I'm looking for a good 
book.


Org's latex exporter is exceptionally capable.  AFAICT, it doesn't 
have practical limits on the LaTeX it produces, at least for my 
academic use case.  I'm able to use all of the LaTeX packages I've 
ever wanted to use.


With the world of LaTeX at your feet, I recommend The LaTeX 
Companion by Mittelbach and Goosens.  My well-worn copy is almost 
20 years old, and I use it as often now as when I did all of my 
writing in LaTeX.  Of course, there are many new LaTeX packages in 
the last 20 years, but LaTeX was very capable at the turn of the 
millennium and the few new packages I use were easy to discover by 
browsing.


hth,
Tom

--
Thomas S. Dye
https://tsdye.online/tsdye

Re: How to disable completely org-persist

[Angelo Graziosi]

> Il 30/12/2022 18:42 Colin Baxter ha scritto:
> 
>  
> > Angelo Graziosi writes:
> 
> > tomas wrote:
> >> there is now a defvar `org-element-cache-persistent'
> 
> > Ah! didn't knew that..
> 
> > Setting
> 
> > (setq org-element-cache-persistent nil)
> 
> > seems to work..
> 
> Indeed, although I'm not yet convinced that org-persist directories wont
> eventually start showing up in /tmp!

I fear that sooner or later it will reappear somewhere.. 

When it showed up few week ago, I found that setting and added it to the init 
file but that time it didn't solved the issue. That folder showed up even with 
that setting.. Instead now it seems to fix the issue hmm.. I wouldn't want it 
to be a Pyrrhic victory!

Re: Export Org with Org concept -- Re: Problems with C-c C-e file.org,

[Eduardo Ochs]

On Mon, 19 Dec 2022 at 18:13, Jean Louis  wrote:
>
> * Ihor Radchenko  [2022-12-18 17:57]:
> > andre duarte bueno  writes:
> >
> > > When I try to export file.org  using C-c C-e the window with the list of
> > > possibilities appears. But it appears incomplete(visualization), so I try
> > > to use the mouse to view the other export options and the system is
> > > completely blocked. Every mouse click is captured and displayed in the
> > > command window. And it doesn't allow you to do anything else. I am forced
> > > to cancel the command without completing it.
> > > Apparently C-c C-e is capturing all events and not just keyboard
> > > events!
>
> That is not first complaint, right? I would say it is obvious that
> such interface is not user friendly.
>
> > This is because we use `read-char-exclusive'.
>
> Don't use what is blocking Emacs. Apart from Org mode I have never
> seen a package that blocks Emacs that I cannot even inspect keys.

Hi Jean Louis,

did you solve your problem? Did you find a way to replace the blocking
code by something else?

I stumbled on exactly the same problem some months ago, and it drove
me nuts:

https://lists.gnu.org/archive/html/emacs-orgmode/2021-12/msg00674.html Edrx 1
https://lists.gnu.org/archive/html/emacs-orgmode/2022-02/msg00098.html Ihor 2
https://lists.gnu.org/archive/html/emacs-orgmode/2022-02/msg00106.html Edrx 3
https://lists.gnu.org/archive/html/emacs-orgmode/2022-02/msg00111.html Ihor 4
http://angg.twu.net/e/org.e.html#org-export-dispatch

My conclusion was that Org is much harder to learn than I thought.
It's easy to learn if:

  1) you're a "user", or
  2) you know a lot about debugging Emacs, or
  3) the developers like your questions.

My holidays have just started, and I'm planning to work on (2).

Btw, at some point I gave up trying to find the functions that the
dispatcher calls, and I just defined this "function with a very short
name" that [c]ompiles the current .org file to HTML:

  (defun c () (interactive) (eek "C-c C-e h h"))

Refs:

  (find-eev-quick-intro "3. Elisp hyperlinks" "eek")
  (find-eev-quick-intro "7.4. Commands with very short names")
  http://angg.twu.net/eev-intros/find-eev-quick-intro.html#3
  http://angg.twu.net/eev-intros/find-eev-quick-intro.html#7.4

Cheers,
  Eduardo Ochs
  http://angg.twu.net/eepitch.html
  http://angg.twu.net/2021-org-for-non-users.html

LaTeX tutorial (focused on what Org exports) ??

[David Masterson]

Anyone have a recommendation for a LaTeX tutorial that would
(especially) help me understand the LaTeX exported by Org and how to
enhance what is exported (new document classes, etc.).  I don't want to
bore you all with a lot of questions, so I'm looking for a good book.
-- 
David Masterson

Re: ob-shell intentions and paperwork (was Bash results broken?)

[Matt]

  On Fri, 30 Dec 2022 00:34:38 -0500  Matt  wrote --- 
 > 
 >   On Thu, 29 Dec 2022 06:08:59 -0500  Ihor Radchenko  wrote --- 

 >  > > From: Matt Trzcinski m...@excalamus.com>
 >  > > +(require 'org-test (expand-file-name "../org-test.el"))
 >  > 
 >  > I am unsure here. What will happen if you run this file from
 >  > default-directory not the same with file location?

I was mistaken.  Loading a new Emacs instance and running `(load 
"/path/to/test-ob-shell.el")' fails with file-missing error.  I'm content to 
leave that alone for now.

I've backed out the `require' change and adjusted everything else based on your 
feedback.  There is a separate patch for each refactor that created a new test. 
  The remaining refactors are in a single patch.  I was also able to resolve 
the issue I had with inserting the test name for the session (the "yes" string 
in `test-ob-shell/session').  The issue with `org-babel-shell-initialize' still 
stands but is outside the scope of these patches and isn't dealt with here.



0001-test-ob-shell.el-Split-test-ob-shell-dont-error-on-e.patch
Description: Binary data


0002-test-ob-shell.el-Refactor-test-ob-shell-session.patch
Description: Binary data


0003-test-ob-shell.el-Refactor-ob-shell-generic-uses-no-a.patch
Description: Binary data


0004-Refactor-ob-shell-bash-uses-assoc-arrays.patch
Description: Binary data


0005-test-ob-shell.el-Refactor-test-names-and-kill-test-b.patch
Description: Binary data


0006-ob-shell-test.org-Remove-ob-shell-test.org.patch
Description: Binary data


0007-test-ob-shell.el-Organize-tests.patch
Description: Binary data

Broken numerical ordered list when exported to latex

[Sharon Kimble]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


I have a long-standing problem with a numerical ordered list which is broken by 
sub-headings, and exported to latex.

On looking at the org manual, the most recent one that I have, on page 12, it 
shows something like '[@20]' which when exported shows exactly the same, and 
hasn't continued the numerical numbering.

So how can I have a continuing numerical ordered list please when exported to 
latex?  

Thanks
  Sharon.
- -- 
A taste of linux = http://www.sharons.org.uk
Debian 11.5, fluxbox 1.3.7, emacs 29.0.60, org 9.5.5 
-BEGIN PGP SIGNATURE-

iQJRBAEBCgA7FiEELSc/6QwVBIYugJDbNoGAGQr4g1sFAmOvJusdHGJvdWRpY2Nh
c0Bza2ltYmxlMDkucGx1cy5jb20ACgkQNoGAGQr4g1uezw//VGtV0aOt28kBaQvb
wD+FTdbNIrd4zem042gFsQqD906nIWLefcxwFiYke1NNKorvLD8sSnfb8ENsyb2x
q1OTHC9b5DePhatfeRz6l4v/dNdlasK8QjPm2pq+aXZQ5/t68E4WcVCbbxVETBph
bvC/jslsGFlWu25etndTFJWDAX2vxZoEsD1f5Ufm29Fg5aF6hl7lXvUhS+WPVJHY
qe3wjwkyryp8u0u+7maBwN/eg+IeSBYeVZgN6RoWDZckWkEECmyzVtnkCT3rzA8h
WJfSdjQHZoWdRhFdxbVze7pAfKyjhmi7DSfsOwhus2nW9LY57AKESQ9VD2D/DBQj
G1Lc+vL3Ahs55X9viVix2nwM+8IsOL46wCoxBJPAs5Gbd3VggeJ4TefkopKDUpaF
Zzg/lGtF4Ga9/rTC/XrOe3tLw6RnErTFNiDeqOt41GkuHfWBvd1K1ROrXg4Fvi/w
yOD03QdM8pCa5lp/5z9YJHTMMRmW5rYgqyloVjQ6Rai6Wg/wqUps65s95MIRi8AI
kEbwOg/lHyyR80PLUAI2ZVWM36i84+u1TwzOz5l2kuZezPW8l75TgOlVL0Itd82q
Oo61FMHlRGiDY0OzmJo49RZiYqAjr2/V0a/qSSCuOh/enWiA5NP3ICa6KoA0hul7
P98wewfIKgxX4BDTFZ444I4w+8g=
=gKSC
-END PGP SIGNATURE-

Re: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable

[Tom Gillespie]

Hi Bastien,
   In short, we need two variables due to the case where
a user wants to set nil for all vars and a function for code.
More replies in line. Best!
Tom

> I see nothing in etc/ORG-NEWS that describes this change: am I missing
> something?

Looks like any mention of the change is missing to me as well.

> >> Whether it changed or not, what is the problem in 9.6?
> >
> > The problem is that Org now displays more queries.
> >
> >> How does the patch solves this problem?
> >
> > It allows disabling these new queries about lisp evaluation outside
> > code blocks without disabling code block eval confirmation completely.

> Is there a real use-case for this?

Yes. To give one example. I have many files that need to run hundreds
of cells at tangling/export time. I have reviewed all the code in the cells
and know patterns that are safe and wont' burn me. I do not want to
allow execution of code blocks blindly during tangling and confirm eval
is a secondary line of defense against running those blocks during
export. I want to allow the cells to run uninhibited as they did before
this change, so that I don't have to fight with org during the tangling
process.

As it is right now the change has completely broken various CI
pipelines for me, and if these changes do not get in to emacs 29
in time I will be unable to use emacs 29 for CI until they are in the
base image without having to resort to insane hacks and massive
additional configuration changes to work around the issues discussed
in the loading multiple org versions thread.

> It looks like the patch fixes the "too many queries" problem by
> providing a setup that is similar to what was the previous default
> (i.e. only asking about code block evaluation when
> org-confirm-babel-evaluate-cell is set to nil.)

This interpretation is not quite right. org-confirm-babel-evaluate-cell has
no interaction with evaluating code blocks, only with evaluating cells.
When org-confirm-babel-evaluate-cell is nil or evaluates to nil then the
org-babel-confirm-evaluate code runs on a fake block that is created
out of the cell. (This is where there is still a bug that I mentioned up
thread.)

> But are we sure that users need to confirm header args evaluation
> separately from code blocks evaluation?

I am sure that in my workflow I want them split, especially for
global nil/t behavior. I need to think a bit more about your
suggestion to add more values to org-confirm-babel-evaluate
to see whether it might work and what the relative complexity
would be.

It seems to me that duplicating the variable is certainly easier
to maintain, if not to explain to those who do not use babel
regularly. I would be interested to hear from other babel users
their thoughts on the design, because it seems obvious to me,
but again I wrote the code so am the last person whose view
on the clarity of the should be considered. It seems that it
was not clear to Max initially.

> IOW I have difficulties understanding when these would be relevant:

> (setq org-confirm-babel-evaluate-cell nil)

Anywhere that a parenthesized elisp expression occurs
that is not in #+begin_src block.

> (setq org-confirm-babel-evaluate t)

Only inside #+begin_src blocks.

> I think that's the best route: providing, optionnally, more, while not
> annoying users who don't want more.

I think this is probably the right default as well.

> > Yes. Ideally, we need to improve the code evaluation query. It should
> > allow confirming evaluation in bulk and add some code blocks/files to
> > whitelist. Similar to `org--confirm-resource-safe'.
>
> I see, indeed.

Improving general code auditing prior to evaluation of blocks would
be greatly appreciated. The fighting between the minibuffer and
the primary buffer for priority and the fact that you often cannot
see that code that will be run is a significant issue. However, this is
orthogonal to the issue at hand.

> > A concern have been expressed that more queries may annoy users and
> > drive them towards setting `org-confirm-babel-evaluate' to nil globally.
> > Upon doing this, the future more flexible security queries may be not
> > used by such users.
>
> The future more flexible security queries will be made visibile enough
> so that users currently setting `org-confirm-babel-evaluate' to nil
> will *want* to have a look at it.

Yep. We need to get the fundamentals in place to enable those
workflows. I'm too paranoid to simply set that variable to nil, even
when I'm only running code that I wrote, but I suppose that is not
the case for everyone.

> I find "cell" confusing here (as Max said earlier in the thread).  It
> either refers to a table cell or, in Elisp jargon, a "cons cell" (or a
> "function cell").

I also dislike the name cell, but i'm not sure what to call it instead.
I mentioned "parenthized elisp expression" above, since strictly
speaking they aren't closures, they are any valid elisp sexpression.

In the context of org-outside-emacs I imagine a day when 

Re: How to disable completely org-persist

[Colin Baxter]

> Angelo Graziosi  writes:

> tomas wrote:
>> there is now a defvar `org-element-cache-persistent'

> Ah! didn't knew that..

> Setting

> (setq org-element-cache-persistent nil)

> seems to work..

Indeed, although I'm not yet convinced that org-persist directories wont
eventually start showing up in /tmp!

Best wishes,

[BUG] warning message for straight-use-package [9.6 (9.6-gb2adb6 @ /Users/stephen/.emacs.d/straight/build/org/)]

[Stephen Eglen]

Hi,

I use straight.el for package management, and a recent package (I think
it was todoist.el) pulled in org-mode.  This then caused the warning
about mismatch between the org-mode in Emacs and the one from the repo.

I read the *Warning* and in particular this bit:

--
3. New Org version is loaded using straight.el package manager and
   other package depending on Org is loaded before straight triggers
   loading of the newer Org version.

   It is recommended to put
(straight-use-package ’org)
   early in the config.  Ideally, right after the straight.el
--

so I copied the elisp straight into .emacs.  This then
generated an error, because the symbol 'org had been copied across as
’org.  

Checking the source, I see line 77 of org-macs.el has

 (straight-use-package 'org)

so I'm not sure what the fix is, but does anyone have any ideas on
providing a warning that uses the correct quote character?

Thanks, Stephen





Emacs  : GNU Emacs 29.0.50 (build 1, aarch64-apple-darwin21.6.0, NS 
appkit-2113.60 Version 12.5 (Build 21G72))
 of 2022-08-08
Package: Org mode version 9.6 (9.6-gb2adb6 @ 
/Users/stephen/.emacs.d/straight/build/org/)

Re: How to disable completely org-persist

[Ihor Radchenko]

to...@tuxteam.de writes:

>> The variable has been there since the beginning.
>
> But you made me aware of it, and thanks for it :)

https://orgmode.org/Changes.html ;)

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

Re: How to disable completely org-persist

[tomas]

On Fri, Dec 30, 2022 at 01:35:39PM +, Ihor Radchenko wrote:
>  writes:
> 
> > AFAIK there is now a defvar `org-element-cache-persistent'. Maybe it
> > works for you?
> 
> The variable has been there since the beginning.

But you made me aware of it, and thanks for it :)

> Now, org-persist is just more careful not to create the directory when
> nothing needs to be stored there.

Understood.

Cheers & may the new year...
-- 
t


signature.asc
Description: PGP signature

Re: How to disable completely org-persist

[Ihor Radchenko]

 writes:

> AFAIK there is now a defvar `org-element-cache-persistent'. Maybe it
> works for you?

The variable has been there since the beginning.
Now, org-persist is just more careful not to create the directory when
nothing needs to be stored there.

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

Re: How to disable completely org-persist

[Angelo Graziosi]

tomas wrote:

> there is now a defvar `org-element-cache-persistent'

Ah! didn't knew that..

Setting 

(setq org-element-cache-persistent nil)

seems to work..

Thanks,
 Angelo.

Re: How to disable completely org-persist

[tomas]

On Fri, Dec 30, 2022 at 01:11:12PM +0100, Angelo Graziosi wrote:
> > Il 05/12/2022 18:58 Colin Baxter ha scritto:
> > 
> >  
> > > Angelo Graziosi writes:
> > 
> > > Colin Baxter wrote:
> > >> I too would like a means to disable org-persist.
> > 
> > > On emacs-devel there was this suggestion:
> > 
> > > https://lists.gnu.org/archive/html/emacs-devel/2022-12/msg00125.html
> > 
> > It appears to work, after removing a couple of surplus brackets from the
> > end of the last line.
> 
> After the last Emacs master build, the what suggested there, i.e.
> 
> ;; As suggested here:
> ;; https://lists.gnu.org/archive/html/emacs-devel/2022-12/msg00125.html
> (setq org-persist-disable-when-emacs-Q t)
> 
> (defun tv/advice--org-persist (old-fn  args)
>   (let (user-init-file)
> (apply old-fn args)))
> 
> (advice-add 'org-persist-write :around #'tv/advice--org-persist)
> (advice-add 'org-persist-read :around #'tv/advice--org-persist)
> (advice-add 'org-persist-gc :around #'tv/advice--org-persist)
> 
> does not work any more: that directory is recreated even with that cod in the 
> init.el
> 
> Someone knows how to avoid that?

AFAIK there is now a defvar `org-element-cache-persistent'. Maybe it
works for you?

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: How to disable completely org-persist

[Angelo Graziosi]

> Il 05/12/2022 18:58 Colin Baxter ha scritto:
> 
>  
> > Angelo Graziosi writes:
> 
> > Colin Baxter wrote:
> >> I too would like a means to disable org-persist.
> 
> > On emacs-devel there was this suggestion:
> 
> > https://lists.gnu.org/archive/html/emacs-devel/2022-12/msg00125.html
> 
> It appears to work, after removing a couple of surplus brackets from the
> end of the last line.

After the last Emacs master build, the what suggested there, i.e.

;; As suggested here:
;; https://lists.gnu.org/archive/html/emacs-devel/2022-12/msg00125.html
(setq org-persist-disable-when-emacs-Q t)

(defun tv/advice--org-persist (old-fn  args)
  (let (user-init-file)
(apply old-fn args)))

(advice-add 'org-persist-write :around #'tv/advice--org-persist)
(advice-add 'org-persist-read :around #'tv/advice--org-persist)
(advice-add 'org-persist-gc :around #'tv/advice--org-persist)

does not work any more: that directory is recreated even with that cod in the 
init.el

Someone knows how to avoid that?

TIA,
 Angelo.

Re: [PATCH][WORG] replaces broken javascript with link

[Ihor Radchenko]

gerard.vermeu...@posteo.net writes:

> the attached patch replaces a snippet of broken javascript code with an 
> org-mode link.
>
> Best regards -- Gerard

Bastien, may you take a look?

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

Re: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable

[Max Nikulin]

On 30/12/2022 15:52, Bastien wrote:

But are we sure that users need to confirm header args evaluation
separately from code blocks evaluation?


I do not think we need to confirm header arguments *separately*, but 
they should not be executed before asking users. It is not easy to 
implement request for header arguments in another way.


Commit

10e857d42 2022-10-28 11:09:50 +0800 Ihor Radchenko: org-babel-read: Obey 
`org-confirm-babel-evaluate'


was a reaction to

Max Nikulin. [BUG][Security] begin_src :var evaluated before the prompt 
to confirm execution. Thu, 27 Oct 2022 10:18:05 +0700. 
https://list.orgmode.org/tjct9e$179u$1...@ciao.gmane.io


The latter partially was caused by demand to open arbitrary Org files 
downloaded from net in Emacs.


https://debbugs.gnu.org/cgi/bugreport.cgi?bug=58774
[WISH]: Let us make EWW browse WWW Org files correctly

Accidental unsolicited code execution due to unintentional C-c C-c may 
be rather dangerous, it does not depend if it is source block body, 
header arguments, or table formula (the latter may still be activated by 
just TAB). Org-9.5 behavior is not ideal but at least acceptable for 
most of trusted (e.g. private) Org files.

Re: [BUG] ob-R.el: extra empty data.frame columns generated from plain lists after recent change [9.6 (release_9.6-3-ga4d38e @ /usr/share/emacs/30.0.50/lisp/org/)]

[Bastien]

"Berry, Charles"  writes:

> The R `data.frame' type is a list with some added attributes. In
> that list each top level element is a *column* in the data.frame.

Thanks for the explanation.

> There might be some useful applications for converting org lists to R
> lists and vice versa. But it looks like a significant amount of effort
> to get it right.

Yes... up to Jeremie, depending on users' needs.

Best,

-- 
 Bastien

Re: [BUG] ob-R.el: extra empty data.frame columns generated from plain lists after recent change [9.6 (release_9.6-3-ga4d38e @ /usr/share/emacs/30.0.50/lisp/org/)]

[Bastien Guerry]

So, based on Charles recent feedback:

>> If there are more complaints about that in the future, I'll
>> reconsider.

... let's do as Jeremie originally said: wait until someone complains.

> Note that my NEWS entry may not be accurate for ob-R then:
>
> ** List references in source block variable assignments are now proper lists
>
> So, we may create confusion one way or another.
>
> Or I may need to put a special clause regarding ob-R into the NEWS
> item.

And add this special clause regarding ob-R into the NEWS item.  

Ihor, could you do that?

-- 
 Bastien

Re: Re: Problems with LaTeX export for $x\text{foo $x$}$-like construts?

[Pedro Andres Aranda Gutierrez]

> From: Ihor Radchenko 
> To: alain.coch...@unistra.fr
> Cc: emacs-orgmode@gnu.org
> Subject: Re: Problems with LaTeX export for $x\text{foo $x$}$-like
> construts?
> Message-ID: <87wn6av84v.fsf@localhost>
> Content-Type: text/plain
>
> alain.coch...@unistra.fr writes:
>
> > Version used: release_9.6-149-g554935
> >
> > With an org file containing only
> >
> >#+begin_export latex
> >$x \text{foo $y$}$
> >
> >\(x \text{foo \(y\)}\)
> >
> >$x \text{foo \(y\)}$
> >
> >\(x \text{foo $y$}\)
> >#+end_export
> >
> > the pdf generated upon latex export gives as expected, i.e., with 'x'
> > and 'y' in mathematical font.
>
> This is to be expected because of how Org parser works.

In my experience, this also applies for some situations while creating
listings.
My question is if there would be space for a `:raw t` in the
`#+begin_export latex` to produce a _verbatim_ copy of the contents of the
environment.

All the best, freedom and just(=justa, gerecht) peace in 2023,

/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: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable

[Bastien]

Thanks a lot for the detailed answer, very helpful.

> What changed: The prompt previously displayed on code block evaluation
> is now also displayed when expanding header arguments:

I see nothing in etc/ORG-NEWS that describes this change: am I missing
something?

>> Whether it changed or not, what is the problem in 9.6?
>
> The problem is that Org now displays more queries.
>
>> How does the patch solves this problem?
>
> It allows disabling these new queries about lisp evaluation outside
> code blocks without disabling code block eval confirmation completely.

Is there a real use-case for this?  

It looks like the patch fixes the "too many queries" problem by
providing a setup that is similar to what was the previous default
(i.e. only asking about code block evaluation when
org-confirm-babel-evaluate-cell is set to nil.)

But are we sure that users need to confirm header args evaluation
separately from code blocks evaluation?

IOW I have difficulties understanding when these would be relevant:

(setq org-confirm-babel-evaluate-cell nil)
(setq org-confirm-babel-evaluate t)

> I later suggested disabling the queries by default - mimicking the pre
> 9.6 behaviour yet keeping the ability for concerned users enable the
> extra confirmation.

I think that's the best route: providing, optionnally, more, while not
annoying users who don't want more.

> Yes. Ideally, we need to improve the code evaluation query. It should
> allow confirming evaluation in bulk and add some code blocks/files to
> whitelist. Similar to `org--confirm-resource-safe'.

I see, indeed.

> A concern have been expressed that more queries may annoy users and
> drive them towards setting `org-confirm-babel-evaluate' to nil globally.
> Upon doing this, the future more flexible security queries may be not
> used by such users.

The future more flexible security queries will be made visibile enough
so that users currently setting `org-confirm-babel-evaluate' to nil
will *want* to have a look at it.

>> Also, org-confirm-babel-evaluate-table-cell seems more explicit than
>> org-confirm-babel-evaluate-cell.
>
> But it will not be accurate. The query is now displayed upon executing
> `org-babel-read' -- cell refers to Elisp code "cell" here. Not to a
> table cell.

I find "cell" confusing here (as Max said earlier in the thread).  It
either refers to a table cell or, in Elisp jargon, a "cons cell" (or a
"function cell").

What about modifying `org-confirm-babel-evaluate' to allow these values:

- t  : confirm header vars *and* code blocks
- 'code  : confirm code blocks
- 'vars  : confirm vars
- nil: don't confirm

and set the default value to 'code, while allowing concerned users to
set it to `t' -- until we have a better system for evaluation query.

WDYT?

-- 
 Bastien

Re: ob-shell intentions and paperwork (was Bash results broken?)

[Bastien Guerry]

Hi Matthew,

Matt  writes:

>  You're correct, I've not contributed to core.  I would love to
> maintain lisp/ob-shell.el.

Your wish has been granted:
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=e8ceb4a2

> I'm expecting life changes in the coming
> months and can't anticipate how that will affect my time.  Would it be
> a problem if I need to step down as maintainer for a period?

It is no problem at all.

You don't even need to step down as maintainer: if requests against
ob-shell.el are not *that* pressing during the time you're not fully
available, users and maintainers can just be patient.

I've warned Emacs maintainers and they'll give you write access to
the Org repository.

Thanks!

-- 
 Bastien