Re: Clarification on blank lines following list items

[Tom Alexander]

Thank you so much for explaining all of that! There is some good information 
there I was missing. I think the most important bit I was missing is the 
post-blank stuff. I was only looking at begin->end but I think digging into the 
post-blank is what makes this consistent.

I've got 2 separate questions:

1. Is the following statement true? "Two elements can count the same character 
in their post-blank?"
I am seeing dual-ownership of the post-blank in the examples below, but at the 
same time if I put a plain-list inside a footnote definition, the footnote 
definition ends up with sole custody of the post-blank.

2. I'm still not sure about some behavior I'm seeing. I think it would be 
easiest to see if we focus on exactly 1 blank line:

```
1. bar
2. baz
   < this blank line here
ipsum
```

In this example, the blank line gets counted in the post-blank for the 
plain-list but not for the item:
```
plain-list: post-blank 1 | begin 1 end 16 | contents-begin 1 contents-end 15
item: post-blank 0 | begin 1 end 8 | contents-begin 4 contents-end 8
paragraph: post-blank 0 | begin 4 end 8 | contents-begin 4 contents-end 
8
item: post-blank 0 | begin 8 end 15 | contents-begin 11 contents-end 15
paragraph: post-blank 0 | begin 11 end 15 | contents-begin 11 
contents-end 15
paragraph: post-blank 0 | begin 16 end 22 | contents-begin 16 contents-end 22
```

but if we take that plain-list and nest it inside another plain-list:
```
1. foo
   1. bar
   2. baz
   < this blank line here
2. lorem
ipsum
```

The blank line gets counted as a post-blank for both the item "foo" and the 
item "baz":
```
plain-list: post-blank 0 | begin 1 end 38 | contents-begin 1 contents-end 38
item: post-blank 1 | begin 1 end 29 | contents-begin 4 contents-end 28
paragraph: post-blank 0 | begin 4 end 8 | contents-begin 4 contents-end 
8
plain-list: post-blank 0 | begin 8 end 29 | contents-begin 8 
contents-end 29
item: post-blank 0 | begin 8 end 18 | contents-begin 14 
contents-end 18
paragraph: post-blank 0 | begin 14 end 18 | contents-begin 14 
contents-end 18
item: post-blank 1 | begin 18 end 29 | contents-begin 24 
contents-end 28
paragraph: post-blank 0 | begin 24 end 28 | contents-begin 24 
contents-end 28
item: post-blank 0 | begin 29 end 38 | contents-begin 32 contents-end 38
paragraph: post-blank 0 | begin 32 end 38 | contents-begin 32 
contents-end 38
paragraph: post-blank 0 | begin 38 end 44 | contents-begin 38 contents-end 44
```

Meaning the post-blank did this movement:
```
plain-list: post-blank 0
item: post-blank 1   <---<<<-\
paragraph: post-blank 0  |
plain-list: post-blank 0 >>--|
item: post-blank 0   |
paragraph: post-blank 0  |
item: post-blank 1   <---<---/
paragraph: post-blank 0
item: post-blank 0
paragraph: post-blank 0
paragraph: post-blank 0
```


Question ---> So why is the item "baz" gaining a post-blank instead of the 
inner plain-list (bar baz) keeping that post-blank?

I would expect it to instead be:
```
plain-list: post-blank 0
item: post-blank 1
paragraph: post-blank 0
here -> plain-list: post-blank 1
item: post-blank 0
paragraph: post-blank 0
not here -> item: post-blank 0
paragraph: post-blank 0
item: post-blank 0
paragraph: post-blank 0
paragraph: post-blank 0
```

I re-did both test cases using greater blocks and lesser blocks instead of 
paragraphs to make sure it wasn't that historical exception at the end of your 
email, and the post-blank behavior was exactly the same.


-- 
Tom Alexander

Re: Maintenance status of individual Org libraries

[Matt]

  On Mon, 30 Jan 2023 14:41:18 +0100  Ihor Radchenko  wrote --- 

 > The following libraries have no maintainer or author active on the list:
 
 > ob-comint, ob-core, ...

I'm interested (and technically still maintainer of ob-shell). ob-comint and 
ob-core are both used by ob-shell, so I've looked at good bits of both.  I'd be 
willing to work on those.

Unfortunately, my new job has yet to sign the FSF disclaimer, so I'm unable to 
contribute at the moment (I'm doing what I can to facilitate communication 
between parties).  Feel free to reach out off-list with advice for how I might 
help that process.

Until the disclaimer language gets resolved, I may be able to help in other 
ways.  I have notes explaining the ob- API 
(https://lists.gnu.org/archive/html/emacs-orgmode/2023-02/msg00531.html).  
Maybe if that were completed, it would make being a maintainer more 
approachable for people?  I'd also be happy to mentor new maintainers.  What 
other ways might I help?

Re: [MAINTENANCE] Org orphanage?

[Hrvoje Nikšić]

Thanks, will continue there.

On Tue, Aug 15, 2023 at 6:11 PM Ihor Radchenko  wrote:

> Hrvoje Nikšić  writes:
>
> > Can we discuss the technical details in a separate email thread or
> ticket?
>
> I opened an issue on github:
> https://github.com/hniksic/emacs-htmlize/issues/47
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>

Re: [RFC] [feat] org-colview/org-columns: 'column view' moving rows up/down

[Ihor Radchenko]

Sławomir Grochowski  writes:

> I thought it would get lost in the many thousands of other TODOs you have
> on your plate.
> Thank you.

Merging contributed patches is high priority. I either have them
scheduled in agenda or they are the next thing to do upon clearing the
scheduled tasks.

The last thing I want is being a sole committer to Org.

> But to my another surprise you have fixed the bug that was killing me
> everyday 'org-insert-heading: Fix when folded text is kept right at the new
> heading'.
> Thank you very much.

A reproducer was provided :) So I was able to debug what was going on.

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

Re: [PATCH] ob-python results handling for dicts, dataframes, arrays, and plots

[Jack Kamm]

Liu Hui  writes:

> I think these objects need to be shown in a single column rather than
> two. Besides, if the python code becomes too complex finally, I think
> maintaining the python code outside the ob-python.el, as suggested by
> Ihor, is a good idea.

Thanks for reporting these misbehaving examples. I think the root of the
problem is `org-babel-script-escape', which is too aggressive in
recursively converting strings to lists. We may need to rewrite our own
implementation for ob-python.

Also, I agree that moving the python code to an external file will be
helpful in handling these more complex cases.

I may leave these tasks for future patches. In the meantime, we may have
to recommend ":results verbatim" for these more complex cases that
":results table" doesn't fully handle yet.

Re: [PATCH] ob-python results handling for dicts, dataframes, arrays, and plots

[Ihor Radchenko]

Jack Kamm  writes:

> In the meantime, I'm thinking to squash and apply my patch as is. Then
> afterwards, I can start working on a followup patch to move some Python
> code into a separate file (and coordinate with emacs-devel if
> necessary).

+1
Don't forget to update
https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-python.html
(note how the docs already have an example of org formatting from python)

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

Re: [PATCH] ob-python results handling for dicts, dataframes, arrays, and plots

[Ihor Radchenko]

Jack Kamm  writes:

> Ihor Radchenko  writes:
>
>> Similar to the existing LaTeX formatters, one may write a Python package
>> that will pretty-print Org markup as text.
>
> This sounds interesting -- are these LaTeX formatters external to Org?
> Could you provide a link/reference?

https://docs.sympy.org/latest/tutorials/intro-tutorial/printing.html
https://jeltef.github.io/PyLaTeX/current/examples/basic.html

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

Re: [PATCH] ob-python results handling for dicts, dataframes, arrays, and plots

[Jack Kamm]

Ihor Radchenko  writes:

> We might add the code into a separate proper python file. Then, we can
> use the contents of that file to retrieve the variable value.
>
> We already do the same thing for CSL style files and odt schema/style.

Thanks, I think this is a good idea, and will make the python code
easier to maintain.

And thanks also for the pointer to oc-csl and ox-odt -- I think I should
be able to implement this by following their example.

It seems like there will be an extra logistical step, to make sure the
extra python file is added to emacs as well. I'm not familiar with the
details of how we sync Org into Emacs, but will start to look into it.

In the meantime, I'm thinking to squash and apply my patch as is. Then
afterwards, I can start working on a followup patch to move some Python
code into a separate file (and coordinate with emacs-devel if
necessary).

Re: [PATCH] ob-python results handling for dicts, dataframes, arrays, and plots

[Jack Kamm]

Ihor Radchenko  writes:

> Similar to the existing LaTeX formatters, one may write a Python package
> that will pretty-print Org markup as text.

This sounds interesting -- are these LaTeX formatters external to Org?
Could you provide a link/reference?

Re: [RFC] [feat] org-colview/org-columns: 'column view' moving rows up/down

[Sławomir Grochowski]

I thought it would get lost in the many thousands of other TODOs you have
on your plate.
Thank you.

But to my another surprise you have fixed the bug that was killing me
everyday 'org-insert-heading: Fix when folded text is kept right at the new
heading'.
Thank you very much.

Regards,
Sławomir Grochowski


On Sun, Aug 20, 2023 at 12:43 PM Ihor Radchenko  wrote:

> Ihor Radchenko  writes:
>
> > I suspect that it is something with overlay boundaries. AFAIR, some org
> > subtree motion functions use `insert-before-markers', which may be
> > tricky when we insert right at the beginning/end of an overlay.
>
> It was totally unrelated bug on Org side.
> Applied, onto main, with minor amendments to function docstring and
> changelog format.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=650e42996
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=e08d87831
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>

Re: Question Regarding Routinely Importing Phone Note Org File Into Other Org File Under Subheadings

[Ihor Radchenko]

"Samuel Banya"  writes:

> In my actual phone notes file, I have this for an example:
>
> ```
>
> Title: 08-15-2023
>
> Recorded music
>
> ```
>
> With this in mind, how do I facilitate the ability to routinely ingest any of 
> the notes that are date based on the phone note title itself from Orgzly so 
> that it automatically determines the Monday of the given week, creates a 
> 'Week of (Starting Monday of that week)' subheading in the 'notes.org' file 
> and slams that new note in there?

You can use Elisp, for example.
1. Parse your note file to be ingested. You can use regular expressions.
2. Create a heading (using, for example lisp/org-datetree.el functions)
3. Put your note body under the heading.

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

Re: Inconvenient end-of-file behavior in org-mode 9.6 (emacs 29.1)

[Max Nikulin]

On 20/08/2023 13:32, Ihor Radchenko wrote:

Max Nikulin writes:


* Sec1
** SubSec1
** SubSec2
* |* Sec2


Wonderful... an no single test has failed.
Fixed the fix, on bugfix, adding a test for this.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=7b38670e6


Thank you, Ihor. It seems you have fixed the issue.

Question Regarding Routinely Importing Phone Note Org File Into Other Org File Under Subheadings

[Samuel Banya]

Hey there,

So I'm in the process of figuring out how I can sync my phone notes to my local 
file server with Syncthing occasionally. Basically 'phonenotes.org' from one 
machine to another. That being noted, I have another file called notes.org on 
my file server that basically lists completed tasks under a following format:

```

*COMPLETED TASKS 2023

** Week of 08-14-2023

*** Date

Completed task summary

```

In my actual phone notes file, I have this for an example:

```

Title: 08-15-2023

Recorded music

```

With this in mind, how do I facilitate the ability to routinely ingest any of 
the notes that are date based on the phone note title itself from Orgzly so 
that it automatically determines the Monday of the given week, creates a 'Week 
of (Starting Monday of that week)' subheading in the 'notes.org' file and slams 
that new note in there?

Sorry if it sounds complicated but I do this manually all the time and I wanted 
an easier way to do this programatically with Org Mode.

Thanks!

Re: [BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Dr. Arne Babenhauserheide]

Jonathan Gregory  writes:

> On 20 Aug 2023, Ihor Radchenko wrote:
>
>> Jonathan Gregory  writes:
>>
>>> ob-doc-lilypond.html looks good, but I changed lilypond.org in:
>>>
>>> https://git.sr.ht/~bzg/worg/commit/6b9da77c8078be183971575fdc79d402bf6184c2
>>
>>> -  b c d e
>>> +  b4 c d e
>>
>> Is there any specific reason for this change?
>
> This is to ensure that the notes use the correct duration in 
> arrange-mode. 4 is the default duration and is carried over until 
> a new value is added, in this case c1. 1 is then carried over 
> making all subsequent "e"s have a value of 1, which is incorrect.

This looks safe to me. Omitting the duration in the next line is a
mistake I made a few times, so I think it’s a good change to have.

Could you add a comment before the prologue-line
#+PROPERTY: header-args:lilypond :prologue (org-babel-ref-resolve "settings[]")
that this uses the source-block named settings?

Calling org-babel-ref-resolve directly there is something I have not
seen before so I think it won’t be obvious from the documentation.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de


signature.asc
Description: PGP signature

Re: [BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Jonathan Gregory]

On 20 Aug 2023, Ihor Radchenko wrote:


Jonathan Gregory  writes:


ob-doc-lilypond.html looks good, but I changed lilypond.org in:

https://git.sr.ht/~bzg/worg/commit/6b9da77c8078be183971575fdc79d402bf6184c2



-  b c d e
+  b4 c d e


Is there any specific reason for this change?


This is to ensure that the notes use the correct duration in 
arrange-mode. 4 is the default duration and is carried over until 
a new value is added, in this case c1. 1 is then carried over 
making all subsequent "e"s have a value of 1, which is incorrect.


#+begin_src lilypond
{
 b c c c c1
}
#+end_src

#+begin_src lilypond
{
 e e e e f1
}
#+end_src

In basic-mode it makes no difference, but that's assuming the 
default value never changes. BTW I prefer inline-mode over 
basic-mode, but I'll leave that for a future time.


--
Jonathan

Re: [PATCH] ob-python results handling for dicts, dataframes, arrays, and plots

[Liu Hui]

> > Here we can use '{}'.format(df.index.name) to show the name of index
>
> Patch has been updated to print the index name when it is non-None.

Thanks! It would be nice to also support MultiIndex names using
`result.index.names', e.g.

#+begin_src python :results table
import numpy as np
import pandas as pd

df = pd.DataFrame({
"A": ["foo", "bar", "foo", "bar", "foo", "bar", "foo", "foo"],
"B": ["one", "one", "two", "three", "two", "two", "one", "three"],
"C": np.random.randn(8),
"D": np.random.randn(8)})
return df.groupby(["A", "B"]).agg('sum').round(3)
#+end_src

Another problem is the display of objects like datetime, e.g.

#+begin_src python :results table
import pandas as pd
s = pd.Series(range(3), index=pd.date_range("2000", freq="D", periods=3))
return s.to_frame()
#+end_src

#+RESULTS:
|   | 0 |   |
|---+---+---|
| Timestamp | (2000-01-01 00:00:00 freq= D) | 0 |
| Timestamp | (2000-01-02 00:00:00 freq= D) | 1 |
| Timestamp | (2000-01-03 00:00:00 freq= D) | 2 |

#+begin_src python
from pathlib import Path
import numpy as np

return {'a': 1, 'path': Path('/'), 'array': np.zeros(3)}
#+end_src

#+RESULTS:
| a | 1 |   |
| path  | PosixPath | (/)   |
| array | array | ((0 0 0)) |

I think these objects need to be shown in a single column rather than
two. Besides, if the python code becomes too complex finally, I think
maintaining the python code outside the ob-python.el, as suggested by
Ihor, is a good idea.

Re: [RFC] [feat] org-colview/org-columns: 'column view' moving rows up/down

[Ihor Radchenko]

Ihor Radchenko  writes:

> I suspect that it is something with overlay boundaries. AFAIR, some org
> subtree motion functions use `insert-before-markers', which may be
> tricky when we insert right at the beginning/end of an overlay.

It was totally unrelated bug on Org side.
Applied, onto main, with minor amendments to function docstring and
changelog format.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=650e42996
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=e08d87831

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

Re: [Tip] Popup-menu with several actions for a link

[Juan Manuel Macías]

Ihor Radchenko writes:

>> ... Also, I don't usually use the mouse
>> much (actually I only use it in Gimp and the like) and the combination
>> of popup.el with hyperbole is more comfortable and keyboard-centric for
>> me.
>
> By default, context menu is bound to S-. Who cares about mouse XD

Oh I see. Very interesting. But I have seen that, at least by default,
there is no autocomplete feature. What I like about popup.el is, in
addition to autocompletion, the ability to easily create menus for
anything. Some time ago I defined a popup-menu[1] that shows me all the
header levels from where I am to the first one, defaulting to the
current level. It helps me situate myself in deep levels (other options
like imenu or org-sidebar give me too much information and I get lost).
I'm going to investigate if something similar can be done with
context-menu-mode...

Thank you for all the info!

[1] https://i.imgur.com/KoAZtIz.png
┌
│ (defun my-org-where-i-am-popup ()
│   (interactive)
│   (setq org-heading-titles-list nil)
│   (org-with-wide-buffer
│(save-excursion
│  (save-restriction
│(org-back-to-heading t)
│(if (eq (org-element-property :level (org-element-at-point)) 1)
│(message "First level")
│  (push (cons (org-link-display-format
│   (nth 4 (org-heading-components)))
│  (point))
│org-heading-titles-list)
│  (while
│  (ignore-errors (outline-up-heading 1 t))
│(push (cons (org-link-display-format
│ (nth 4 (org-heading-components)))
│(point))
│  org-heading-titles-list))
│   (org-with-wide-buffer
│(save-excursion
│  (save-restriction
│(goto-char
│ (popup-menu* (mapcar
│   (lambda (x)
│ (popup-make-item (car x) :value (cdr x)))
│   org-heading-titles-list)
│  :isearch t
│  :initial-index (length org-heading-titles-list)))
│(org-tree-to-indirect-buffer)
└

-- 
Juan Manuel Macías

https://juanmanuelmacias.com

https://lunotipia.juanmanuelmacias.com

https://gnutas.juanmanuelmacias.com

Re: [Bug] org-update-dblock randomly broken for more than 10 columns and larger files

[Ihor Radchenko]

Jakob Schöttl  writes:

> * Table
> #+BEGIN: columnview :format "%a %b %c %d %e %f %g %h"
> #+END:
> ** foo
> :PROPERTIES:
> :a: a
> :b: b
> :c: c
> :d: d
> :e: e
> :f: f
> :g: g
> :h: h
> :END:
>
> The first call to org-dblock-update adds some spaces and only has one 
> empty line of data in the table.
>
> The second call adds more spaces and has two lines of data in the table.

Thanks for the reproducer!
I committed a fix onto main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=58c5c5882

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

Re: [Bug] org-update-dblock randomly broken for more than 10 columns and larger files

[Jakob Schöttl]

Am 20.08.23 um 08:56 schrieb Ihor Radchenko:

Jakob Schöttl  writes:


So, org-update-dblock or org-dblock-write:columnview is adding trailing
spaces in the org file. These spaces change the behavior of subsequent
calls which will add even more spaces.

Confirmed.
Unimportant.


Got one:

* Table
#+BEGIN: columnview :format "%a %b %c %d %e %f %g %h"
#+END:
** foo
:PROPERTIES:
:a: a
:b: b
:c: c
:d: d
:e: e
:f: f
:g: g
:h: h
:END:


The first call to org-dblock-update adds some spaces and only has one 
empty line of data in the table.


The second call adds more spaces and has two lines of data in the table.

If %h is removed from :format, it works on the first run.

For larger files it's totally unreliable; I'd consider the columnview 
feature as broken.

Re: [Bug] org-update-dblock randomly broken for more than 10 columns and larger files

[Jakob Schöttl]

Am 20.08.23 um 08:56 schrieb Ihor Radchenko:

Jakob Schöttl  writes:


So, org-update-dblock or org-dblock-write:columnview is adding trailing
spaces in the org file. These spaces change the behavior of subsequent
calls which will add even more spaces.

Confirmed.
Unimportant.

The internal implementation details of colview demand heading text to
have at least the number of characters equal to the number of fields. If
there are less, spaces are added. But not beyond the necessary number of
spaces.

This is not easy to change.
And I am not sure if it is necessarily a bug, though I can see how it
can be slightly annoying.


The thing is, that this is only the smallest part of the bug. Spaces are 
not only added to headings but also to normal text lines and to ":END:" 
lines.


The spaces then lead to different table data in the dynamic block. I'll 
see if I can provide an example where it messes up the table data.

Re: [Tip] Popup-menu with several actions for a link

[Ihor Radchenko]

Juan Manuel Macías  writes:

>> Since Emacs 28, Emacs has built-in context menu. (terminal is also
>> supported) Moreover, major modes are encouraged to add support for
>> context menus.
>
> Thanks for the information. Do you mean context-menu-mode?

Yes.

> ... I'll keep an
> eye on it. When you say terminal support, do you mean terminal emulators
> or TTY?

Both.

> ... Also, I don't usually use the mouse
> much (actually I only use it in Gimp and the like) and the combination
> of popup.el with hyperbole is more comfortable and keyboard-centric for
> me.

By default, context menu is bound to S-. Who cares about mouse XD

>> May you explain more about how you attach to an email/upload?
>
> Sure! But they are very simple functions, which I don't use much.
> Although they work fine for what I want:
>
> The first requires the imgur.el package; the second one needs gnus-dired-mode:

I see. I thought that you are using built-in functionality.

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

Re: [BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Ihor Radchenko]

Jonathan Gregory  writes:

> ob-doc-lilypond.html looks good, but I changed lilypond.org in:
>
> https://git.sr.ht/~bzg/worg/commit/6b9da77c8078be183971575fdc79d402bf6184c2

> -  b c d e
> +  b4 c d e

Is there any specific reason for this change?

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

Re: [Bug] org-update-dblock randomly broken for more than 10 columns and larger files

[Ihor Radchenko]

Jakob Schöttl  writes:

> So, org-update-dblock or org-dblock-write:columnview is adding trailing 
> spaces in the org file. These spaces change the behavior of subsequent 
> calls which will add even more spaces.

Confirmed.
Unimportant.

The internal implementation details of colview demand heading text to
have at least the number of characters equal to the number of fields. If
there are less, spaces are added. But not beyond the necessary number of
spaces.

This is not easy to change.
And I am not sure if it is necessarily a bug, though I can see how it
can be slightly annoying.

If someone reading this is bothered about the current behaviour, feel
free to work on the fix.

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

[FR] Allow customizing blank lines in-between when creating footnote definitions (was: "Footnote" section line spacing is weird)

[Ihor Radchenko]

James Harkins  writes:

> Let's say I have, at the bottom of a document:
> ...
> Somewhere else in the document, I do C-c C-x f.
> ...
>
> [fn:-]
> [fn:..] lorem ipsum...
> ```
>
> I believe it would make more sense like this:
>
> ```
> * Footnotes
>
> [fn:-]
>
> [fn:..] lorem ipsum...
> ```

This is currently not customizeable.
If implemented, it can be an extension of the existing
`org-blank-before-new-entry' customization.

Patches welcome!

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

Re: Inconvenient end-of-file behavior in org-mode 9.6 (emacs 29.1)

[Ihor Radchenko]

Max Nikulin  writes:

>> Fixed, on bugfix.
>> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=52bc95676
>
> Ihor, I have tried "main" and I confirm that at the end of file behavior 
> has become better. Unfortunately newline is not added in the case of an 
> intermediate headings
> ...
> * Sec1
> ** SubSec1
> ** SubSec2
> * |* Sec2

Wonderful... an no single test has failed.
Fixed the fix, on bugfix, adding a test for this.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=7b38670e6

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