Re: [PATCH] ob-plantuml: Allow setting PlantUML args for jar file

[Max Nikulin]

Hi.

Disclaimer: I am neither plantuml nor ditaa user, so my comments may 
have no sense.


On 15/01/2022 13:20, Ihor Radchenko wrote:

Dejan Josifović writes:


Comparing ob-plantuml.el and plantuml-mode.el files I found what is the
problem. plantuml-mode has a customizable variable for specifying
arguments when using PlantUML from jar (plantuml-jar-args (list
"-charset" "UTF-8" ). The charset arguments is what is needed for
the images to render correctly (I confirmed it by implementing it locally).

I was wondering why such variable doesn't exist in ob-plantuml.


Dejan, have you tried :java or :cmdline header arguments?


Even though I was unable to reproduce your problem (most likely because
my system is different), it sounds like a good idea to allow users to
customise jar args as well.


I agree that arguments should be customizable when the application is 
launched from jar, but there are already :java argument that is inserted 
before jar file and :cmdline argument that is appended after it.


Another consideration is that ob-ditaa and ob-plantuml should use 
similar set of header arguments for additional parameters. They (and 
third-party packages) may even share some parameters related to java 
executable location and arguments for tuning of java VM (memory limits, 
etc.).



See the attached patch. It appears that we can simply carry over the
executable args to jar (but please test it on other systems!)



-   (t (list java
-"-Djava.awt.headless=true"


(unrelated to this patch) The line above is a recent change, and I do 
not see a reason why it is not added in a customizable way through 
appending (:java "-Djava.awt.headless=true") to 
`org-babel-default-header-args:plantuml'. Maybe I just missed something 
stupid since I have not tried it.



-"-jar"
-(shell-quote-argument 
(expand-file-name org-plantuml-jar-path))
+   (t `(,java
+"-Djava.awt.headless=true"
+"-jar"
+,(shell-quote-argument (expand-file-name 
org-plantuml-jar-path))
+ ,@org-plantuml-args


Is there a case when some arguments are suitable for dedicated binary 
but should be avoided for jar (when a user has both executable from 
system package and manually downloaded jar having newer version)? It may 
be a reason to have separate variables (or header arguments).


I suppose, a part of problem that there are no plantuml and ditaa users 
and subscribers of this list who are ready to discuss code of related 
babel packages.

Re: Strange bug with text scaling and variable-pitch

[Andrew Hyatt]

I tracked this down to a bug in emacs, which happens only when indirect
buffers are cloned. Reported as bug#53294 with a patch.

On Thu, Jan 13, 2022 at 9:51 PM Andrew Hyatt  wrote:

>
> Hi all,
>
> I've been having an odd problem where if I try to change my text
> scale on my org capture buffers, the scale keeps increasing, and
> increases the scale on the parent of the indirect org-capture
> buffer, on each capture.
>
> I'm using org-mode 9.5, emacs 29.0.50.
>
> Debugging into the issue, I realized I can only reproduce this if
> the org-mode buffer has variable-pitch-mode on.
>
> Here's a short repro that works on emacs -Q (of course, you may
> want to change the path):
>
> (require 'face-remap) (defun ash/big-font ()
>   "Creates a font that is big enough for about 20 lines of text."
>   (interactive) (let ((text-scale-mode-amount (/ (frame-height)
>   20)))
> (text-scale-mode 1)))
>
> (require 'org-capture) (add-hook 'org-capture-mode-hook
> #'ash/big-font) (setq org-capture-templates '(("c" "Capture" entry
> (file "~/Desktop/test.org") nil))) (find-file
> "~/Desktop/test.org") (variable-pitch-mode 1)
>
> After evaluating this, every time you call org-capture, the text
> size will increase, until the text size is so large emacs crashes!
>
> I have also tried to reproduce this without org-mode, just using
> indirect buffers, but can't do it.  Something that org-mode is
> doing is causing this, but org-capture is complicated enough that
> I can't really see what it could be.  I can and will continue
> looking into this, but I'm curious if anyone might have a clue as
> to what is going wrong here.
>

Re: org-->html text between @ should be red.

[Uwe Brauer]

>>> "JMM" == Juan Manuel Macías  writes:

> I think this would work:
> (setq org-export-filter-plain-text-functions
>   (remove 'my-html-red org-export-filter-plain-text-functions))

> Anyway, I recommend that you take a look at the documentation on filters
> that Timothy pointed you to, as custom filters are tremendously useful
> and versatile, and very "surgical". I use them a lot!

> You can also apply a filter only in a document, by using the #+bind
> keyword and including the function in a non-exportable code block:

> #+begin_src emacs-lisp :exports results :results none
>   (defun my-html-red (text backend info)
> (when (org-export-derived-backend-p backend 'html)
>   (replace-regexp-in-string "@\\([^@]*\\)@"
>   "\\1"
>   text)))
> #+end_src

> #+bind: org-export-filter-plain-text-functions (my-html-red)

> (You need to set org-export-allow-bind-keywords to non-nil)

Thanks very much!!!

Regards

Uwe 


smime.p7s
Description: S/MIME cryptographic signature

Re: org-->html text between @ should be red.

[Juan Manuel Macías]

Uwe Brauer writes:

> (add-to-list 'org-export-filter-plain-text-functions 'my-html-red)
>
> How could I remove something from a list?

I think this would work:

(setq org-export-filter-plain-text-functions
(remove 'my-html-red org-export-filter-plain-text-functions))

Anyway, I recommend that you take a look at the documentation on filters
that Timothy pointed you to, as custom filters are tremendously useful
and versatile, and very "surgical". I use them a lot!

You can also apply a filter only in a document, by using the #+bind
keyword and including the function in a non-exportable code block:

#+begin_src emacs-lisp :exports results :results none
  (defun my-html-red (text backend info)
(when (org-export-derived-backend-p backend 'html)
  (replace-regexp-in-string "@\\([^@]*\\)@"
"\\1"
text)))
#+end_src

#+bind: org-export-filter-plain-text-functions (my-html-red)

(You need to set org-export-allow-bind-keywords to non-nil)

Best regards,

Juan Manuel 

Re: org-->html text between @ should be red.

[Uwe Brauer]

>>> "JMM" == Juan Manuel Macías  writes:

> Uwe Brauer writes:
>> Thanks very much it works as expected. However I just realized (and
>> this is true also for the org-mime filter that the reg-exp has a flaw.
>> 
>> I used the text 
>> 
>> 
>> =email:o...@mat.ucm.es=
>> 
>> So there is only one @, nevertheless the exporter translated that to 
>> email:oubmat.ucm.es
>> 
>> But this is wrong in my view.
>> 
>> Any ideas how to deal with such a situation?

> You can bind the function to org-export-filter-plain-text-functions
> instead of ...-final-output-functions.

Perfect, thanks.

Just out of curiosity because google does not know the answer

There is 
(add-hook 'some-hook 'some-function)
(remove-hook 'some-hook 'some-function)

So if I have 

(add-to-list 'org-export-filter-plain-text-functions 'my-html-red)

How could I remove something from a list?

Regards

Uwe 


smime.p7s
Description: S/MIME cryptographic signature

Re: org-->html text between @ should be red.

[Juan Manuel Macías]

Uwe Brauer writes:

> Thanks very much it works as expected. However I just realized (and
> this is true also for the org-mime filter that the reg-exp has a flaw.
>
> I used the text 
>
>
>  =email:o...@mat.ucm.es=
>
> So there is only one @, nevertheless the exporter translated that to 
> email:oubmat.ucm.es
>
> But this is wrong in my view.
>
> Any ideas how to deal with such a situation?

You can bind the function to org-export-filter-plain-text-functions
instead of ...-final-output-functions.

That way you wouldn't get false positives on lines like:

=email:o...@mat.ucm.es= some text @some text@

email:o...@mat.ucm.es some text some 
text

Best regards,

Juan Manuel 

Re: org-->html text between @ should be red.

[Uwe Brauer]

>>> "T" == Timothy   writes:
Hi Timothy
> Hi Uwe,
>> And every text between @ appears red.
>> 
>> Can I have a similar setting when exporting an org file to html via the
>> «normal» html exporter?

> Have a look at the filter functions, such as
> `org-export-filter-final-output-functions'. See
> .

Thanks, Juan already solved it, thanks.


smime.p7s
Description: S/MIME cryptographic signature

Re: org-->html text between @ should be red.

[Uwe Brauer]

>>> "JMM" == Juan Manuel Macías  writes:

> Uwe Brauer writes:
>> Can I have a similar setting when exporting an org file to html via the
>> «normal» html exporter?

> Using a custom filter?

> #+begin_src emacs-lisp

> (defun foo (text backend info)
> (when (org-export-derived-backend-p backend 'html)
>   (replace-regexp-in-string "@\\([^@]*\\)@"
>   "\\1"
>   text)))

> (add-to-list 'org-export-filter-final-output-functions 'foo)

> #+end_src

Thanks very much it works as expected. However I just realized (and this is 
true also for the org-mime filter that the reg-exp has a flaw.

I used the text 


 =email:o...@mat.ucm.es=

So there is only one @, nevertheless the exporter translated that to 
email:oubmat.ucm.es

But this is wrong in my view.

Any ideas how to deal with such a situation?

Thanks

Uwe 


smime.p7s
Description: S/MIME cryptographic signature

Re: org-->html text between @ should be red.

[Timothy]

Hi Uwe,

> And every text between @ appears red.
>
> Can I have a similar setting when exporting an org file to html via the
> «normal» html exporter?

Have a look at the filter functions, such as
`org-export-filter-final-output-functions'. See
.

All the best,
Timothy

Re: org-->html text between @ should be red.

[Juan Manuel Macías]

Uwe Brauer writes:

> Can I have a similar setting when exporting an org file to html via the
> «normal» html exporter?

Using a custom filter?

#+begin_src emacs-lisp

(defun foo (text backend info)
(when (org-export-derived-backend-p backend 'html)
  (replace-regexp-in-string "@\\([^@]*\\)@"
"\\1"
text)))

(add-to-list 'org-export-filter-final-output-functions 'foo)

#+end_src

Best regards,

Juan Manuel 

org-->html text between @ should be red.

[Uwe Brauer]

Hi 

When I use org-mime-htmlize, then I can use the setting 

Render text between "@" in red color, you can use =org-mime-html-hook=,
#+begin_src elisp
(add-hook 'org-mime-html-hook
  (lambda ()
(while (re-search-forward "@\\([^@]*\\)@" nil t)
  (replace-match "\\1"
#+end_src

And every text between @ appears red.

Can I have a similar setting when exporting an org file to html via the
«normal» html exporter?

Thanks 

Uwe Brauer 

Re: Depreciating TeX-style LaTeX fragments (was: Org Syntax Specification)

[Timothy]

Hi Sebastien,

Thanks for your comments, and your thoughts on the proposed deprecation.

It’s worth explicitly considering why we wouldn’t want to steer people away from
the TeX-syntax LaTeX fragments, so I am glad you have brought up some reasons.
I do not find myself agreeing with them however, and will endeavour to explain
why below.

⁃ It is easier to use
  • Hmm. Not sure about this. Keystroke wise we’re comparing `$$' to `\('. The
latter can be completed by smartparens, but since single dollars are
reasonable Org content the former can’t. At this point the only argument is
muscle memory, and if you’re a LaTeX user (a good target audience for LaTeX
fragments I think), I’d expect LaTeX-style `\(' to be more familiar.
⁃ Easier to read
  • I had a quick look at a document to gauge this for myself, and if anything I
found the opposite (see ). This may be influenced 
by
a minor fontification tweak I made to LaTeX style input though.
⁃ more commonly used (and known) in tex documents (a quick web search for sample
  tex documents confirms the latter).
⁃ Removing this syntax would make org slightly harder to pick up, with respect
  to writing scientific documents.
  • With respect to writing scientific documents, I think we can reasonably
expect people to be familiar with `\(', particularly given the points I 
raise
below.

These points seem to have a common thread in wanting to have Org be like LaTeX.
I find this sensible, but I think this is a good opportunity to point out that
$/$$ are very much second class citizens in LaTeX now, no matter what you may
see in old documents.

To quote from David Carlisle (one of the main members of the LaTeX3 team) on 
[tex.stackexchange]:
> $$ is TeX primitive syntax, which, as others have commented is hard to
> redefine (in classic TeX there is no command name which triggers entering or
> leaving display math).
> LaTeX doesn’t officially support $$. The most noticeable failure if you use
> the syntax is that the fleqn option will no longer affect the display of the
> mathematics, it will remain centered rather than being set flush left.

Another member of the LaTeX3 team, Joseph Wright, has made even stronger
comments about $-syntax on [tex.stackexchange]:
> I’d note with my ’LaTeX3’ hat on that there is a strong chance we’ll favour 
> `\(
> ... \)' to the point of not supporting `$...$' for LaTeX3. So in the long 
> term it
> might be best to get used to `\(...\)'.

In further comments Joseph goes on to say that it is likely that $-syntax will
/not/ be dropped outright, but that $$ likely will be. Among other
things the $-syntax produces worse error reporting and spacing.

So, to sum up LaTeX currently prefers `\(...\)' / `\[...\]' over `$' / `$$', 
and it
looks like people will be pushed more strongly in this direction in future.

More than anything else, I think this demonstrates why aside from annoyances
with the parsing, purely from a user perspective, it would make sense to favour
LaTeX-syntax LaTeX fragments.

All the best,
Timothy


[tex.stackexchange] 


[tex.stackexchange] 

Re: [PATCH] make test: Make failure results more verbose

[Max Nikulin]

On 02/01/2022 20:12, Ihor Radchenko wrote:


In newer Emacs, ERT is capable of providing more info about FAILED
tests. Maybe we can enable this option by default in the Org test suite?

Thinking more, I have realized that something is wrong.

Behavior of tests in Org should be controlled by EMACS_TEST_VERBOSE 
*environment* variable. Org makefiles may have it on by default, but it 
should not override explicitly chosen value. Fortunately Emacs 
repository contains no makefiles from Org, so it will not cause conflict 
with Emacs builds.


The problem is that EMACS_TEST_VERBOSE interface is broken. In the 
following case I expect that test summary should not be verbose:


ert-sample.el
 >8 
(require 'ert)
(ert-deftest ert-sample ()
  (should (equal 5 (* 2 2
(ert-run-tests-batch-and-exit)
 8< 

(I am tried it with Emacs-27, so I put a copy of ert.el from git HEAD to 
~/ert)


EMACS_TEST_VERBOSE= emacs --batch -Q -L ~/ert -l ert-sample.el

1 unexpected results:
   FAILED  ert-sample  ((should (equal 5 (* 2 2))) :form (equal 5 4) 
:value nil :explanation (different-atoms (5 "#x5" "?") (4 "#x4" "?")))


That is why I am going to file a bug against ert.

In a minimal variant empty string (`getenv' return value) should not be 
considered as t.


For better user experience, I expect that the following case-insensitive 
strings should be considered as false: "0", "false", "no", "n", "off", 
"f" (borrowed from .ini), "none", "nil". Other values should be 
considered as true or anything besides "1", "true", "yes", "y", "on", 
"t" should be considered as invalid value.


I am attaching a tentative patch for Org that should make 
EMACS_TEST_VERBOSE setting more transparent.
>From 5f8d93a9895b67ce89bac3b2d95ca723fe754ab4 Mon Sep 17 00:00:00 2001
From: Max Nikulin 
Date: Sat, 15 Jan 2022 22:54:30 +0700
Subject: [PATCH] make test: Make failure summary more verbose

* mk/default.mk: By default enable verbose failure summary for Emacs-28
or newer.

Set or unset EMACS_TEST_VERBOSE environment to control reporting of failure
reasons in summary since ERT switches to verbose mode even by an empty
string. As an extension, allow values as "0", "off", "no" to disable
verbosity.
---
 mk/default.mk | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/mk/default.mk b/mk/default.mk
index c8a15bdd2..11ddcc2e1 100644
--- a/mk/default.mk
+++ b/mk/default.mk
@@ -32,6 +32,24 @@ TMPDIR ?= /tmp
 testdir = $(TMPDIR)/tmp-orgtest
 
 # Configuration for testing
+# Verbose ERT summary by default for Emacs-28 and above.
+# To override:
+# - Add to local.mk
+#   EMACS_TEST_VERBOSE =
+# - Export EMACS_TEST_VERBOSE environment variable with empty value
+# - Run tests as
+#   EMACS_TEST_VERBOSE= make test [OTHER_ARGUMENTS...]
+#   or as
+#   make test EMACS_TEST_VERBOSE= [OTHER_ARGUMENTS...]
+# For convenience some other values are recognized as false by Org makefiles
+# ("0", "no", "off", "false") despite any set value (including empty one)
+# is considered as true by ERT.
+EMACS_TEST_VERBOSE ?= yes
+ifneq (,$(filter-out 0 n N no No NO f F false False FALSE off Off OFF none None NONE nil NIL,$(EMACS_TEST_VERBOSE)))
+export EMACS_TEST_VERBOSE
+else
+unexport EMACS_TEST_VERBOSE
+endif
 # add options before standard load-path
 BTEST_PRE   =
 # add options after standard load path
-- 
2.25.1

Re: [PATCH] make test: Make failure results more verbose

[Max Nikulin]

A couple of additional remarks.

On 15/01/2022 19:52, Max Nikulin wrote:

On 02/01/2022 20:12, Ihor Radchenko wrote:


Subject: [PATCH] make test: Make failure results more verbose


At first it was not clear to me that only *summary* of test results is 
affected.


Should not the variable be named BTEST_ERT_VERBOSE_SUMMARY instead of 
just BTEST_ERT_VERBOSE due to this reason?



I am unsure if this line or local.mk has priority. I am unsure the the
following is better as well.
BTEST_ERT_VERBOSE ?= yes


I am not very familiar with Makefile conventions. Just followed the
existing settings in the same file. All other BTEST_ERT_* settings just
use "=".


I have found an example when "?=" is better. It is possible to export 
BTEST_ERT_VERBOSE from shell (or set in in the environment of continuous 
integration runner) and the value will not be overridden. Quick tests 
shell equivalent:


BTEST_ERT_VERBOSE= make test

currently it have to be written only as

make test-dirty BTEST_ERT_VERBOSE=

Re: [PATCH] make test: Make failure results more verbose

[Max Nikulin]

Ihor, I have tried your patch. My opinion is that you can go ahead and 
commit it as is. Reaction to my comments is optional.



Subject: [PATCH] make test: Make failure results more verbose


At first it was not clear to me that only *summary* of test results is 
affected.



+ifeq ($(BTEST_ERT_VERBOSE),yes)


I would consider (it should be a single line)

ifneq (,$(filter-out 0 n N no No NO f F false False 
FALSE,$(BTEST_ERT_VERBOSE)))


to allow more variants to enable verbose logging, e.g. "Y", "true" or 
"1". The idea is that only empty string "", 0, "n", "no", "f", "false" 
values should disable verbose summary.


On 11/01/2022 23:46, Max Nikulin wrote:

On 07/01/2022 22:04, Ihor Radchenko wrote:

Max Nikulin writes:

Also, we can adjust the ERT output using
ert-batch-backtrace-right-margin, ert-batch-print-level,
ert-batch-print-level, and ert-batch-backtrace-line-length


COLUMNS environment variable may be a sensible default when set. It 
seems, some of variables are quite recent addition to Emacs, so some 
care is required.


Maybe I am just not get used to such form of output, maybe I expect 
pretty print output instead of single form per line, maybe enough of 
call stack entries adds no value (e.g. pytest allows to suppress some 
frames from helper functions by defining special local variable and it 
cuts some outer frames by default). Actually some experience is required 
to quickly extract necessary information from backtrace. Even output of 
Python's pdb looks unfamiliar at first because gdb formats it in another 
way.


Thank you. After sending that message I realized that I did not try to 
load just ert.el from git to emacs version that I have installed.


It was more tricky than I expected. Latest ert is incompatible with 
Emacs-26. I am not motivated enough to build it from git, but compiling 
ert for 27 version generates no errors, just some warnings.



In my opinion, code of test should be written having clear error reports
in mind.



Do you have good ideas what could be changed?


Consider `test-org-element/bold-parser' with a typo. Current summary:

  FAILED  test-org-element/bold-parser  ((should (equal 
(org-element-contents (org-test-with-temp-text "*first line\nsecond 
line*" (org-element-map ... ... ... nil t))) '("first line\nSecond 
line"))) :form (equal (#("first line\nsecond line" 0 22 (:parent (bold 
... #3 ("first line\nSecond line")) :value nil :explanation 
(list-elt 0 (array-elt 11 (different-atoms (115 "#x73" "?s") (83 "#x53" 
"?S")


After some reorder

  (should
   (equal
'("Line 1\nline 2")
(org-test-with-temp-text "*Line 1\nline 2*"
  (org-element-contents
   (org-element-map (org-element-parse-buffer) 'bold #'identity nil 
t)


it becomes a bit easy to read since expected value and input are closer 
to beginning:


   FAILED  test-org-element/bold-parser  ((should (equal '("Line 
1\nline 2") (org-test-with-temp-text "*Line 1\nLine 2*" 
(org-element-contents (org-element-map ... ... ... nil t) :form 
(equal ("Line 1\nline 2") (#("Line 1\nLine 2" 0 13 (:parent (bold ... 
#3) :value nil :explanation (list-elt 0 (array-elt 7 
(different-atoms (108 "#x6c" "?l") (76 "#x4c" "?L")


Actually I am a bit surprised that `different-atoms' are shortened to 
"..." in long failure report but readable in summary.



Side note. In f0c474e659b81da0d2ab75e7ec109355965f7a1c I have noticed
"* H1\nP1\n* H2\n"


Unrelated to this patch, but still should be fixed.


I am unsure if this line or local.mk has priority. I am unsure the the
following is better as well.
BTEST_ERT_VERBOSE ?= yes


I am not very familiar with Makefile conventions. Just followed the
existing settings in the same file. All other BTEST_ERT_* settings just
use "=".


It was a false alarm, sorry for it. local.mk included after default.mk, 
so there is no problem to override value of BTEST_ERT_VERBOSE.



+    TMPDIR=$(testdir) EMACS_TEST_VERBOSE=yes $(BTEST)


A purist would say that it is not a directory, it is something like
...FLAGS or ...ARGS. I know, it was abused before your patch.


I do not follow you here.
VARIABLE1=1 VARIABLE2=2 /path/to/script
is the usual way to set variables in script environment in bash.


My bad. I did not noticed that it is a part of script of a rule. I 
believed that the whole line is assignment to TMPDIR variable. I am 
unsure if the following approach to avoid excessive ifeq's without 
modification of the rule is better:


ifeq ($(BTEST_ERT_VERBOSE),yes)
EMACS_TEST_VERBOSE=yes
export EMACS_TEST_VERBOSE
endif


With such approach the variable is exported for all targets, not only 
for testing ones, however it will not harm. The advantage of your 
variant is that value of the variable value may be found in logs, 
disadvantage is that makefile is a bit more obscure.



Shouldn't it be mentioned in testing/README?


Only BTEST_RE is documented there. BTEST_PRE, BTEST_POST,
BTEST_OB_LANGUAGES, and BTEST_EXTRA are not documented.
I believe that 

Re: Org Syntax Specification

[Sébastien Miquel]

Hi,

The new document seems much clearer. It makes a nice complement to the
manual and we should definitely lose the (draft). Thank you Timothy
for the work.

Lastly, having spent a while looking at the syntax, I’m wondering if 
we should take this opportunity to mark some of the syntactic elements 
we’ve become less happy with as *(depreciated)*. I’m specifically 
thinking of the TeX-style LaTeX fragments which have been a bit of a 
pain. To quote Nicolas in org-syntax.org:


It would introduce incompatibilities with previous Org versions,
but support for |$...$| (and for symmetry, |$$...$$|) constructs
ought to be removed.

They are slow to parse, fragile, redundant and imply false
positives. — ngz



This quote has been mentioned a few times lately, and no one has yet
spoken in favor of the $…$ syntax, so I'll have a quick go.

It is easier to use, easier to read and more commonly used (and known)
in tex documents (a quick web search for sample tex documents confirms
the latter). Removing this syntax would make org slightly harder to
pick up, with respect to writing scientific documents.

As for the listed shortcomings, I don't think we know whether its
slowness is significant and false positives can be avoided by using
the \dollar entity (possibly ?). In my own use, the only usability
issue I can think of is false negatives while writing : inserting a
space or other such characters at the end of a snippet removes the
fontification (I solve this by modifying the fontification regexps).

Regards,

--
Sébastien Miquel

Re: [BUG] ob-tangle overrides user customization of org-id-link-to-org-use-id [9.5.2 (9.5.2-gfbff08 @ /home/ionasal/.emacs.d/elpa/org-9.5.2/)]

[Ihor Radchenko]

Allen Li  writes:

> I see.  In my opinion those occurrences should be fixed even if no one
> is reporting issues because it is bad/improper code, and it is not
> especially surprising that no one has reported it yet; there is always a
> first person who reports a bug, and there are always more old bugs to be
> found in a big project like Emacs/Org mode.
>
> This is annoying to reproduce because it relies on the normal Emacs
> startup process, which loads packages.  Anyway, I have found a reproduction.
>
> ...
> 3. Press RET on the customize link.
>
> Note that the Customize UI says "CHANGED outside Customize."

I was also able to reproduce the problem following your steps. Thank you!

Unfortunately, fixing the occurrences of (defvar foo nil) is not
completely straightforward. Some of them are real defvars.

If someone is willing to check all the occurrences of
(defvar +[^ ]+ +nil) and remove nil values where we merely put a defvar
to silence byte-compiler, please do it.

Also, I feel that my Elisp-foo is not good enough in this specific
scenario. I invite others to reply if they feel that changing
(defvar foo nil) to (defvar foo) for externally defined variables is
_not_ universally safe.

Best,
Ihor

Re: [PATCH] org-attach-use-inheritance inherits from sibling

[Ihor Radchenko]

Ihor Radchenko  writes:

> Johan Tolö  writes:
>
>> If "* Top heading" is the first heading in the buffer with nothing 
>> above it, not even a whitespace/newline, then '(org-entry-get nil 
>> "id" t)' with point in "* Second heading" will return the id of 
>> "Top heading". If there is anything before "Top heading" then 
>> 'nil' will be returned.
>>
>> This happens when I run 'emacs -Q' from within the "lisp" 
>> directory of a newly cloned "org-mode" main branch.
>
> Ouch. Thanks for reporting!
>
> Confirmed
>
> The fix is attached.
>
> Dear all,
>
> I had to fix one of the tests, that apparently was only working because
> the bug existed. Please double check.

For record, this patch has been incorporated as parts of two other
patches.

Best,
Ihor

[PATCH] Add :noweb-prefix and :noweb-trans babel header arguments

[Sébastien Miquel]

Hi,

The attached patch adds support for two new babel header arguments:
=:noweb-prefix= and =:noweb-trans=.

=:noweb-prefix= can be set to =no= to disable the noweb prefix
behaviour, where prefix characters are repeated when expanding a
multiline noweb reference.

=:noweb-trans= can be set to =prin1-to-string= to insert a lisp string
representing the content of the referenced src block.

The goal is to allow one to use, say, a LaTeX src block to represent
some LaTeX snippet to be tangled into a string in some lisp (or other)
code. This isn't possible currently, and one has to manually string
escape the LaTeX code.

As an example, the following two blocks

#+BEGIN_SRC LaTeX :tangle no :noweb-ref nw
\usepackage{…}
\usepackage{…}
#+END_SRC

#+BEGIN_SRC emacs-lisp :noweb yes :tangle yes :noweb-prefix no 
:noweb-trans prin1-to-string

(setq latex-header <>)
#+END_SRC

would tangle to

#+BEGIN_SRC emacs-lisp
(setq latex-header "\\usepackage{…}
\\usepackage{…}")
#+END_SRC

I've left undocumented the possibility of setting =:noweb-trans= to
another function. I wonder if anyone can think of some other use.

Regards,

--
Sébastien Miquel
From 66f271225767d07e12bcc73a1ddbadf038d245fa Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= 
Date: Mon, 6 Sep 2021 18:45:42 +0200
Subject: [PATCH] ob-core.el: Add `:noweb-prefix`, `:noweb-trans` babel header
 arguments

* lisp/ob-core.el (org-babel-expand-noweb-references): Add support for
`noweb-prefix' header argument, to not repeat the prefix characters
when expanding a noweb reference. Add support for `noweb-trans' header
argument, to apply a function to the noweb content upon
expansion.
(org-babel-common-header-args-w-values):
(org-babel-safe-header-args): Add `noweb-prefix' and `noweb-trans' values.
* doc/org-manual.org: Document `noweb-prefix' and `noweb-trans' babel header
arguments.
* etc/NEWS: Document `:noweb-prefix' and `:noweb-trans'.
---
 doc/org-manual.org | 34 ++
 etc/ORG-NEWS   |  9 +
 lisp/ob-core.el| 26 --
 3 files changed, 59 insertions(+), 10 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index b4c20f252..d7b1c4203 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -18554,10 +18554,11 @@ Note that the expansion now contains the results of the code block
 : 100
 
 Noweb insertions honor prefix characters that appear before the noweb
-syntax reference.  This behavior is illustrated in the following
-example.  Because the =<>= noweb reference appears behind the
-SQL comment syntax, each line of the expanded noweb reference is
-commented.  With:
+syntax reference. This behavior can be turned off by setting the
+=noweb-prefix= header argument to =no= and is illustrated in the
+following example. Because the =<>= noweb reference appears
+behind the SQL comment syntax, each line of the expanded noweb
+reference is commented. With:
 
 #+begin_example
 ,#+NAME: example
@@ -18626,6 +18627,31 @@ else:
 print('do things when false')
 #+end_example
 
+The header argument =noweb-trans= can be set to =prin1-to-string= to
+insert a lisp string representing the content of the referenced src
+block. With:
+
+#+begin_example
+,#+NAME: latex-header
+,#+BEGIN_SRC latex
+  \usepackage{amsmath}
+,#+END_SRC
+#+end_example
+
+#+texinfo: @noindent
+this code block:
+
+#+begin_example
+,#+BEGIN_SRC elisp :noweb yes
+  (setq header <>)
+,#+END_SRC
+#+end_example
+
+#+texinfo: @noindent
+expands to:
+
+: (setq header "\\usepackage{amsmath}")
+
 When in doubt about the outcome of a source code block expansion, you
 can preview the results with the following command:
 
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 335db4139..6fa808645 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -63,6 +63,15 @@ list of various table options (between brackets in LaTeX export),
 since certain tabular environments, such as longtblr of the
 tabularray LaTeX package, provides this structure.
 
+*** New =:noweb-prefix= and =:noweb-trans= babel header arguments
+
+=:noweb-prefix= can be set to =no= to prevent the prefix characters
+from being repeated when expanding a multiline noweb reference.
+
+=:noweb-trans= can be set to =prin1-to-string=. Noweb reference
+therein will be expanded to an elisp string representation of their
+content.
+
 ** New functions and changes in function arguments
 
 *** New function ~org-element-cache-map~ for quick mapping across Org elements
diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index 239a57f96..1d5d1bedc 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -411,6 +411,8 @@ then run `org-babel-switch-to-session'."
 (noweb	. ((yes no tangle no-export strip-export)))
 (noweb-ref	. :any)
 (noweb-sep  . :any)
+(noweb-prefix . ((no yes)))
+(noweb-trans  . ((prin1-to-string)))
 (output-dir . :any)
 (padline	. ((yes no)))
 (post   . :any)
@@ -436,9 +438,10 @@ specific header arguments as well.")
 
 (defconst