Re: [BUG] org-element--cache Cached element is incorrect (ox-hugo) [9.6.10 (release_9.6.10 @ /home/gk/.emacs.d/lib/org/lisp/)]

[Kaushal Modi]

On Wed, Oct 25, 2023 at 5:10 AM Ihor Radchenko  wrote:

> [ Adding Org ML back to CC ]
>
> George Kettleborough  writes:
>
> > I really struggled to come up with a minimal example for this as the
> > behaviour seemed truly bizarre!
> >
> > The best I have is my blog: 
> >
> > To build it (ie. export org files as md files), I run `cd content-org &&
> > emacs --batch -Q --load ../publish.el --funcall gpk-publish-all`
>
> I was able to reproduce.
> Fixed, on bugfix, and, as a separate commit, on main (main diverges from
> bugfix in this part of the code).
>
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=a9e2a97ee
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=9c255cacf
>
>
Thank you for that quick fix Ihor!!

And thank you George for bringing this issue to this ML.

>From the commit log:

> This fixes ox-hugo bug when Org buffer copy cache is corrupted.

Ihor, is there a bug that needs to be addressed on the ox-hugo side as well?

[bug] Org mode 9.6.1: Subtree export without body creates an empty code block on export

[Kaushal Modi]

Hello,

This issue is best explained with this small example.

1. Create this Org buffer:

=
#+options: author:nil toc:nil

* Post 1
:PROPERTIES:
:EXPORT_FILE_NAME: foo
:END:
* Post 2
=

2. Place the cursor at the end of :END:
3. C-c C-e C-s t A


You get this:

=


 POST 1



,

`
=

Note the empty code block exported (I see this for any backend; but I
discovered this as I was locally running the ox-hugo test suite.. and a few
dozen tests which did not have any body in the subtrees, I saw these empty
code blocks), which is not present in the Org source.

If I delete the "* Post 2" line, that empty code block is not exported (as
expected).



Org mode version 9.6.1 (release_9.6.1-116-g07c63d).





--
Kaushal Modi

Re: Request to bump up the Org version in Elpa [

[Kaushal Modi]

On Wed, Jan 11, 2023 at 10:50 AM Bastien  wrote:

> Ihor Radchenko  writes:
>
> > +1
>
> Done, thanks.
>
> Kaushal, it should appear on GNU ELPA in a few hours.
>

Wow, thanks a lot for this prompt action! This will help get the Github
Actions CI status back in green state.. soon :).


> Ihor, feel free to publish bugfix releases with no special permission
> in the future.
>

Request to bump up the Org version in Elpa [ Was: Incorrect numbering of tables (and other elements like figures) ]

[Kaushal Modi]

Hello,

Can a new version of Org be tagged from the bugfix branch?

The below-reported bug was fixed quickly but the Elpa version of Org
doesn't yet see that fix.

My ox-hugo package uses the Elpa version of Org mode for the tests on
Github Actions, so my test suite has been failing for quite some time.

I believe that for Elpa, the only way to update the version is to update
the version in the package's comment header.

--
Kaushal Modi


On Tue, Dec 13, 2022 at 3:51 PM Kaushal Modi  wrote:

> On Tue, Dec 13, 2022 at 3:52 AM Ihor Radchenko 
> wrote:
>
>> Kaushal Modi  writes:
>>
>> > Since Org 9.6, I am seeing that the numbering of tables (and other
>> elements
>> > like figures) resets to 1 and stays so, thought I cannot see a pattern
>> of
>> > why that happens.
>> >
>> > Org version: Org mode version 9.6 (release_9.6-40-g49cf3e ..)
>> >
>> > Here's a small reproducible example that shows the problem in any
>> exporter
>> > (ox-ascii, ox-html, ..)
>> > ...
>>
>> Thanks for reporting!
>> Fixed on bugfix. With a test now.
>> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=bdb4c4c66
>> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=02909fe37
>>
>>
> Thank you!
>
> I confirm the fix. Also thanks for adding the test.
>

Re: [Syntax discussion] Should we treat src blocks without LANG as paragraphs? (was: [BUG] ox-html does not export captions of source blocks without language)

[Kaushal Modi]

On Thu, Dec 15, 2022, 4:32 AM Ihor Radchenko  wrote:

> Johan Bolmsjö  writes:
>
> > #+caption: Caption 1
> > #+begin_src
> > foo bar baz
> > #+end_src
>
> There is an inconsistency here between Org parser and
> https://orgmode.org/worg/org-syntax.html + manual.
>
> The actual parser does allow empty lang in src blocks, setting :lang
> element property to nil.



Should we stop doing this and treat such src
> blocks as paragraphs?


I think that this would cause more of a surprise to the user when something
in a source block exports as a plain paragraph instead of in a  block
(for HTML exports).

Or should we allow empty lang and instead adapt
> the exporters to treat empty lang correctly?
>

I vote for this one. Then

#+begin_src
foo
#+end_src

will be analogous to this in Markdown:

```
foo
```

Re: [BUG] ox-html does not export captions of source blocks without language

[Kaushal Modi]

On Wed, Dec 14, 2022, 4:44 PM Johan Bolmsjö 
wrote:

> ** Description
>
> The caption "Caption 1" is not exported by ox-html in the following
> source block.
>
> #+caption: Caption 1
> #+begin_src
> foo bar baz
> #+end_src
>

The begin_src block always requires a "language" as far as I know. If you
don't want to specify a language, you can use #+begin_example instead.

You can even do "#+begin_src text".

It's a different issue as to why you are seeing a different behavior
between the two exporters.

>

Re: Incorrect numbering of tables (and other elements like figures) [Org 9.6]

[Kaushal Modi]

On Tue, Dec 13, 2022 at 3:52 AM Ihor Radchenko  wrote:

> Kaushal Modi  writes:
>
> > Since Org 9.6, I am seeing that the numbering of tables (and other
> elements
> > like figures) resets to 1 and stays so, thought I cannot see a pattern of
> > why that happens.
> >
> > Org version: Org mode version 9.6 (release_9.6-40-g49cf3e ..)
> >
> > Here's a small reproducible example that shows the problem in any
> exporter
> > (ox-ascii, ox-html, ..)
> > ...
>
> Thanks for reporting!
> Fixed on bugfix. With a test now.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=bdb4c4c66
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=02909fe37
>
>
Thank you!

I confirm the fix. Also thanks for adding the test.

Incorrect numbering of tables (and other elements like figures) [Org 9.6]

[Kaushal Modi]

Hello,

Since Org 9.6, I am seeing that the numbering of tables (and other elements
like figures) resets to 1 and stays so, thought I cannot see a pattern of
why that happens.

Org version: Org mode version 9.6 (release_9.6-40-g49cf3e ..)

Here's a small reproducible example that shows the problem in any exporter
(ox-ascii, ox-html, ..)

=
#+title: Table numbering test
#+options: author:nil toc:nil

#+caption: Should be Table 1
| h1   | h2   | h3   |
|--+--+--|
| abcdefgh | ijklmnop | qrstuvwx |

#+caption: Should be Table 2
| h1   | h2   | h3   |
|--+--+--|
| abcdefgh | ijklmnop | qrstuvwx |

#+caption: Should be Table 3
| h1   | h2   | h3   |
|--+--+--|
| abcdefgh | ijklmnop | qrstuvwx |

#+caption: Should be Table 4
| h1   | h2   | h3   |
|--+--+--|
| abcdefgh | ijklmnop | qrstuvwx |
=

Output of C-c C-e t A:

=
 __

  TABLE NUMBERING TEST
 __


 h1h2h3
--
 abcdefgh  ijklmnop  qrstuvwx
Table 1: Should be Table 1

 h1h2h3
--
 abcdefgh  ijklmnop  qrstuvwx
Table 2: Should be Table 2

 h1h2h3
--
 abcdefgh  ijklmnop  qrstuvwx
Table 1: Should be Table 3

 h1h2h3
--
 abcdefgh  ijklmnop  qrstuvwx
Table 1: Should be Table 4
=



--
Kaushal Modi

Re: [BUG] Setting export scope to subtree not working as expected [9.6 (9.6-gb3da42 @ /Users/apc/.emacs.d/straight/build/org/)]

[Kaushal Modi]

Hi Alejandro,

Thanks for reporting this issue. I was seeing the same issue and I wasn't
sure if this issue was in org-mode or the ox-hugo package. It was on my
to-debug list.

Ihor: Thank you for the quick response and fix!

On Sat, Dec 10, 2022, 4:47 AM Ihor Radchenko  wrote:

> Alejandro Pérez Carballo  writes:
>
> > If point is on a heading followed by a subheading without any text in
> between, the export process is using the tree starting with the subheading
> instead of the tree starting from point position. If instead you have some
> text after the first heading and before the subheading, the tree that is
> exported is the tree starting from point position, as expected. I’m
> assuming this is a bug, but maybe I’m missing something.
> >
> > For example, take a buffer containing just this:
> >
> >* The title
> >** A subtitle
> >Some text
> >
> > If I export this to an HTML buffer, with point at the beginning of the
> first line and  after setting the scope to ‘subtree’, I get an HTML buffer
> whose title is “A subtitle”.
> >
> > If I follow the same steps on a buffer containing just this:
> >
> >* The title
> >Some text
> >** A subtitle
> >
> > I get an HTML buffer whose title is “The title”.
>
> Thanks for reporting!
> Fixed on bugfix.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=0616b3c37
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>
>

Re: Org mode, Org Mode, Org-mode or Org-Mode?

[Kaushal Modi]

On Fri, Oct 28, 2022, 4:25 PM Marcin Borkowski  wrote:

> What is the "official" version?  I found at least two spelling on
> orgmode.org...
>
> TIA,
>

Here's my personal take on that topic:
https://scripter.co/how-do-i-write-org-mode/

>

Re: [ANN] We are now regularily testing Org main branch against Emacs 26, 27, 28

[Kaushal Modi]

On Sun, Oct 16, 2022 at 2:04 AM Bastien  wrote:

> Hi all,
>
> thanks to joint efforts by Christian Köstlin and Ihor, we are running
> the Org test suite from the Org main branch against Emacs 26, 27, 28.
>

It's great to hear this. Thank you, Christian and Ihor!

Re: Interest in an Org video meetup?

[Kaushal Modi]

I'd like to join.

--
Kaushal Modi


On Thu, Oct 6, 2022 at 9:24 AM Russell Adams 
wrote:

>
> Would there be any interest in a monthly 1-2 hour long ad-hoc screen
> sharing and video discussion for Org-mode?
>
> I'm offering to schedule and moderate the first few events. I'd
> propose a Saturday meeting in the afternoon European time to cover EU
> and NA.
>
> I'm considering using Jitsi, or maybe GNU Jami.
>
> Topics could include Q, demonstrations of features, interactive
> troubleshooting, etc. I hadn't considered presentations, but
> that could be an option too.
>
> Comments?
>
> --
> Russell Adamsrlad...@adamsinfoserv.com
> https://www.adamsinfoserv.com/
>
>

Re: Support for tagging (special) blocks

[Kaushal Modi]

On Wed, Aug 31, 2022 at 4:19 PM Sébastien Miquel 
wrote:

> Hi,
>
> I've been using tags on special blocks, src blocks and other, for two
> purposes:
>
>   1. to control which blocks get exported, using the `#+exclude_tags`
>  property.
>   2. to fine tune the export, according to tags, of special blocks such as
>  #+BEGIN_exercice:hard:
>  …
>  #+END_exercice
>
> Does anyone think this is useful and might warrant adding support for ?
>

I think that using the #+header: property for something like this might be
more canonical.
https://orgmode.org/manual/Using-Header-Arguments.html

Example:

=
#+header: :tags noexport
#+begin_foo
..
#+end_foo
=

or

=
#+header: :tags hard
#+begin_foo
..
#+end_foo
=

It's also relatively easy to parse these headers:

=
(org-babel-parse-header-arguments (car (org-element-property :header
special-block)))
=

Re: org-set-properties for various (all) headings

[Kaushal Modi]

On Wed, Jul 20, 2022 at 4:07 AM Uwe Brauer  wrote:

> 2. Second code
>
> (defun test/set-property-at-heading ()
>   "Function to be called at the beginning of an Org heading."
>   (interactive)
>   (let ((el (org-element-at-point)))
> ^el is defined but not used.
> (org-set-property "New" "[ ]")))
> (org-map-entries #'test/set-property-at-heading)
>

Correct. The el variable is not required here. It's a relic from the
previous version of that function.


> A.11 Using the Mapping API
> > A.10 Using the Property API
>
> Is this a reference to the manual?
>

Yes. You can access those from within Emacs as Info manuals:

- (org) Using the Mapping API - online

- (org) Using the Property API - online

Re: org-set-properties for various (all) headings

[Kaushal Modi]

On Tue, Jul 19, 2022 at 12:58 PM Uwe Brauer  wrote:

>
> > On Tue, Jul 19, 2022, 10:54 AM Uwe Brauer  wrote:
>
> > Try replacing the `org-set-property` form to:
>
> > (org-set-property "New" "[]")
>
> This does not anything (besides garbage collecting)
>

Did you replace only the `org-set-property` form with my suggestion?

In any case, I got to a computer and I tested that to work alright.

=
* Over
:PROPERTIES:
:ID:   ef19f286-8769-4fe7-8f95-8167691257a0
:COLUMNS:  %5TODO(Status) %5NR(Nr)
:foo:  Over
:END:
** TODO Test
:PROPERTIES:
:Sent: [X]
:END:

** WAIT Test2
:PROPERTIES:
:Sent: [X]
:END:

** TODO Test3
:PROPERTIES:
:Sent: [ ]
:END:

#+begin_src emacs-lisp
(defun test/set-property-at-heading ()
  "Function to be called at the beginning of an Org heading."
  (interactive)
  (let ((el (org-element-at-point)))
(org-set-property "New" "[ ]")))
(org-map-entries #'test/set-property-at-heading)
#+end_src
=

Hit C-c C-c with the cursor in that code block, say "yes" or "y" if
prompted, and then you should see that Org buffer change to:

=
* Over
:PROPERTIES:
:ID:   ef19f286-8769-4fe7-8f95-8167691257a0
:COLUMNS:  %5TODO(Status) %5NR(Nr)
:foo:  Over
:New:  [ ]
:END:
** TODO Test
:PROPERTIES:
:Sent: [X]
:New:  [ ]
:END:

** WAIT Test2
:PROPERTIES:
:Sent: [X]
:New:  [ ]
:END:

** TODO Test3
:PROPERTIES:
:Sent: [ ]
:New:  [ ]
:END:

#+begin_src emacs-lisp
(defun test/set-property-at-heading ()
  "Function to be called at the beginning of an Org heading."
  (interactive)
  (let ((el (org-element-at-point)))
(org-set-property "New" "[ ]")))
(org-map-entries #'test/set-property-at-heading)
#+end_src

#+RESULTS:

=

Re: org-set-properties for various (all) headings

[Kaushal Modi]

On Tue, Jul 19, 2022, 10:54 AM Uwe Brauer  wrote:

>
>
> #+begin_src elisp :noexport
> (defun my-set-property-at-heading ()
>   "Function to be called at the beginning of an Org heading."
>   (interactive)
>   (let ((el (org-element-at-point)))
> (org-set-property "New" (org-element-property "[ ]" el)
> (org-map-entries #'my-set-property-at-heading)
>
> #+end_src
>

Try replacing the `org-set-property` form to:

(org-set-property "New" "[]")

[Not tested, typing from phone.]

Re: org-set-properties for various (all) headings

[Kaushal Modi]

Check out org-map-entries. I have one example here:
https://scripter.co/looping-through-org-mode-headings/#example-modifying-a-property-in-all-headings
.

On Tue, Jul 19, 2022, 4:16 AM Uwe Brauer  wrote:

>
>
> Now, I would add to all subheadings a new property, say
>
>  :Received:  [ ]
>
> Whose value I will then individually change later.
>
> Any idea how to do that

Re: Taking notes of videos in Emacs

[Kaushal Modi]

On Fri, Jul 8, 2022, 9:07 AM Gerardo Moro  wrote:

> Hi,
>
> I recently discover the Obsidian Media Extended plugin (
> https://www.youtube.com/watch?v=GQXVWtNkeZw) to take notes while watching
> videos / listening to audios with keybindings to stop the video and create
> timestamps with link to the specific moment of the video, etc.
>
> Is there something similar in Emacs?
>

I think Sacha Chua uses Org mode to take time stamped notes. She might be
able to point you to her note taking flow.

>

Re: how to convert a non-org list to org headings

[Kaushal Modi]

On Wed, Jul 6, 2022 at 11:17 AM Uwe Brauer  wrote:

> Hi
>
> I have a file that contains a list as:
>
>
> 1.1 Funciones de una variable
>
> 1.1.1. Catálogo de funciones. Translaciones y dilataciones
>
> 1.1.2. Derivación
>
> 1.1.2.1. Optimización. Tasa de cambio
>
> 1.1.2.2. Aproximación de funciones
>
> 1.1.2.3.1. Interpolación vs. ajuste
>
> 1.1.2.3.2. Polinomio de Taylor
>
> 1.1.2.3. Ceros de funciones (método de Newton-Raphson)
>
> 1.1.3. Integración
>
> 1.1.3.1. Integral definida. Aplicaciones
>
> 1.1.3.2. Integral impropia
>
> 1.1.3.2.1. De 1.ª especie
>
> 1.1.3.2.2. De 2ª especie
>
>
>
> Etc, that is a non org list but I would like to convert
> it to the corresponding headings
>
> ** Funciones de una variable
>
> *** Catálogo de funciones. Translaciones y dilataciones
>
> Etc, any idea how to do this in a quick way?
>

The method that I show below is quick but not robust. You'll need to review
all the replacements.

- Do query-replace-regexp [default binding: C-M-%]
- Search for [0-9]+\.
- Replace with *

Running that on your example gives:

=
*1 Funciones de una variable

*** Catálogo de funciones. Translaciones y dilataciones

*** Derivación

 Optimización. Tasa de cambio

 Aproximación de funciones

* Interpolación vs. ajuste

* Polinomio de Taylor

 Ceros de funciones (método de Newton-Raphson)

*** Integración

 Integral definida. Aplicaciones

 Integral impropia

* De *ª especie

* De 2ª especie
=

You'll need to manually fix up the " *1 Funciones de una variable" and "
* De *ª especie" lines.

Re: Utility of description lists

[Kaushal Modi]

On Fri, Jun 17, 2022 at 8:50 AM Cletip Cletip  wrote:

> Final question : why do you use description lists and not another ?

I use description lists *heavily*.

1. For description lists of course.. where the "description" part is a
bit verbose and plain lists don't look at that elegant

For example, this in Org

=
** Customizing ~local.mk~ (Optional)
Here are few variables that you might like to change in the ~local.mk~:
- ~prefix~ :: Org installation directory
  #+begin_src makefile
  prefix = /dir/where/you/want/to/install/org # Default: /usr/share
  #+end_src
  The ~.el~ files will go to ~$(prefix)/emacs/site-lisp/org~ by
  default. If you'd like to change that, change the ~lispdir~
  variable too.
- ~infodir~ :: Org Info installation directory. I like to keep the
  Info file for development version of Org in a separate directory.
  #+begin_src makefile
  infodir = $(prefix)/org/info # Default: $(prefix)/info
  #+end_src
- ~ORG_MAKE_DOC~ :: Types of Org documentation you'd like to build by
  default.  Setting below generates only the Org Info manual.
  #+begin_src makefile
  ORG_MAKE_DOC = info # Default: html pdf
  #+end_src
=

exports to 
https://scripter.co/building-org-development-version/#customizing-local-dot-mk--optional

2. Where something would belong in a sub-heading, but not quite
exactly? I can only describe that using one of my examples:

=
* Using ~pip install~
If you do not want to manually download the ~.jar~, there's a Python
wrapper available to do the same for you:
[[https://github.com/svenkreiss/html5validator][html5validator]].
- Install ::
  #+begin_src shell
  pip install --user html5validator
  #+end_src
- Run ::
  #+begin_src shell
  html5validator --root public/
  #+end_src
  It seems like this Python wrapper implicitly passes ~--skip-non-html
=

exports to https://scripter.co/offline-html5-validator/#using-pip-install

3. Sometimes I also use it for adding Notes to a section

=
- Note :: While the =%.1f= format is handy for those who are used to
  =printf()= syntax, note that Calc unlimited precision
  numbers are converted to double floats before applying
  =%.1f=. Whereas =f1= operates on Calc numbers without
  conversion.
=

exports to the Note in
https://scripter.co/field-formatters-in-org-table/#using-calc-f1-formatter

Re: Missing stardiviner repos [org-contrib]

[Kaushal Modi]

On Sun, Jun 5, 2022, 9:40 AM Kaushal Modi  wrote:

>
> Have you moved those repos elsewhere?
>

I kept on looking at the release 0.4 commit message on the org-contrib and
didn't realize that the "release notes" referred in that Mastodon thread
are at the different place on sr.ht .

I see that those repos have moved to https://repo.or.cz (ref :
https://git.sr.ht/~bzg/org-contrib/refs/release_0.4 ).

>

Missing stardiviner repos [org-contrib]

[Kaushal Modi]

Hello Christopher,

I read about the release of Org Contrib:
https://git.sr.ht/~bzg/org-contrib/commit/c6aef31ccfc7c4418c3b51e98f7c3bd8e255f5e6
..

The release notes mention that few of the org-contrib packages have moved
to your repos on GitHub. But none of those repos are visible:
https://github.com/stardiviner?tab=repositories.

Have you moved those repos elsewhere?

Do you plan to maintain that? If not, can you notify which need to be moved
an Emacs archive repository? I am aware of https://github.com/emacsmirror
that's used for that purpose.

Reference thread on Mastodon: https://fosstodon.org/@bzg/108424011487959609

--
Kaushal Modi

Re: [PATCH] ox: fix comment exported as a blank line

[Kaushal Modi]

On Wed, Jun 1, 2022 at 1:32 AM Phil Estival  wrote:
>
>
> * lisp/ox.el (org-export--skip-p): no longer export single-line
> comments as blank lines which did break paragraphs in two.

This is a pretty big breaking change. In your next PATCH email, I see
that you are also modifying the test that ensures that a comment line
gets parsed as a paragraph break.

Re: BUG: org cycling regression when using the legacy folding style overlays

[Kaushal Modi]

On Mon, May 30, 2022 at 7:45 PM Ihor Radchenko  wrote:
> Your code__collapse_all_posts block makes use of hide-subtree from
> outline.el. Please, do not use it. outline.el is no longer considered
> compatible with Org. It was not in the past, and even more so now. This
> has been announced in ORG-NEWS.

I read the ORG-NEWS:

> The new folding backend breaks some of the =outline-*= functions that
> rely on the details of visibility state implementation in
> =outline.el=.  The old Org folding backend was compatible with the
> =outline.el= folding, but it is not the case anymore with the new
> backend.  From now on, using =outline-*= functions is strongly
> discouraged when working with Org files.

It says that the new folding backend won't work with outline.el. But
in this case, I am still using the old backend.
Are the outline.el functions expected to stop working for the old backend too?

I replaced hide-subtree with org-fold-hide-subtree and my subtree
collpasing function seems to work as before even with
org-fold-core-style set to 'overlays. I will update this thread if I
see any issue with that.

Thanks!

Re: BUG: org cycling regression when using the legacy folding style overlays

[Kaushal Modi]

On Mon, May 30, 2022, 7:45 PM Ihor Radchenko  wrote:

> Kaushal Modi  writes:
>
> > I was trying to create a minimal reproducible example for a different
> > issue and I ended up with this other issue that I didn't expect and so
> > I am reporting that first.
> >
> > Issue: Opening an Org file gives (wrong-number-of-arguments # > looking-at> 2) error.
>
> Do I understand correctly that your reproducer has nothing to do with
> this error?
>

Oddly, I was able to reproduce that error 2 times in an emacs -Q session,
but after resetting the Org element cache, that error went away. So turns
out that the same cache can be reused between emacs -Q and regular Emacs
sessions?

Your code__collapse_all_posts block makes use of hide-subtree from
> outline.el. Please, do not use it. outline.el is no longer considered
> compatible with Org. It was not in the past, and even more so now. This
> has been announced in ORG-NEWS.
>

Thanks! I definitely missed that. I'll read up on how to do the same
without hide-subtree.

>

BUG: org cycling regression when using the legacy folding style overlays

[Kaushal Modi]

Hello,

I was trying to create a minimal reproducible example for a different
issue and I ended up with this other issue that I didn't expect and so
I am reporting that first.

Issue: Opening an Org file gives (wrong-number-of-arguments # 2) error.

=
Warning (org-element-cache): org-element--cache: Org parser error in
t.org::88. Resetting.
 The error was: (wrong-number-of-arguments # 2)
 Backtrace:
nil
 Please report this to Org mode mailing list (M-x org-submit-bug-report).
=

Recipe:

1. Clone https://gitlab.com/kaushalmodi/org-mode-mwe to a temp
directory (say, in /tmp)
2. cd to the org repo and check out the main branch. The Org version
used when creating this report was release_9.5.3-520-g4dda0d.
3. emacs -Q -L ./lisp/
/tmp/org-mode-mwe/bug-recipes/collapse-all-post-subtrees/t.org &
4. Evaluate the "code__fold_style" src block in that test file; it
sets the fold style to overlays
5. Evaluate the "code__collapse_all_posts" src block; this code hides
all the subtrees with non-empty values for EXPORT_FILE_NAME or
CUSTOM_ID properties.

If you skip step 4, you will find the collapsing of all subtrees where
EXPORT_FILE_NAME or CUSTOM_ID is set happens as expected in step 5.

But if you evaluate step 4, most (or all?) subtrees remain uncollapsed.
Additionally, once step 4 + 5 are evaluated, the default TAB binding
that should cycle a subtree's visibility also starts behaving
erratically.

For example, move cursor to line 68 (* Image / Figure) in the test
file t.org after completing all of the above steps.

You will find these lines visible:

=
* Image / Figure  :image:
** Image links
:PROPERTIES:
:EXPORT_FILE_NAME: image-links
:EXPORT_DATE: 2017-07-15T07:49:44-04:00
:END:
=

Hit TAB once, and now you see this: it hid only the title of the
subtree heading under it, but still shows the property drawer
expanded!

=
* Image / Figure  :image:
:PROPERTIES:
:EXPORT_FILE_NAME: image-links
:EXPORT_DATE: 2017-07-15T07:49:44-04:00
:END:
=

Hit TAB once again, you will see:

=
* Image / Figure  :image:
** Image links...
=

Now if you move the point to line 69 (* Image links), hitting the TAB
will not do any kind of cycling at all.

--
Kaushal Modi

About opening issues vs email [Was: About 'inline special blocks']

[Kaushal Modi]

On Thu, May 26, 2022 at 1:36 PM João Pedro  wrote:
>
> On Thu, May 26 2022 20:20, Ihor Radchenko  wrote:
>
> > I think that you can simply open an issue in his Github repo.
>
> I reached out to him on e-mail, if he doesn't reply there I'll create
> the issue. Thanks!

Just saying this based on my personal preference. I would rather
prefer that people directly open an issue on Github than emailing me
personally.

Reasons:

- Issues section is there for a reason. If the repo owner did not like
people opening Issues, they would disable that section.
- Conversations and discussions are better formatted and readable in
the issue threads.
- If the feature is implemented, I like to link that commit or PR to
that issue so that the entire history and reasoning behind a feature
addition (esp. if it's a breaking one) can be followed through
hyperlinks from the commit log to the issue thread.

Re: export regions of a org files to other formats (most likely only to a buffer).

[Kaushal Modi]

On Wed, May 25, 2022 at 11:09 AM Uwe Brauer  wrote:
>
> Hi
>
> Sometimes I only want to convert/export a region or a paragraph of an
> org file to another format, most likely as html or latex.
> I cannot find such a functionality also not in the package system
> does anybody knows about such a function?

Check out this recent thread:
https://lists.gnu.org/r/emacs-orgmode/2022-05/msg4.html
It concludes with a solution on how to convert a region in Org buffer
to Markdown. You can do something similar for any exporter.

http://mbork.pl/2021-05-02_Org-mode_to_Markdown_via_the_clipboard

Re: About 'inline special blocks'

[Kaushal Modi]

On Mon, May 23, 2022 at 10:33 AM Juan Manuel Macías
 wrote:

> I think this idea was suggested by Ihor in a thread from a few months
> ago (I don't remember which one), but since other topics were discussed,
> the idea remained a bit in limbo. I still find the idea very
> interesting, and I think it would be very productive for Org to have a
> multipurpose inline container, so it occurred to me to open this thread
> to invite a possible discussion on the subject.

Thanks for doing this. I missed that thread. I would welcome this
feature addition too.

If I understand correctly, this will mean adding a new element type
that all the Org exporters can then support. Right?

> The question is: Does Org Mode need inline special blocks?

Yes.

> On the one hand, it seems that we can live without them.

Not quite. I developed few hacks in ox-hugo to make regular special
blocks act like special inline blocks :D

Example:

=
More than the visual inaccuracy of seeing curved quoted where straight
quotes should be,
#+begin_mark
if someone copies that code to try it out, it will
not work
#+end_mark
!
=

Another example:

=
By the way, I submitted a patch for fixing the escaping of straight
quotes in ~shortdoc-add-function~ documentation string
#+begin_sidenote
I planned to fix just this straight quote escaping issue, but then I
also ended up slightly improving the documentation of the ~(FUNC :eval
EVAL)~ and other forms used for adding a function's documentation to
~shortdoc~.
#+end_sidenote
in ..
=

ox-hugo does the job of deleting the newlines and white-space (leaving
just 1) before and after few "special" special Org blocks.


> Therefore, I think that inline special blocks would fill an important
> gap. They could be translated into HTML as a  container;

+1

> Perhaps the syntax could be a continuation of that of inline code
> blocks. Something like:
>
> _[options]{text}

The challenging part will be deciding the syntax so that there are no
false matches.

May be reserve "inline_" for inline blocks?

e.g. inline_[options]{text}  ?

Using my example above, if I want the  elements in HTML, I would do

abc inline_mark{some text} def

and that would export to below for an HTML based exporter:

abc some text def

Re: Change of behavior of org-meta-return in 9.6/DoomEmacs?

[Kaushal Modi]

On Tue, May 17, 2022 at 12:24 PM Guillaume MULLER
 wrote:
>
> I noticed that hitting Meta-Return in org in Doom does not behave as in 
> Vanilla Emacs. If I have (with <> being the cursor):
>
> * outline 1
> ** outline 2
>+ no<>te1
>+ note2
>
> In Vanilla Emacs, hitting M-Ret (i.e. calling org-meta-return) resulted in:
>
> * outline 1
> ** outline 2
>+ no
>+ <>te1
>+ note2

I am seeing your Vanilla Emacs behavior on Emacs 28.1 with Org built
from main branch (Org mode version 9.5.3 (release_9.5.3-504-gcdbb1c)).

> As I use "keycast" package, I can see that, in both cases:
> - M-Ret is org-meta-return
> - C-Ret is +org/insert-item-below

The keycast package's modeline display might not show if that
org-meta-return has been advised to modify the behavior.

If you do C-h f org-meta-return, do you see something like "This
function has .. advice: .." towards the end of that *Help* buffer?

> How can I check if it is a change in org 9.6 or in DoomEmacs?

Try reverting your DoomEmacs version to an older version to see if
that fixes it.
Then try reverting to the Org stable version from GNU ELPA (version
9.5.3) and see if that fixes the issue.

Also, may be opening an issue on the DoomEmacs repo might help.

Good luck!

Re: Inline src org block element with containing inside item does not get exported when it contains a newline (was: Inline src block element not parsed correctly for export when in a list item)

[Kaushal Modi]

On Sat, May 14, 2022 at 5:39 AM Ihor Radchenko  wrote:
>
> I just tried again on the latest main and I cannot reproduce anymore.
> Though I do see the problem on bugfix.
>
> Can you please check again on your side?

I confirm -- I cannot reproduce the bug in Org mode version 9.5.3
(release_9.5.3-482-gd5a52b).

For reference, I tried the same bug recipe from my earlier email:
https://lists.gnu.org/r/emacs-orgmode/2022-03/msg8.html.

Re: [BUG] C-u C-u C-u TAB regression on master

[Kaushal Modi]

> Allen Li  writes:
>
> > There appears to be a regression in the behavior of C-u C-u C-u TAB on
> > master (at aea24b3feafb9c389dc5933005928462bb20c4f8).
> >
> > C-u C-u C-u TAB is supposed to show everything including drawers, but on
> > this test file it does not show property drawers:

Thanks for reporting this! I was about to create a report for the same
issue. For me though, this issue persisted regardless of the value of
org-fold-core-style.
But it's fixed now.

On Thu, May 12, 2022 at 9:43 AM Ihor Radchenko  wrote:
> Thanks for reporting!
> Fixed on main via 7dcd15105.

Thanks! I confirm the fix.

Re: source block evaluation in #+DATE line

[Kaushal Modi]

Also check out the {{{time}}} macro if you want complete control on
the formatting of the date string.

Example Org snippet:

=
#+date: {{{time(%Y-%m-%d)}}}
#+options: toc:nil author:nil

See the ~{{{time}}}~ macro in [[info:org#Macro Replacement][org#Macro
Replacement]].

The format passed to the ~time~ macro is same as that understood by
[[help:format-time-string]].

- Note :: Remember to escape the commas. \\
  Example: ~#+date: {{{time(%b %e %Y\, %a)}}}~.


#+begin_src emacs-lisp
(org-export-as 'ascii)
#+end_src
=

Re: oc-basic "Wrong value for ENTRY-OR-KEY" error on emacs master (29.x) [Was: Bibliographies on export with ox-context and ox-epub]

[Kaushal Modi]

On Mon, May 9, 2022 at 5:44 PM Kaushal Modi  wrote:
>
> I have now sent this to Emacs bug tracking:
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=55342

Thanks for the debug[1] Ihor!

This issue was quickly fixed on Emacs master in
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=d221c02fa1db17e1275687f0bbce4ff1499119a1.

[1]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=55342#11

bug#55342: 29.0.50; org-cite-basic--get-field: Wrong value for ENTRY-OR-KEY: nil

[Kaushal Modi]

done 55342

On Tue, May 10, 2022 at 1:06 AM Lars Ingebrigtsen  wrote:
>
> Ihor Radchenko  writes:
>
> > The code above always skips a bibtex entry starting at bob.
> > Hence, the provided example bibliography is parsed as empty, which is
> > not expected by Org.
>
> This should now be fixed on the trunk.

Thanks! I confirm the fix.

Re: oc-basic "Wrong value for ENTRY-OR-KEY" error on emacs master (29.x) [Was: Bibliographies on export with ox-context and ox-epub]

[Kaushal Modi]

I have now sent this to Emacs bug tracking:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=55342

Re: oc-basic "Wrong value for ENTRY-OR-KEY" error on emacs master (29.x) [Was: Bibliographies on export with ox-context and ox-epub]

[Kaushal Modi]

On Mon, May 9, 2022 at 10:21 AM Kaushal Modi  wrote:
> Can someone using emacs
> built from master branch confirm that they see this same error when
> `org-cite-process-bibliography` is called? It should be reproducible
> without using ox-hugo too.


Alright I was able to confirm this possibly upstream bug on Emacs 29
after building it from source.

Here's a minimal test recipe:

=
#+title: "Wrong value for ENTRY-OR-KEY: nil" error on Emacs 29

#+bibliography: test.bib

#+begin_src bib :tangle test.bib
@article{Foo,
 author={Bar},
 journal={Zoo},
 title={Foo by Bar},
 year={2021}}
#+end_src

[cite:@Foo]

#+print_bibliography:

Evaluate the below code block.

#+begin_src emacs-lisp :results none
(org-babel-tangle)
(org-export-as 'ascii)
#+end_src
=

1. Open the above file in Emacs.
2. Run C-c C-c in that emacs-lisp code block

On Emacs 28: No error
On Emacs 29: org-cite-basic--get-field: Wrong value for ENTRY-OR-KEY: nil

oc-basic "Wrong value for ENTRY-OR-KEY" error on emacs master (29.x) [Was: Bibliographies on export with ox-context and ox-epub]

[Kaushal Modi]

On Thu, Nov 25, 2021 at 6:21 AM juh  wrote:
> With cite_export: basic I get
>
> Wrong value for ENTRY-OR-KEY: nil

Hello,

I saw the ox-hugo CI fail with emacs master (29.0.50) over the past
few days with this backtrace, but this error is probably not related
to ox-hugo, and I need help confirming if that's the case.


=

  signal(error ("Wrong value for ENTRY-OR-KEY: nil"))
  error("Wrong value for ENTRY-OR-KEY: %S" nil)
  org-cite-basic--get-field(author nil (:export-options (subtree)
:back-end #s(org-export-backend :name hugo :parent blackfriday
:transcoders ((code . org-hugo-kbd-tags-maybe) (example-block .
org-hugo-example-block) (export-block . org-hugo-export-block)
(export-snippet . org-hugo-export-snippet) (headline .
org-hugo-heading) (inner-template . org-hugo-inner-template)
(inline-src-block . org-hugo-inline-src-block) (keyword .
org-hugo-keyword) (link . org-hugo-link) (paragraph .
org-hugo-paragraph) (src-block . org-hugo-src-block) (special-block .
org-hugo-special-block)) :options ((:with-toc nil "toc"
org-hugo-export-with-toc) (:section-numbers nil "num"
org-hugo-export-with-section-numbers) (:author "AUTHOR" nil
user-full-name newline) (:creator "CREATOR" nil
org-hugo-export-creator-string) (:with-smart-quotes nil "'" nil)
(:with-special-strings nil "-" nil) (:with-sub-superscript nil "^"
...) (:hugo-with-locale "HUGO_WITH_LOCALE" nil nil)
(:hugo-front-matter-format "HUGO_FRONT_MATTER_FORMAT" nil
org-hugo-front-matter-format) (:hugo-level-offset "HUGO_LEVEL_OFFSET"
nil "1") (:hugo-preserve-filling "HUGO_PRESERVE_FILLING" nil
org-hugo-preserve-filling) (:hugo-delete-trailing-ws
"HUGO_DELETE_TRAILING_WS" nil org-hugo-delete-trailing-ws)
(:hugo-section "HUGO_SECTION" nil org-hugo-section) (:hugo-bundle
"HUGO_BUNDLE" nil nil) (:hugo-base-dir "HUGO_BASE_DIR" nil
org-hugo-base-dir) (:hugo-goldmark "HUGO_GOLDMARK" nil
org-hugo-goldmark) (:hugo-code-fence "HUGO_CODE_FENCE" nil t)
(:hugo-use-code-for-kbd "HUGO_USE_CODE_FOR_KBD" nil
org-hugo-use-code-for-kbd) (:hugo-prefer-hyphen-in-tags
"HUGO_PREFER_HYPHEN_IN_TAGS" nil org-hugo-prefer-hyphen-in-tags)
(:hugo-allow-spaces-in-tags "HUGO_ALLOW_SPACES_IN_TAGS" nil
org-hugo-allow-spaces-in-tags) (:hugo-auto-set-lastmod
"HUGO_AUTO_SET_LASTMOD" nil org-hugo-auto-set-lastmod)
(:hugo-custom-front-matter "HUGO_CUSTOM_FRONT_MATTER" nil nil space)
(:hugo-blackfriday "HUGO_BLACKFRIDAY" nil nil space)
(:hugo-front-matter-key-replace "HUGO_FRONT_MATTER_KEY_REPLACE" nil
nil space) (:hugo-date-format "HUGO_DATE_FORMAT" nil
org-hugo-date-format) (:hugo-paired-shortcodes
"HUGO_PAIRED_SHORTCODES" nil org-hugo-paired-shortcodes space)
(:hugo-pandoc-citations "HUGO_PANDOC_CITATIONS" nil nil)
(:bibliography "BIBLIOGRAPHY" nil nil newline) (:html-container
"HTML_CONTAINER" nil org-hugo-container-element)
(:html-container-class "HTML_CONTAINER_CLASS" nil "") (:hugo-aliases
"HUGO_ALIASES" nil nil space) (:hugo-audio "HUGO_AUDIO" nil nil) ...)
:filters ((:filter-body . org-hugo-body-filter)) :blocks nil :menu (72
"Export to Hugo-compatible Markdo..." (... ... ... ... ... ...)))
:translate-alist ((code . org-hugo-kbd-tags-maybe) (example-block .
org-hugo-example-block) (export-block . org-hugo-export-block)
(export-snippet . org-hugo-export-snippet) (headline .
org-hugo-heading) (inner-template . org-hugo-inner-template)
(inline-src-block . org-hugo-inline-src-block) (keyword .
org-hugo-keyword) (link . org-hugo-link) (paragraph .
org-hugo-paragraph) (src-block . org-hugo-src-block) (special-block .
org-hugo-special-block) (center-block . org-blackfriday-center-block)
(example-block . org-blackfriday-example-block) (fixed-width .
org-blackfriday-fixed-width) (footnote-reference .
org-blackfriday-footnote-reference) (inner-template .
org-blackfriday-inner-template) (italic . org-blackfriday-italic)
(item . org-blackfriday-item) (latex-environment .
org-blackfriday-latex-environment) (latex-fragment .
org-blackfriday-latex-fragment) (line-break . org-html-line-break)
(plain-list . org-blackfriday-plain-list) (plain-text .
org-blackfriday-plain-text) (quote-block .
org-blackfriday-quote-block) (radio-target .
org-blackfriday-radio-target) (special-block .
org-blackfriday-special-block) (src-block . org-blackfriday-src-block)
(strike-through . org-blackfriday-strike-through) (table-cell .
org-blackfriday-table-cell) (table-row . org-blackfriday-table-row)
(table . org-blackfriday-table) ...) :exported-data # :input-buffer "*Ox-hugo Pre-processed all-posts..."
:input-file "/home/runner/work/ox-hugo/ox-hug..." :with-toc nil
:section-numbers nil :author "" :creator "Emacs + Org mode + ox-hugo"
:with-smart-quotes nil :with-special-strings nil :with-sub-superscript
{} :hugo-with-locale nil :hugo-front-matter-format "toml"
:hugo-level-offset "1" ...))
  org-cite-basic--print-entry(nil nil (:export-options (subtree)
:back-end #s(org-export-backend :name hugo :parent blackfriday
:transcoders ((code . org-hugo-kbd-tags-maybe) (example-block .
org-hugo-example-block) (export-block . 

Re: [BUG] org-fold-core-style 'text-properties interprets Org link syntax in code blocks too

[Kaushal Modi]

On Thu, Apr 28, 2022 at 10:44 AM Ihor Radchenko  wrote:

> I am not going to fix this just yet unless it is critical. It does not
> look like this bug is common.

It's not time-critical, but it would be good to fix this bug. It's not
just the Org link syntax.. any Org markup is fontified inside the src
blocks. Here's a screenshot (attached) that shows the bold
fortification happen in the src block as well.

> This and other fontification issues will be solved by new parser-based
> fontification engine I am working on now.

If it is planned to be fixed before the next major release of Org,
it's OK. Thanks for working on this!

[BUG] org-fold-core-style 'text-properties interprets Org link syntax in code blocks too

[Kaushal Modi]

Hello,

With the default value of the new org-fold-core-style, if I have a
snippet like below:

#+begin_src toml
[[asdf]]
#+end_src

The brackets around asdf get hidden. ([[asdf]] is TOML syntax for maps
or array of tables: https://toml.io/en/v1.0.0#array-of-tables)

If I change org-fold-core-style to overlays, and refresh that Org
buffer, I see the square brackets around asdf in the src block (as
expected).

Org mode version 9.5.3 (release_9.5.3-458-g1ed9e4)

--
Kaushal Modi

Difference seen in org-version strings when built from git

[Kaushal Modi]

On Fri, Dec 17, 2021 at 11:34 PM Ihor Radchenko  wrote:
>
> Kaushal Modi  writes:
>
> > I actually run a wrapper script to update Org and that has all that:
> > ...
> > I verified that at least the git hash was latest as of then:
> > release_9.5-364-g*de022e*
>
> Odd. Though the commit number is indeed correct.

I figured out this mystery ..

>From the org-fixup function in mk/org-fixup.el, I saw that the "git
describe .." command is used to derive the Org version with git hash.
That bakes in the last tag + number of commits seen since that tag in
the org-version returned string.

Turns out that I was simply doing a pull of the main branch and
building Org all this time. I wasn't fetching all the tags!

I saw the version as "release_9.5-364-gde022e". That meant that
"release_9.5" happened to be the last fetched tag in my local repo
back then.

Fix was simple.. I had to do "git fetch --all" before building Org.

[PATCH] Fix inf-loop due to org-eldoc when point is in an org src block

[Kaushal Modi]

Hello all,

The patches attached in this email fix the issue reported in
https://lists.gnu.org/r/emacs-orgmode/2022-04/msg00373.html. They are
based off the master branch of https://git.sr.ht/~bzg/org-contrib.

patch 1: Minor cleanup in the function that I am touching for the fix
in patch 2: re-indent, untabify
patch 2: Fix for the inf-loop

Can someone please review and apply these patches to the org-contrib repo?
[I am unable to commit using ssh/git: protocol (only https is allowed)
based on the network restrictions at work.]

Thanks!

--
Kaushal Modi


0001-lisp-org-eldoc.el-Whitespace-change.patch
Description: Binary data


0002-lisp-org-eldoc.el-Fix-inf-loop-when-point-in-org-src.patch
Description: Binary data

[BUG] org-eldoc inf-loops when point is in an org src block

[Kaushal Modi]

c-print-current-symbol-info ((string= lang "css")
(if (require 'css-eldoc nil t) (progn (css-eldoc-function
((string= lang "php") (if (require 'php-eldoc nil t) (progn
(php-eldoc-function ((or (string= lang "go") (string= lang
"golang")) (if (require 'go-eldoc nil t) (progn
(go-eldoc--documentation-function (t (let ((doc-fun
(org-eldoc-get-mode-local-documentation-function lang)) (callback (car
args))) (if (functionp doc-fun) (progn (if (functionp callback)
(funcall doc-fun callback) (funcall doc-fun)))
  (let ((lang (org-eldoc-get-src-lang))) (cond ((or (string= lang
"emacs-lisp") (string= lang "elisp")) (cond ((and (boundp
'eldoc-documentation-functions) (fboundp 'elisp-eldoc-var-docstring)
(fboundp 'elisp-eldoc-funcall)) (let ((eldoc-documentation-functions
...)) (eldoc-print-current-symbol-info))) ((fboundp
'elisp-eldoc-documentation-function)
(elisp-eldoc-documentation-function)) (t (let
(eldoc-documentation-function) (eldoc-print-current-symbol-info)
((or (string= lang "c") (string= lang "C")) (if (require 'c-eldoc nil
t) (progn (c-eldoc-print-current-symbol-info ((string= lang "css")
(if (require 'css-eldoc nil t) (progn (css-eldoc-function
((string= lang "php") (if (require 'php-eldoc nil t) (progn
(php-eldoc-function ((or (string= lang "go") (string= lang
"golang")) (if (require 'go-eldoc nil t) (progn
(go-eldoc--documentation-function (t (let ((doc-fun
(org-eldoc-get-mode-local-documentation-function lang)) (callback (car
args))) (if (functionp doc-fun) (progn (if (functionp callback)
(funcall doc-fun callback) (funcall doc-fun
  (or (org-eldoc-get-breadcrumb) (org-eldoc-get-src-header) (let
((lang (org-eldoc-get-src-lang))) (cond ((or (string= lang
"emacs-lisp") (string= lang "elisp")) (cond ((and (boundp ...)
(fboundp ...) (fboundp ...)) (let (...)
(eldoc-print-current-symbol-info))) ((fboundp
'elisp-eldoc-documentation-function)
(elisp-eldoc-documentation-function)) (t (let
(eldoc-documentation-function) (eldoc-print-current-symbol-info)
((or (string= lang "c") (string= lang "C")) (if (require 'c-eldoc nil
t) (progn (c-eldoc-print-current-symbol-info ((string= lang "css")
(if (require 'css-eldoc nil t) (progn (css-eldoc-function
((string= lang "php") (if (require 'php-eldoc nil t) (progn
(php-eldoc-function ((or (string= lang "go") (string= lang
"golang")) (if (require 'go-eldoc nil t) (progn
(go-eldoc--documentation-function (t (let ((doc-fun
(org-eldoc-get-mode-local-documentation-function lang)) (callback (car
args))) (if (functionp doc-fun) (progn (if ... ... ...
  org-eldoc-documentation-function(#f(compiled-function (string 
plist) #))
=


Recipe to create this error:
1. Create a file test.org with these contents:

#+begin_src org
,#+html: foo
#+end_src

2. emacs -Q
3. Load/evaluate org-eldoc.el from
https://git.sr.ht/~bzg/org-contrib/tree/master/item/lisp/org-eldoc.el
4. Open the test.org file and place the point *inside* the org src block
5. eldoc error: (error Lisp nesting exceeds ‘max-lisp-eval-depth’)

-

Upon inspecting the `org-eldoc-documentation-function` function, I
don't see a reason why the control should enter the default of `t'
case if the src lang is "org". Just returning with nil works for me if
the lang is "org". I will send a patch for this in a follow-up email.

--
Kaushal Modi

Re: What's the flow for adding info: links in Org documents?

[Kaushal Modi]

On Wed, Apr 13, 2022 at 7:38 AM Max Nikulin  wrote:
>
> On 13/04/2022 01:26, Kaushal Modi wrote:
> > On Mon, Apr 11, 2022 at 10:57 AM Max Nikulin wrote:
> >
> >> There are a some problems with info links outside of Emacs:
> >> - Export to PDF
> >
> > Yeah, I recently realized that I will need to add custom support for
> > exporting info: links using ox-hugo. I made a small blog post out of
> > this learning: https://scripter.co/linking-and-exporting-org-info-links/.
>
> I would prefer
>  info "(org) Top"
> to
>  Org Info: Top
> since the former may be pasted to M-x : or to shell command prompt. And
> the link target ideally should be https://orgmode.org/manual/index.html
> Unfortunately there is no way to customize mapping of documents.
>
> >> - Links to single page manuals as the result of export to HTML. E.g.
> >> Emacs manual is really huge
> >
> > I did not understand this. The HTML exports convert an Info node to a
> > hyperlink of the same manual page online.
>
> For  export to html produces the following link:
> https://www.gnu.org/software/emacs/manual/html_mono/emacs.html#Browse_002dURL
> I think, a better variant is
> https://www.gnu.org/software/emacs/manual/html_node/emacs/Browse_002dURL.html
> even though for the Org manual I often prefer single-page HTML version.

Thanks for your feedback! I absorbed almost all of it into ox-hugo and
wrote about it in a followup blog post:
https://scripter.co/improving-ox-hugo-exported-org-info-links/.

You'll see the update info: link examples on that post.

Re: What's the flow for adding info: links in Org documents?

[Kaushal Modi]

On Mon, Apr 11, 2022 at 10:57 AM Max Nikulin  wrote:

> There are a some problems with info links outside of Emacs:
> - Export to PDF

Yeah, I recently realized that I will need to add custom support for
exporting info: links using ox-hugo. I made a small blog post out of
this learning: https://scripter.co/linking-and-exporting-org-info-links/.

> - Links to single page manuals as the result of export to HTML. E.g.
> Emacs manual is really huge

I did not understand this. The HTML exports convert an Info node to a
hyperlink of the same manual page online.

> - info: is a registered scheme, but not for texinfo.
>https://www.rfc-editor.org/rfc/rfc4452.html
>RFC 4452 - The "info" URI Scheme for Information Assets

Re: #+latex_header blocks, or, managing lots of LaTeX headers

[Kaushal Modi]

On Mon, Apr 11, 2022 at 10:53 PM Vikas Rawal  wrote:
>
> For a major project like this, I would just put these in a separate file, and 
> include it using #+INCLUDE:

Org has a special keyword for the purpose of including *just the setup
stuff*: #+setupfile

See (org) Export Settings.

#+include is useful when you want to include setup stuff mixed with Org content.

#+setupfile will include only the setup stuff. I think that would mean
only the Org keywords (lines beginning with #+) will be imported.
Additionally, #+setupfile keyword can accept either a file path or a
web URL.

So I have this at the top of many of my Org files:

#+setupfile: 
https://cdn.rawgit.com/kaushalmodi/.emacs.d/master/misc/org-setupfile.org

That file has my common setup stuff like LaTeX headers, Org macros, etc.

Re: What's the flow for adding info: links in Org documents?

[Kaushal Modi]

On Mon, Apr 11, 2022 at 8:35 AM Kaushal Modi  wrote:

> I believe I am missing out something basic with inserting info: links
> in Org documents.

Yes, I was missing out on something :)

To my future self:

1. When in Info buffer, do M-x org-store-link (typically a user binds
this to C-c l: https://orgmode.org/manual/Activation.html ). The link
gets copied in the [[info:MANUAL#NODE]] format.
2. In Org buffer, do C-c C-l to insert that last stored link.

What's the flow for adding info: links in Org documents?

[Kaushal Modi]

Hello all,

I believe I am missing out something basic with inserting info: links
in Org documents.

The info links look like:

[[info:org#External links]]

But if I am on that Info node and I hit `w' to copy the node
reference, this gets copied: "(org) External Links"

So when I insert a link in Org, it goes like this:

1. Type "[[info:"
2. Paste the Info node ref, so that I get "[[info:(org) External Links"
3. Refactor that to make it parseable by ol-info: "[[info:org#External Links]]"

I can locally advice the `org-info-export' so that "[[info:(org)
External Links]]" would work as well. But I think I am missing out on
some flow that would make the above manually editing in step 3
unnecessary.

How do you insert info: links efficiently?

--
Kaushal Modi

Re: How to handle strings with commas in macros?

[Kaushal Modi]

On Thu, Apr 7, 2022 at 12:30 PM William Denton  wrote:

> I'm using macros to format names in a LaTeX export, like so:
>
> on export and LaTeX will format it.  That works fine.  But in an index of
> names,
> if I want
>
> {{{m(Denton, William)}}}
>
> then Org takes that as two arguments to the macro, and outputs
>
> \m{Denton}
>
> Is there a way to get around this?
>

The comma needs to be backslash escaped.

{{{m(Denton\, William)}}}

Ref: (org) Macro Replacement

> (1) Since commas separate the arguments, commas within arguments have
to be escaped with the backslash character.  So only those backslash
characters before a comma need escaping with another backslash
character.

Re: Multiline list entries / Is auto-fill-mode in org(roam) usual?

[Kaushal Modi]

On Mon, Apr 4, 2022 at 10:34 AM  wrote:

>
> I would like to know why does a list need 2 blank lines instead of 1?
> For what reason exists this rule?
>

- 1 blank line in a list item with create a paragraph break as I showed in
my example earlier. It will not end the list item or list.
- So we need 2 blank lines if we mean to end the list.


Example:

- list 1 item 1

  second paragraph in list 1 item 1
- list 1 item 2


- list 2 item 1 because there are 2 blank lines before this item.

Re: Multiline list entries / Is auto-fill-mode in org(roam) usual?

[Kaushal Modi]

On Mon, Apr 4, 2022, 12:06 AM Ihor Radchenko  wrote:

>
> I think your examples are a bit misleading.


I have the indentations correct in my three examples.

A list item continues until
> there are _2_ blank lines or until the subsequent line is not indented >=
> current list item indentation:
>

The whole list ends after 2 blank lines. But I didn't demonstrate this rule
in my examples. I was just focusing on plain single new line char vs a
blank line (2 consecutive newlines) in my examples.

1. list item 1
> not a list item because it not indented
> 2. completely new list
>
> Also,
>
> 1. list item 1
>
>Still a list item - new paragraph inside the list
>
>
>Indented, but not a list item because there are two blank lines above
>
> Everything is described in the manual. See
> https://orgmode.org/manual/Plain-Lists.html#Plain-Lists


+1

>
>

Re: Multiline list entries / Is auto-fill-mode in org(roam) usual?

[Kaushal Modi]

On Sun, Apr 3, 2022, 4:29 PM  wrote:

> Hello togehter,
>
> is it usual to have auto-fill-mode (automatic new-line after n
> characters) turned on in org or org-roam (including fill-column set e.g.
> to 80)?
>

I cannot comment on that. Enabling auto-fill-mode is user preference.

Or let me ask from another point of view: Is it usual to have multiline
> list entries?
>

Yes, if auto-fill-mode is enabled in org-mode.

I know that org is not markdown but I tried some markdown editors to
> test it. They still recognize the linebreak in my first example and
> rendered it "correct" as a 3 item list.
> I checked the syntax docu [1] about it but I couldn't find a hint or
> didn't understand.
>
> Do I understand it correct that the end of a list is marked by an empty
> line?
>

Yes. I think that the list items follow the same rules as Paragraphs [1]
i.e. A list item continues until it sees a blank line. This is identical to
Markdown.

Below, you have 2 list items:

- item 1
- item 2

Below is also 2 list items:

- item 1
  item 1 continued
- item 2

Below is also 2 list items, but the first item has 2 paragraphs:

- item 1

  second paragraph in item 1
- item 2

I hope that helps.

[1]: https://orgmode.org/manual/Paragraphs.html#Paragraphs

Re: Inline src block element not parsed correctly for export when in a list item

[Kaushal Modi]

Hello,

Just pinging here again. Can someone confirm this bug?

--
Kaushal Modi

On Tue, Mar 1, 2022, 10:10 PM Kaushal Modi  wrote:

> Hello,
>
> I believe I have come across a corner case issue where the inline src
> block element doesn't get parsed as one, if:
>
> 1. That src block is in a list item (plain list, definition list, etc.),
> AND
> 2. That src block wraps around when auto-filling.
>
> This issue can be reproduced on the main branch:
>
> Org mode version 9.5 (release_9.5-505-gef666)
>
> MWE:
>
> =
> #+author:
> #+options: toc:nil
>
> Run ~C-c C-e t A~.
>
> * Doesn't export correctly if inline src block is in a wrapped list
> - abcdefg abcdefg abcdefg abcdefg src_org[:exports code]{[[abc
>   def][bar]]}.
> * Exports correctly
> ** .. if the inline src block wraps in a paragraph
> abcdefg abcdefg abcdefg abcdefg src_org[:exports code]{[[abc
> def][bar]]}.
> ** .. if the inline src block is in a list but doesn't wrap
> - abcdefg abcdefg abcdefg abcdefg src_org[:exports code]{[[abc def][bar]]}.
> =
>
> Upon pasting the above snippet in an Org buffer and running `C-c C-e t
> A`, I get:
>
> =
> Run `C-c C-e t A'.
>
>
> 1 Doesn't export correctly if inline src block is in a wrapped list
> ===
>
>   - abcdefg abcdefg abcdefg abcdefg src_org[:exports code]{[[abc
>   def][bar]]}.
>
>
> 2 Exports correctly
> 
>
> 2.1 .. if the inline src block wraps in a paragraph
> ~~~
>
>   abcdefg abcdefg abcdefg abcdefg `[[abc def][bar]]'.
>
>
> 2.2 .. if the inline src block is in a list but doesn't wrap
> 
>
>   - abcdefg abcdefg abcdefg abcdefg `[[abc def][bar]]'.
> =
>
>
> Note that incorrect export of the inline src block in section 1 above.
> The remaining sections exports correctly because either the inline src
> block is not in a list item, or it doesn't wrap to the next line.
>
> --
> Kaushal Modi
>

Possible bug in `org-subtree--get-subtree-options`?

[Kaushal Modi]

Hello Nicolas,

Today I was debugging something where a subtree export wasn't recognizing
the EXPORT_OPTIONS property set in that subtree.

MWE:

=
* Top level
** Allow broken links, but mark them
:PROPERTIES:
:EXPORT_FILE_NAME: allow-broken-links-but-mark-them
:EXPORT_OPTIONS: broken-links:mark
:END:
=

1. Move cursor to BOL of "** Allow broken links, but mark them" line.
2. M-: (org-export--get-subtree-options)

Output:

(:title (#("Top level" 0 9 (:parent #1

Issue: Point is already on a heading, but it is jumping to the parent
heading and returning that heading's properties.

Debugging through how the export options got parsed in subtree exports, I
reached the `org-export--get-subtree-options' function and this line in
there:

;;
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/tree/lisp/ox.el#n1425
(if (org-at-heading-p) (org-up-heading-safe) (org-back-to-heading t))

It looks like the if condition actions are swapped here.

Should it be:

(if (org-at-heading-p) (org-back-to-heading t) (org-up-heading-safe))
;; If point is in a heading, just go to the BOL  (org-back-to-heading t)
;; Otherwise, jump up to a parent-heading if available.

If I evaluate that function after updating that if condition as above and
redo the steps I mentioned above, the output is now what I expect:

(:with-broken-links mark :title (#("Allow broken links, but mark them" 0 33
(:parent #1

I am only surprised that this line has been there at least since 2015.

Thanks!

--
Kaushal Modi

Re: Code blocks and quotes export style

[Kaushal Modi]

On Sun, Mar 13, 2022, 6:55 AM Sébastien Gendre  wrote:

> Hello everyone. _o/
>
> When I export an Org file to LaTeX and finally PDF, the code blocks and
> quotes often exceed the width of the page.
>

Hello _o/

I fixed[1] that problem by using the LaTeX minted package that allows
wrapping around the lines using its "breaklines" option.

Well, that will at least help the code blocks going out of bounds. It won't
help the quotes.

Note that I added that to my Org mode config more than 6 years back or
something. So there might be a better way to do the same but that setup
still works! :)

[1]:
https://github.com/kaushalmodi/.emacs.d/blob/c643684ad675753c69df602d7298241d05173255/setup-files/setup-org.el#L941-L972

>

Re: Unable to resolve link; aborting: "roam:git"

[Kaushal Modi]

On Sun, Mar 13, 2022, 8:23 AM  wrote:

> In real I (try to) use ox-hug to export my org-files (org-roam-v2) to
> markdown (and later to HTML).
>
> After analyzing the my debug output [1] the ox-hugo people pointed me to
> org-roam community because the error is "thrown" (correct term in
> emas-lisp=?) by "org-export-resolve-fuzzy-link".
>

After revisiting this, I believe, this is something that needs to be fixed
in ox-hugo as it is calling org-export-resolve-fuzzy-link directly without
handling the broken link error.

I'll try to fix it in the next week.

>

Re: org-roam to HTML: My needs are unusual?

[Kaushal Modi]

Hello Christian,

tl;dr: If you decide to learn how to use Hugo (read its docs, ask questions
on its forum, etc.), this[1] should solve the issues you have faced so far.

---

Details:

On Fri, Mar 11, 2022 at 7:04 AM  wrote:

>
> ox-hugo with hugo is often mentioned in the context. But ox-hugo is not
> able to export everything out-of-the-box [2].
> [2] -- 


Correct, because it is not the job of `ox-hugo` to figure out how the user
needs to export all the Org files. I see users coming with various
use-cases; it is out of scope of my free time to attempt to support all of
that in the ox-hugo package:

- How to export only the Org files that already have the Markdown exported?
- How to export Org files written for  package?
- This didn't work on Windows.
- etc.

So I encourage the users to attempt to learn a bit of elisp or Makefile or
bash to do this batch exporting for them. I have posted one solution to
this here[4], but I won't be surprised if this solution is not exactly what
someone wants (for example, that solution does not update the org-id
locations from everywhere a user has their Org files).


And the HTML files
> generated by hugo are not usable via the file:// protocol without some
> hacks [3].
> [3] -- 
>

Those are not hacks; those are Hugo switches a user can use to generate the
kind of HTML they need (with or without ugly URLs, with or without relative
URLs, with or without RSS, so on and so forth).

[1]:
https://github.com/kaushalmodi/ox-hugo/discussions/585#discussioncomment-2339756
[4]:
https://github.com/kaushalmodi/ox-hugo/discussions/585#discussioncomment-2335203

Inline src block element not parsed correctly for export when in a list item

[Kaushal Modi]

Hello,

I believe I have come across a corner case issue where the inline src
block element doesn't get parsed as one, if:

1. That src block is in a list item (plain list, definition list, etc.), AND
2. That src block wraps around when auto-filling.

This issue can be reproduced on the main branch:

Org mode version 9.5 (release_9.5-505-gef666)

MWE:

=
#+author:
#+options: toc:nil

Run ~C-c C-e t A~.

* Doesn't export correctly if inline src block is in a wrapped list
- abcdefg abcdefg abcdefg abcdefg src_org[:exports code]{[[abc
  def][bar]]}.
* Exports correctly
** .. if the inline src block wraps in a paragraph
abcdefg abcdefg abcdefg abcdefg src_org[:exports code]{[[abc
def][bar]]}.
** .. if the inline src block is in a list but doesn't wrap
- abcdefg abcdefg abcdefg abcdefg src_org[:exports code]{[[abc def][bar]]}.
=

Upon pasting the above snippet in an Org buffer and running `C-c C-e t
A`, I get:

=
Run `C-c C-e t A'.


1 Doesn't export correctly if inline src block is in a wrapped list
===

  - abcdefg abcdefg abcdefg abcdefg src_org[:exports code]{[[abc
  def][bar]]}.


2 Exports correctly


2.1 .. if the inline src block wraps in a paragraph
~~~

  abcdefg abcdefg abcdefg abcdefg `[[abc def][bar]]'.


2.2 .. if the inline src block is in a list but doesn't wrap


  - abcdefg abcdefg abcdefg abcdefg `[[abc def][bar]]'.
=


Note that incorrect export of the inline src block in section 1 above.
The remaining sections exports correctly because either the inline src
block is not in a list item, or it doesn't wrap to the next line.

--
Kaushal Modi

Re: Inconsistent handling of multi-line properties

[Kaushal Modi]

On Mon, Feb 28, 2022 at 3:34 PM Kaushal Modi  wrote:
>
> On Sat, Oct 2, 2021 at 11:03 AM Hanno Perrey  wrote:
> >
> > Hej,
> >
> > I have noticed that properties that stretch over multiple lines using
> > the :value+: syntax are ignored by org-element-property and therefore
> > also by e.g. org-export-get-node-property when exporting to ics via
> > ox-icalendar.el (see example below). I was wondering now whether this is
> > intentional and to be expected or a bug?
>
> I use the :value+: syntax for the subtree properties regularly. For
> exports, though, you need to prefix the properties with EXPORT_.
>
> See the (org) Export Settings node in Org manual.
>
> > When exporting sub-trees, special node properties can override the
> above keywords.  These properties have an ‘EXPORT_’ prefix.  For
> example, ‘DATE’ becomes, ‘EXPORT_DATE’ when used for a specific
> sub-tree.  Except for ‘SETUPFILE’, all other keywords listed above have
> an ‘EXPORT_’ equivalent.

Sorry, ignore my email noise. I had never tried ox-icalendar before.
But I just tried it with your test snippet and it doesn't work as
expected even with the EXPORT_ prefix.

Also, I don't see any location info get exported to the .ics file
(with or without the EXPORT_ prefix). So I don't know what I should
expect to see in the .ics file.

Re: Inconsistent handling of multi-line properties

[Kaushal Modi]

On Sat, Oct 2, 2021 at 11:03 AM Hanno Perrey  wrote:
>
> Hej,
>
> I have noticed that properties that stretch over multiple lines using
> the :value+: syntax are ignored by org-element-property and therefore
> also by e.g. org-export-get-node-property when exporting to ics via
> ox-icalendar.el (see example below). I was wondering now whether this is
> intentional and to be expected or a bug?

I use the :value+: syntax for the subtree properties regularly. For
exports, though, you need to prefix the properties with EXPORT_.

See the (org) Export Settings node in Org manual.

> When exporting sub-trees, special node properties can override the
above keywords.  These properties have an ‘EXPORT_’ prefix.  For
example, ‘DATE’ becomes, ‘EXPORT_DATE’ when used for a specific
sub-tree.  Except for ‘SETUPFILE’, all other keywords listed above have
an ‘EXPORT_’ equivalent.

Here's one of the pathogenic test cases of ox-hugo:

=
** Custom front matter in multiple lines
:PROPERTIES:
:EXPORT_FILE_NAME: custom-front-matter-multiple-lines
:EXPORT_DATE: 2017-07-24
:EXPORT_HUGO_CUSTOM_FRONT_MATTER: :foo bar
:EXPORT_HUGO_CUSTOM_FRONT_MATTER+: :baz zoo
:EXPORT_HUGO_CUSTOM_FRONT_MATTER+: :alpha 1
:EXPORT_HUGO_CUSTOM_FRONT_MATTER+: :beta "two words"
:EXPORT_HUGO_CUSTOM_FRONT_MATTER+: :gamma 10
:EXPORT_HUGO_CUSTOM_FRONT_MATTER+: :empty_string ""
:END:
=

All the HUGO_CUSTOM_FRONT_MATTER properties get collected as expected.

Here's another example:

=
#+author:
#+options: toc:nil
* Heading
:PROPERTIES:
:EXPORT_AUTHOR: abc def
:EXPORT_AUTHOR+: ghi jkl
:EXPORT_AUTHOR+: kmo pqr
:END:
=

C-c C-e C-s t A exports to:

=
   _

HEADING

abc def ghi jkl kmo pqr
   _


=

Re: Org mode profiling meetup on Sat, Feb 26 (was: profiling latency in large org-mode buffers (under both main & org-fold feature))

[Kaushal Modi]

On Wed, Feb 23, 2022 at 7:37 AM Ihor Radchenko  wrote:
>
> Dear all,
>
> Since there is at least a couple of people who might be interested, lets
> try to meet online on jitsi and debug performance issues you experience
> because of Org mode. Probably some time this Saturday (Feb 26). I am
> thinking about 9pm SG time (4pm Moscow; 8am New York; 1pm London). WDYT?

That time will work for me. Thanks!

Re: profiling latency in large org-mode buffers (under both main & org-fold feature)

[Kaushal Modi]

On Tue, Feb 22, 2022, 12:34 AM Ihor Radchenko  wrote:

>
> I am wondering if many people in the list experience latency issues.
> Maybe we can organise an online meeting (jitsi or BBB) and collect the
> common causes/ do online interactive debugging?
>

+1

I have seen few people see this issue on the ox-hugo issue tracker:
https://github.com/kaushalmodi/ox-hugo/discussions/551#discussioncomment-2104352

Re: [PATCH] c-csl : accept relative CSL filenames

[Kaushal Modi]

> It is already in the main branch, AFAIU. I assume you mean it should be
> back-ported to bugfix branch. If that's the case, I don't know. This is
> a new feature, and not a critical one: there are workarounds, as you
> found out.

Yes, sorry, I meant the bugfix branch.

> This should be available when Org 9.6 is released. I don't know when
> that will happen.

OK. It's not urgent. I can wait.

> I don't think Glenn Morris suggests using #'string-or-null-p, which
> would contradict his statement. He is pointing out that ":safe
> #'string-or-null-p" is better than ":safe t", even though but allowing
> arbitrary locations (strings in this case) is not safe anyway.

OK, I thought he referred to ":safe t" equivalent to any arbitrary
location. I don't understand how ":safe
#'string-or-null-p" can be potentially unsafe. So I will go by your judgment.

So, no action needed. Thanks! :)

Re: [PATCH] c-csl : accept relative CSL filenames

[Kaushal Modi]

Hello Nicolas,

> Since you are probably busy, I implemented this on your behalf. The new
> behaviour is in main branch. Thank you.
>

Can this commit[1] be merged into the main branch. Locally on my
machine, I use org built from main and something like this was working
fine:

#+cite_export: csl cite/csl/ieee.csl

Here, "csl cite/csl/ieee.csl" is the csl path relative to the Org file.

But when the same ran on a CI where the stable Org version is used, it
failed with this error:

> Debugger entered--Lisp error: (user-error "Cannot handle relative style file 
> name: "cite/csl/...")
> signal(user-error ("Cannot handle relative style file name: "cite/csl/..."))
> user-error("Cannot handle relative style file name: %S" "cite/csl/ieee.csl")

I believe the behavior I see with this commit on main branch is kind
of obvious and it should prevent this surprise failure for other users
too.

This is my current workaround for the Org stable version:

#+cite_export: csl ieee.csl

# Local Variables:
# org-cite-csl-styles-dir: "./cite/csl/"
# End:

This works for both main and bugfix, but while doing this, I realized
that even string values are not considered safe for this variable.

Looking through git revisions, I found
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=41e67cff0d3bf27ffb57f9a230598b0385341517.

Earlier `:safe t' was added for `org-cite-csl-styles-dir'. Instead can
we have `:safe #'string-or-null-p' as suggested by Glenn Morris in
that commit?

Thanks!




[1]: 
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=c6186be3fd6c09a6deaa4edc1fbabbad0cb986d3

Re: Bug with exporting list with link item containing "::" to markdown

[Kaushal Modi]

On Sun, Feb 13, 2022, 4:18 AM Jeremie Juste  wrote:

> Hello Cash,
>
> Many thanks for reporting but I cannot reproduce the error with my current
> version of emacs and org-mode. Could you specify the version of org-mode
> and emacs you are currently using?
>
> * test
> :PROPERTIES:
> :ID:   cbce567a-861c-4d9b-8b2f-5933afadb864
> :END:
>
> [[id:cbce567a-861c-4d9b-8b2f-5933afadb864][ryans01 :: No Zero Days]]
>

I haven't tried this yet (away from computer), but I think you would need a
hyphen before that line with :: to make it a list item. The :: in the link
description then probably gets perceived as the :: marker for descriptive
lists.

So try:

- [[id:cbce567a-861c-4d9b-8b2f-5933afadb864][ryans01 :: No Zero Days]]

>

org-element persist logic hangs when quitting emacs

[Kaushal Modi]

Hello,

Lately (at least as of last 3 days), I have seen that when I try to
quit emacs, it gets stuck on one of my Org files; it's a personal
journal.org that I frequently update using org-capture. So that file
is usually open in one of the buffers.

Today I did M-x toggle-debug-on-quit and tried to quit emacs. When it
got stuck, I hit C-g and I saw this backtrace:

=
Debugger entered--Lisp error: (quit)
  org-get-limited-outline-regexp()
  org-element--current-element(567757 element nil nil)
  org-element--parse-to(567811)
  org-element-at-point(567811)
  org-element--cache-persist-before-write(org-element--cache #)
  run-hook-with-args-until-success(org-element--cache-persist-before-write
org-element--cache #)
  #f(compiled-function (v) #)(org-element--cache)
  #f(compiled-function (elt) #)(org-element--cache)
  mapc(#f(compiled-function (elt) #)
(org-element--headline-cache org-element--cache))
  seq-do(#f(compiled-function (elt) #)
(org-element--headline-cache org-element--cache))
  seq-find(#f(compiled-function (v) #)
(org-element--headline-cache org-element--cache))
  org-persist-write((org-element--headline-cache org-element--cache)
#)
  org-persist-write-all()
  #f(compiled-function (fun) #)(org-persist-write-all)
  run-hook-wrapped(#f(compiled-function (fun) #) org-persist-write-all)
  run-hook-query-error-with-timeout(kill-emacs-hook)
  kill-emacs()
  save-buffers-kill-emacs()
  (if (daemonp) (save-buffers-kill-emacs) (save-buffers-kill-terminal))
  modi/quit-emacs(nil)
  funcall-interactively(modi/quit-emacs nil)
  call-interactively(modi/quit-emacs nil nil)
  command-execute(modi/quit-emacs)
=


I had also enabled the profiler. The profiler report showed this:

=
   14247  92% - command-execute
   14247  92%  - call-interactively
   14247  92%   - funcall-interactively
   13973  91%- modi/quit-emacs
   13973  91% - if
   13939  90%  - save-buffers-kill-emacs
   13834  90%   - kill-emacs
   13834  90%- run-hook-query-error-with-timeout
   13834  90% - run-hook-wrapped
   13834  90%  - #
   13724  89%   - org-persist-write-all
   13715  89%- org-persist-write
   13698  89% - seq-find
   13698  89%  - seq-do
   13698  89%   - mapc
   13698  89%- #
   13698  89% - #
   13698  89%  - run-hook-with-args-until-success
   13698  89%   - org-element--cache-persist-before-write
   13698  89%- org-element-at-point
   13244  86% - org-element--parse-to
6568  42%  + org-element--current-element
2649  17%  + org-element--cache-put
=


I was able to quit emacs once I disabled the cache feature by setting
org-element-use-cache to nil.

---

- Org mode version 9.5 (release_9.5-428-g26dece)
- Emacs version: GNU Emacs 28.0.91 (build 7, x86_64-pc-linux-gnu, GTK+
Version 3.22.30, cairo version 1.15.12) of 2022-01-25, built using
commit 7eca80b20444f7bd7bcb6a66a9054e029f0e7013.


--
Kaushal Modi

Re: Question Regarding CSS Stylesheets For Art Gallery Webpage Made With Org Mode

[Kaushal Modi]

Hi Samuel,

On Sun, Jan 16, 2022 at 12:06 PM Samuel Banya  wrote:
>
> I am planning to use Emacs to create Org Mode files for the few main sections 
> of my site that aren't the Art Gallery page itself.
>
> I'm trying to figure out how to get a modern Wordpress looking Org generated 
> HTML page that rivals pages like this:
>
> https://karlkopinski.com/
> https://wyliebeckert.com/
> http://www.brucepennington.co.uk/
> https://turnislefthome.com/
> https://davidmattingly.com/sketches/
> https://www.mathewborrett.com/
> https://www.stephenfabian.com/gallery

Here's my personal opinion: Org mode is great at concisely formatting
content, so I format my blog content in Org. But then I leave it up to
static site generator giants like Hugo to make the site look good. The
kind of look you want on your website could be achieved by one of the
themes: https://themes.gohugo.io/
Static site generators have tons of other benefits like putting the
right meta data, easily creating RSS, ATOM feeds, integrating
pre-generated search index, post-processing images, etc. before
uploading to the server, minifying CSS, JS, HTML, etc.

[ I am giving examples of using Hugo because that's what I use. You
can pick any static site generator and a compatible theme. ]

> Would be curious to know everyone's thoughts on this if there's a cool way to 
> do this via Org Mode :)

I would focus on:

1. Content writing in Org mode
2. Rendering/prettifying the website using CSS, templating, etc in a
static site generator.

Of course you can do everything in Org mode and many people do it, but
then you need to design CSS, JS, etc yourself.
( I am not a web designer, so I took the static site generator
approach and started learning more about CSS and templating from
available themes. )



Kaushal

org-element-cache: org-set-tags (C-c C-q) makes Emacs unresponsive at times

[Kaushal Modi]

Hello Ihor,

> The issue here had nothing to do with hanging. You are probably seeing
> yet another bug.

ok.

> By hang, do you mean that even C-g does not restore responsiveness?

Typically, within a second of doing C-c C-q, I would know that the
buffer is going to freeze, and if I do C-g soon enough, Emacs would
recover in a second or two.

But if I wait 5-6 seconds and then do C-g, it could take minutes to
recover, and I often do pkill SIGUSR2 from the terminal to get back.

Sorry, but since then I set org-element-use-cache to nil once that
issue comes back. It's usually that I am between something and I don't
think of getting a backtrace on C-g (Now I have made a note to self to
provide a backtrace in this thread when that issue repeats).

---

Right now, I set org-element-use-cache back to t, did M-x
toggle-debug-on-quit and did a couple of C-c C-q in a 10k line Org
buffer .. this time, it's responsive and snappy :|

I'll keep you posted. Thanks!!

---

Org mode version 9.5 (release_9.5-415-g9b58ea)
Emacs version: GNU Emacs 28.0.91 (build 5, x86_64-pc-linux-gnu, GTK+
Version 3.22.30, cairo version 1.15.12) of 2022-01-18, built using
commit f393d0d441c3746f98007ae54341870a296bf809.

Re: [BUG] org-element-cache: The inherited property is set wrong

[Kaushal Modi]

Hi Anders,

I have also been seeing some issues when adding/modidying heading tags
(C-c C-q), and I was able to narrow it down to the element caching
mechanism.

Issue: Org mode/Emacs hangs kind of indefinitely when I do C-c C-q,
but that doesn't happen each time.

Once I set org-element-use-cache to nil, Emacs stopped hanging.

Looking at your bug report, I believe that the issue I am seeing with
cache and Org tags could be very much related. So thanks for
submitting this.

--
Kaushal Modi

Re: [BUG] Prefer lowercase #+results [9.5.2 (release_9.5.2-3-geb9f34 @ /Users/salutis/src/emacs/nextstep/Emacs.app/Contents/Resources/lisp/org/)]

[Kaushal Modi]

On Mon, Jan 10, 2022 at 8:35 AM Timothy  wrote:
>
> FWIW, I think it would be good to be internally consistent. #+RESULTS is
> currently one of the few keywords inserted in upper case. Unless there’s a 
> good
> reason to distinguish it from other keywords (perhaps an argument could be 
> made
> that it should be treated differently because it is usually generated, not
> inserted by the user?), I’d be in favour of changing the default to be
> consistent.

+1 for consistency. The Org parser does not care if the keywords are
upper or lower case.

So inserting the #+results keyword in lower-case would be a good
change towards improving the consistency.

Re: Way to mark contents of an Org special block as verbatim?

[Kaushal Modi]

On Sun, Jan 9, 2022 at 3:01 PM Nicolas Goaziou  wrote:
>
> I suggest to use
>
>   (org-element-interpret-data (org-element-contents special-block))


That does it!! Thank you!

Also thanks to Juan and Charles who helped lead me to the final solution.

Re: Way to mark contents of an Org special block as verbatim?

[Kaushal Modi]

> On Sat, Jan 8, 2022 at 10:01 PM Berry, Charles  
> wrote:

Hi Charles,

I used your minimal example to show the issue I am seeing when using
ox-md as the base exporter.

=
#+property: header-args :results none :exports none :eval never-export
#+options: toc:nil

* Define newmd :noexport:
Eval below to define a minimal "newmd" exporter:
#+begin_src emacs-lisp
;; minimal backend with md parent
(org-export-define-derived-backend 'newmd 'md
  :translate-alist
  '((special-block . org-newmd-special-block)))

;; special block transcoder
(defun org-newmd-special-block (special-block contents info)
  "Newmd special block transcoder."
  (let
   ((type (org-element-property :type special-block)))
(if (equal type "katex")
(format "{{<%s>}}\n%s{{}}\n" type contents type)
  ;; not `katex' so default to md transcoder
  (org-export-with-backend 'md special-block contents info
#+end_src
* Test block for exporting
#+begin_katex
E = -J \sum_{i=1}^N s_i s_{i+1}
#+end_katex
* Do export:noexport:
Eval below to export this buffer using the ~newmd~ exporter:
#+begin_src emacs-lisp
(org-export-to-buffer 'newmd "*Org NEW LATEX Export*" nil nil nil :body-only)
#+end_src
=

1. Eval the block in first heading
2. Eval the block in second heading to export

Exporter buffer content:

=
# Test block for exporting

{{}}
E = -J i=1^N s\_i si+1
{{}}
=


How do we disable Org from transforming this:

E = -J \sum_{i=1}^N s_i s_{i+1}

to this:


E = -J i=1^N s\_i si+1

Re: Way to mark contents of an Org special block as verbatim?

[Kaushal Modi]

On Sat, Jan 8, 2022 at 10:01 PM Berry, Charles  wrote:
>
>
> A simple one here:
>
> #+begin_src emacs-lisp
>   ;; minimal backend with latex parent
>   (org-export-define-derived-backend 'newlatex 'latex
> :translate-alist
> '((special-block . org-newlatex-special-block)))
>
>   ;; special block transcoder
>   (defun org-newlatex-special-block (special-block contents info)
> "Newlatex special block transcoder."
> (let
>  ((type (org-element-property :type special-block)))
>   (if (equal type "newlatex")
>   (format "{{}}\n%s{{}}\n" contents)

I am already doing something like this, but at this point in the code,
the `contents' already is the modified content i.e. Org entities
replaced and _{..} converted to , etc.

Note that ox-hugo exporter is extended from ox-md, which is extended
from ox-html.

My problem statement is that the contents I am receiving is already
modified and I don't get to access the original/raw/verbatim content.
Thanking the original example in this thread:

#+begin_katex
E = -J \sum_{i=1}^N s_i s_{i+1}
#+end_katex

- \sum will have converted to 
- _{i=1} will have converted to i=1 by the time I receive
the contents in ox-hugo's org-hugo-special-block.

[ May be I am doing something wrong in my exporter? ]

Or may be it's due to the fact that my eventual base exporter is ox-html?

> ;; not `newlatex` so default to latex transcoder
> (org-export-with-backend 'latex special-block contents info
> #+end_src
>
> Eval the above, then use this as an example by copying the following
> src block to an org buffer and entering
>
> M-; (org-export-to-buffer 'newlatex "*Org NEW LATEX Export*" nil nil nil t) 
> RET
>
> #+begin_src org
>
>   ,#+begin_newlatex
>   This is the new content
>   ,#+end_newlatex
>
>
>   ,#+attr_latex: :caption \MyCaption{HeadingA}
>   ,#+BEGIN_proof
>  dot-dot-dot
>   ,#+END_proof
>
> #+end_src
>
> I get an *Org NEW LATEX Export* buffer like this:
>
> #+begin_example
> {{}}
> This is the new content
> {{}}
>
>
> \begin{proof}
> dot-dot-dot
> \MyCaption{HeadingA}
> \end{proof}
>
> #+end_example

Re: Way to mark contents of an Org special block as verbatim?

[Kaushal Modi]

> What am I missing?
>
> It seems like you want your derived backend to transcode special blocks 
> somewhat differently than the parent backend. And adding a special block 
> export filter doesn't quite do the job.

I tried out the example Juan posted and it works perfectly well. But
it would require to user to do something similar for each arbitrary
new special block they need. E.g. #+being_katex, #+begin_tikz,
#+begin_tikzjax (could be anything!) where the content needs to be
kept unmodified.

> For that purpose, you should write a special block transcoder - perhaps 
> falling back to the parent backend for block types you do not wish to handle 
> as described above.

Can you please point me to an example?

> Block specific customizations could rely on a backend specific attribute.

Yes, I am doing block-specific customization (like support
#+attr_shortcode above special blocks here[1]). But I don't know how
to get back the original content of the special block because the
`contents` arg received by the exporter's org-hugo-special-block
already has the Org entities, and sub/super replacements done.

[1]: 
https://github.com/kaushalmodi/ox-hugo/blob/458142675bb5a0e7ee26ecea07d75c10aa52184b/ox-hugo.el#L2872

Re: Way to mark contents of an Org special block as verbatim?

[Kaushal Modi]

On Thu, Jan 6, 2022 at 2:33 PM Juan Manuel Macías
 wrote:
> I just realized that there is a much simpler solution for your katex
> environment :-)
>
> You can use an example block, and define your custom environment using
> the attribute :environment

Sorry, but this exporter is derived from md, and before exporting the
verbatim body of the special block needs to be surrounded with some
special syntax, with some optional stuff that the user specifies. Also
it could any special block name:
- katex
- tikz
- tikzjax

In any case, if user has this in Org:

#+begin_FOO

#+end_FOO

I need to export:

{{< FOO custom stuff >}}

{{< /FOO >}}

Re: Way to mark contents of an Org special block as verbatim?

[Kaushal Modi]

On Thu, Jan 6, 2022 at 1:27 PM Juan Manuel Macías
 wrote:
> I think one possibility would be using a parse tree export filter:
>
> #+BIND: org-export-filter-parse-tree-functions (katex-verbatim)
> #+begin_src emacs-lisp :exports results :results none
>   (defun katex-verbatim (tree backend info)
> (when (org-export-derived-backend-p backend 'latex)
>   (org-element-map tree 'special-block
> (lambda (block)
>   (when (equal "katex" (org-element-property :type block))
> (let ((cont (org-element-interpret-data (org-element-contents 
> block)))
>   (create-export-snippet ;; idea from Nicolas Goaziou
>(lambda (v)
>  (org-element-create 'export-snippet (list :back-end 
> "latex" :value v)
>   (apply #'org-element-set-contents
>  block
>  (list (funcall create-export-snippet cont))
> info)
>   tree))
> #+end_src
>
> #+begin_katex
> E = -J \sum_{i=1}^N s_i s_{i+1}
> #+end_katex
>
> ==>
>
> \begin{katex}
> E = -J \sum_{i=1}^N s_i s_{i+1}
> \end{katex}

Wow, thanks for that complete code. I didn't know about the parse tree
functions.

I was thinking if below is possible as any user running my exporter
would need to use this feature easily.

#+begin_katex :verbatim t
E = -J \sum_{i=1}^N s_i s_{i+1}
#+end_katex

Is it possible to do anything inside the org-hugo-special-block
function that's defined in the exporter?

Way to mark contents of an Org special block as verbatim?

[Kaushal Modi]

Hello,

Is there a way to mark contents of an Org special block as verbatim?

In my custom exporter, when I do the below,

#+begin_katex
E = -J \sum_{i=1}^N s_i s_{i+1}
#+end_katex

it gets exported to:

{{< katex display >}}
E = -J i=1^N s\_i si+1
{{< /katex >}}

I would like to treat that block /like/ how Org treats the latex
environment blocks, but it needs to be a special block as
begin_katex/end_katex here is special and it could be a different
equation rendering backend for another user.

So is that a header switch or arg that can be passed on to this
special block that enables the verbatim mode (prevent Org from
replacing the Org entities, do the sub/superscript expansion, etc.)?

--
Kaushal Modi

Re: [BUG] org-element--cache gives "Unregistered buffer modifications" warning [9.5 (9.5-g859984 @ /home/john/.emacs.d/straight/build/org/)]

[Kaushal Modi]

On Fri, Dec 17, 2021 at 11:34 PM Ihor Radchenko  wrote:

> > There's a setup included in there; I forgot about that. If you don't mind
> > trying it again, this would download everything needed:
>
> Thanks! I was able to follow your steps this time.
>

I really appreciate making this extra effort to help me out. Thanks!


> > Sorry, but I am getting similar backtrace in another function now:
>
> Sigh... Should be fixed now. I did not expect that arguments to cache
> functions could ever be markers.
>
> After the fix, I was able to see the warning you were talking about in
> the earlier email. Your test case revealed an important omission in the
> cache logic when a huge number of edits are stacked together into
> asynchronous cache queue. Thanks you for providing the excellent
> reproducer!
>

No problem! The ox-hugo tests end up indirectly testing a lot of Org
features :D


> On latest main, your example file is exported without any warnings.
>

I just verified that. Also, I did not even need to add
`(org-element-cache-reset)' in `org-hugo--get-pre-processed-buffer' after
the `(insert ..)' in the temp buffer.

Is that expected?

Also, I noticed that now the exports are much more snappier than before!

Also, I noticed that the large number of edits makes the cache use a lot
> of memory adding load onto the Emacs garbage collector. May I know what
> exactly ox-hugo does that triggers that many edits? Exporting your
> example files took approximately 30sec on my system (both with and
> without cache). I believe that the speed can be improved if cache is
> used more optimally.
>

That command exports 81 subtrees (as of now) from ox-hugo-manual.org to
independent Markdown files.

That said, I think that `org-hugo--get-pre-processed-buffer' [1] is the
performance bottleneck. It was added so that Org subtree exports can work
even if one subtree has an internal link to a different subtree in the same
file.

The pre processing logic slurps up the AST of the whole Org buffer, does
org-element-copy on all the link org-elements to point to a place outside
the exported subtree, fixes that link so that the export works, and copies
the modified link element back on the original element. And then the whole
Org temp buffer is overwritten with the modified AST.
And then.. the subtree export happens from there.

This is the only way possible as far as I know to support cross-subtree
links. Credit for this implementation goes to Folkert van der Beek[2].

Let me know if you have any suggestions to improve the performance. I think
that the org-element-copy and writing the huge AST to temp Org buffer is
keeping the GC busy (the ox-hugo-manual.org is about 3700 lines right now).

[1]:
https://github.com/kaushalmodi/ox-hugo/blob/1ea466d33f76eaf2567593fa612b82c22ef86d3d/ox-hugo.el#L4033-L4151

[2]: https://github.com/kaushalmodi/ox-hugo/pull/280

Re: [BUG] org-element--cache gives "Unregistered buffer modifications" warning [9.5 (9.5-g859984 @ /home/john/.emacs.d/straight/build/org/)]

[Kaushal Modi]

On Thu, Dec 16, 2021 at 10:16 AM Ihor Radchenko  wrote:

>
> FYI, it is suspicious. You should be at 9.5.1. Maybe you forgot to make
> clean; make autoloads.
>

I actually run a wrapper script to update Org and that has all that:

=
# cmds to update to latest commit on git main branch
# Ensure that the prefix path is correct in local.mk for
# emacs/home/$1 version.
sed -i 's|^prefix.*=.*|prefix =
/home/kmodi/usr_local/apps/7/emacs/'"$1"'/share|' local.mk
# Update the infodir if needed.
sed -i 's|^infodir.*=.*|infodir = $(prefix)/org/info|' local.mk
echo -e "\\nBuilding for emacs version: $(emacs --version | grep -E
'Emacs [0-9]+\.[0-9]+')\\n"
make cleanall
make autoloads
make compile
make doc
make install
=

I verified that at least the git hash was latest as of then:
release_9.5-364-g*de022e*



> > Steps to reproduce this issue (after setting those variables as suggested
> > above):
> >
> > 1. Install ox-hugo from MELPA and require it
> > 2. Download the ox-hugo-manual.org[1]
> > 3. Take point to anywhere inside a subtree with :EXPROT_FILE_NAME:
> property
> > (e.g. under the * Org Special Blocks subtree around line 3038)
> > 4. C-c C-e H A (this will export all the valid subtrees in that file
> using
> > ox-hugo)
>
> I tried on my side and I am getting "Undefined Org macro: issue;
> aborting" Does not look like Org's fault unless I miss something.
>

There's a setup included in there; I forgot about that. If you don't mind
trying it again, this would download everything needed:

=
git clone https://github.com/kaushalmodi/ox-hugo
cd ox-hugo/doc/
# open ox-hugo-manual.org from this dir
=

and then:

=
1. Eval /ox-hugo/ox-hugo.el
2. Take point to anywhere inside a subtree with :EXPROT_FILE_NAME: property
(e.g. under the * Org Special Blocks subtree around line 3038)
3. C-c C-e H A (this will export all the valid subtrees in that file using
ox-hugo)
=

I am unable to reproduce but I know why it happened (and it is indeed
> different from previous one). I just pushed a fix upstream.
>

Thanks. I see this version after the update:

Org mode version 9.5 (release_9.5-366-g092e92 @
/home/kmodi/usr_local/apps/7/emacs/emacs-28/share/emacs/site-lisp/org/)
The git hash is correct (
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=092e921423f02d48778a0c5d298a211388af8090).
So not sure, why it's still saying version 9.5.

Sorry, but I am getting similar backtrace in another function now:

=
Debugger entered--Lisp error: (error "Format specifier doesn’t match
argument type")
  format("org-element-cache diagnostics( *temp*-378635): Int..." 28172
#)
  org-element--cache-process-request([28170 28171 22333 1 (headline
(:raw-value "Usage" :begin 17933 :end 22334 :pre-blank 0 :contents-begin
17942 :contents-end 22334 :robust-begin 17978 :robust-end 22332 :level 2
:priority nil :tags nil :todo-keyword nil :todo-type nil :post-blank 0
:footnote-section-p nil :archivedp nil :commentedp nil :post-affiliated
17933 :CUSTOM_ID "usage" :title "Usage" :mode nil :granularity element
:cached t :parent (headline (:raw-value "Reused Sections" :begin 17054 :end
28172 :pre-blank 0 :contents-begin 17072 :contents-end 28172 :robust-begin
17074 :robust-end 28170 :level 1 :priority nil :tags nil :todo-keyword nil
:todo-type nil :post-blank 0 :footnote-section-p nil :archivedp nil
:commentedp nil :post-affiliated 17054 :title "Reused Sections" :mode nil
:granularity element :cached t :parent (org-data (:begin 1 :contents-begin
1 :contents-end 145098 :end 145098 :robust-begin 3 :robust-end 145096
:post-blank 0 :post-affiliated 1 :path nil :mode org-data :CATEGORY nil
:cached t)) :org-element--cache-sync-key (69 . 17054)))
:org-element--cache-sync-key (67 . 17933))) 1] 145000 # nil nil)
  org-element--cache-sync(# #)
  org-element-at-point(#)
  org-element-cache-map(#f(compiled-function (el) #) :next-re "^\\*+ " :fail-re "^\\*+ " :narrow t)
  org-scan-tags(#f(compiled-function () #) t
nil nil)
  org-map-entries(#f(compiled-function () #))
=

*Another observation: *

I see this warning when building from the latest main:

In org-element--cache-sync:
org-element.el:5935:19: Warning: assignment to free variable
‘org-element--cache-change-warning’

Re: [BUG] org-element--cache gives "Unregistered buffer modifications" warning [9.5 (9.5-g859984 @ /home/john/.emacs.d/straight/build/org/)]

[Kaushal Modi]

> Can you:
> 1. Update Org to latest version
> 2. set org-element--cache-self-verify to 'backtrace
> 3. set org-element--cache-self-verify-frequency to 1.0
> 4. Try to reproduce the warning you are seeing
> 5. If you still see it, post the full warning text including the
>backtrace (below the warning).
>

Hi Ihor,

I updated Org to

Org mode version 9.5 (release_9.5-364-gde022e @
/home/kmodi/usr_local/apps/7/emacs/emacs-28/share/emacs/site-lisp/org/)

I am using the latest build of emacs-28 branch:

=
Emacs version: GNU Emacs 28.0.90 (build 2, x86_64-pc-linux-gnu, GTK+
Version 3.22.30, cairo version 1.15.12)
 of 2021-12-16, built using commit 1e578267fb19208504d28253e0c892ceb9a34fb4.

./configure options:
  --prefix=/home/kmodi/usr_local/apps/7/emacs/emacs-28
'--program-transform-name=s/^ctags$/ctags_emacs/' --with-modules
--with-harfbuzz --with-native-compilation --enable-checking=yes,glyphs
--enable-check-lisp-object-type CPPFLAGS=-I/home/kmodi/stowed/7/include
'CFLAGS=-ggdb3 -Og' 'CXXFLAGS=-ggdb3 -Og'
'LDFLAGS=-L/home/kmodi/stowed/7/lib -L/home/kmodi/stowed/7/lib64 -ggdb3'

Features:
  ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
LIBOTF LIBSELINUX LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG
RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS X11 XDBE XIM XPM GTK3
ZLIB
=

I also set those 2 variables and then exported the ox-hugo-manual.org[1]
using ox-hugo and get those warnings[2].

Steps to reproduce this issue (after setting those variables as suggested
above):

1. Install ox-hugo from MELPA and require it
2. Download the ox-hugo-manual.org[1]
3. Take point to anywhere inside a subtree with :EXPROT_FILE_NAME: property
(e.g. under the * Org Special Blocks subtree around line 3038)
4. C-c C-e H A (this will export all the valid subtrees in that file using
ox-hugo)
5. The exports abruptly stop around half way due to this error (this error
doesn't always get thrown at the same point):

=
org-babel-exp process org at position 59086...
org-babel-exp process org at position 59385...
org-babel-exp process org at position 60069...
org-babel-exp process org at position 60740...
org-babel-exp process org at position 63055...
Saving file
/home/kmodi/stow/pub_dotfiles/emacs/dot-emacs.d/elisp/ox-hugo/doc/content/doc/image-links.md...
Wrote
/home/kmodi/stow/pub_dotfiles/emacs/dot-emacs.d/elisp/ox-hugo/doc/content/doc/image-links.md
[ox-hugo] 21/ Exporting ‘Source blocks’ ..
org-element--cache-process-request: Format specifier doesn’t match argument
type

(I have an advice applied in between:
modi/advice-org-tangle-and-export-boost. But it's unrelated to this error.)

Debugger entered--Lisp error: (error "Format specifier doesn’t match
argument type")
  format("org-element-cache diagnostics( *temp*-467986): Rea..." # "(headline (:raw-value \"Menus\" :begin 28167
:end 14...")
  org-element--cache-process-request([26673 26673 25896 1 (paragraph
(:begin 26634 :end 26674 :contents-begin 26634 :contents-end 26674
:post-blank 0 :post-affiliated 26634 :mode nil :granularity element
:org-element--cache-sync-key (76 26672 1152921504606846975) :cached t
:parent (item (:bullet "8. " :begin 26631 :end 26674 :contents-begin 26634
:contents-end 26674 :checkbox nil :counter nil :structure ((26009 0 "1. "
nil nil nil 26029) (26029 0 "2. " nil nil nil 26145) (26145 0 "3. " nil nil
nil 26167) (26167 0 "4. " nil nil nil 26346) (26226 3 "- " nil nil nil
26346) (26346 0 "5. " nil nil nil 26462) (26389 3 "- " nil nil nil 26462)
(26462 0 "6. " nil nil nil 26564) (26564 0 "7. " nil nil nil 26631) (26631
0 "8. " nil nil nil 26674)) :pre-blank 0 :post-blank 0 :post-affiliated
26631 :tag nil :mode item :granularity element :org-element--cache-sync-key
(76 26672 -1) :cached t :parent (plain-list (:type ordered :begin 26009
:end 26674 :contents-begin 26009 :contents-end 26674 :structure ...
:post-blank 0 :post-affiliated 26009 :mode nil :granularity element
:org-element--cache-sync-key ... :cached t :parent ...)) 2] nil
# nil nil)
  org-element--cache-sync(# #)
  org-element-at-point(#)
  org-element-cache-map(#f(compiled-function (el) #) :next-re "^\\*+ " :fail-re "^\\*+ " :narrow t)
  org-scan-tags(#f(compiled-function () #) t
nil nil)
  org-map-entries(#f(compiled-function () #))

org-export--prepare-file-contents("/home/kmodi/stow/pub_dotfiles/emacs/dot-emacs.d/el..."
"548-589" 0 4 1 #
"/home/kmodi/stow/pub_dotfiles/emacs/dot-emacs.d/el...")
  org-export-expand-include-keyword()
  org-export-as(hugo :subtreep nil nil (:output-file
"/home/kmodi/stow/pub_dotfiles/emacs/dot-emacs.d/el..."))
  #f(compiled-function (backend file  async subtreep visible-only
body-only ext-plist post-process) "Call `org-export-as' with output to a
specified file.\n\nBACKEND is either an export back-end, as returned by,
e.g.,\n`org-export-create-backend', or a symbol referring to\na registered
back-end.  FILE is the name of the output file, as\na string.\n\nA non-nil
optional argument ASYNC means the 

Re: [BUG] org-element--cache gives "Unregistered buffer modifications" warning [9.5 (9.5-g859984 @ /home/john/.emacs.d/straight/build/org/)]

[Kaushal Modi]

On Wed, Dec 15, 2021 at 9:29 PM Kaushal Modi  wrote:

>
> Can you help fix this?
>

Also looking closely, I am seeing a different warning:

Warning (org-element-cache): org-element--cache:
(org-hugo-export-wim-to-md) Cached element is incorrect in *Ox-hugo
Pre-processed ox-hugo-manual.org *<2>. (Cache tic up to date: "yes")
Resetting.
If this warning appears regularly, please report it to Org mode mailing
list (M-x org-submit-bug-report).
The element is:   "(headline (:raw-value \"Homepage\" :begin 16675 :end
25840 :pre-blank 0 :contents-begin 16686 :contents-end 25840 :robust-begin
16891 :robust-end 25838 :level 1 :priority nil :tags nil :todo-keyword nil
:todo-type nil :post-blank 0 :footnote-section-p nil :archivedp nil
:commentedp nil :post-affiliated 16675 :EXPORT_TITLE \"Org to Markdown for
Hugo\" :EXPORT_FILE_NAME \"_index\" :EXPORT_HUGO_TYPE \"homepage\"
:EXPORT_HUGO_SECTION \"/\" :EXPORT_HUGO_MENU \":menu \\\"1.main\\\" :title
\\\"Homepage\\\"\" :CUSTOM_ID \"main\" :title \"Homepage\" ...))"
 The real element is: "(headline (:raw-value \"Homepage\" :begin 16675 :end
25888 :pre-blank 0 :contents-begin 16686 :contents-end 25888 :robust-begin
16891 :robust-end 25886 :level 1 :priority nil :tags nil :todo-keyword nil
:todo-type nil :post-blank 0 :footnote-section-p nil :archivedp nil
:commentedp nil :post-affiliated 16675 :EXPORT_TITLE \"Org to Markdown for
Hugo\" :EXPORT_FILE_NAME \"_index\" :EXPORT_HUGO_TYPE \"homepage\"
:EXPORT_HUGO_SECTION \"/\" :EXPORT_HUGO_MENU \":menu \\\"1.main\\\" :title
\\\"Homepage\\\"\" :CUSTOM_ID \"main\" :title \"Homepage\" ...))"

I see the :end and :content-end changing.

Re: [BUG] org-element--cache gives "Unregistered buffer modifications" warning [9.5 (9.5-g859984 @ /home/john/.emacs.d/straight/build/org/)]

[Kaushal Modi]

On Mon, Nov 8, 2021 at 1:05 AM Ihor Radchenko  wrote:

>
> I was able to reproduce the issue. This is a bug on ox-hugo side.
> `org-hugo--get-pre-processed-buffer' inserts text with
> inhibit-modification-hooks bound to non-nil, which breaks
> org-element-cache. The cache is enabled by default in latest Org, which
> is why the issue revealed itself.
>
> The fix on ox-hugo side can be made similarly to the new implementation
> of `org-export--generate-copy-script' - ox-hugo needs to manually reset
> the cache after silent changes in temporary Org buffer.
>

Hi Ihor,

I followed your change to `org-export--generate-copy-script'  in
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=fe6cefdaaf020c315031a139a7b9bc443cbefc5c
and added a `(org-element-cache-reset)' call in
`org-hugo--get-pre-processed-buffer' after the `(insert ..)' in the temp
buffer.

But I am still seeing that warning.

Ref commit to a branch:
https://github.com/kaushalmodi/ox-hugo/commit/2bdbf51922ec2e01be65397b237d0b716edb5cb4

Can you help fix this?

Thanks!

Re: [BUG] make test is extremely slow since b3cc2f793 [9.5.1 (9.5.1-g984367 @ /home/yantar92/.emacs.d/straight/build/org/)]

[Kaushal Modi]

On Sun, Dec 5, 2021 at 4:12 AM Nicolas Goaziou 
wrote:

> Hello,
>
> Ihor Radchenko  writes:
>
> > Sorry, but tests are still slow for me after the update.
> > If I run the test from inside Emacs with ert, things got better, but
> > make BTEST_RE="^test-org-cite/adjust-note" test
> > still takes 12sec.
>
> I cannot reproduce it. The test went down from 4.5s to 1.5s. I am using
> Emacs 27.2.
>

Ihor,

FWIW, the tests runs in about the same time for me.

Running 1 tests (2021-12-06 08:59:31-0500, selector
‘"^test-org-cite/adjust-note"’)
   passed  1/1  test-org-cite/adjust-note (1.333928 sec)

I just rebuild Org from main branch and I am on emacs-28 branch built last
Friday:

Emacs version: GNU Emacs 28.0.90 (build 1, x86_64-pc-linux-gnu, GTK+
Version 3.22.30, cairo version 1.15.12)
 of 2021-12-03, built using commit 7282e492d5c3ed8c856d92a121d143f6a70db244.

Maybe strace would help identify a disk IO issue if any?

Re: [PATCH] Fix org-comment-line-break-function

[Kaushal Modi]

Hi Nicolas,

I have added few tests in the updated patch pasted in this email.
I have made the tests for (call-interactive #'default-indent-new-line)
because that the interactive function M-j is bound to by default.

Can you please review and commit it? The machine I am on right now does not
allow external ssh access.



>From de607dff518eaa91149ff1aa8c255f67fb6ee887 Mon Sep 17 00:00:00 2001
From: Kaushal Modi 
Date: Tue, 30 Nov 2021 20:37:10 -0500
Subject: [PATCH] org: Remove `org-comment-line-break-function'

* lisp/org.el: Remove `org-comment-line-break-function' and let
`comment-line-break-function' be the default value.
* testing/lisp/test-org.el (test-org/default-indent-new-line): Add
tests for M-j behavior when point is inside or outside an Org comment.

This fixes the `M-j' binding issue reported by Richard Lawrence in
<https://lists.gnu.org/r/emacs-orgmode/2021-11/msg00639.html>.
---
 lisp/org.el  | 17 ++---
 testing/lisp/test-org.el | 19 +++
 2 files changed, 21 insertions(+), 15 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index ec59ddf44..ee8ca1f03 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -19624,8 +19624,7 @@ assumed to be significant there."

 ;; `org-auto-fill-function' takes care of auto-filling.  It calls
 ;; `do-auto-fill' only on valid areas with `fill-prefix' shadowed with
-;; `org-adaptive-fill-function' value.  Internally,
-;; `org-comment-line-break-function' breaks the line.
+;; `org-adaptive-fill-function' value.

 ;; `org-setup-filling' installs filling and auto-filling related
 ;; variables during `org-mode' initialization.
@@ -19647,8 +19646,7 @@ assumed to be significant there."
   (setq-local fill-paragraph-function 'org-fill-paragraph)
   (setq-local auto-fill-inhibit-regexp nil)
   (setq-local adaptive-fill-function 'org-adaptive-fill-function)
-  (setq-local normal-auto-fill-function 'org-auto-fill-function)
-  (setq-local comment-line-break-function
'org-comment-line-break-function))
+  (setq-local normal-auto-fill-function 'org-auto-fill-function))

 (defun org-fill-line-break-nobreak-p ()
   "Non-nil when a new line at point would create an Org line break."
@@ -19903,17 +19901,6 @@ filling the current element."
  (adaptive-fill-mode (not (equal fill-prefix ""
  (when fill-prefix (do-auto-fill))

-(defun org-comment-line-break-function ( soft)
-  "Break line at point and indent, continuing comment if within one.
-The inserted newline is marked hard if variable
-`use-hard-newlines' is true, unless optional argument SOFT is
-non-nil."
-  (if soft (insert-and-inherit ?\n) (newline 1))
-  (save-excursion (forward-char -1) (delete-horizontal-space))
-  (delete-horizontal-space)
-  (indent-to-left-margin)
-  (insert-before-markers-and-inherit fill-prefix))
-

 ;;; Fixed Width Areas

diff --git a/testing/lisp/test-org.el b/testing/lisp/test-org.el
index 056ea7d87..de4ac7ea9 100644
--- a/testing/lisp/test-org.el
+++ b/testing/lisp/test-org.el
@@ -1200,6 +1200,25 @@
 (org-indent-region (point-min) (point-max))
 (buffer-string)

+(ert-deftest test-org/default-indent-new-line ()
+  "Test behavior of default binding `M-j'."
+  ;; Calling `M-j' when point is not in an Org comment:
+  (should
+   (equal "* Some heading\n"
+  (org-test-with-temp-text "* Some heading"
+   (call-interactively #'default-indent-new-line)
+   (buffer-string
+  ;; Calling `M-j' when point is in an Org comment:
+  (should
+   (equal "# Some Org comment\n# "
+  (org-test-with-temp-text "# Some Org comment"
+   (call-interactively #'default-indent-new-line)
+   (buffer-string
+  (should
+   (equal "# Some Org\n# comment"
+  (org-test-with-temp-text "# Some Org comment"
+   (call-interactively #'default-indent-new-line)
+   (buffer-string)


 ;;; Editing
-- 
2.34.0





--
Kaushal Modi


On Mon, Dec 6, 2021 at 8:17 AM Richard Lawrence <
richard.lawre...@uni-tuebingen.de> wrote:

> Kaushal Modi  writes:
>
> > On Sat, Dec 4, 2021, 5:25 PM Tim Cross  wrote:
> >
> >> Given that Nicholas cannot remember the reason for the original function
> >> and suspects it was meant to be an internal only function, I think this
> >> patch is probably the best way forward and should be applied.
> >
> > Thanks. Nicolas asked me to add tests for this patch. But I need to look
> > into how to add tests for behavior of bindings. Need to add tests for M-j
> > binding behavior when cursor is within a comment or outside.
>
> FWIW I have been running the equivalent of Kaushal's patch (I just
> removed the local binding of comment-line-break-function to
> 'org-comment-line-break-function without deleting 

Re: [PATCH] Fix org-comment-line-break-function

[Kaushal Modi]

On Sat, Dec 4, 2021, 5:25 PM Tim Cross  wrote:

>
> Given that Nicholas cannot remember the reason for the original function
> and suspects it was meant to be an internal only function, I think this
> patch is probably the best way forward and should be applied.
>

Thanks. Nicolas asked me to add tests for this patch. But I need to look
into how to add tests for behavior of bindings. Need to add tests for M-j
binding behavior when cursor is within a comment or outside.

>

Re: examples for org-manual

[Kaushal Modi]

On Thu, Dec 2, 2021, 8:08 AM Vincent Breton 
wrote:

> Hi,
>
>
> Emacs and Emacs Org documentation, and lot of others GNU products use
> Texinfo to generate their own  documentation to different formats.


The Org mode documentation switched to Org format few years back:
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/tree/doc/org-manual.org

Yes, originally, it was in Texinfo.

Re: [PATCH] Fix org-comment-line-break-function

[Kaushal Modi]

On Tue, Nov 30, 2021 at 6:29 PM Tim Cross  wrote:

>
> It would be good to get Nicholas' input here as I think he wrote the
> original function back in 2012.
>

Just to see what happens, I tried this:

M-: (setq-local comment-line-break-function #'comment-indent-new-line)

.. and then M-j started working perfectly! It worked fine both: in Org
comment lines and out of comment lines.

I see that comment-indent-new-line was added to emacs in newcomment.el back
in 2000. So I don't know why org-comment-line-break-function was added. May
be Nicolas can comment more on that.

So would this patch work?

=

>From 1a9187b82ed8d4e8d54ddd369a44d34295281fc3 Mon Sep 17 00:00:00 2001
From: Kaushal Modi 
Date: Tue, 30 Nov 2021 20:37:10 -0500
Subject: [PATCH] org: Remove `org-comment-line-break-function'

* lisp/org.el: Remove `org-comment-line-break-function' and let
`comment-line-break-function' be the default value.

This fixes the `M-j' binding issue reported by Richard Lawrence in
<https://lists.gnu.org/r/emacs-orgmode/2021-11/msg00639.html>.
---
 lisp/org.el | 17 ++---
 1 file changed, 2 insertions(+), 15 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index ec59ddf44..ee8ca1f03 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -19624,8 +19624,7 @@ assumed to be significant there."

 ;; `org-auto-fill-function' takes care of auto-filling.  It calls
 ;; `do-auto-fill' only on valid areas with `fill-prefix' shadowed with
-;; `org-adaptive-fill-function' value.  Internally,
-;; `org-comment-line-break-function' breaks the line.
+;; `org-adaptive-fill-function' value.

 ;; `org-setup-filling' installs filling and auto-filling related
 ;; variables during `org-mode' initialization.
@@ -19647,8 +19646,7 @@ assumed to be significant there."
   (setq-local fill-paragraph-function 'org-fill-paragraph)
   (setq-local auto-fill-inhibit-regexp nil)
   (setq-local adaptive-fill-function 'org-adaptive-fill-function)
-  (setq-local normal-auto-fill-function 'org-auto-fill-function)
-  (setq-local comment-line-break-function
'org-comment-line-break-function))
+  (setq-local normal-auto-fill-function 'org-auto-fill-function))

 (defun org-fill-line-break-nobreak-p ()
   "Non-nil when a new line at point would create an Org line break."
@@ -19903,17 +19901,6 @@ filling the current element."
  (adaptive-fill-mode (not (equal fill-prefix ""
  (when fill-prefix (do-auto-fill))

-(defun org-comment-line-break-function ( soft)
-  "Break line at point and indent, continuing comment if within one.
-The inserted newline is marked hard if variable
-`use-hard-newlines' is true, unless optional argument SOFT is
-non-nil."
-  (if soft (insert-and-inherit ?\n) (newline 1))
-  (save-excursion (forward-char -1) (delete-horizontal-space))
-  (delete-horizontal-space)
-  (indent-to-left-margin)
-  (insert-before-markers-and-inherit fill-prefix))
-

 ;;; Fixed Width Areas

-- 
2.34.0

=

Re: [PATCH] Fix org-comment-line-break-function

[Kaushal Modi]

On Tue, Nov 30, 2021, 6:29 PM Tim Cross  wrote:

>
> Regardless, I think that unless we understand the purpose of
> insert-before-markers-and-inherit, we should make the patch such that it
> still calls that function. Even if fill-prefix is nil there is
> probably a good reason why the markers and properties need to be
> modified for some situations.
>

Oops! You're right; I did not verify that binding within a comment. I just
checked that it prevented the error.

It would be good to understand the purpose of that function call and have a
proper fix.

>

Re: [PATCH] Fix org-comment-line-break-function

[Kaushal Modi]

On Tue, Nov 30, 2021 at 3:20 PM Marco Wahl  wrote:

>
>
> diff --git a/lisp/org.el b/lisp/org.el
> index 1a1375461..fdeec0d67 100644
> --- a/lisp/org.el
> +++ b/lisp/org.el
> @@ -19695,7 +19695,8 @@ non-nil."
>(save-excursion (forward-char -1) (delete-horizontal-space))
>(delete-horizontal-space)
>(indent-to-left-margin)
> -  (insert-before-markers-and-inherit fill-prefix))
> +  (when fill-prefix
> +(insert-before-markers-and-inherit fill-prefix)))
>
> I don't have anything better.  I think this is a good patch.  It makes
> M-j work again.
>
> Possible refinements and improvements can follow.
>
> +1 for applying of your patch.
>

I am able to reproduce that M-j issue (using Emacs version: GNU Emacs
28.0.60 (build 9, x86_64-pc-linux-gnu, GTK+ Version 3.22.30, cairo version
1.15.12)
 of 2021-11-29, built using commit
c4daff9cf844ec85930bdcd2064787c92c260861, and Org mode version 9.5
(release_9.5-292-g5e35de)).

And this patch fixes that for me as well.

+1 for applying this patch.

=

Before this patch, M-j gave this backtrace with debug enabled:

Debugger entered--Lisp error: (wrong-type-argument char-or-string-p nil)
  insert-before-markers-and-inherit(nil)
  org-comment-line-break-function(nil)
  default-indent-new-line(nil t)
  funcall-interactively(default-indent-new-line nil t)
  call-interactively(default-indent-new-line nil nil)
  command-execute(default-indent-new-line)


Output of C-h k M-j:

M-j runs the command default-indent-new-line (found in global-map),
which is an interactive compiled Lisp function in ‘simple.el’.

It is bound to C-M-j, M-j.

(default-indent-new-line  SOFT FORCE)

Break line at point and indent.
If a comment syntax is defined, call ‘comment-line-break-function’.

The inserted newline is marked hard if variable ‘use-hard-newlines’ is true,
unless optional argument SOFT is non-nil.

Re: babel output seems to drop anything before % (in session)

[Kaushal Modi]

Hello all,

I am following up on this issue with ob-shell and sessions.

I had posted the recipe to reproduce the issue few months back, and it
still applies; ref:
https://list.orgmode.org/CAFyQvY2AeToQc2G=e+de4votetfbkvisenipypw1y-feu1o...@mail.gmail.com/

Thanks!

--
Kaushal Modi

Re: [BUG] Org V 9.5 error when ~/.cache doesn't exist

[Kaushal Modi]

On Fri, Nov 5, 2021, 9:48 AM Ihor Radchenko  wrote:

>
> I am not sure if we are dropping Emacs 25 just yet. However, there is
> currently more than one place in Org that does not work on Emacs 25.
> See https://list.orgmode.org/87zgqu6081.fsf@localhost/T/#t
>
> If compilation is critical for you, I can make a patch to make things
> compile in Emacs 25. Though compatibility layer for xdg is more tricky.
> I do not want to do it unless necessary.
>

I haven't switched back to emacs 25 in a while. It's just that the script I
had for building Org started failing. All's good after removing the build
step for emacs 25.

I am anyways on emacs/master and then emacs-28 for a while now. So I
personally don't need emacs 25 compatibility. But in any case, this
breakage on emacs 25 should be fixed or the min req bumped to emacs 26.

>

Re: wrong-type-argument avl-tree- (org-persist-write-all-buffers) [org main + emacs emacs-28]

[Kaushal Modi]

On Fri, Nov 5, 2021 at 10:25 AM Ihor Radchenko  wrote:

> Fixed on main. Thanks for reporting!
>

Thanks! I confirm the fix.

wrong-type-argument avl-tree- (org-persist-write-all-buffers) [org main + emacs emacs-28]

[Kaushal Modi]

Hello all,

For few days now, I have been seeing the "wrong-type-argument avl-tree-"
error when I try to kill a buffer where org-persist has run.

I am seeing this with the latest build of emacs-28 branch plus org main
branch as of today.

Here's the backtrace:

Debugger entered--Lisp error: (wrong-type-argument avl-tree- nil)
  avl-tree-mapc(# nil)
  org-element--cache-persist-before-write(org-element--cache #)
  run-hook-with-args-until-success(org-element--cache-persist-before-write
org-element--cache #)
  #f(compiled-function (v) #)(org-element--cache)
  #f(compiled-function (elt) #)(org-element--cache)
  mapc(#f(compiled-function (elt) #)
(org-element--headline-cache org-element--cache))
  seq-do(#f(compiled-function (elt) #)
(org-element--headline-cache org-element--cache))
  seq-find(#f(compiled-function (v) #)
(org-element--headline-cache org-element--cache))
  org-persist-write((org-element--headline-cache org-element--cache)
#)
  org-persist-write-all(#)
  org-persist-write-all-buffer()
  kill-buffer("NEWS")

Are there any pointers on how to fix this?

Thanks!

--
Kaushal Modi

Re: [BUG] Org V 9.5 error when ~/.cache doesn't exist

[Kaushal Modi]

On Fri, Nov 5, 2021 at 9:27 AM Kaushal Modi  wrote:

> Hello,
>
> On the topic of xdg, I pulled Org from main branch today and tried to
> build it but it's failing with:
>
> org-persist.el:32:1:Error: Cannot open load file: No such file or
> directory, xdg
>
> Anybody else seeing this?
>

Figured out the problem.. looks like Org main branch doesn't support emacs
25.

My build script was building Org for all emacs versions starting from
version 25. It builds fine if remove the build  for emacs 25. I think I
missed it somewhere that Org main branch is dropping emacs 25 support.

Re: [BUG] Org V 9.5 error when ~/.cache doesn't exist

[Kaushal Modi]

On Fri, Nov 5, 2021 at 9:27 AM Kaushal Modi  wrote:

> Hello,
>
> On the topic of xdg, I pulled Org from main branch today and tried to
> build it but it's failing with:
>
> org-persist.el:32:1:Error: Cannot open load file: No such file or
> directory, xdg
>
> Anybody else seeing this?
>

To add more context, I am on emacs-28 branch right now.

Re: [BUG] Org V 9.5 error when ~/.cache doesn't exist

[Kaushal Modi]

Hello,

On the topic of xdg, I pulled Org from main branch today and tried to build
it but it's failing with:

org-persist.el:32:1:Error: Cannot open load file: No such file or
directory, xdg

Anybody else seeing this?

Re: Headings and Headlines

[Kaushal Modi]

On Fri, Jul 23, 2021 at 10:07 AM Marco Wahl  wrote:

> André A. Gomes  writes:
>
> > The project's documentation refers to headings and headlines as
> > synonyms.  Relying on a single definition would be beneficial.
>
> Agreed.  E.g. no more thinking waste about the question if it is
> headline or heading?
>

+1

> If I had to choose between the two, I'd go with heading.
>
> +1
>

+1

> If the community finds this valuable, I could prepare a patch.
>
> +1
>

+1

@André

> There's a problem though.  Function names would have to be changed,
> which would have to wait for version 10 otherwise we'd ruin backwards
> compatibility.

It doesn't have to break things drastically. When such changes are made,
you would define function aliases using `define-obsolete-function-alias'.
And then that obsoletion warning is removed after a few years.

Re: Comments break up a paragraph when writing one-setence-per-line

[Kaushal Modi]

Hello,


On Fri, Jul 16, 2021 at 12:35 PM Bruce D'Arcus  wrote:

> On Fri, Jul 16, 2021 at 12:07 PM William Denton  wrote:
>
> > However, I was a bit surprised when I found that a commented line starts
> a new
> > paragraph.
>
> I hadn't yet discovered that, but I think it should be considered a
> bug.


Comments causing paragraph breaks has been a long known behavior. I learned
about it few years back, probably from one of the threads here or by
reading the code.


> The output of your example should remove the commented line
> entirely, and so be:
>
> In this paragraph I introduce an idea.
> But I am sure about this. And here is my conclusion.
>
> Perhaps it can be easily fixed?
>

I don't think it would be a very easy fix as the behavior stems from an
intentional low level implementation in org-element.el. Changing this
behavior will cause a regression in all Org exporters out there.

Re: babel output seems to drop anything before % (in session)

[Kaushal Modi]

Hi Nick,

On Tue, Jun 8, 2021 at 11:54 PM Kaushal Modi  wrote:

>
> Thanks! I tried out your patch and it does fix the truncation of results
> output. Though, it retains the shell prompt in the first eval block and
> removes it only from the second eval block onwards.
>

I have one more feedback about the patch. I see that now indentation is
stripped away from ob-shell results.

I am documenting git commands in ob-shell.

In the terminal, `git log' outputs:

=
commit ba72672c499af8b713437d8c05eb5979969954dd (HEAD -> main)
Author: Foo Bar 
Date:   Tue Jun 8 23:56:48 2021 -0400

first commit
=

But in shell src block results, I see that that indentation is gone:

=
#+begin_src shell
git log
#+end_src

#+RESULTS:
:
: commit 34924761f042eab59567ec150a73c730ab2c929c (HEAD -> main)
: Author: Foo Bar 
: Date:   Tue Jun 8 23:56:48 2021 -0400
:
: first commit
=



Kaushal Modi

Re: babel output seems to drop anything before % (in session)

[Kaushal Modi]

On Thu, May 6, 2021 at 7:45 PM Nick Savage  wrote:

> So I have a patch written that doesn't completely fix the problem, but
> maybe makes enough progress that someone else can figure it out.
>
> The issue is that comint-prompt-regexp is reading the "% " as a prompt,
> and taking everyone off before it. I've added another parameter to
> org-babel-comint-with-output in the "meta" to pass our own regexp to
> replace comint-prompt-regexp, which works except when it doesn't. The
> regexp I've added is just "\n" now, so the newline characters are removed.
>
> The tests that Daniele added as a patch don't quite pass though with
> this. The issue is that something in the way the output is posted in the
> output buffer includes the prompt occasionally is included in a line and
> occasionally not. It seems the first time the block of code is executed,
> it is included (and therefore needs to be removed) and each other time
> it is not, so it is only the first time that it is run is not working
> properly.
>
> This is obviously way too fragile to actually merge, but I was hoping
> the work I've done so far is enough to help someone else make progress.
> I'll probably take another stab at this tomorrow (since it's bugging
> me), but thought I'd share what I have for now.
>
> Cheers,
> Nick
>

Thanks! I tried out your patch and it does fix the truncation of results
output. Though, it retains the shell prompt in the first eval block and
removes it only from the second eval block onwards.

Here's a MWE:

=
#+property: header-args:shell :exports both :results output :session
*ob-shell-session-issue*

#+begin_src shell
echo "1 > 0"
#+end_src

#+RESULTS:
:
: sh-4.2$ 1 > 0

#+begin_src shell
echo "1 > 0"
#+end_src

#+RESULTS:
:
: 1 > 0

#+begin_src shell
echo "1 > 0"
#+end_src

#+RESULTS:
:
: 1 > 0

#+begin_src shell
echo "1 > 0"
#+end_src

#+RESULTS:
:
: 1 > 0
=