Re: [OT] org and diff

[Marcin Borkowski]

On 2022-12-28, at 03:30, Samuel Wales  wrote:

> hi marcin,
>
> thanks for your blog post on my crash-proof editing idea.

You're welcome! :-)  In fact, it was an interesting exercise.

>
> more below
>
> On 12/17/22, Marcin Borkowski  wrote:
>>
>> On 2022-12-17, at 03:06, Samuel Wales  wrote:
>>
>>> marcin> One question I'd ask is: how important a legible diff is to
>>> you?  I keep my Org files in Git, too, but if /I/ know what was
>>> changed, I just don't care about diff going nuts and I treat it as
>>> (more or less) Git's internal implementation detail.
>>>
>>> for org, i mostly use git for reviewing changes.  it is only one step
>>> more sophisticated than saving old and diffing.
>>>
>>> i have lots of tools for improving diff, but this intermingling
>
> [n.b. i have an still unpubolished package for 30 years that
> postprocesses diff and is extremely powerful, and it can if you are
> reviewing an ientire repo changes, to some degree nullify the
> intermingling issue, but its integration with magit, and magit's bugs
> with intra-hunk staging [2 bugs ime], make the intermingling an issue.
> with no bugs, less of an issue, mnerely because it is desirable to use
> magit instead of merely reviewing it and intra-hunk staging [and
> killing] is part of that.  but i use old magit, with --- +++, istead
> of new magit, which does not supply headers.  idk if new magit fixes
> the bugs.
>
> so really i was askig about the intermingling issue and whetehr it
> could be mitigated at the magit/git level.]
>
>> Well, "months of changes" seems tough.  I sometimes (rarely) have to
>> enter 2 days' worth of changes...  It requires discipline, but
>> discipline pays off in /so many areas of life/...
>
> not sure what you men to say in this case about discipline.  my
> circumstances if i told you about you'd be surprised.  my physical
> survival is very much at issue and i have no  support for dalin with
> it.
>
> i.e. not sure if this was aimed at me or a general comment, and the
> emphasis i wasn't sure what it was referring to.

General comment.  I meant that committing my changes (almost) every day
requires serious discipline, and I worked pretty hard to acquire it.
Also, I do not claim that everyone can learn it like me - people are
/very/ different...

OTOH, you might consider "outsourcing the discipline".  One way would be
to set up some kind of reminder to review/commit the changes every day.
(That's more or less what I did, though I used a heavy-weight type of
reminder: https://www.beeminder.com/ .)  Another could be to use some
tool to do the committing for you (see
e.g. https://stackoverflow.com/q/420143/1181665), though then you lose
the "review" part.  (Still, with tools like `git log --grep' and/or `git
blame' you might find that this is good enough.)

Hth,

-- 
Marcin Borkowski
http://mbork.pl

Re: [OT] org and diff

[Samuel Wales]

well well.  my habit of always hitting reply to all bit me.  it was
meant for the poster only, not for the list.  apologies.

it bites me once every 12 years or so.

list members please disregard the message.

Re: [OT] org and diff

[Samuel Wales]

hi marcin,

thanks for your blog post on my crash-proof editing idea.

more below

On 12/17/22, Marcin Borkowski  wrote:
>
> On 2022-12-17, at 03:06, Samuel Wales  wrote:
>
>> marcin> One question I'd ask is: how important a legible diff is to
>> you?  I keep my Org files in Git, too, but if /I/ know what was
>> changed, I just don't care about diff going nuts and I treat it as
>> (more or less) Git's internal implementation detail.
>>
>> for org, i mostly use git for reviewing changes.  it is only one step
>> more sophisticated than saving old and diffing.
>>
>> i have lots of tools for improving diff, but this intermingling

[n.b. i have an still unpubolished package for 30 years that
postprocesses diff and is extremely powerful, and it can if you are
reviewing an ientire repo changes, to some degree nullify the
intermingling issue, but its integration with magit, and magit's bugs
with intra-hunk staging [2 bugs ime], make the intermingling an issue.
with no bugs, less of an issue, mnerely because it is desirable to use
magit instead of merely reviewing it and intra-hunk staging [and
killing] is part of that.  but i use old magit, with --- +++, istead
of new magit, which does not supply headers.  idk if new magit fixes
the bugs.

so really i was askig about the intermingling issue and whetehr it
could be mitigated at the magit/git level.]

> Well, "months of changes" seems tough.  I sometimes (rarely) have to
> enter 2 days' worth of changes...  It requires discipline, but
> discipline pays off in /so many areas of life/...

not sure what you men to say in this case about discipline.  my
circumstances if i told you about you'd be surprised.  my physical
survival is very much at issue and i have no  support for dalin with
it.

i.e. not sure if this was aimed at me or a general comment, and the
emphasis i wasn't sure what it was referring to.

>
>> days as normal.  i find reviewing changes to be valuable.  every once
>> in a while i discover data corruption or something that i forgot etc.
>
> Yes, same here.
>
>> i wonder if diff, or difftastic, could be taught or postprocessed to
>> do merely one thing: try to preserve stuff between "^\\*+ ".  that is
>> probably too optimistic, but imagine a --preserve-between option.
>
> I afraid so.  Difftastic does not support Org mode format.  However, the

huh.  so it's a hard problem [i.e. parser needed rather than merely
kluydging with entries].  :[

> tree-sitter page claims that Org parser is under way, so there's hope
> (AFAIK difftastic uses tree-sitter under the hood).

great.

>
> Best,
> mbork
>
> --
> Marcin Borkowski
> http://mbork.pl
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: [PATCH] oc-csl: Improve LaTeX bibliography formatting

[András Simonyi]

Dear All,
I have attached a new version of the patch with added ascii "illustrations".
best wishes,
András

On Tue, 13 Dec 2022 at 20:03, András Simonyi  wrote:
>
> Dear All,
>
> On Tue, 13 Dec 2022 at 17:07, Timothy  wrote:
>
> > Perhaps an ASCII approximation in an example block could work? Even if it’s
> > exaggerated to give the idea.
>
> yes, I'm also thinking of first trying to produce something in ASCII
> as the docstring will probably need it anyway,
> and we can think about the image version afterwards -- it might turn
> out that the text version is already sufficient for the news (and
> maybe later on for the manual).
>
> best wishes,
> András
>
> > All the best,
> > Timothy
> >
> > --
> > Timothy (‘tecosaur’/‘TEC’), Org mode contributor.
> > Learn more about Org mode at .
> > Support Org development at ,
> > or support my work at .
From 2bdbb02901b9831f3bb6b3d29ff8050eadd69e46 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Andr=C3=A1s=20Simonyi?= 
Date: Tue, 27 Dec 2022 23:15:34 +0100
Subject: [PATCH] oc-csl: Improve LaTeX bibliography formatting

* lisp/oc-csl.el (org-cite-csl--output-format): Use the dedicated
'org-latex' citeproc formatter to export references in LaTeX.
(org-cite-csl-latex-preamble, org-cite-csl--generate-latex-preamble,
org-cite-csl-finalizer): Insert a preamble fragment compatible with
the 'org-latex' citeproc formatter.
(org-cite-csl-latex-label-separator,
org-cite-csl-latex-label-width-per-char): Introduce additional
variables to control bibliography formatting.

* etc/ORG-NEWS: Describe the introduced new options.
---
 etc/ORG-NEWS   |  27 +
 lisp/oc-csl.el | 145 +++--
 2 files changed, 155 insertions(+), 17 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index d4e9b4368..1185a51b2 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -13,6 +13,33 @@ Please send Org bug reports to mailto:emacs-orgmode@gnu.org.
 
 * Version 9.7 (not released yet)
 ** New options
+*** New custom settings for the "csl" citation export processor's LaTeX output
+
+The settings ~org-cite-csl-latex-label-separator~ and
+~org-cite-csl-latex-label-width-per-char~ allow the user to control
+the indentation of entries for labeled bibliography styles when the
+"csl" citation processor is used for LaTeX export.  The indentation
+length is computed as the sum of ~org-cite-csl-latex-label-separator~
+and the maximal label width, for example:
+
+#+begin_example
+indentation length
+<->
+max. label width  separator
+<---><>
+[Doe22]John Doe. A title...
+[DoeSmithJones19]  John Doe, Jane Smith and...
+[SmithDoe02]   Jane Smith and John Doe...
+#+end_example
+
+The maximal label width, in turn, is calculated as the product of
+~org-cite-csl-latex-label-width-per-char~ and the maximal label length
+measured in characters.
+
+The setting ~org-cite-csl-latex-preamble~ makes it possible to
+customize the entire LaTeX fragment that the "csl" citation processor injects
+into the preamble.
+
 *** New ~org-latex-listings-src-omit-language~ customization for LaTeX export
 
 The ~org-latex-listings-src-omit-language~ customization variable
diff --git a/lisp/oc-csl.el b/lisp/oc-csl.el
index 1ccb74e92..11194b9b4 100644
--- a/lisp/oc-csl.el
+++ b/lisp/oc-csl.el
@@ -214,6 +214,111 @@ Used only when `second-field-align' is activated by the used CSL style."
   :type 'string
   :safe #'stringp)
 
+(defcustom org-cite-csl-latex-label-separator "0.6em"
+  "Distance between citation label and bibliography item for LaTeX
+output in valid LaTeX units.  Used only when `second-field-align'
+is activated by the used CSL style.
+
+The indentation length in these cases is computed as the sum of
+`org-cite-csl-latex-label-separator' and the maximal label width,
+for example,
+
+indentation length
+<->
+max. label width  separator
+<---><>
+[Doe22]John Doe. A title...
+[DoeSmithJones19]  John Doe, Jane Smith and...
+[SmithDoe02]   Jane Smith and John Doe...
+
+The maximal label width, in turn, is calculated as the product of
+`org-cite-csl-latex-label-width-per-char' and the maximal label
+length measured in characters."
+  :group 'org-cite
+  :package-version '(Org . "9.7")
+  :type 'string
+  :safe #'stringp)
+
+(defcustom org-cite-csl-latex-label-width-per-char "0.45em"
+  "Character width in LaTeX units for calculating entry label widths.
+Used only when `second-field-align' is activated by the used CSL
+style.
+
+See the documentation of `org-cite-csl-latex-label-separator' for
+details."
+  :group 'org-cite
+  :package-version '(Org . "9.7")
+  :type 'string
+  :safe #'stringp)
+
+;; The following was inspired by and in many details follows how
+;; Pandoc's () default LaTeX template
+;; handles CSL 

Re: ob-shell intentions and paperwork (was Bash results broken?)

[Matt]

  On Wed, 21 Dec 2022 01:17:50 -0500  Matt  wrote --- 

 > Currently, though, I'm refactoring the ob-shell tests to remove dependency 
 > on ob-shell-test.org and to stop the suite from littering. 

Done.  Branched off bugfix, 12e10eb0d, and refactored test-ob-shell.el.  See 
attached patches.

The main changes spanning the patches are:

- tests are now standalone; they don't rely on ob-shell-test.org
- tests now share a common prefix, "test-ob-shell".  The entire suite runs with 
(ert "test-ob-shell")
- buffers and processes created during a test are killed when the test passes

 >  After that, I intend to incorporate the worg examples as tests.

This is probably a good place for me to pause and get feedback before writing 
more code. 

I just got the signed paperwork back from Craig and am waiting to be admitted 
to the Emacs group on Savannah.

0001-test-ob-shell.el-Remove-mixed-tabs-and-spaces.patch
Description: Binary data


0002-test-ob-shell.el-Split-cases-into-two-tests.patch
Description: Binary data


0003-test-ob-shell.el-Refactor-test-ob-shell-session.patch
Description: Binary data


0004-test-ob-shell.el-Refactor-ob-shell-generic-uses-no-a.patch
Description: Binary data


0005-test-ob-shell.el-Refactor-ob-shell-bash-uses-arrays.patch
Description: Binary data


0006-test-ob-shell.el-Refactor-ob-shell-generic-uses-no-a.patch
Description: Binary data


0007-test-ob-shell.el-Refactor-ob-shell-bash-uses-assoc-a.patch
Description: Binary data


0008-test-ob-shell.el-Refactor-ob-shell-simple-list.patch
Description: Binary data


0009-test-ob-shell.el-Refactor-ob-shell-remote-with-stdin.patch
Description: Binary data


0010-test-ob-shell.el-Refactor-ob-shell-results-table.patch
Description: Binary data


0011-test-ob-shell.el-Refactor-ob-shell-results-list.patch
Description: Binary data


0012-test-ob-shell.el-Refactor-ob-shell-standard-output-a.patch
Description: Binary data


0013-test-ob-shell.el-Refactor-ob-shell-standard-output-a.patch
Description: Binary data


0014-test-ob-shell.el-Refactor-ob-shell-error-output-afte.patch
Description: Binary data


0015-test-ob-shell.el-Refactor-ob-shell-error-output-afte.patch
Description: Binary data


0016-test-ob-shell.el-Refactor-ob-shell-error-output-afte.patch
Description: Binary data


0017-test-ob-shell.el-Refactor-ob-shell-exit-code.patch
Description: Binary data


0018-test-ob-shell.el-Refactor-ob-shell-exit-code-multipl.patch
Description: Binary data


0019-ob-shell-test.org-Remove-ob-shell-test.org.patch
Description: Binary data


0020-test-ob-shell.el-Organize-tests.patch
Description: Binary data

Re: Problem with multi-occur search when restricted to region

[Alain . Cochard]

Ihor Radchenko writes on Tue 27 Dec 2022 13:43:

 > Can you try the attached patch?

It did not work with the version I initially used:

   release_9.6-149-g554935.dirty

but it works OK with

   release_9.6-149-g554935


Thanks





-- 
EOST (École et Observatoire des Sciences de la Terre) 
ITE (Institut Terre & Environnement) | alain.coch...@unistra.fr
5 rue René Descartes   [bureau 110]  | Phone: +33 (0)3 68 85 50 44 
F-67084 Strasbourg Cedex, France | [ slot available for rent ]

[Bug] isearch errors when org-fold-core-style is 'overlays

[Matt Lundin]

I'm finding that isearch fails to unfold the correct region or to search
in the correct region when there are folded regions in a buffer and
`org-fold-core-style` is set to 'overlays.

Here is a minimal recipe for reproducing the bug:

Use a minimal emacs startup file:

--8<---cut here---start->8---
(add-to-list 'load-path "~/org-mode/lisp/")
(setq org-startup-folded t)
(setq org-fold-core-style 'overlays)
--8<---cut here---end--->8---

Open the following file:

--8<---cut here---start->8---
* One
word
* Two
word
--8<---cut here---end--->8---

Issue #1:

Go to the beginning of headline "Two" when the trees are folded.

Type "M-x isearch word [RET]".

Expected behavior: isearch should reveal the entry under headline two
and shift the highlighted region dynamically as the characters typed
begin to match.

What happens: the beginning of the highlighted region remains stuck at
the beginning of the headline and the entry does not unfold until after
the return key is pressed.

Issue #2:

Cycle headlines to folded state. Go to the beginning of headline "Two".

Type "M-x isearch word [RET]".

Note that during this second search dynamically highlighted region
expands to include the folded headline "One". Once return is pressed,
isearch reveals the entry under headline "One" and moves the point to
the "word" there. 

After running git bisect, I traced the issue to commit
6cd7c6fb1cf6363f1057086760bed9875cdd97c7

Thanks,

Matt

Re: [FR] Present list of errors in separate buffer when running org-export, similar to what org-lint does (was: [Syntax discussion] Should we treat src blocks without LANG as paragraphs?)

[Tim Cross]

Ihor Radchenko  writes:

> As Max proposed, it may be a good idea to extend the concept of org-lint
> to export.
>
> We may unify the LaTeX errors, some errors/warnings potentially signalled
> by export backend, and maybe some warnings from org-lint during the
> export process. These errors can ideally be displayed just like in
> org-lint, with ability to jump to the problematic LoCs in
> Org/intermediate file.
>
> This is a medium task and one will need to:
> 1. Generalize org-lint interactive interface (list of errors) to work
>with other code. Extract it into a separate library.
> 2. Accumulate export issues into a list to be displayed. For example,
>broken links can be displayed
> 3. Make functions like `org-latex-compile' accumulate LaTeX errors as
>well. (Optionally) associate LaTeX buffer lines with Org source.
> 4. Display the list of errors/warnings at the end of successful or
>failed export.
>
> Each step if fairly simple, except optional part in 3.
> Patches welcome!
>

Anything which provides additional information to assist the user in
identifying issues in their document is a plus in my view. 

Re: [FR] Please add writing to existing heading in org-bibtex

[Ihor Radchenko]

Sterling Hooten  writes:

> The default behavior of org-bibtex-write is to insert a new
> heading with the bibliographic data in the properties. But an
> alternative workflow would just update the properties of the heading at
> point, rather than creating a new one. The below patch is a simple
> implementation I’ve been using for a month. Would it be possible to
> integrate this upstream?

Yes. It will make sense.

> -(defun org-bibtex-write ()
> -  "Insert a heading built from the first element of `org-bibtex-entries'."
> +(defun org-bibtex-write ( no-new)
> +  "Insert a heading built from the first element of `org-bibtex-entries'. 
> With non-nil optional NO-NEW write to heading at point instead of creating 
> new."

Please put the second sentence on a separate line. By convention, first
line is a short description of the command and should not exceed 80
symbols. See
https://www.gnu.org/software/emacs/manual/html_node/elisp/Documentation-Tips.html

Also, it will be a good idea to write heading at point when the command
is called with prefix argument (C-u).

> +  ;; SWH 2022-11-22 changes to allow for writing heading at point instead of 
> inserting new.

Please prepare a proper patch with CHANGELOG entry.
This comment is not how we make changes in Org.
See https://orgmode.org/worg/org-contribute.html#first-patch

>(interactive)

You can change the interactive form to allow prefix argument.
See 
https://www.gnu.org/software/emacs/manual/html_node/elisp/Using-Interactive.html

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

Re: Bug? org-assert-version does not prevent mixed install

[Max Nikulin]

On 18/12/2022 21:26, Ihor Radchenko wrote:

Max Nikulin writes:


We might do something like

(eval-and-compile (org-assert-version))


This will give obscure error during compiling since `org-assert-version'
is not defined.


Yes, but we will at least abort the compilation this way.


You are right that it prevents creation of .elc files. Unfortunately 
`byte-recompile-directory' converts failure into a message instead of 
aborting package install completely.


When used consistently, it should cause load of Org completely 
uncompiled during next Emacs session. It is better than having 
incorrectly compiled files.


Notice that `org-assert-version' works for compiled files only, so if a 
user loads some third-party package (hyperbole?) that loads built-in Org 
and later adds new Org to `load-path' then we get an obscure error again.


Currently I am experimenting with minimal examples, not with full Org 
package, so I may confuse something.



;; Remove when support of Emacs-29 is dropped.
(unless (fboundp 'org-assert-version)
(error "Org is compiled or loaded while older version loaded already.
   Please, ensure that no other org versions are loaded and recompile."))


Another idea to have more concise code in each file is to put a new 
macro to a *new* file to avoid the issue with old org-macs.el without 
definition of the new macro `org-assert-version'. So each file should 
contain


(require 'org-assert-version-undefined)
(org-assert-version-undefined)

`org-assert-version' remains in org-macs.el. The goal is to generate an 
instructive error. The problem is that after fix in 
org-assert-version-undefined.el, an old version will be active for some 
users.


In addition I have noticed that e.g. org-matlab.el contains

 (require 'org-macs)
 (org-assert-version)

Shouldn't it be (eval-when-compile (require 'org-macs)) since no 
functions are used from this file? Some files have duplicated (require 
'org-macs).

Re: Expand macros in links

[Ihor Radchenko]

Michael Dauer  writes:

> Agree. How do you run such feature polls?

Change subject to something like

  [FR] [POLL] Allow expanding macros in link path like 
[[https://site-{{{macro}}}.com]]

Then see how many people reply.

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

[FR] Please add writing to existing heading in org-bibtex

[Sterling Hooten]

The default behavior of org-bibtex-write is to insert a new
heading with the bibliographic data in the properties. But an
alternative workflow would just update the properties of the heading at
point, rather than creating a new one. The below patch is a simple
implementation I’ve been using for a month. Would it be possible to
integrate this upstream?

Thanks,
Sterling

diff --git a/lisp/ol-bibtex.el b/lisp/ol-bibtex.el
index 81b99167b..38198eae4 100644
--- a/lisp/ol-bibtex.el
+++ b/lisp/ol-bibtex.el
@@ -703,8 +703,9 @@ Return the number of saved entries."
   (interactive "fFile: ")
   (org-bibtex-read-buffer (find-file-noselect file 'nowarn 'rawfile)))
 
-(defun org-bibtex-write ()
-  "Insert a heading built from the first element of `org-bibtex-entries'."
+(defun org-bibtex-write ( no-new)
+  "Insert a heading built from the first element of `org-bibtex-entries'. With 
non-nil optional NO-NEW write to heading at point instead of creating new."
+  ;; SWH 2022-11-22 changes to allow for writing heading at point instead of 
inserting new.
   (interactive)
   (when (= (length org-bibtex-entries) 0)
 (error "No entries in `org-bibtex-entries'"))
@@ -712,8 +713,9 @@ Return the number of saved entries."
 (org-special-properties nil) ; avoids errors with `org-entry-put'
 (val (lambda (field) (cdr (assoc field entry
 (togtag (lambda (tag) (org-toggle-tag tag 'on
-(org-insert-heading)
-(insert (funcall org-bibtex-headline-format-function entry))
+(unless no-new
+  (org-insert-heading)
+  (insert (funcall org-bibtex-headline-format-function entry)))
 (org-bibtex-put "TITLE" (funcall val :title))
 (org-bibtex-put org-bibtex-type-property-name
(downcase (funcall val :type)))

Re: Expand macros in links

[Michael Dauer]

Agree. How do you run such feature polls?

Ihor Radchenko  schrieb am Di., 27. Dez. 2022, 17:20:

> Michael Dauer  writes:
>
> > I'm aware of this theoretical conflict. But I see the risk as very low
> > compared to the value of not having to make a lot of customizations for
> > export and internal link handling. It should just work out of the box.
>
> Even low risk does not justify impossible-to-use links when such problem
> occurs.
>
> > If you deem necessary there would still be the possibility to define a
> > global switch for this. This could then still have the 100% save default,
> > while still being easy to "configure".
>
> > If you want to go so far you could mitigate the risk of a conflict by
> > "escaping" the macro brackets. {{not-a-macro}} would be treated
> as
> > {{{not-a-marco}}} without expansion. Or any other escape sequence to
> bring
> > the conflict probability to 0.001.
>
> This is all indeed possible. The main question if whether it is
> justified to introduce all these complexities given the provided
> alternatives.
>
> Basically, we need more votes in favour to consider such feature.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>

Re: Expand macros in links

[Ihor Radchenko]

Michael Dauer  writes:

> I'm aware of this theoretical conflict. But I see the risk as very low
> compared to the value of not having to make a lot of customizations for
> export and internal link handling. It should just work out of the box.

Even low risk does not justify impossible-to-use links when such problem
occurs.

> If you deem necessary there would still be the possibility to define a
> global switch for this. This could then still have the 100% save default,
> while still being easy to "configure".

> If you want to go so far you could mitigate the risk of a conflict by
> "escaping" the macro brackets. {{not-a-macro}} would be treated as
> {{{not-a-marco}}} without expansion. Or any other escape sequence to bring
> the conflict probability to 0.001.

This is all indeed possible. The main question if whether it is
justified to introduce all these complexities given the provided
alternatives.

Basically, we need more votes in favour to consider such feature.

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

Re: Expand macros in links

[Michael Dauer]

I'm aware of this theoretical conflict. But I see the risk as very low
compared to the value of not having to make a lot of customizations for
export and internal link handling. It should just work out of the box.

If you deem necessary there would still be the possibility to define a
global switch for this. This could then still have the 100% save default,
while still being easy to "configure".

If you want to go so far you could mitigate the risk of a conflict by
"escaping" the macro brackets. {{not-a-macro}} would be treated as
{{{not-a-marco}}} without expansion. Or any other escape sequence to bring
the conflict probability to 0.001.

Am Di., 27. Dez. 2022 um 16:51 Uhr schrieb Ihor Radchenko <
yanta...@posteo.net>:

> Michael Dauer  writes:
>
> > I mean something like:
> > * Heading
> > [[http:abc{{{input-file}}}]
> >
> > When exporting it to html then the link is not replaced.
>
> This is to be expected, and I do think that Org is doing it right by not
> replacing macros in links.
>
> You cannot exactly control what is inside link path - if an actual
> website link happens to contain {{{...}}} pattern, you will have no
> options left how to prevent Org from replacing that pattern.
>
> If you want to generate link paths programmatically, you can instead
> define custom links types or link abbreviations. See
> https://orgmode.org/manual/Link-Abbreviations.html and
> https://orgmode.org/manual/Adding-Hyperlink-Types.html
>
> You can control custom link export as well.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>

Re: Expand macros in links

[Ihor Radchenko]

Michael Dauer  writes:

> I mean something like:
> * Heading
> [[http:abc{{{input-file}}}]
>
> When exporting it to html then the link is not replaced.

This is to be expected, and I do think that Org is doing it right by not
replacing macros in links.

You cannot exactly control what is inside link path - if an actual
website link happens to contain {{{...}}} pattern, you will have no
options left how to prevent Org from replacing that pattern.

If you want to generate link paths programmatically, you can instead
define custom links types or link abbreviations. See
https://orgmode.org/manual/Link-Abbreviations.html and
https://orgmode.org/manual/Adding-Hyperlink-Types.html

You can control custom link export as well.

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

Re: Expand macros in links

[Michael Dauer]

I mean something like:
* Heading
[[http:abc{{{input-file}}}]

When exporting it to html then the link is not replaced.

I'm talking about expansion when exporting.

But I also implemented macro expansion for following links within emacs
quite a while ago. Different story but also very powerful especially for
action links and deep links into other applications.


Am Di., 27. Dez. 2022 um 16:30 Uhr schrieb Ihor Radchenko <
yanta...@posteo.net>:

> Michael Dauer  writes:
>
> > I do not understand why links are excluded from macro expansion. I would
> > see it as very valuable to have macros for links too.
>
> Are they? Could you please provide an example?
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>

Re: Expand macros in links

[Ihor Radchenko]

Michael Dauer  writes:

> I do not understand why links are excluded from macro expansion. I would
> see it as very valuable to have macros for links too.

Are they? Could you please provide an example?

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

Expand macros in links

[Michael Dauer]

Hi,

I do not understand why links are excluded from macro expansion. I would
see it as very valuable to have macros for links too.

The change would be as simple as inserting
(eq type 'link)
into org-macro-replace-all.

May I recommend this patch.

Thanks,
Michael

Re: copying text from links makes it with a starting [[

[Max Nikulin]

On 27/12/2022 20:06, Luca Ferrari wrote:

I'm not sure this is an org problem, rather a clipboard problem or
what else, but when I select an org link in Emacs and I copy into my
Firefox browser, the link has always a starting pair of square
brackets (e.g. [[https://...).


Selecting link to copy it to an external application or even to a 
non-org buffer has another problem. Some links may contain square 
brackets. Org needs to escape them (and backslash character as well). To 
reliably copy a link, it is necessary to define a dedicated command what 
unescapes URL. Alternatively you may copy URL using C-c C-l 
(`org-insert-link') and abort the command after that.


Besides copy, another action is open URL (C-c C-o) and it should handle 
unescaping properly. Depending on your environment, you may need to 
configure the browse-url package to use the preferred browser.

Re: [PATCH] lisp/ob-octave.el, was [PATCH] rfc: using ert-deftest with side-effects

[Ihor Radchenko]

Leo Butler  writes:

>> Note that the tests are failing only partially. The graphics file does
>> get created, but it has 0 size for some reason. Maybe something to do
>> with non-graphical CI environment.
>
> There is a race condition between writing the contents of the graphics
> file to disk and emacs checking the file size. My guess is that this is
> causing the problem (and that the same failure applies for emacs-2{6,7},
> since only the emacs-28 reports the exact test failure).

Maybe we can just add several `sleep-for' calls to the test?

>> I disabled the tests for the time being until we figure out what is
>> going on.
>>
>> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=a29103a78
>
> That's pretty crude. Here are a couple thoughts:
>
> - Is there a way to detect that the tests are running in this CI
>   environment? We could use that to skip the file-size test selectively.
> - Alternatively, we could remove the file-size test entirely.

That's temporary solution to not make CI flood me with failure emails
several times a day.

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

Re: copying text from links makes it with a starting [[

[Esteban Ordóñez]

El 2022-12-27 09:34, Esteban Ordóñez escribió:

> As Ighor wrote, please post the exact details of what you did so we can
> do it the same way as you do in our own environment.

Sorry for the typo, Ihor!

Re: ob-groovy.el must be hand-loaded?

[Ihor Radchenko]

Galaxy Being  writes:

> form. I've renamed it apache-groovy and it errored out specifically not
> finding ob-groovy.el. But again, if I don't specifically load the org-9.6
> ob-groovy.el, I get "can't find program groovy" upon block C-c C-c.

This error sounds like ob-groovy has been loaded (you can check it via
M-: (featurep 'ob-groovy) ), but you are missing executable in the path.

You may want to customize `org-babel-groovy-command'.

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

Re: copying text from links makes it with a starting [[

[Esteban Ordóñez]

El 2022-12-27 08:06, Luca Ferrari escribió:
> Hi all,
> I'm not sure this is an org problem, rather a clipboard problem or
> what else, but when I select an org link in Emacs and I copy into my
> Firefox browser, the link has always a starting pair of square
> brackets (e.g. [[https://...).
> What puzzles me is that there are no ending brackets, as it would make
> more sense to me.

What you are probably doing is removing the ]] at the closing to see the
link.  Then you are copying the link with the openning [[.  And then you
are pasting it with that on you browser.

As Ighor wrote, please post the exact details of what you did so we can
do it the same way as you do in our own environment.

[FR] Present list of errors in separate buffer when running org-export, similar to what org-lint does (was: [Syntax discussion] Should we treat src blocks without LANG as paragraphs?)

[Ihor Radchenko]

As Max proposed, it may be a good idea to extend the concept of org-lint
to export.

We may unify the LaTeX errors, some errors/warnings potentially signalled
by export backend, and maybe some warnings from org-lint during the
export process. These errors can ideally be displayed just like in
org-lint, with ability to jump to the problematic LoCs in
Org/intermediate file.

This is a medium task and one will need to:
1. Generalize org-lint interactive interface (list of errors) to work
   with other code. Extract it into a separate library.
2. Accumulate export issues into a list to be displayed. For example,
   broken links can be displayed
3. Make functions like `org-latex-compile' accumulate LaTeX errors as
   well. (Optionally) associate LaTeX buffer lines with Org source.
4. Display the list of errors/warnings at the end of successful or
   failed export.

Each step if fairly simple, except optional part in 3.
Patches welcome!

Max Nikulin  writes:

> ... Exporter may issue warnings, they are 
> collected and presented to user in a temporary window with buffer names 
> and line numbers as in compilation-minor-mode. The user may see that 
> something goes wrong, but if their does not switch to the warnings 
> window then it disappears. It would be great if exporters and lint share 
> code generating warnings. Another issue that mature development tools 
> usually allows to suppress particular warning for a specific line. It 
> may be a problem taking into account specific of Org syntax.
>
> As to `org-lint', I believe, it is hard to discover for new users and 
> there should be a reason to run it. It easy to forget about it even when 
> some problem is faced. It is mentioned in the manual, but
> - https://orgmode.org/manual/Feedback.html does not request to run 
> org-lint before reporting a bug
> - `org-submit-bug-report' neither suggest `org-lint' nor runs it as a 
> check. Likely it should be suppressed (with appropriate report) for 
> large buffers.

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

Re: [BUG] ox-html does not export captions of source blocks without language

[Ihor Radchenko]

Johan Bolmsjö  writes:

> ** Description
>
> The caption "Caption 1" is not exported by ox-html in the following
> source block.
>
> #+caption: Caption 1
> #+begin_src
> foo bar baz
> #+end_src
>
> The caption "Caption 2" is exported by ox-html in the following source
> block.
>
> #+caption: Caption 2
> #+begin_src sh
>   echo foo bar baz
> #+end_src
>
> ** Expectation
>
> The caption "Caption 1" is exported just as "Caption 2" is. The plain
> text exporter ox-ascii exports both "Caption 1" and "Caption 2".

Here is the plan to resolve this issue:

1. We update the manual allowing src blocks to have empty language spec
2. We update org-syntax document
3. We change org-html-src-block to add caption to src blocks without lang
4. We _do not_ treat such src blocks as example blocks.
   It is because at least ox-html, ox-latex, and ox-ascii never add
   captions to example blocks. Changing this default may possible, but
   require further discussion. The existing code already uses separate
   implementations for example blocks and src blocks with nil lang.

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

Re: Problem with multi-occur search when restricted to region

[Ihor Radchenko]

alain.coch...@unistra.fr writes:

>* h1
>foo
>* h2
>foo bar
>
> I make the 1st two lines the region.  Then I do
>
>M-x org-agenda << / foo
>
> and I see
>
>2 matches for "foo" in buffer: debug.org
>2:foo
>4:foo bar

Thanks for reporting!
Can you try the attached patch?

>From e0e18a6e98fb2faafcc9a43a55321206e8b3f9ed Mon Sep 17 00:00:00 2001
Message-Id: 
From: Ihor Radchenko 
Date: Tue, 27 Dec 2022 16:41:57 +0300
Subject: [PATCH] org-occur-in-agenda-files: Respect agenda restriction

* lisp/org.el (org-occur-in-agenda-files): Respect agenda restriction
when searching.

Reported-by: alain.coch...@unistra.fr
Link: https://orgmode.org/list/25514.61148.396137.347...@gargle.gargle.howl
---
 lisp/org.el | 32 
 1 file changed, 24 insertions(+), 8 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 26a4c8b1c..2ab7c0ccf 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -18551,24 +18551,40 @@ (defun org-occur-in-agenda-files (regexp  _nlines)
   (interactive "sOrg-files matching: ")
   (let* ((files (org-agenda-files))
 	 (tnames (mapcar #'file-truename files))
-	 (extra org-agenda-text-search-extra-files))
-(when (eq (car extra) 'agenda-archives)
+	 (extra org-agenda-text-search-extra-files)
+ (narrows nil))
+(when (and (eq (car extra) 'agenda-archives)
+   (not org-agenda-restrict))
   (setq extra (cdr extra))
   (setq files (org-add-archive-files files)))
-(dolist (f extra)
-  (unless (member (file-truename f) tnames)
-	(unless (member f files) (setq files (append files (list f
-	(setq tnames (append tnames (list (file-truename f))
+(unless org-agenda-restrict
+  (dolist (f extra)
+(unless (member (file-truename f) tnames)
+	  (unless (member f files) (setq files (append files (list f
+	  (setq tnames (append tnames (list (file-truename f)))
 (multi-occur
  (mapcar (lambda (x)
 	   (with-current-buffer
 		   ;; FIXME: Why not just (find-file-noselect x)?
 		   ;; Is it to avoid the "revert buffer" prompt?
 		   (or (get-file-buffer x) (find-file-noselect x))
-		 (widen)
+ (if (eq (current-buffer) org-agenda-restrict)
+		 (progn
+   ;; Save the narrowing state.
+   (push (list (current-buffer) (point-min) (point-max))
+ narrows)
+   (widen)
+   (narrow-to-region org-agenda-restrict-begin
+ org-agenda-restrict-end))
+		   (widen))
 		 (current-buffer)))
 	 files)
- regexp)))
+ regexp)
+;; Restore the narrowing.
+(dolist (narrow narrows)
+  (with-current-buffer (car narrow)
+(widen)
+(narrow-to-region (nth 1 narrow) (nth 2 narrow))
 
 (add-hook 'occur-mode-find-occurrence-hook
 	  (lambda () (when (derived-mode-p 'org-mode) (org-fold-reveal
-- 
2.38.1


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

Re: copying text from links makes it with a starting [[

[Ihor Radchenko]

Luca Ferrari  writes:

> I'm not sure this is an org problem, rather a clipboard problem or
> what else, but when I select an org link in Emacs and I copy into my
> Firefox browser, the link has always a starting pair of square
> brackets (e.g. [[https://...).
> What puzzles me is that there are no ending brackets, as it would make
> more sense to me.

Could you please provide more details about what is happening?
What exactly do you do to copy the link?
See https://orgmode.org/manual/Feedback.html#Feedback

> Is there a way to insrtument Emacs to copy in the clipboard only the
> marked text and not the org mode formatting text?

If you configure Org to hide parts of the links, you can use
org-copy-visible.

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

Problem with multi-occur search when restricted to region

[Alain . Cochard]

Tested with

   Org mode version 9.6 (release_9.6-149-g554935.dirty @
   /home/cochard/Org/Coch-git/org-mode/lisp/)

I have the file debug.org containing

   * h1
   foo
   * h2
   foo bar

I make the 1st two lines the region.  Then I do

   M-x org-agenda << / foo

and I see

   2 matches for "foo" in buffer: debug.org
 2:foo
 4:foo bar

(By contrast, 'M-x org-agenda << s foo' only shows 'debug: h1' as I
expect.)

-- 
EOST (École et Observatoire des Sciences de la Terre) 
ITE (Institut Terre & Environnement) | alain.coch...@unistra.fr
5 rue René Descartes   [bureau 110]  | Phone: +33 (0)3 68 85 50 44 
F-67084 Strasbourg Cedex, France | [ slot available for rent ]

copying text from links makes it with a starting [[

[Luca Ferrari]

Hi all,
I'm not sure this is an org problem, rather a clipboard problem or
what else, but when I select an org link in Emacs and I copy into my
Firefox browser, the link has always a starting pair of square
brackets (e.g. [[https://...).
What puzzles me is that there are no ending brackets, as it would make
more sense to me.
Is there a way to insrtument Emacs to copy in the clipboard only the
marked text and not the org mode formatting text?

I'm running Emacs 28.2 and org 9.5.5

Thanks,
Luca

Re: [PATCH] lisp/ob-tangle.el, lisp/ob-core.el: Add strip-tangle noweb option

[Ihor Radchenko]

Ihor Radchenko  writes:

> Also, several small comments about the commit message.

For the record, an amended version of this patch have been applied.
See https://orgmode.org/list/87leona2r1.fsf@localhost

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

Re: Export Org with Org concept -- Re: Problems with C-c C-e file.org,

[Ihor Radchenko]

Jean Louis  writes:

> If you mean formatting of the text, how it looks like, then retain
> formatting of text. That is choice. That is not part of the offered
> concept. 

Yes, that's what I was referring to. I am not against non-blocking
interface per se.

> QUESTION: Should I now add the ordinary layout and keybindings and
> show you how it works?

It will be a good first step forward, yes.
If we move in this direction, we will need to find some way to replace
all the menus, like agenda menu, attach menu, clock menu, capture menu,
export menu, tag menu, etc.

We have one shared interface in `org-mks', which might be tweaked a
starting point.

> From your side I expect that you tell me how do you use Org functions
> to discover new exports as to see how to automatically include such.

For export menu, the relevant function is `org-export--dispatch-ui'.

> You have defined constraints to be the formatting (layout) and key
> bindings.
>
> Is there anything else?

I don't think so. The basic idea is to not break workflows that worked
in the past.

> I believe there is something in org that recognizes various export
> options and implements menu, is it? 

Mostly a collection of ad-hoc code all across Org. See the above.

>> In the video, you are using Org mode commands inside menu, which is a
>> new concept for me.
>
> I can't understand what you mean. Which Org mode command do you mean?
>
> Is it on this first video:
> https://gnu.support/files/emacs/packages/rcd-org-export/2022-12-19-23:36:10.ogv

Here.  on the menus toggling the checklist.
The approach used in the existing menus is entering a dedicated key or
key sequence to select/unselect options.

> Regarding formatting: I don't think that formatting and layouts were
> pretty dependant on the interface in the manner how it began in past,
> and then programmers kept using that concept for the sake of the
> interface, not for sake of users. If you are bound to foundation
> lacking usability, of course programmers must stick to that
> foundation. However, that does not help users become swift in
> exporting. And thus it is not bad to escape the formatting for
> something better.

You may be right, but, as stated in the article I referenced, "I won't
lecture you [the user] on why the new experience is better."

If you think that we need to throw that existing approach away
completely and use the one you proposed, I'd suggest implementing the
better menu framework as independent package instead, allow plugging it
into Org, and then maybe switch to it in future if many users use the
alternative framework instead of the default one.

Combining the two is better though. IMHO.

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

Re: CSV agenda export formats some day and month values as single digits

[Ihor Radchenko]

Max Nikulin  writes:

>> The reason I suggest using the default value is that
>> `calendar-iso-date-display-form' is a defcustom.
>
> Thank you, I did not noticed that it is a user option. I should think 
> more on this. If a user has a reason to override the ISO format, perhaps 
> it should be respected in some way.

It will not be very obvious that calendar-related customization will
affect agenda export. If we want to allow customizing csv export format,
we need to introduce agenda-specific customization instead.

I suggest keeping this as a constant for now and provide a defcustom if
there is interest. There haven't been any until now, including this
report, which merely pointed to a bug.

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

Re: 'C-c a s' sometimes gives as result the END of an inelinetask

[Ihor Radchenko]

alain.coch...@unistra.fr writes:

> Here is a minimal example: file debug2.org which contains
>
>* foo
>*** inlt
>ininlt
>*** END
>bar
>
> ...
> Then I do
>
>M-x org-agenda  < s bar 

Thanks for reporting!
Fixed on bugfix.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=fc4bbb28f

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

Re: bug#59882: Multiple versions of Org in load-path problem

[Max Nikulin]

On 27/12/2022 16:47, Ihor Radchenko wrote:

Can you then try to test using Emacs 28?
The main question if whether this has been fixed in newer Emacs releases
or it is also something to do with OS environment.


I see quite the same issue with Emacs-28.2 in Debian testing. Compile 
buffer displays a bit more warnings and usual `org-assert-version' 
warnings and errors are present as well. It might have another level of 
complexity due to .eln files. I am unsure what happens with calls to 
undefined macros.

Re: [BUG] org-block face not working for "non-default" languages

[Ihor Radchenko]

duskhorn  writes:

> This works perfectly!
> I get both fixed pitch and syntax highlight!
> Thank you so much for your work, Ihor!

Applied onto bugfix.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=ecfb55af0

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

Re: bug#59882: Multiple versions of Org in load-path problem

[Ihor Radchenko]

Max Nikulin  writes:

> I found just single commit to lisp/emacs-lisp/package.el between 
> emacs-27.1 and emacs-27.2:
>
> 1fc9de4b81c 2020-10-30 19:20:24 -0700 Glenn Morris: Improve 
> reproducibility of generated -pkg.el files
>
> So I am still surprised that you can not reproduce the issue.

Can you then try to test using Emacs 28?
The main question if whether this has been fixed in newer Emacs releases
or it is also something to do with OS environment.

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