Re: Is the cascading logic of outlines a feature, or a design bug?

[tomas]

On Mon, Dec 26, 2022 at 06:47:37AM +, a...@bitrot.link wrote:

> Likewise, is the inability to close an org-mode outline section without
> starting a new section really a feature? [...] Or is
> the restriction really just a bug with seniority, and the difficulty of
> fixing it (or the compatibility headaches caused by fixing it) would
> outweigh the benefits?

I guess the answer depends on your perspective. Try to reformulate
your question in another way, perhaps then it leads to something.

I must admit I've missed the possibility for Org to continue a
section after a deeper level one from time to time. I've resorted
to "local conventions" (e.g. a headline with "-" as a title).

But all in all, that's what Org's document model is, and you won't
change it because it's (sometimes) more convenient to you. What
you might try is to find enough people to agree in a common way
to work around it, if necessary.

Cheers
-- 
t


signature.asc
Description: PGP signature

Feature request: "task table" (similar to clock table)

[Marcin Borkowski]

Hi fellow Orgers,

I've been using clock tables for some time now, and they are very
useful.  However, it has just occurred to me that I'd really appreciate
another feature - a "task table".  By this, I mean a table (generated
much like a clock table) with a summary of all tasks in a given
file/subtree/etc.: how many of them there are, how many are in any
state, maybe how many have scheduled times and/or deadlines, how many
are past their deadline...

Now, question 1: is there any feature in Org mode to make C-c C-c do
something when the point is on a line e.g. matching certain regex?  This
way I could extend Org mode to do that myself.

I peeked around and found out `org-ctrl-c-ctrl-c-hook', so that's that.
Pretty nice!  Although some functions allowing stuff like "substitute
the results for the block that follows" etc. might be also nice.

Question 2: am I the only one who would like to see such a feature?
Would someone like to code it?  (I /might/ be tempted to do that, but
it's kinf difficult: while I signed FSF papers some time ago, I've
changed jibs since then and I suppose I'd need to got through some more
paperwork to fix that; also, I'm not sure whether I really want to, and
whether my employer would be willing to let me.)

TIA,

-- 
Marcin Borkowski
http://mbork.pl

Is the cascading logic of outlines a feature, or a design bug?

[abq]

https://orgmode.org/worg/org-faq.html#closing-outline-sections answers 
the question:

"Can I close an outline section without starting a new section?"

The answer given is:
"no. Org-mode adheres to the cascading logic of outlines, in which a 
section is closed only by another section that occupies an equal or 
greater level."


Is that limitation a feature, or a design bug? E.g. if someone proposes 
enhancing the Unix directory system to support multiple files with the 
same filename in one directory, the proposal would be rejected, with the 
explanation that the limitation of only one file per filename is a 
feature, not a bug, since it enables the name to uniquely identify the 
file. (If you want to claim it's a bug, please at least edit your 
subject line, or preferably start a new thread.)


Likewise, is the inability to close an org-mode outline section without 
starting a new section really a feature? If so, what benefit does the 
restriction provide, that would be lost by relaxing the restriction? Or 
is the restriction really just a bug with seniority, and the difficulty 
of fixing it (or the compatibility headaches caused by fixing it) would 
outweigh the benefits?


Andy

Re: Bash results broken?

[Matt]

  On Sun, 25 Dec 2022 06:23:53 -0500  Ihor Radchenko  wrote --- 
 > As you see, "%S" have been used previously for non-string results.
 > I cannot find explanation in git log.
 > 
 > That said, I think that it will be more consistent to leave strings
 > specifically as is. See the attached patch.

That makes sense and works for me.

Re: [BUG] Emacs tries to recenter / rescroll when it hits hidden org emphasis [9.4.6 (9.4.6-798-g738759.dirty-elpaplus @ .emacs.d/elpa/develop/org-plus-contrib-20210929/)]

[Chris Findeisen]

Thanks a lot Ihor for looking at this. I followed the discussion in the
linked mailing list. I write a lot in Emacs and this gets rid of a long
standing annoyance. :) Cheers!

On Thu, Oct 27, 2022 at 11:08 PM Ihor Radchenko  wrote:

> Ihor Radchenko  writes:
>
> > I have forwarded this bug report to Emacs bug tracker.
> > See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=58793
>
> The bug is now fixed on Emacs master.
> This issue will be resolved in the next Emacs 29 release.
> (It has nothing to do with Org)
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>

Re: missing from the manual

[Peter Mao]

Also, it moves you to an outer level if you are at an end.

For my own use, because I want the command to treat the first item in a
list the same way as the others (when moving forward), I tweaked
org-forward-element from
(let* ((elem (org-element-at-point))

to:
(let* ((elem (progn
(when (equal (car (org-element-at-point))
'plain-list)
  (forward-char))
(org-element-at-point)))

The "backward" version behaves exactly as I would like it to.

Peter

On Sun, Dec 25, 2022 at 12:19 AM Ihor Radchenko  wrote:

> Marcin Borkowski  writes:
>
> >> org-forward-element
> >> org-backward-element
> >>
> >> These two should be mentioned in the manual in section 2.3 "Motion"
> >
> > How are they different from `org-forward-heading-same-level` and
> > `org-backward-heading-same-level'?  (Not irony etc., I'm genuinely
> > curious.)
>
> They work on paragraphs, lists, blocks, etc.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>

[BUG] org-block face not working for "non-default" languages

[duskhorn]

I have set up my org-mode so that I use variable pitch fonts for most of the 
items and fixed pitch fonts for verbatim and src blocks.

This works as expected for languages babel knows by default, for example 
emacs-lisp, python and c++.

However, I get variable pitch fonts for when I use an unrecognized language, 
such as nim (in my case) or R. 

This seems to be an issue related to faces and not blocks as a whole, since I 
can still run both "internal" and "external" languages: the ob-nim package 
works upon running the block via C-c C-c

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

[Jean Louis]

* Ihor Radchenko  [2022-12-25 15:07]:
> Jean Louis  writes:
> 
> >> > 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. 
> 
> Yes and no. Some users do not like it. Some users prefer the existing
> one. Conclusion: even if we implement something better, it should be
> backwards compatible.

Remember, one cannot prefer something without having a choice! 

User preferring existing functions have basically more or less how
many choices? One. So that is why they "prefer" it. 

QUESTION: You said that improvement to Org should be backwards
compatible, but what exactly and specifically you mean in this case?

The solution I have offered to you is the concept. Not the package.

In that concept, by observing the code, you could see that it is
possible:

- to setup key bindings to emulate what org-export-dispatch does; it
  is up to you to set the key bindings to make it "backwards"
  compatible, and finally, (QUESTION) why should a new improvement to
  interface be backwards compatible?

  The underlying functions should be backwards compatible. 

- that it is possible to turn on/off necessary variables for export by
  single key or by mouse clicks or using cursor and ENTER; now if you
  wish to keep it "backwards compatible" use those IMHO complicated
  key bindings such as C-b C-s C-a, etc.

- interface does NOT block Emacs and buffer can remain for as long
  until it is invoked new time. User can freely keep the Org Export
  Dispatch buffer on screen and keep exporting various versions in the
  breeze. Any key may be inspected. User may switch to other buffers
  and come back what one cannot do with org-export-dispatch interface.

So what exactly has to be backwards compatiable?

Is there anything you think it can't be made backwards compatible?

> >> 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.
> 
> gnus, reftex, ediff.
> (I do not mean that we should not improve Org in this regard)

gnus -- does not have that function inside, but how I remember me of
using Gnus, it never blocked the Emacs user interface, anything I used
allowed me to switch to other buffers. Thus I cannot see the
similarity to blocking user-unfriendly org-export-dispatch interface.

reftex -- function is inside, but when invoked it does not block the
Emacs user interface. I cannot see similarity to the blocking Org
Export interface.

ediff -- function `read-char-exclusive' is not inside and I have
options which I can use without Emacs being blocked. I can switch from
frame to frame, I can inspect every key.

 Sorry, but none of your examples is equivalent to blocking Org
dispatch or Org agenda.

The concept offered to you from my side is equivalent to ediff concept
of using keys which is:

1. make a new derived mode (for any kind of mode)

2. define keys in that derived mode

3. remember which buffer is to be exported by using local variables

4. display options menu for Org Export export, to switch or toggle
   global variables in the buffer itself, which are necessary to
   modify exporting functions

5. use mouse, and ENTER, SPC, whatever keys you wish to choose options
   and make it freely backwards compatible

6. Help Emacs user not to get blocked while Emacs is waiting for
   keys. User shall be in control and be able to inspect keys and
   switch from buffer to buffer even during the exporting. 

To help Emacs user be able to get "out of Org Export" is important as
export deals with files, and files need be inspected. It is so much
faster to export Org file by using RCD Org Export than by common
interface.

Using `ediff' interface is the same concept, it is non-blocking,
user-liberating concept, which is taken for granted in Emacs, but
disabled in Org Export and Org Agenda, and where else.

> There is code prototype down in the thread.
> https://list.orgmode.org/orgmode/am9pr09mb49770f57f33859770649c7c896...@am9pr09mb4977.eurprd09.prod.outlook.com/

I have downloaded org-select.el and tried demo1, demo2, demo3, and
that is what we are talking about. It does the job well.

I would just not use text mode but for Org export I would use Org mode
as that is what users of Org are used to.

> > Here is the concept of using Org similar buffers to export Org
> > buffers:
> >
> > 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
> >
> > It is made for you, as concept, as I have already mentioned the
> > concept before months. 
> >
> > In general, this is Org mode, so why not use Org mode to export Org
> > mode?
> >
> > See the video demonstration:
> >
> > https://gnu.support/files/emacs/packages/rcd-org-export/2022-12-19-23:36:10.ogv

Re: CSV agenda export formats some day and month values as single digits

[Ihor Radchenko]

"David O'Toole"  writes:

> CSV export for the agenda is formatting January 1, 2023 as "2023-1-1" and
> not "2023-01-01".
> The raw output is here: https://pastebin.com/raw/EyN1JbhP

Could you please provide detailed steps how to obtain the erroneous CSV
output? See https://orgmode.org/manual/Feedback.html#Feedback

Note that pastebin is not available in all countries. If you can, please
send the code/text right in the email as an attachment. This is more
sustainable for future readers.

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

Re: Problems with org-toggle-comment in or around inlinetasks

[Ihor Radchenko]

alain.coch...@unistra.fr writes:

> Hello.
>
> I do
>
>emacs -Q -l ~/.emacs.git
> ...

Thanks for reporting!
Fixed on bugfix.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=f13881006
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=718e19683

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

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

[Ihor Radchenko]

Jean Louis  writes:

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

Yes and no. Some users do not like it. Some users prefer the existing
one. Conclusion: even if we implement something better, it should be
backwards compatible.

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

gnus, reftex, ediff.
(I do not mean that we should not improve Org in this regard)

>> Alternative menu designs have been discussed in
>> https://list.orgmode.org/orgmode/am9pr09mb497743d21fa1c908392413f496...@am9pr09mb4977.eurprd09.prod.outlook.com/
>
> I did not find anything on that link.

There is code prototype down in the thread.
https://list.orgmode.org/orgmode/am9pr09mb49770f57f33859770649c7c896...@am9pr09mb4977.eurprd09.prod.outlook.com/

> Here is the concept of using Org similar buffers to export Org
> buffers:
>
> 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
>
> It is made for you, as concept, as I have already mentioned the
> concept before months. 
>
> In general, this is Org mode, so why not use Org mode to export Org
> mode?
>
> See the video demonstration:
>
> https://gnu.support/files/emacs/packages/rcd-org-export/2022-12-19-23:36:10.ogv

Thanks for the effort, but I'm afraid that it is not something we want in
Org core from maintenance perspective. Would be welcome as a third-party
package though.

Why:

1. Your package is introducing a new formatting for menus and new
   interaction paradigm. This is not backwards-compatible.
   If we add the package like yours into Org core, it will mean
   maintaining yet another piece of menu code in Org. Org is already
   huge and maintaining a separate menu package _in addition_ to all the
   existing staff is not a good idea.

2. We are moving towards removing menu-specific code from Org in general
   in favour of the existing menu frameworks. In particular, we plan to
   change Org menus to use transient. See
   
https://orgmode.org/list/8c364693bf6856e60cdd3e8b63ab0c9284d16733.ca...@heagren.com

   Note that transient allows menu buffer navigation (C-s)

3. Ideally, we should also adopt the existing menu layouts using
   transient. If not possible, we should consolidate the menu code into
   a separate simple library. Something just enough to replicate the
   existing functionality. With minimal maintenance. The thread I linked
   is one of such efforts.

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

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

[Max Nikulin]

On 18/12/2022 22:40, Stefan Monnier wrote:

Could Someone™ investigate why that code
doesn't do its job.

The code in question is in `package--reload-previously-loaded` and
my understanding is that it should cause `org-macs` to be reloaded


I do not see obvious flaws in `package--reload-previously-loaded' code. 
My guess is that we get reports from users who have installed released 
versions of emacs.


Notice that my complain concerning failure `byte-recompile-directory', 
hidden from its caller, is still valid.


On 25/12/2022 16:48, Ihor Radchenko wrote:

Max Nikulin writes:


I have tried the following in Emacs-27. For Emacs >= 29 add -L to Org <=
9.5.


Stefan convinced me that I was too optimistic concerning Emacs-29.


- "emacs -l org" to simulate a regular user session with some opened files.
- Update to Org-9.6 from ELPA.
- Close emacs and start it again "emacs -l org"

Result:
byte-code: Invalid function: org-assert-version


I tried to follow these steps, but unfortunately I am unable to
reproduce. Everything works fine using Emacs 27 on my side. Strange.


I tried it once more in a minimal LXC container with Ubuntu-22.04 LTS 
jammy. This time I even removed the elpa-org-9.5.2 system package, so 
built-in version of org is really used. So, emacs-27


- emacs -l org
- M-x list-packages RET
- / n org RET
- move cursor to org, install it
- i x y
- compilation buffers pops up with warning and errors.

Due to "-l org" some libraries like org, org-macs, ob are loaded. Files 
that `require' already loaded libraries generate warnings


Compiling file /home/emcs/.emacs.d/elpa/org-9.6/ob-R.el at Sun Dec 18 
04:30:49 2022


In end of data:
ob-R.el:562:1:Warning: the function ‘org-assert-version’ is not known to be
defined.

because `org-assert-version' is defined in org-macs.el, but the old 
version without it is already loaded. Call to `org-assert-version' is 
just added to the .elc file.


E.g. org-keys.el produce the same warning. Another case is

Compiling file /home/emcs/.emacs.d/elpa/org-9.6/ob-matlab.el at Sun Dec 
18 04:30:50 2022
ob-matlab.el:43:1:Error: Symbol’s function definition is void: 
org-assert-version


This file contains "(require 'ob-octave)". Attempt of load new version 
of ob-octave fails because during execution of it contents causes an 
error due to the `org-assert-version' call.


In particular, compilation of org.el fails because the new version has 
new "(require 'org-fold)" and the latter also tries to call undefined 
`org-assert-version'.


So at this point we have partially compiled broken install. Some files 
are not compiled, others have call to `org-assert-version' instead of 
its expansion.


Let's try to start emacs again and load org. Since org.el is not 
compiled, "(org-assert-version)" inside it is unable to catch any 
problem due to mixed-version compilation. Now `org-release' returns new 
version. The failure happens during "(require 'org-keys)" that was 
compiled with the warning.


Debugger entered--Lisp error: (invalid-function org-assert-version)
  org-assert-version()
  byte-code("\300\301!\210\302 \210\300\303!\210\300\304!\207" [require 
org-macs org-assert-version cl-lib oc] 2)

  require(org-keys)

So we have an obscure load time error.  I would say that compile *error* 
messages are obscure as well because it is unclear that errors happen in 
`require'. E.g. when compiling org-matlab.el the reported line number is 
for "(require 'ob-maxima)" while compiling of ob.maxima.el finished with 
a warning, not an error and it is really confusing. "ob-octave:34:" in 
addition to "ob-matlab:43:" during compiling of ob-matlab.el would be 
more informative.

Re: [PATCH] oc-basic.el: Fix wrong type for the editors field when parsing JSON.

[Ihor Radchenko]

Hugo Cisneros  writes:

> I use org-cite with a JSON bibliography and noticed a bug when an entry only 
> has
> an "editors" field but no "authors" field. The function
> `org-cite-basic—get-author' correctly falls back to using the editors instead 
> of
> the authors, but `org-cite-basic--parse-json’ stringifies only the "authors"
> field and not the "editors." This creates an error when other functions assume
> they got a string from `org-cite-basic—get-author'. The patch fixes the issue 
> by
> applying the same transformation to both "authors" and "editors".

Thanks!
Applied onto bugfix.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=318807013
Use are now also listed as an Org contributor.
https://git.sr.ht/~bzg/worg/commit/c2bb6a52

> As explained in the ChangeLog entry, this points to a more general issue where
> `org-cite-basic--get-field' is expected to return nil or a string, but calls
> `org-cite-basic--get-entry' that may return an association list. I am not sure
> how to fix that since it means converting anything that
> `org-cite-basic--get-entry' may return into a string.

Non-string can only be for JSON bibliographies for fields that are not
supported. `org-cite-basic--get-field' can probably return nil in such
scenarios.

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

Re: org-persist files in /tmp

[tomas]

On Sun, Dec 25, 2022 at 09:30:00AM +, Ihor Radchenko wrote:
>  writes:
> 
> >> Another idea is to avoid caching of parse result for small files.
> >
> > I haven't been following along very closely, but seeing the
> > involved complexities, I'd appreciate a knob to disable caching
> > altogether.
> 
> org-element-cache-persistent

Thanks, Ihor. You made me a Christmas present *<:-)~

> > My usage of Org hasn't triggered any slowdowns which would be
> > worth all that complexity (and yes, my biggest Org file so-far
> > is 36k lines, and my box isn't the fastest around).
> 
> The main reason we cannot disable org-persist is _not_ Org AST cache.
> The reason is mostly caching some downloaded files.

I see. That latency weighs significantly more, yes.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Bash results broken?

[Ihor Radchenko]

Matt  writes:

> For :results list, the manual says, "Interpret the results as an Org list.  
> If the result is a single value, create a list of one element".  I don't find 
> that clarifies what would be best.
>
> Thoughts?

In my patch, I followed the previous code branch:

(list (if (stringp e) e (format "%S" e)))

As you see, "%S" have been used previously for non-string results.
I cannot find explanation in git log.

That said, I think that it will be more consistent to leave strings
specifically as is. See the attached patch.

>From 22ee116511a40cc9cbee02e66799fdeb3e81ba78 Mon Sep 17 00:00:00 2001
Message-Id: <22ee116511a40cc9cbee02e66799fdeb3e81ba78.1671967390.git.yanta...@posteo.net>
From: Ihor Radchenko 
Date: Sun, 25 Dec 2022 14:20:48 +0300
Subject: [PATCH] org-babel-insert-result: Output strings as is for lists of
 strings

* lisp/ob-core.el (org-babel-insert-result): Do not use %S format for
lists of strings in :results list output.  This is more consistent
with single string output.

Reported-by: Matt 
Link: https://orgmode.org/list/1852d9eb52f.c4c534f9581400.7140516675874523...@excalamus.com
---
 lisp/ob-core.el | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index c2a367375..300c9d92f 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -2461,13 +2461,18 @@ (defun org-babel-insert-result (result  result-params info hash lang ex
 		(insert
 		 (org-trim
 		  (org-list-to-org
+   ;; We arbitrarily choose to format non-strings
+   ;; as %S.
 		   (cons 'unordered
 			 (mapcar
 			  (lambda (e)
 (cond
  ((stringp e) (list e))
  ((listp e)
-  (mapcar (lambda (x) (format "%S" x)) e))
+  (mapcar
+   (lambda (x)
+ (if (stringp x) x (format "%S" x)))
+   e))
  (t (list (format "%S" e)
 			  (if (listp result) result
 (split-string result "\n" t
-- 
2.38.1



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

[Ihor Radchenko]

Tom Gillespie  writes:

> From 4a78e1b5ea98dee569ff690037c661ab5c300194 Mon Sep 17 00:00:00 2001
> From: Tom Gillespie 
> Date: Sat, 10 Dec 2022 12:11:17 -0800
> Subject: [PATCH 1/2] ob-core: add org-confirm-babel-evaluate-cell custom
>  variable

Bastien, may you please take a look at this discussion?

As pointed by this patch, the current behaviour of asking users about
code evaluation every single time will increase the odds to set
`org-confirm-babel-evaluate' to t and never come back.

We may not want to do it.

Instead, we may apply this patch, but using an opposite default value of
this new variable - do not confirm.
The end result after applying will then be the same as in the previous
release.

Or we may apply this patch + extend the confirmation dialogue to accept
"All" answer to confirm execution for the duration of `this-command'.

WDYT?

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

[Ihor Radchenko]

Tom Gillespie  writes:

> One more correction. The source of the issue is that the two values in the
> list need to be different, one for the message and one for the actual test.
> Best,
> Tom
>
> (list "emacs-lisp" cell
>   '((:eval . yes)) nil (format "%S" cell)
>   nil nil)

Makes sense. "%s" for printed string is even better.
Fixed on bugfix.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=7f2f73c41

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

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

[Ihor Radchenko]

Max Nikulin  writes:

> I have tried the following in Emacs-27. For Emacs >= 29 add -L to Org <= 
> 9.5.
>
> - "emacs -l org" to simulate a regular user session with some opened files.
> - Update to Org-9.6 from ELPA.
> - Close emacs and start it again "emacs -l org"
>
> Result:
> byte-code: Invalid function: org-assert-version

I tried to follow these steps, but unfortunately I am unable to
reproduce. Everything works fine using Emacs 27 on my side. Strange.

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

Re: org-persist files in /tmp

[Ihor Radchenko]

Max Nikulin  writes:

> If you demonstrate that e.g., when working with encrypted files, their 
> sensitive content leaks to the cache then it will raise the severity of 
> the issue.

Nothing related to encrypted files is ever written by org-persist.
Some edge cases might exist for org-crypt, but that will involve manual
calls to writing cache.

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

Re: org-persist files in /tmp

[Ihor Radchenko]

 writes:

>> Another idea is to avoid caching of parse result for small files.
>
> I haven't been following along very closely, but seeing the
> involved complexities, I'd appreciate a knob to disable caching
> altogether.

org-element-cache-persistent

> My usage of Org hasn't triggered any slowdowns which would be
> worth all that complexity (and yes, my biggest Org file so-far
> is 36k lines, and my box isn't the fastest around).

The main reason we cannot disable org-persist is _not_ Org AST cache.
The reason is mostly caching some downloaded files.

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

Re: org-persist files in /tmp

[Ihor Radchenko]

Max Nikulin  writes:

> Ihor, I do not like that after your latest changes temporary directory 
> became world readable.

This is the only sane way for emacs -Q, AFAIK. And the cache will now
only exist while Emacs is running (for -Q cmd arg). Removed
unconditionally upon exiting.

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

Re: org-persist files in /tmp

[Ihor Radchenko]

Greg Minshall  writes:

>> Do we need to care about cleaning up /tmp?
>
> my two cents is that maybe one should not care so much about cleaning up
> /tmp, but i think it's worthwhile trying not to clutter it up too much.

I improved things a tiny bit more.
Now, whatever is created by emacs -Q will be removed as long as
`kill-emacs-hook' is executed. It is the most aggressive cleaning I can
imagine.

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

Re: missing from the manual

[Ihor Radchenko]

Marcin Borkowski  writes:

>> org-forward-element
>> org-backward-element
>>
>> These two should be mentioned in the manual in section 2.3 "Motion"
>
> How are they different from `org-forward-heading-same-level` and
> `org-backward-heading-same-level'?  (Not irony etc., I'm genuinely
> curious.)

They work on paragraphs, lists, blocks, etc.

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

Re: missing from the manual

[Marcin Borkowski]

On 2022-12-24, at 03:43, Peter Mao  wrote:

> Dear maintainers,
>
> The following commands are missing from the manual!
>
> org-forward-element
> org-backward-element
>
> These two should be mentioned in the manual in section 2.3 "Motion"

How are they different from `org-forward-heading-same-level` and
`org-backward-heading-same-level'?  (Not irony etc., I'm genuinely
curious.)

Best,

-- 
Marcin Borkowski
http://mbork.pl