Re: Multiple versions of Org in load-path problem

[Ihor Radchenko]

David Masterson  writes:

> I went so far as to add the following to early-init.el:
>
> (if (featurep 'org) (load-feature 'org))
> (add-to-list 'load-path (expand-file-name "~/.emacs.d/elpa/org-9.6")
> (load-library "org")
>
> The load-library still fails with the org-assert-version error.

Indeed. It is to be expected. M-x package-install should not err here
though. In theory.

I suggest you to read `org-assert-version'. It aims to catch the
situation above and similar.

Note, however, that installation problem is different. Or rather it
should be different.

> Could it be that, when you package-install Org-9.6, it runs through a
> check where (I think) it compiles the package?  I get a lot of warnings
> and 34(?) failed files.  Could it be that some of the files are not
> built and, so, when I load-library, I'm picking up some of the wrong
> files from the built-in Org-9.3?  Do we need to remove all versions of
> Org that is not the current version from the load-path at the very
> beginning of org.el to ensure no fall-through?  Kind of a hack, but...

Maybe. It should not. That's why I raised
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59882
I'd like to see if Emacs devs have anything to say here.

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

Re: Multiple versions of Org in load-path problem

[David Masterson]

David Masterson  writes:

> David Masterson  writes:
>
>> Ihor Radchenko  writes:
>>
>>> David Masterson  writes:
>>>
 Is there a proper way to do this?  Do I really have to delete the
 built-in 9.3 version (by hand or package-delete?) or will that mess up
 something else?  I saw mention of 'unload-feature' which is new to me --
 would that be safe to use?
>>>
>>> In theory, Emacs should handle such updates even when built-in Org is
>>> loaded. See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59882
>>
>> I'm going to test if (in my case) the buit-in 9.3 is already loaded when
>> my .emacs runs,  I also have to see when 9.6 loads in my .emacs.
>>
>>> unload-feature is the last resort. We are still discussing the available
>>> options in https://orgmode.org/list/87k033h218.fsf@localhost.
>>
>> I have to play with the solution I suggested.  I'm beginning to wonder
>> if it will cause other problems with (seeming) Org dependent packages.
>> In my case, the error I get is from various use-package calls --
>> something like "Error: org-assert-version is not known".  This is
>> confusing because I've arranged my .emacs as (almost) an alphabetical
>> loading of the packages and some of the use-package errors are coming
>> from packages loaded before Org.  IOW, org-assert-version from 9.6
>> shouldn't be loaded yet and 9.3 doesn't have org-assert-version. So
>> what's referring to org-assert-version?
>
> I went so far as to add the following to early-init.el:
>
> (if (featurep 'org) (load-feature 'org))

typo -- unload-feature

> (add-to-list 'load-path (expand-file-name "~/.emacs.d/elpa/org-9.6")
> (load-library "org")
>
> The load-library still fails with the org-assert-version error.
>
> Could it be that, when you package-install Org-9.6, it runs through a
> check where (I think) it compiles the package?  I get a lot of warnings
> and 34(?) failed files.  Could it be that some of the files are not
> built and, so, when I load-library, I'm picking up some of the wrong
> files from the built-in Org-9.3?  Do we need to remove all versions of
> Org that is not the current version from the load-path at the very
> beginning of org.el to ensure no fall-through?  Kind of a hack, but...

-- 
David Masterson

Re: Multiple versions of Org in load-path problem

[David Masterson]

David Masterson  writes:

> Ihor Radchenko  writes:
>
>> David Masterson  writes:
>>
>>> Is there a proper way to do this?  Do I really have to delete the
>>> built-in 9.3 version (by hand or package-delete?) or will that mess up
>>> something else?  I saw mention of 'unload-feature' which is new to me --
>>> would that be safe to use?
>>
>> In theory, Emacs should handle such updates even when built-in Org is
>> loaded. See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59882
>
> I'm going to test if (in my case) the buit-in 9.3 is already loaded when
> my .emacs runs,  I also have to see when 9.6 loads in my .emacs.
>
>> unload-feature is the last resort. We are still discussing the available
>> options in https://orgmode.org/list/87k033h218.fsf@localhost.
>
> I have to play with the solution I suggested.  I'm beginning to wonder
> if it will cause other problems with (seeming) Org dependent packages.
> In my case, the error I get is from various use-package calls --
> something like "Error: org-assert-version is not known".  This is
> confusing because I've arranged my .emacs as (almost) an alphabetical
> loading of the packages and some of the use-package errors are coming
> from packages loaded before Org.  IOW, org-assert-version from 9.6
> shouldn't be loaded yet and 9.3 doesn't have org-assert-version. So
> what's referring to org-assert-version?

I went so far as to add the following to early-init.el:

(if (featurep 'org) (load-feature 'org))
(add-to-list 'load-path (expand-file-name "~/.emacs.d/elpa/org-9.6")
(load-library "org")

The load-library still fails with the org-assert-version error.

Could it be that, when you package-install Org-9.6, it runs through a
check where (I think) it compiles the package?  I get a lot of warnings
and 34(?) failed files.  Could it be that some of the files are not
built and, so, when I load-library, I'm picking up some of the wrong
files from the built-in Org-9.3?  Do we need to remove all versions of
Org that is not the current version from the load-path at the very
beginning of org.el to ensure no fall-through?  Kind of a hack, but...

-- 
David Masterson

Re: Multiple versions of Org in load-path problem

[David Masterson]

Ihor Radchenko  writes:

> David Masterson  writes:
>
>> Is there a proper way to do this?  Do I really have to delete the
>> built-in 9.3 version (by hand or package-delete?) or will that mess up
>> something else?  I saw mention of 'unload-feature' which is new to me --
>> would that be safe to use?
>
> In theory, Emacs should handle such updates even when built-in Org is
> loaded. See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59882

I'm going to test if (in my case) the buit-in 9.3 is already loaded when
my .emacs runs,  I also have to see when 9.6 loads in my .emacs.

> unload-feature is the last resort. We are still discussing the available
> options in https://orgmode.org/list/87k033h218.fsf@localhost.

I have to play with the solution I suggested.  I'm beginning to wonder
if it will cause other problems with (seeming) Org dependent packages.
In my case, the error I get is from various use-package calls --
something like "Error: org-assert-version is not known".  This is
confusing because I've arranged my .emacs as (almost) an alphabetical
loading of the packages and some of the use-package errors are coming
from packages loaded before Org.  IOW, org-assert-version from 9.6
shouldn't be loaded yet and 9.3 doesn't have org-assert-version. So
what's referring to org-assert-version?

-- 
David Masterson

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/)]

[Jeremie Juste]

Hello,

Many thanks to you all for your feedback.
>From 1ad16ffb9, I have restored the expected output in R. that is.


#+NAME: example-list
- simple
  - not
  - nested
- list

#+BEGIN_SRC R :var x=example-list
x
#+END_SRC

#+RESULTS:
| simple |
| list   |


On Wednesday,  7 Dec 2022 at 12:16, Ihor Radchenko wrote:

> I also like the second option as **printing** more, but it is _not_ what
> we have in the manual.

Thanks for the precision. We propably need to update the doc. I guess it also
has to be language specific.

Best regards,
Jeremie

Re: Proposal: folding stacked `#+header:' lines in src blocks

[Thomas S. Dye]

h...@heagren.com writes:

First question: what do people think of this, do people support 
this as

an idea?


I would use this feature.  My stack typically includes headers, a 
name, and a caption.  It would be nice to fold them all out of 
sight.


All the best,
Tom

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

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

[Daniel Clemente]

It works now, thanks!

On Wed, 7 Dec 2022 at 10:53, Ihor Radchenko  wrote:

> Daniel Clemente  writes:
>
> > 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
>
> Thanks for reporting!
> Fixed on bugfix.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=4dddbc143
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>

Re: Clocking in is pretty slow in version 9.6 when the item has a large

[Mark Barton]

> On Dec 7, 2022, at 10:36 AM, Ihor Radchenko  wrote:
> 
> Sorry, I meant (setq org-element--cache-self-verify nil).
> In any case, the time is back to previous, which should be good enough
> considering that no optimizations have been made to the clock table
> calculation.

I just realized my mistake on the variable. I'm good. It was very acceptable 
for me at 20s considering how many clocking lines I have to parse going back to 
2019. I will keep the self-verify as is if that will help capture errors before 
the release branch.

Mark

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

[Jeremie Juste]

Hello Malcolm,

On Wednesday,  7 Dec 2022 at 17:50, Cook, Malcolm wrote:
>
> Byte-compiling and reloading ob-R.el worked.

Glad that you could solve it. From 08433d9b0, I added a test to make sure we 
are not
surprised again. 

Best regards,
Jeremie

Re: Clocking in is pretty slow in version 9.6 when the item has a large

[Ihor Radchenko]

Mark Barton  writes:

>> On Dec 7, 2022, at 3:53 AM, Ihor Radchenko  wrote:
>> 
>> What about setting org-element--cache-self-verify to nil?
>
> (setq org-element--cache-self-verify-frequency nil)
> Update clocktable
> Wrong type argument: number-or-marker-p, nil
>
> Try again but use zero instead of nil...
> (setq org-element--cache-self-verify-frequency 0)
> Updates in 11s.

Sorry, I meant (setq org-element--cache-self-verify nil).
In any case, the time is back to previous, which should be good enough
considering that no optimizations have been made to the clock table
calculation.

If you need it, you may run M-x profiler-start  cpu , run
clocktable, M-x profiler-report M-x profiler-report-write-profile, and
share the resulting profile.

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

Re: Clocking in is pretty slow in version 9.6 when the item has a large

[Mark Barton]

> On Dec 7, 2022, at 3:53 AM, Ihor Radchenko  wrote:
> 
> What about setting org-element--cache-self-verify to nil?

(setq org-element--cache-self-verify-frequency nil)
Update clocktable
Wrong type argument: number-or-marker-p, nil

Try again but use zero instead of nil...
(setq org-element--cache-self-verify-frequency 0)
Updates in 11s.

Mark

Prevent files with excluded FILETAGS from being exported

[Thomas Ingram]

Hello,

Currently when trying to export an org file with FILETAGS set to
"noexport" (or any value in `org-export-exclude-tags') the file is still
exported with the title and top level text.  I propose that be changed
so files with FILETAGS in `org-export-exclude-tags' are completely
skipped by the exporter.

This would be extremely useful in combination with ox-publish, as it
would allow users to easily exclude files from publishing from within
the file.  Currently this can only be done by adjusting the ':exclude'
value to match the filename in the `org-publish-project-alist' settings.

Please let me know your thoughts.  I would be happy to try to submit a
patch but I would need some pointers on where in the export process this
change should be added.

Thanks,
--
Thomas Ingram
https://taingram.org

[BUG] generated ":comment link" when tangling babel src blocks are not complete (or buggy)

[Vincent Picaud]

When I tangle code "C-c C-v t" of this org-mode file:

#+title: Demo
#+property: header-args:sh :tangle example.sh :comments link

* Part A
** source
#+begin_src sh
  echo "Part A"
#+end_src

* Part B
** source
#+begin_src sh
  echo "Part B"
#+end_src

I get this example.sh file

# [[file:poub.org::*source][source:1]]
echo "Part A"
# source:1 ends here

# [[file:poub.org::*source][source:1]]
echo "Part B"
# source:1 ends here

Now I move to the line "echo "Part B"" of this example.sh file and call
org-babel-tangle-jump-to-org. This causes me to jump back to the
org-mode file as expected, but it jumps to the "* Part A" heading instead
of the right "* Part B" heading.

If I manually modify the generated example.sh file as follows

# [[file:poub.org::*source][source:2]]
echo "Part B"
# source:2 ends here

then org-babel-tangle-jump-to-org works correctly and jumps back to
right "* Part B" header's source block.

Do you observe the same behavior ? Is there a way to get expected behavior
(still having 2 headings with the same "source" name) ?

Thanks,
despite that, org-mode is awesome! :)

Emacs  : GNU Emacs 28.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.34, cairo version 1.16.0) of 2022-11-09
Package: Org mode version 9.6 (9.6-gc59d6d @
/home/picaud/.emacs.d/straight/build/org/)

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

[Cook, Malcolm]

>"Cook, Malcolm"  writes:
>
>> I tried applying just the change in 
>> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=456462741 to 
>> released Org 9.6 and find that when using `:session *R*` the #+RESULTS are 
>> still empty, but when running without :session the results are provided.
>
>Could you please elaborate what you mean by "just the change"? This
>change is a fix on top of another change we included in Org 9.6.

Of course

I manually edited ob-comint.el and inserted the lines marked with a '+' from 
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=456462741 
(removing the '+') in the right place, and re-evaluated the now modified 
function definition (went to end of defun and hit C-x C-e)

Doh!  

It is a macro not a defun, so simply redefining it will not effect where it was 
used.  

My bad.

Byte-compiling and reloading ob-R.el worked.

So, answering your question revealed my error.

Thanks.

I look forward to the fix finding elpa.

Cheers,

Malcolm

Re: Syntax question: What is BORDER in 4.17. Text Markup?

[Ihor Radchenko]

Nick Dokos  writes:

> The problem is that these things are configurable, so the above is onlyu
> true by default. But you can redefine `org-emphasis-regexp-components` in
> ways that would make the above untrue: hence the more abstract description.

They are no longer configurable:

;; This used to be a defcustom (Org <8.0) but allowing the users to
;; set this option proved cumbersome.  See this message/thread:
;; https://orgmode.org/list/b72cdc2b-72f6-43a8-ac70-e6e629576...@gmail.com
(defvar org-emphasis-regexp-components

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

Re: Syntax question: What is BORDER in 4.17. Text Markup?

[Nick Dokos]

Jens Lechtenboerger  writes:


> Actually, what about this?  Get rid of both, BORDER and BODY, and
> specify CONTENTS as follows:
> “Either a string (when MARKER represents code or verbatim) or a
> series of objects from the standard set, not spanning more than
> three lines.  In any case, CONTENTS must neither begin nor end with
> whitespace.”
>

The problem is that these things are configurable, so the above is onlyu
true by default. But you can redefine `org-emphasis-regexp-components` in
ways that would make the above untrue: hence the more abstract description.

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: TBLFM trying to create an infinite number of lines

[Julien Palard]

> Thank you both for reporting!

Thank you for fixing!

-- 
[Julien Palard](https://mdk.fr)

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

[Max Nikulin]

On 07/12/2022 18:43, Ihor Radchenko wrote:

That said, I find David Masterson's suggestion promising:

  (if (and (featurep 'org) (< org-version 9.6))


`version<'?

Mixed install may be still a problem in the case of bug fix ("patch" 
component of the version) release.

Re: TBLFM trying to create an infinite number of lines

[Ihor Radchenko]

Bruno Barbier  writes:

> Same here with 9.6-pre (release_9.5.5-1096-gf83e45).
>
> Like with:
>
> |  | 
> #+TBLFM: $1='(eval "\n")
>
> IIUC, the command "echo 42" outputs a newline, newlines are not allowed
> as in cell values.

Thank you both for reporting!
Fixed on bugfix.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=97a780f0b

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

Re: Two problems with export to Google calendar

[Max Nikulin]

On 07/12/2022 19:56, Ihor Radchenko wrote:

Neil Jerram:


X-WR-TIMEZONE:BST

which I think was intended to mean British Summer Time; but Google
interpreted it as Bangladesh Standard Time.  As a result, my events
from Org are shown at the wrong time in Google calendar.


By default, ox-icalendar takes the value of your TZ environment variable.


I think, in most cases TZ is not set, so (format-time-string "%Z") is 
used to get abbreviation (that is ambiguous).


On Linux we may try

timedatectl show --property=Timezone --value

during generation of export template. There is a chance that init system 
is not systemd, so the command is not available. It is possible to get 
timezone from /etc/timezone, but the code would not concise since it may 
be a text file or a symlink to the definition. I have no idea concerning 
macOS or Windows.


Emacs relies on libc to handle time zones, and there is no API to get 
the identifier. I miss the option available in modern browser JavaScript


new Intl.DateTimeFormat().resolvedOptions().timeZone

I have never read .ics file spec, so I am unaware what kinds of name are 
allowed for X-WR-TIMEZONE.

Re: Multiple versions of Org in load-path problem

[Ihor Radchenko]

David Masterson  writes:

> Is there a proper way to do this?  Do I really have to delete the
> built-in 9.3 version (by hand or package-delete?) or will that mess up
> something else?  I saw mention of 'unload-feature' which is new to me --
> would that be safe to use?

In theory, Emacs should handle such updates even when built-in Org is
loaded. See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59882

unload-feature is the last resort. We are still discussing the available
options in https://orgmode.org/list/87k033h218.fsf@localhost.

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

Re: Flyspell causes severe slowdown when manipulating footnotes

[Ihor Radchenko]

aroz...@gmail.com writes:

> I just upgraded to Org 9.6 and I've noticed that having flyspell-mode
> turned on causes very large slowdowns when adding or deleting footnotes in
> an org file with lots of footnotes (e.g., more than 200, which is common
> for the academic articles that I use org for). Any ideas for what might be
> causing this?

Most likely cache updates.
Could you please (1) Set org-element--cache-self-verify to nil and see
if things get back to normal; (2) If things are still slow after setting
the variable, please run M-x profiler-start ... M-x profiler-report and
share the data. See https://orgmode.org/list/87ee2nlslt.fsf@localhost.

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

Re: [BUG] Org-mode 9.6 parallel build issue [9.6 (N/A @ /usr/share/emacs/site-lisp/org-mode/)]

[Ihor Radchenko]

Maciej Barć  writes:

>> Could you please provide a more clear recipe to reproduce, if possible?
>
> There are logs in the bug report on the Gentoo Bugzilla,
> from the bug I had already mentioned:
> https://884243.bugs.gentoo.org/attachment.cgi?id=839581
> and from the one occurring with the documentation generation process:
> https://884403.bugs.gentoo.org/attachment.cgi?id=840181

Thanks!
I may be missing something, but I do not see make autoloads in the logs.
make autoloads is necessary if you start from a clean repo.
See https://orgmode.org/manual/Installation.html

I think that adding make autoloads before building documentation should
solve the problem.

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

Re: Two problems with export to Google calendar

[Ihor Radchenko]

Neil Jerram  writes:

> Firstly, when I last exported during late summer, org generated an
> .ics file with
>
> X-WR-TIMEZONE:BST
>
> which I think was intended to mean British Summer Time; but Google
> interpreted it as Bangladesh Standard Time.  As a result, my events
> from Org are shown at the wrong time in Google calendar.

By default, ox-icalendar takes the value of your TZ environment variable.

> Secondly, it seems to me that the concept of having a timezone for the
> whole .ics file might be wrong.  My Org files have dated events in
> both the summer and the winter, and it is obvious to me that the times
> for the summer events should be understood as British Summer time
> (UTC+1), and that the times for the winter events should be understood
> as GMT (UTC).
>
> Do others agree with that?  If so, it would need to be reflected on
> export by each event having its own timezone, instead of a global
> timezone for the whole file.

You can set TIMEZONE heading property to provide a separate time zone
per entry. See 13.15 iCalendar Export section of the manual.

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

Re: [BUG] Not all time/date strings are recognized as time in org-make-tags-matcher [9.6 (9.6-gd500b4 @ /home/hubisan/.emacs.default/straight/build/org/)]

[Ihor Radchenko]

Daniel Hubmann  writes:

> After updating to Org 9.6 this match in the agenda
> 'SCHEDULED<"<+2d>"+SCHEDULED<>"' shows all scheduled items event if they
> are far more in the future than 2 days.
>
> Tracked this down to a commit (e022a0cea11a0e784ba20ac478a033da7fb1bb7f)
> that changed the regular expression to recognize timestamps:
>
> -(timep (string-match-p "^\"[[<].*[]>]\"$" pv))
>> +(timep (string-match-p "^\"[[<][0-9]+.*[]>]\"$" pv))
>>

Thanks for reporting!
It is a duplicate of https://orgmode.org/list/87bkokgtd7@kyleam.com
Fixed (see the linked thread).

-- 
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: session evaluation returns empty ouputs with Org 9.6 [9.6 ( @ /home/fsantos/.emacs.d/elpa/org-9.6/)]

[Ihor Radchenko]

"Cook, Malcolm"  writes:

> I tried applying just the change in 
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=456462741 to 
> released Org 9.6 and find that when using `:session *R*` the #+RESULTS are 
> still empty, but when running without :session the results are provided.

Could you please elaborate what you mean by "just the change"? This
change is a fix on top of another change we included in Org 9.6.

-- 
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.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/)]

[Ihor Radchenko]

Jeremie Juste  writes:

> Many thanks for the insights. I confess that I have never transferred
> list from org to R before. I've always use tables and as far as I
> understand they works fine in 9.6.
>
> So assuming this list
>
> #+name: alist 
> - first item
> - second item
> - third item
>   - 3.1 item
> - fourth item
>
>
> before c72d5ee84 we could do something like 
>
> #+begin_src R :var list=alist
>   list
> #+end_src
>
> #+RESULTS:
> | first item  ||
> | second item ||
> | third item  | (unordered (3.1 item)) |
> | fourth item ||

And it was a bug that the ob-core patch fixed.
Unfortunately, a number of babel backends also developed workarounds
meanwhile.

For the context, the ground truth is Org manual:

16.4 Environment of a Code Block

list
 A simple named list.

  #+NAME: example-list
  - simple
- not
- nested
  - list

  #+BEGIN_SRC emacs-lisp :var x=example-list
(print x)
  #+END_SRC

  #+RESULTS:
  | simple | list |

 Note that only the top level list items are passed along.  Nested
 list items are ignored.

> and after we end up with 
>
>
> #+begin_src R :var list=alist
>   list
> #+end_src
>
> #+RESULTS:
> | first item | second item | third item | fourth item |   |   |   |   |   |   
> |
>
> Here I'm on uncharted territory. We could go with 
> 1.
> | first item | second item | third item | fourth item |
>
> or be closer to the version 9.5 with
> 2. 
> | first item  | 
> | second item | 
> | third item  | 
> | fourth item | 
>
> However I'm still tempted to choose the second option to break as little
> workflow as possible.
>
> If we go in this direction the solution of Chuck works fine. Many thanks
> for the suggestions.

I also like the second option as **printing** more, but it is _not_ what
we have in the manual.

Note that the origin of the issue is in how list=alist is assigned.

Before the problematic commit, we had awkward situation when
alist=(("first item") ("second item") ...)

I changed things to
alist=("first item" "second item" ...)
which makes a lot more sense when passed as variable value.

Now, printing:

ob-core prints lists as a special case of tables.
Since ("first item" "second item" ...) is a row vector, we get
| first item | second item | ... |

changing row vectors to be printed as column vectors is easy, but I am
afraid about non-trivial breakage.


Hope the above clarifies about what happened and why I changes things
like I did.

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

Re: Clocking in is pretty slow in version 9.6 when the item has a large

[Ihor Radchenko]

Mark Barton  writes:

> FYI here is how reducing that number helped with my clocktable updates in the 
> order I tested each value.
> *** org-element--cache-self-verify-frequency 0.01 
> update takes 1:18 (minutes : seconds)
> *** org-element--cache-self-verify-frequency 0.005
> update takes 0:48
> *** org-element--cache-self-verify-frequency 0.002
> update takes 0:28
> *** org-element--cache-self-verify-frequency 0.001
> update takes 0:19
> *** org-element--cache-self-verify-frequency 0.0005
> update takes 0:20
> *** org-element--cache-self-verify-frequency 0.03 (default value)
> update takes 3:29

Thanks for the data!
What about setting org-element--cache-self-verify to nil?
That's what we will do once we finish the test.


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

Re: Two problems with export to Google calendar

[Neil Jerram]

On Wed, 7 Dec 2022 at 11:30, Neil Jerram  wrote:
>
> Firstly, when I last exported during late summer, org generated an
> .ics file with
>
> X-WR-TIMEZONE:BST
>
> which I think was intended to mean British Summer Time; but Google
> interpreted it as Bangladesh Standard Time.  As a result, my events
> from Org are shown at the wrong time in Google calendar.
>
> Secondly, it seems to me that the concept of having a timezone for the
> whole .ics file might be wrong.  My Org files have dated events in
> both the summer and the winter, and it is obvious to me that the times
> for the summer events should be understood as British Summer time
> (UTC+1), and that the times for the winter events should be understood
> as GMT (UTC).
>
> Do others agree with that?  If so, it would need to be reflected on
> export by each event having its own timezone, instead of a global
> timezone for the whole file.
>
> Best wishes,
>  Neil

Ah, it looks like the solution for both points might be customizing
org-icalendar-timezone as "Europe/London".  I will try that...

Neil

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

[Ihor Radchenko]

Bastien  writes:

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

I just asked Emacs devs as it does not look like we do anything wrong
here. It is probably Emacs package.el doing something wrong.
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59882

That said, I find David Masterson's suggestion promising:

  (if (and (featurep 'org) (< org-version 9.6))
  (unload-feature 'org))

We may force unloading the current Org version at the beginning of all
the libraries.

Another possibility could be

  (eval-when-compile (load-file "./org-macs.el"))

instead of require.

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

Two problems with export to Google calendar

[Neil Jerram]

Firstly, when I last exported during late summer, org generated an
.ics file with

X-WR-TIMEZONE:BST

which I think was intended to mean British Summer Time; but Google
interpreted it as Bangladesh Standard Time.  As a result, my events
from Org are shown at the wrong time in Google calendar.

Secondly, it seems to me that the concept of having a timezone for the
whole .ics file might be wrong.  My Org files have dated events in
both the summer and the winter, and it is obvious to me that the times
for the summer events should be understood as British Summer time
(UTC+1), and that the times for the winter events should be understood
as GMT (UTC).

Do others agree with that?  If so, it would need to be reflected on
export by each event having its own timezone, instead of a global
timezone for the whole file.

Best wishes,
 Neil

Proposal: folding stacked `#+header:' lines in src blocks

[hugo]

Sometimes I deal with large blocks (generally src blocks) with a lot of
header arguments. To deal with this, I stack them up in `#+header:'
lines. Real example from a file I have:

,
| #+header: :results (if (org-export-derived-backend-p 
org-export-current-backend 'latex) "latex" "file raw")
| #+header: :file (if (org-export-derived-backend-p 
org-export-current-backend 'latex) nil "foo.png")

| #+header: :packages '((nil "tikz" t))
| #+header: :imagemagick t :fit t
| #+header: :headers '("\\usetikzlibrary{calc,positioning,patterns}")
| #+begin_src latex
|   
| #+end_src
`

This is fine, but the height of the header lines often rather gets in
the way when I'm working (once I've written them out, or expanded them
from a snippet, I don't want to see them again).

Thus, I propose that stacked `#+header:' line on top of blocks be
foldable. I'm thinking of this as roughly analagous to folding property
drawers under headlines. That is:
- the header stack should be foldable independently of the block's
  content. That is, I should be able to fold up my stack of five header
  lines into one line, without folding my block.
- the header lines should be folded by default when the block is folded
- there should be a variable (corresponding to
  `org-cycle-hide-drawer-startup') controlling wether the header stacks
  are shown on startup or not.
- /unlike/ property drawer folding, I think it would be good if hitting
   repeatedly cycled the block through three states:
  - everything unfolded
  - header folded and content open
  - everything folded.

First question: what do people think of this, do people support this as
an idea?

If so, second question: I think this would be implemented by altering
`org-fold--hide-wrapper-toggle' to treat blocks specially with a cyclic
folding system. Is this right?

If other people think this is a good idea, and that's roughly the way to
go, I'll try to make a patch at some point.

Any thoughts welcome!

Hugo

Re: [BUG] Org 9.6 Inactive timestamp search no longer works as expected.

[Ihor Radchenko]

Kyle Meyer  writes:

> On 12/03/22 13:44:33 -0500, Carlo Tambuatco wrote:
>> Simple inactive timestamp search for recent completed tasks used to return 
>> as expected. ie:
>>
>> +TIMESTAMP_IA>=“”+TIMESTAMP_IA<“” 
>>
>> would return all tasks that I completed today. (Had an inactive timestamp 
>> greater than or equal 
>> to 12:00 am of the current day, but less than tomorrow)
>> [...]
>
> Thanks for reporting.  I had noticed one of my "" queries had
> stopped working but hadn't yet got around to bisecting.  Doing so now,
> this looks like a regression from e022a0cea (org-make-tags-matcher: Do
> not treat PROPERTY="[X]" as timestamp match, 2022-10-25).
>
> Ihor, I haven't reviewed the linked discussion in that commit, but with
> its change (shown below), the regex now longer matches things like
> "" and "".
>
> diff --git a/lisp/org.el b/lisp/org.el
> index e93a81210..01e0279c8 100644
> --- a/lisp/org.el
> +++ b/lisp/org.el
> @@ -11337,7 +11337,7 @@ (defun org-make-tags-matcher (match  
> only-local-tags)
>(pv (match-string 7 term))
>(regexp (eq (string-to-char pv) ?{))
>(strp (eq (string-to-char pv) ?\"))
> -  (timep (string-match-p "^\"[[<].*[]>]\"$" pv))
> +  (timep (string-match-p "^\"[[<][0-9]+.*[]>]\"$" 
> pv))

Thanks for the bisection!
The problematic commit tried to fix false positive matches of the
regexp. I overdid it.

Fixed on bugfix now.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=5d14e88c5

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

Re: [BUG] (org-babel-result-to-file) adds the relative path even if attachment link is generated [9.6 (release_9.6-3-ga4d38e @ /usr/share/emacs/30.0.50/lisp/org/)]

[Ihor Radchenko]

Johan Tolö  writes:

> With org 9.6 I am having an issue where the following generates a 
> result with an attachment link that includes the original path to 
> the file. I expect the link to be relative to the attachment 
> directory.
>
> * Test
> :PROPERTIES:
> :DIR:  build
> :END:
>
> #+begin_src R :results output file graphics :file build/test.png
>   plot(1)
> #+end_src
>
> #+RESULTS:
> [[attachment:build/test.png]]
>
> The expected result is:
>
> #+RESULTS:
> [[attachment:test.png]]
>
> My ob-core.el has in the org-babel-result-to-file function (on 
> line 2712):
>
> (file-relative-name result-file-name)
>
> I changed it to:
>
> (file-relative-name result-file-name attach-dir)

Thanks for reporting and catching the cause!
Fixed on bugfix.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=cc5427b7e

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

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

[Ihor Radchenko]

Daniel Clemente  writes:

> 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

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

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

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

[Ihor Radchenko]

Daniel Clemente  writes:

> 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

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

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

Re: Syntax question: What is BORDER in 4.17. Text Markup?

[tomas]

On Wed, Dec 07, 2022 at 11:29:29AM +0100, Jens Lechtenboerger wrote:
> On 2022-12-07, Timothy wrote:

[...]

> > This seems like an improvement to me, implemented in 56338725e61 :)
> 
> Many thanks, Timothy!

Seconded :)
-- 
t


signature.asc
Description: PGP signature

Re: Syntax question: What is BORDER in 4.17. Text Markup?

[Jens Lechtenboerger]

On 2022-12-07, Timothy wrote:

> Hi Jens,
>
>> Actually, what about this?  Get rid of both, BORDER and BODY, and
>> specify CONTENTS as follows:
>> “Either a string (when MARKER represents code or verbatim) or a
>> series of objects from the standard set, not spanning more than
>> three lines.  In any case, CONTENTS must neither begin nor end with
>> whitespace.”
>
> This seems like an improvement to me, implemented in 56338725e61 :)

Many thanks, Timothy!

Best wishes
Jens

Re: Syntax question: What is BORDER in 4.17. Text Markup?

[Timothy]

Hi Jens,

> Actually, what about this?  Get rid of both, BORDER and BODY, and
> specify CONTENTS as follows:
> “Either a string (when MARKER represents code or verbatim) or a
> series of objects from the standard set, not spanning more than
> three lines.  In any case, CONTENTS must neither begin nor end with
> whitespace.”

This seems like an improvement to me, implemented in 56338725e61 :)

All the best,
Timothy

-- 
Timothy (‘tecosaur’/‘TEC’), Org mode contributor.
Learn more about Org mode at .
Support Org development at ,
or support my work at .