Re: [PATCH] Prevent displayed images from being re-scaled

[Timothy]

Bastien  writes:

> Nitpick: I suggest shortening the ChangeLog part like this:
> *snip*
> The ChangeLog part should not be too verbose, you can add explanations
> after it.

Thanks Bastien, I’ll use that message when I push the commit .

All the best,
Timothy

Re: Worg footnotes

[Bastien]

Hi Thomas,

"Thomas S. Dye"  writes:

> Worg footnotes are oddly formatted for me.  

This should be fixed now.  

See https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-gnuplot.html

Thanks!

-- 
 Bastien

Re: [PATCH] Prevent displayed images from being re-scaled

[Bastien]

Hi Timothy,

Timothy  writes:

> From 9c34dd6aba62d734f6ae9aecaffa76a0250bf495 Mon Sep 17 00:00:00 2001
> From: TEC 
> Date: Wed, 29 Sep 2021 21:29:27 +0800
> Subject: [PATCH] org: Don't change image size based on font size
>
> * lisp/org.el (org--create-inline-image): When `create-image' is called
> without the :scale parameter, the image size is expanded based on the
> default font size (if it is larger than 10px).  When displaying images
> with a specified width in Org buffers, either in pixels or proportional
> to the text width, this width should not be modified according the to
> font size.  Giving a :scale parameter of 1 prevents this font-size based
> rescaling.

Nitpick: I suggest shortening the ChangeLog part like this:

  * lisp/org.el (org--create-inline-image): Set :scale parameter to 1 to
  prevent font-size based rescaling.
  
  When `create-image' is called without the :scale parameter, the image
  size is expanded based on the default font size (if it is larger than
  10px).  When displaying images with a specified width in Org buffers,
  either in pixels or proportional to the text width, this width should
  not be modified according the to font size.  Giving a :scale parameter
  of 1 prevents this font-size based rescaling.

The ChangeLog part should not be too verbose, you can add explanations
after it.

Thanks,

-- 
 Bastien

9.5: coping with loss of ditaa.jar

[Jarmo Hurri]

Greetings.

I use ditaa with org on a regular basis. Now that ditaa.jar is out of
org 9.5, I need to cope with the situtation.

I see two options, and neither was successful today. This is sort of
what I was afraid of when I voted for keeping ditaa bundled with org.

1. I am running Fedora 34, where ditaa is available as a
   package. However, just pointing org-ditaa-jar-path to the correct
   location /usr/share/java/ditaa.jar is not sufficient, because doing
   so leads to errors when trying to execute a ditaa babel block:

   Error: Unable to initialize main class 
org.stathissideris.ascii2image.core.CommandLineConverter
   Caused by: java.lang.NoClassDefFoundError: 
org/apache/commons/cli/ParseException

   Taking a look at what the system binary "ditaa" does, I found the
   following shell script:

   # -
   #!/usr/bin/bash
   #

   source /usr/share/java-utils/java-functions

   MAIN_CLASS=org.stathissideris.ascii2image.core.CommandLineConverter
   BASE_JARS="ditaa commons-cli xml-commons-apis batik"

   set_classpath $BASE_JARS

   run "$@"
   # -

   Has anyone successfully fed all these parameters to ob-ditaa?

2. Ditaa is available via github at
   https://github.com/stathissideris/ditaa

   The developer section points to building with some clojure build
   system lein, which is not available in my system, and in Fedora,
   running

   dnf list available '*lein*'

   gives me nothing useful.

   There are, however, ant build files available in ditaa repo under
   build. Then again, running ant with any parameters I could think of
   leads to the error

   BUILD FAILED
   /home/jarmo/src/ditaa/build/build.xml:6: The following error occurred while 
executing this line:
   /home/jarmo/src/ditaa/build/release.xml:67: /home/jarmo/src/ditaa/lib does 
not exist.

   Has anyone succesfully compiled ditaa for use with org?

Have fun and stay safe.

Jarmo

Re: [emacs-humanities] Elegant way to export org to Markdown ?

[Jean-Christophe Helary]

Better solution found: quit sr.ht and move to a gitea implementation.

No hassle, org files are fully recognized.

Jean-Christophe 

> On Oct 2, 2021, at 14:20, Jean-Christophe Helary  
> wrote:
> 
> I'm trying to work with SourceHut (sr.ht) and right now they only accept 
> Markdown syntax for their readme/wiki files.
> 
> Since I work in Emacs/org-mode to write my documents (and try to stick to 
> that), I'd like to know if there is an elegant way to export org syntax to 
> MarkDown.
> 
> I was thinking that the export-dispatch had an option for Plain Text / 
> Markdown, but that doesn't seem to be the case.
> 
> As a workaround, I thought I'd work on a README.org file that I export to 
> HTML, change the name to .md and edit the contents to reduce the markup to 
> the strict minimum... But when I saw the contents of the HTML, I thought that 
> would be way too much work.
> 
> *BUT* MarkDown bien basically HTML *without* the head/body tags, it seems to 
> me that the HTML export-dispatch thing could have a "super simplified MD 
> compatible" HTML option...
> 
> Either way, I need a method to export to something that sr.ht will recognize 
> and process as MD so:
> 
> 1) is there an external "approved" process to convert org-mode syntaxt to an 
> MD-compatible format ?
> 2) if no, what is the not too hard way to hack the HTML output to produce 
> what I need with export-dispatch ?
> 
> ---side note--
> And, Hello to Emacs-Humanities! I was away from the emacs-lists for a year 
> and when I came back I found that this amazing list was born. Last year I 
> started a "go-back-to-school" process that will eventually conclude with me 
> finishing an MA in Japanese studies, and I wrote my first 57 pages research 
> report last year with org-mode/Zotero/NeoOffice (a macOS only LibreOffice), 
> and that was fun. This year I work remotely as a part-time lecturer in 
> translation studies where I'll teach how to use free software in translation 
> (OmegaT/Opaki Framework/Maxprograms) and I wanted to write my teaching 
> material in org on sr.ht, but...
> 
> -- 
> Jean-Christophe Helary @brandelune
> https://mac4translators.blogspot.com
> https://sr.ht/~brandelune/omegat-as-a-book/
> 
> 

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

Re: Stable 9.5: invalid function (date date)

[Jarmo Hurri]

Ihor Radchenko  writes:

> Jarmo Hurri  writes:
>
>> Greetings.
>>
>> I just installed (stable) 9.5. from GNU ELPA, and tried to see what my
>> agenda for today looks like. The agenda is empty, and I got error
>>
>> Debugger entered--Lisp error: (invalid-function (date date))
>>
>> with backtrace
>>
>>   (date date)()
>>   org-agenda-get-day-entries("/home/jarmo/projects/gtd/faq.org" (10
>> 2 2021) :deadline :scheduled :timestamp :sexp)
>
> Looks like garbled installation.  Can you try to re-install Org?

Hello Ihor.

This morning the install instructions on orgmode.org had changed from
yesterday: they now pointed to the manual, which contains the text

Important: You need to do this in a session where no ‘.org’ file has
been visited, i.e., where no Org built-in function have been
loaded. Otherwise autoload Org functions will mess up the installation.

I reinstalled from "emacs -q", and my error disappeared. So thank you
very much.

Have fun and stay safe.

Jarmo

Fwd: [PATCH] ox-publish.el: Speed up org-publish-cache-file-needs-publishing

[Gustav Wikström]

FYI. It seems we fixed the same issue half a year apart by chance..!

Maybe if we had a forge or smth this would have been solved already by Emily's 
patch beginning 2021. One can always wish, right? ;-)

Best
Gustav


From: Bastien 
Sent: Monday, September 27, 2021 10:48 PM
To: Gustav Wikström
Subject: Re: [PATCH] ox-publish.el: Speed up 
org-publish-cache-file-needs-publishing

Gustav Wikström  writes:

> Aha, hmm... I don't remember commiting any other persons code. I
> honestly think it's just me fixing the same thing thing that
> apparently already had a patch without me knowing it!

I'm glad to read this :) - thanks, then!

--
 Bastien

Worg footnotes

[Thomas S. Dye]

Aloha all,

Worg footnotes are oddly formatted for me.  I see the footnote 
number on one line, then the footnote on the next line, like so:


1
Gnuplot manual downloads: 
http://www.gnuplot.info/documentation.html


Do others see this, as well?  Is there a fix?

All the best,
Tom
--
Thomas S. Dye
https://tsdye.online/tsdye

Re: Release 9.5

[Thomas S. Dye]

Max Nikulin  writes:


On 01/10/2021 10:53, Jarmo Hurri wrote:

Bastien writes:

I just ran 'git pull' and got a warning and an error:

warning: redirecting to 
https://git.savannah.gnu.org/git/emacs/org-mode.git/
Your configuration specifies to merge with the ref 
'refs/heads/maint'

from the remote, but no such ref was fetched.


Maybe you are trying to pull while you are on master branch from 
old orgmode.org

repository. You should either remove or rename old remote

git remote rm origin


I found these instructions (including the ones in the rest of the 
message) very helpful.  Thanks!


All the best,
Tom
--
Thomas S. Dye
https://tsdye.online/tsdye

Re: [PATCH] async process in R

[Jack Kamm]

I just noticed one more thing, regarding ess-eval-visibly etc:

>> + (setq user-inject-src-param ess-inject-source)
>>   (setq ess-eval-visibly nil)
>> + (setq  ess-inject-source 'function-and-buffer)
>>   (ess-eval-buffer nil))
>> - (setq ess-eval-visibly tmp)
>> +   (setq ess-eval-visibly tmp)
>> +   (setq ess-inject-source user-inject-src-param)
>
> Rather than using setq, it would be better to let bind these like so:
>
> (let ((ess-eval-visibly nil)
>   (ess-inject-source 'function-and-buffer))
>...code in here...
> )

I noticed these variables are only reset to defaults when ":results
output". It may also be necessary to set them as well for the case of
":results value". In my original implementation [1], I set
"ess-eval-visibly" within the wrapping advice function, so it applied to
all cases.

[1] 
https://github.com/jackkamm/ob-session-async/blob/master/lisp/ob-session-async-R.el

Re: [PATCH] async process in R

[Jack Kamm]

Hi Jeremie and Chuck,

>> But changing to `:async yes', the error aborts in a way that omits the 
>> output.
>
> Interesting, I haven't thought about errors cases enough. Async process
> will be on the 9.5 release and this issue will be next on the todo list.
> Many thanks again for the feedback.

I agree async eval should handle error outputs better. Errors are also
not handled well in ob-python's async eval at the moment. Certainly
something to improve in the future.

Best,
Jack

Re: [PATCH] async process in R

[Jack Kamm]

Hi Jeremie,

Many thanks for bringing this over the finish line! I'm very glad it
made it into Org 9.5.

All the tests passed on my end, and and I successfully ran a few async
R blocks without any issues.

I do have some suggestions for code style below. They apply to both the
original patch, as well as followup fixes that have been committed
since.

> +(defconst ob-session-async-R-indicator "'ob_comint_async_R_%s_%s'")
> +
> +(defun ob-session-async-org-babel-R-evaluate-session

For consistency with the rest of ob-R.el, as well as with the async
functions in ob-python, I suggest using a prefix of
"org-babel-R-async-". So
"ob-session-async-org-babel-R-evaluate-session" would become
"org-babel-R-async-evaluate-session", etc.

> +(ert-deftest ob-session-async-R-simple-session-async-value ()

Again, for consistency I suggest renaming the test functions so they are
prefixed with "test-ob-R/". For example,
"ob-session-async-R-simple-session-async-value" could become
"test-ob-R/async-session-simple-value". This would also allow easily
running all the R tests using "BTEST_RE='.*ob-R.*' make test".

> + (setq user-inject-src-param ess-inject-source)
>   (setq ess-eval-visibly nil)
> + (setq  ess-inject-source 'function-and-buffer)
>   (ess-eval-buffer nil))
> - (setq ess-eval-visibly tmp)
> +   (setq ess-eval-visibly tmp)
> +   (setq ess-inject-source user-inject-src-param)

Rather than using setq, it would be better to let bind these like so:

(let ((ess-eval-visibly nil)
  (ess-inject-source 'function-and-buffer))
   ...code in here...
)

This temporarily sets the variables within the let-block, then resets
them to their original values afterwards. Then you can also remove the
temporary variables "user-inject-src-param" and "ess-eval-visibly-tmp"
as well as their defvars at the top of the file.

Actually, since the code is already in a let-block, you can simply add
these variables to the existing let-statement.

> +   (list (format org-babel-R-write-object-command
> + (if row-names-p "TRUE" "FALSE")
> + (if column-names-p
> + (if row-names-p "NA" "TRUE")
> +   "FALSE")
> + ".Last.value"
> + (org-babel-process-file-name tmp-file 'noquote))

Some parts of ob-session-async-org-babel-R-evaluate-session, such as
the above, are duplicated from org-babel-R-evaluate-session; it would
be good to reduce duplication by abstracting these out to separate
functions.

Thanks again for porting this, and for taking care of ob-R.el in
general.

All the best,
Jack

Re: [PATCH] Prevent displayed images from being re-scaled

[Timothy]

Hi All,

I intend to push this in the next few days, assuming I don’t get any feedback.

All the best,
Timothy

Re: org-latex-preview and latex export blocks

[Timothy]

Tom Gillespie  writes:

> But surely #+begin_export latex works with org-latex-preview? If not then
> that would be a feature request to org-latex-preview yes?

It might be possible, but I don’t think you can generally expect #+begin_export
latex blocks to be either previewable in isolation, or something one would want
to preview.

This separation is also useful for packages like org-fragtog, which auto-toggles
equations[1] previews on cursor entry/exit.

Basically, LaTeX export blocks and maths are (in my view) two different things,
even if both use LaTeX syntax.

All the best,
Timothy



Footnotes
─

[1] `\( ... \) =, =\[ ... \]', and `\begin{*math} ... \end{*math}' bits

Re: [Question] A single *-language-alist in ox-latex.el?

[Juan Manuel Macías]

Hi Stefan,

Stefan Nobis writes:

> And, as far as I remember, babel development had nearly ceased during
> that period.
>
> Since quite some years, the development has gained much more traction
> for babel and, as far as I read, babel is today as good or superior to
> polyglossia in many regards (but polyglossia is also in quite a good
> shape today). See for example:
>
> https://tex.stackexchange.com/questions/482396/decide-between-polyglossia-and-babel-for-lualatex-in-2019
>
> In short: Babel is a very good choice in almost all cases, maybe
> except for right-to-left texts set with XeLaTeX.

Indeed, Javier Bezos (who is also the author of very popular packages
like enumitem or titlesec/titletoc) is doing a great job with Babel (you can
see the latest news here: https://latex3.github.io/babel/). And he has
added a lot of powerful features, such as babel replacements (with Lua code)
or the possibility to load languages via ini files and define new
languages with \babelprovide

I've been doing some testing, and I think this hypothetical new
unified list could support two types of members:

1. A member with 2 elements:

("lang-id" "lang-name"),

i.e.: ("it" "italian")

2. A member with 4 elements (for variants):

("lang-id" "babel-lang-name" "polyglossia-lang-name" "polyglossia-variant")

i.e.: ("la-classic" "classiclatin" "latin" "classic")

And then it would be necessary to make some minor modifications in
org-latex-guess-polyglossia-language and org-latex-guess-babel-language.

I will try to write a patch (or at least a proof of concept) in the next days 
...

Best regards,

Juan Manuel 


-- 
--
--
Juan Manuel Macías

https://juanmanuelmacias.com/

Re: [PATCH] Don't fill displayed equations

[Tom Gillespie]

Hi Timothy,

> │ \[
> │   not part of a paragraph
> │ \]

My point is that that parses first as a paragraph (check org-element-at-point).
\[ and \] would be meaningless if it did not first parse as a paragraph.

> I also don’t see how footnotes are analogous, as footnotes are placed in the
> middle of a line of text.

Inline footnotes [fn::
can span
multiple lines] but can't contain empty lines because the empty line ends the
paragraph that they are contained in.

> org-latex-preview :)

But surely #+begin_export latex works with org-latex-preview? If not then
that would be a feature request to org-latex-preview yes?

Best!
Tom

Re: [org-cite] Testing on macOS, XML file missing

[Kyle Meyer]

Kyle Meyer writes:

> Rudolf Adamkovič writes:
>
>> When I try to export HTML with APA/CSL citations (C-c C-e h o), 
>> Emacs says:
>>
>>> The default CSL locale file 
>>> /Users/salutis/src/emacs/nextstep/Emacs.app/Contents/Resources/lisp/org/etc/csl/locales-en-US.xml
>>>  
>>> doesn’t exist or is unreadable

This is hopefully resolved with bb209cd5ab (Update to Org
9.5-30-g10dc9d, 2021-10-02) in the Emacs repo.

Re: [PATCH] Don't fill displayed equations

[Timothy]

Hi Tom,

> The answer is that  can only occur inside paragraphs. The issues
> here are exactly the same as the issues for inline footnotes. Org gives
> us a bit more power, but not the full power because Org is Org, not
> Latex. Making  available outside of a paragraph would be a massive
> breaking change.
>
> In Timothy’s original example he is narrowly skirting the syntax to
> allow that all to remain a single paragraph, but stick in a newline
> anywhere and boom, no more paragraph, no more equation.

I don’t understand what you’re talking about here. You can already use `\[ ... 
\]'
outside a paragraph, e.g.

┌
│ blah blah blah
│ 
│ \[
│   not part of a paragraph
│ \]
│ 
│ blah blah blah
└

I also don’t see how footnotes are analogous, as footnotes are placed in the
middle of a line of text.

If you could explain your thoughts here a bit more, that would be appreciated.

> I guess one thing I’m missing/not understanding is when/why people
> want to use  instead of full #+begin_export latex block?

org-latex-preview :)

All the best,
Timothy

Re: [Worg] Proposing a few CSS changes

[Thomas S. Dye]

Eric S Fraga  writes:


Looks good (on both large monitor and on my phone).  Thank you!


+1

--
Thomas S. Dye
https://tsdye.online/tsdye

Re: Comments break up a paragraph when writing one-setence-per-line

[Tom Gillespie]

A general comment (heh) here. This is not a bug and not easily fixed.
Line comments are their own top level element distinct from
paragraphs. If you need something that fits in a paragraph you can use
@@comment:@@ at the start of a line.

I agree that it is annoying, but Org line comment syntax also only
works if it starts the line, so the behavior diverges from traditional
code comments. It may make sense to update the docs to call them "line
comments" instead of just comments.

One area where we could almost certainly do better is in how line
comments break up the flow of text. I'm not sure there will ultimately
be much we can do about it, but it is worth investigating.

Best,
Tom

Re: [PATCH] Don't fill displayed equations

[Tom Gillespie]

> do not see a reason for idiosyncrasy that markup intended to add LaTeX
> snippet that looks like exactly as LaTeX commands for this purpose and
> even actually preserved during export to LaTeX should have different
> semantics for Org parser.

The answer is that \[ \] can only occur inside paragraphs. The issues
here are exactly the same as the issues for inline footnotes. Org gives
us a bit more power, but not the full power because Org is Org, not
Latex. Making \[ \] available outside of a paragraph would be a massive
breaking change.

In Timothy's original example he is narrowly skirting the syntax to
allow that all to remain a single paragraph, but stick in a newline
anywhere and boom, no more paragraph, no more equation.

I guess one thing I'm missing/not understanding is when/why people
want to use \[ \] instead of full #+begin_export latex block?

Best,
Tom

Re: [PATCH] org-manual.org: Some correction of Installation section

[Bastien]

Ihor Radchenko  writes:

> Max Nikulin  writes:
>
>> - I am in doubts whether "emacs -Q -L ~/src/org-mode/lisp" way to try 
>> version from git is important enough for the manual.  I have added a 
>> separate patch however to discuss such change.
>
> I feel that it should not be in the manual. However, it may be helpful
> addition to https://orgmode.org/contribute.html

Yes, I reverted this commit.

-- 
 Bastien

Re: [PATCH] org-manual.org: Some correction of Installation section

[Bastien]

Hi Max,

Max Nikulin  writes:

> If you think that some patches improve the manual, feel free to apply
> ones that you like or to suggest better variants.

Applied, thanks a lot!

-- 
 Bastien

Re: [PATCH] org-attach: Fix checkdoc warnings

[Bastien]

No Wayman  writes:

> See attached.

Applied, thanks.

-- 
 Bastien

Re: [PATCH] Fix patching of single-page manuals

[Bastien]

Max Nikulin  writes:

> Currently the problem exists e.g. for "Plain Lists" section
> https://orgmode.org/manual/Plain-Lists.html - OK
> https://orgmode.org/org.html#Plain-Lists - bold items with no markers
>
> Output of makeinfo changed a bit, so a pattern in a helper script
> postprocessing HTML files is not suitable for currently generated
> files. CSS styles intended to tune table of contents are applied to
> all unordered lists.

Applied, thanks!

-- 
 Bastien

Re: Moving some lisp/ob-*.el files to org-contrib - your advice?

[Bastien Guerry]

Bastien  writes:

> Less code is less bug and less maintainance.  So I'm considering
> moving these files to the new (unmaintained) org-contrib repo at
> https://git.sr.ht/~bzg/org-contrib:

I'm now discarding this call for help on updates.orgmode.org.

-- 
 Bastien

How is the return value of `org-babel-execute:FOO` interpreted?

[Kodi Arfer]

I have an `org-babel-execute` function for the Hy programming language that 
seems to have partly broken when I upgraded Org (from 9.1.14 to 9.4.6). It has 
code to write a plot to a file when a `:file` argument is given to the code 
block. It returns `nil` in this case, and previously, Org would automatically 
insert a link to the file in the results block, as desired. Now, however, the 
`nil` is printed in the results block. So I guess have to edit the function to 
return a link instead, but I can't find documentation for how Org interprets 
the return value of an `org-babel-execute` function: as I vaguely recall, you 
have to use a certain cons structure to produce a table, another to produce a 
link, and so on. So the concrete question in this case is: what do I return to 
put a link in the document?

Here's my code in case it's helpful, but it isn't pretty: 
https://github.com/Kodiologist/Daylight/blob/37e38d216ffe41ad3537522c40ccf1cdb134bbbc/daylight.el#L430

[PATCH] Fix patching of single-page manuals

[Max Nikulin]

On 27/11/2020 23:32, Maxim Nikulin wrote:
Unordered lists are styled a bit incorrectly in the single-page org 
manual. Compare e.g. "Installation" section:


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

For some reason whole text of single-page manual is a part of table of 
contents (div.contents), so bold font and suppressed marker rules are 
applied for regular ul elements.


It is a minor issue. Maybe someone familiar with export settings for the 
manual could have a look and decide either CSS should be tweaked of main 
part of the manual should be pulled out of the TOC block.


Currently the problem exists e.g. for "Plain Lists" section
https://orgmode.org/manual/Plain-Lists.html - OK
https://orgmode.org/org.html#Plain-Lists - bold items with no markers

Output of makeinfo changed a bit, so a pattern in a helper script 
postprocessing HTML files is not suitable for currently generated files. 
CSS styles intended to tune table of contents are applied to all 
unordered lists.
>From 6c2e0872df94c7c970aebabafc4b809be446485a Mon Sep 17 00:00:00 2001
From: Max Nikulin 
Date: Sat, 2 Oct 2021 23:36:49 +0700
Subject: [PATCH 1/2] manfull.pl: Adjust pattern for current makeinfo

* mk/manfull.pl: During patching of single-page html manuals allow
current form of table of contents headers.

Older makeinfo did not add "contents-heading" class to "" element.
Helper script failed to properly modify HTML files generated by current
version of makeinfo.  With partially patched file, CSS stiles intended
for table of contents were applied to all unordered lists, so e.g. in
"Plain Lists" section items were bold and with missed markers.
---
 mk/manfull.pl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mk/manfull.pl b/mk/manfull.pl
index 95ffa392c..307ce396e 100755
--- a/mk/manfull.pl
+++ b/mk/manfull.pl
@@ -13,7 +13,7 @@ while () {
   } elsif (//) {
 print OUT;
 print OUT 'This is the official manual for the latest https://orgmode.org;>Org mode release.';
-  } elsif (/Table of Contents<\/h2>/) {
+  } elsif (/Table of Contents<\/h2>|/) {
 print OUT;
 print OUT 'https://orgmode.org;>https://orgmode.org';
 $toc = 1;
-- 
2.25.1

>From 78bc4d01e1cc2aeb8264166d734add7a2d5a1810 Mon Sep 17 00:00:00 2001
From: Max Nikulin 
Date: Sat, 2 Oct 2021 23:41:23 +0700
Subject: [PATCH 2/2] manfull.pl: Avoid silent failures

* mk/manfull.pl: Report failures of patching of single-page HTML
manuals.

It should prevent silent generating of manual pages inconsistent with
provided CSS files when output of makeinfo will change next time.
---
 mk/manfull.pl | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/mk/manfull.pl b/mk/manfull.pl
index 307ce396e..39439bd4b 100755
--- a/mk/manfull.pl
+++ b/mk/manfull.pl
@@ -1,11 +1,14 @@
 #!/usr/bin/perl
 
+$failures = 0;
 
 while ($page = shift) {
 system "mv $page $page.orig";
 open IN,"<$page.orig" or die "Cannot read from $page.orig\n";
 open OUT,">$page" or die "Cannot write to $page\n";
 
+$toc = undef;
+
 while () {
   if (//) {
 print OUT;
@@ -25,4 +28,11 @@ while () {
   }
 }
 system "rm $page.orig";
+
+if (!defined($toc) || $toc != 0) {
+  ++$failures;
+  print STDERR "Patching of $page failed\n";
 }
+}
+
+$failures == 0 or die "Patching of $failures files failed\n";
-- 
2.25.1

How is the return value of `org-babel-execute:FOO` interpreted?

[Kodi Arfer]

I have an `org-babel-execute` function for the Hy programming language that 
seems to have partly broken when I upgraded Org (from 9.1.14 to 9.4.6). It has 
code to write a plot to a file when a `:file` argument is given to the code 
block. It returns `nil` in this case, and previously, Org would automatically 
insert a link to the file in the results block, as desired. Now, however, the 
`nil` is printed in the results block. So I guess have to edit the function to 
return a link instead, but I can't find documentation for how Org interprets 
the return value of an `org-babel-execute` function: as I vaguely recall, you 
have to use a certain cons structure to produce a table, another to produce a 
link, and so on. So the concrete question in this case is: what do I return to 
put a link in the document?

Here's my code in case it's helpful, but it isn't pretty: 
https://github.com/Kodiologist/Daylight/blob/37e38d216ffe41ad3537522c40ccf1cdb134bbbc/daylight.el#L430

[PATCH] org-attach: Fix checkdoc warnings

[No Wayman]

See attached.

>From 477f05274d2de75fc6d4761e6e6089f46e024f4e Mon Sep 17 00:00:00 2001
From: Nicholas Vollmer 
Date: Thu, 30 Sep 2021 16:07:15 -0400
Subject: [PATCH] org-attach.el: Fix checkdoc warnings

* org-attach.el: Fix checkdoc warnings.
---
 lisp/org-attach.el | 41 +
 1 file changed, 21 insertions(+), 20 deletions(-)

diff --git a/lisp/org-attach.el b/lisp/org-attach.el
index 75db69c9c..e62432dca 100644
--- a/lisp/org-attach.el
+++ b/lisp/org-attach.el
@@ -123,8 +123,8 @@ lns   create a symbol link.  Note that this is not supported
 
 Enabling inheritance for `org-attach' implies two things.  First,
 that attachment links will look through all parent headings until
-it finds the linked attachment.  Second, that running org-attach
-inside a node without attachments will make org-attach operate on
+it finds the linked attachment.  Second, that running `org-attach'
+inside a node without attachments will make `org-attach' operate on
 the first parent heading it finds with an attachment.
 
 Selective means to respect the inheritance setting in
@@ -335,7 +335,7 @@ will be invoked to access the directory for the current entry.
 Note that this method returns the directory as declared by ID or
 DIR even if the directory doesn't exist in the filesystem.
 
-If CREATE-IF-NOT-EXIST-P is non-nil, `org-attach-dir-get-create'
+If CREATE-IF-NOT-EXISTS-P is non-nil, `org-attach-dir-get-create'
 is run.  If NO-FS-CHECK is non-nil, the function returns the path
 to the attachment even if it has not yet been initialized in the
 filesystem.
@@ -378,7 +378,7 @@ If the attachment by some reason cannot be created an error will be raised."
 	 ((or (eq org-attach-preferred-new-method 'dir) (eq answer ?2))
 	  (setq attach-dir (org-attach-set-directory)))
 	 ((eq org-attach-preferred-new-method 'nil)
-	  (error "No existing directory. DIR or ID property has to be explicitly created")
+	  (error "No existing directory.  DIR or ID property has to be explicitly created")
 (unless attach-dir
   (error "No attachment directory is associated with the current node"))
 (unless (file-directory-p attach-dir)
@@ -483,6 +483,7 @@ DIR-property exists (that is different from the unset one)."
   (org-attach-tag 'off))
 
 (defun org-attach-url (url)
+  "Attach URL."
   (interactive "MURL of the file to attach: \n")
   (let ((org-attach-method 'url))
 (org-attach-attach url)))
@@ -503,7 +504,7 @@ if it would overwrite an existing filename."
 
 (defun org-attach-attach (file  visit-dir method)
   "Move/copy/link FILE into the attachment directory of the current outline node.
-If VISIT-DIR is non-nil, visit the directory with dired.
+If VISIT-DIR is non-nil, visit the directory with `dired'.
 METHOD may be `cp', `mv', `ln', `lns' or `url' default taken from
 `org-attach-method'."
   (interactive
@@ -574,27 +575,27 @@ The attachment is created as an Emacs buffer."
 (find-file (expand-file-name file attach-dir))
 (message "New attachment %s" file)))
 
-(defun org-attach-delete-one ( file)
-  "Delete a single attachment."
+(defun org-attach-delete-one ( attachment)
+  "Delete a single ATTACHMENT."
   (interactive)
   (let* ((attach-dir (org-attach-dir))
 	 (files (org-attach-file-list attach-dir))
-	 (file (or file
+	 (attachment (or attachment
 		   (completing-read
 		"Delete attachment: "
 		(mapcar (lambda (f)
 			  (list (file-name-nondirectory f)))
 			files)
-(setq file (expand-file-name file attach-dir))
-(unless (file-exists-p file)
-  (error "No such attachment: %s" file))
-(delete-file file)
+(setq attachment (expand-file-name attachment attach-dir))
+(unless (file-exists-p attachment)
+  (error "No such attachment: %s" attachment))
+(delete-file attachment)
 (run-hook-with-args 'org-attach-after-change-hook attach-dir)))
 
 (defun org-attach-delete-all ( force)
   "Delete all attachments from the current outline node.
 This actually deletes the entire attachment directory.
-A safer way is to open the directory in dired and delete from there.
+A safer way is to open the directory in `dired' and delete from there.
 
 With prefix argument FORCE, directory will be recursively deleted
 with no prompts."
@@ -629,12 +630,12 @@ empty attachment directories."
  t))
   (delete-directory attach-dir))
 
-(defun org-attach-file-list (dir)
-  "Return a list of files in the attachment directory.
+(defun org-attach-file-list (directory)
+  "Return a list of files in the attachment DIRECTORY.
 This ignores files ending in \"~\"."
   (delq nil
 	(mapcar (lambda (x) (if (string-match "^\\.\\.?\\'" x) nil x))
-		(directory-files dir nil "[^~]\\'"
+		(directory-files directory nil "[^~]\\'"
 
 (defun org-attach-reveal ()
   "Show the attachment directory of the current outline node.
@@ -645,7 +646,7 @@ exist yet.  Respects `org-attach-preferred-new-method'."
   (org-open-file 

Re: Grabbing the link to a message on the archive

[Kyle Meyer]

Max Nikulin writes:

> On 02/10/2021 21:26, Ihor Radchenko wrote:
[...]
>> It can be parsed from the html.  Something like below (it is my
>> home-made parser, but I think the idea should be clear):
>> 
>> (org-capture-ref-set-bibtex-field :key (org-capture-ref-query-dom :tag 'form 
>> :tag 'input :attr '(name . "d") :attr 'value))
>
> Thank you, Ihor. I did not expect such funny form of obfuscation. Since 
> even author names are hidden in search results, I believed that 
> message-id should be considered even more confidential to put it into 
> page code.

Any obfuscation presented by https://lists.gnu.org is misleading.  Bots
don't have any issue getting addresses from that domain:

  curl -fSsL https://lists.gnu.org/archive/mbox/emacs-orgmode/2021-09

Re: [org-cite] Testing on macOS, XML file missing

[Kyle Meyer]

Bruce D'Arcus writes:

> Sorry; I wasn't clear.
>
> What I meant is that etc/styles was also not synced.

Right, some of the non-lisp files get moved around directory-wise
between the Org and Emacs repos.  Just in case it didn't stick out in
the snippets from my message upstream, the same files are there on both
sides:

  $ git -C org-mode ls-tree -r release_9.5:etc/styles
  100644 blob d0c98a3e51c079e74780d54289b09ba8ba52ac64  
OrgOdtContentTemplate.xml
  100644 blob 1a8edee99b4ccbbb18321091a7530afee660906a  OrgOdtStyles.xml
  100644 blob 07126fc31ba60103032e075e7cfdf81569e324c9  README

  $ git -C emacs show --no-patch --format="%s (%ch)" bf9ec3d91a
  Update to Org 9.5 (Wed Sep 29 23:21)

  $ git -C emacs ls-tree bf9ec3d91a:etc/org
  100644 blob d0c98a3e51c079e74780d54289b09ba8ba52ac64  
OrgOdtContentTemplate.xml
  100644 blob 1a8edee99b4ccbbb18321091a7530afee660906a  OrgOdtStyles.xml
  100644 blob 07126fc31ba60103032e075e7cfdf81569e324c9  README

Re: Grabbing the link to a message on the archive

[Max Nikulin]

On 02/10/2021 21:26, Ihor Radchenko wrote:

Max Nikulin writes:


Unfortunately I have no idea how to get Message-ID having a link to
particular message on lists.gnu.org without search by e.g. subject and
author.


It can be parsed from the html.  Something like below (it is my
home-made parser, but I think the idea should be clear):

(org-capture-ref-set-bibtex-field :key (org-capture-ref-query-dom :tag 'form :tag 'input 
:attr '(name . "d") :attr 'value))


Thank you, Ihor. I did not expect such funny form of obfuscation. Since 
even author names are hidden in search results, I believed that 
message-id should be considered even more confidential to put it into 
page code.

Re: [org-cite] Testing on macOS, XML file missing

[Kyle Meyer]

Bruce D'Arcus writes:

> On Sat, Oct 2, 2021 at 1:24 AM Kyle Meyer  wrote:
>
>> Is there a reason to avoid updating to the latest version?
>
> No; updating them makes sense.

All right, thanks.  I've updated these files to latest versions in
06ab36eb0.

Re: Inconsistent handling of multi-line properties

[Ihor Radchenko]

Hanno Perrey  writes:

> Hej,
>
> I have noticed that properties that stretch over multiple lines using 
> the :value+: syntax are ignored by org-element-property and therefore 
> also by e.g. org-export-get-node-property when exporting to ics via 
> ox-icalendar.el (see example below). I was wondering now whether this is 
> intentional and to be expected or a bug?

I proposed to change PROPERTY/PROPERTY+ handling in org-element (among
other things):
https://orgmode.org/list/87bl4p6n0m.fsf@localhost

However, that code still need some testing.

Best,
Ihor

Re: [BUG] [PATCH] org-src.el: Fix checkdoc warnings [9.5 (9.5-g59cb39 @ /home/n/.emacs.d/straight/build/org/)]

[Bastien]

No Wayman  writes:

> Bastien  writes:
>
>> Thanks -- it does not apply against the main branch, can you rebase
>> and resend it?
>
> Certainly. See attached.

Applied, thanks a lot!

-- 
 Bastien

Inconsistent handling of multi-line properties

[Hanno Perrey]

Hej,

I have noticed that properties that stretch over multiple lines using 
the :value+: syntax are ignored by org-element-property and therefore 
also by e.g. org-export-get-node-property when exporting to ics via 
ox-icalendar.el (see example below). I was wondering now whether this is 
intentional and to be expected or a bug?


* heading with multi-line property
:PROPERTIES:
:LOCATION: Someplace
:LOCATION+: Some Street 5
:LOCATION+: 12345 Small Town
:END:

#+begin_src emacs-lisp
(org-entry-get (point) "LOCATION")
#+end_src

#+RESULTS:
: Someplace Some Street 5 12345 Small Town


#+begin_src emacs-lisp
(save-excursion
  (goto-char (point-min))
  (org-element-property :LOCATION (org-element-at-point)))
#+end_src

#+RESULTS:
: Someplace

#+begin_src emacs-lisp
(save-excursion
  (goto-char (point-min))
  (org-element-property :LOCATION+ (org-element-at-point)))
#+end_src

#+RESULTS:
: 12345 Small Town


Thanks and cheers,

Hanno

Re: [BUG] [PATCH] org-src.el: Fix checkdoc warnings [9.5 (9.5-g59cb39 @ /home/n/.emacs.d/straight/build/org/)]

[No Wayman]

Bastien  writes:

Thanks -- it does not apply against the main branch, can you 
rebase

and resend it?


Certainly. See attached.

>From 4971ceb26a1fb138f4eeddc1a569b5c4dd3f1859 Mon Sep 17 00:00:00 2001
From: Nicholas Vollmer 
Date: Thu, 30 Sep 2021 16:07:15 -0400
Subject: [PATCH] org-src.el: Fix checkdoc warnings

* org-src.el: Fix checkdoc warnings.
---
 lisp/org-src.el | 22 ++
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/lisp/org-src.el b/lisp/org-src.el
index 8d02cf434..23e196438 100644
--- a/lisp/org-src.el
+++ b/lisp/org-src.el
@@ -37,6 +37,7 @@
 (require 'org-compat)
 (require 'org-keys)
 
+(declare-function org--get-expected-indentation "org" (element contentsp))
 (declare-function org-mode "org" ())
 (declare-function org--get-expected-indentation "org" (element contentsp))
 (declare-function org-element-at-point "org-element" ())
@@ -240,8 +241,7 @@ green, respectability.
   :package-version '(Org . "9.0"))
 
 (defcustom org-src-tab-acts-natively t
-  "If non-nil, the effect of TAB in a code block is as if it were
-issued in the language major mode buffer."
+  "If non-nil, TAB uses the language's major-mode binding in code blocks."
   :type 'boolean
   :package-version '(Org . "9.4")
   :group 'org-babel)
@@ -304,7 +304,8 @@ is 0.")
 (put 'org-src--preserve-blank-line 'permanent-local t)
 
 (defun org-src--construct-edit-buffer-name (org-buffer-name lang)
-  "Construct the buffer name for a source editing buffer."
+  "Construct the buffer name for a source editing buffer.
+Format is \"*Org Src ORG-BUFFER-NAME [ LANG ]*\"."
   (concat "*Org Src " org-buffer-name "[ " lang " ]*"))
 
 (defun org-src--edit-buffer (beg end)
@@ -614,7 +615,7 @@ Leave point in edit buffer."
 ;;; Fontification of source blocks
 
 (defun org-src-font-lock-fontify-block (lang start end)
-  "Fontify code block.
+  "Fontify code block between START and END using LANG's syntax.
 This function is called by Emacs' automatic fontification, as long
 as `org-src-fontify-natively' is non-nil."
   (let ((lang-mode (org-src-get-lang-mode lang)))
@@ -760,7 +761,9 @@ See also `org-src-mode-hook'."
 ;;; Babel related functions
 
 (defun org-src-associate-babel-session (info)
-  "Associate edit buffer with comint session."
+  "Associate edit buffer with comint session.
+INFO should be a list simlar in format to the return value of
+`org-babel-get-src-block-info'."
   (interactive)
   (let ((session (cdr (assq :session (nth 2 info)
 (and session (not (string= session "none"))
@@ -770,6 +773,7 @@ See also `org-src-mode-hook'."
(and (fboundp f) (funcall f session))
 
 (defun org-src-babel-configure-edit-buffer ()
+  "Configure src editing buffer."
   (when org-src--babel-info
 (org-src-associate-babel-session org-src--babel-info)))
 
@@ -842,6 +846,7 @@ Raise an error when current buffer is not a source editing buffer."
   org-src--source-type)
 
 (defun org-src-switch-to-buffer (buffer context)
+  "Switch to BUFFER considering CONTEXT and `org-src-window-setup'."
   (pcase org-src-window-setup
 (`plain
  (when (eq context 'exit) (quit-restore-window))
@@ -1204,11 +1209,12 @@ the area in the Org mode buffer."
   (interactive)
   (let (org-src--allow-write-back) (org-edit-src-exit)))
 
-(defun org-edit-src-continue (e)
+(defun org-edit-src-continue (event)
   "Unconditionally return to buffer editing area under point.
-Throw an error if there is no such buffer."
+Throw an error if there is no such buffer.
+EVENT is passed to `mouse-set-point'."
   (interactive "e")
-  (mouse-set-point e)
+  (mouse-set-point event)
   (let ((buf (get-char-property (point) 'edit-buffer)))
 (if buf (org-src-switch-to-buffer buf 'continue)
   (user-error "No sub-editing buffer for area at point"
-- 
2.33.0

Re: [BUG] [PATCH] org-src.el: Fix checkdoc warnings [9.5 (9.5-g59cb39 @ /home/n/.emacs.d/straight/build/org/)]

[Bastien]

Hi,

No Wayman  writes:

> Apologies. Resent.

Thanks -- it does not apply against the main branch, can you rebase
and resend it?

-- 
 Bastien

Re: Bug: org-map-entries calls file-exists-p when SCOPE is nil [9.4.4 (release_9.4.4 @ /usr/share/emacs/27.2/lisp/org/)]

[Ihor Radchenko]

Rodrigo Morales  writes:

> #+BEGIN_EXAMPLE
> Non-existent agenda file ~/foo.org.  [R]emove from list or [A]bort?
> #+END_EXAMPLE

Confirmed

Someone to help merging orgmode.org/contribute.html and orgmode.org/worg/org-contribute.html ?

[Bastien]

Hi all,

as the subject says: 

https://orgmode.org/contribute.html is very straightforward and
https://orgmode.org/worg/org-contribute.html is very complete.

I think we should merge both pages into worg/org-contribute.org,
the page that we recommand users to read in general.

The page would start with simple "calls to action" and progress
toward more informative sections.

It's a delicate balance to have -- but having two pages for the
same purpose isn't very good today.

Anyone?

-- 
 Bastien

Re: Grabbing the link to a message on the archive

[Ihor Radchenko]

Max Nikulin  writes:

> Unfortunately I have no idea how to get Message-ID having a link to 
> particular message on lists.gnu.org without search by e.g. subject and 
> author.

It can be parsed from the html.  Something like below (it is my
home-made parser, but I think the idea should be clear):

(org-capture-ref-set-bibtex-field :key (org-capture-ref-query-dom :tag 'form 
:tag 'input :attr '(name . "d") :attr 'value))


Best,
Ihor

Re: [PATCH] Don't fill displayed equations

[Max Nikulin]

On 02/10/2021 18:24, Eric S Fraga wrote:

On Saturday,  2 Oct 2021 at 18:18, Timothy wrote:

I can’t help but think that this line of thinking is a bit of a trap, because


I think you're right.  Nicolas's view that we should not think of org as
a front-end for LaTeX is probably more to the point.  As Stefan has
noted, how LaTeX processes \[...\] in the context of paragraphs is much
more complex (as it should be as typography is an incredibly difficult
task to do well, and TeX/LaTeX generally does it very well).  Trying to
have org mirror LaTeX in some way is doomed to fail.

I am happy with \[...\] being treated as an inline element.  That is
more sympathetic to LaTeX than the opposite.


\begin{equation}
  1 != 2
\end{equation}

does not start new paragraph in LaTeX and formats expression as a 
separate block in display math mode similar to \[ \]. However in Org 
\begin{equation} starts block element, so terminates preceding 
paragraph. At the same time Org export backend is transparent enough, so 
Org paragraphs separated by equation blocks may become parts of single 
paragraphs in LaTeX.


So formatting paragraphs properly by LaTeX does not depend whether \[ \] 
is treated as inline object or as block-level element in Org. I really 
do not see a reason for idiosyncrasy that markup intended to add LaTeX 
snippet that looks like exactly as LaTeX commands for this purpose and 
even actually preserved during export to LaTeX should have different 
semantics for Org parser. It is rather a source of confusion and nothing 
more.

Re: [BUG] [PATCH] org-src.el: Fix checkdoc warnings [9.5 (9.5-g59cb39 @ /home/n/.emacs.d/straight/build/org/)]

[No Wayman]

Bastien  writes:


Hi,

No Wayman  writes:


The attached patch


I don't see a patch, can you resend it?


Apologies. Resent.

>From e5d1c6cc231363e20b378e082236af44ac717ccc Mon Sep 17 00:00:00 2001
From: Nicholas Vollmer 
Date: Thu, 30 Sep 2021 16:07:15 -0400
Subject: [PATCH] org-src.el: Fix checkdoc warnings

* org-src.el: Fix checkdoc warnings.
---
 lisp/org-src.el | 22 ++
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/lisp/org-src.el b/lisp/org-src.el
index 0e16e236b..8f1e68d90 100644
--- a/lisp/org-src.el
+++ b/lisp/org-src.el
@@ -37,6 +37,7 @@
 (require 'org-compat)
 (require 'org-keys)
 
+(declare-function org--get-expected-indentation "org" (element contentsp))
 (declare-function org-mode "org" ())
 (declare-function org-element-at-point "org-element" ())
 (declare-function org-element-class "org-element" (datum  parent))
@@ -239,8 +240,7 @@ green, respectability.
   :package-version '(Org . "9.0"))
 
 (defcustom org-src-tab-acts-natively t
-  "If non-nil, the effect of TAB in a code block is as if it were
-issued in the language major mode buffer."
+  "If non-nil, TAB uses the language's major-mode binding in code blocks."
   :type 'boolean
   :package-version '(Org . "9.4")
   :group 'org-babel)
@@ -303,7 +303,8 @@ is 0.")
 (put 'org-src--preserve-blank-line 'permanent-local t)
 
 (defun org-src--construct-edit-buffer-name (org-buffer-name lang)
-  "Construct the buffer name for a source editing buffer."
+  "Construct the buffer name for a source editing buffer.
+Format is \"*Org Src ORG-BUFFER-NAME [ LANG ]*\"."
   (concat "*Org Src " org-buffer-name "[ " lang " ]*"))
 
 (defun org-src--edit-buffer (beg end)
@@ -613,7 +614,7 @@ Leave point in edit buffer."
 ;;; Fontification of source blocks
 
 (defun org-src-font-lock-fontify-block (lang start end)
-  "Fontify code block.
+  "Fontify code block between START and END using LANG's syntax.
 This function is called by Emacs' automatic fontification, as long
 as `org-src-fontify-natively' is non-nil."
   (let ((lang-mode (org-src-get-lang-mode lang)))
@@ -759,7 +760,9 @@ See also `org-src-mode-hook'."
 ;;; Babel related functions
 
 (defun org-src-associate-babel-session (info)
-  "Associate edit buffer with comint session."
+  "Associate edit buffer with comint session.
+INFO should be a list simlar in format to the return value of
+`org-babel-get-src-block-info'."
   (interactive)
   (let ((session (cdr (assq :session (nth 2 info)
 (and session (not (string= session "none"))
@@ -769,6 +772,7 @@ See also `org-src-mode-hook'."
(and (fboundp f) (funcall f session))
 
 (defun org-src-babel-configure-edit-buffer ()
+  "Configure src editing buffer."
   (when org-src--babel-info
 (org-src-associate-babel-session org-src--babel-info)))
 
@@ -841,6 +845,7 @@ Raise an error when current buffer is not a source editing buffer."
   org-src--source-type)
 
 (defun org-src-switch-to-buffer (buffer context)
+  "Switch to BUFFER considering CONTEXT and `org-src-window-setup'."
   (pcase org-src-window-setup
 (`plain
  (when (eq context 'exit) (quit-restore-window))
@@ -1203,11 +1208,12 @@ the area in the Org mode buffer."
   (interactive)
   (let (org-src--allow-write-back) (org-edit-src-exit)))
 
-(defun org-edit-src-continue (e)
+(defun org-edit-src-continue (event)
   "Unconditionally return to buffer editing area under point.
-Throw an error if there is no such buffer."
+Throw an error if there is no such buffer.
+EVENT is passed to `mouse-set-point'."
   (interactive "e")
-  (mouse-set-point e)
+  (mouse-set-point event)
   (let ((buf (get-char-property (point) 'edit-buffer)))
 (if buf (org-src-switch-to-buffer buf 'continue)
   (user-error "No sub-editing buffer for area at point"
-- 
2.33.0

Re: adding a header and/or footer when exporting to odt

[Christian Moe]

Uwe Brauer writes:

 "CM" == Christian Moe  writes:
>
>> Uwe Brauer writes:
>
>>> Hi
>>> 
>>> Is it possible to have a header and footer in all pages when
>>> exporting to odt? I presume I have to use a odt style I create with
>>> Libreoffice/Openoffice?
>>> 
>>> Thanks
>>> 
>>> Uwe Brauer
>
>> Yes, that's it. Just export your document, add the header you want (and
>> do whatever else you want to do with the style), save it as
>> "my-document-styles.odt" or whatever, and add the header
>
> Shouldn't that be my-documents-styles.ott ???

It could be, if you like, but it works just as well as .odt. Org just
needs to grab a styles.xml from somewhere.

Yours,
Christian

Re: Elegant way to export org to Markdown ?

[Jean-Christophe Helary]

> On Oct 2, 2021, at 21:18, Morgan Willcock  wrote:
> 
> Jean-Christophe Helary  writes:
> 
>> I'm trying to work with SourceHut (sr.ht) and right now they only accept 
>> Markdown syntax for their readme/wiki files.
> 
> Hi Jean-Christophe,
> 
> If this is just for SourceHut you can use an HTML export and upload it
> via the API instead of committing a Markdown based file.
> 
> https://man.sr.ht/git.sr.ht/#setting-a-custom-readme

Morgan,

Thank you for the pointer.

Actually, Noah and Drew suggested that on sr.ht, but I really have *no* idea 
what an API is, how I work with it, what is the graphql thing and all.

It looks like a super-powerful thing that smart people use, but it will 
probably take me quite some time before I can actually know where to start with 
all that info (I did check graphql tutorials but I was like: "ok, and where do 
I type all that?")...

Besides, org's md export works like a charm.

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

Re: [org-cite] Testing on macOS, XML file missing

[Bruce D'Arcus]

On Sat, Oct 2, 2021 at 1:46 AM Kyle Meyer  wrote:
>
> [reordering top-posting...]
>
> Bruce D'Arcus writes:
>
> > On Fri, Oct 1, 2021 at 8:33 AM Bruce D'Arcus  wrote:
> >>
> >> It looks like that /etc/csl directory isn't included in the emacs source 
> >> tree.
>
> > Actually, that whole etc directory is outdated.
>
> Aside from the new etc/csl/ directory that wasn't synced, could you be
> more specific about what you think is out of date between the Org repo
> and Emacs repo?

Sorry; I wasn't clear.

What I meant is that etc/styles was also not synced.

Bruce

Re: [org-cite] Testing on macOS, XML file missing

[Bruce D'Arcus]

On Sat, Oct 2, 2021 at 1:24 AM Kyle Meyer  wrote:

> Is there a reason to avoid updating to the latest version?

No; updating them makes sense.

Bruce

Re: Elegant way to export org to Markdown ?

[Morgan Willcock]

Jean-Christophe Helary  writes:

> I'm trying to work with SourceHut (sr.ht) and right now they only accept 
> Markdown syntax for their readme/wiki files.

Hi Jean-Christophe,

If this is just for SourceHut you can use an HTML export and upload it
via the API instead of committing a Markdown based file.

https://man.sr.ht/git.sr.ht/#setting-a-custom-readme

Regards,
Morgan

Re: [Worg] Proposing a few CSS changes

[Adam Porter]

Hi Timothy,

Timothy  writes:

> Great! I’ve just taken a peek and it’s a clear improvement in my eyes
> .

:)

>> Note that, after I made the other changes, the links scattered around
>> the page clashed very badly with the nice “Org green” and black theme,
>> so I adjusted them as well (as detailed in the commit message).  I tried
>> using “Org green” for the link text, but it seemed too low-contrast, as
>> well as a bit distracting while reading, so I opted to use colorize just
>> the underlines, and to make the link text green when hovering.
>
> I just had a look at this, and I tried a darkened green (#08402e). I think 
> this
> may be the best option.

That may be a good choice, yes.  But I almost feel like, with the
headers also being a very similar green, it's a bit of "green overload"
in some areas.  For example, this screenshot:


But in other places it does look nice, so I won't protest if you want to
make that change.  :)

>> Note as well that I ended up using 48em for the content width due to the
>> unicorn logo in the corner being covered up by wider content than that
>> (in a half-1080p-width browser window, which seems like an important use
>> case to consider).
>
> We should probably update the “angry unicorn” to the logo on the homepage,
> perhaps  or a 
> simplified
> version.

Well, personally, I don't mind having "the original" there.  :)  But I'll
leave that decision to you and others.

Thanks.

Re: [Worg] Proposing a few CSS changes

[Eric S Fraga]

Looks good (on both large monitor and on my phone).  Thank you!
-- 
: Eric S Fraga via Emacs 28.0.50, Org 9.5-g9a4a24
: Latest paper written in org: https://arxiv.org/abs/2106.05096

[Worg] New subdirectory not fully built?

[Adam Porter]

Hi,

I took the liberty of creating a new "archive" subdirectory in Worg to
preserve some obsolete content (like "Fireforg", an extension which its
Worg entry said hasn't been developed since 2009):

https://orgmode.org/worg/archive/index.html

The archive's index page is exported, but the linked "fireforg.org"
file, in the same directory, appears to not have been generated, as it
returns 404:

https://orgmode.org/worg/archive/fireforg.html

I checked other subdirectories' indexes and files, and I made the link
in the same way, so I don't know if I did something wrong, or if there's
something else going on.

Thanks,
Adam

Re: [Worg] Proposing a few CSS changes

[Timothy]

Hi Adam,

> Sure, I’ve just pushed these commits:

Great! I’ve just taken a peek and it’s a clear improvement in my eyes .

> Note that, after I made the other changes, the links scattered around
> the page clashed very badly with the nice “Org green” and black theme,
> so I adjusted them as well (as detailed in the commit message).  I tried
> using “Org green” for the link text, but it seemed too low-contrast, as
> well as a bit distracting while reading, so I opted to use colorize just
> the underlines, and to make the link text green when hovering.

I just had a look at this, and I tried a darkened green (#08402e). I think this
may be the best option.

> Note as well that I ended up using 48em for the content width due to the
> unicorn logo in the corner being covered up by wider content than that
> (in a half-1080p-width browser window, which seems like an important use
> case to consider).

We should probably update the “angry unicorn” to the logo on the homepage,
perhaps  or a simplified
version.

> And I left the H1 header black rather than green, because it didn’t seem
> to stand out enough as the page heading when it was also green.

The contrast looks good to me .

All the best,
Timothy

Re: [PATCH] Don't fill displayed equations

[Timothy]

Hi Nicolas,

> *snip lots of text*

Thanks for going through my points in detail. I think I understand your
perspective much better now. At this point though, I’m not really sure what to
make of `\[ ... \]', I now feel like it’s sitting in some sort of markup limbo
where it can’t be either fully LaTeX-y or fully Org-y. I still think it would be
good to improve this, but I no longer have such a firm idea that “modifying fill
is the way”.

All the best,
Timothy

Re: [PATCH] Don't fill displayed equations

[Eric S Fraga]

On Saturday,  2 Oct 2021 at 18:18, Timothy wrote:
> I can’t help but think that this line of thinking is a bit of a trap, because

I think you're right.  Nicolas's view that we should not think of org as
a front-end for LaTeX is probably more to the point.  As Stefan has
noted, how LaTeX processes \[...\] in the context of paragraphs is much
more complex (as it should be as typography is an incredibly difficult
task to do well, and TeX/LaTeX generally does it very well).  Trying to
have org mirror LaTeX in some way is doomed to fail.

I am happy with \[...\] being treated as an inline element.  That is
more sympathetic to LaTeX than the opposite.

-- 
: Eric S Fraga via Emacs 28.0.50, Org 9.5-g9a4a24
: Latest paper written in org: https://arxiv.org/abs/2106.05096

Re: [Question] A single *-language-alist in ox-latex.el?

[Stefan Nobis]

Juan Manuel Macías  writes:

> Well, if I'm not mistaken, the situation in the LaTeX ecosystem is
> this: Polyglossia appeared as a babel replacement for XelaTeX and
> LuaLaTeX, since babel, at that time, had no support for these two
> new Unicode based TeX engines.

And, as far as I remember, babel development had nearly ceased during
that period.

Since quite some years, the development has gained much more traction
for babel and, as far as I read, babel is today as good or superior to
polyglossia in many regards (but polyglossia is also in quite a good
shape today). See for example:

https://tex.stackexchange.com/questions/482396/decide-between-polyglossia-and-babel-for-lualatex-in-2019

In short: Babel is a very good choice in almost all cases, maybe
except for right-to-left texts set with XeLaTeX.

> But I think it does not make much sense to mantain in ox-latex.el
> two separate lists today. Maybe, for simplicity, it would be better
> to unify the two lists in a single db, something like
> `org-latex-language-alist'. What do you think?

+1

-- 
Until the next mail...,
Stefan.

Re: [PATCH] Don't fill displayed equations

[Nicolas Goaziou]

Hello,

Timothy  writes:

> Is it? I can't use verbatim like this:
>
> =
> some
> verbatim
> text
> =
>
> but I can do
>
> \[
> some
> display
> equation
> \]
>
> It seems to me that \[ ... \] is already treated differently from other
> inline markup.

There is some misunderstanding here. 

You cannot use verbatim like the above because its definition forbids
spaces on the inner side of the markers (for obvious reasons). There is
no such restriction in \[...\] markup. For citations, you can also write

  [@cite:
  @foo
  ]

if you like.

But this is orthogonal to the type of element, i.e., inline or block.

Inline means the object is always enclosed in a paragraph (or a verse
block, or possibly a table cell). In particular, it cannot get past the
boundaries of its container. Corollary: since a blank line in Org ends
a paragraph, objects cannot contain blank lines. Both verbatim objects
and \[...\] snippets share those limitations.

> If that's the only way that Org could treat \[ ... \] differently from
> \( ... \), I'd be strongly in favour of this.

I think it is not necessarily a bad thing that \(...\) and \[...\] are
the same. Some export back-ends can tell the difference between them,
others do not care. This is the same for, e.g., verbatim and code. Not
all back-ends use a different output for them. IOW, it is not
necessarily right to treat them differently just because some back-ends
do treat them differently. Org is simply agnostic to this subtleties.

> I prefer \[ ... \] over \begin{equation*}...\end{equation*} as it's much
> more succinct, and helps reduce the "markup noise" in my documents. 

This is all about taste. But at least you have a choice. With your
patch, I may have to struggle with filling whenever some paragraph
contains \[...\], without any choice.

Also, it could be possible to overlay "\[" over \begin{equation*} thus
negating the markup noise.

> I don't think this is an insignificant concern, brevity may not be
> something I'm very good at in emails  but is something I look for in
> syntax.

You probably have noticed that Org syntax is not very much into brevity.

> I must admit, I don't see the downside here --- how does this break the
> filling function for the rest of you? This only affects \[ ... \] blocks
> that have already been put on their own line.

No it doesn't. Without additional guards, filling a paragraph could
split a line and send an otherwise mid-line block at the beginning of
a line. But this is not the point. The point is much more basic,
actually. It is related to the uniformity of filling behaviour, as
already explained.

> Why can't we apply LaTeX expectations to LaTeX elements in Org? Applying
> LaTeX expectations to Org as a whole is clearly a silly idea, but Org
> copies \[ .. \] from LaTeX and it is a LaTeX construct.

Nope, it is obviously borrowed to LaTeX, but they are not the same.

I think I understand where you're coming from. Relying much on LaTeX,
you probably grew habits on how your equations should be formatted in
a LaTeX document. Applying this formatting in an Org document doesn't
work, tho, because Org has little understanding of true LaTeX syntax. It
just needs a way to quickly write maths.

  \[
  ... equation ...
  \]

should be seen as a LaTeXism.

>> Notwithstanding filling behaviour, \[...\] in Org is much more limited
>> than \[...\] in LaTeX.
>
> I'd be curious to hear how, as I personally haven't run into any
> instances where \[ ... \] has behaved differently other than when an
> environment starts on a new line in of a \[ ... \] block (which can
> easily be fixed by putting something like \!\ at the start of the
> line).

As explained above, for example, \[...\] cannot contain blank lines.
They cannot contain, e.g., "|" at the beginning of a line, too.
Full-fledged LaTeX environments do not have those limitations.

> I don't want "advanced" LaTeX code, I just want my display equations to
> be treated as display equations consistently .

It is a "display equation" in LaTeX. There is no such thing as
a "display equation" in Org, even though you probably see it as such due
to your LaTeX background. There, \[...\] is just another way to write
maths within a paragraph.

Regards,
-- 
Nicolas Goaziou

[Question] A single *-language-alist in ox-latex.el?

[Juan Manuel Macías]

Hi,

I have seen that `org-latex-polyglossia-language-alist' contains far
more languages than `org-latex-babel-language-alist'.

Well, if I'm not mistaken, the situation in the LaTeX ecosystem is this:
Polyglossia appeared as a babel replacement for XelaTeX and LuaLaTeX,
since babel, at that time, had no support for these two new Unicode
based TeX engines. I think those two separate lists in ox-latex.el
translate that situation. But the reality is different now: babel has
full support now for LuaTeX and XeTeX and supports more languages than
polyglossia (and also supports language variants. See
http://mirrors.ctan.org/macros/latex/required/babel/base/babel.pdf p.
20). In addition, babel is part of the LaTeX core and is, therefore,
better mantained.

Of course, anyone who wants to use polyglossia in their documents can
keep doing it without problems. But I think it does not make much sense
to mantain in ox-latex.el two separate lists today. Maybe, for
simplicity, it would be better to unify the two lists in a single db,
something like `org-latex-language-alist'. What do you think?

Best regards,

Juan Manuel

--
--
--
Juan Manuel Macías

https://juanmanuelmacias.com/

Re: Org syntax: \[ \] as block element instead of inline object

[Stefan Nobis]

Max Nikulin  writes:

> I like Timothy's idea that \[ \] markup should behave like
> block-level element rather than inline object.

On the other hand, we will loose the ability to inline small parts of
math, that should be typeset as separate equation, like:

...text \[ 1+2=3 \] more text...

I'm quite undecided in this regard. Personally, in almost all cases I
try to let my equations stand out even in the source (Org or LaTeX),
so I mostly use the "\begin{equation*}...\end{equation*}" variant.

At least, Nicolas convinced me, that comparing to LaTeX does not help
much (how LaTeX treats \[...\] is independent from how we want to
structure Org documents).

BTW: In LaTeX, I like to make equations stand out even further like
this:

--8<---cut here---start->8---
Some text
%
\begin{equation*}
...
\end{equation*}
%
more text
--8<---cut here---end--->8---

Is there a simple way to achieve this in Org (without using ugly
solutions like "@@latex:%@@" - something concise, at most 2-3 chars,
better only 1, but still visible in order to distinguish between
compound block belonging to a single paragraph and separate
paragraphs)?

-- 
Until the next mail...,
Stefan.

[PATCH] Bug: Indenting empty description list item leaves point at beginning of line [9.4.4]

[Ihor Radchenko]

Bodertz  writes:

> As you can see, point is at the beginning of the line.  I think it
> should be after the dash, as is the case when indenting plain list
> items.

The fix is attached.

Best,
Ihor

>From 63870bec28e59732cbbdf8b2534f6ece96e2d5d8 Mon Sep 17 00:00:00 2001
Message-Id: <63870bec28e59732cbbdf8b2534f6ece96e2d5d8.1633171544.git.yanta...@gmail.com>
From: Ihor Radchenko 
Date: Sat, 2 Oct 2021 18:32:34 +0800
Subject: [PATCH] org-list: Do not move point when promoting/demoting items

* lisp/org-list.el (org-list-struct-apply-struct): Make sure the
origin marker is not moved to bol when promoting/demoting item in
special case:
- item
-  ::

* testing/lisp/test-org-list.el (test-org-list/indent-item): Add test

Fixes https://orgmode.org/list/87o88hlkvv@gmail.com
---
 lisp/org-list.el  |  5 -
 testing/lisp/test-org-list.el | 10 +-
 2 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/lisp/org-list.el b/lisp/org-list.el
index 2bd9dc4d9..b6ab14f84 100644
--- a/lisp/org-list.el
+++ b/lisp/org-list.el
@@ -1866,7 +1866,10 @@ (defun org-list-struct-apply-struct (struct old-struct)
 	  (looking-at org-list-full-item-re)
 	  ;; a.  Replace bullet
 	  (unless (equal old-bul new-bul)
-		(replace-match new-bul nil nil nil 1))
+(save-excursion
+  (replace-match "" nil nil nil 1)
+  (goto-char (match-end 1))
+  (insert-before-markers new-bul)))
 	  ;; b.  Replace checkbox.
 	  (cond
 	   ((equal (match-string 3) new-box))
diff --git a/testing/lisp/test-org-list.el b/testing/lisp/test-org-list.el
index 3689a172f..e3d904b1e 100644
--- a/testing/lisp/test-org-list.el
+++ b/testing/lisp/test-org-list.el
@@ -298,7 +298,15 @@ (ert-deftest test-org-list/indent-item ()
 	(push-mark (point) t t)
 	(goto-char (point-max))
 	(let (org-list-demote-modify-bullet) (org-indent-item))
-	(buffer-string)
+	(buffer-string
+  ;; When point is right after empty item, do not move point.
+  (should
+   (= 13
+  (org-test-with-temp-text "
+- item
+-  ::"
+(org-indent-item)
+(point)
 
 (ert-deftest test-org-list/indent-item-tree ()
   "Test `org-indent-item-tree' specifications."
-- 
2.32.0

Re: [PATCH] Don't fill displayed equations

[Timothy]

Hi  Eric,

>> text
>> 1+1=3
>> text
>>
>> is a single paragraph in LaTeX.

> This is true and probably the most convincing argument in this debate.

I can’t help but think that this line of thinking is a bit of a trap, because
what LaTeX’s idea of a paragraph does not line up with Org’s. I think the more
pertinent consideration is that `\[ ... \]' changes LaTeX into vertical mode,
which does not allow for any other content on the ’line’ — which is far
closer to Org’s concept of a block element than an inline element.

Frankly, I think the issue is that the semantics of `\[ ... \]' simply don’t 
play
well with Org. Unfortunately, due to the Org/LaTeX difference I don’t see any
ideologically “pure” way we can have it in Org. The most idiomatic solution
would be to just remove support for `\[ ... \]' *. Otherwise, we have to treat
`\[ ... \]' specially in if we want ’sensible’ behaviour — as I mention in my
reply to Nicolas, we’re already parsing it differently to other inline markup…

All the best,
Timothy

* However, I am not advocating for this: There’s both the obvious comparability
  issue, but I also rather like using `\[ ... \]' myself.

Re: [orgweb] Making the git repo URL more visible

[Timothy]

Hi Adam,

> Sounds good to me.

Thanks :) it’s nice to get a second opinion.

All the best,
Timothy

Re: [orgweb] Making the git repo URL more visible

[Adam Porter]

Timothy  writes:

> I think a “Source Code” header could make sense, with a link to the cgit page,
> git clone line, and maybe a sentence or on Savannah for the unfamiliar. 
> Perhaps
> we could like to the org-contrib and website repos as well there?

Sounds good to me.

Re: Re : Re: Capture abort: Symbol’s function definition is void: turn-on-org-provide

[Ihor Radchenko]

Joseph Vidal-Rosset  writes:

> I got the following backtrace:

Err... This looks strange. Can you try re-installing Org? Or otherwise
go to org-capture.el, M-x eval-buffer, and try to get backtrace again
(hopefully, it can become more readable then).

Best,
Ihor

Re: [PATCH] Don't fill displayed equations

[Eric S Fraga]

On Friday,  1 Oct 2021 at 22:41, Nicolas Goaziou wrote:
> Yes: habit. Also, I don't think LaTeX treats it as a block element.
> E.g.,
>
> text
> \[1+1=3\]
> text
>
> is a single paragraph in LaTeX.

This is true and probably the most convincing argument in this debate.

I have no problem with the current parsing/interpretation in org even
though most of my writing in org treats it as a LaTeX front end...

Thank you,
eric
-- 
: Eric S Fraga via Emacs 28.0.50, Org 9.5-g9a4a24
: Latest paper written in org: https://arxiv.org/abs/2106.05096

Re: ox-bibtex incorrectly renders bibtex entries with slashes.

[Ihor Radchenko]

Vladimir Nikishkin  writes:

> Does anybody have a workaround for this?

Note that ox-bibtex is not a part of Org now.  Maybe you try using new
org-cite syntax instead? It should support HTML natively.

Best,
Ihor

Re: [PATCH] Don't fill displayed equations

[Stefan Nobis]

Nicolas Goaziou  writes:

> Also, I don't think LaTeX treats it as a block element.
> E.g.,
>
> text
> \[1+1=3\]
> text
>
> is a single paragraph in LaTeX.

Yes and no. LaTeX is a bit more complex and does not only see inline
or block elements. It has paragraph mode (and inner paragraph mode
like \parbox, which does not allow page breaks), vertical mode, LR
mode, math mode and within math mode there is inline math style
and display math style (and some more little details I forgot).

But still, the equation in the example is in display math style and it
is typeset as a separate line. Additionally, as far as I remember,
with processing "\]" LaTeX leaves math mode, typesets the necessary
vertical space, and switches back to paragraph mode. Then, if an empty
line (or the command "\par") is encountered, the marking of a new
paragraph is typeset (e.g. using "\parindent" and "\parskip"), else
normal output resumes.

Therefore, I would argue, LaTeX modes are not really comparable to Org
element types (inline or block).

See also the following LaTeX code:

--8<---cut here---start->8---
\documentclass{article}
\begin{document}
text\par text\\ and more text
\end{document}
--8<---cut here---end--->8---

Here, with an Org point of view, one may say, this is a single block
or paragraph. But LaTeX will typeset two paragraphs in three lines
(and internally stays the whole time in paragraph mode, if I correctly
remember the small fragments I once learned about the LaTeX kernel).

> If it's a block element, you cannot write \[...\] mid-line.

Hmm... so maybe, it's really worth to have both (\[...\] as inline
element and the \begin{equation*}...\end{equation*} block). I'm
undecided. :)

But thanks for your explanations!

-- 
Until the next mail...,
Stefan.

Re: Advice for new feature 'image block` for new `sketch-mode` package

[Ihor Radchenko]

dalanicolai  writes:

> As svg is just xml, for small sketches I would prefer to insert directly
> the xml
> into the org-buffer within an image block, in which I can quickly toggle
> showing
> the image using `C-c C-c` (or `org-toggle-inline-images`). Also, exporting
> such
> xml should work perfectly fine when exporting to e.g. html.

> I guess a normal source block is not suitable, because I would like to
> create
> the image overlay directly within the block. I am happy to (help)
> implement(ing)
> such a feature, but I thought it would be wise to first discuss and
> 'enquire'
> for suggestions here.

You can try to define a special block and add appropriate
org-ctrl-c-ctrl-c-hook to display the overlay.

For defining special blocks, you can try
https://github.com/alhassy/org-special-block-extras/

Hope it helps.

Best,
Ihor

Re: [PATCH] Re: New source block results option for attaching file to node

[Ryan Scott]

Would it be better then as a new option entirely that sets the default
directory to the attachment directory and results in attachment links for
any inserted paths that are under that?

The attachment link detection could possibly be default behavior for link
insertion, but i can imagine that might have broader implications.

I also found and have a fix for my patch where the 'attach symbol gets
converted to a string when using #+call to call a block that is defined
with this option, which felt a little awkward in the code.

I'll try this as a standalone option and see how that feels. That would
carve out space for other options in handling attachments.

On Sat, Oct 2, 2021, 01:31 Ihor Radchenko  wrote:

> Ryan Scott  writes:
>
> >(default-directory
> > -(or (and dir (file-name-as-directory dir)) default-directory))
> > +(or (and dir (if (eq dir 'attach)
> > +(org-attach-dir t)
> > +  (file-name-as-directory dir)))
> > +   default-directory))
>
> This does not always work.  Some ob-*.el code (namely, ob-lisp have the
> following:
>
> (let ((dir (if (assq :dir params)
>(cdr (assq :dir params))
>   default-directory)))
>
> As you can see, :dir parameter is overriding default-directory.  If :dir
> is set to symbol 'attach, execution will fail.
>
> I think that you also need to override :dir in the parameter list and
> put actual path to attachment dir instead of symbol.  That way, we will
> not need to change every possible ob-*.el implementation to account for
> new 'attach option.
>
> Also, marking this as patch.
>
> Best,
> Ihor
>

Re: Manually/programmatically adding a state transition message

[Ihor Radchenko]

Trevoke  writes:

> I've looked at the code around adding a log-note and it looks like it might
> be automatable but there's a lot of pieces I don't know in there, so if
> there's a way to add just a state transition with a programmatically
> provided note, I'll take that, please :)

It may be fragile, but you can try let-binding

(org-inhibit-logging 'note)

around elisp org-todo call

Best,
Ihor

Re: Elegant way to export org to Markdown ?

[Jean-Christophe Helary]

> On Oct 2, 2021, at 16:44, Tim Cross  wrote:
> 
> Jean-Christophe Helary  writes:
> 
>> I'm trying to work with SourceHut (sr.ht) and right now they only accept 
>> Markdown syntax for their readme/wiki files.
>> 
>> Since I work in Emacs/org-mode to write my documents (and try to stick to 
>> that),
>> I'd like to know if there is an elegant way to export org syntax to MarkDown.

> Org does have an exporter for markdown. You need to enable it (see the
> manual).

That's what I had missed. Thank you.

> Note that 'markdown' is a somewhat generic term - there is no 'standard'
> for markdown.

Well, there is John Gruber's original definition.

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

Re: [PATCH] Re: New source block results option for attaching file to node

[Ihor Radchenko]

Ryan Scott  writes:

>(default-directory
> -(or (and dir (file-name-as-directory dir)) default-directory))
> +(or (and dir (if (eq dir 'attach)
> +(org-attach-dir t)
> +  (file-name-as-directory dir)))
> +   default-directory))

This does not always work.  Some ob-*.el code (namely, ob-lisp have the
following:

(let ((dir (if (assq :dir params)
   (cdr (assq :dir params))
  default-directory)))

As you can see, :dir parameter is overriding default-directory.  If :dir
is set to symbol 'attach, execution will fail.

I think that you also need to override :dir in the parameter list and
put actual path to attachment dir instead of symbol.  That way, we will
not need to change every possible ob-*.el implementation to account for
new 'attach option.

Also, marking this as patch.

Best,
Ihor

Re: [Worg] Proposing a few CSS changes

[Timothy]

Hi Adam,

>From the last few messages in this thread, I think we’ve reached agreement on
the changes. Would you like to go ahead?

All the best,
Timothy

Org syntax: \[ \] as block element instead of inline object

[Max Nikulin]

I like Timothy's idea that \[ \] markup should behave like block-level 
element rather than inline object. On the other hand, Nicolas convinced 
me that the problem is not only with filling paragraphs in Emacs using 
M-q and it requires change of Org grammar. That is why I do not think 
that suggested patch should be applied.


Although Org has its own syntax, \[ \] constructs are added for LaTeX 
snippets, so unless there is a strong reason, such construct should not 
be a surprise for users familiar with LaTeX.


As it pointed out by Nicolas, the following is a compatibility issue 
with such change.


The following will be invalid Org structure, however the problem is 
hidden in the case of exporting to LaTeX:

A \[
  1 \ne 2,
\] B

It should be typed as

A
\[ 1 \ne 2, \]
B

or

A
\[
  1 \ne 2,
\]
B

On 02/10/2021 03:41, Nicolas Goaziou wrote:



I wonder, why it is not a block element. As far as I know, the only
difference (even in the context of Org) between \(...\) and \[...\]
is, that the former denotes inline math and the latter denotes a math
block. And at least exporting to HTML (with MathJax) and LaTeX results
in a block equation for \[...\].


That's not true. Only some export back-ends can tell the difference
between \(...\) and \[...\], so in the context of Org, they are the
same.


Is there a valid use case for that backends, so they should not consider 
\[ \] as a block-level element? Otherwise I would tell that it is a bug 
in that backend and in Org parser.



Do you have a short summary or a pointer why \[...\] has been choosen
to be an inline element?


Yes: habit. Also, I don't think LaTeX treats it as a block element.
E.g.,

 text
 \[1+1=3\]
 text

is a single paragraph in LaTeX.


It is a single LaTeX paragraphs assembled in vertical mode from parts 
created in horizontal or math mode. Splitting text into lines (in 
horizontal mode) is performed for each part of paragraph independently. 
So LaTeX paragraph is more like "greater element" than just "element". 
There is no of similar concept in HTML + CSS, there are blocks and 
inline parts. Formatting like paragraph indents and vertical spacing 
between paragraphs may be achieved with CSS rules.


Visually formatted paragraph may contain several block-level elements.

P.S. Examples of HTML vs. LaTeX paragraphs in Org export that were not 
intuitive for me:

https://list.orgmode.org/orgmode/sd9h2q$t9a$1...@ciao.gmane.io/T/#u

Re: [orgweb] Making the git repo URL more visible

[Timothy]

Hi Adam,

> Maybe this is moot, since Bastien already added the link to the home
> page, but anyway…
>
> On the Contribute page, I’d be in favor of having some kind of
> heading, like “Source Code,” and listing the git URL in text for easy
> copying (i.e. not hiding the URL behind a descriptive link).  It’d
> also be good to have a clickable link to view the repo on Savannah.
>
> Also, on that page, while I’m glad to have Bastien’s sponsorship links
> there, the “GitHub” link with the GitHub icon might be expected to be
> a link to the git source code, because that’s a common way to link to
> a git repo on other projects’ sites.  So it might be good to put them
> under a heading, like “Sponsor Development”.

I think a “Source Code” header could make sense, with a link to the cgit page,
git clone line, and maybe a sentence or on Savannah for the unfamiliar. Perhaps
we could like to the org-contrib and website repos as well there?

All the best,
Timothy

Re: [orgweb] Making the git repo URL more visible

[Adam Porter]

Hi Timothy,

On Fri, Oct 1, 2021 at 10:10 AM Timothy  wrote:
>
> Hi Adam,
>
> > Just now I found myself needing to look up the URL of the Org git repo,
> > and it seemed a bit harder than it ought to be.  It’d be nice if there
> > were a prominent “source code” link on the front page, but I remembered
> > that it was somewhere on the “Contribute” page, so I opened that.
>
> > When it loaded, I still overlooked the URL to the git repo.  I was
> > expecting to see some kind of “Source Code” header, or “git repo” link,
> > but instead the link is “The Org Codebase”, and it’s not under a header
> > or near any other text like “source code” or “git repo”, so it seems
> > easy to overlook:
>
> Thanks for bringing this up. I agree that it should be more prominent. My
> instinctual response is to change the text, add an icon, and bump the font 
> size
> up. Perhaps make it a /button link/ like “Tools that work with Org” on the
> homepage. I’d be tempted to put it on the homepage, but I’m also wary of
> clutter, and I’m hoping that the use of the common Git branch icon may clue 
> devs
> into thinking that the repository is linked/given on that page.
>
> Do you have any thoughts on that?

Maybe this is moot, since Bastien already added the link to the home
page, but anyway...

On the Contribute page, I'd be in favor of having some kind of
heading, like "Source Code," and listing the git URL in text for easy
copying (i.e. not hiding the URL behind a descriptive link).  It'd
also be good to have a clickable link to view the repo on Savannah.

Also, on that page, while I'm glad to have Bastien's sponsorship links
there, the "GitHub" link with the GitHub icon might be expected to be
a link to the git source code, because that's a common way to link to
a git repo on other projects' sites.  So it might be good to put them
under a heading, like "Sponsor Development".

Re: [orgweb] Making the git repo URL more visible

[Adam Porter]

Hi Bastien,

On Sat, Oct 2, 2021 at 12:03 AM Bastien  wrote:
>
> Hi Adam,
>
> Adam Porter  writes:
>
> > Other FOSS projects's sites seem to make their source code repo links
> > very prominent; could Org's web site do that too?  :)
>
> Done, let me know if it's good enough.
>
> I was missing this prominent link too!

Thanks, I think it's great having the git repo URL front-and-center on
the home page of FOSS projects.

Re: Elegant way to export org to Markdown ?

[Tim Cross]

Jean-Christophe Helary  writes:

> I'm trying to work with SourceHut (sr.ht) and right now they only accept 
> Markdown syntax for their readme/wiki files.
>
> Since I work in Emacs/org-mode to write my documents (and try to stick to 
> that),
> I'd like to know if there is an elegant way to export org syntax to MarkDown.
>
> I was thinking that the export-dispatch had an option for Plain Text / 
> Markdown, but that doesn't seem to be the case.
>
> As a workaround, I thought I'd work on a README.org file that I export to 
> HTML,
> change the name to .md and edit the contents to reduce the markup to the 
> strict
> minimum... But when I saw the contents of the HTML, I thought that would be 
> way
> too much work.
>
> *BUT* MarkDown bien basically HTML *without* the head/body tags, it seems to 
> me
> that the HTML export-dispatch thing could have a "super simplified MD
> compatible" HTML option...
>
> Either way, I need a method to export to something that sr.ht will recognize 
> and process as MD so:
>
> 1) is there an external "approved" process to convert org-mode syntaxt to an 
> MD-compatible format ?
> 2) if no, what is the not too hard way to hack the HTML output to produce 
> what I need with export-dispatch ?
>

Org does have an exporter for markdown. You need to enable it (see the
manual).

Note that 'markdown' is a somewhat generic term - there is no 'standard'
for markdown. This means that the markdown generated by org may not be
the same syntax as the markdown supported by sourceHut. A similar issue
exists with github and as a result, there is also an external package
which can add github flavoured markdown to org.

If sourceHut markdown is not the same as org's markdown or the github
flavored markdown, it may be necessary to write a sourceHut flavored
markdown exporter (probably fairly easy to do using the existing ox-md
as a starting point). 

Re: Elegant way to export org to Markdown ?

[Jean-Christophe Helary]

> On Oct 2, 2021, at 16:00, Ihor Radchenko  wrote:
> 
> Jean-Christophe Helary  writes:
> 
>> Next (related) question:
>> 
>> Why that ugly number in front of headers defined with  in HTML ?
> 
> I have little knowledge about HTML export... I blind guess is that you
> may disable org-export-with-section-numbers
> (see "14.1.5 Options for the exporters" section of the manual)

Thank you for the pointer.

> As for "ugly", it is probably subjective.

HTML does not require the addition of a number to indicate the heading level. 
The exported number is very much unexpected. Numbers (or ordering indicators) 
are expected in an  context, but nowhere else.

> Can you share a screenshot and
> suggest a concrete improvement?

Disable that by default.

> Also, are you on Org 9.5?

I'm on the latest update in a locally recently built emacs/master.

> I have seen some patches in that area lately.

Thank you for the information.

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

Re: Release 9.5

[Max Nikulin]

On 01/10/2021 10:53, Jarmo Hurri wrote:

Bastien writes:

I just ran 'git pull' and got a warning and an error:

warning: redirecting to https://git.savannah.gnu.org/git/emacs/org-mode.git/
Your configuration specifies to merge with the ref 'refs/heads/maint'
from the remote, but no such ref was fetched.


Maybe you are trying to pull while you are on master branch from old 
orgmode.org repository. You should either remove or rename old remote


git remote rm origin

or

git remote rename origin orgmode_org

and

git remote add origin 
https://git.savannah.gnu.org/git/emacs/org-mode.git

git fetch origin
git checkout main  # or bugfix

Even if you already added new repository earlier then maybe you are 
still on the master branch from old repository. Run "git fetch" with 
proper remote name and


git checkout main
git pull

(not "maint" that is "bugfix" now) should help. The commands that should 
help to determine current state of your repository


git remote -v show
git status -sb


Do I need to start a new clone from scratch, or is there a fix for this?


Git may works with several remotes, so it is not necessary.


(I honestly have _no recollection_ of what changes I have made, and what
changes need to be made, to the cloned repository locally in order for
'make' to run successfully.)


If you have a personal local branch, checkout it and rebase to "main" or 
"bugfix". If it is (or was) tracking remote changes, it may require 
adjustment.

Re: Stable 9.5: invalid function (date date)

[Ihor Radchenko]

Jarmo Hurri  writes:

> Greetings.
>
> I just installed (stable) 9.5. from GNU ELPA, and tried to see what my
> agenda for today looks like. The agenda is empty, and I got error
>
> Debugger entered--Lisp error: (invalid-function (date date))
>
> with backtrace
>
>   (date date)()
>   org-agenda-get-day-entries("/home/jarmo/projects/gtd/faq.org" (10 2 2021) 
> :deadline :scheduled :timestamp :sexp)

Looks like garbled installation.  Can you try to re-install Org?

Best,
Ihor

Re: Elegant way to export org to Markdown ?

[Ihor Radchenko]

Jean-Christophe Helary  writes:

> Next (related) question:
>
> Why that ugly number in front of headers defined with  in HTML ?

I have little knowledge about HTML export... I blind guess is that you
may disable org-export-with-section-numbers
(see "14.1.5 Options for the exporters" section of the manual)

As for "ugly", it is probably subjective. Can you share a screenshot and
suggest a concrete improvement?

Also, are you on Org 9.5? I have seen some patches in that area lately.

Best,
Ihor

Stable 9.5: invalid function (date date)

[Jarmo Hurri]

Greetings.

I just installed (stable) 9.5. from GNU ELPA, and tried to see what my
agenda for today looks like. The agenda is empty, and I got error

Debugger entered--Lisp error: (invalid-function (date date))

with backtrace

  (date date)()
  org-agenda-get-day-entries("/home/jarmo/projects/gtd/faq.org" (10 2 2021) 
:deadline :scheduled :timestamp :sexp)
  apply(org-agenda-get-day-entries "/home/jarmo/projects/gtd/faq.org" (10 2 
2021) (:deadline :scheduled :timestamp :sexp))
  org-agenda-list(nil)
  funcall-interactively(org-agenda-list nil)
  call-interactively(org-agenda-list)
  org-agenda(nil)
  funcall-interactively(org-agenda nil)
  call-interactively(org-agenda nil nil)
  command-execute(org-agenda)

Any ideas?

I am running

(emacs-version)
"GNU Emacs 27.2 (build 1, x86_64-redhat-linux-gnu, GTK+ Version 3.24.30, cairo 
version 1.17.4)
 of 2021-08-07"

in

Linux fedora 5.14.9-200.fc34.x86_64 #1 SMP Thu Sep 30 11:55:35 UTC 2021 x86_64 
x86_64 x86_64 GNU/Linux

Have fun and stay safe.

Jarmo

[PATCH] Bug: Unintended column added to table [9.4.6 (9.4.6-gab9f2a @ /home/user/.emacs.d/elpa/org-9.4.6/)]

[Ihor Radchenko]

Ihor Radchenko  writes:

> spect...@mail.com writes:
>
>> In a preexisting org table, hitting  can add a new, unintended column
>>
>> Bug: After the 2nd iteration, org adds a unintended new column. Further 
>> iteration adds more columns.
>
> Confirmed
>
> The problem appears somewhere inside org-table-justify-field-maybe

And here is the fix.

I am not familiar with org-table codebase, so feedback would be
appreciated.

Best,
Ihor

>From 36485b234d607be16cc06912dc85b9984a0142af Mon Sep 17 00:00:00 2001
Message-Id: <36485b234d607be16cc06912dc85b9984a0142af.1633157571.git.yanta...@gmail.com>
From: Ihor Radchenko 
Date: Sat, 2 Oct 2021 14:44:30 +0800
Subject: [PATCH] org-table.el: Do not create new field when at EOL after table
 line

* lisp/org-table.el (org-table-justify-field-maybe): Do not treat "|$"
as unclosed table field.

Fixes https://orgmode.org/list/trinity-2561db57-1561-470b-982f-0d91ddf4f145-1629900012884@3c-app-mailcom-lxa06
---
 lisp/org-table.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/org-table.el b/lisp/org-table.el
index 89c57fb06..e34872fb4 100644
--- a/lisp/org-table.el
+++ b/lisp/org-table.el
@@ -4436,7 +4436,7 @@ (defun org-table-justify-field-maybe ( new)
 	  (col (org-table-current-column)))
   (when (> col 0)
 	(skip-chars-backward "^|")
-	(if (not (looking-at " *\\([^|\n]*?\\) *\\(|\\|$\\)"))
+	(if (not (looking-at " *\\(?:\\([^|\n]*?\\) *\\(|\\)\\|\\([^|\n]+?\\) *\\($\\)\\)"))
 	(setq org-table-may-need-update t)
 	  (let* ((align (nth (1- col) org-table-last-alignment))
 		 (width (nth (1- col) org-table-last-column-widths))
-- 
2.32.0

Re: Elegant way to export org to Markdown ?

[Jean-Christophe Helary]

> On Oct 2, 2021, at 15:24, Ihor Radchenko  wrote:
> 
> Jean-Christophe Helary  writes:
> 
>> My follow-up question is, most of the ox-stuff seem to be installed by 
>> default, as far as I can tell. Why is ox-md not ?
> 
> Not most. The default export backends are:
> 
>> org-export-backends is a variable defined in org.el.
>> 
>> Value
>> (ascii html icalendar latex odt)
> 
> You can also customise this variable instead of direct (require 'ox-md)
> 
> Why not all backends are loaded? Mostly to reduce Org loading speed that
> some people complain about.

Also, I could have checked the manual... It was all there... Apologies for the 
noise.

Next (related) question:

Why that ugly number in front of headers defined with  in HTML ?


-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

Re: Elegant way to export org to Markdown ?

[Ihor Radchenko]

Jean-Christophe Helary  writes:

> My follow-up question is, most of the ox-stuff seem to be installed by 
> default, as far as I can tell. Why is ox-md not ?

Not most. The default export backends are:

> org-export-backends is a variable defined in org.el.
> 
> Value
> (ascii html icalendar latex odt)

You can also customise this variable instead of direct (require 'ox-md)

Why not all backends are loaded? Mostly to reduce Org loading speed that
some people complain about.

Best,
Ihor

Re: Elegant way to export org to Markdown ?

[Jean-Christophe Helary]

> On Oct 2, 2021, at 14:57, Protesilaos Stavrou  wrote:
> 
> On 2021-10-02, 14:20 +0900, Jean-Christophe Helary 
>  wrote:
> 
>> I'm trying to work with SourceHut (sr.ht) and right now they only
>> accept Markdown syntax for their readme/wiki files.
>> 
>> Since I work in Emacs/org-mode to write my documents (and try to stick
>> to that), I'd like to know if there is an elegant way to export org
>> syntax to MarkDown.
>> 
>> I was thinking that the export-dispatch had an option for Plain Text /
>> Markdown, but that doesn't seem to be the case.
> 
> Hello Jean-Christophe,
> 
> Have you tried the 'ox-md' which is part of Org?  Like this:
> 
>(require 'ox-md)
>(add-to-list 'org-export-backends 'md)
> 
> The export dispatched should then have an "Export to Markdown" option
> bound to 'm'.
> 
> There are more export backends as well.  If you do M-x find-library and
> search for "ox-" you will find more options.
> 
> All the best,
> Protesilaos (or simply "Prot")

Prot, Ihor,

Thank you *very much* for the pointers.

My follow-up question is, most of the ox-stuff seem to be installed by default, 
as far as I can tell. Why is ox-md not ?

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/