Re: Support for whitespace prefix for :noweb-prefix

[Doerthous]

Ihor Radchenko  于2024年3月29日周五 03:25写道：
>
> Doerthous  writes:
>
> > Can we add a support for whitespace prefix such that the prefix of a
> > noweb-ref replaced by whitespace characters?
> >
> > ...
> > #+name: a-fragment
> > #+begin_src elisp :noweb yes :noweb-prefix whitespace
> >   (let (<>)
> > <>)
> > #+end_src
> >
> > using whitespace :noweb-prefix, the above code will expand to
> >
> > #+begin_src elisp
> > (let ((a 0)
> >   (b 1))
> >   `(,a ,b))
> > #+end_src
>
> Do you mean that you want the code to be indented according to the major
> mode rules?
>

Why it relates to major mode,

Currently, with :noweb-prefix set to yes, the above code will be expand to
#+begin_src elisp
(let ((a 0)
(let ((b 1))
   `(,a ,b))
#+end_src

~(let (~ is the prefix of <>.

I thought we can replace just the prefix in current code[1]  with
~(setq prefix (replace-regexp-in-string "[^ \t]" " " prefix))~ ?

[1] lisp/ob-core.el (org-babel-expand-noweb-references) @ 9.6.23

Re: Support for whitespace prefix for :noweb-prefix

[Ihor Radchenko]

Doerthous  writes:

> Can we add a support for whitespace prefix such that the prefix of a
> noweb-ref replaced by whitespace characters?
>
> ...
> #+name: a-fragment
> #+begin_src elisp :noweb yes :noweb-prefix whitespace
>   (let (<>)
> <>)
> #+end_src
>
> using whitespace :noweb-prefix, the above code will expand to
>
> #+begin_src elisp
> (let ((a 0)
>   (b 1))
>   `(,a ,b))
> #+end_src

Do you mean that you want the code to be indented according to the major
mode rules?

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

Re: [Bug?] Non-existent agenda file %s.

[Ihor Radchenko]

Akash Pal  writes:

> I came across this flow of execution while trying to export a ghost
> org-file to pdf, meaning that the file is 'created' through #'find-file but
> not saved. While export the following backtrace is noted:
>
> ```
> Debugger entered--entering a function:
> * org-check-agenda-file("/home/akash/Desktop/test.org")
> org-agenda-prepare-buffers(("/home/akash/Desktop/test.org"))
> org-map-entries((lambda nil (org-set-tags (delete "attached"
> ...
> I have provisions to call #'org-map-entries before export this triggers
> #'org-agenda-prepare-buffers which finally calls #'org-check-agenda-files
>
> This asks the user what to do with a non existent file
>
> Non-existent agenda file %s. [R]emove from list or [A]bort?
>
> *Problem*
>
> I think this should not be called unless the file is part of
> 'org-agenda-files

This has been fixed already, on main branch.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=6223f20a6
Canceled.

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

Re: [Worg] CSS improvements

[Adam Porter]

On 3/28/24 08:18, Ihor Radchenko wrote:

Adam Porter  writes:


I guess we can make this into a poll... (I have no better ideas on
how to resolve the disagreement)


I think that's unnecessary.  Worg isn't a democracy, after all.  If you
are vetoing the idea, then let it be vetoed, and let us move on with the
rest of the proposed changes.  I'll go ahead and push them, without the
background color.


It is not about democracy or veto. We disagree about expectations for
#+begin_center. Expectations are not about me or you, but rather about
what WORG authors will expect. So, asking people makes sense.


If you feel strongly enough about the background color idea (which would 
be an interesting reversal ;), I'll leave that in your hands. 
Otherwise, I don't feel strongly enough about it to pursue a poll.



Also, we may consider re-using inlinetask style for TODO: entries.

Rather than
#+begin_center
TODO: Even better, find a volunteer to maintain this information!
#+end_center

We can do

 TODO Even better, ...


That is a lot of asterisks, and I can't remember if inline tasks are 
enabled by default.  :)  But in general, sure, I've no objection.  I 
think that we should have some standard way to encode tasks within Worg 
documents, regardless of what it is.


Thanks,
Adam

[Bug?] Non-existent agenda file %s.

[Akash Pal]

I came across this flow of execution while trying to export a ghost
org-file to pdf, meaning that the file is 'created' through #'find-file but
not saved. While export the following backtrace is noted:

```
Debugger entered--entering a function:
* org-check-agenda-file("/home/akash/Desktop/test.org")
org-agenda-prepare-buffers(("/home/akash/Desktop/test.org"))
org-map-entries((lambda nil (org-set-tags (delete "attached"
(org-get-tags "attached")
custom/org-export-remove-attached-tag(latex)
org-export-as(latex nil nil nil (:output-file "org-exports/test/test.tex"))
org-export-to-file(latex "org-exports/test/test.tex" nil nil nil nil
nil org-latex-compile)
org-latex-export-to-pdf(nil nil nil nil)
org-export-dispatch(nil)
funcall-interactively(org-export-dispatch nil)
command-execute(org-export-dispatch)

```

I have provisions to call #'org-map-entries before export this triggers
#'org-agenda-prepare-buffers which finally calls #'org-check-agenda-files

This asks the user what to do with a non existent file

Non-existent agenda file %s. [R]emove from list or [A]bort?

*Problem*

I think this should not be called unless the file is part of
'org-agenda-files

I have resorted to advicing the function as follows:

```
;; Advice-Patch
;; if #'org-map-entries is called then #'org-check-agenda-file is
executed through #'org-agenda-prepare-buffers
;; issue: neither functions is relevant to non-agenda files, causes
bug asking user for extra input
;; Non-existent agenda file %s.  [R]emove from list or [A]bort?
;; see : 
https://github.com/bzg/org-mode/blob/ec5d76bce1434a54a9a529dbe250b09dc3c132c0/lisp/org.el#L15340
;; Possible solution: Do not call #'org-agenda-prepare-buffers for
non-agenda files => ~exist 'org-agenda-files

(defun my-org-agenda-prepare-buffers-advice (orig-func  args)
"Advice function to modify `org-agenda-prepare-buffers'.
It filters the FILES argument to ensure only agenda files are processed."
(let ((files (if (listp (car args)) (car args) nil)))
(when files
(setq files (seq-filter #'(lambda (file) (member file
org-agenda-files)) files)))
(apply orig-func (list files

(advice-add 'org-agenda-prepare-buffers :around
#'my-org-agenda-prepare-buffers-advice)
```

I don't know if this is a bug or something peculiar to my use case. Leaving
the solution for others to see and possibly advice further.

First posted on reddit r/emacs.
https://www.reddit.com/r/emacs/comments/1bnhz24/bug_nonexistent_agenda_file_s/

[FR] Add whitespace option for :noweb-prefix

[Chen Mingzheng]

Hi


For :noweb-prefix of noweb feature, now we have "yes" or "no" option.
Can we add a new "whitespace" option so that we can:

Giving following fragments,
  #+begin_src elisp :noweb-ref varable-bindings
  (a 0)
  (b 1)
  #+end_src

  #+begin_src elisp :noweb-ref do-something
  `(,a ,b)
  #+end_src

we use the "whitespace" option here
  #+name: a-fragment
  #+begin_src elisp :noweb yes :noweb-prefix whitespace
(let (<>)
  <>)
  #+end_src

to produce the follow code:
  #+begin_src elisp
  (let ((a 0)
(b 1))
`(,a ,b))
  #+end_src


Here is a try:
  #+begin_src elisp :exports results :wrap src elisp
  (org-babel--expand-body (org-babel-lob--src-info "a-fragment"))
  #+end_src
BTW, I'm curious if there's an public API that can output the code expansion of 
an noweb src block by it's name like above?


Best regards,

Chen

Add new whitespace option for :noweb-prefix

[Chen Mingzheng]

Hi


For :noweb-prefix of noweb feature, now we have "yes" or "no" option.
Can we add a new "whitespace" option so that we can:

Giving following fragments,
  #+begin_src elisp :noweb-ref varable-bindings
  (a 0)
  (b 1)
  #+end_src

  #+begin_src elisp :noweb-ref do-something
  `(,a ,b)
  #+end_src

we use the "whitespace" option here
  #+name: a-fragment
  #+begin_src elisp :noweb yes :noweb-prefix whitespace
(let (<>)
  <>)
  #+end_src

to produce the follow code:
  #+begin_src elisp
  (let ((a 0)
(b 1))
`(,a ,b))
  #+end_src


Here is a try:
  #+begin_src elisp :exports results :wrap src elisp
  (org-babel--expand-body (org-babel-lob--src-info "a-fragment"))
  #+end_src
BTW, I'm curious if there's an public API that can output the code expansion of 
an noweb src block by it's name like above?


Best regards,

Chen

Support for whitespace prefix for :noweb-prefix

[Doerthous]

Hi

Can we add a support for whitespace prefix such that the prefix of a
noweb-ref replaced by whitespace characters?

Here is a use case,

#+begin_src elisp :noweb-ref varable-bindings
(a 0)
(b 1)
#+end_src

#+begin_src elisp :noweb-ref do-something
`(,a ,b)
#+end_src

#+name: a-fragment
#+begin_src elisp :noweb yes :noweb-prefix whitespace
  (let (<>)
<>)
#+end_src

using whitespace :noweb-prefix, the above code will expand to

#+begin_src elisp
(let ((a 0)
  (b 1))
  `(,a ,b))
#+end_src

Best regards,

D

Re: [Worg] CSS improvements

[Ihor Radchenko]

Adam Porter  writes:

>> I guess we can make this into a poll... (I have no better ideas on
>> how to resolve the disagreement)
>
> I think that's unnecessary.  Worg isn't a democracy, after all.  If you
> are vetoing the idea, then let it be vetoed, and let us move on with the 
> rest of the proposed changes.  I'll go ahead and push them, without the 
> background color.

It is not about democracy or veto. We disagree about expectations for
#+begin_center. Expectations are not about me or you, but rather about
what WORG authors will expect. So, asking people makes sense.

Also, we may consider re-using inlinetask style for TODO: entries.

Rather than
#+begin_center
TODO: Even better, find a volunteer to maintain this information!
#+end_center

We can do

 TODO Even better, ...

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

Re: [WORG] 2680e65 * org-maintenance.org (Copyright assignments): Minor improvements

[Ihor Radchenko]

Adam Porter  writes:

>> Actually, what Bastien suggested is slightly different.
>> See the attached tentative patch.
>
> Sure.  I've pushed that, adding a "co-authored-by" line for Bastien.

Thanks!

Re: [WORG] 2680e65 * org-maintenance.org (Copyright assignments): Minor improvements

[Adam Porter]

On 3/28/24 07:01, Ihor Radchenko wrote:

Adam Porter  writes:


On 3/26/24 09:59, Ihor Radchenko wrote:


I agree. My concern was not about dropping the previous wording.

What about

The assignment process does not always go quickly; occasionally it may
get stuck or overlooked at the FSF.  If there is no response to the
contributor from FSF, Org mode maintainers can contact the FSF at
   =copyright-clerk AT fsf DOT org=.  Historically, FSF replies to the
   maintainer request within a few days.

 ^^^

Other than changing "request" to, e.g. "arrive," no objection from me.


Actually, what Bastien suggested is slightly different.
See the attached tentative patch.


Sure.  I've pushed that, adding a "co-authored-by" line for Bastien.

Thanks,
Adam

Re: [Worg] CSS improvements

[Adam Porter]

On 3/28/24 06:44, Ihor Radchenko wrote:


So I would still suggest that, on Worg, we use my suggested styling
on #+begin_center blocks.  This would make them useful and fulfill
their natural purpose.


I think that we have a principal disagreement here. For me,
highlighting #+begin_center blocks is extremely unnatural. I would
never expect that, and I would be extremely surprised by that.


It's a mild background color fitting with the theme of the Worg site.

And as I've said, centering has not even had any effect up til now.  So
I don't think it's a big deal.


Since Worg is updated with relatively low frequency, anyway,
perhaps this suggestion could be tried as an experiment.  If
problems are found with it, then the extra styling, beyond merely
centering the text, could be reverted.  Nothing is permanent here;
we've probably spilled more virtual ink on this topic than would be
affected by the change.


I am mostly worried about future effect. We will not have any
problems with it in the near future, because the only user of this
style will be your new WORG page.


I don't know what there is to worry about.  If someone centers some text 
on a Worg page to make it stand out, it would...stand out?  :)



Anyway, if this idea is vetoed, it would still be good to have some
way to make text stand out in a standard way, similar to various
HTML documentation styles in other projects (to avoid resorting to
inline HTML).  It seems like a missing feature on Worg.


Agree.


And the other changes in the patch would be good to have,
regardless.


Yup.



I guess we can make this into a poll... (I have no better ideas on
how to resolve the disagreement)


I think that's unnecessary.  Worg isn't a democracy, after all.  If you
are vetoing the idea, then let it be vetoed, and let us move on with the 
rest of the proposed changes.  I'll go ahead and push them, without the 
background color.


Thanks,
Adam

Re: [BUG] ob-calc and decimal number in :var [9.7-pre (release_9.6.17-1446-g252971 @ /home/viz/lib/emacs/straight/build/org/)]

[Ihor Radchenko]

Visuwesh  writes:

> In emacs -Q, try evaluating the source block
>
> #+BEGIN_SRC calc :var thetarot=1.3
>   1/thetarot  
> #+END_SRC
>
> and witness the following error:
>
> Debugger entered--Lisp error: (wrong-type-argument listp 1.3)
>   nth(2 1.3)

Confirmed.

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

[BUG] ob-calc and decimal number in :var [9.7-pre (release_9.6.17-1446-g252971 @ /home/viz/lib/emacs/straight/build/org/)]

[Visuwesh]

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

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

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


In emacs -Q, try evaluating the source block

#+BEGIN_SRC calc :var thetarot=1.3
  1/thetarot
#+END_SRC

and witness the following error:

Debugger entered--Lisp error: (wrong-type-argument listp 1.3)
  nth(2 1.3)
  calc-div-fractions(1 1.3)
  math-div(1 1.3)
  math-mul-or-div(1 1.3 nil t)
  math-combine-prod(1 1.3 nil t t)
  math-simplify-one-divisor((1 1.3) (1.3))
  math-simplify-divisor((1 1.3) (1.3) nil t)
  math-simplify-divide((/ 1 1.3))
  #f(compiled-function (expr) #)((/ 1 1.3))
  math-simplify-step((/ 1 1.3))
  math-simplify((/ 1 1.3))
  calc-normalize-fancy((/ 1 1.3))
  calc-normalize((/ 1 1.3))
  math-evaluate-expr((/ 1 1.3))
  #f(compiled-function (line) #)("1/thetarot")
  mapc(#f(compiled-function (line) #) 
("1/thetarot"))
  org-babel-execute:calc("1/thetarot\11" ((:var thetarot . 1.3) 
(:colname-names) (:rowname-names) (:result-params "replace") (:result-type . 
value) (:results . "replace") (:exports . "code") (:session . "none") (:cache . 
"no") (:noweb . "no") (:hlines . "no") (:tangle . "no")))
  org-babel-execute-src-block(nil ("calc" "1/thetarot\11" ((:var thetarot . 
1.3) (:colname-names) (:rowname-names) (:result-params "replace") (:result-type 
. value) (:results . "replace") (:exports . "code") (:tangle . "no") (:hlines . 
"no") (:noweb . "no") (:cache . "no") (:session . "none")) "" nil 148 
"(ref:%s)"))
  org-ctrl-c-ctrl-c(nil)
  funcall-interactively(org-ctrl-c-ctrl-c nil)
  call-interactively(org-ctrl-c-ctrl-c nil nil)
  command-execute(org-ctrl-c-ctrl-c)

This happens because the decimal number 1.3 is not in the format calc
expects.  A VERY DIRTY patch to do this is

diff --git a/lisp/ob-calc.el b/lisp/ob-calc.el
index f36df77ff..6ef09032a 100644
--- a/lisp/ob-calc.el
+++ b/lisp/ob-calc.el
@@ -111,7 +116,7 @@ EL is taken from the output of `math-read-exprs'."
   (if (and (eq 'var (car el)) (member (cadr el) org--var-syms))
  (progn
(calc-recall (cadr el))
-   (prog1 (calc-top 1)
+   (prog1 (math-read-exprs (format "%S" (calc-top 1)))
  (calc-pop 1)))
(mapcar #'org-babel-calc-maybe-resolve-var el))
 el))

but unfortunately, I don't have the time currently to polish this up.
If someone doesn't beat me to it, I will send a more polished+tested
patch by the beginning of May (if I get a lot of free time, I can try to
make one in the meanwhile).

Emacs  : GNU Emacs 30.0.50 (build 2, x86_64-pc-linux-gnu, X toolkit, cairo 
version 1.18.0, Xaw scroll bars)
 of 2024-02-17
Package: Org mode version 9.7-pre (release_9.6.17-1446-g252971 @ 
/home/viz/lib/emacs/straight/build/org/)

Re: [PATCH] Run latex more than once for LaTeX src block evaluation

[Ihor Radchenko]

Michael  writes:

> Should we perhaps have different variables for preview & Org
> source block evaluation?

Likely yes.

In fact, ob-latex is making use of `org-preview-latex-process-alist'
only in a single cond branch in `org-babel-execute:latex' - when we have
:file foo.png

However, that branch assumes that `org-preview-latex-default-process' is
'dvipng (the default value). If one changes it to, say dvisvgm, the
generated image will not be a .png image:

(setq org-preview-latex-default-process 'dvisvgm)

#+begin_src latex :results file link :file test.png
x^2
#+end_src

#+RESULTS:
[[attachment:test.png]]

^ This is actually an svg image, renamed to "test.png".

So, it makes sense for `org-babel-execute:latex' to override
`org-preview-latex-default-process' temporarily, to something actually
generating .png file.

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

Re: [WORG] 2680e65 * org-maintenance.org (Copyright assignments): Minor improvements

[Ihor Radchenko]

Adam Porter  writes:

> On 3/26/24 09:59, Ihor Radchenko wrote:
>
>> I agree. My concern was not about dropping the previous wording.
>> 
>> What about
>> 
>> The assignment process does not always go quickly; occasionally it may
>> get stuck or overlooked at the FSF.  If there is no response to the
>> contributor from FSF, Org mode maintainers can contact the FSF at
>>   =copyright-clerk AT fsf DOT org=.  Historically, FSF replies to the
>>   maintainer request within a few days.
> ^^^
>
> Other than changing "request" to, e.g. "arrive," no objection from me.

Actually, what Bastien suggested is slightly different.
See the attached tentative patch.

>From eff683e8a936edb0e84516daee8d4b8972e3ab8a Mon Sep 17 00:00:00 2001
Message-ID: 
From: Ihor Radchenko 
Date: Thu, 28 Mar 2024 14:59:40 +0300
Subject: [PATCH] org-maintenance.org: Clarify how to followup when no reply
 from FSF

* org-maintenance.org (Assignment and verification): Explain that we
allow one month for FSF to reply for the copyright request and then
follow up.

Link: https://orgmode.org/list/87o7b3bye3.fsf@localhost
---
 org-maintenance.org | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/org-maintenance.org b/org-maintenance.org
index cfbb55b4..a0393e20 100644
--- a/org-maintenance.org
+++ b/org-maintenance.org
@@ -467,9 +467,12 @@ *** Assignment and verification
 #+end_center
 
 The assignment process does not always go quickly; occasionally it may
-get stuck or overlooked at the FSF.  The contact at the FSF for this
-is: =copyright-clerk AT fsf DOT org=.  In rare cases, an inquiry from an
-Org maintainer gets the process moving again.
+get stuck or overlooked at the FSF.  If there is no response to the
+contributor from FSF within a month[fn:: The official response time is
+5 business days, according
+https://www.gnu.org/prep/maintain/maintain.html.  We allow a bit
+more.], the maintainers can ask the contributor to follow up with the
+FSF, CCing the Org maintainers.
 
 *** Authorship information
 
-- 
2.44.0


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

Re: [Worg] CSS improvements

[Ihor Radchenko]

Adam Porter  writes:

> ...
> So I would still suggest that, on Worg, we use my suggested styling on 
> #+begin_center blocks.  This would make them useful and fulfill their 
> natural purpose.

I think that we have a principal disagreement here. For me, highlighting
#+begin_center blocks is extremely unnatural. I would never expect that,
and I would be extremely surprised by that.

I guess we can make this into a poll... (I have no better ideas on how
to resolve the disagreement)

> Since Worg is updated with relatively low frequency, anyway, perhaps 
> this suggestion could be tried as an experiment.  If problems are found 
> with it, then the extra styling, beyond merely centering the text, could 
> be reverted.  Nothing is permanent here; we've probably spilled more 
> virtual ink on this topic than would be affected by the change.

I am mostly worried about future effect.
We will not have any problems with it in the near future, because the
only user of this style will be your new WORG page.

> Anyway, if this idea is vetoed, it would still be good to have some way 
> to make text stand out in a standard way, similar to various HTML 
> documentation styles in other projects (to avoid resorting to inline 
> HTML).  It seems like a missing feature on Worg.

Agree.

> And the other changes in the patch would be good to have, regardless.

Yup.

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

ox-html content-type metadata (was: [BUG] ox-html output does not pass validation for html4-strict doctype [9.7-pre (release_9.6.23-1423-gcea6a1.dirty @ /home/yantar92/.emacs.d/straight/build/org/)])

[Ihor Radchenko]

This is tangent to the original problem I described.

Max Nikulin  writes:

> On 25/03/2024 18:18, Ihor Radchenko wrote:
>> I am wondering whether it is at all possible to use the same syntax and
>> yet pass validation for all the allowed values of `org-html-doctype':
>> "html4-strict", "html4-transitional", "html4-frameset", "xhtml-strict",
>> "xhtml-transitional", "xhtml-frameset", "xhtml-11", "html5", "xhtml5".
>
> Is it correct to use text/html for XHTML? I would expect 
> application/xhtml+xml, but it is better to check standard.

It is certainly not an error.

Also,
https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types#texthtml
says

All HTML content should be served with this type. Alternative MIME types
for XHTML (like application/xhtml+xml) are mostly useless nowadays.

> For html5 my expectation is
>
>  
>
> instead of http-equiv
> https://developer.mozilla.org/en-US/docs/Web/HTML/Element/meta#charset

What made you think that your expectation is not fulfilled by ox-html?

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

Re: [PATCH] Highlight ANSI sequences in the whole buffer (was [PATCH] ANSI color on example blocks and fixed width elements)

[Ihor Radchenko]

Nathaniel Nicandro  writes:

> Feedback appreciated!

Thanks for the update!

> I've finally implemented a solution to what I've discussed previously,
> inserting zero width spaces as boundary characters after an ANSI
> sequence to act as a separator from the text after the sequence.  This
> would handle the scenario where deleting into the end byte of a
> sequence causes ansi-color to recognize the partially deleted sequence
> plus the character directly after the end byte to be a new sequence.
> This looked like the invisible region containing a sequence eating up
> other characters not intended to be part of the region.
> ...
> So the implementation of that rule of maintaining a zero width space
> after valid sequences and the rules around deleting into the space or
> insertion in front of a space are the main changes in this patch
> compared to previous versions.

This is very fragile.
I believe that hooking into `org-fold-check-before-invisible-edit' would
lead to simpler implementation.

I also do not like the idea that fontification code modifies the buffer.

I tried your latest patch with test-ansi.org file you shared earlier:

1. Open the file and move to the end of the headline "Greater elements"
2.  
3. Observe fontification extending past the title.

I also edited it around in various places and I managed to trigger
parser errors when the parser lost track of the modifications. This was
presumably because your patch edited the buffer.

I also observed strange glitches and hangs when I tried to surround an
ANSI-colored region like =[42mtask 1[0m= and then edited near the
boundaries.

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

Re: Feature request: exclude sub-trees by backend

[Ihor Radchenko]

Edgar Lux  writes:

> Hi, I had a need for this again (sorry for the necro-bump).

One month is perfectly normal reply time by mailing list standards :)
We just start questioning whether the discussion is active after one month.

> On Feb 26, 2024 at 5:51 PM, Ihor Radchenko  wrote:
>> The suggestions to use backend-specific export tag in the links are used
>> as ugly workarounds...
>
> Ok. It was just to show that there are other people who may use it :) .

Note that we are currently discussing somewhat similar idea, but for all
the Org markup elements, not just headings:
https://list.orgmode.org/877chvvq1b.fsf...@posteo.net/T/#madc064d96ae66467adc2ea9adb53c6c0edc7aaf7

>> As for ignore-heading, ...
>> ... the author of Org export system
>> repeatedly opposed it. This is why:
>> https://list.orgmode.org/87mwdfzmox@nicolasgoaziou.fr/
>
> Ok. Sorry. I should have assumed (or looked for) that there was a reason :) .

To be fair, it would be nice to include :ignore: tag as a part of the
Org. However, we need to somehow make sure that nothing unexpected
happens when users use :ignore: in a context where it does not make
sense:

* Heading
** Sub-heading
Text.
* Ignored :ignore:
Merging this text with previous sub-heading is unexpected.

If you have ideas how to address such scenarios, feel free to share
them.

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

Re: [BUG] org-clock-sum: Wrong type argument: fixnump, nil [9.7-pre (release_9.6.22-1309-g8507ef @ /home/grfz/src/org-mode/lisp/)]

[Gregor Zattler]

Hi Ihor,
* Ihor Radchenko  [2024-03-27; 12:00 GMT]:
> Gregor Zattler  writes:
>
>>> I'd like to see the problematic timestamp to understand what might be
>>> going on there.
>>
>>
>> thanks for your instructions, I edited it a bit:
>>
>> "- SxII VPN vxx USB S ()
>>  CLOCK: [2012-02-02 Do 14:00]--[2012-02-02 Do 16:00] =>  2:00
>>  - SxII; Rxx kx, n xx
>>  Clock: [2012-02-01 Mi 17:34]--[2012-02-01 Mi 18:24] =>  0:50
>
> The parser had inconsistent handling of case-sensitivity in "CLOCK:"
> keyword. Now, fixed - it should be case-insensitive.

I did not realize this glitch --although I stumbled
upon such one before.

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

Thanks so much.  I confirm it works now with my file
(after finding another glitch).

Ciao, gregor

Re: Question about citation formatting

[Pedro Andres Aranda Gutierrez]

Christian writes:

> Dear org users,
>
> This is my second paper I am formatting with the new citation framework,
> this time using csl for the first time, since basic does not fit the
> bill anymore.
>
> This paper is discussing and comparing translations to the same text. So
> when I mention publications in the text, I want to have the keyword to
> be the translator, rather than the author.

Hi Christian,

just to focus the discussion... if you were to export to LaTeX (just a
hypothesis), would
https://tex.stackexchange.com/questions/381615/citing-a-translator
cover your needs?

Thx, /PA

-- 
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