Re: org-agenda queries for absent properties

[Ihor Radchenko]

Jens Schmidt  writes:

> - I used "\(?NUM: ... \)" constructs to explicitly number the subres.
>Hope this is OK w.r.t. style and backward-compatibility.

Yes, it is ok.

> - I fixed the operator-matching subre to also include `==', `!=', `/='
>but exclude `<<' and the like which currently give void-function
>errors.

Sounds reasonable.

> But from here it gets more intersting:
>
> - The code uses subre "-" in property names to (supposedly) allow
>for inclusion of minus characters in property names, which (probably)
>could be confused with term negation.

Not probably. It is known to be confused.
https://orgmode.org/list/87jzv67k3p.fsf@localhost

> - It also unquotes these minus characters for {tag regexps}:
>
>  (tag (save-match-data
> (replace-regexp-in-string
>  "-" "-" (match-string 2 term
>
>But it never unquotes them in property names.  That missing unquoting
>could be easily amended, but:
>
> - The other issue is: Why do we need "-" for both property names and
>{tag regexps}?  This forces us to do queries like:
>
>  {[a\\-z]}|foo\\-bar="baz"
>
>where in my opinion
>
>  {[a\-z]}|foo\-bar="baz"
>
>should be sufficient.

Ideally, we should have no need to quote "-" inside regexp terms.
The need to do it is not documented either.

> - Even more, IMO one could do away completely with the minus-quoting and
>unquoting, since the overall regexp should allow for unambiguously
>matching minus characters both
>
>+ in {tag regexps} (because of "{[^}]+}" gobbling them) and
>
>+ in property names (because a property name must always be followed
>  by some operator)
>
>*without* them getting confused with term negation.
>
>Or do I miss something here?  A cursory test with sth like
>
>  +foo-bar="xxx"-patchday=202302
>
>seems to work fine.

Agree.

> - However, removing the unquoting of {tag regexps} would be a breaking
>change.  Even though I doubt anybody has ever used it, the more it is
>not mentioned in the documentation.

Unquoting in {tag regexps} was never intentional.
The commit that introduced this piece of code is the following:

19b0e03f32c6032a60150fc6cb07c6f766cb3f6c
Author: Carsten Dominik 
Make backslash escape "-" in property matches

* lisp/org.el (org-make-tags-matcher): Read "\\-" as "-" in
the tags/property matcher.

Ilya Shlyakhter writes:

 When doing an agenda tags match for tags or properties with dashes in
 their name, the dashes become negation operators: "my-prop>0" means
 "entries that have the tag 'my' and do not have a positive property
 'prop'", rather than "entries that have a positive property
 'my-prop'".  Is there a way to escape the dashes to get the latter
 meaning?

> +  ;; LEVEL property match
> +  "LEVEL\\(?3:[<=>]=?\\|[!/]=\\|<>\\)\\(?4:[0-9]+\\)\\|"
> +  ;; regular property match
> +  "\\(?:"
> +  ;; property name
> +  "\\(?5:\\(?:[[:alnum:]_]+\\(?:-\\)*\\)+\\)"
> +  ;; operator, optionally starred
> +  "\\(?6:[<=>]=?\\|[!/]=\\|<>\\)\\(?7:\\*\\)?"

?3 and ?6 duplicate a part of regexp. It would make sense to let-bind
the common part to avoid accidental typos in future.

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

Re: [PATCH] org-manual: Add references to LaTeX docs

[Ihor Radchenko]

David Masterson  writes:

> I think you meant '=texdoc latex=' here.
> ...
> Oh, also 'open a PDF file'.
>
> Everything else looks good.

Thanks for the review!
Applied, with the suggested amendments, onto main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=f4fecc244

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

Re: [Help] org-capture: How to capitalize the text entered from the "nth prompt"

[Ihor Radchenko]

Maske  writes:

> Could it be possible, in org-capture, to capitalize the text entered 
> from a previous prompt?

Check out https://github.com/progfolio/doct

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

Re: Maintenance status of individual Org libraries

[Ihor Radchenko]

Bastien Guerry  writes:

> Ihor Radchenko  writes:
>
>> Should we try to make a call for maintenance at least for some of these
>> libraries?
>
> Definitely.  We should probably prioritize files in this list, then
> ask on this list *and* on the web.
>
> Let's make sure we propose this as something fun to do, not a chore.
>
> How do you want to proceed?

I have no concrete plan. Some random thoughts:

- We may run a poll on how people use various parts of Org to see
  popularity/user base for different libraries. This may be a useful
  metrics for prioritization.

- We may need to identify the core libraries that have to be maintained
  better because everything else relies upon them.

- Some people are scared of maintenance partly because they do not want
  to follow all the messages in the mailing list.

- Rather than asking straight about maintenance, we may ask about
  problem people encounter with the Org libraries they use.  Having some
  real, personal problem to solve may be a driver to get started with
  maintaining a library.

- Instead of maintenance, we can ask people to demo using some less
  popular libraries during meetups (like
  https://orgmode.org/list/87tttlflht.fsf@localhost). This may reveal
  problems better and may allow writing the often missing tests. At
  least, tests can make things more robust even if not maintained.

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

Re: How to put a string produced by an Elisp form in an Org source block in the Org file?

[Ihor Radchenko]

Marcin Borkowski  writes:

>> May you elaborate why you consider this a bug?
>
> I wouldn't call it a bug per se.  If my chart looks like this:
>
> |
> *
> |*
> | *
> +--*-
>
> it is displayed in Org example block as
>
> |
> ,*
> |*
> | *
> +--*-

Is there any problem with the default results handling? By default, Org
uses fixed-width like

: |
: *
: |*
: | *
: +--*-

Except very long outputs. But see `org-babel-min-lines-for-block-output'.

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

Re: [ANN] lisp/ob-tangle-sync.el

[Ihor Radchenko]

Mehmet Tekman  writes:

> Anyway, I finally did it - I got it to work. Every single patch now
> pasts tests.

Consider the following edge case:

#+PROPERTY: header-args :tangle "file name with spaces and no word.txt"

#+begin_src emacs-lisp :tangle sync
#+end_src

With your patch, I got :tangle "file name with spaces and no word.txt sync".

Also, there is actually a big problem across Org where :tangle parameter
is often checked using expressions like (cdr (assq :tangle (nth 2 info)))
No splitting is done, and the assumption is made that the value cannot be
compound.

It looks like we are opening a Pandora box with this feature. And rather
than fixing all the places that use :tangle across Org, we may need to
create a new API to retrieve header argument values uniformly, without
knowing the details about how to split PARAMS string.

We may have to use the approach employed for :results header argument
where in addition to (:results . "string value"), we have
(:result-params "sub-value" "sub-value" ...).

:result-params is now handled by `org-babel-process-params'.
We may need to extend this function to work with all the possible header
arguments that have multiple exclusive groups and do not have a single
allowed value.

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

Re: org-agenda queries for absent properties

[Jens Schmidt]

On 2023-08-06  09:55, Ihor Radchenko wrote:


But from here it gets more intersting:

- The code uses subre "-" in property names to (supposedly) allow
for inclusion of minus characters in property names, which (probably)
could be confused with term negation.


Not probably. It is known to be confused.
https://orgmode.org/list/87jzv67k3p.fsf@localhost


Right.  But the issue back then appeared because the subre for property
names does not match minus characters, just alnums and underscores:

  \\([[:alnum:]_]+\\)

What I'm trying to convey is: If we match plain minus characters in
above subre, these will be greedily goobled up including any following
operator, which makes the whole thing uniquely an operator term.  If
there is no following operator, but something else, the whole regexp
backtracks and (hopefully) matches a following negative term.


- Even more, IMO one could do away completely with the minus-quoting and
unquoting, since the overall regexp should allow for unambiguously
matching minus characters both

+ in {tag regexps} (because of "{[^}]+}" gobbling them) and

+ in property names (because a property name must always be followed
  by some operator)

*without* them getting confused with term negation.

Or do I miss something here?  A cursory test with sth like

  +foo-bar="xxx"-patchday=202302

seems to work fine.


Agree.


Ah, OK.  I thought you wouldn't.  Let me redo this thing as I think it
is correct (including let-binding common subres as you suggested).  I
will also add tests for matching property names having minuses and then
we can see how it goes.

Re: Worg: issue with org-tools page

[Max Nikulin]

On 05/08/2023 19:23, Ihor Radchenko wrote:

Max Nikulin writes:


I was trying to modify publish.sh to collect errors up to a reasonable
number, a draft is attached.

...

Currently it just prints summary of failures. When allowed failures
count is exceeded, it fails immediately.

./publish.sh --maxfail 32


I am not sure why it would be useful to limit the number of errors to
anything other than 0/infinity.


You have agreed that aborting of upload on any error may be 
disappointing when the error was introduced by another person.


If there are dozens of failures then something serious has happened 
either with Org or with Worg and it is a reason to not upload partial 
results.


I believe that list of 5-10 failed files is suitable for notification 
failure (e-mail, instant messaging, etc.).



Note that I just pushed an alternative (but very similar) change in
https://git.sr.ht/~bzg/worg/commit/b38a1f08


It fails on first error. I find a report containing several errors much 
more helpful for figuring out what has actually happened. On the other 
hand there should be a strong reason to read all errors when there are 
hundreds one.


P.S. You have not documented that your approach abuses --debug-init 
standard Emacs option.

[patch] ox-latex.el: fix blank lines behavior in verse block

[Juan Manuel Macías]

Rationale for this patch: the treatment of blank lines in
`org-latex-verse-block' is inconsistent with the syntax of the `verse'
environment, both the one that includes LaTeX and the one provided by
the `verse' package as a replacement for the former.

Currently, each blank line is exported to LaTeX as an explicit vertical
space: \vspace*{1em}. This can return unexpected results. For example,
this:

┌
│ #+begin_verse
│
│ lorem
│ ipsum
│ dolor
| 
│ #+end_verse
└

is exported to LaTeX as:

┌
│ \begin{verse}
│ \vspace*{1em}
│ lorem\\[0pt]
│ ipsum\\[0pt]
│ dolor\\[0pt]
│ \vspace*{1em}
│ \end{verse}
└

In the LaTeX `verse' environment, spaces before and after the content
are not taken into account.

As for the separation between stanzas, this is marked with at least one
blank line between the stanzas, as in normal paragraphs (not with an
explicit vertical space). Also it is not necessar y that the last verse
of each stanza ends with the linebreak mark `\\'.

So, after this patch:

• Any blank line before and/or after the content is removed;

• One or more blank lines between stanzas are exported as a single blank
  line, leaving the previous final verse without the linebreak mark
  `\\';

• When verse numbering is enabled via the `:lines' attribute (for the
  `verse' package), the last verses of each stanza are marked with
  `\\!', according to the verse package syntax (this was not necessary
  with the previous behavior).


This way, the `verse' block is exported to LaTeX with the correct
syntax. This also brings the advantage of being able to globally control
the spacing between stanzas via the verse package’s \stanzaskip command.

Example:

┌
│ #+begin_verse
│ Lorem ipsum dolor
│ lorem ipsum dolor
│ lorem ipsum dolor
│
│ Lorem ipsum dolor
│ lorem ipsum dolor
│ lorem ipsum dolor
│
│ Lorem ipsum dolor
│ lorem ipsum dolor
│ lorem ipsum dolor
│ #+end_verse
└

LaTeX:

┌
│ \begin{verse}
│ Lorem ipsum dolor\\[0pt]
│ lorem ipsum dolor\\[0pt]
│ lorem ipsum dolor
│
│ Lorem ipsum dolor\\[0pt]
│ lorem ipsum dolor\\[0pt]
│ lorem ipsum dolor
│
│ Lorem ipsum dolor\\[0pt]
│ lorem ipsum dolor\\[0pt]
│ lorem ipsum dolor\\[0pt]
│ \end{verse}
└

And with verse numbers:

┌
│ #+ATTR_LaTeX: :lines 5
│ #+begin_verse
│ Lorem ipsum dolor
│ lorem ipsum dolor
│ lorem ipsum dolor
│
│ Lorem ipsum dolor
│ lorem ipsum dolor
│ lorem ipsum dolor
│
│ Lorem ipsum dolor
│ lorem ipsum dolor
│ lorem ipsum dolor
│ #+end_verse
└

LaTeX:

┌
│ \begin{verse}
│ \poemlines{5}
│ Lorem ipsum dolor\\[0pt]
│ lorem ipsum dolor\\[0pt]
│ lorem ipsum dolor\\!
│
│ Lorem ipsum dolor\\[0pt]
│ lorem ipsum dolor\\[0pt]
│ lorem ipsum dolor\\!
│
│ Lorem ipsum dolor\\[0pt]
│ lorem ipsum dolor\\[0pt]
│ lorem ipsum dolor\\[0pt]
│ \end{verse}
│ \poemlines{0}
└

N.B.: the `\\[0pt]' mark of the last verse does not affect the final result.

Best regards,

Juan Manuel

--
Juan Manuel Macías

https://juanmanuelmacias.com

https://lunotipia.juanmanuelmacias.com

https://gnutas.juanmanuelmacias.com

>From 0c8a352567333d0d743b5235b68e9cd5d513f615 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias 
Date: Sun, 6 Aug 2023 12:42:36 +0200
Subject: [PATCH] lisp/ox-latex.el: fix blank lines behavior in verse block
 export.

* (org-latex-verse-block): now the treatment of blank lines is
consistent with the syntax of the LaTeX `verse' environment, and the
one provided by the `verse' package.
---
 lisp/ox-latex.el | 18 +-
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 31cad1dc4..26827537a 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -4128,20 +4128,28 @@ contextual information."
   verse-block
   ;; In a verse environment, add a line break to each newline
   ;; character and change each white space at beginning of a line
-  ;; into a space of 1 em.  Also change each blank line with
-  ;; a vertical space of 1 em.
+  ;; into a space of 1 em.  One or more blank lines between lines
+  ;; are exported as a single blank line.
   (format "%s\\begin{verse}%s\n%s\\end{verse}%s"
 	  vwidth
 	  attr
 	  (replace-regexp-in-string
 	   "^[ \t]+" (lambda (m) (format "\\hspace*{%dem}" (length m)))
 	   (replace-regexp-in-string
-(concat "^[ \t]*" (regexp-quote org-latex-line-break-safe) "$")
-	"\\vspace*{1em}"
+		(concat "\\("
+			(regexp-quote org-latex-line-break-safe)
+			"\n\\)"
+			"\\(^[ \t]*"
+			(regexp-quote org-latex-line-break-safe)
+			"\n"
+			"\\)+")
+		(if lin "!\n\n" "\n\n")
 	(replace-regexp-in-string
 	 "\\([ \t]*\\)?[ \t]*\n"
  (concat org-latex-line-break-safe "\n")
-	 contents nil t)
+	 ;; Remove any blank lines before and after CONTENTS.
+		 (concat (org-trim contents t) "\n")
+		 nil t)
 nil t)
nil t)
   linreset)
-- 
2.41.0

Re: org-agenda queries for absent properties

[Jens Schmidt]

On 2023-08-06  11:19, Jens Schmidt wrote:


I
will also add tests for matching property names having minuses and then
we can see how it goes.


Went well.  With a property name regexp

  "\\(?5:[[:alnum:]_-]+\\)"

and the following Org file

--
* H1 :BAR:
:PROPERTIES:
:TEST-FOO: 1
:END:
* H2 :FOO:
:PROPERTIES:
:TEST-FOO: 2
:END:
* H3 :BAR:
:PROPERTIES:
:-FOO: 1
:END:
* H4 :FOO:
:PROPERTIES:
:-FOO: 2
:END:
* H5
--

the search expressions "TEST-FOO!=*0-FOO" and "-FOO+TEST-FOO!=*0" work
as expected, finding only the first heading.

The expression "-FOO!=*0-FOO" does *not* work, though, since the leading
minus in the property name is gobbled by the greedy inclusion/exclusion
subexp "\\(?1:[-+:]\\)?".  However, the remedy is simple: Add an
explicit plus sign: "+-FOO!=*0-FOO".

Documented that in the Org manual, added tests, looks good.  Please
check.
From cb3268c8b1c69371589a9aa44a96d33e29aedbb1 Mon Sep 17 00:00:00 2001
From: Jens Schmidt 
Date: Sun, 6 Aug 2023 16:38:04 +0200
Subject: [PATCH] org-make-tags-matcher: Add starred property operators, fix
 quoting

* lisp/org.el (org-make-tags-matcher): Add starred property operators.
Recognize additional operators "==", "!=", "/=".  Clean up and
document match term parsing.  Remove needless and buggy unquoting of
minus characters in property and tag names.
(org-op-to-function): Recognize additional inequality operator "/=".

* doc/org-manual.org (Matching tags and properties): Add documentation
on starred and additional operators.  Document allowed characters in
property names and handling of minus characters in property names.

* testing/lisp/test-org.el (test-org/map-entries): Add tests for
starred and additional operators.  Add tests for property names
containing minus characters.

* etc/ORG-NEWS: (~org-tags-view~ supports more property operators):
Add announcement on starred and additional operators.

Link: https://orgmode.org/list/9132e58f-d89e-f7df-bbe4-43d53a236...@vodafonemail.de
---
 doc/org-manual.org   |  35 +++-
 etc/ORG-NEWS |  10 +++-
 lisp/org.el  | 120 ---
 testing/lisp/test-org.el |  64 -
 4 files changed, 192 insertions(+), 37 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index e59efc417..4252d7ac3 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -9246,16 +9246,18 @@ When matching properties, a number of different operators can be used
 to test the value of a property.  Here is a complex example:
 
 #+begin_example
-+work-boss+PRIORITY="A"+Coffee="unlimited"+Effort<2
++work-boss+PRIORITY="A"+Coffee="unlimited"+Effort<*2
  +With={Sarah\|Denny}+SCHEDULED>="<2008-10-11>"
 #+end_example
 
+#+cindex: operator, for property search
 #+texinfo: @noindent
 The type of comparison depends on how the comparison value is written:
 
 - If the comparison value is a plain number, a numerical comparison is
   done, and the allowed operators are =<=, ===, =>=, =<==, =>==, and
-  =<>=.
+  =<>=.  As synonym for the equality operator there is also , as
+  synonyms for the inequality operator there are =!== and =/==.
 
 - If the comparison value is enclosed in double-quotes, a string
   comparison is done, and the same operators are allowed.
@@ -9273,6 +9275,13 @@ The type of comparison depends on how the comparison value is written:
   is performed, with === meaning that the regexp matches the property
   value, and =<>= meaning that it does not match.
 
+- All operators may be optionally followed by an asterisk =*=, like in
+  =<*=, =!=*=, etc.  Such /starred operators/ work like their regular,
+  unstarred counterparts except that they match only headlines where
+  the tested property is actually present.  This is most useful for
+  search terms that logically exclude results, like the inequality
+  operator.
+
 So the search string in the example finds entries tagged =work= but
 not =boss=, which also have a priority value =A=, a =Coffee= property
 with the value =unlimited=, an =EFFORT= property that is numerically
@@ -9280,6 +9289,28 @@ smaller than 2, a =With= property that is matched by the regular
 expression =Sarah\|Denny=, and that are scheduled on or after October
 11, 2008.
 
+Note that the test on the =EFFORT= property uses operator =<*=, so
+that the search result will include only entries that actually have an
+=EFFORT= property defined and with numerical value smaller than 2.
+With the regular =<= operator, the search would handle entries without
+an =EFFORT= property as having a zero effort and would include them in
+the result as well.
+
+Currently, you can use only property names including alphanumeric
+characters, underscores, and minus characters in search strings.  In
+addition, if you want to search for a property whose name starts with
+a minus character, you have to "quote" that leading minus character
+with an exp

Re: [PATCH] org-macs: Fix incorrect use of relative paths in org-compile-file

[Roshan Shariff]

Thanks again Ihor!

For the future, I wanted to clarify that I do have a copyright
assignment to the FSF "for the suite of programs known as GNU EMACS".
I have a signed copy of the assignment form dated 3 April, 2022. I
should be in the list as "Roshan Shariff", but if not I can follow up
with the FSF to see if they missed adding me.

On Sun, 6 Aug 2023 at 00:49, Ihor Radchenko  wrote:
>
> Roshan Shariff  writes:
>
> > Thanks for the feedback! I'm attaching a new version of the patch that
> > improves the commit message and avoids the use of file-name-concat.
>
> Thanks!
> Applied, onto main, with minor amendments.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=4ea9a98f8
>
> I added a TINYCHANGE cookie as you do not appear to have FSF copyright
> assignment. I also duplicated your comment about "pwd" usage to
> `org-compile-file' to avoid accidental edits in future.
>
> Please note that your total contribution have now exceeded the allowed
> limit we can accept without copyright paper work.
> You may consider FSF copyright assignment in future. See
> https://orgmode.org/worg/org-contribute.html#copyright
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 

Re: Worg: issue with org-tools page

[Ihor Radchenko]

Max Nikulin  writes:

>> I am not sure why it would be useful to limit the number of errors to
>> anything other than 0/infinity.
>
> You have agreed that aborting of upload on any error may be 
> disappointing when the error was introduced by another person.

This will not happen now.
See https://git.sr.ht/~bzg/worg/tree/master/item/.build.yml
The error is only reported after "upload" via "check" task.

> If there are dozens of failures then something serious has happened 
> either with Org or with Worg and it is a reason to not upload partial 
> results.
>
> I believe that list of 5-10 failed files is suitable for notification 
> failure (e-mail, instant messaging, etc.).

Even a single failed file should trigger e-mail notification.

As for dozens of failures caused by something serious, I do hope that
Org commiters are careful enough. WORG uses bugfix version of Org where
we already push with care, when we are confident that things should not
break even theoretically. And if the large failures are caused by WORG
commit, it should be a commit either touching the build system or basic
WORG includes - such commits should be taken with care anyway.

In summary, I do not think that we should be concerned about downtime
caused by accidental and _also very serious_ issue caused by careless
commit. If we do encounter such scenarios, it will be a sign that we
should switch to a proper testing/production website builds; not trying
to re-invent the wheel with ad-hoc build script solutions.

>> Note that I just pushed an alternative (but very similar) change in
>> https://git.sr.ht/~bzg/worg/commit/b38a1f08
>
> It fails on first error. I find a report containing several errors much 
> more helpful for figuring out what has actually happened. On the other 
> hand there should be a strong reason to read all errors when there are 
> hundreds one.

You are right. I will see what I can do to throw exit only at the end,
showing all the errors.

> P.S. You have not documented that your approach abuses --debug-init 
> standard Emacs option.

My approach does not abuse --debug-init. The new cmd line argument is --debug.
I have no opinion about which header argument should be used. You can
propose an alternative, if you find something more self-explanatory and
not clashing with the existing Emacs command line args.

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

Re: [PATCH] org-macs: Fix incorrect use of relative paths in org-compile-file

[Ihor Radchenko]

Roshan Shariff  writes:

> For the future, I wanted to clarify that I do have a copyright
> assignment to the FSF "for the suite of programs known as GNU EMACS".
> I have a signed copy of the assignment form dated 3 April, 2022. I
> should be in the list as "Roshan Shariff", but if not I can follow up
> with the FSF to see if they missed adding me.

Thanks for the update.
I do not have access to the FSF records, and you are not yet listed on
https://orgmode.org/worg/contributors.html

Bastien, may you please confirm Roshan's copyright status?

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

Re: Worg: issue with org-tools page

[Bastien Guerry]

Ihor Radchenko  writes:

> May it be enough to drop --quick in Emacs call from publish.sh instead
> of manually adding system-installed Emacs packages?

Indeed.  Please go ahead: experimental commits won't hurt much.

> May we just set #+PROPERTY: header-args :eval no-export across
> examples?

Sure, please go ahead as you see fit!

-- 
 Bastien Guerry

Re: [PATCH] org-macs: Fix incorrect use of relative paths in org-compile-file

[Bastien Guerry]

Ihor Radchenko  writes:

> Bastien, may you please confirm Roshan's copyright status?

Yes, I do confirm Roshan is a FSF registered contributor for Emacs.

-- 
 Bastien Guerry

Re: What is a week?

[Bastien]

Hi Marcin,

I've found your entry in the FSF records for signed contributors but
if you have a new employer, he would have to sign the FSF assignment.

The form is here: https://orgmode.org/request-assign-future.txt

Of course, that's if you *want* to contribute with code and patches.
I do perfectly understand you might not want that, all other forms of
contributions are really appreciated too.

Best,

-- 
 Bastien

Re: What is a week?

[Bastien Guerry]

Ihor Radchenko  writes:

> Thanks for the clarification.
> Bastien, I think we should update the copyright status in WORG. Maybe
> also inform FSF?

I've updated the status in Worg.

-- 
 Bastien

Re: [PATCH] org-faq.org: Inline comments

[Bastien Guerry]

Ihor Radchenko  writes:

> Max Nikulin  writes:
>
>>> The proposed FAQ entry is overwhelming. It would work fine as a blog,
>>
>> A blog with a couple of posts a year has a little sense. Moreover it is 
>> closer to a wiki article because it is supposed to be updated. That is 
>> why I asked for an alternative location on Worg for bonus or extra 
>> material for the manual.
>
> I have no idea about alternative location.
> Maybe someone more familiar with WORG. Bastien?

FWIW, for such cases, I think a dedicated Worg page would make sense.

Also, yes, Worg css needs a lotta love.

-- 
 Bastien

Re: [PATCH] Re: what is the purpose of "This link has already been stored"?

[Bastien]

Ihor Radchenko  writes:

> * lisp/ol.el (org-link-store-existing): New customization controlling
> how to deal with already stored links.
> (org-store-link): Respect the new customization, allowing duplicates
> to (1) be added anyway; (2) be ignored; (3) be moved to front of
> `org-stored-links'.  The default is (3).
> * etc/ORG-NEWS (~org-store-link~ now moves an already stored link to
> front of the ~org-stored-links~): Document the breaking change.

I'm not sure what is the real world use-case for allowing storing the
same link several times.  Maybe one was provided, but I missed it.

I believe the new default behavior makes a lot of sense, thanks for
implementing this.

I'm skeptical about the need for a new dedicated option, though.

The current single universal prefix argument seems not that useful ("A
single `C-u' negates `org-context-in-file-links' for file links or
`org-gnus-prefer-web-links' for links to Usenet articles.") and we
could use it to force storing duplicates, which is more useful.

Here is the suggested new behavior, also modifying other universal
prefix args:

- M-x org-stored-links : don't store dups, move upfront if dup
- C-u M-x org-stored-links : force storing the link, even if dup
- [2 universal prefix arg] : negates ‘org-context-in-file-links’, etc
- [3 universal prefix arg] : forces skipping storing functions
  that are not part of Org core.

The current behavior for 3 prefix args should be the default when the
region is active.

WDYT?

-- 
 Bastien

[BUG?] org-babel eval src block with :dir parameter

[Sławomir Grochowski]

Dear All,

I'm surprised by this behaviour.

#+begin_src sh :results replace output
ls
#+end_src

#+RESULTS:
: file1.txt
: file2.txt

Adding :dir parameter changes output RESULTS. It's now wrapped in
#+begin_example #+end_example block.

#+begin_src sh :dir ~/ :results replace output
ls
#+end_src

#+RESULTS:
#+begin_example
file1.txt
file2.txt
#+end_example

Is it a bug?

Org mode version 9.6.7 (9.6.7-gc74c4a @
/home/slk/.emacs.d/straight/build/org/)
GNU Emacs 29.1.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.24,
cairo version 1.16.0) of 2023-07-30

Regards,
Sławomir Grochowski

Re: [BUG] Geiser fails to start REPL on Emacs 26

[Jose A. Ortega Ruiz]

Hi.  Thanks for the heads up. I've upped the requirement in Geiser 0.29.1
to Emacs 27.1.

Cheers,
jao

On Sun, Aug 06 2023, Ihor Radchenko wrote:

> Hi,
>
> Our (Org mode) CI is now failing to run ob-scheme tests because Geiser
> fails to run REPL:
>
> https://builds.sr.ht/~bzg/job/1035753
>
> Test test-ob-scheme/tables backtrace:
>   (obsolete max-specpdl-size)()
>   geiser-syntax--read-from-string("#")
>   geiser-guile-update-warning-level()
>   geiser-guile--startup(nil)
>   apply(geiser-guile--startup nil)
>   geiser-impl--call-method(repl-startup guile nil)
>   geiser-repl--startup(guile nil)
>   geiser-repl--start-repl(guile nil)
>   geiser(guile)
>   org-babel-scheme-get-repl(guile nil)
>
> This happens because `geiser-syntax--read-from-string' tries to call
> `with-suppressed-warnings', which is only available starting from Emacs
> 27.
>
> Considering that geiser claims supporting Emacs >=25.1, this appears to
> be a bug.

Re: [BUG?] org-babel eval src block with :dir parameter

[Ihor Radchenko]

Sławomir Grochowski  writes:

> I'm surprised by this behaviour.
>
> #+begin_src sh :results replace output
> ls
> #+end_src
>
> #+RESULTS:
> : file1.txt
> : file2.txt
>
> Adding :dir parameter changes output RESULTS. It's now wrapped in
> #+begin_example #+end_example block.

I am pretty sure that your example is not the whole output. The variant
with :dir has many more files, right? If so, check out
`org-babel-min-lines-for-block-output'.

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

Re: [BUG?] org-babel eval src block with :dir parameter

[Sławomir Grochowski]

Yes I just simplified the example. The case is if I add :dir param it
result will be wrapped it #+begin_example #+end_example block.

On Sun, Aug 6, 2023 at 9:02 PM Ihor Radchenko  wrote:

> Sławomir Grochowski  writes:
>
> > I'm surprised by this behaviour.
> >
> > #+begin_src sh :results replace output
> > ls
> > #+end_src
> >
> > #+RESULTS:
> > : file1.txt
> > : file2.txt
> >
> > Adding :dir parameter changes output RESULTS. It's now wrapped in
> > #+begin_example #+end_example block.
>
> I am pretty sure that your example is not the whole output. The variant
> with :dir has many more files, right? If so, check out
> `org-babel-min-lines-for-block-output'.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>

Re: [PATCH] Re: what is the purpose of "This link has already been stored"?

[Samuel Wales]

i am confused.  org-stored-links is a command?  what are the known
user needs for storing and pasting links?

i am also unclear on why we have a dedicated paste function as opposed
to kill ring.  probably a good reason.  but wfm.

i merely wanted to store then yank a link.  which in bugfix errors if
dup.  i also envisioned other less defined use cases.

stprog link several times could include having colelected a bunch of
links, perhaps in sequene but in the meantime wanting to copy and
paste a single link that is by coincidence in that list?  i could
imagine such a thing.

On 8/6/23, Bastien  wrote:
> Ihor Radchenko  writes:
>
>> * lisp/ol.el (org-link-store-existing): New customization controlling
>> how to deal with already stored links.
>> (org-store-link): Respect the new customization, allowing duplicates
>> to (1) be added anyway; (2) be ignored; (3) be moved to front of
>> `org-stored-links'.  The default is (3).
>> * etc/ORG-NEWS (~org-store-link~ now moves an already stored link to
>> front of the ~org-stored-links~): Document the breaking change.
>
> I'm not sure what is the real world use-case for allowing storing the
> same link several times.  Maybe one was provided, but I missed it.
>
> I believe the new default behavior makes a lot of sense, thanks for
> implementing this.
>
> I'm skeptical about the need for a new dedicated option, though.
>
> The current single universal prefix argument seems not that useful ("A
> single `C-u' negates `org-context-in-file-links' for file links or
> `org-gnus-prefer-web-links' for links to Usenet articles.") and we
> could use it to force storing duplicates, which is more useful.
>
> Here is the suggested new behavior, also modifying other universal
> prefix args:
>
> - M-x org-stored-links : don't store dups, move upfront if dup
> - C-u M-x org-stored-links : force storing the link, even if dup
> - [2 universal prefix arg] : negates ‘org-context-in-file-links’, etc
> - [3 universal prefix arg] : forces skipping storing functions
>   that are not part of Org core.
>
> The current behavior for 3 prefix args should be the default when the
> region is active.
>
> WDYT?
>
> --
>  Bastien
>
>


-- 
The Kafka Pandemic

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