Re: [BUG] [PATCH] Add yank-media and DND handler [9.6.7 (9.6.7-g6eb773 @ /home/viz/lib/emacs/straight/build/org/)]

[Liu Hui]

Visuwesh  于2023年10月11日周三 23:36写道：

> >> + (caddr (read-multiple-choice
> >> + "What to do with dropped file?"
> >> + '((?a "attach" attach)
> >> + (?o "open" open)
> >> + (?f "insert file: link" file-link
> >
> > The dialog box is shown in the center of frame and I find it a little
> > inconvenient compared with a menu popped up just at the mouse
> > location. How about using x-popup-menu?
>
> But isn't that for menus?  I don't know how convenient is a menu
> compared to a dialog box.  But if the consensus is that a menu should be
> popped, then I will adjust the query to use rmc or menu as per
> use-dialog-box.

Thanks for consideration. I don't mean menu keymap but a pop-up menu
that simply returns a candidate, like

(x-popup-menu t
  (list "What to do with dropped file?"
(cons ""
  '(("Attach" . attach)
("Open" . open)
("Insert file: link" . file-link)

The menu is popped up at the location where the file is dropped, so
users only need to move the mouse slightly to select the desired
action, rather than always moving the mouse to the center of frame.

An example in dired mode is attached, and I feel it is a little more
convenient and efficient from the perspective of user interaction ;)

[BUG] org sub tree sort broken [9.7-pre (release_9.6.10-827-ge15699 @ /home/d/src/git-org-mode/lisp/)]

[Daniel Ortmann]

Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See

https://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org mailing list.


Create a test-of-org-sort.org file with the following content:
* top
** one
** two
** three

Click mouse-1 on the top heading.

Press C-c ^ a
... to attempt to sort the sub headings alphabetically.

The result is:
Sort children: [a]lpha [n]umeric [p]riority p[r]operty todo[o]rder [f]unc
[t]ime [s]cheduled [d]eadline [c]reated cloc[k]ing
A/N/P/R/O/F/T/S/D/C/K means reversed:
Sorting entries...
org-element--generate-copy-script: Symbol\u2019s function definition is 
void: org-export--list-bound-variables



Emacs : GNU Emacs 30.0.50 (build 37, x86_64-pc-linux-gnu, GTK+ Version 
3.24.37, cairo version 1.16.0)

of 2023-10-11
Package: Org mode version 9.7-pre (release_9.6.10-827-ge15699 @ 
/home/d/src/git-org-mode/lisp/)

--
Daniel Ortmann  612-518-3147 m
key: C9E170E2, fingerprint = 81BB 6CAF F1EC F6C7 690C F4E9 66D7 7AFD 
C9E1 70E2

Comments following not-really-affiliated keywords are becoming paragraphs

[Tom Alexander]

Emacs version: 29.1
Org-mode version: e1569918cc94253650781e83a09695739c93352f (latest in git)

Test document:
```
#+CAPTION: foo
# bar
```

This parses as a paragraph with the caption of foo and the body of "# bar" when 
it should parse as a regular keyword followed by a comment.

Relevant org-syntax[1] bit:

> a keyword with the same KEY as an affiliated keyword may occur so long as it 
> is not immediately preceding a valid element that can be affiliated. For 
> example, an instance of #+caption: hi followed by a blank line will be parsed 
> as a keyword, not an affiliated keyword.


[1] https://orgmode.org/worg/org-syntax.html#Keywords

--
Tom Alexander
pgp: https://fizz.buzz/pgp.asc

Org-mode starting with 37d6bde27 errors out parsing org-mode/testing/examples/pub/a.org

[Tom Alexander]

Steps to reproduce:
 1. Build emacs 29.1
 2. Build org-mode with revision 37d6bde27fe228cdadcb5cdaa09287872a508777
 3. Run the following:
```
emacs -q --no-site-file --no-splash --batch --eval "(progn
 (require 'org)
 (setq vc-handled-backends nil)
 (find-file-read-only \"org-mode/testing/examples/pub/a.org\")
 (org-mode)
 (message \"%s\" (pp-to-string (org-element-parse-buffer)))
)"
```

I've attached a Dockerfile that reproduces the issue. Just throw that in a 
directory and run `docker build -t temp .` to see it fail. Change the `ARG 
ORG_VERSION=` line to `ac108a3ac1b332bf27ff2984a9cf26af3744185d` to see it 
succeed.

Error message:
```
File mode specification error: (void-function org-export--list-bound-variables)

Error: void-function (org-export--list-bound-variables)
  mapbacktrace(#f(compiled-function (evald func args flags) #))
  debug-early-backtrace()
  debug-early(error (void-function org-export--list-bound-variables))
  org-export--list-bound-variables()
  org-element--generate-copy-script(# :copy-unreadable 
do-not-check :drop-visibility t :drop-narrowing t :drop-contents t :drop-locals 
nil)
  org-element-copy-buffer(:to-buffer # :drop-visibility t 
:drop-narrowing t :drop-contents t :drop-locals nil)
  org-element-parse-secondary-string("<2014-03-04 Tue>" (bold citation code 
entity export-snippet inline-babel-call inline-src-block italic line-break 
latex-fragment link macro radio-target statistics-cookie strike-through 
subscript superscript target timestamp underline verbatim))
  org-macro--find-date()
  org-macro--collect-macros()
  org-macro-initialize-templates()
  org-mode()
  (progn (require 'org) (setq vc-handled-backends nil) (find-file-read-only 
"/input/home/talexander/git/org-mode/testing/examples/pub/a.org") (org-mode) 
(message "%s" (pp-to-string (org-element-parse-buffer
  command-line-1(("--no-splash" "--eval" "(progn\n (require 'org)\n 
(setq vc-handled-backends nil)\n (find-file-read-only 
\"/input/home/talexander/git/org-mode/testing/examples/pub/a.org\")\n 
(org-mode)\n (message \"%s\" (pp-to-string 
(org-element-parse-buffer)))\n)"))
  command-line()
  normal-top-level()
Symbol’s function definition is void: org-export--list-bound-variables
```

--
Tom Alexander
pgp: https://fizz.buzz/pgp.asc


Dockerfile
Description: Binary data

Document-level properties incorrect and/or missing based on preceding blank lines and/or comments

[Tom Alexander]

Emacs version: Emacs 29.1
Org-mode version: e1569918cc94253650781e83a09695739c93352f  (latest in git)

The org-mode syntax document[1] says that property drawers can exist in the 
zeroth section with the format:
```
BEGINNING-OF-FILE
BLANK-LINES
COMMENT
PROPERTYDRAWER
```

Using this test document:
```
:PROPERTIES:
:FOO:bar
:END:
```

I correctly get the foo property in the top-level org-data
```
(org-data
(:standard-properties
  [1 1 1 33 33 0 nil org-data nil nil nil 32 33 nil # nil nil 
nil]
  :path nil :FOO "bar" :CATEGORY nil)
```

But now there are two separate issues:

### Issue 1

Putting a comment before it makes the value for the foo property incorrect 
(seems to be grabbing an earlier string slice):
```
# baz
:PROPERTIES:
:FOO:bar
:END:
```

```
(org-data
(:standard-properties
  [1 1 1 39 39 0 nil org-data nil nil nil 38 39 nil # nil nil 
nil]
  :path nil :FOO "O: " :CATEGORY nil)
```

Interestingly, looking farther down the AST, the value for foo is properly set 
in the node-property, just not the org-data:
```
(node-property
(:standard-properties
 [20 20 nil nil 33 0 nil node-property nil nil nil nil nil nil # nil nil #2]
 :key "FOO" :value "bar"))
```

### Issue 2

Putting any blank lines before it makes the foo property not appear in org-data 
at all
```

:PROPERTIES:
:FOO:bar
:END:
```

```
(org-data
(:standard-properties
  [1 1 2 34 34 0 nil org-data nil nil nil 4 34 nil # nil nil 
nil]
  :path nil :CATEGORY nil)
```

Looking farther down the AST it seems the property-drawer became a regular 
drawer


[1] https://orgmode.org/worg/org-syntax.html#Property_Drawers

--
Tom Alexander
pgp: https://fizz.buzz/pgp.asc

Re: Exporting elisp: and shell: links

[Rudolf Adamkovič]

Ihor Radchenko  writes:

> I am not sure if I like it.

Me neither.  The problem is in the parentheses, IMHO.  The Lisp
expression is enclosed in parentheses and so is the description:

  (message "Hello") (Message Hello)

That indeed looks confusing!  How about we swap the sides and remove one
pair of parentheses?  That would give:

  Message Hello (message "Hello")

Rudy
-- 
"Genius is 1% inspiration and 99% perspiration."
-- Thomas Alva Edison, 1932

Rudolf Adamkovič  [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

Re: Pandoc and nested emhases

[Max Nikulin]

It was long time ago...

On 18/02/2022 07:47, Juan Manuel Macías wrote:

Otherwise, if you export to LaTeX with pandoc (v. 2.14.2), the result is
(to my surprise) correct:

#+begin_src sh :results latex
str="/lorem /ipsum/ dolor/"
pandoc -f org -t latex <<< $str
#+end_src

#+RESULTS:
#+begin_export latex
\emph{lorem \emph{ipsum} dolor}
#+end_export


Nesting of the same emphasis style may be achieved with Org parser as well:

(org-export-string-as
 "/lorem /ipsum// /dolor/"
 'latex t)
"\\emph{lorem \\emph{ipsum}} \\emph{dolor}
"

Namely closing markers should be combined. See the recent thread
Tom Alexander to emacs-orgmode. Inconsistent text markup handling when 
double-nesting markers. Mon, 09 Oct 2023 19:02:18 -0400.

https://list.orgmode.org/dad964f5-c764-4dd5-9829-ca38e3fbe...@app.fastmail.com

Re: [BUG] [PATCH] Add yank-media and DND handler [9.6.7 (9.6.7-g6eb773 @ /home/viz/lib/emacs/straight/build/org/)]

[Visuwesh]

[புதன் அக்டோபர் 11, 2023] Liu Hui wrote:

> Hi,
>
> Thanks for your work. I have two minor suggestions about the patch.
>
>> + (`file-link
>> + (let ((filename (dnd-get-local-file-name url)))
>> + (insert (org-link-make-string (concat "file:" filename
>
> I think it is better to abbreviate the file name for file-link, so it
> would be consistent with org-insert-link.

OK, will do.

>> + (caddr (read-multiple-choice
>> + "What to do with dropped file?"
>> + '((?a "attach" attach)
>> + (?o "open" open)
>> + (?f "insert file: link" file-link
>
> The dialog box is shown in the center of frame and I find it a little
> inconvenient compared with a menu popped up just at the mouse
> location. How about using x-popup-menu?

But isn't that for menus?  I don't know how convenient is a menu
compared to a dialog box.  But if the consensus is that a menu should be
popped, then I will adjust the query to use rmc or menu as per
use-dialog-box.

Re: [the cryptic @@#$7]

[Uwe Brauer]

> Uwe Brauer  writes:

> The ref "remote(table1,@2$7..@>$7)" targets a range, containing all fields of
> colum 7.  So, for each field, you get the same value: an array
> containing all the field values: [22, 19, 19].



> See (info "(org) References"), in the section:
>"Field coordinates in formulas"

> "‘@#’ is substituted with the row number of the field where the
> current result will go to".



> With this formula, your remote reference targets the field, that is in
> the same row number as the computed field in final.

> Here is the same table, with some extra columns that show the
> intermediate steps:

>#+Name: final2
>| Name   | Some | ResSh1 | What is '@#'? | Which ref? |

>|+--++---+|
>| Smith  |4 | 22 | 2 | @2$7   |
>| Miller |4 | 19 | 3 | @3$7   |
>| Wick   |4 | 18 | 4 | @4$7   |
>|+--++---+|

>#+TBLFM: @2$3..@>$3=remote(table1,@@#$7)
>#+TBLFM: @2$4..@>$4=@#

>#+TBLFM: @2$5..@>$5='(concat "@" (format "%d" @#) "$" "7")


Here is an example where the org-lookup-first method seems to fail

#+begin_src 

#+Name: Table1A
| / | <>   |  <> |  <> |  <> |  <> |  <> |<> |
|   | Name | Ex1 | Ex2 | Ex2 | Ex4 | Ex5 | E1Tot |
|---+--+-+-+-+-+-+---|
|   | Smith|   2 |   3 |   4 |   6 |   7 |22 |
|   | Brown|   7 |  10 |   3 |   4 |  12 |36 |
|   | Graham   |   4 |   5 |   1 |  10 |   7 |27 |
|   | Jones|  14 |   9 |   1 |   8 |  13 |45 |
|   | Thompson |  14 |   4 |  11 |   9 |  11 |49 |
|   | Walker   |   3 |  11 |   5 |   3 |   6 |28 |
#+TBLFM: $8=vsum($3..$7);f2

#+Name: Table2A
| / | <>   |  <> |  <> |  <> |  <> |  <> |<> |
|   | Name | Ex1 | Ex2 | Ex2 | Ex4 | Ex5 | E2Tot |
|---+--+-+-+-+-+-+---|
|   | Smith|   1 |   3 |   5 |   8 |   9 |26 |
|   | Brown|  14 |   9 |  10 |   3 |   8 |44 |
|   | Graham   |   5 |  14 |   1 |   5 |   6 |31 |
|   | Jones|  11 |  11 |   3 |   1 |   9 |35 |
|   | Thompson |   7 |  10 |   3 |   9 |   5 |34 |
|   | Walker   |   2 |   3 |   3 |  10 |   2 |20 |
#+TBLFM: $8=vsum($3..$7);f2


#+Name: Final1A
| / | <>   | <>| <>| <>|
|   | Name | E1Tot | E2Tot | Total |
|---+--+---+---+---|
|   | Smith| nil   | nil   | 2 nil |
|   | Brown| nil   | nil   | 2 nil |
|   | Graham   | nil   | nil   | 2 nil |
|   | Jones| nil   | nil   | 2 nil |
|   | Thompson | nil   | nil   | 2 nil |
|   | Walker   | nil   | nil   | 2 nil |
#+TBLFM: $3='(org-lookup-first $2 '(remote(Table1A, @I$1..@II$1)) 
'(remote(Table1A, @I$7..@II$7)))::$4='(org-lookup-first $2 '(remote(Table2A, 
@I$1..@II$1)) '(remote(Table2A, @I$7..@II$7)))::$5=vsum($3..$4);f2


#+Name: Final2A
| / | <>   |<> |<> |<> |
|   | Name | E1Tot | E2Tot | Total |
|---+--+---+---+---|
|   | Smith|22 |26 |48 |
|   | Brown|36 |44 |80 |
|   | Graham   |27 |31 |58 |
|   | Jones|45 |35 |80 |
|   | Thompson |49 |34 |83 |
|   | Walker   |28 |20 |48 |
#+TBLFM: 
$5=vsum($3..$4);f2::@3$3..@>$3=remote(Table1A,@@#$8)::@3$4..@>$4=remote(Table2A,@@#$8)




#+Name: Final3
| / | <>   |<> |<> |<> |
|   | Name | E1Tot | E2Tot | Total |
|---+--+---+---+---|
|   | Smith|22 |26 |48 |
|   | Brown|36 |44 |80 |
|   | Graham   |27 |31 |58 |
|   | Jones|45 |35 |80 |
|   | Thompson |49 |34 |83 |
|   | Walker   |28 |20 |48 |
#+TBLFM: $3=remote(Table1A,@@#$8)::$4=remote(Table2A,@@#$8)::$5=vsum($3..$4);f2
#+end_src






> Bruno






-- 
Warning: Content may be disturbing to some audiences
I strongly condemn Hamas terroristic attack on Israel.
I strongly condemn Putin's war of aggression against Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the NATO membership of Ukraine.
I support the EU membership of Ukraine. 
https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/


smime.p7s
Description: S/MIME cryptographic signature

Re: Inconsistent text markup handling when double-nesting markers

[Tom Alexander]

> Fixed, on main.

Thanks!

--
Tom Alexander
pgp: https://fizz.buzz/pgp.asc

Re: COUNTER-SET for alphabetical ordered lists ignored for utf-8 exporter

[Tom Alexander]

Thanks!

> We aim to reduce config-dependent Org syntax in the long term.

Thats wonderful news! Sometimes this stuff can really surprise you. For 
example, the structure of the document created by running `echo "1. foo\n 
1.bar\n1.baz\n\t1.lorem"` changes based on the user's **tab-width**!!

If tab-width is less than 8 then this is:
```text
1. foo
  1. bar
1. baz
  2. lorem
```

If tab-width is 8 then this is:
```text
1. foo
  1. bar
1. baz
2. lorem
```

and if tab-width is greater than 8 this is:
```text
1. foo
  1. bar
1. baz
  1. lorem
```

Absolute madness! I always considered tab-width to be a personal aesthetic 
choice and not something that would functionally change how documents other 
people wrote will be parsed.

Idk if its been discussed, but personally if I were given dictatorship over 
org-mode I would take all of these emacs variables that are defined outside of 
the document, and instead of having them influence org-mode directly, I would 
*only* use them to pre-populate values for in-buffer settings templates.

For example, if a user had set `org-odd-levels-only` then I wouldn't have that 
impact ANY existing document they open, but if they open a new document then I 
would have it auto-insert `#+STARTUP: odd` at the top of the fresh document.

Otherwise it seems like org-mode is unsuitable for multi-person collaboration 
without dictating the contents of everyone's `.emacs` file.

--
Tom Alexander
pgp: https://fizz.buzz/pgp.asc

Re: [BUG] [PATCH] Add yank-media and DND handler [9.6.7 (9.6.7-g6eb773 @ /home/viz/lib/emacs/straight/build/org/)]

[Liu Hui]

Hi,

Thanks for your work. I have two minor suggestions about the patch.

> + (`file-link
> + (let ((filename (dnd-get-local-file-name url)))
> + (insert (org-link-make-string (concat "file:" filename

I think it is better to abbreviate the file name for file-link, so it
would be consistent with org-insert-link.

> + (caddr (read-multiple-choice
> + "What to do with dropped file?"
> + '((?a "attach" attach)
> + (?o "open" open)
> + (?f "insert file: link" file-link

The dialog box is shown in the center of frame and I find it a little
inconvenient compared with a menu popped up just at the mouse
location. How about using x-popup-menu?

Re: Inconsistent text markup handling when double-nesting markers

[Ihor Radchenko]

Max Nikulin  writes:

>> No, **bold** it is not a bug. The parser is recursive with inner markup
>> not "seeing" its parent. So, we first parse the outer bold and then
>> continue parsing the contents separately, as *bold*.
>
> I just find the following rather confusing:
>
> (org-export-string-as "**bold**" 'html t)
> "\nbold\n"
> (org-export-string-as "**inner* outer*" 'html t)
> "\n*inner outer*\n"
> (org-export-string-as "*outer *inner**" 'html t)
> "\nouter inner\n"
> (org-export-string-as "*begin *inner* end*" 'html t)
> "\nbegin *inner end*\n"

Maybe. It is indeed one of the edge cases. But it is following the
parser logic, which is (1) first matching markup is parser; (2) parsing
recursive contents is isolated.

>> Be it another way, /*bold italic*/ would also not be allowed as
>> we demand bol, whitespace, -, (, {, ', or " before the markup:
>> https://orgmode.org/worg/org-syntax.html#Emphasis_Markers
>
> Certainly /*b*/ should work, but nested bold was a surprise for me. I 
> believed that nesting is strictly prohibited. The case of underscores is 
> even more tricky due to ambiguity of underline and subscript.

It is not strictly prohibited on purpose. It is just a consequence of
how the parser works that nesting  constructs is almost impossible,
except certain edge cases like **b**.

> P.S. Juan Manuel at certain moment discovered that pandoc allows nesting 
> for *b1 *b2* b3*.

Which is a bug in pandoc.

I think we discussed this topic a number of times in the past - our
markup is a compromise between simplicity for users and simplicity of
the parser. This works in many simple cases, but edge cases become
problematic.

Workarounds have been discussed as well. For example, creole markup and
generic inline markup constructs (your idea with direct AST and the idea
with inline special blocks).

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

Re: Inconsistent text markup handling when double-nesting markers

[Max Nikulin]

On 11/10/2023 16:15, Ihor Radchenko wrote:

Max Nikulin  writes:


Isn't nested bold for "**bold**" a bug? Generally it is not allowed and

   *b1 *b2* b3*

is parsed as bold only for "b1 *b2".


No, **bold** it is not a bug. The parser is recursive with inner markup
not "seeing" its parent. So, we first parse the outer bold and then
continue parsing the contents separately, as *bold*.


I just find the following rather confusing:

(org-export-string-as "**bold**" 'html t)
"\nbold\n"
(org-export-string-as "**inner* outer*" 'html t)
"\n*inner outer*\n"
(org-export-string-as "*outer *inner**" 'html t)
"\nouter inner\n"
(org-export-string-as "*begin *inner* end*" 'html t)
"\nbegin *inner end*\n"


Be it another way, /*bold italic*/ would also not be allowed as
we demand bol, whitespace, -, (, {, ', or " before the markup:
https://orgmode.org/worg/org-syntax.html#Emphasis_Markers


Certainly /*b*/ should work, but nested bold was a surprise for me. I 
believed that nesting is strictly prohibited. The case of underscores is 
even more tricky due to ambiguity of underline and subscript.


P.S. Juan Manuel at certain moment discovered that pandoc allows nesting 
for *b1 *b2* b3*.

Re: Inconsistent text markup handling when double-nesting markers

[Ihor Radchenko]

Max Nikulin  writes:

> Isn't nested bold for "**bold**" a bug? Generally it is not allowed and
>
>   *b1 *b2* b3*
>
> is parsed as bold only for "b1 *b2".

No, **bold** it is not a bug. The parser is recursive with inner markup
not "seeing" its parent. So, we first parse the outer bold and then
continue parsing the contents separately, as *bold*.

Be it another way, /*bold italic*/ would also not be allowed as
we demand bol, whitespace, -, (, {, ', or " before the markup:
https://orgmode.org/worg/org-syntax.html#Emphasis_Markers

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

Re: [BUG] Warning when creating preview

[Ihor Radchenko]

Edgar Lux  writes:

> Emacs  : GNU Emacs 28.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.36, 
> cairo version 1.17.6)
>  of 2023-01-03

Hopefully, fixed now.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=37d6bde27

(the reproducer was found in a private email thread, and is not public)

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

Re: org-agenda t giving "Wrong type argument: stringp, nil"

[Ihor Radchenko]

William Denton  writes:

> I updated things from source today and got an error when trying to view my 
> agenda:
>
> M-x org-agenda
> t
>
> showed the error
>
> Wrong type argument: stringp, nil
>
> In *Messages* I saw:
>
> Press key for agenda command (unrestricted):
> org-agenda-get-todos: Wrong type argument: stringp, nil

Thanks for reporting!
I am unable to reproduce the problem on my side, unfortunately.
May you enable `debug-on-error' and post the backtrace? Or provide a
reproducer.

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

Re: [BUG] Inactive interval is not correctly displayed in agenda view (was: [BUG?] Org-agenda doesn't work with this error : Search failed: "\]+\)>")

[Ihor Radchenko]

Ihor Radchenko  writes:

>> if I have the following heading :
>>
>> * A test
>>  [2023-10-10 Tue 17:25]--[2023-10-10 Tue 17:30]
>>  <2023-10-10 Tue 17:25>--<2023-10-10 Tue 17:30>
>>
>> The "org interval" are not respected for the inactive timestamp. See what
>> is the result in org-agenda :
>>
>>  17:25-17:30   A test
>>  17:25-17:25  [ A test
>>  17:30-17:30  [ A test
>>
>> The first line is what I want : a beginning hour, with a end. But, the two
>> other are not normal : it must be the same line.
>
> I can reproduce. Indeed looks odd.
> I will look closer at this problem later.

Fixed, on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=e1569918c

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

Re: [BUG] No newline at end of exported HTML file [9.6.6 (release_9.6.6 @ /Applications/MacPorts/Emacs.app/Contents/Resources/lisp/org/)]

[YE]

> Bruno Barbier  writes:

> The change seems to come from this commit:
>
>commit d7a55bbd537314d2776b082bd92a1a08b3edc84e
>Date:   Wed Sep 28 12:07:14 2022 +0800
>org-latex-export-to-latex: Do not suppress major modes in babel
>
Thank you for finding the culprit.

> Ihor Radchenko  writes:
> See the attached tentative patch.

Thanks, LGTM so far.