Org mode version 9.7-pre (9.7-pre-n/a-g356072 @ /home/dinko/.config/emacs/elpaca/builds/org/); table alignment broken when using links in cells

[Kostadin Ninev]

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



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


After installing latest org from git, table alignment is broken for 
me in tables where some of the cells contain links for example:

 ab 

 [c]  d 

Shows like this:

 a  b 
--
 c  d 

Unless I do M-x org-toggle-link-display, tested with emacs -Q.

This is what I get on emacs 29.1 org:

 a  b 
--
 c  d 


Emacs  : GNU Emacs 29.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.40, 
cairo version 1.18.0)
Package: Org mode version 9.7-pre (9.7-pre-n/a-g356072
 @ /home/dinko/.config/emacs/elpaca/builds/org/)
--
*Kostadin Ninev*


[c] 

emacs-orgmode@gnu.org Subject: Org mode version 9.7-pre (9.7-pre-n/a-g356072; org-table-to-lisp breaks table alignment when using links

[Kostadin Ninev]

After installing latest org from git, table alignment is broken for 
me in tables where some of the cells contain links for example:


| a| b |
|--+---|
| [[c][c]] | d |


Shows like this:


| a| b |
|--+---|
| c | d |


Unless I M-x org-toggle-link-display, tested with emacs -Q).


This is what I get on emacs 29.1 org:


| a| b |
|--+---|
| c| d |

Re: [proof of concept] inline language blocks

[Max Nikulin]

Juan Manuel,

I am not against optional arguments. The idea is to make the feature 
more flexible and convenient for domain-specific documents. I did not 
use square brackets in my example to concentrate on the use case of 
concise and clear markup.


On 29/02/2024 06:42, Juan Manuel Macías wrote:

Max Nikulin writes:


#+options: custom-object(:type la :latex_element foreignlanguage
:latex_pre "{latin}")


mmm, I see it as not very flexible and perhaps too complicated for the user.


Do not concentrate on \foreignlanguage. I am using it just because the 
thread was started from markup suitable for mixed-language texts.



the user should expect something like {...} to produce \foo{...} or
..., etc. The only difference is that there would
be an anonymous variant &_{...}.


I do not try to dispute \foo and class="foo" as default behavior. I 
suggest to implement possibility to override default behavior of
{text} to \bar{text} and text. The same is applicable for 
anonymous objects


 &_[:latex_command bar :html_element bar]{text}


class in HTML


HTML has a number of elements for semantic markup, e.g. , , 
, etc. I hope, they can be supported in addition to default .

Things got very slow: profiler output

[William Denton]

I rebuilt Org and Emacs from the development trees and something is wrong, 
because some Org files I use regularly have become incredibly slow to use.  I 
rarely use the profiler and don't know what to make of what it says, but I 
opened a file and ran it while I moved around and expanded and collapsed some 
headings for a minute or so.  (It was so slow that it took me a minute to do 
what would usually take me a few seconds.)  I'll paste the results below.  Does 
that say anything useful?  There is a little LaTeX in the file but not much.

Any help on interpreting this would be welcome.  I can try reverting to an 
earlier Git commit tomorrow.

Bill

 Samples%   Function
   73203  70% - redisplay_internal (C function)
   71496  68%  - jit-lock-function
   71488  68%   - jit-lock-fontify-now
   71472  68%- jit-lock--run-functions
   71472  68% - #
   71472  68%  - font-lock-fontify-region
   71468  68%   - font-lock-default-fontify-region
   71436  68%- font-lock-fontify-keywords-region
   71124  68% - org-do-latex-and-related
   71124  68%re-search-forward
 228   0% + org-activate-folds
  16   0% + org-fontify-meta-lines-and-blocks
  12   0% + org-activate-footnote-links
   8   0%   org-activate-dates
   8   0% + org-activate-links
   4   0%   org-do-emphasis-faces
   4   0%   org-fontify-drawers
   4   0%   org-raise-scripts
  28   0%+ font-lock-unfontify-region
   4   0%+ font-lock-extend-region-wholelines
   4   0%  text-property-any
   30951  29% + command-execute
  ...


--
William Denton
https://www.miskatonic.org/
Librarian, artist and licensed private investigator.
Toronto, Canada

Re: [proof of concept] inline language blocks

[Juan Manuel Macías]

Max Nikulin writes:

> #+options: custom-object(:type la :latex_element foreignlanguage 
> :latex_pre "{latin}")

mmm, I see it as not very flexible and perhaps too complicated for the user.

My idea with the concept of inline-special-block is that it is like the
inline version of its older brother. If something like

#+begin_foo
...
#+end_foo

produces things like

\begin{foo}
...
\end{foo}

or


...


the user should expect something like {...} to produce \foo{...} or
..., etc. The only difference is that there would
be an anonymous variant &_{...}.

The attributes syntax (in square brackets) adds verbosity, but I
understand that it is also very flexible and granular. It doesn't need
to be used always, but at least it's there when you need to use it.
Furthermore, the user can always define lists of attributes (styles or
aliases: I would have preferred the term "style", instead of "alias",
but I fear that it will be confused with the HTML attribute of the same
name). Furthermore, these lists of attributes can also be used in
combination with other single attributes, giving rise to a great
possibility of combinations. The fact that there are a number of
universal attributes such as :lang, :color, :smallcaps prevents the user
from having to figure out which code to use on each backend to produce
colored text, small caps or the correct language selector. ":lang ru",
for example, will always produce in LaTeX \foreignlanguage{russian}{}
(which, in addition, is a command shared by babel and polyglossia) and
in HTML lang="ru".

And ultimately you could also think about some kind of folding for the
attributes part.

I believe that this possible new element would solve the need for a
native, multipurpose inline text container with properties[1], which
until now could only be achieved through macros or links, with the
limitations of both elements.

Additionally, I think this approach is more flexible than having
specific purpose blocks (for languages, colors, etc.).

Of course, it would be best not to abuse the attributes. If in a
long document one needs to put a single sentence in red, I don't think
it is a verbosity problem to put something like &_[:color red]{lorem
ipsum dolor}. If you need to put a lot of sentences in red or any other
color, it may be a better idea to define some command in LaTeX
(\redtext), a class in HTML or a character style in odt. And then it
would be enough to use {lorem ipsum dolor}.

[1] Pandoc has the "bracketed spans". According to pandoc manual:

#+begin_quote

A bracketed sequence of inlines, as one would use to begin
a link, will be treated as a Span with attributes if it is followed
immediately by attributes:

[This is *some text*]{.class key="val"}

#+end_quote

Re: Radio links work only in small numbers

[Noboru Ota]

Ihor Radchenko  writes:

> You need Www.
> The attached version of the patch should work for 5000-terms.org.

Thank you, Ihor. With your advice, I have managed to apply the patch. It
works for 5000 terms! Thank you.

Some observations:

- Running `org-update-radio-target-regexp` takes about 15 seconds for the
  file[1].

- Writing experience is very good. When I type one of the terms, and a
  radio target link gets added without noticable delay for me on my end.

> (I had to scale down the maximum allowed regexp size; apparently,
> the number from C sources was not small enough).

Do you have any indication on how many would be maximum?

Thank you.

---
[1]: You can also see the benchmark results in the file.  
https://git.sr.ht/~nobiot/org-radio-links-patch-20240228/tree/main/item/5000-terms.org

– nobiot

Re: [PATCH] doc/org-manual.org (Checkboxes): move section 'Checkboxes' from 'TODO Items' to 'Plain Lists'

[Matt]

  On Wed, 28 Feb 2024 13:17:54 +0100  Ihor Radchenko  wrote --- 
 > Matt m...@excalamus.com> writes:
 > 
 > > I had responded in favor here: 
 > > https://list.orgmode.org/18d4cf138a6.10fb9c6702382826.5023996590743168...@excalamus.com/
 > 
 > Did I miss something...

Yes, it appears there's a little bit of a mix up because of a bad subject line. 
 There's also some nitpicky logic.  The tl;dr is, we shouldn't use the current 
patch.

 >...or did you not provided arguments /why/ the
 > section should be moved? I need to understand what kind of improvement
 > it would provide to the manual.

I didn't know that's what you were looking for.  When I said, "I had responded 
in favor..." it was in response to your prior message which said,

> No comments arrived within one month. 

This is incorrect albeit understandable.  I had responded and, therefore, there 
were not "no comments."  However, it looks like I responded in the wrong 
thread! ("Re: [PATCH] doc/org-manual.org: Checkboxes, add checkbox states 
examples")  That's my bad! 

Regarding reasoning, I'm in favor of the move for the reasons Sławomir gave:

> Because checkbox can only exist in a plain list, as a plain list feature.
> So the section should be under 'Plain Lists' heading not under 'TODO Items'.

The issue is checkbox usage is split between different sections of the manual.

You had responded to this by saying,

> Both arrangements are logical. Checkboxes are useful as a complement to
> TODO items. And they are also indeed a plain list feature.

It seems we're all agreed the proposed arrangement is logical and that the 
issue is valid.  I don't think it needs extra justification.

Conceding this point, which we all appear to, the issue becomes which 
arrangement we should use?

Originally, we were reluctant to move the Checkboxes section only because 
Carston had moved it previously.  Unfortunately, we don't know *why* Carston 
moved it.  This isn't a very contestable justification.

My latest reply gives a specific reason to *not* apply the current patch.  That 
is, to *not* move the Checkbox section as-is.  The reason is:

 > > The Checkboxes section is written assuming the reader knows what 
 > > Properties are.  The GNU documentation guidelines suggest writing as 
 > > though readers have read from the beginning [fn:1] [fn:2].  That is, 
 > > unless introducing a concept, only use concepts that have already been 
 > > explained.  Properties are introduced in Section 2.7 and Checkboxes is 
 > > currently 5.6.   The proposal is to move Checkboxes to 2.6.1 *before* 
 > > properties are introduced.  This is a problem.

I suspect this is the reason Carston moved the section.  Regardless, it's a 
valid reason to have moved it and gives us clear criteria for why we can't 
apply the patch.  It also gives us a precise target for what would need to be 
fixed in order to resolve the issue of checkbox usage being split between 
sections by moving the Checkbox section.

 > We start talking about properties as early as in 2.2.2 Initial
 > visibility and in many other places. Re-ordering the manual to avoid
 > referring to future concepts would entail a major rewrite.

I believe that arranging documentation in conceptual order is always a 
worthwhile goal.  It's obviously better to have concepts introduced in order.   
It's also completely reasonable to not want to do that work right now.  I'm not 
willing to at the moment and it sounds like you aren't either.  That's okay.  
If Sławomir or someone else wants to, I still think the original point is 
valid.  However, the proposed patch, moving the section as-is, won't work 
because it (re)introduces problems with conceptual ordering.

If someone wants to suggest a patch which resolves the issue of checkbox usage 
being split between sections which preserves, or improves, the conceptual 
order, I'd be happy to assist.

--
Matt Trzcinski
Emacs Org contributor (ob-shell)
Learn more about Org mode at https://orgmode.org
Support Org development at https://liberapay.com/org-mode

Re: [PATCH] ob-tangle: Add flag to optionally remove files before writing

[Olivier Lischer]

Ihor Radchenko  writes:

>
> Thanks for the update!
> Unfortunately, your patch has unbalanced parenthesis and will not work.
> I have modified your patch to make things work and to make it conform to
> Elisp code conventions. I also removed spurious change in the existing
> variable.
>
> See the attached.
>
> Please, let me know if you want to change anything.
> Also, if you can, please test my patch with your use-case.

Sorry for the headache.
I tried it and it works for me.
Thank you for your patience.

Re: [proof of concept] inline language blocks

[Max Nikulin]

On 28/02/2024 20:15, Juan Manuel Macías wrote:

#+options: inline-special-block-aliases:(("latin" :lang "la" :color blue :prelatex "\\itshape " 
:html "style=\"font-style:italic;\""))

This is an example of Latin text: &_[@latin@]{lorem ipsum dolor sit amet}.


It is more verbose than {lorem ipsum dolor sit amet}. My idea is to 
allow latex commands other than object type ("la" this case). Something like


#+options: custom-object(:type la :latex_element foreignlanguage 
:latex_pre "{latin}")

Re: Radio links work only in small numbers

[Ihor Radchenko]

nobiot  writes:

>> May you try the attached patch?
>
> I would love to help this patch move forward and would be happy to try
> the patch, if this is not going to waste anyone's time:
>
> (1) I took the liberty of creating two test Org files we can use on
> sr.ht: https://git.sr.ht/~nobiot/org-radio-links-patch-20240228/tree
>
> The two files, `500-terms.org`  and `5000-terms.org`, contain 500
> and 5000 radio targets respectively.
>
> Both files have two H1 headlines "Definitions" and "Body text". Once
> you open the file, call `M-x org-update-radio-target-regexp`. For
> 500 entries, radio targets work beautifully; for the 5000 entries, I
> get 'org-element-context: Invalid regexp: "Regular expression too
> big"' error.

The attached version of the patch should work for 5000-terms.org.
(I had to scale down the maximum allowed regexp size; apparently,
the number from C sources was not small enough).

> (2) I am struggling to apply the patch cleanly to the current HEAD of
> Org-mode source. I git-cloned the source from
> https://git.sr.ht/~bzg/org-mode (commit 755fef38f Merge branch
> 'bugfix').
>
> I use Magit and use "W" -> "a" -> "a" to apply the
> plain patch file. I "get error: patch failed:

You need Www.

>From f565a9f3187ae99680ec92969bb3f6c29b542b04 Mon Sep 17 00:00:00 2001
Message-ID: 
From: Ihor Radchenko 
Date: Mon, 19 Feb 2024 12:19:34 +0300
Subject: [PATCH] Work around regexp size limitation for large number of link
 targets
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* lisp/ol.el (org-target-link-regexp-limit): New constant defining
maximum regexp limit where `org-target-link-regexp' is still safe to
use without triggering "Regexp too long" error.
(org-target-link-regexps): New variable holding a series of shorter
regexps to be used instead of too long single
`org-target-link-regexp'.
(org--re-list-search-forward): New function like `re-search-forward',
but accepting a list of regexps.
(org--re-list-looking-at): New function like `looking-at', but
accepting a list of regexps.
(org-update-radio-target-regexp): When `org-target-link-regexp' is too
long, set `org-target-link-regexps', partitioning the link target list
into smaller regexps.
* lisp/org-element.el (org-element-link-parser):
(org-element--object-lex):
* lisp/org.el (org-activate-target-links): Use
`org--re-list-search-forward' and `org--re-list-looking-at' when
`org-target-link-regexps' is non-nil.
* testing/lisp/test-org-element.el (test-org-element/link-parser): Add
tests.

Reported-by: Rudolf Adamkovič 
Link: https://list.orgmode.org/orgmode/m2lenax5m6@me.com/
---
 lisp/ol.el   | 68 ++--
 lisp/org-element.el  | 16 ++--
 lisp/org.el  |  4 +-
 testing/lisp/test-org-element.el | 17 
 4 files changed, 97 insertions(+), 8 deletions(-)

diff --git a/lisp/ol.el b/lisp/ol.el
index 22782578c..97423738a 100644
--- a/lisp/ol.el
+++ b/lisp/ol.el
@@ -52,6 +52,7 @@ (declare-function org-before-first-heading-p "org" ())
 (declare-function org-do-occur "org" (regexp  cleanup))
 (declare-function org-element-at-point "org-element" ( pom cached-only))
 (declare-function org-element-cache-refresh "org-element" (pos))
+(declare-function org-element-cache-reset "org-element" ( all no-persistence))
 (declare-function org-element-context "org-element" ( element))
 (declare-function org-element-lineage "org-element-ast" (datum  types with-self))
 (declare-function org-element-link-parser "org-element" ())
@@ -532,6 +533,13 @@ (defconst org-radio-target-regexp (format "<%s>" org-target-regexp)
 
 (defvar-local org-target-link-regexp nil
   "Regular expression matching radio targets in plain text.")
+(defconst org-target-link-regexp-limit (ash 2 10)
+  "Maximum allowed length of regexp.
+See MAX_BUF_SIZE in src/regex-emacs.c")
+(defvar-local org-target-link-regexps nil
+  "List of regular expressions matching radio targets in plain text.
+This list is non-nil, when a single regexp would be too long to match
+all the possible targets, exceeding Emacs' regexp length limit.")
 
 (defvar org-link-types-re nil
   "Matches a link that has a url-like prefix like \"http:\".")
@@ -2170,6 +2178,34 @@ (defun org-insert-link-global ()
   (org-load-modules-maybe)
   (org-run-like-in-org-mode 'org-insert-link))
 
+(defun org--re-list-search-forward (regexp-list  bound noerror count)
+  "Like `re-search-forward', but REGEXP-LIST is a list of regexps.
+BOUND, NOERROR, and COUNT are passed to `re-search-forward'."
+  (let (result (min-found most-positive-fixnum)
+

Re: Radio links work only in small numbers

[nobiot]

Hi Ihor, Rudy, and everyone,

> May you try the attached patch?

I would love to help this patch move forward and would be happy to try
the patch, if this is not going to waste anyone's time:

(1) I took the liberty of creating two test Org files we can use on
sr.ht: https://git.sr.ht/~nobiot/org-radio-links-patch-20240228/tree

The two files, `500-terms.org`  and `5000-terms.org`, contain 500
and 5000 radio targets respectively.

Both files have two H1 headlines "Definitions" and "Body text". Once
you open the file, call `M-x org-update-radio-target-regexp`. For
500 entries, radio targets work beautifully; for the 5000 entries, I
get 'org-element-context: Invalid regexp: "Regular expression too
big"' error.

(2) I am struggling to apply the patch cleanly to the current HEAD of
Org-mode source. I git-cloned the source from
https://git.sr.ht/~bzg/org-mode (commit 755fef38f Merge branch
'bugfix').

Which commit can I test the patch? I'd appreciate some guidance
here.

I use Magit and use "W" -> "a" -> "a" to apply the
plain patch file. I "get error: patch failed:
testing/lisp/test-org-element.el:2378". If I delete the hunk in the
patch for test-org-element.el, I then get "error: patch failed:
lisp/org.el:5705" on this latest commit.

Kind regards,
nobiot

Re: [proof of concept] inline language blocks

[Juan Manuel Macías]

Max Nikulin writes:

> Juan Manuel your ":fr{}" and similar objects is a domain-specific
> language that is quite different from a generic element proposed by
> Samuel. Do you think it makes sense to modify your inline special
> block patch to allow creation of concise DSL?
>
> Juan Manuel Macías. [testing patch] inline-special-block with full
> implementation for LaTeX backend. Fri, 23 Feb 2024 23:50:52 +.
> https://list.orgmode.org/87ttlyloyr@posteo.net
>
> I mean {bonjour} defined using "#+options:" or some new keyword or
> a special block. A definition of "fr" may be (using a bit different
> names)
>
> :latex_element "foreignlanguage" :latex_prefix "french"
> :html_element "span" :html_attr (:lang "fr")
>
> {} is no heavier than :fr{}. The only drawback is necessity to
> define elements for each language used in the document. I do not
> think, even a dozen of declarations is a significant burden.

Hi, Maxim,

In the end I abandoned the concept of inline language block to the
detriment of the more general concept of inline special block (as,
rightly, proposed Ihor). I feel that at the beginning both concepts
overlapped. The patch you mention deals exclusively with the inline
special block concept, as well as the experimental branch that I hope to
publish shortly.

The syntax of my approach, summarized, would be:

-basic form: [optional attributes]{lorem ipsum dolor}

==> LaTeX \foo{lorem ipsum dolor} ; ==> HTML lorem
ipsum dolor

- anonymous variant: &_{lorem ipsum dolor}

Common to all backends (so far I have only implemented LaTeX and HTML)
are a series of universal attributes. At the moment I have thought about
the following: :lang, :smallcaps and :color. For example:

[:lang el :color blue :smallcaps t]{contents}

==> LaTeX:

{\scshape\color{blue}\foreignlanguage{greek}{\foo{contents}}}

==> HTML

contents

There is also the :html attribute and for LaTeX the :prelatex and
:postlatex attributes. Groups of attributes can also be defined, as if
they were styles, and combined with single attributes:

#+options: inline-special-block-aliases:(("latin" :lang "la" :color blue 
:prelatex "\\itshape " :html "style=\"font-style:italic;\""))

This is an example of Latin text: &_[@latin@]{lorem ipsum dolor sit amet}.

This is an example of Latin text with small caps: &_[@latin@ :smallcaps 
t]{lorem ipsum dolor sit amet}.

==> LaTeX:

This is an example of Latin text: {\color{blue}\foreignlanguage{latin}{\itshape 
lorem ipsum dolor sit amet}}.

This is an example of Latin text with small caps: 
{\scshape{}\color{blue}\foreignlanguage{latin}{\itshape lorem ipsum dolor sit 
amet}}

==> HTML:

This is an example of Latin text: lorem ipsum dolor sit amet.

This is an example of Latin text with small caps: lorem 
ipsum dolor sit amet.

Re: [PATCH] org-agenda: Make sure skipping warning/delay days never increases their number

[Ihor Radchenko]

Bastien Guerry  writes:

> Ihor Radchenko  writes:
>
>> Bastien, may you please check FSF records?
>
> Done, and confirmed things are in order.  Welcome!

Recorded.
https://git.sr.ht/~bzg/worg/commit/4760468a

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

Re: [PATCH] org-agenda: Make sure skipping warning/delay days never increases their number

[Bastien Guerry]

Ihor Radchenko  writes:

> Bastien, may you please check FSF records?

Done, and confirmed things are in order.  Welcome!

-- 
 Bastien Guerry

Re: [PATCH] doc/org-manual.org (Checkboxes): move section 'Checkboxes' from 'TODO Items' to 'Plain Lists'

[Ihor Radchenko]

Matt  writes:

> I had responded in favor here: 
> https://list.orgmode.org/18d4cf138a6.10fb9c6702382826.5023996590743168...@excalamus.com/

Did I miss something, or did you not provided arguments /why/ the
section should be moved? I need to understand what kind of improvement
it would provide to the manual.

> The Checkboxes section is written assuming the reader knows what Properties 
> are.  The GNU documentation guidelines suggest writing as though readers have 
> read from the beginning [fn:1] [fn:2].  That is, unless introducing a 
> concept, only use concepts that have already been explained.  Properties are 
> introduced in Section 2.7 and Checkboxes is currently 5.6.   The proposal is 
> to move Checkboxes to 2.6.1 *before* properties are introduced.  This is a 
> problem.

We start talking about properties as early as in 2.2.2 Initial
visibility and in many other places. Re-ordering the manual to avoid
referring to future concepts would entail a major rewrite.

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

Re: org-mode: example blocks are no longer syntax highlighted in emacs

[Ihor Radchenko]

Max Nikulin  writes:

>>> After upgrading to emacs 29.2 and org 9.7, my example blocks are no longer
>>> syntax highlighted in emacs.
>> 
>> Yet, there is no reason to remote it.
>> I recovered example block fontification on main.
>
> At least some people are against the feature:
>
> https://list.orgmode.org/orgmode/CA+G3_PPYmiiwHYKkgiJDZQ=o7DvaG=0g3aqnphsbkemzsoy...@mail.gmail.com/T/#u
> Tom Gillespie. Re: [DISCUSSION] Refactoring fontification system. Tue, 7 
> Jun 2022 21:23:21 -0700.

Tom is against babel support for example blocks. However, indicating
language and fontification have nothing to do with babel.

> I do not mind to have syntax highlighting support for #+begin_example 
> blocks, but it should be coherent with ox exporters. My idea to unify 
> #+begin_src and #+begin_example exporters was not meet warmly.

It just got no responses, right? I personally did not reply because it
was out of scope of that thread.

> To notify users that fontification will be lost during export, the 
> feature may be turned into an opt-in one by adding a defcustom user 
> option disabled by default and having docstring clearly describing that 
> language will be ignored during export and users need to suppress 
> `org-lint' warnings.

Colored export might be reasonable to add for example blocks,
but we should discuss that separately. Not in this thread.

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

Re: [PATCH] org-agenda: Make sure skipping warning/delay days never increases their number

[Ihor Radchenko]

Tim Ruffing  writes:

> On Tue, 2024-02-27 at 12:49 +, Ihor Radchenko wrote:
>> However, your total contributions are now at the limit we can legally
>> accept without FSF copyright assignment.
>> Would you consider doing copyright paperwork as described in
>> ?
>> 
>
> Oh, I had completed the process on 2023-05-03, after my previous patch.
> But yeah, I never told you. :)

Thanks for letting me know!
Bastien, may you please check FSF records?

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

Re: [PATCH] org-babel-demarcate-block: split using element API

[Ihor Radchenko]

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

>> You may wrap `org-indent-block' into `condition-case' to catch
>> user-errors.
>
> The caveat is not a real constraint, since Org has limited support for
> source block editing in an Org mode buffer when an
> `org-babel-edit-prep:' function signals an user-error.
>
> I show that in the attached no-user-errors-in-edit-prep.org.

I studied the existing Org handling of various errors related to src
edit buffers and it seems that we tend to ignore them in a number of
scenarios. In particular, when major mode fails to load for any reason,
Org mode does not even throw an error, but simply displays a warning.

So, I think that we can similarly ignore errors in edit-prep function,
demoting them to messages.

(In addition, it does not look like electric-indent-mode triggered in
your example file by pressing  handles errors gracefully either -
yet another reason not to throw errors in `org-indent-*' functions)

Does it make sense?

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

Re: [PATCH] ob-tangle: Add flag to optionally remove files before writing

[Ihor Radchenko]

[ Moving the discussion back to public in Org mailing list ]

Olivier Lischer  writes:

> I hope that this time I have changed the patch the way you wanted it.
> If anything is still wrong, I am happy to improve it.

Thanks for the update!
Unfortunately, your patch has unbalanced parenthesis and will not work.
I have modified your patch to make things work and to make it conform to
Elisp code conventions. I also removed spurious change in the existing
variable.

See the attached.

Please, let me know if you want to change anything.
Also, if you can, please test my patch with your use-case.

>From b8d2a8506c9b63ad9fefbf8caaefb5de94001eb7 Mon Sep 17 00:00:00 2001
Message-ID: 
From: Olivier Lischer 
Date: Tue, 23 Jan 2024 21:02:20 +0100
Subject: [PATCH] ob-tangle: Add flag to optionally remove files before writing

* lisp/ob-tangle.el: Add new custom option
`org-babel-tangle-remove-file-before-write'.
(org-babel-tangle): Remove file before writing according to the value
of `org-babel-tangle-remove-file-before-write'.

The variable `org-babel-tangle-remove-file-before-write' adds support
for the current and old behaviour of `org-babel-tangle'.

Link: https://list.orgmode.org/orgmode/877cjzhjtg@liolin.ch/
Co-authored-by: Ihor Radchenko 

TINYCHANGE
---
 etc/ORG-NEWS  | 10 ++
 lisp/ob-tangle.el | 31 ++-
 2 files changed, 40 insertions(+), 1 deletion(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index dc0d9c0ad..26f0c90f9 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -928,6 +928,16 @@ properties, links to headlines in the file can also be made more
 robust by using the file id instead of the file path.
 
 ** New features
+*** =ob-tangle.el=: New flag to remove tangle targets before writing
+
+When ~org-babel-tangle-remove-file-before-write~ is set to ~t~ the
+tangle target is removed before writing.  This will allow overwriting
+read-only tangle targets.  However, when tangle target is a symlink,
+this will convert the tangle target into an ordinary file.
+
+The default value is ~auto~ -- overwrite tangle targets when they are
+read-only.
+
 *** ~org-bibtex-yank~ accepts a prefix argument
 
 When called with a prefix argument, ~org-bibtex-yank~ adds data to the
diff --git a/lisp/ob-tangle.el b/lisp/ob-tangle.el
index 281ab13d4..9bb69e5da 100644
--- a/lisp/ob-tangle.el
+++ b/lisp/ob-tangle.el
@@ -166,6 +166,23 @@ (defcustom org-babel-tangle-default-file-mode #o644
   :package-version '(Org . "9.6")
   :type 'integer)
 
+(defcustom org-babel-tangle-remove-file-before-write 'auto
+  "How to overwrite the existing tangle target.
+When set to nil, `org-babel-tangle' will replace contents of an existing
+tangle target (and fail when tangle target is read-only).
+When set to t, the tangle target (including read-only) will be deleted
+first and a new file, possibly with different ownership and
+permissions, will be created.
+When set to symbol `auto', overwrite read-only tangle targets and
+replace contents otherwise."
+  :group 'org-babel-tangle
+  :package-version '(Org . "9.7")
+  :type '(choice
+	  (const :tag "Replace contents, but keep the same file" nil)
+  (const :tag "Re-create file" t)
+  (const :tag "Re-create when read-only" auto))
+  :safe t)
+
 (defun org-babel-find-file-noselect-refresh (file)
   "Find file ensuring that the latest changes on disk are
 represented in the file."
@@ -323,7 +340,19 @@ (defun org-babel-tangle ( arg target-file lang-re)
(error "Not allowed to tangle into the same file as self"))
  ;; We do not erase, but overwrite previous file
  ;; to preserve any existing symlinks.
-		 (write-region nil nil file-name)
+ ;; This behavior is modified using
+ ;; `org-babel-tangle-remove-file-before-write' to
+ ;; tangle to read-only files.
+ (when (and
+			(file-exists-p file-name)
+(pcase org-babel-tangle-remove-file-before-write
+  (`auto (not (file-writable-p file-name)))
+  (`t t)
+  (`nil nil)
+  (_ (error "Invalid value of `org-babel-tangle-remove-file-before-write': %S"
+	org-babel-tangle-remove-file-before-write
+   (delete-file file-name))
+ (write-region nil nil file-name)
 		 (mapc (lambda (mode) (set-file-modes file-name mode)) modes))
(push file-name path-collector))
 	 (if (equal arg '(4))
-- 
2.43.0


(For records, below is the original patch, sent off-list)

> From 1523056a0dff5de64ed361d5bb1ad7d92ec7e369 Mon Sep 17 00:00:00 2001
> From: Olivier Lischer 
> Date: Tue, 23 Jan 2024 21:02:20 +0100
> Subject: [PATCH] ob-tangle: Add flag to optionally remove files before writing
>
> * lisp/ob-tangle.el: Add variable
> `org-babel-tangle-remove-file-before-write'.
> 

Re: Provide sane default for the @direntry

[Ihor Radchenko]

Stefan Monnier  writes:

> When exporting to Texinfo, the patch below makes it easier to generate
> a good `@direntry` by using sane defaults.
> For most files, you'll just need
>
> #+TEXINFO_DIR_CATEGORY: {my-category}
>
> I believe it also makes it a bit harder to shoot oneself in the foot and
> generate an invalid entry (e.g. with a missing or wrong file name).

May you please supply a ChangeLog entry? I am not sure if I understand
the purpose of each change in the diff.

Also, it looks like you introduce some DWIM behaviour for auto-generating
@direntry contents. Such new behaviour ought to be documented in the
manual and announced in the news.

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

Re: [proof of concept] inline language blocks

[Max Nikulin]

On 22/02/2024 06:02, Juan Manuel Macías wrote:

Samuel Wales writes:

:fr{some text in French}

being expressed as

$[lang :fr "bonjour"]


To expand a little more... Another problem I see in your example is
nesting. In my proposal, the blocks can be nested:

:fr{text in French and :it{text in Italian}}

But I would find this difficult to read:

$[lang :fr "text in French and $[lang :it "text in italian"]"]


Juan Manuel your ":fr{}" and similar objects is a domain-specific 
language that is quite different from a generic element proposed by 
Samuel. Do you think it makes sense to modify your inline special block 
patch to allow creation of concise DSL?


Juan Manuel Macías. [testing patch] inline-special-block with full 
implementation for LaTeX backend. Fri, 23 Feb 2024 23:50:52 +. 
https://list.orgmode.org/87ttlyloyr@posteo.net


I mean {bonjour} defined using "#+options:" or some new keyword or a 
special block. A definition of "fr" may be (using a bit different names)


:latex_element "foreignlanguage" :latex_prefix "french"
:html_element "span" :html_attr (:lang "fr")

{} is no heavier than :fr{}. The only drawback is necessity to define 
elements for each language used in the document. I do not think, even a 
dozen of declarations is a significant burden.

Re: Asynchronous blocks for everything (was 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/b

[Bruno Barbier]

Hi Matt,

Matt  writes:

>   On Sat, 24 Feb 2024 17:42:54 +0100  Bruno Barbier 
>
>  > I'll publish a branch soon; it will be a major rewrite of my current
>  > proposal.  It should be less confusing and, I hope, address some of your
>  > comments.
>  > 
>  > Thanks again for your questions and feedbacks,
>
> You're welcome and thanks for sharing your ideas.
>
> Any lack of comments from me recently is just limited time and trying to 
> focus on maintenance.

Thanks for letting me know.

No worries. Take care.

Bruno

Pending contents in org documents (Re: Asynchronous blocks for everything (was Re: ...))

[Bruno Barbier]

Hi,

Bruno Barbier  writes:

> Hi Matt,
[...]
>> Since this thread is dedicated to blocking, let me share my thoughts on that 
>> subject.
>
> I guess I should start a new thread then :)


I finally got a new version.  I've renamed the proposed feature "pending
contents", that is, some contents that something will update *later*.
With that feature, source code blocks and dynamic blocks can be made
asynchronous … and more!

I've publish the proposed changes as a branch.  You can fecth that
branch there:
┌
│ repo:   https://framagit.org/brubar/org-mode-mirror
│ branch: bba-pending-contents
└

The file [my-async-tests.org] describes the proposed changes, its
implementation and contains examples to play with it (shell, python,
ruby, results{append,prepend,silent}, inline blocks, multithreading,
dynamic asynchronous blocks, source codes that depend on other blocks
{post, stdin}, etc.).

I've tried to fully describe the feature in the new section "Pending
contents", in the file `lisp/org-macs.el'.

Testing it in a bare Emacs should now work (I'm using 30.0.50).

*DO NOT TEST* in your production Emacs: this is *alpha* software and it
hooks itself deeply into Emacs (kill hooks), and (only when trying the
multithread examples) uses thread mutexes

Here is a simple recipe to test the proposed "pending contents" feature:
┌
│ git clone -b bba-pending-contents https://framagit.org/brubar/org-mode-mirror
│ cd org-mode-mirror
│ make compile
│ cd scratch/bba-pending-contents/
│ emacs -q -L ../../lisp my-async-tests.org
└


Thanks you all for your previous comments.  I hope I've addressed most
of them.

Comments, critiques, ideas, corrections are most welcome.

Thanks,

Bruno


[my-async-tests.org]