Re: bug#68687: [PATCH] Use text/org media type

[Eli Zaretskii]

> From: Richard Stallman 
> Cc: e...@gnu.org, maniku...@gmail.com, 68...@debbugs.gnu.org,
>   emacs-orgmode@gnu.org, stefankan...@gmail.com
> Date: Thu, 01 Feb 2024 22:40:06 -0500
> 
>   > It may or may not depending on user customization `mm-inline-media-tests'.
>   > Just like with text/html, application/javascript, text/x-sh, images,
>   > etc.
> 
> I looked at the definition of that option, and at the function
> `mm-display-inline-fontify' that it calls.  That function is
> nontrivial, so I can't tell, in a short time, what it does and doesn't
> do.

AFAIU, that function copies a portion of buffer text to a temporary
buffer, determines the correct major-mode for that text, then invokes
that major-mode and fontifies the text according to that mode, and
finally copies the fontified text back into the original buffer.

Re: bug#68687: [PATCH] Use text/org media type

[Stefan Kangas]

Max Nikulin  writes:

> On 01/02/2024 03:00, Stefan Kangas wrote:
>> Max Nikulin writes:
>>> +++ b/lisp/net/mailcap.el
>>> @@ -989,7 +989,8 @@ (defvar mailcap-mime-extensions
>>>   (".jpe"   . "image/jpeg")
>>>   (".jpeg"  . "image/jpeg")
>>>   (".webp"  . "image/webp")
>>> -(".org"   . "text/x-org"))
>>> +;; May be overridden by application/vnd.lotus-organizer in 
>>> /etc/mime.types.
>>> +(".org"   . "text/org"))
>
> Org files are plain text files and have no specific signature that would
> allow tools like libmagic to unambiguously distinguish them from other
> text files. Rare files have explicit "# -*- mode: org-mode -*-" header.
> So there is no other way besides file name extensions when a message is
> composed or a file is served by a HTTP server. Clients should rely on
> the Content-Type header.

So old mailers will still use "Content-Type: text/x-org", and it is
therefore premature to remove that entry.

I'm not sure about the urgency in starting to send out "text/org" at
this stage.  It will just lead to old versions of Emacs displaying org
attachments incorrectly in more cases, I think?

So why not:

 1. Add support for _receiving_ "text/org" in Emacs 30
 2. Wait with _sending_ "text/org" until it is formally accepted by IANA

?

In Emacs <29, perhaps Org mode could update the relevant variables to
include "text/org", too?

>> Is it
>> documented somewhere how to override that system configuration in Emacs?
>
> Create ~/.mime.types. Debian's variant suggests it in the
> /etc/mime.types header.

Is that documented somewhere in our documentation?

>> But thinking about this more, why not do that unconditionally for users?
>> Lotus Organizer is dead, long gone, and not really relevant to anyone,
>> certainly not to the overwhelming majority of Emacs users.
>
> Ideally text/org should be registered in IANA, so all applications could
> use consistent mapping. Prerequisites have been discussed already.

Yes, that would be best.  While waiting for that to happen, why not do
what I proposed (override it unconditionally in Emacs)?  It should be
more useful for Emacs users, if nothing else.

Taking a step back, how sure are we that IANA will accept this?  Do they
typically accept taking over a previous designation?

[BUG] Newlines after links are fontified with the org-link face after an incremental search

[Rohit Patnaik]

Hello everyone,

I've noticed a potential regression in the way that org-mode fontifies links in
the latest git main branch version of org-mode. When the user conducts an
incremental search that matches a link that runs to the end of the line, for 
some reason the =org-link= face is extended to cover the newline as well.

Detailed repro steps:
1. Run =make repro= from the =main= branch
2. Switch the scratch buffer to org-mode with =M-x org-mode=
3. Add two lines
   - The first line should be a link, for example:
 [[https://www.google.com][Link]]
   - The second line should be a blank line
4. Place the point at the beginning of the first line
5. Hit =C-s= to begin an incremental search and search for the link description
   (i.e. =Link=)
6. Hit =RET= to leave the search
7. Note that the link underline now seems to extend past the end of the link
   text
8. Place the point at the end of the line and hit =M-x describe-char=. You
   should see that the character is a =C-j=, and the face is =org-link=

The above result does not occur when I check out the =release_9.6.17= tag, which
is why I think it might be a regression. 

My version of emacs is: 

GNU Emacs 29.1 (build 2, x86_64-pc-linux-gnu, X toolkit, cairo version 1.17.8, 
Xaw3d scroll bars) of 2023-08-02

My operating system is Fedora Linux 39, running Gnome 45.3 on Wayland.

Thanks,
Rohit Patnaik

Re: bug#68687: Org mode code evaluation

[Max Nikulin]

On 02/02/2024 10:38, Richard Stallman wrote:


   > I did not imply that Org mode is safe. I directly said that there are
   > security issues and that they are known.

Could you plesae post a pointer to a desciption of them?


I would strongly prefer to move discussion of Org security to a 
dedicated thread on emacs-orgmode or emacs-devel and leave this bug to 
media types used for Org.


Whenever the suggested patch committed (as a whole or in parts) or not, 
admit that Org mode is already used as media type handler for mail 
messages and downloaded files.


I have tried a couple more ideas, but have not managed to achieve code 
execution when files are loaded (assuming default or plausible user 
settings). If Org keystrokes are not active when mail messages are 
opened then it should be safe enough. (However I suspect an issue 
unrelated to code execution.) If Emacs or Org mode has severe issues 
then it is possible to exploit them even without the patch. Just send a 
message having 3 attachments covering all variants of Content-Type.


The point is to minimize discrepancy related to Org mode stuff within 
Emacs and outside of it. E.g. in default configuration Thunderbird on 
Debian 12 bookworm sends attachments as text/org. Emacs core uses 
text/x-org or application/vnd.lotus-organizer. With no action taken it 
will last further.

Re: Should org-link-parser add type "file" when link has no "file:" prefix?

[joseph]

February 1, 2024 at 4:23 AM, "Ihor Radchenko"  wrote:



> 
> jos...@ushin.org writes:
> 
> > 
> > > 
> > > > > What we can do then is pass an extra argument to :follow function - 
> > > > > the
> > > 
> > >  > > link object. That way, :follow function can get all the information 
> > > it
> > > 
> > >  > > needs.
> > > 
> > >  > > 
> > > 
> > >  > 
> > > 
> > >  > I like this idea! Would this change break existing :follow functions
> > > 
> > >  > which only expect max two args?
> > > 
> > >  > 
> > > 
> > >  
> > > 
> > >  No. We can preserve backwards-compatibility by checking :follow function
> > > 
> > >  arity and only passing the extra argument with the :follow function
> > > 
> > >  supports that many arguments.
> > > 
> > 
> >  Good to know. If the goals of hyperdrive.el can be accomplished without 
> > adding complexity to Org mode, it may be best to avoid avoid adding another 
> > argument to :follow functions. WDYT?
> > 
> 
> I did not make any changes to Org mode. And I will not, unless we need
> 
> to pass this extra information to :follow functions.

Thank you!  I think we can close this issue.  Can I close the issue myself?

> -- 
> 
> Ihor Radchenko // yantar92,
> 
> Org mode contributor,
> 
> Learn more about Org mode at  https://orgmode.org/%3E .
> 
> Support Org development at , 
> https://liberapay.com/org-mode%3E, 
> 
> or support my work at  
> https://liberapay.com/yantar92%3E
>

Re: bug#68687: [PATCH] Use text/org media type

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > It may or may not depending on user customization `mm-inline-media-tests'.
  > Just like with text/html, application/javascript, text/x-sh, images,
  > etc.

I looked at the definition of that option, and at the function
`mm-display-inline-fontify' that it calls.  That function is
nontrivial, so I can't tell, in a short time, what it does and doesn't
do.

  > Even when text/org is rendered using Org mode, there is nothing
  > pressuring people to use Org mode there. It is just visuals. Org major
  > mode is not activated.

That is one good thing.  Maybe that means it's fine.

But you've told me little about what things `mm-display-inline-fontify' does,
only that they do not include selecting Org mode.

Could you please tell me the main things it _does_ do?

  > Max is referring to various security issues with evaluating code inside
  > Org mode buffers. They are known, but not relevant to Org text being
  > displayed in email MUA - Org never evaluates any code automatically
  > without user explicitly asking for it.

I understand now.  I agree, that is not an issue for this specific point.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: bug#68687: Org mode code evaluation (was: bug#68687: [PATCH] Use text/org media type)

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I did not imply that Org mode is safe. I directly said that there are
  > security issues and that they are known.

Could you plesae post a pointer to a desciption of them?
-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: org-icalendar export problems

[Ypo]

I got org updated, following Ihor's instructions: Org mode version 
9.7-pre (release_N/A-N/A-afc529 @ ./org-9.7pre0.20240130.161905/)


If I were able to fulfill a good process to export from agenda to 
icalendar, maybe we could share an easy process, useful for a lot of 
users that miss a good android calendar visualization. Do you think it 
could be possible to export, in an async way, a calendar file every time 
when a new timestamp, Schedule or Deadline are added to a buffer? What 
would happen if an export process is already running and a new timestamp 
is added? Would it be robust enough or prone to errors? I can see that 
even if a footnote is not correct, the process seems to be interrupted.


Actual state: when I try to export to icalendar, the behavior is quite 
confusing:


+ [c] Combine all agenda files: I don't get any ics file. I don't know 
what is the problem.


+ [a] All agenda files: I get just an ics file. I thought I would get 
one file for each agenda file.


Best!

On 30/01/2024 5:13, Jack Kamm wrote:

ypuntot  writes:


Problem! Found 1 error

Errors
Lines not delimited by CRLF sequence near line # 1
Reference: RFC 5545 3.1. Content Lines

Which version of Org are you using? (M-x org-version)

Org 9.7 (unreleased) contains some fixes for how ox-icalendar handles
newlines. If you are using a previous version of Org, please try out the
latest main branch and see if it fixes the problem.

[BUG] org-insert-heading changed behavior with Emacs 29.2 [9.6.15 (release_9.6.15 @ /usr/local/share/emacs/29.2/lisp/org/)]

[gusbrs]

Hi All,

I recently upgraded to Emacs 29.2 (from 29.1) and observed that
`org-insert-heading-respect-content' has changed behavior with regard
to how it handles blank lines at the end of the entry at which the
command was called.

Consider the following document (with "|" representing point):

#+begin_src org
,* Sec1

,** |SubSec1

text

,** SubSec2

text

#+end_src

Calling `org-insert-heading-respect-content' ("C-RET") with Org
version 9.6.6 (built-in Emacs 29.1) would result in:

#+begin_src org
,* Sec1

,** SubSec1

text

,** |

,** SubSec2

text

#+end_src

Now, with Org version 9.6.15 (built-in Emacs 29.2), it results in:

#+begin_src org
,* Sec1

,** SubSec1

text

,** |
,** SubSec2

text

#+end_src

Note the missing blank line between the inserted heading and SubSec2.

That is an unfortunate change of behavior since those who like to keep
some breathing space at the end of entries now have to deal with it
manually after the heading is inserted.  So the handy "C-RET" becomes
something like "C-RET RET C-b SPC".  Plus the cost of having to think
about it, and that of occasionally forgetting it, consistency is just
harder to maintain.

As far as I can tell, the commit which introduced this change of
behavior was 
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=52bc95676.
It was introduced to deal with a real issue which had been reported:
to avoid the possibility of those blank lines being shown folded after
insertion in some cases (link on the commit).

However, as far as I understand, the issue the commit tried to fix was
one of visibility of the buffer.  The actual contents were expected,
correct.  But to fix the visibility issue, the behavior of
`org-insert-heading' with regard to the actual contents was changed:
to avoid the blank lines being shown folded the blank lines were
actually removed.

So I'd like to suggest / propose that previous behavior of
`org-insert-heading' with respect to blank lines be somehow restored
and that the problem of the blank lines being shown folded be treated
as one of visibility / folding, not one of buffer contents.

Best regards,
gusbrs.





Emacs  : GNU Emacs 29.2 (build 2, x86_64-pc-linux-gnu, GTK+ Version
3.24.33, cairo version 1.16.0)
 of 2024-01-18
Package: Org mode version 9.6.15 (release_9.6.15 @
/usr/local/share/emacs/29.2/lisp/org/)

current state:
==
(setq
 org-link-elisp-confirm-function 'yes-or-no-p
 org-bibtex-headline-format-function #[257 "\300 \236A\207" [:title] 3
"\n\n(fn ENTRY)"]
 org-persist-after-read-hook '(org-element--cache-persist-after-read)
 org-export-before-parsing-hook '(org-attach-expand-links)
 org-cycle-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
 org-archive-hook '(org-attach-archive-delete-maybe)
 org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-show-empty-lines
  org-cycle-optimize-window-after-visibility-change
  org-cycle-display-inline-images)
 org-persist-before-read-hook '(org-element--cache-persist-before-read)
 org-mode-hook '(#[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook org-fold-show-all append
local]
   5]
 #[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook org-babel-show-result-all
append local]
   5]
 org-babel-result-hide-spec org-babel-hide-all-hashes)
 org-confirm-shell-link-function 'yes-or-no-p
 outline-isearch-open-invisible-function 'outline-isearch-open-invisible
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-src-mode-hook '(org-src-babel-configure-edit-buffer
 org-src-mode-configure-edit-buffer)
 org-confirm-elisp-link-function 'yes-or-no-p
 org-speed-command-hook '(org-speed-command-activate
  org-babel-speed-command-activate)
 org-persist-directory "/tmp/org-persist-St7aom"
 org-fold-core-isearch-open-function 'org-fold--isearch-reveal
 org-persist-before-write-hook '(org-element--cache-persist-before-write)
 org-tab-first-hook '(org-babel-hide-result-toggle-maybe
  org-babel-header-arg-expand)
 org-link-shell-confirm-function 'yes-or-no-p
 org-babel-pre-tangle-hook '(save-buffer)
 org-agenda-loop-over-headlines-in-active-region nil
 org-occur-hook '(org-first-headline-recenter)
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-link-parameters '(("attachment" :follow org-attach-follow :complete
org-attach-complete-link)
   ("id" :follow org-id-open)
   ("eww" :follow org-eww-open :store org-eww-store-link)
   ("rmail" :follow org-rmail-open :store
org-rmail-store-link)
   ("mhe" :follow org-mhe-open :store org-mhe-store-link)
   ("irc" :follow org-irc-visit :store org-irc-store-link
:export org-irc-export)
   ("info" :follow org-info-open :export org-info-export
:store org-info-store-link :insert-description
 

Re: [DISCUSSION] Allowing footnote-references inside parsed keywords (#+AUTHOR, #+TITLE, etc)

[Marvin Gülker]

Am Donnerstag, dem 01. Februar 2024 schrieb Juan Manuel Macías:
> How about using dedicated keywords? Something like:
>
> #+FN_AUTHOR: footnote text
> #+FN_TITLE: footnote text

For reference -- I do not know if this prompted the discussion here --
just a few days ago I asked about footnotes in author information
because such footnotes are just so common in the field I write in. They
are used to give a short description of the author's position usually
("XY is a researcher at the chair of Foo Bar..."). Since in my field I
have to submit DOCX to journals, such footnotes should be properly
exported by ox-odt in particular.

Here is the thread over at emacs-humanities:
https://lists.gnu.org/archive/html/emacs-humanities/2024-01/msg0.html
It includes an ugly workaround I applied in form of an advice. A proper
solution directly in org would of course be much preferable.

I like the dedicated keyword solution. This way third party backends
will probably ignore the new keywords, because for them they will look
like a comment.

Marvin

-- 
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland  | kont...@guelker.eu| O<

Re: [DISCUSSION] Allowing footnote-references inside parsed keywords (#+AUTHOR, #+TITLE, etc)

[Juan Manuel Macías]

Ihor Radchenko writes:

> Max Nikulin  writes:
>
>> On 26/01/2024 19:53, Ihor Radchenko wrote:
>>> So, I am leaning towards reverting that commit - that will allow things
>>> like
>>> 
>>> #+TITLE: This is a test title[fn::This is test]
>>
>> I hope, document metadata will be generated with stripped footnotes.
>
> This is a good point.
>
> For now, [fn::This is test], when passed to exporters, is simply treated
> as plain text.
>
> If we change the parser nesting rules, Org will pass footnote-reference
> objects instead.
>
> Then, in a number of parsers, if something like
> (org-export-data (plist-get info :title) info) or
> (org-export-data author info)
> is used, footnotes may break export because metadata fields often have
> special rules about markup that is allowed inside.
>
> In particular, ox-odt will be broken; ox-latex will be broken.
>
> Of course, we can adjust built-in backends to take into account the new
> parsing rules, but we have no control over the third-party backends.
>
> On the other hand, when user exports something like
>
> #+AUTHOR: John Doe[fn::935 Pennsylvania Avenue, NW Washington, D.C. 
> 20535-0001]
> it is probably not exported as expected anyway.

How about using dedicated keywords? Something like:

#+FN_AUTHOR: footnote text
#+FN_TITLE: footnote text

I give these two examples because they are the two places where a
footnote of this type is expected. I know: it's ugly and corseted (what
to do if a title has more than one footnote or an "inner" footnote?).
But I suppose it would be safe for a basic case, since it would only be
necessary to modify org-latex-template, org-odt-template, etc., without
risk of unexpected results.

Best regards,

Juan Manuel 

Re: [PATCH v2] org-id: allow using parent's existing id in links to headlines

[Rick Lupton]

On Thu, 1 Feb 2024, at 12:13 PM, Ihor Radchenko wrote:
> The patch does not apply onto the latest main. May you please update it?

I have rebased onto the latest main. It changes quickly!

(there were no conflicts during the rebase, which I'd have thought would mean 
the patches shouldn't be a problem to apply? It the problem was something else, 
please let me know)

0001-lisp-org.el-org-insert-heading-allow-specifying-head.patch
Description: Binary data


0002-org-id.el-Extend-links-with-search-strings-inherit-p.patch
Description: Binary data

Re: RFI: LaTeX - AUTO for \usepackage{inputenc}

[Pedro Andres Aranda Gutierrez]

Yes, indeed...
Thx for pointing out
/PA

On Thu, 1 Feb 2024 at 17:31, Ihor Radchenko  wrote:

> Pedro Andres Aranda Gutierrez  writes:
>
> > some days ago I sent a proof-of-concept for customising the coding for
> the
> > inputenc package. Before continuing with this, I'd like to know what
> other
> > people think and/or need.
>
> Did you mean fontenc?
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>


-- 
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

Re: RFI: LaTeX - AUTO for \usepackage{inputenc}

[Ihor Radchenko]

Pedro Andres Aranda Gutierrez  writes:

> some days ago I sent a proof-of-concept for customising the coding for the
> inputenc package. Before continuing with this, I'd like to know what other
> people think and/or need.

Did you mean fontenc?

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

Re: [PATCH] doc/org-manual.org: Checkboxes, add checkbox states examples

[Ihor Radchenko]

Matt  writes:

>  > In fact, Checkboxes section of the manual was previously under Document
>  > structure. This was changed in release_4.45.
>  > https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=6a9c670d
>
> I checked the mailing list around that time for any issues that might mention 
> checkboxes and didn't find anything.  On 2008-01-27, they were discussing 
> results of a recent survey.  I was able to find a copy from the week after 
> the change.  I didn't see anything that would have motivated the change.  

2008-01-31 is the first commit in Org git repository. So, the discussion
may be any time before that date.

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

Re: [PATCH] doc/org-manual.org: Checkboxes, add checkbox states examples

[Ihor Radchenko]

Sławomir Grochowski  writes:

> I noticed in my patch that I moved the description ("The ‘[2/4]’ and
> ‘[1/3]’ in") of an example.
> And it should be just below the example.
>
> So I'm sending a fixup! patch to fix this.
> It's my first fixup! patch so I hope this is the right procedure ;)

Thanks!
Applied, onto main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=614d534a9

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

Re: Suggested manual changes - section 7.2 Special Properties

[Ihor Radchenko]

Tommy Kelly  writes:

> It’s here:
> https://www.reddit.com/r/orgmode/s/3viPfF78Lr
>
> In a nutshell, I was trying to understand how to have one of the columns in
> column mode be the creation date of each headline. I thought that because I
> almost always insert a clock entry when I create (using org-capture) a new
> item then I already had the required timestamp — the first one in the clock
> entry. However, it turns out that timestamp isn’t usable, and so the thread
> was me looking for help in figuring out the best way to do it.

Column view is currently not flexible enough to retrieve data that is
not a known property from property drawer or from special properties.

In theory, we might modify `org-columns--collect-values' to allow
user-defined special properties.

This might be something similar to `org-columns-summary-types', but to
allow custom functions that retrieve property value.

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

Re: Suggested manual changes - section 7.2 Special Properties

[Ihor Radchenko]

Tommy Kelly  writes:

> After figuring out, with help on Reddit (ht: Adam), some nuances
> affecting timestamps, column
> mode, and the Special Properties TIMESTAMP, and TIMESTAMP_IA, I think
> the following
> modifications to section 7.2 (Special Properties) of the manual would
> be worthwhile.
> 
>  START OF PATCHFILE 

Applied, onto main, with minor markup amendments.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=055ed4a2f
Thanks for your contribution!

You are now listed as an Org contributor.
https://git.sr.ht/~bzg/worg/commit/9c26ec3e

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

Re: [BUG] beamer export

[Ihor Radchenko]

Leo Butler  writes:

>   The docstring of `org-latex-classes' says:
>
>  The HEADER-STRING is the header that will be inserted into the
>  LaTeX file.  It should contain the \documentclass macro, and
>  anything else that is needed for this setup.
>
>   From that, I figured that would be the correct place to put that
>   \newenvironment command. I have moved it, as requested.

Yes, but org-latex-classes is a custom option. If user accidentally
deletes the \newenvironment command, things will not compile.

We generally prefer to keep things that we expect to remain constant out
of customizations.

> Replying to self: Attached is a patch that adds a property,
> BEAMER_FRAME, that lets the frame environment name be set on a
> frame-by-frame basis. In addition, it typesets any fragile frame in the
> `orgframe' environment. I am not sure if the latter is really needed,
> given the former.

Thanks!

> Comments?

I am not a big fan of introducing a new BEAMER_FRAME option.
We already have BEAMER_ENV.

However, BEAMER_ENV is somewhat tricky for frame headings - ox-beamer
allows special values of frame and fullframe (the latter is not fully
documented) to allow frames nesting different from
`org-beamer-frame-level'.

What about not adding BEAMER_FRAME, but instead adding org-lint checker
that will detect when frame text contains the problematic \end{orgframe}?

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

Re: [BUG] Unexpected result when evaluating python src block asynchronously [9.7-pre (release_9.6.17-1131-gc9ed03.dirty @ /home/yantar92/.emacs.d/straight/build/org/)]

[Bruno Barbier]

Hi Ihor,

Ihor Radchenko  writes:

>
> This is most likely something about my current system setup - I can
> reproduce with other Org mode and Emacs versions. But I have no clue
> what is the cause.

I'm getting the same as you with your MWE.
   
The tag, used by ob-comint async, is:

   "/tmp/babel-zqh04P/python-GL5N5d"
   
but, in "/tmp/bug.org" it becomes:

   "babel-zqh04P/python-GL5N5d"

(`org-babel-result-to-file' transformed it into a simpler relative
path).

The filter `org-babel-comint-async-filter' cannot spot it, because
it's searching for the exact string "/tmp/babel-zqh04P/python-tXsdFw".

Here is how to reproduce:
   #+begin_src elisp :results table
 (let* ((tag "/tmp/babel-zqh04P/python-tXsdFw")
(repro 
 (lambda (fn)
   (let ((lnk 
  (with-temp-buffer
(org-mode)
(let* ((default-directory "/tmp")
   (buffer-file-name  fn)
   (cbuf (clone-indirect-buffer "tmp" nil)))
  (with-current-buffer cbuf
(org-babel-result-to-file tag))
 (list fn
   (not (eq nil (string-match-p (regexp-quote tag) lnk)))
   lnk)
   (cons (list "Filename" "string-match-p" "Org link")
 (cons 'hline
   (mapcar repro (list "/tmp/bug.org" 
   "/somewhere/else/bug.org")
   #+end_src

   #+RESULTS:
   | Filename| match-p | Org link   
   |
   
|-+-+---|
   | /tmp/bug.org| nil | [[file:babel-zqh04P/python-tXsdFw]]
   |
   | /somewhere/else/bug.org | t   | 
[[file:../../tmp/babel-zqh04P/python-tXsdFw]] |


I don't know what a proper fix would be though.
   
Hoping this help,

Bruno


>
> Emacs  : GNU Emacs 30.0.50 (build 4, x86_64-pc-linux-gnu, GTK+ Version 
> 3.24.39, cairo version 1.18.0)
>  of 2024-01-30
> Package: Org mode version 9.7-pre (release_9.6.17-1131-gc9ed03.dirty @ 
> /home/yantar92/.emacs.d/straight/build/org/)
> -- 
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 

[DISCUSSION] Allowing footnote-references inside parsed keywords (#+AUTHOR, #+TITLE, etc) (was: [BUG] Footnotes in section titles)

[Ihor Radchenko]

Max Nikulin  writes:

> On 26/01/2024 19:53, Ihor Radchenko wrote:
>> So, I am leaning towards reverting that commit - that will allow things
>> like
>> 
>> #+TITLE: This is a test title[fn::This is test]
>
> I hope, document metadata will be generated with stripped footnotes.

This is a good point.

For now, [fn::This is test], when passed to exporters, is simply treated
as plain text.

If we change the parser nesting rules, Org will pass footnote-reference
objects instead.

Then, in a number of parsers, if something like
(org-export-data (plist-get info :title) info) or
(org-export-data author info)
is used, footnotes may break export because metadata fields often have
special rules about markup that is allowed inside.

In particular, ox-odt will be broken; ox-latex will be broken.

Of course, we can adjust built-in backends to take into account the new
parsing rules, but we have no control over the third-party backends.

On the other hand, when user exports something like
#+AUTHOR: John Doe[fn::935 Pennsylvania Avenue, NW Washington, D.C. 20535-0001]
it is probably not exported as expected anyway.
So, changing things from unexpected export to failing export may not be
a critical regression.

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

Re: Should org-link-parser add type "file" when link has no "file:" prefix?

[Ihor Radchenko]

jos...@ushin.org writes:

>> > > What we can do then is pass an extra argument to :follow function - the
>> > >  link object. That way, :follow function can get all the information it
>> > >  needs.
>> > > 
>> > 
>> >  I like this idea! Would this change break existing :follow functions
>> >  which only expect max two args?
>> > 
>> 
>> No. We can preserve backwards-compatibility by checking :follow function
>> arity and only passing the extra argument with the :follow function
>> supports that many arguments.
>
> Good to know.  If the goals of hyperdrive.el can be accomplished without 
> adding complexity to Org mode, it may be best to avoid avoid adding another 
> argument to :follow functions.  WDYT?

I did not make any changes to Org mode. And I will not, unless we need
to pass this extra information to :follow functions.

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

Re: [PATCH v2] doc/org-manual.org (Summary): Clarify the Org markup is human-readable

[Ihor Radchenko]

Ihor Radchenko  writes:

> Thanks for the comments!
> I am attaching the next iteration of the patch.

Applied, onto main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=788af5675

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

Re: [PATCH v2] org-id: allow using parent's existing id in links to headlines

[Ihor Radchenko]

The patch does not apply onto the latest main. May you please update it?

[BUG] Unexpected result when evaluating python src block asynchronously [9.7-pre (release_9.6.17-1131-gc9ed03.dirty @ /home/yantar92/.emacs.d/straight/build/org/)]

[Ihor Radchenko]

This is a followup for another bug report
https://orgmode.org/list/87plxg95u4@gmail.com

Using the MWE from that report I am seeing a different bug and it is not
very clear for me what is causing it.

1. When I create /tmp/bug.org with the following contents:

#+begin_src python :dir otherdir :async yes :session pysession :return 
figname :results file value :mkdirp yes
import matplotlib.pyplot as plt
plt.figure(figsize=(1, 1))
plt.plot([1, 2])
figname = 'fig.svg'
plt.savefig(figname)
#+end_src

2. Go to Org git folder
3. make repro REPRO_ARGS="-l ob-python /tmp/bug.org"
4. Evaluate the code block
5. I get

#+RESULTS:
[[file:babel-GJy87v/python-xr8wq9]]

rather than expected [[file:otherdir/fig.svg]]

I use matplotlib 3.8.2-r1.
The contents of Python REPL is suspicious:

Python 3.11.7 (main, Jan  8 2024, 18:11:18) [GCC 13.2.1 20231216] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 
ob_comint_async_python_file_/tmp/babel-s8nwvB/python-NmMFRv
>>> 

This is most likely something about my current system setup - I can
reproduce with other Org mode and Emacs versions. But I have no clue
what is the cause.

Emacs  : GNU Emacs 30.0.50 (build 4, x86_64-pc-linux-gnu, GTK+ Version 3.24.39, 
cairo version 1.18.0)
 of 2024-01-30
Package: Org mode version 9.7-pre (release_9.6.17-1131-gc9ed03.dirty @ 
/home/yantar92/.emacs.d/straight/build/org/)
-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Async Python src block behavior with :dir header property

[Ihor Radchenko]

Jack Kamm  writes:

>> Confirmed.
>
> Does the attached patch fix the issue?
>
> It seems the problem is with async sessions generally (not just
> ob-python), and happens because `org-babel-comint-async-filter' does not
> set `default-directory' before calling `org-babel-insert-result', unlike
> `org-babel-execute-src-block'.

The patch generally looks reasonable, although I am slightly concerned
about interaction between :dir and session we describe in the manual:

When ‘dir’ is used with ‘session’, Org sets the starting directory
for a new session.  But Org does not alter the directory of an already
existing session.

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

Re: [PATCH] Silently remove lockfiles from org-agenda-files

[Ihor Radchenko]

Joseph Turner  writes:

>> I feel slightly reluctant about this patch:
>> ...
>
> Yes, I think you're right.  Thanks for your caution :)

Closing.
Canceled.

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

Re: [PATCH] lisp/ox-latex.el: improve org-latex-toc-command docstring

[Ihor Radchenko]

gerard.vermeu...@posteo.net writes:

> I have read the docstring of `org-latex-toc-command' too literally
> to discover that specifying anything else than "toc:nil" works.
> ...
> The attached patch contains a proposal for improvement.
> Subject: [PATCH] lisp/ox-latex.el: improve org-latex-toc-command docstring

Thanks!
Applied, onto bugfix.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=84f56c47f

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

Re: bug#68687: [PATCH] Use text/org media type

[Max Nikulin]

On 01/02/2024 03:00, Stefan Kangas wrote:

Max Nikulin writes:

+++ b/lisp/net/mailcap.el
@@ -989,7 +989,8 @@ (defvar mailcap-mime-extensions
  (".jpe"   . "image/jpeg")
  (".jpeg"  . "image/jpeg")
  (".webp"  . "image/webp")
-(".org"   . "text/x-org"))
+;; May be overridden by application/vnd.lotus-organizer in /etc/mime.types.
+(".org"   . "text/org"))


With this patch, what happens if someone is emailing using an old
version of Emacs?  Does that matter, or is this stuff based only on the
file ending?


Org files are plain text files and have no specific signature that would 
allow tools like libmagic to unambiguously distinguish them from other 
text files. Rare files have explicit "# -*- mode: org-mode -*-" header. 
So there is no other way besides file name extensions when a message is 
composed or a file is served by a HTTP server. Clients should rely on 
the Content-Type header.


Old mailers will continue sending messages with 
application/vnd.lotus-organizer, text/x-org, or text/org media type.



IOW, I'm asking if it is backwards-compatible to remove
"text/org", in either direction.


I suggest to use text/org instead of text/x-org.


Will .org files be displayed in the
same way as before or not on both new and old versions?


I do not see a better way toward consistency in respect to the media type.


I've noticed on my machine that .org files have been interpreted as
application/vnd.lotus-organizer.


From my point of view, it is a reason to not bother concerning removing 
of "text/x-org" from `mailcap-mime-extensions'



Presumably that's due to some local
configuration in /etc/mime.types on my distro.  Is that correct?


There are 2 projects maintaining /etc/mime.types, they follows IANA 
registry, so have application/vnd.lotus-organizer. XDG shared-mime-info 
project (another media types DB, not /etc/mime.types) has text/org.



Is it
documented somewhere how to override that system configuration in Emacs?


Create ~/.mime.types. Debian's variant suggests it in the 
/etc/mime.types header.



But thinking about this more, why not do that unconditionally for users?
Lotus Organizer is dead, long gone, and not really relevant to anyone,
certainly not to the overwhelming majority of Emacs users.


Ideally text/org should be registered in IANA, so all applications could 
use consistent mapping. Prerequisites have been discussed already.

Re: Async Python src block behavior with :dir header property

[Nasser Alkmim]

Jack Kamm  writes:

>
> Does the attached patch fix the issue?
>

I briefly tested it here and it works.
Thanks for taking a look into it.

-- 
Nasser Alkmim 
 +43 677 6408 9171