Re: [PATCH] Autoload `org-assert-version' and remove org-loaddefs.el

[Bastien]

Kyle Meyer  writes:

>> This patch autoloads `org-assert-version'.
>
> I don't understand the rationale behind this.  

It was my naive attempt at fixing the "invalid-function
org-assert-version" error several people reported.

> Every spot that calls
> org-assert-version is preceded by a line that requires org-macs, so
> isn't this error likely due to a mixed installation/load-path issue
> where the wrong/older org-macs is taking precedence?

Yes: I thought `org-assert-version' job was to help catching mixed
installations, so my reasoning was that, even when an old org-macs
version has been loaded, autoloading `org-assert-version' would help
report about mixed installation.

Also you're right about org-loaddefs.el, we should keep it.

That said, do you have any idea how to fix the bug people encounter
when installing Org from ELPA and being bitten by "invalid-function
org-assert-version"?

-- 
 Bastien

Re: [BUG] dead loop on (org-table-clean-line "|a|b|") [9.6 (release_9.6-3-ga4d38e @ share/emacs/29.0.60/lisp/org/)]

[Lin Sun]

Hi Ihor,

> I cannot reproduce.
> Can you please provide detailed steps starting from emacs -Q?

The bug caused by the function org-table-clean-line​ calls the 
org-string-width​ inside a string-match​ clause without protection, for the 
org-string-width​ maybe change the match data then cause the string-match run 
into wrong result.

The attachment is a quick patch for the issue, please help to review and apply 
it, thanks


From 428f989c6e9f846cf6a1bbb25ada56146789a2c6 Mon Sep 17 00:00:00 2001
From: Lin Sun 
Date: Fri, 2 Dec 2022 07:31:05 +
Subject: [PATCH] org-table.el: fix match-data changed in org-table-clean-line

---
 lisp/org-table.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/org-table.el b/lisp/org-table.el
index b160dc97c..6e6835fba 100644
--- a/lisp/org-table.el
+++ b/lisp/org-table.el
@@ -1699,7 +1699,7 @@ In particular, this does handle wide and invisible characters."
   (setq s (mapconcat (lambda (x) (if (member x '(?| ?+)) "|" " ")) s ""))
 (while (string-match "|\\([ \t]*?[^ \t\r\n|][^\r\n|]*\\)|" s)
   (setq s (replace-match
-	   (concat "|" (make-string (org-string-width (match-string 1 s))
+	   (concat "|" (make-string (save-match-data (org-string-width (match-string 1 s)))
 	?\ ) "|")
 	   t t s)))
 s))
-- 
2.20.5

Re: [BUG] dead loop on (org-table-clean-line "|a|b|") [9.6 (release_9.6-3-ga4d38e @ share/emacs/29.0.60/lisp/org/)]

[Lin Sun]

Hi Ihor,

> I cannot reproduce.
> Can you please provide detailed steps starting from emacs -Q?

It's not happened with emacs -Q, but happened with Spacemace configuration.

[BUG] Shift-up/down move the cursor to end of timestamp

[Daniel Clemente]

Hi.

Using a file with just one header:

* something
  :CLOCK:
  CLOCK: [2022-12-01 Thu 17:15]--[2022-12-01 Thu 17:30] =>  0:15
  :END:

If I put the cursor on the end timestamp (on the 3 of 17:30) and press
shift+up or shift-down, the timestamp is correctly adjusted by 5 minutes,
but the cursor jumps some characters to the right and stays at the right of
]
It should stay on the same character (the 3), so that I can keep adjusting
the minutes with shift-up/down

Tested on: GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit,
cairo version 1.16.0, Xaw scroll bars) of 2022-11-18
No other settings needed in your .emacs

I bisected the tree until I found in which commit this started. Copying
from git bisect:

5bc6741a5abd42e8305bb0fcfe78801813309640 is the first bad commit
commit 5bc6741a5abd42e8305bb0fcfe78801813309640
Author: Ihor Radchenko 
Date:   Tue Nov 1 15:52:25 2022 +0800

org-clock-update-time-maybe: Update the containing timestamps as well

* lisp/org-clock.el (org-clock-update-time-maybe): Update the
containing timestamps inside the clock, not only the clock sum.

Reported-by: Bruce E. Robertson 
Link: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=53393

 lisp/org-clock.el | 35 ---
 1 file changed, 24 insertions(+), 11 deletions(-)

Re: [BUG] ob-R: session evaluation returns empty ouputs with Org 9.6 [9.6 ( @ /home/fsantos/.emacs.d/elpa/org-9.6/)]

[Ihor Radchenko]

Greg Minshall  writes:

> Ihor will know, but i *think* that without :session, there is no R
> "shell" running, so the ...-prompt-regexp isn't used.  rather (do i know
> this?  assume this?), an R script is prepared and executed.

You are right.

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

Re: Release 9.6

[Ihor Radchenko]

Tim Cross  writes:

> One question I do have is with respect to the new folding code, the
> changes in Emacs to improve overlay performance and the correct way
> forward.
>
> On one hand, it was an immense amount of work for Ihor to implement a
> better performing solution and something I'm sure those with large org
> files will appreciate. However, on the other hand, I guess it also puts
> a greater burden from a maintenance perspective on org maintainers as
> org is now using its own unique approach to hiding/showing content
> (folding).

Note that org-fold text property implementation will remain relevant
until we drop the support of Emacs 28.

> Has anyone done any comparisons between the new overlay implementation
> in Emacs 29 and the new folding approach in org 9.6? Is there still
> sufficient performance benefit with org's approach over using Emacs
> overlays or do we need to seriously consider changing the default back
> to native Emacs overlays?

I did.
https://orgmode.org/list/87359z8ssb@163.com

Emacs master:
 - main Org branch using text properties for folding: Elapsed time: 
2.185786s (0.639190s in 4 GCs)
 - main Org branch using overlays for folding: Elapsed time: 27.244284s 
(0.731581s in 5 GCs)

Emacs feature/noverlay:
 - main Org branch using text properties for folding: Elapsed time: 
1.586936s (0.476606s in 3 GCs)
 - main Org branch using overlays for folding: Elapsed time: 2.039803s 
(0.724576s in 5 GCs)

The improvement is very significant. GCs are mostly caused by Org
internals staff as you can see by comparing built-in and main Org
versions. Without GCs, overlays are on par with text properties.

overlays vs. text properties are now mostly on par modulo some more GCs
when using overlays.

In terms of maintenance, it is not that bad. org-fold supports both
overlays and text properties. I just did not implement certain features
when overlays are used.

Eventually, we can drop text property support and go back to overlays.
We do not have to abandon org-fold for that. org-fold is mostly an API
for folding. It provides more than just a replacement of overlays. Other
places in Org code now use API calls instead of directly working with
overlays.

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

Re: [PATCH] Autoload `org-assert-version' and remove org-loaddefs.el

[Kyle Meyer]

Bastien writes:

> Some users reported an (invalid-function org-assert-version) error
> when installing Org from ELPA:
>
> https://lists.sr.ht/~bzg/emacsfr/%3Cd091463e1615422eb00070727d6a094ec0ae3c73.camel%40adocentyn.io%3E
> https://www.reddit.com/r/emacs/comments/z7qulo/comment/iyd9vam/?context=3
>
> This patch autoloads `org-assert-version'.

I don't understand the rationale behind this.  Every spot that calls
org-assert-version is preceded by a line that requires org-macs, so
isn't this error likely due to a mixed installation/load-path issue
where the wrong/older org-macs is taking precedence?

> It also removes the ;; generated-autoload-file: "org-loaddefs.el"
> footer in all files and let Make create org-autoloads.el instead.

I'm worried with how this will play with the Org bundled with Emacs.
The autoloads that are now written to lisp/org/org-loaddefs.el will
instead pollute the top-level lisp/loaddefs.el.

When I tested this out in the Emacs repo, running `make` shows many
lines of

WARNING: No org-autoloads.el file could be found from where org.el
is loaded.

and

You need to run "make" or "make autoloads" from Org lisp directory

during the build.  And loading/using Org shows the same.

> Before the patch, installing from ELPA creates both org-loaddefs.el
> and org-autoloads.el, which is confusing.

Hmm, isn't this in line with the lisp/org-loaddefs.el and
lisp/loaddefs.el split that happens for the Emacs repo?

A similar split is used other packages in the Emacs repo as well:

$ find lisp | grep '\-loaddefs.el' | head
lisp/ps-print-loaddefs.elc
lisp/org/org-loaddefs.el
lisp/org/org-loaddefs.elc
lisp/net/tramp-loaddefs.el
lisp/net/tramp-loaddefs.elc
lisp/calc/calc-loaddefs.el
lisp/calc/calc-loaddefs.elc
lisp/textmodes/reftex-loaddefs.el
lisp/textmodes/reftex-loaddefs.elc
lisp/textmodes/texinfo-loaddefs.elc

$ find lisp | grep -c '\-loaddefs.el'
29
$ find lisp | grep -c '\-autoloads.el'
0

And with the port of Emacs's 2682ea1b3 (Org commit 19c3969e7,
2022-10-04), there's also one spot that uses ;;;###org-autoload, which
tells loaddefs-gen.el to direct the autoload to org-loaddefs.el.

> Unless anyone objects, I'll install this patch in the bugfix branch
> tomorrow and release 9.6.1.

I think as is the patch would cause issues, and more generally I'm not
convinced we should be moving away from having an org-loaddefs.el file.
I'm also concerned about this sort of tree-wide change in a patch
release that will be synced to the emacs-29 branch.

Thanks for posting this for discussion, and please let me know if I'm
mistaken about the interaction with the Emacs repo.

Re: Release 9.6

[Charles Millar]

On 12/1/22 18:10, Tim Cross wrote:


Max Nikulin  writes:


On 29/11/2022 13:58, Bastien wrote:

Last but not least: thanks to Ihor his
truly amazing work and for being the de facto maintainer.


I think, Ihor's role in this release is crucial. He spent a lot of time fixing 
bugs and
reviewing patches, not to mention the org-fold framework to overcome performance
limitation of overlays (the latter has been recently addressed in Emacs though).


I agree. The amount of time and effort Ihor has put into org mode is
both crucial and hugely appreciated.

One question I do have is with respect to the new folding code, the
changes in Emacs to improve overlay performance and the correct way
forward.

On one hand, it was an immense amount of work for Ihor to implement a
better performing solution and something I'm sure those with large org
files will appreciate. However, on the other hand, I guess it also puts
a greater burden from a maintenance perspective on org maintainers as
org is now using its own unique approach to hiding/showing content
(folding).

Has anyone done any comparisons between the new overlay implementation
in Emacs 29 and the new folding approach in org 9.6? Is there still
sufficient performance benefit with org's approach over using Emacs
overlays or do we need to seriously consider changing the default back
to native Emacs overlays?


Is this the cause for the behavior I described a few days ago in

Bug org-cycke fails after "replace-string"

Charlie Millar

P.S. Sorry for the typo

[PATCH] lisp/ox-latex.el: put labels inside example blocks

[hugo]

I exported an essay written in org mode to a LaTeX file (and then a pdf)
today. It had `example' blocks in several consequent sections, each with
a name (i.e. `#+name'). I have `org-latex-prefer-user-labels' set to t,
and used these names to refer to the examples later on.

I noticed that some of these labels were resolved wrong (i.e. printed as
the wrong number) in the resulting pdf. Examining the tex source, this
was because the labels had been printed outside (just before) the
example blocks, thus:

,---
|  \label{ex:foo}
|  \begin{example}
| My example here
|  \end{example}
`---


In tnhese cases, sometimes LaTeX interpreted the surrounding section as
the subject of the label, and printed the number of that section when
the label was referred to.

The attached patch forces example environments to be printed thus:

,---
|  \begin{example}\label{ex:foo}
| My example here
|  \end{example}
`---

This solves the problem.

The logic/conditions for when to print a label, and how it is generated
remain unchanged.

Hope this is helpful for someone else too!

HugoFrom ce920752084eaa776a885d403c18ddd981e92203 Mon Sep 17 00:00:00 2001
From: Hugo Heagren 
Date: Thu, 1 Dec 2022 23:24:10 +
Subject: [PATCH] lisp/ox-latex.el: put labels inside example blocks

* lisp/ox-latex.el (org-latex-example-block): Instead of
`org-latex--wrap-label', manually add label after
\begin{}.

This produces proper label resolution in LaTeX. Labels before the
environment begins can be interpreted as referring to the surrounding
section.
---
 lisp/ox-latex.el | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 3d18ee7ff..10e4292d2 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -2127,13 +2127,13 @@ information."
 (let ((environment (or (org-export-read-attribute
 			:attr_latex example-block :environment)
 			   "verbatim")))
-  (org-latex--wrap-label
-   example-block
-   (format "\\begin{%s}\n%s\\end{%s}"
-	   environment
-	   (org-export-format-code-default example-block info)
-	   environment)
-   info
+  (format "\\begin{%s}%s\n%s\\end{%s}"
+	  environment
+  (if (org-element-property :name example-block)
+  (org-latex--label example-block info nil 'full)
+"")
+	  (org-export-format-code-default example-block info)
+	  environment
 
 
  Export Block
-- 
2.20.1

Re: Release 9.6

[Tim Cross]

Max Nikulin  writes:

> On 29/11/2022 13:58, Bastien wrote:
>> Last but not least: thanks to Ihor his
>> truly amazing work and for being the de facto maintainer.
>
> I think, Ihor's role in this release is crucial. He spent a lot of time 
> fixing bugs and
> reviewing patches, not to mention the org-fold framework to overcome 
> performance
> limitation of overlays (the latter has been recently addressed in Emacs 
> though).

I agree. The amount of time and effort Ihor has put into org mode is
both crucial and hugely appreciated.

One question I do have is with respect to the new folding code, the
changes in Emacs to improve overlay performance and the correct way
forward.

On one hand, it was an immense amount of work for Ihor to implement a
better performing solution and something I'm sure those with large org
files will appreciate. However, on the other hand, I guess it also puts
a greater burden from a maintenance perspective on org maintainers as
org is now using its own unique approach to hiding/showing content
(folding).

Has anyone done any comparisons between the new overlay implementation
in Emacs 29 and the new folding approach in org 9.6? Is there still
sufficient performance benefit with org's approach over using Emacs
overlays or do we need to seriously consider changing the default back
to native Emacs overlays?

Re: [BUG] ob-R: session evaluation returns empty ouputs with Org 9.6 [9.6 ( @ /home/fsantos/.emacs.d/elpa/org-9.6/)]

[Berry, Charles]

> On Nov 30, 2022, at 5:48 PM, Ihor Radchenko  wrote:
> 
> William Denton  writes:
> 
>> I tried that, but it didn't fix it. :(
> 
> Ok. I was able to reproduce on my side.
> 
>> With a minimal setup, running the R block with a :session makes it ask where 
>> the 
>> working directory should be (the default in the prompt is the directory the 
>> test 
>> Org file is in).  Setting ess-startup-directory to 'default-directory 
>> doesn't 
>> change that, or the output problem.
> 
> It looks like there is something wrong with comint-prompt-regexp in R
> buffers. It somehow does not match the prompt.
> 
> I will need to look further.
> 

The older (commit bed47b437d8cde7a98bafdb07996e248b40f70e6e) version of 
org-babel-comint-with-output used comint-prompt-regexp and works fine.

I don't really follow how `org-babel-comint-prompt-separator` gets set to 
something useful in the current version. 

Reverting org-babel-comint-with-output to that older commit (and eval-ing the 
defun for org-babel-R-evaluate-session) seems to fix this case for those who 
need `:results output` in R src blocks till this gets sorted out.

HTH,

Chuck

Re: [BUG] ob-R: session evaluation returns empty ouputs with Org 9.6 [9.6 ( @ /home/fsantos/.emacs.d/elpa/org-9.6/)]

[Greg Minshall]

Frederic,

> > It looks like there is something wrong with comint-prompt-regexp in
> > R buffers. It somehow does not match the prompt.
> 
> I'm not sure it's the explanation either, since external (i.e.,
> non-session) evaluation works as expected. (Just remove the ":session
> *R*" part of the header, and you'll see everything is okay.)

Ihor will know, but i *think* that without :session, there is no R
"shell" running, so the ...-prompt-regexp isn't used.  rather (do i know
this?  assume this?), an R script is prepared and executed.

cheers, Greg

Re: S-RET not incrementing table cell with emacs -nw

[tomas]

On Thu, Dec 01, 2022 at 04:50:48PM +0100, Loris Bennett wrote:
> Hi,
> 
> If I run emacs or emacsclient with the option -nw or -t, the chord S-RET
> in a table cell does not create a new cell below with the incremented
> value.  It just creates a new empty cell.  When running Emacs with a
> GUI, the incrementation works.
> 
> Is this a known problem?  If so, is there a solution?

Most terminals don't even know what a S-RET is (i.e. they don't have
a code sequence to pass it to the application). Actually, most terms
just pass 0x0a, i.e. "linefeed".

So Emacs has no chance to "see" that you meant S-RET.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Looking for new maintainer for ob-sql-mode

[Bastien]

Hi Nik

> I wrote https://github.com/nikclayton/ob-sql-mode as a thing that
> scratched my own itch a few years ago. Since then my need for it has
> disappeared, but kind people occasionally report issues or send PRs.
>
> I'm not really in a position to review them, so I'm looking for
> someone who would be interested in taking over maintainership.

Thanks for sharing this on the list - I added you call for help on
https://orgmode.org/worg/org-orphanage.html

All best,

-- 
 Bastien

S-RET not incrementing table cell with emacs -nw

[Loris Bennett]

Hi,

If I run emacs or emacsclient with the option -nw or -t, the chord S-RET
in a table cell does not create a new cell below with the incremented
value.  It just creates a new empty cell.  When running Emacs with a
GUI, the incrementation works.

Is this a known problem?  If so, is there a solution?

Cheers,

Loris

-- 
This signature is currently under constuction.

Looking for new maintainer for ob-sql-mode

[Nik Clayton]

Hi,

I wrote https://github.com/nikclayton/ob-sql-mode as a thing that scratched
my own itch a few years ago. Since then my need for it has disappeared, but
kind people occasionally report issues or send PRs.

I'm not really in a position to review them, so I'm looking for someone who
would be interested in taking over maintainership.

N
ᐧ

Re: 9.6 version has 9.4 Info manual?

[Alain . Cochard]

Colin Baxter writes on Thu  1 Dec 2022 11:19:

 > You might have an INFOPATH conflict.

Indeed. Thanks.

-- 
EOST (École et Observatoire des Sciences de la Terre) 
ITE (Institut Terre & Environnement) | alain.coch...@unistra.fr
5 rue René Descartes   [bureau 110]  | Phone: +33 (0)3 68 85 50 44 
F-67084 Strasbourg Cedex, France | [ slot available for rent ]

Re: 9.6 version has 9.4 Info manual?

[Colin Baxter]

Dear Alain,

> Alain Cochard  writes:

> With the 9.5.5 version

> Org mode version 9.5.5 (9.5.5-g8ef620 @
> /home/cochard/.emacs.d/elpa/org-9.5.5/)

> What I have in Info is

> The Org Manual **

> This manual is for Org version 9.5.

>Copyright ©️ 2004–2022 Free Software Foundation, Inc.

> But if

> Org mode version 9.6 (release_9.6-6-gd500b4 @
> /home/cochard/Org/Coch-git/org-mode/lisp/)

> then

> The Org Manual **

> This manual is for Org version 9.4.

>Copyright ©️ 2004–2021 Free Software Foundation, Inc.

You might have an INFOPATH conflict. For Org mode version 9.6
(release_9.6-6-gd500b4 @/path/to/git/org-mode/lisp/), I get the info
manual to begin as:

The Org Manual
**

This manual is for Org version 9.6.

   Copyright © 2004–2022 Free Software Foundation, Inc.


Best wishes,

9.6 version has 9.4 Info manual?

[Alain . Cochard]

With the 9.5.5 version

Org mode version 9.5.5 (9.5.5-g8ef620 @
/home/cochard/.emacs.d/elpa/org-9.5.5/)

What I have in Info is

The Org Manual
**

This manual is for Org version 9.5.

   Copyright © 2004–2022 Free Software Foundation, Inc.

But if

Org mode version 9.6 (release_9.6-6-gd500b4 @
/home/cochard/Org/Coch-git/org-mode/lisp/)

then

The Org Manual
**

This manual is for Org version 9.4.

   Copyright © 2004–2021 Free Software Foundation, Inc.




-- 
EOST (École et Observatoire des Sciences de la Terre) 
ITE (Institut Terre & Environnement) | alain.coch...@unistra.fr
5 rue René Descartes   [bureau 110]  | Phone: +33 (0)3 68 85 50 44 
F-67084 Strasbourg Cedex, France | [ slot available for rent ]