Re: org syntax: is \begin{equation} a latex-fragment?

[Ihor Radchenko]

Max Nikulin  writes:

> Is it expected that
>
>  8< 
> \begin{equation}
>  >8 
>
> is parsed by (org-element-parse-buffer) as the following?
>
> (latex-fragment ... :value "\\begin{equation}")

Yes.
It matches https://orgmode.org/worg/org-syntax.html#LaTeX_Fragments

> \begin{something} is quite special in LaTeX, so despite it is similar to 
> `latex-fragment' definition, it almost certainly leads to an error. 
> Perhaps is should be detected by `org-lint' and treated as literal text 
> by `org-element' since it is incomplete `latex-environment'.

Yes, a linter would make sense.
Patches welcome!

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

Re: columnview dynamic block - different time summing behaviour for EFFORT and CLOCKSUM

[Alexander Adolf]

Ihor Radchenko  writes:

> [...]
>> `make compile` didn't complain at all, and `make test` ended with the
>> following:
>> ...
>> 4 unexpected results:
>>FAILED  ob-calc/matrix-inversion
>>FAILED  test-ob-shell/bash-uses-assoc-arrays
>>FAILED  test-ob-shell/bash-uses-assoc-arrays-with-lists
>>FAILED  test-org-table/sort-lines
>
> MacOS? There are known issues with locale rules in MacOS that may cause
> test failures.
> [...]

Yes, macOS. So I won't be worried about these.


  --alexander

Re: columnview dynamic block - different time summing behaviour for EFFORT and CLOCKSUM

[Ihor Radchenko]

Alexander Adolf  writes:

>> Also, if you mention a variable in the manual, please add #+vindex:
>> entry. Maybe even #+cindex: entry for "formatter", to make the parameter
>> more discoverable.
>
> I kept it to the format of the existing parameter descriptions, which
> don't create index entries. Happy to add one though. #+cindex would seem
> more appropriate, as it's not a variable?

When suggesting #+vindex, I was referring to
org-columns-dblock-formatter variable.

> On a loosely related note: the description of the :formatter parameter
> of the clock table does not have and index entry either. Should it get
> one too, then?

Within the scope of this patch, it is enough to add the index entry to
the newly added parameter.

More generally, we do want index entries for various parameters in
dynamic blocks and clock tables. As we do for header arguments:

#+cindex: @samp{file}, header argument

But that should be a separate patch.

For colview dynamic blocks, cindex entry may look like

#+cindex: @samp{formatter}, dynamic block parameter

>> Is there any reason why you did not remove the statistics cookies here
>> as well?
>> [...]
>
> Somehow (how?) the statistics cookies get removed in my current
> implementation. org-link-make-string does not remove them (I double
> checked). I would thus speculate that perhaps the overlay creation (to
> show description only) removes them? OTOH, I'm happy to add the
> org-trim part to make things more robust.

I see how. It is because CELL-CONTENT is not the original heading. It is
the heading name processed with `org-columns--clean-item'.

`org-column--clean-item' removes statistics cookies among other things.
It actually removes more, leading to some edge cases in your patch:

** TODO Foo

** TODO src_elisp{"Hello"} world


#+begin: columnview :id global :link t
| <25>  |  | <3>  |  |
| ITEM  | TODO | PRIORITY | TAGS |
|---+--+--+--|
| [[file:/tmp/test.org::*Foo][Foo]]   | TODO | B|  |
| [[file:/tmp/test.org::*src_elisp{"Hello"} world][world]] | TODO | B|  
|
#+end:

Note how inline src block is stripped from the link description.

We should probably also change org-clock to use
`org-columns--clean-item'.

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

Re: MathML and ODT export: inline possible?

[Max Nikulin]

On 18/04/2024 22:51, Fraga, Eric wrote:

In LaTeX, something like $a_{b_c}$.  Pandoc generates

 a  b c 

(where the a, b, and c are ...) whereas, by hand, I use

 a  b c 


MathJax may be your friend. LaTeXML and katex do not add  as well.

Actually I asked to confirm that your troubles are not with proper 
escaping of input to a converter.


I have not used katex before, I just noticed it in
Martin Edström. Re: Warn about shell-expansion in the docstring of 
org-latex-to-html-convert-command. Wed, 21 Feb 2024 15:57:47 +0100.

https://list.orgmode.org/cadojovjhoc5zzatf1y7uw2deqndhmdp5ka8mgzujhufkgte...@mail.gmail.com

During my quick try of LaTeXML I learned that "--preload=siunitx.sty" 
should not be used with fresh TeXLive despite it is recommended in the 
`org-latex-to-html-convert-command' docstring.



Pandoc also wraps the inner contents of the ... block in
.  I do not know what that does as I've only just started
learning mathml.


I have seen  as well, but I did not go deeper. I recall the 
following in the context of screen readers:


T.V Raman. Re: Org mode export accessibility. Sat, 09 Jul 2022 06:20:27 
-0700.

https:list.orgmode.org/p91czeeo21w@google.com


MathJax is a wonderful thing and the LaTeX expression embedded in the
HTML is the best one can do -- MathML loses semantics -- which is why I
always recommend preserving the LaTeX when going to HTML.

Re: columnview dynamic block - different time summing behaviour for EFFORT and CLOCKSUM

[Alexander Adolf]

Ihor Radchenko  writes:

> Alexander Adolf  writes:
>
>> Subject: [PATCH 1/2] lisp/org-colview.el: add formatter parameter to colview
>>  dynamic block
>
> Thanks for the patches!
> See my comments below.

Thanks for your swift review, and most helpful comments!

While I'm implementing these, reactions of my own on a select, few
comments of yours:

> [...]
>> +- =:formatter= ::
>> +
>> +  A function for formatting the data in the dynamic block, overriding
>> +  the default formatting function set in
>> +  ~org-columns-dblock-formatter~.
>
> You can also mention that the function also inserts the data. Something
> similar to what we do when describe the equivalent option for clock tables:
>
> - =:formatter= ::
>
>   A function to format clock data and insert it into the buffer.
>
> Also, if you mention a variable in the manual, please add #+vindex:
> entry. Maybe even #+cindex: entry for "formatter", to make the parameter
> more discoverable.

I kept it to the format of the existing parameter descriptions, which
don't create index entries. Happy to add one though. #+cindex would seem
more appropriate, as it's not a variable?

On a loosely related note: the description of the :formatter parameter
of the clock table does not have and index entry either. Should it get
one too, then?

Btw, I will also move the half-sentence about overriding the default
formatting function from the manual to the docstring of
org-dblock-write:columnview, where the :formatter parameter is
explained, too. It somehow seems more appropriate there, since a user
who is looking into implementing a formatting function will most likely
be accessing that docstring anyway (so will find the information),
whereas the information about the customization variable is likely
adding more confusion than it tries to remove for the rest of the Org
users (who will likely consult the manual only).

> [...]
> (defun org-columns--capture-view (maxlevel match skip-empty exclude-tags 
> format local  link)
>
>> +   (push (if (and link (string= p "ITEM"))
>> + (let ((search (org-link-heading-search-string
>> +cell-content)))
>> +   (org-link-make-string
>> +(if (not (buffer-file-name)) search
>> +  (format "file:%s::%s" (buffer-file-name) search))
>> +cell-content))
>
> In org-clock, we do
>
> (org-link-make-string
>(if (not (buffer-file-name)) search
>  (format "file:%s::%s" (buffer-file-name) search))
>;; Prune statistics cookies.  Replace
>;; links with their description, or
>;; a plain link if there is none.
>(org-trim
> (org-link-display-format
>  (replace-regexp-in-string
>   "\\[[0-9]*\\(?:%\\|/[0-9]*\\)\\]" ""
>   headline
>
> Is there any reason why you did not remove the statistics cookies here
> as well?
> [...]

Somehow (how?) the statistics cookies get removed in my current
implementation. org-link-make-string does not remove them (I double
checked). I would thus speculate that perhaps the overlay creation (to
show description only) removes them? OTOH, I'm happy to add the
org-trim part to make things more robust.


Will email updated patches when I will have addressed all your comments.


Many thanks and cheers,

  --alexander

Re: [BUG] LaTeX preview should use a subdirectory in /tmp

[emm . charpentier]

I can M-x trace-function org-compile-file-commands (whic now appears in the 
auocompletions) but, curiously, I *dp* **not** get a ttace output buffer.

Exporting still fails with :

org-babel-exp process emacs-lisp at position 194...
Formatting LaTeX using dvipng
Creating LaTeX Image 1...
Creating LaTeX Image 2...
Embedding 
/home/charpent/WinFiles/Temporaire/Org/file:ltximg/EssaiSnippetsLaTeX_2923a1941c0e63eab69544afa1be2ec0d95a01c4.png
 as Images/0001.png...
condition-case: OpenDocument export failed: Opening input file: No such file or 
directory, 
/home/charpent/WinFiles/Temporaire/Org/file:ltximg/EssaiSnippetsLaTeX_2923a1941c0e63eab69544afa1be2ec0d95a01c4.png
Making completion list...
Quit [8 times]

in the *Messages* buffer.

I am at loss..

--
Emmanuel Charpentier


- Mail original -
> De: "Ihor Radchenko" 
> À: "Emmanuel Charpentier" 
> Cc: emacs-orgmode@gnu.org
> Envoyé: Vendredi 19 Avril 2024 13:56:52
> Objet: Re: [BUG] LaTeX preview should use a subdirectory in /tmp
> 
> Emmanuel Charpentier  writes:
> 
> >> What if you do M-x trace-function  org-compile-file-commands
> >
> > No such function : I just have  org-compile-file , which I traced.
> 
> May you try the development branch of Org mode (main)?
> 
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
> 

Re: `org-element-cache-map' misses elements at end of buffer

[Ihor Radchenko]

Morgan Smith  writes:

> I may or may not have been trying to rewrite `org-clock-sum' for like
> the 5th time.
>
> Anyways I was wanting to parse a file using `org-element-cache-map' that
> looked roughly like this:
>
> 
> * clock
> :LOGBOOK:
> CLOCK: [2024-03-24 Sun 15:18]--[2024-03-24 Sun 15:39] =>  0:21
> :END:
> ===
>
> However I couldn't get the clock element this way.  After much trail and
> error I found that simply adding another heading on the end allowed me
> to get the clock element!
>
> I've attached a test so you can reproduce the problem.  In the test it
> is a paragraph element that is not showing up.

Thanks for reporting!
Fixed, on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=942a7320d

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

Re: org-persist-write slowing down kill-buffer

[Ihor Radchenko]

Karthik Chikmagalur  writes:

> I've been noticing that kill-buffer blocks Emacs for a noticeable
> period when killing org buffers.  Here are elp results obtained by
> instrumenting org-persist-* and kill-buffer:
>
> | Function name | Call count | Elapsed time | Average 
> time |
> |---++--+--|
> | kill-buffer   | 38 | 2.5647546329 | 
> 0.0674935429 |
> | org-persist-write-all-buffer  |  1 |  2.562779994 |  
> 2.562779994 |
> | org-persist-write-all |  1 |   2.56277329 |   
> 2.56277329 |
> | org-persist-write |  1 |  1.627834788 |  
> 1.627834788 |
> | org-persist--write-elisp-file |  1 |  0.312172392 |  
> 0.312172392 |

> It blocks Emacs for about 3 seconds each time.  Any Org file with > 500
> lines causes this behavior.
>
> I've also attached the sampling profiler output from killing an Org
> buffer.
>
> Some facts that might be relevant:
>
> - I'm using the WIP LaTeX preview system fork of Org, but there are no
>   LaTeX previews in the Org buffers that I run these tests on.  (There
>   aren't even any LaTeX fragments.)
>
> - My org-persist-dir is 627MB in size.

What is your (length org-persist--index) ?

Also, it does not look like your `org-element-ast-map' is compiled.

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

Re: [BUG] A custom org-num-format-function causes org-latex-preview warn when it called. [9.6.15 (release_9.6.15 @ /usr/share/emacs/29.3/lisp/org/)]

[Ihor Radchenko]

Ihor Radchenko  writes:

> I was able to reproduce using the provided steps using the built-in Org
> mode version and using the latest stable Org mode version.
> However, I am unable to reproduce using the latest development Org mode
> version.

Handled.

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

Re: [BUG] LaTeX preview should use a subdirectory in /tmp

[Ihor Radchenko]

Emmanuel Charpentier  writes:

>> What if you do M-x trace-function  org-compile-file-commands
>
> No such function : I just have  org-compile-file , which I traced.

May you try the development branch of Org mode (main)?

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

Re: `org-element-cache-map' misses elements at end of buffer

[Morgan Smith]

So I found another bug in `org-element-cache-map'.

Executing the following code just freezes up.  I am struggling to work
through the logic of `org-element-cache-map'.  If no-one else magically
solves my issues, I'll figure it out eventually.  But I would appreciate
some advice on how to debug this stuff (both my issue of missing
elements and freezing).

I guess my next current step is to read the manual on breakpoints.  I'm
getting a little tired of just shoving print statements everywhere.

#+BEGIN_SRC elisp
;; I get that this use case looks weird but in a more complicated
;; situation I also experienced freezing so I'm hoping solving this case
;; will also solve my other situation.
(require 'org-test)
(org-test-with-temp-text "* headline\nCLOCK: => 23:43\n"
(let ((headline (progn (goto-char (point-min)) (org-element-at-point
 (org-element-cache-map
 #'car
 :granularity 'element
 :next-re org-element-clock-line-re
 :after-element headline)))
#+END_SRC

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

[Bruno Barbier]

Hi Ihor,

Thanks for the review.

I've pushed a new version, hoping to decrease the number of dislikes
;-)

Ihor Radchenko  writes:

> Bruno Barbier  writes:
>
>>> I have a further request on interaction with penreg objects.
>>> I feel that it is not ideal that overlays associated with penreg objects
>>> cannot be fully controlled by the callers.
>>
>> I'm trying to limit the public API surface.  I don't think we should
>> leak that we are currently using a mix of overlays and text
>> properties.
>
> Let me rephrase my concern - I do not like that after reglock is no
> longer live (got success/failure signal), there is no way to clean up the
> visual hints associated with this particular reglock.
[]

For the org-pending library, "live" means "locked".  Once the outcome
is known, it can't be "live" anymore (it's unlocked); as it's not
reusable, it's "dead".

As the region is not locked anymore, the lock properties/fields can't
be trusted anymore.

But see below about removing the visual outcome hints of a given
reglock.

>>> 2. Act on the outcome overlays - there is currently no way to remove
>>>them using penreg object.
>>
>> I've added a funcion `org-pending-delete-outcome-marks' to manually
>> delete outcome marks that are in a given region.
>>
>> Else, everything is handled automatically. Once the outcome is known,
>> the reglock is dead (not live-p).  org-pending may leave outcome marks
>> about the outcomes (outcome marks are optional).  The outcome marks
>> automatically disappear if the user remove the section, or, if a new
>> lock is created for the same region.
>
> I do not like this.
> I'd like the Elisp program that creates the reglock to be able to
> clean up any visual hints associated with it. > A function doing it for a
> given region cannot do this AFAIU.

ok. I've added the function `org-pending-reglock-delete-outcome-marks,
that will delete the outcome visual hints for a given reglock, if
there are some.

I updated how the lock is described to the user
(org-pending-describe-reglock): I added a button "Forget" (if the lock
is dead, that removes the outcome marks), and I added a "Cancel"
button if the lock is still live.


>>>Maybe :cancel signal? Canceled penreg
>>>objects can then be garbage-collected from the manager.
>>
>> Cancel is handled by sending a failure message (see
>>  `org-pending-cancel').  It's customizable using the reglock field
>>  ~org-pending-reglock-user-cancel-function~, which can decide what to
>>  do (like kill a process) and which can send a better outcome.
>>  Standard 'cancel' leaves a failure outcome mark.
>
> Note that this function is not documented anywhere other than in reglock
> class documentation.

Thanks. I've improved the documentation of `org-pending' to mention
that one may want to customize the following fields of a reglock:
before-kill-function, user-cancel-function and
insert-details-function.  And, also, I added that one can attach
custom properties using the "properties" field.

> In general, I am confused about your overall design
> of the user interaction with the locks.
> The updated top commentary explains well how Elisp programs can send
> data to the locks, but it does not say anything about how Elisp programs
> can receive the data.

An elisp program, that uses org-pending, must update the locks using
`org-pending-send-update'.  That program does not receive any data
from the lock; it may customize Emacs behavior using the reglock
fields mentioned above: before-kill-function, user-cancel-function and
insert-details-function.

Hopefully, it's clearer now with the improved documentation of the
org-pending function.

Just let me know if you still think that the top commentary should
explain this.  Thanks.


> Also, I'd like to see more information in the top commentary about what
> are the "visual hints" displayed to the user and how to configure them.

If you think the current "visual hints" are good enough and could be
shipped as-is, in a first version (indirect buffers, etc.); I could
work on documenting them better.  What kind of configuration are you
thinking about ? just the faces ? or more advanced configurations ?


[...]

>>> Is there any reason why you hide the extra information behind :-alist
>>> filed? Why not directly adding extra fields with proper documentation?
>>
>> To hide them, indeed :)
>
>> The API for 'get-status and 'get-live-p are
>> `org-pending-reglock-status' and `org-pending-reglock-live-p' (they
>> are read-only).  The API for the new `useless-p' is
>> `org-pending-reglock-useless-p' (it's read-only too).
>
> We usually "hide" fields by declaring them private.
> Hiding them from the type docs is not a good idea because it defeats the
> purpose of type documentation in general.
>
>> The fields anchor-ovl, region-ovl, on-outcome, set-status and
>> creation-point are the dump of the closure context, so that
>> org-pending doesn't rely anymore on a closure to handle updates; I've
>> rewritten that 

Re: [BUG] org-paste-subtree level when point is in the middle of a heading (was: Make org-paste-subtree more predictable and useful)

[Ihor Radchenko]

Ihor Radchenko  writes:

> Steps to reproduce:
>
> 1. Create a file
>
>  1.1.1.1
>  1.1.1.2
> * 3
> ** 3.1
> *** 3.1.1
>  low-level item
> *** 3.1.2
> *** 3.1.3
>
> 2. Copy the first two headings
> 3. Move point as indicated
> 4. M-x org-paste-subtree
>
> Observed: 1.* headings inserted after 3.1.1 and before "low-level-item",
> thus breaking the sub-tree.

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

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

Re: columnview dynamic block - different time summing behaviour for EFFORT and CLOCKSUM

[Ihor Radchenko]

Alexander Adolf  writes:


> Subject: [PATCH 1/2] lisp/org-colview.el: add formatter parameter to colview
>  dynamic block

Thanks for the patches!
See my comments below.

> * lisp/org-colview.el (org-dblock-write:column view): Factor out the
> existing formatting code to new function
> org-columns-dblock-write-default, and honour new dblock parameter
> :formatter for specifying a different formatting function.

In the changelog entries, we quote the symbol and variable names like
`this'.

> +- =:formatter= ::
> +
> +  A function for formatting the data in the dynamic block, overriding
> +  the default formatting function set in
> +  ~org-columns-dblock-formatter~.

You can also mention that the function also inserts the data. Something
similar to what we do when describe the equivalent option for clock tables:

- =:formatter= ::

  A function to format clock data and insert it into the buffer.

Also, if you mention a variable in the manual, please add #+vindex:
entry. Maybe even #+cindex: entry for "formatter", to make the parameter
more discoverable.

> +*** New option ~org-columns-dblock-formatter~
> +
> +=colview= dynamic blocks now understand a new ~:formatter~ parameter
> +to use a specific function for formatting the contents of the dynamic
> +block. This new option can be used to set the global default

... and inserting its contents.

It would also be helpful to refer to the existing :formatter parameter
in clock tables.

> +*** =colview= dynamic block supports custom formatting function
> +
> +The =colview= dynamic block understands a new ~:formatter~ parameter,
> +which specifies a user-supplied function to format the data in the

... and insert the data

> +(defcustom org-columns-dblock-formatter #'org-columns-dblock-write-default
> +  "Function to format data in column view dynamic blocks.
> +For more information, see `org-columns-dblock-write-default'."
> +  :group 'org-properties
> +  :version "30.0"

We do not need :version tag when there is :package-version.

> +(defun org-columns-dblock-write-default (ipos table params)
> +  "Write out a columnview table at position IPOS in the current buffer.
> +TABLE is a table with data as produced by `org-columns--capture-view'.
> +PARAMS is the parameter property list obtained from the dynamic block
> +definition."
> +  (let ((width-specs
>   (mapcar (lambda (spec) (nth 2 spec))
>   org-columns-current-fmt-compiled)))
>  (when table

This new function ignores IPOS parameter. It should not.
 
> From 4d69c3407c7c00fe0a1f52c383ced572f3524076 Mon Sep 17 00:00:00 2001
> From: Alexander Adolf 
> Date: Mon, 15 Apr 2024 18:01:40 +0200
> Subject: [PATCH 2/2] lisp/org-colview.el: add link parameter to colview
>  dynamic block

*Add
(capitalize)

> * lisp/org-colview.el (org-columns--capture-view): Add new link
> parameter, which when non-nil causes ITEM headlines to be linked to
> their origins.
> (org-dblock-write:columnview): Pass new link parameter to
> org-columns--capture-view, and explain its use in the docstring.

`org-columns--capture-view'

> -(defun org-columns--capture-view (maxlevel match skip-empty exclude-tags 
> format local)
> +(defun org-columns--capture-view (maxlevel match skip-empty exclude-tags 
> link format local)

While this is an internal function and we are free to change it as we
need, it is generally more robust to not make changes in the order of
function arguments. I recommend

(defun org-columns--capture-view (maxlevel match skip-empty exclude-tags format 
local  link)

> +(push (if (and link (string= p "ITEM"))
> +  (let ((search (org-link-heading-search-string
> + cell-content)))
> +(org-link-make-string
> + (if (not (buffer-file-name)) search
> +   (format "file:%s::%s" (buffer-file-name) search))
> + cell-content))

In org-clock, we do

(org-link-make-string
 (if (not (buffer-file-name)) search
   (format "file:%s::%s" (buffer-file-name) search))
 ;; Prune statistics cookies.  Replace
 ;; links with their description, or
 ;; a plain link if there is none.
 (org-trim
  (org-link-display-format
   (replace-regexp-in-string
"\\[[0-9]*\\(?:%\\|/[0-9]*\\)\\]" ""
headline

Is there any reason why you did not remove the statistics cookies here
as well?

> `make compile` didn't complain at all, and `make test` ended with the
> following:
> ...
> 4 unexpected results:
>FAILED  ob-calc/matrix-inversion
>FAILED  test-ob-shell/bash-uses-assoc-arrays
>FAILED  test-ob-shell/bash-uses-assoc-arrays-with-lists
>FAILED  

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Корякин Артём]

Max Nikulin  writes:

> On 19/04/2024 00:58, Корякин Артём wrote:
>>>  shell-file-name
>> ; "pwsh.exe"
>>>  system-type
>> ; windows-nt
>>>  (w32-shell-dos-semantics)
>> ; nil
>
> I have no idea what style of escaping is expected by pwsh.exe. If it
> is the same as for cmd.exe then I would try to add it to
> `w32-system-shells' and would file a bug report against emacs with
> links to docs. However pwsh.exe as a shell may require dedicated
> support in Emacs (it it does not lead to other issues).
>
> See emacs sources for details.

Thanks. I removed that part of the config that sets pwsh.exe as
shell-file-name and now latex-previews works without any problems and
necessity to run workaround.

I am sorry. It was my fault all way around.

>> and removed shell-quote-argument from org-fc functions[4].
>
> It is no go. Improper escaping leads to vulnerabilities like

I get it. I understand that something like that only can be a temporary
local solution.

> you dropped my address in the second copy I would not receive a duplicate.

>> I don't know how to do this automatically from gnus unfortunately.
> I am not a Gnus user. Perhaps it has reply to list and reply to all
> actions. Unfortunately the message composed in gmail lacks In-Reply-To
> and Reference headers, and it causes broken thread.

I am sorry again.
Gnus has post follow up on article button and
gnus-summary-wide-reply[-with-original] commands. I tried the former

Best regards, Artsiom.