org-agenda-skip-function not honored by 'tags-tree' custom agenda view

[João O'Neill Cortes]

Tested with org-mode version 9.7-pre.
Looking at section 'A.7 Special Agenda Views' of the info org-manual.

It is stated that 'tags-tree' searches can set
'org-agenda-skip-function' to some function that decides on the
visibilty of each match.  For what I gathered, by setting up something
like this,

 (org-add-agenda-custom-command
  '("b" tags-tree "some-tag"
((org-agenda-skip-function 'my-skip-function)
 ))) 

, and then calling 'org-agenda' and selecting the 'b' entry.

It does not work, and 'my-skip-function' never fires after the request
is made. It works for some types of special agenda views though, like
'todo', but not with 'tags-tree'.

Is this a bug?

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

[Juan Manuel Macías]

Ihor Radchenko writes:

> Looks reasonable in general. Of course, we will also need to document
> the new attribute.

Here is the modified patch (with your suggestions, including the `rx' code)
and the documentation of the new attribute.

-- 
Juan Manuel Macías

https://juanmanuelmacias.com

https://lunotipia.juanmanuelmacias.com

https://gnutas.juanmanuelmacias.com

>From 463e4a984b0ccc9bc1fdde699cb5cfed1ac59613 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias 
Date: Mon, 14 Aug 2023 21:48:58 +0200
Subject: [PATCH] lisp/ox-latex.el: add the `:literal' attribute to verse
 block.

* (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. If the `:literal' attribute is
used, the content is not exported within a `verse' environment, but
as-is, preserving horizontal spaces, line breaks, and blank lines.
The rx code has been suggested by Ihor Radchenko, to improve
readability.

* doc/org-manual.org (Verse blocks in LaTeX export): the new feature
is documented.
---
 doc/org-manual.org | 12 ++--
 lisp/ox-latex.el   | 43 ++-
 2 files changed, 40 insertions(+), 15 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index e59efc417..b640bbc7c 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -14425,8 +14425,8 @@ The LaTeX export backend converts horizontal rules by the specified
 #+cindex: verse blocks, in @LaTeX{} export
 #+cindex: @samp{ATTR_LATEX}, keyword
 
-The LaTeX export backend accepts four attributes for verse blocks:
-=:lines=, =:center=, =:versewidth= and =:latexcode=.  The three first
+The LaTeX export backend accepts five attributes for verse blocks:
+=:lines=, =:center=, =:versewidth=, =:latexcode= and =:literal=.  The three first
 require the external LaTeX package =verse.sty=, which is an extension
 of the standard LaTeX environment.
 
@@ -14440,6 +14440,14 @@ of the standard LaTeX environment.
   verse.
 - =:latexcode= :: It accepts any arbitrary LaTeX code that can be
   included within a LaTeX =verse= environment.
+- =:literal= :: With value t, the block is not exported to a =verse=
+  environment; instead, the content is exported as-is, preserving all
+  white lines as =\vspace{\baselineskip}=.  Note that in the =verse=
+  environment, one or more blank lines between stanzas are exported as
+  a single blank line, and any blank lines before or after the content
+  are removed.  If the =verse= package is loaded, the vertical spacing
+  between stanzas can be controlled by the length =\stanzaskip= (see
+  https://www.ctan.org/pkg/verse).
 
 A complete example with Shakespeare's first sonnet:
 
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 31cad1dc4..fcf22f87d 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -4116,32 +4116,49 @@ contextual information."
   (let* ((lin (org-export-read-attribute :attr_latex verse-block :lines))
  (latcode (org-export-read-attribute :attr_latex verse-block :latexcode))
  (cent (org-export-read-attribute :attr_latex verse-block :center))
- (attr (concat
-	(if cent "[\\versewidth]" "")
-	(if lin (format "\n\\poemlines{%s}" lin) "")
-	(if latcode (format "\n%s" latcode) "")))
+ (lit (org-export-read-attribute :attr_latex verse-block :literal))
+ (attr (if (not lit)
+		   (concat
+		(if cent "[\\versewidth]" "")
+		(if lin (format "\n\\poemlines{%s}" lin) "")
+		(if latcode (format "\n%s" latcode) ""))
+		 ""))
  (versewidth (org-export-read-attribute :attr_latex verse-block :versewidth))
- (vwidth (if versewidth (format "\\settowidth{\\versewidth}{%s}\n" versewidth) ""))
- (linreset (if lin "\n\\poemlines{0}" "")))
+ (vwidth (if (and versewidth (not lit)) (format "\\settowidth{\\versewidth}{%s}\n" versewidth) ""))
+ (linreset (if (and lin (not lit)) "\n\\poemlines{0}" "")))
 (concat
  (org-latex--wrap-label
   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.
-  (format "%s\\begin{verse}%s\n%s\\end{verse}%s"
+  ;; into a normal space, calculated with `\fontdimen2\font'.
+  ;; One or more blank lines between lines are exported as a
+  ;; single blank line.  If the `:literal' attribute is used,
+  ;; CONTENTS is exported as is, with no environment, preserving
+  ;; line breaks and vertical and horizontal spaces.
+  (format (if (not lit)
+		  "%s\\begin{verse}%s\n%s\\end{verse}%s"
+		"%s%s\n%s%s")
 	  vwidth
 	  attr
 	  (replace-regexp-in-string
-	   "^[ \t]+" (lambda (m) (format "\\hspace*{%dem}" (length m)))
+	   "^[ \t]+" (lambda (m) (format "\\hspace*{%d\\fontdimen2\\font}" (length m)))
 	   

Re: [BUG] org-set-tags-command hangs indefinitely in some indirect buffers

[Adam Beckmeyer]

See attached.*** 2021-08 August
 2021-08-23 Monday
*** Hello World   :Foobar:

[BUG] org-set-tags-command hangs indefinitely in some indirect buffers

[Adam Beckmeyer]

Hi everyone,

In some of my files, org-set-tags-command hangs indefinitely when invoked in an 
indirect buffer. Attached is an example file where you can see the behavior:

1. Open this file in org-mode.
2. Invoke org-tree-to-indirect-buffer in the "Hello World" heading
3. Invoke org-set-tags-command in the new indirect buffer.

I noticed this problem on git master but bisected and found the bug was 
introduced by: 
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=2f7b35ac89470f17937f5c20524c38db103aaa4c

Here's a backtrace when C-g in the middle of the hanging `org-set-tags-command`:

Debugger entered--Lisp error: (quit)
org-element-headline-parser(990890 t)
#f(compiled-function (limit  granularity mode structure) "Parse the 
element starting at point.\n\nReturn value is a list like (TYPE PROPS) where 
TYPE is the type\nof the element and PROPS a plist of properties associated to 
the\nelement.\n\nPossible types are defined in 
`org-element-all-elements'.\n\nLIMIT bounds the search.\n\nOptional argument 
GRANULARITY determines the depth of the\nrecursion. Allowed values are 
`headline', `greater-element',\n`element', `object' or nil. When it is broader 
than `object' (or\nnil), secondary values will not be parsed, since they 
only\ncontain objects.\n\nOptional argument MODE, when non-nil, can be 
either\n`first-section', `item', `node-property', 
`planning',\n`property-drawer', `section', `table-row', or 
`top-comment'.\n\n\nIf STRUCTURE isn't provided but MODE is set to `item', it 
will be\ncomputed.\n\nThis function assumes point is always at the beginning of 
the\nelement it has to parse." #)(990890 element 
nil nil)
org-element--parse-to(990890)
org-element-at-point(990890)
org-element-cache-map(#f(compiled-function (el) #))
org-get-buffer-tags()
org-set-tags-command(nil)
funcall-interactively(org-set-tags-command nil)
command-execute(org-set-tags-command)


Emacs : GNU Emacs 29.1 (build 2, x86_64-unknown-linux-gnu, X toolkit, cairo 
version 1.16.0)
of 2023-08-02
Package: Org mode version 9.7-pre (release_9.6.6-412-g2f7b35 @ 
/home/adam/.emacs.d/straight/repos/org/lisp/)

Best


Adam Beckmeyer

#+startup: noalign & C-c }

[Edgar Lux]

Hi! Is there a way to prevent resizing of a table with 
=org-table-toggle-coordinate-overlays=?

#+caption: there are some extra spaces after =1=, and before and after =b=.
#+begin_src org
,#+startup: noalign

| 1 | 2 |   b   |
#+end_src

When typing C-c } (command for =org-table-toggle-coordinate-overlays=) and then 
C-c } again to get out of that mode, the cells become

#+caption: the spaces are gone
#+begin_src org
| 1 | 2 | b |
#+end_src

#+begin_src emacs-lisp
  (emacs-version)
#+end_src

#+RESULTS:
: GNU Emacs 28.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.36, cairo 
version 1.17.6)
:  of 2023-01-03

#+begin_src emacs-lisp
  (org-version)
#+end_src

#+RESULTS:
: 9.5.5

Thanks! 

P.S. Is it polite that I reply with a thanks? or is it better to stay silent to 
avoid the extra e-mail (reading on your side)?

-- 
Sent with https://mailfence.com  
Secure and private email

Export snippet matching without closing "@@"

[Tom Alexander]

I suspect this is a regression. I am using this test document:
```
@@latex:



\documentclass[margin,11pt]{res} % default is 10 pt



@@
```

and dumped the AST with M-x eval-expression (message "%s" (pp-to-string 
(org-element-parse-buffer)))

When using the latest in main (commit b89bc55867d7cb809c379d371d12d409db785154, 
Org mode version 9.7-pre (release_N/A-N/A-b89bc5 @ 
/usr/share/emacs/site-lisp/org/)) the "@@latex:" gets parsed as an export 
snippet despite not having a closing "@@" (because the "@@" is in a different 
paragraph).

When using the version of org-mode that shipped with emacs 29.1 (Org mode 
version 9.6.6 (release_9.6.6 @ /usr/share/emacs/29.1/lisp/org/)) the "@@latex:" 
gets parsed as plaintext.

The docs seem to show that a "@@" is required as the end of an export snippet 
based on the pattern "@@BACKEND:VALUE@@": 
https://orgmode.org/worg/org-syntax.html#Export_Snippets

AST from org-mode in main:
```
(org-data
 (:standard-properties
  [1 71 1 71 0 1 nil nil nil 3 71 org-data nil nil nil nil nil #]
  :path nil :CATEGORY nil)
 (section
  (:standard-properties
   [1 71 1 71 0 1 nil nil nil 1 71 first-section nil nil #0 nil nil #])
  (paragraph
   (:standard-properties
[1 13 1 10 3 1 nil nil nil nil nil top-comment nil nil #1 nil nil #])
   (export-snippet
(:standard-properties
 [1 9 nil nil 0 nil nil nil nil nil nil nil nil nil #2 nil nil #]
 :back-end "latex" :value nil))
   #("\n" 0 1
 (:parent #2)))
  (paragraph
   (:standard-properties
[13 68 13 65 3 13 nil nil nil nil nil nil nil nil #1 nil nil #])
   (latex-fragment
(:standard-properties
 [13 46 nil nil 1 nil nil nil nil nil nil nil nil nil #2 nil nil #]
 :value "\\documentclass[margin,11pt]{res}"))
   #("% default is 10 pt\n" 0 19
 (:parent #2)))
  (paragraph
   (:standard-properties
[68 71 68 71 0 68 nil nil nil nil nil nil nil nil #1 nil nil #])
   #("@@\n" 0 3
 (:parent #2)
```

AST from org-mode in emacs 29.1:
```
(org-data
 (:begin 1 :contents-begin 1 :contents-end 71 :end 71 :robust-begin 3 
:robust-end 69 :post-blank 0 :post-affiliated 1 :path nil :mode org-data 
:CATEGORY nil :granularity nil)
 (section
  (:begin 1 :end 71 :contents-begin 1 :contents-end 71 :robust-begin 1 
:robust-end 69 :post-blank 0 :post-affiliated 1 :mode first-section 
:granularity nil :parent #0)
  (paragraph
   (:begin 1 :end 13 :contents-begin 1 :contents-end 10 :post-blank 3 
:post-affiliated 1 :mode top-comment :granularity nil :parent #1)
   #("@@latex:\n" 0 9
 (:parent #2)))
  (paragraph
   (:begin 13 :end 68 :contents-begin 13 :contents-end 65 :post-blank 3 
:post-affiliated 13 :mode nil :granularity nil :parent #1)
   (latex-fragment
(:value "\\documentclass[margin,11pt]{res}" :begin 13 :end 46 :post-blank 1 
:parent #2))
   #("% default is 10 pt\n" 0 19
 (:parent #2)))
  (paragraph
   (:begin 68 :end 71 :contents-begin 68 :contents-end 71 :post-blank 0 
:post-affiliated 68 :mode nil :granularity nil :parent #1)
   #("@@\n" 0 3
 (:parent #2)
```

--
Tom Alexander

Re: Htmlize support, maintenance, and Org mode

[Bastien Guerry]

Ihor Radchenko  writes:

> Bastien Guerry  writes:
>
>> If not, then relying on engrave-faces, which is maintained and also
>> handles LaTeX, instead of htmlize, sounds like a good idea.
>
> I'd like to hear Timothy's opinion on this. He is the author of
> engrave-faces and the maintainer of ox-html.

Sure!

-- 
 Bastien Guerry

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

[Bastien Guerry]

Ihor Radchenko  writes:

> See the attached tentative patch.

LGTM.

>> 2) Also remove the current C-u C-u C-u arg and make it the default
>>when a region is active.
>> ...
>> (2) should be done anyway.
>
> I studied this further and what you suggest will interfere with
> `org-link-context-for-files'. It will no longer be possible to select
> text very long
> and multi-line link description, M-x org-store-link, and get
> the selected text as stored link description.
>
> The current default of using active region as description makes more
> sense, IMHO.

Indeed.

So I was not that stupid when I added this C-u C-u C-u option :)

Thanks!

-- 
 Bastien Guerry

Re: [patch] Fix inner smart quotes in French

[Bastien Guerry]

Ihor Radchenko  writes:

> Bastien Guerry  writes:
>
>>> Are you referring to `org-export-smart-quotes-alist'? It is a defconst.
>>
>> Ah, indeed.  I'd say using a defcustom here would be useful.
>
> Is changing defconst to defcustom ok for bugfix?

Nope, it's more an "evolution" than a bugfix.

-- 
 Bastien Guerry

Re: Htmlize support, maintenance, and Org mode

[Ihor Radchenko]

Bastien Guerry  writes:

> It looks like engrave-faces already does a better job than htmlize.el,
> and does it for LaTeX too, I see no drawback in using engrave-faces as
> a replacement of htmlize.el.  Are there any?

engrave-faces is technically in "beta".
(https://github.com/tecosaur/engrave-faces)
Also, we need to carefully study if there are any missing features
compared to htmlize.

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

Re: [PATCH] org.el: Respect org-extend-today-until in timestamps with ++

[Bastien Guerry]

Ihor Radchenko  writes:

> "Valentin G. J. Herrmann"  writes:
>
>> Ok, so I guess I was stupid in another way :E
>> I do in fact have the FSF copyright assignment (Though probably under an 
>> old email address: herr.valentin.m...@gmail.com). I still included the 
>> TINYCHANGE comment. The attached patch should finally work.
>
> Bastien, may you please check the FSF records?

I did, I'll provide more information offlist.

-- 
 Bastien Guerry

Re: Htmlize support, maintenance, and Org mode

[Ihor Radchenko]

Bastien Guerry  writes:

> If not, then relying on engrave-faces, which is maintained and also
> handles LaTeX, instead of htmlize, sounds like a good idea.

I'd like to hear Timothy's opinion on this. He is the author of
engrave-faces and the maintainer of ox-html.

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

Re: Htmlize support, maintenance, and Org mode

[Bastien Guerry]

Ihor Radchenko  writes:

> That's what I meant. The latest thread named some issue with fine-tuning
> the output and never got any follow-up.

(Please ignore my suggestion to explore the htmlfontify.el scenario.)

>>> As for engrave-faces, it is working for both LaTeX and HTML export.
>>
>> Would that have the same issue has htmlize, that it copies the colours
>> from the currently active theme, causing issues when exporting a website
>> while a dark-theme is enabled?
>
> No. It can copy the current theme, but it is not the default. Instead,
> engrave-faces provides customization on how the faces should be
> re-mapped. Defaults are tuned to work for usual white backgrounds, but
> can be customized either using existing Emacs themes, or by hand,
> mapping Emacs faces to text colors and attributes.

It looks like engrave-faces already does a better job than htmlize.el,
and does it for LaTeX too, I see no drawback in using engrave-faces as
a replacement of htmlize.el.  Are there any?

-- 
 Bastien Guerry

Re: Htmlize support, maintenance, and Org mode

[Bastien Guerry]

Ihor Radchenko  writes:

> That's fine to install htmlize. Org relies upon htmlize for certain
> features, including HTML export.

A while ago, it has been suggested to rely on htmlfontify.el, which is
part of Emacs core, instead of htmlize.el.

Maybe this is still relevant?

If not, then relying on engrave-faces, which is maintained and also
handles LaTeX, instead of htmlize, sounds like a good idea.

2 cts,

-- 
 Bastien Guerry

Re: [PATCH] org.el: Respect org-extend-today-until in timestamps with ++

[Ihor Radchenko]

"Valentin G. J. Herrmann"  writes:

> I've now added org-test-with-time-locale so that the test results are 
> independent of the running machine. I think it's much cleaner this way 
> than using .*
> ...
> +(org-test-with-time-locale "en_US.UTF-8"
> + (org-test-at-time "<2014-03-04 02:35>"

This is fine, but not all the installations will have en_US.UTF-8 locale.
You may use `org-test-without-dow' instead.

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

Re: Htmlize support, maintenance, and Org mode

[Ihor Radchenko]

Philip Kaludercic  writes:

>> Nicolas once tried to port htmlize support into htmlfontify [1], but it
>> did not go well [2].
>>
>> [1] https://list.orgmode.org/orgmode/874lnw5rfi@nicolasgoaziou.fr/
>> [2] https://list.orgmode.org/orgmode/874ldzovv4@nicolasgoaziou.fr/
>
> How come you infer that it didn't go that well?  It just seems incomplete?

That's what I meant. The latest thread named some issue with fine-tuning
the output and never got any follow-up.

>> As for engrave-faces, it is working for both LaTeX and HTML export.
>
> Would that have the same issue has htmlize, that it copies the colours
> from the currently active theme, causing issues when exporting a website
> while a dark-theme is enabled?

No. It can copy the current theme, but it is not the default. Instead,
engrave-faces provides customization on how the faces should be
re-mapped. Defaults are tuned to work for usual white backgrounds, but
can be customized either using existing Emacs themes, or by hand,
mapping Emacs faces to text colors and attributes.

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

Re: Htmlize support, maintenance, and Org mode

[Philip Kaludercic]

Ihor Radchenko  writes:

> Philip Kaludercic  writes:
>
>>> We might consider extending engrave-faces to cover all the htmlize
>>> features.
>>
>> Perhaps I missed something, but is there an issue with the built-in
>> `htmlfontify'?
>
> Org uses htmlize historically.
> Nicolas once tried to port htmlize support into htmlfontify [1], but it
> did not go well [2].
>
> [1] https://list.orgmode.org/orgmode/874lnw5rfi@nicolasgoaziou.fr/
> [2] https://list.orgmode.org/orgmode/874ldzovv4@nicolasgoaziou.fr/

How come you infer that it didn't go that well?  It just seems incomplete?

> As for engrave-faces, it is working for both LaTeX and HTML export.

Would that have the same issue has htmlize, that it copies the colours
from the currently active theme, causing issues when exporting a website
while a dark-theme is enabled?

Re: Htmlize support, maintenance, and Org mode

[Ihor Radchenko]

Philip Kaludercic  writes:

>> We might consider extending engrave-faces to cover all the htmlize
>> features.
>
> Perhaps I missed something, but is there an issue with the built-in
> `htmlfontify'?

Org uses htmlize historically.
Nicolas once tried to port htmlize support into htmlfontify [1], but it
did not go well [2].

[1] https://list.orgmode.org/orgmode/874lnw5rfi@nicolasgoaziou.fr/
[2] https://list.orgmode.org/orgmode/874ldzovv4@nicolasgoaziou.fr/

As for engrave-faces, it is working for both LaTeX and HTML export.

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

Re: Htmlize support, maintenance, and Org mode

[Philip Kaludercic]

Ihor Radchenko  writes:

> Jonas Bernoulli  writes:
>
>> `htmlize' is currently maintained at https://github.com/hniksic/emacs-htmlize
>> but its maintainer hasn't been responding to any issues and pull-requests
>> for quite some time now and seems to be inactive on Github altogether.
>
> Hmm... Org has built-in htmlize support and I did not know that it is
> not maintained actively.
>
> Note that Timothy wrote https://github.com/tecosaur/engrave-faces that
> provides similar functionality but not just for HTML.
>
> We might consider extending engrave-faces to cover all the htmlize
> features.

Perhaps I missed something, but is there an issue with the built-in
`htmlfontify'?

Re: Htmlize support, maintenance, and Org mode (was: [MAINTENANCE] Org orphanage?)

[Ihor Radchenko]

Jonas Bernoulli  writes:

>> Hmm... Org has built-in htmlize support and I did not know that it is
>> not maintained actively.
>
> I only installed htmlize because org-html-fontify-code told me to do so.
> Should it not have done that?  I did not have any version of htmlize
> installed prior to this.

That's fine to install htmlize. Org relies upon htmlize for certain
features, including HTML export.

However, we also recently added engrave-faces for LaTeX export. And
engrave-faces is advertised as successor to htmlize. So, we might
consider (in future) to offer engrave-faces as another option to export
HTML as well. (This idea has nothing to do with helping to maintain
htmlize - it will be relevant for a long time at least for users of
older Org versions, even if we decide to use engrave-faces instead of
htmlize).

>> Or we can simply hand-pick that 13 open Github issues and transfer them
>> manually. (Does not mean that we have to do it, but I see not why having
>> a few issues on Github should be a blocker to anything)
>
> The idea was to let those who have already opened pull-requests on
> Github and have been patiently waiting for a response ever since, to
> finish the work there.

Good point. Although all the pull requests appear to be rather trivial
from the first glance. Let's see if Hrvoje has anything to say.

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

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Fraga, Eric]

I'll chime in regarding inlinetasks: I used to use these *a lot* but I
found that drawers do what I needed in almost all cases very
effectively (for my use cases).

I have no strong feelings therefore with respect to either of the
aspects being discussed.
-- 
: Eric S Fraga, with org release_9.6.7-635-gf9e083 in Emacs 30.0.50

Re: [PATCH] org.el: Respect org-extend-today-until in timestamps with ++

[Ihor Radchenko]

"Valentin G. J. Herrmann"  writes:

> Ok, so I guess I was stupid in another way :E
> I do in fact have the FSF copyright assignment (Though probably under an 
> old email address: herr.valentin.m...@gmail.com). I still included the 
> TINYCHANGE comment. The attached patch should finally work.

Bastien, may you please check the FSF records?

> -   (string-match-p
> -"2014-03-04 .* 02:00"
> +   (string-search
> +"<2014-03-04 Tue 02:00 +8h>"

This won't work for people testing in non-English language environments
where the day names are in native language.
.* was there for a reason.

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

[Ihor Radchenko]

Bastien Guerry  writes:

> Here is another suggestion:
>
> 1) Remove the option and make adding the dup link on top the default.
>
> (1) is because removing this option would be a breaking change, and
> inflincting a new option to every user to deal with a hypothetical
> use-case does not seem right.
>

See the attached tentative patch.

> 2) Also remove the current C-u C-u C-u arg and make it the default
>when a region is active.
> ...
> (2) should be done anyway.

I studied this further and what you suggest will interfere with
`org-link-context-for-files'. It will no longer be possible to select
text very long
and multi-line link description, M-x org-store-link, and get
the selected text as stored link description.

The current default of using active region as description makes more
sense, IMHO.

>From 7d8ed8f767c632bbb94f236fd08ee31e0d573e39 Mon Sep 17 00:00:00 2001
Message-ID: <7d8ed8f767c632bbb94f236fd08ee31e0d573e39.1692010108.git.yanta...@posteo.net>
From: Ihor Radchenko 
Date: Mon, 14 Aug 2023 13:39:47 +0300
Subject: [PATCH] org-store-link: Never allow link duplicates in
 `org-stored-links'

* lisp/ol.el (org-link-store-existing): Remove the previously added
custom option.
(org-store-link): Do not use `org-link-store-existing' removing all
the code branches for values other than 'move-to-front.
* etc/ORG-NEWS (~org-store-link~ now moves an already stored link to
front of the ~org-stored-links~): Remove reference to the removed
custom option.

Link: https://orgmode.org/list/87leeffd1z.fsf@localhost
---
 etc/ORG-NEWS |  6 --
 lisp/ol.el   | 37 +++--
 2 files changed, 11 insertions(+), 32 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 1dc0a4519..6169dacf9 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -31,12 +31,6 @@ Now, ~org-store-link~ moves the stored link to front of the list of
 stored links.  This way, the link will show up first in the completion
 and when inserting all the stored links with ~org-insert-all-links~.
 
-The new behavior is controlled by new customization ~org-link-store-existing~.
-
-Users can set ~org-link-store-existing~ to nil to revert previous
-defaults.  The value of =store-duplicate= will force duplicate links
-in ~org-stored-links~.  The default value is =move-to-front=.
-
 *** Major changes and additions to Org API
  New term: "syntax node"
 
diff --git a/lisp/ol.el b/lisp/ol.el
index 3a8ca5f39..20aab6bb8 100644
--- a/lisp/ol.el
+++ b/lisp/ol.el
@@ -509,20 +509,6 @@ (defcustom org-link-keep-stored-after-insertion nil
   :type 'boolean
   :safe #'booleanp)
 
-(defcustom org-link-store-existing 'move-to-front
-  "Variable controlling how to deal with already stored links.
-When nil, ignore store request for an already stored link.
-When symbol `move-to-front', move the stored link to the front of
-`org-stored-links'.
-When symbol `store-duplicate', add a duplicate in front."
-  :group 'org-link-store
-  :type '(choice
-  (const :tag "Do no store duplicate" nil)
-  (const :tag "Move stored duplicate to front" move-to-front)
-  (const :tag "Store duplicate" store-duplicate))
-  :safe #'symbolp
-  :package-version '(Org . "9.7"))
-
 ;;; Public variables
 
 (defconst org-target-regexp (let ((border "[^<>\n\r \t]"))
@@ -1764,18 +1750,17 @@ (defun org-store-link (arg  interactive?)
   (if (not (and interactive? link))
 	  (or agenda-link (and link (org-link-make-string link desc)))
 (dotimes (_ (if custom-id 2 1)) ; Store 2 links when CUSTOM-ID is non-nil.
-  (pcase org-link-store-existing
-((or `store-duplicate
- (guard (not (member (list link desc) org-stored-links
- (push (list link desc) org-stored-links)
-	 (message "Stored: %s" (or desc link)))
-((or`nil (guard (equal (list link desc) (car org-stored-links
- (message "This link has already been stored"))
-(`move-to-front
- (setq org-stored-links
-   (delete (list link desc) org-stored-links))
- (push (list link desc) org-stored-links)
- (message "Link moved to front: %s" (or desc link
+  (cond
+   ((not (member (list link desc) org-stored-links))
+(push (list link desc) org-stored-links)
+	(message "Stored: %s" (or desc link)))
+   ((equal (list link desc) (car org-stored-links))
+(message "This link has already been stored"))
+   (t
+(setq org-stored-links
+  (delete (list link desc) org-stored-links))
+(push (list link desc) org-stored-links)
+(message "Link moved to front: %s" (or desc link
 	  (when custom-id
 	(setq link (concat "file:"
 			   (abbreviate-file-name
-- 
2.41.0


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

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

Samuel Wales  writes:

> regexp components docstring in bugfix still say reload or restart.
> biut mayube that is obsolete.

`org-emphasis-regexp-components'? It is no longer a defcustom - you are
not supposed to change it.

> i found possible examples in appt and ediff bot those are not org.  so
> perhaps this is a case where the problem no longer exists?  8if so,
> then never mind that comment about guideline for not requiring setting
> before org where possible.
>
> perhaps these are unavoidable.

> bugfix .el
> g set *.el|g before|g load
> org-fold-core.el:Important: This variable must be set before loading Org."

It is `org-fold-core-style' - must be set before opening file because it
switches between two implementations of folding.
You usually don't need to touch it.

> org-keys.el:Needs to be set before Org is loaded.

`org-mouse-1-follows-link' simply triggers adding/not adding one binding
to `org-mouse-map'. Actually, `org-tab-follows-link' is the same.

These variables are mostly used to avoid forcing users put

(org-defkey org-mouse-map [follow-link] 'mouse-face)
or (org-defkey org-mouse-map (kbd "TAB") #'org-open-at-point)
into their config.

We may alternatively use custom :set function for these variables. That
will not require a restart.

> org-list.el:This variable needs to be set before org.el is loaded.  If you
> org-list.el:This variable needs to be set before org.el is loaded.  If you

`org-plain-list-ordered-item-terminator' and `org-list-allow-alphabetical'
configure Org parser. We should probably remove these variables
eventually. To standardize Org syntax.

> org-persist.el:This variable must be set before loading org-persist library.")

`org-persist--disable-when-emacs-Q' is an internal variable used for debugging.

> org.el:This variable needs to be set before org.el is loaded.  If you

This is `org-export-backends' that literally controls Org loading.
Technically, you don't need to re-load Org here if you set it via
customize interface.

> org.el:This variable needs to be set before org.el is loaded, and you need to

`org-enforce-todo-checkbox-dependencies'. Again, no need to reload Org
if you use customize interface. In both this and previous cases,
docstring explains about customize.

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

[Ihor Radchenko]

Samuel Wales  writes:

> i currently want to copy a link location and then paste that link
> loadtion.  i don't recall theis breaking before.  it does now.

Please provide more details. (https://orgmode.org/manual/Feedback.html#Feedback)
Otherwise, it is very hard to figure out what exactly you are referring to.

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

Re: Passing table to Ruby session

[Ihor Radchenko]

Mike Gauland  writes:

> I've redefined org-babel-ruby-var-to-ruby in my init.el to add a newline 
> after each element in an array, which I think will work for anything 
> less than a 4k-long string. Ideally, the hard-coded \n would follow the 
> EOL convention of the buffer, but I haven't gotten that far yet.
>
>
> (defun org-babel-ruby-var-to-ruby (var)
>    "Convert VAR into a ruby variable.
> Convert an elisp value into a string of ruby source code
> specifying a variable of the same value."
>    (if (listp var)
>    (concat "[" (mapconcat #'org-babel-ruby-var-to-ruby var ", \n") "]")

I think Emacs should handle it automatically.

Also, it looks like ruby sessions are broken now:

#+begin_src ruby :session org-test-ruby :results output
s = "1"
s = "2"
s = "3"
puts s
s = "4"
#+end_src

yields nothing.

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

Re: [BUG] inline src blocks in caption of not-inline src blocks do not execute

[Tom Gillespie]

> org-element-at-point is not supposed to return objects. So, there is no
> problem here.

Right. My original issue description is wrong for this part. It seems that
org-babel-get-src-block-info returns nil when immediately before the start
of the ala |src_ in #+caption: but will return non-nil in other contexts. In
the #+caption: it will only work if the cursor is past the s ala s|rc_. Or
if in non evil mode when the cursor is on the s in src_.

I can workaround the issue for now with forward-char, but it seems there
is an off-by-one error involving #+caption: followed immediately by src_,
if there is anything in between #+caption: and src_ then it works correctly.

> Also, C-c C-c works for me on bugfix in the above example.

Hrm, I can't get it to work, but I haven't done a proper control that
loads only bugfix and nothing else. Will report back if I get it to work.

Re: [BUG] make cursor visible in calendar [9.6.7 ( @ /Users/eugenekim/.emacs.d/elpa/org-9.6.7/)]

[Ihor Radchenko]

eugene kim  writes:

> I found the offending line (windmove-default-keybindings)
> From below configuration, if I move the (windmove-default-keybindings)
> line, it works fine.
> Thank you for the support
>
> -
> (windmove-default-keybindings)
>
>
> (use-package org
>   :ensure t
>   :init
>   (progn
> (add-hook 'org-shiftup-final-hook 'windmove-up)
> (add-hook 'org-shiftleft-final-hook 'windmove-left)
> (add-hook 'org-shiftdown-final-hook 'windmove-down)
> (add-hook 'org-shiftright-final-hook 'windmove-right)
>
> )
>   )
> 

Closing.
Handled.

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

Re: [BUG] make cursor visible in calendar [9.6.7 ( @ /Users/eugenekim/.emacs.d/elpa/org-9.6.7/)]

[Ihor Radchenko]

[ Please use Reply All or Wide Reply to keep the conversation public on
  the mailing list ]

eugene kim  writes:

> my `emacs` was aliased as `emacs -nw` and was not accepting -Q
>
> So the situation is
>
> In terminal (with -nw), cursor shows
> In Window (without -nw)
>  - (with -Q) cursor shows
>  - (without -Q) cursor not shows
>
> I guess some package that gets evaluated only in windows env has
> interfering.. ?..

Most likely. You can try https://github.com/Malabarba/elisp-bug-hunter
to narrow does which part of the config is to blame.

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

Re: [BUG] inline src blocks in caption of not-inline src blocks do not execute

[Ihor Radchenko]

Tom Gillespie  writes:

> This one fails to work with C-c C-c, and org-element-at-point returns
> the bash src block below.
>
> #+caption: src_elisp[:results drawer]{"I've made a horrible mistake"}
> #+begin_src bash
> echo OH NO
> #+end_src

org-element-at-point is not supposed to return objects. So, there is no
problem here.

Also, C-c C-c works for me on bugfix in the above example.

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

Re: [BUG] make cursor visible in calendar [9.6.7 ( @ /Users/eugenekim/.emacs.d/elpa/org-9.6.7/)]

[Ihor Radchenko]

eugene kim  writes:

> I've followed the instruction, nothing i can do further from the feedback
> instructions
> because there's no bug and there's no traceback
>
> I find the cursor is visible in terminal emacs, but not in window
> environment emacs.
> You might wanna try that.

I tried, and can see the cursor in my window Emacs.
May you please start from emacs -Q and detail every step you do + what
you see?

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

[BUG] inline src blocks in caption of not-inline src blocks do not execute

[Tom Gillespie]

I've found a bug where inline source blocks cannot be executed and
org-element cannot find/parse them if they are in #+captions: where
the caption is affiliated with a not-inline source block. Example
below. Best,
Tom

Issue present in:
Org mode version 9.6.6 (release_9.6.6 @ /usr/share/emacs/29.1/lisp/org/)
GNU Emacs 29.1 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version
1.17.8) of 2023-08-0

This inline src block works with C-c C-c.

#+caption: src_elisp[:results drawer]{"All good!"} {{{results(All good!)}}}
[[file:./images/happy-figure.png]]

This one fails to work with C-c C-c, and org-element-at-point returns
the bash src block below.

#+caption: src_elisp[:results drawer]{"I've made a horrible mistake"}
#+begin_src bash
echo OH NO
#+end_src

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Tom Gillespie]

> Same here, I'd be tempted to deny Org citizenship to inline tasks: it
> always felt like a nice hack for a niche use-case, but a hack anyway.
>
> If it modifies Org syntax in surprising ways, this is another argument
> for removing org-inlinetask.el from Org's core.  Remember: this is not
> to say that inline tasks are forbidden, it's just a message for users
> that inline tasks are something not maintained by Org's core team.
>
> > And it is not clear how to fix this. We did not make inlinetasks into
> > standard Org syntax in the past and now it is in the weird state when we
> > have (featurep 'org-inlinetask) sprinkled across the code just to
> > accommodate for this conditional syntax.
>
> Yes, this is ugly.
>
> > Inlinetasks are too similar in syntax with headlines, so it is
> > impossible to make the change backwards-compatible.

Chiming in here to say that inline tasks make it exceptionally annoying
to specify a sane grammar for org because they require putting a special
case in the headline tokenizer, and/or making it possible to toggle the
behavior of the tokenizer.

As such I strongly support removing them from any official status in
the name of simplifying the syntax (among other things).

Re: [BUG] make cursor visible in calendar [9.6.7 ( @ /Users/eugenekim/.emacs.d/elpa/org-9.6.7/)]

[Ihor Radchenko]

eugene kim  writes:

> That's not what I see.

Then, please follow https://orgmode.org/manual/Feedback.html#Feedback to
help me re-create your problem locally.

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

Re: [BUG] make cursor visible in calendar [9.6.7 ( @ /Users/eugenekim/.emacs.d/elpa/org-9.6.7/)]

[Ihor Radchenko]

[Adding Org ML back to CC]

eugene kim  writes:

> I should have been more clear.
> The selected date (the preselected date is visible) is visible.
>
> I'd like to use the keyboard to move dates so I can select a different
> date.
> While moving between dates, the cursor is not visible.

When I use S- and other commands described in "8.2.1 The
date/time prompt" section of the manual, whatever was "preselected"
moves as I change the date.

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