Re: [PATCH v4] [BUG] org-attach-id-ts-folder-format fails on customized IDs [9.6 (9.6-??-2e9999783)]

[Ihor Radchenko]

Max Nikulin  writes:

>> The new version of the patch allows all but first function return nil.
>> See the attached.
>> 
>> Let me know if there are any other objections.
>
> Ihor, sorry that I left your earlier questions with no response. I hope, 
> the attached diff may illustrate my ideas better. I have not tried to 
> run it though, so it can be full of stupid mistakes. I suggest to ignore 
> nil values completely, but maybe I missed some use case.

AFAIU, your version of `org-attach-dir-from-id' may sometimes return
nil, which is neither documented nor expected by the callers.

In particular, `org-attach-dir-get-create' will throw unhelpful "No
attachment directory is associated with the current node" error.

`org-attach-dir' appears to handle nil return value fine.

I will be happy to merge a proper patch upon addressing possible
pitfalls. I do not feel strongly about my variant vs. yours.

> Actually I suspect the if the `org-attach-dir-from-id' function returned 
> both first and existing directories, the code of callers would be
> clearer.

`org-attach-dir-from-id' is a public function, and we cannot change its
return signature drastically without breaking backwards compatibility.
If we do want to change the return value, the current function name
should be obsoleted and an alternative function should be introduced.

I do not feel like the benefits are strong enough to justify such a
drastic measure. `org-attach-dir-from-id' is only used in two places in
Org code - I see no clear benefit of returning multiple paths.

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: `org-fill-paragraph' (`M-q') in Org Mode source blocks

[Ihor Radchenko]

Sébastien Miquel  writes:

> Ihor Radchenko writes:
>> See the attached.
>> I am not sure if we really need the variable.
>> AFAIU, acting natively was the default in the past for M-q with no
>> region selection. Then, I "fixed" some bug report in 05ee1e6ee06db and
>> introduced the bug herein.
>
> You're right, I had not realised org-fill-element already acted natively.
>
> Your patch looks and tests good to me.

Thanks for checking.
Applied onto main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=2c8bd0cc9b914b4dcc11e337faedbabe195097fb

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Fixed.

Re: org-table: deleting columns not always actualise the formulas.

[Ihor Radchenko]

Eric S Fraga  writes:

>> But as you can see @3$17 only gets changed to @3$16 but not to @3$8 as
>> it should be.
>
> Confirmed.

Fixed.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=ceb99b86006f9a10a772860c72dd473cb15a72aa

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: [BUG] org-table: deleting columns not always actualise the formulas. [9.4.6 (release_9.4.6-541-g52b097 @ /home/oub/emacs/site-lisp/packages/org/)]

[Ihor Radchenko]

Uwe Brauer  writes:

> But as you can see @3$17 only gets changed to @3$16 but not to @3$8 as
> it should be.

Thanks for reporting, and sorry for the late reply.
Fixed on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=ceb99b86006f9a10a772860c72dd473cb15a72aa

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: Get current table row data as list

[Ihor Radchenko]

Felix Dorner  writes:

> Is there a helper or another way so that I can get the elements of that row
> as a list or do I have to extract the fields manually by walking over text?

`org-element-context'.
See https://orgmode.org/worg/dev/org-element-api.html

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: Call code block via link?

[Ihor Radchenko]

Felix Dorner  writes:

>>  [[elisp:(some elisp sexp)][Click here to do X]]
>>
>> Neat! When I open the link I always get a message each time, "Execute ...
> as elisp?" Is there a way to get rid of that message?

See https://orgmode.org/manual/Code-Evaluation-Security.html

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: [PATCH] "Cache corruption detected" when editing CLOCK timestamp by hand

[Ihor Radchenko]

Ihor Radchenko  writes:

>> Should we consider the above CLOCK line as a valid running clock or
>> maybe it should be parsed as a paragraph?
>
> I am still leaving this question open despite applying the above patch.
> At least, we need to get the bug fixed.

I now made Org parse malformed CLOCK lines as paragraphs.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=e305755b1a7ac41c74ebf9a39e8b9d547acb523d

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: Get current table row data as list

[Felix Dorner]

Okay I found org-table-get (line column), which is already very helpful.

On Wed, Oct 5, 2022 at 6:17 AM Felix Dorner  wrote:

> When point is in a table, I can run (org-element-at-point) and get a
> table-row:
>
> table-row (:type standard :begin 4932 :end 5151 :contents-begin 4933
> :contents-end 5150 :post-blank 0 :post-affiliated 4932 :parent (table
> (:begin 4546 :end 6818 :type org :tblfm nil :contents-begin 4562
> :contents-end 6816 :value nil :post-blank 2 :post-affiliated 4562 :name
> secrets :parent nil
>
> Is there a helper or another way so that I can get the elements of that
> row as a list or do I have to extract the fields manually by walking over
> text?
>
> Thanks,
> Felix
>
>

-- 
Linux. The choice of a GNU generation.

Get current table row data as list

[Felix Dorner]

When point is in a table, I can run (org-element-at-point) and get a
table-row:

table-row (:type standard :begin 4932 :end 5151 :contents-begin 4933
:contents-end 5150 :post-blank 0 :post-affiliated 4932 :parent (table
(:begin 4546 :end 6818 :type org :tblfm nil :contents-begin 4562
:contents-end 6816 :value nil :post-blank 2 :post-affiliated 4562 :name
secrets :parent nil

Is there a helper or another way so that I can get the elements of that row
as a list or do I have to extract the fields manually by walking over text?

Thanks,
Felix

Re: Call code block via link?

[Felix Dorner]

Eric,

>
>  [[elisp:(some elisp sexp)][Click here to do X]]
>
> Neat! When I open the link I always get a message each time, "Execute ...
as elisp?" Is there a way to get rid of that message?


-- 
Linux. The choice of a GNU generation.

[org-export] Linking inlinetasks (was: BUG?: Link to inline-task not working)

[Ihor Radchenko]

Ihor Radchenko  writes:

> Michael Dauer  writes:
>
>> Shouldn't be org-export-resolve-fuzzy-link the relevant function, at least
>> for my use case?
>>
>> But there it looks like it is searching through all elements including
>> inlinetasks, which is in org-element-all-elements:
>> (append pseudo-types '(target) org-element-all-elements)
>
> Maybe. Further it also calls org-export-search-cells, which does not
> consider inlinetasks even if they are matched.

I have investigated further.
In addition to inlinetasks not being taken into account by
`org-export-search-cells', `org-export-resolve-fuzzy-link', and
`org-export-resolve-id-link', there is no export backend support for
linking inlinetasks.

In order to have full support for inlinetasks during export, we need to
modify export backends to be able to link to the inlinetasks.

For example,
- ox-html.el does not associate ID anchor in
  `org-html-format-inlinetask-default-function'
- ox-latex.el also does not provide any label in
  `org-latex-format-inlinetask-default-function'
- ox-ascii.el does not assign a number to be referred to in
  `org-ascii-format-inlinetask-default'

I did not check other backends.

Note that changing only ox.el without altering the individual backends
can break export in unexpected ways.

I am attaching a simple patch changing the generic link resolution
machinery. If one applies the patch, **export will be broken**.
In particular, exporting to ASCII (C-c C-e t U) will straight throw
an error.

The same may happen in third-party export backends even if we alter the
all built-in export backends appropriately.

Thus, supporting links to inlinetasks will be a breaking change and such
support should be shielded behind a user customization, not be enabled
by default.

>From c6737633b12b8f9de1a240b2f32f52d54e1c14a1 Mon Sep 17 00:00:00 2001
Message-Id: 
From: Ihor Radchenko 
Date: Wed, 5 Oct 2022 11:17:55 +0800
Subject: [PATCH] lisp/ox.el: Allow links to inlinetasks

* lisp/ox.el (org-export-search-cells):
(org-export-resolve-fuzzy-link):
(org-export-resolve-id-link): Resolve links to inlinetasks.

**This is not a proper commit**
Applying it will not make inlinetask links work during export.
Backend-specific support will be required.
---
 lisp/ox.el | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/lisp/ox.el b/lisp/ox.el
index 51145acaa..6090d1ecd 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -4313,7 +4313,7 @@ (defun org-export-search-cells (datum)
 A search cell is the internal representation of a fuzzy link.  It
 ignores white spaces and statistics cookies, if applicable."
   (pcase (org-element-type datum)
-(`headline
+((or `headline `inlinetask)
  (let ((title (split-string
 		   (replace-regexp-in-string
 		"\\[[0-9]*\\(?:%\\|/[0-9]*\\)\\]" " "
@@ -4408,7 +4408,8 @@ (defun org-export-resolve-fuzzy-link (link info  pseudo-types)
 	 ;; Matching both a name and a target is not valid, and
 	 ;; therefore undefined.
 	 (or (cl-some (lambda (datum)
-			(and (not (eq (org-element-type datum) 'headline))
+			(and (not (memq (org-element-type datum)
+  '(headline inlinetask)))
 			 datum))
 		  matches)
 	 (car matches))
@@ -4428,7 +4429,7 @@ (defun org-export-resolve-id-link (link info)
  (let ((table (make-hash-table :test #'equal)))
(org-element-map
(plist-get info :parse-tree)
-   'headline
+   '(headline inlinetask)
  (lambda (headline)
(let ((id (org-element-property :ID headline))
  (custom-id (org-element-property :CUSTOM_ID headline)))
-- 
2.35.1



-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: [PATCH] lisp/org-agenda.el: Fix filter preset problem for sticky agenda

[Ihor Radchenko]

Liu Hui  writes:

>  I have signed the FSF
> copyright assignment paper.

Bastien, could you please confirm the FSF records?

> This patch fixes the bug originally reported in
> https://list.orgmode.org/59e02fb6.1462370a.fffe8.5...@mx.google.com/
> with the following reproducing recipe. The bug still exists in latest
> org-mode.
> ...
>
> Because the filter presets are stored as symbol properties, they
> cannot be used with multiple sticky agenda buffers. The patch fixes
> the problem by adding a new variable `org-agenda-filters-preset' for
> getting and setting per-buffer filter presets. I have signed the FSF
> copyright assignment paper.

Thanks a lot for the contribution!

> Subject: [PATCH] lisp/org-agenda.el: Fix filter preset problem for sticky
>  agenda

The patch is generally good. I just have one minor comment and one
suggestion.

> +(defvar org-agenda-filters-preset nil
> +  "Preset of filters, which becomes buffer-local in org-agenda buffers.")

Can you detail the value format in the docstring?
It would also be useful to mention `org-agenda-local-vars'. Otherwise,
the reader might be confused how `defvar' is buffer-local.

Also, may you create a test for the reported bug in
testing/lisp/test-org-agenda.el?

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: [HELP] Fwd: Org format as a new standard source format for GNU manuals

[Juan Manuel Macías]

Ihor Radchenko writes:

> If I were to choose an alternative symbol other than "_", I'd choose
> "@":
>
> @name{}
> @name{{ @name[:key value ...]{}
>
> 1. It is similar to Texinfo
> 2. It does not clash with TeX
> 3. We already use @ in the inline export snippets.

I like the "@" alternative a lot. And I agree with all three points. It is
also compact without losing clarity, and does not give the feeling of a
blank space before, as in the case of "_".

Best regards,

Juan Manuel 

Re: Explicit page breaks

[Juan Manuel Macías]

Ihor Radchenko writes:

> May we introduce a new standard macro {{{page-break(backend)}}}
> that will expand to an appropriate
> @@backend: ?

The macro seems like a good idea. The only (minor) inconvenience that I
see, if I have understood it correctly, is in the case of LaTeX, where
there are several commands that do different things: \pagebreak,
\clearpage, \newpage, etc.

Since \pagebreak is a more low-level command (introduces a hard break),
it could be left as the default command \clearpage, which starts a new
page and ends the old one. I don't know...

By the way, in LaTeX there is also the opposite of \pagebreak:
\nopagebreak, with a mandatory level from 1 to 4. I see this type of
commands more useful for defining new LaTeX commands than for inserting
them directly into the document.

And, in any case, I think this page break topic is most useful
especially for odt, which only has a hard break (and also splits the
paragraph in two if added inside the paragraph). For LaTeX, after all,
putting things like @@latex:\pagrebreak[2]@@ doesn't involve much
verbosity.

Anyway, the opendocument schema is completely arcane to me. I have taken
a look at the Org Manual and it says that this snippet adds a page break
in odt export:

#+odt:

But I have tried:

foo

#+odt:

bar

and the document is not exported with the page break. I don't know if
I'm missing something. But as i said, XML is beyond me :-).

Best regards,

Juan Manuel 

Re: Org and Hyperbole

[David Masterson]

Robert Weiner  writes:

> We welcome brief summaries of features you need for effective note
> taking in Emacs.  We are not looking to do much with images or on
> mobile devices, just focused on people who spend a lot of time in
> Emacs and want an easy-to-use notes system that does not require any
> external packages like SQLite.

One major use-case for Org is capturing a task quickly.  This can be
done with Org or Mobile-Org (BeOrg, Orgzly).  One feature not easily
available is attaching images to the task to better explain the task.

Thoughts on this?

-- 
David Masterson

Re: Support for tagging (special) blocks

[Sébastien Miquel]

Hi,

Ihor Radchenko writes:

Thanks for the clarification!
I did not mean to reduce the font size in affiliated keywords.
I was referring to replacing the display of affiliated keywords:

#+name: A classic
#+tag: easy

will be displayed by Emacs as

#+... A classic :easy:

The underlying text will not be changed.
The hidden parts will be revealed upon cursor entering the affiliated
keywords.


Perhaps something like
#+... name: A classic tag: easy
might be used for any kind of keyword. That'd be quite the trick.

It would certainly improve the situation when an element has several
keywords, but I'm not sure how common that is.

I'll look into implementing such #+name and #+tag keywords, when I
have the time.

On an unrelated note, how is your work on revamping org's
fontification going, if I may ask ? I had had a look at your repo, but
since adapting my configuration would have required some effort I did
not try it.

--
Sébastien Miquel

Re: [HELP] Fwd: Org format as a new standard source format for GNU manuals

[Max Nikulin]

It seems I completely failed trying to express my idea.

Instead of extending Org grammar (syntax), I suggest to change behavior 
of source blocks during export. In addition to current :results options, 
"ast" may be added. Its effect is that instead of adding text to export 
buffer that is parsed as Org markup, it causes insertion of a branch of 
syntax tree into original parse results. I admit, during export it may 
be necessary to iterate over source blocks one more time at a later stage.


Such source blocks should return "Org Syntax Tree", a simplified variant 
of org-element. It allows to change implementation details and e.g. to 
use vectors instead of lists for attributes in org-element. A converter 
from Org Syntax Tree to org-element should be implemented.


Certainly such format may be used directly as src_ost{(code (:class var) 
"language")} inline snippets or as


#+begin_src ost
  (code nil ("libtree-{sitter}-"
 (code (:class var) "\"language\"")
 "."
 (code (:class var) "ext")))
#+end_src

block-level elements. However I expect that it is the last resort option 
when there is no way to express desired construct in some other way.


I think, more convenient org-babel backends may be created to parse 
TeX-like (texinfo-like) or SGML-like (XML-like) syntax into Org Syntax 
Tree hierarchy. The essential idea is that outside of source blocks 
usual lightweight markup is used. Source blocks however have just a few 
special characters ([\{}], [@{}], or [&<>], etc.) to reduce issues with 
escaping for regular text or verbatim-like commands.


Some comments are inline.

On 03/10/2022 11:36, Ihor Radchenko wrote:

Max Nikulin writes:


On 02/10/2022 11:59, Ihor Radchenko wrote:

If you are asking how to represent such construct without introducing
custom elements then (it may be e.g. :type, not :class) parsed AST
should be like

  (code nil ("libtree-{sitter}-"
 (code (:class var) "\"language\"")
 "."
 (code (:class var) "ext")))


This is not much different from @name[nil]{} idea, but
more verbose.


> Also, more importantly, I strongly dislike the need to wrap the text
> into "". You will have to escape \". And it will force third-party
> parsers to re-implement Elisp sexp reader.

By this example I was trying to show how to express @var, @samp, @file 
without introducing of new custom objects. I do not see any problem with 
verbosity of such format, it may be used for really special cases only, 
while some more convenient markup is used for more simple cases.



If there was some syntax for object attributes then simple cases would
be like

  [[attr:(:class var)]]~language~


I do not like this idea. It will require non-trivial changes in Org
parser and fontification.

Using dedicated object properties or at least inheriting properties from
:parent is the style we employ more commonly across the code:

@var{language}
or
@code[:class var]{language}
or
@attr[:class var]{~language~}


I do not mind to have some "span" object to assign attributes to its 
direct children. I used link-like prefix object just because a proof of 
concept may be tried with no changes in Org. It does not require support 
of nested objects. There is no existing syntax for such "span" objects, 
but perhaps it is not necessary and source blocks should be used instead 
for special needs.



I have no idea concerning particular markup that can be used inside
source blocks. It might be LaTeX-like commands as discussed in the
sibling subthread or HTML (XML) based syntax that is more verbose than
TeX-like notation.

  By convention, the dynamic library
  for src_alt{\code[class=var]{language}} is
  
src_alt{\code{libtree-\{sitter\}-\code[class=var]{"language"}.\code[class=var]{ext}}},

  where src_alt{\code[class=var]{ext}} is the
  system-specific extension for dynamic libraries.


I am against the idea of LaTeX-like commands. It will clash with
latex-fragment object type.
https://orgmode.org/worg/dev/org-syntax.html#LaTeX_Fragments


or

  By convention, the dynamic library for
  src_alt{language} is
  src_alt{libtree-{sitter}-"language".ext},
  where src_alt{ext} is the
  system-specific extension for dynamic libraries.


This style will indeed make things easier for the parser. But I find it
too verbose for practical usage. This is why I instead proposed the idea
with variable number of brackets: @code{{can have } inside}}.


Texinfo is TeX with \ replaced by @. Just another character has the 
category starting command. The important point is that while Org markup 
uses a lot of special characters (*/_+[]...) this flexible markup should 
use just a few ones. I do not see any obstacles to try texinfo-like 
markup. Source blocks allow to have several languages.



Hypothetical "alt" babel language has default :results ast :export
results header arguments to inject AST bypassing Org markup stage.


The 

Re: `org-fill-paragraph' (`M-q') in Org Mode source blocks

[Sébastien Miquel]

Ihor Radchenko writes:

See the attached.
I am not sure if we really need the variable.
AFAIU, acting natively was the default in the past for M-q with no
region selection. Then, I "fixed" some bug report in 05ee1e6ee06db and
introduced the bug herein.


You're right, I had not realised org-fill-element already acted natively.

Your patch looks and tests good to me.

--
Sébastien Miquel

Re: [PATCH v4] [BUG] org-attach-id-ts-folder-format fails on customized IDs [9.6 (9.6-??-2e9999783)]

[Max Nikulin]

On 02/10/2022 16:14, Ihor Radchenko wrote:

Ihor Radchenko writes:

Max Nikulin writes:


The new version of the patch allows all but first function return nil.
See the attached.

Let me know if there are any other objections.


Ihor, sorry that I left your earlier questions with no response. I hope, 
the attached diff may illustrate my ideas better. I have not tried to 
run it though, so it can be full of stupid mistakes. I suggest to ignore 
nil values completely, but maybe I missed some use case.


Actually I suspect the if the `org-attach-dir-from-id' function returned 
both first and existing directories, the code of callers would be clearer.diff --git a/lisp/org-attach.el b/lisp/org-attach.el
index 8509a6564..c4d043fb9 100644
--- a/lisp/org-attach.el
+++ b/lisp/org-attach.el
@@ -163,18 +163,27 @@ When set to `query', ask the user instead."
   "Translate an UUID ID into a folder-path.
 Default format for how Org translates ID properties to a path for
 attachments.  Useful if ID is generated with UUID."
-  (format "%s/%s"
-	  (substring id 0 2)
-	  (substring id 2)))
+  (and (< 2 (length id))
+   (format "%s/%s"
+   (substring id 0 2)
+   (substring id 2
 
 (defun org-attach-id-ts-folder-format (id)
   "Translate an ID based on a timestamp to a folder-path.
 Useful way of translation if ID is generated based on ISO8601
 timestamp.  Splits the attachment folder hierarchy into
 year-month, the rest."
-  (format "%s/%s"
-	  (substring id 0 6)
-	  (substring id 6)))
+  (and (< 6 (length id))
+   (format "%s/%s"
+   (substring id 0 6)
+   (substring id 6
+
+(defun org-attach-id-fallback-folder-format (id)
+  "May be added last to `org-attach-id-path-function-list'.
+A fallback as \"__/ID\" directory for the case when user
+changed ID value to a string too short for `org-attach-id-ts-folder-format'
+and other functions."
+  (format "__/%s" id))
 
 (defcustom org-attach-id-to-path-function-list '(org-attach-id-uuid-folder-format
 		 org-attach-id-ts-folder-format)
@@ -182,7 +191,18 @@ year-month, the rest."
 The first function in this list defines the preferred function
 which will be used when creating new attachment folders.  All
 functions of this list will be tried when looking for existing
-attachment folders based on ID."
+attachment folders based on ID.
+
+Add `org-attach-id-fallback-folder-format' to the end if you edit
+IDs to short value, but you can not implement a better variant of
+layout.  Consider something like the following as first element instead
+
+(defun my/attach-id-custom-folder-format (id)
+ (unless
+  (or (string-match-p \"[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}\" id)
+  (string-match-p \"[0-9]{8}T[0-9]{6}\\.[0-9]{6}\" id))
+  (format \"important/%s/%s\" (substring id 0 1) (substring id 1
+"
   :group 'org-attach
   :package-version '(Org . "9.3")
   :type '(repeat (function :tag "Function with ID as input")))
@@ -384,7 +404,8 @@ If the attachment by some reason cannot be created an error will be raised."
 	 ((eq org-attach-preferred-new-method 'nil)
 	  (error "No existing directory.  DIR or ID property has to be explicitly created")
 (unless attach-dir
-  (error "No attachment directory is associated with the current node"))
+  (error "No attachment directory is associated with the current node, \
+adjust `org-attach-id-to-path-function-list'"))
 (unless (file-directory-p attach-dir)
   (make-directory attach-dir t))
 attach-dir))
@@ -393,23 +414,22 @@ If the attachment by some reason cannot be created an error will be raised."
   "Return a folder path based on `org-attach-id-dir' and ID.
 If TRY-ALL is non-nil, try all id-to-path functions in
 `org-attach-id-to-path-function-list' and return the first path
-that exist in the filesystem, or the first one if none exist.
-Otherwise only use the first function in that list."
-  (let ((attach-dir-preferred (expand-file-name
-			   (funcall (car org-attach-id-to-path-function-list) id)
-			   (expand-file-name org-attach-id-dir
-(if try-all
-	(let ((attach-dir attach-dir-preferred)
-	  (fun-list (cdr org-attach-id-to-path-function-list)))
-	  (while (and fun-list (not (file-directory-p attach-dir)))
-	(setq attach-dir (expand-file-name
-			  (funcall (car fun-list) id)
-			  (expand-file-name org-attach-id-dir)))
-	(setq fun-list (cdr fun-list)))
-	  (if (file-directory-p attach-dir)
-	  attach-dir
-	attach-dir-preferred))
-  attach-dir-preferred)))
+that exist in the filesystem, otherwise independently of TRY-ALL
+value return the first non nil value."
+  (let ((fun-list org-attach-id-to-path-function-list)
+(base-dir (expand-file-name org-attach-id-dir))
+preferred first)
+(while (and fun-list
+(not preferred))
+  (let* ((name (funcall (car fun-list) id))
+ (candidate (and name (expand-file-name name 

Re: Post-process table without changing result for empty table(/list)

[Jonas Bernoulli]

Ihor Radchenko  writes:

> Jonas Bernoulli  writes:
>
>> It used to behave like that before 51a628bc5efc from 2009, which started
>> turning all symbols, including nil, into strings, but without giving any
>> reason why that should be done.
>>
>> It has worked like this for a long time now, so reverting that is
>> probably not feasible in the short run.  However, I feel it would
>> make sense to change now how nil/'() is treated.  Currently it is
>> being treated as the symbol nil, but IMO it would make more sense
>> to treat it as the empty list.  That could be achieved with
>>
>> diff --git a/lisp/ob-ref.el b/lisp/ob-ref.el
>> index b79e47900..2b4a16aea 100644
>> --- a/lisp/ob-ref.el
>> +++ b/lisp/ob-ref.el
>> @@ -199,7 +199,7 @@ (defun org-babel-ref-resolve (ref)
>> (org-babel-execute-src-block nil info 
>> params
>>  (error "Reference `%s' not found in this buffer" ref
>>  (cond
>> - ((symbolp result) (format "%S" result))
>> + ((and result (symbolp result)) (format "%S" result))
>>   ((and index (listp result))
>>(org-babel-ref-index-list index result))
>>   (t result)
>
> Looks reasonable.
> Could you please prepare a patch and possibly also add a test that
> covers your use-case to testing/lisp/test-ob.el?
> See https://orgmode.org/worg/org-contribute.html

Will do.

>> In the long run you might want to consider not turning any symbols
>> into strings, at least not when the "regular" block as well as the
>> post-processing block both use elisp.
>
> This may be tricky. Introducing any kind of special case will make the
> code fragile. We should better make things as generic as possible.

By "special case", do you mean "just for elisp", or "if both use the
same language, whatever that might be"?  IMO it would be best if as much
information were preserved between the two code blocks, and when they
use the same language, that should be "all of it", or nearly.

If they use the same language that might be fairly easy to do (bypass
the code that previously prevented it), but of course it would be
preferable if all type information were preserved between any two block.

But that would be harder, which is why I would suggest to first/only do
it if the same language is used by both blocks.  The actual suggestion
to do it only if both block use elisp, was more about first trying it
with the language we are most familiar with.  I wasn't trying to imply
it should only be done for that language.  Of course, if initially only
doing for elisp actually makes it harder, then doing it for all
languages at once, would be preferable.

---

Speaking of other languages, when I investigated the above issue, I
tried whether the issue was maybe limited to post-processing blocks that
use elisp.  So I also tried doing it using python, but it turned out
that that had the same issue, and additionally there was a somewhat
related, python specific, bug:

`org-babel-script-escape' doesn't handle an empty python list correctly:
  "['a']" => ("a")
but
  "[]"=> []
I.e., an empty python list is turned into an empty lisp vector instead
of an empty lisp list.  At least for python, (> (length str) 2) should
probably be changed to use >=.

---

And while reproducing that issue just now, I ran into an additional,
unrelated issue.  I didn't have python installed and when I tried to
evaluate a python block directly, that resulted in an error as expected.
However, when I evaluated a elisp block, which uses a post-processing
block that uses python, that failed silently.

Re: [PATCH] Fix org-comment-line-break-function

[Ihor Radchenko]

Richard Lawrence  writes:

>> I am attaching an alternative patch to fix the issue using Org element
>> parser. Note that I reused your tests.
>
> FWIW I've tested this patch for a few days and it fixes the issue for
> me. I'd be happy if it were merged.

Thanks for testing.
Applied onto main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=506d5b12ddbb319f0f70593cda54d8d9c580db7b

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

Fixed.
Applied.

Re: Habit tracking (add "DONE" state with configurable date/time)

[Angel de Vicente]

Ihor Radchenko  writes:

> org-todo-yesterday

:-) fantastic. Not configurable but certainly enough for my purposes. 

Many thanks,
-- 
Ángel de Vicente
 Research Software Engineer (Supercomputing and BigData)
 Instituto de Astrofísica de Canarias (https://www.iac.es/en)

Re: Habit tracking (add "DONE" state with configurable date/time)

[Ihor Radchenko]

Angel de Vicente  writes:

> I'm lately finding myself in this situation: I have a number of habits
> that I track, and I want to mark one of them to "DONE", but registering
> not the date when I change its state, but some other date/time (this
> usually happens, for example, with my "sports" habit, which I do late at
> night, so it is only next day when I turn on the computer that I can
> change its state, but I want to register the state change date/time as
> that of the previous day).
>
> I thought that `C-u C-c C-t' might do this, but that apparently lets me
> change the state but not the date.
>
> Any ideas? Thanks

org-todo-yesterday

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

Re: Numbered footnotes in the manual interfere with diff

[Bastien]

Ihor Radchenko  writes:

> Done.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=0641ece57b9d980b63e3a3bb6dc4d467eff3051b
>
> I also documented this in doc/Documentation_Standards.org

Great, thank you.

>>> Also, there is one footnote that is indexed (does it even work?):
>>
>> AFACT it does not work and I think it should not work, we can remove
>> these index entries.
>
> Instead of removing, I moved the entries to the footnote reference.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=180966c645547bf8e0f78ea28d63a686a286d2b2

Even better, thanks.

-- 
 Bastien

Re: [PATCH 2-v4] New: auto display inline images under subtree when `org-cycle'.

[Christopher M. Miles]

Ihor Radchenko  writes:

> "Christopher M. Miles"  writes:
>
>> I think the patch is finished. Please review, Ihor. Thanks for helping.
>
> Thanks for the update!
> I have cleaned the manual and ORG-NEWS wordings.
>
> Upon reading the exported version of the manual, I realized that the
> part in 2.2.1 Global and local cycling section sounds very awkward and
> that we do not mention other cycle hooks like hiding archived
> subtrees there. So, I decided to remove it.
>
> I also rewrote the other part in a bit more direct tone and moved the
> index entry.
>
> (In general, it is useful to try reading the exported version of the
> manual with the additions to check if things are still coherent - manual
> is not just a collection of independent statements; we need to make sure
> that it is not confusing the new readers).
>
> I also updated the commit message adding the CHANGELOG entries about the
> manual and ORG-NEWS.
>

It's OK.

> I am attaching the updated version of the patch with my amendments.

Applied your updated patch.

> However, upon testing your patch, tests are still failing on my side.
> Can you please investigate?

But If I use [M-x ert] to run the test 
"test-org-fold/org-fold-display-inline-images" is passed.
Here is the steps:
1. [M-x load-file RET /path/to/org-mode/testing/org-test.el RET]
2. [C-M-x] to evaluate the target test
3. [M-x ert RET test-org-fold/org-fold-display-inline-images RET] to run this 
test

I attached the uploaded screencast video link to prove it passed.

https://share.cleanshot.com/tvUUoQ

I tried many different other API functions to cycle or fold/unfold, but none
of them works under command "make test" or command
"make BTEST_RE="test-org-fold/org-fold-display-inline-images" test-dirty".

I have nothing brain to think for this test now. Really can't figure out
why this image is not displayed as overlay. Can you help me to fix this test?

#+begin_src emacs-lisp
(ert-deftest test-org-fold/org-fold-display-inline-images ()
  "Test inline images displaying when cycling."
  (let* ((org-cycle-inline-images-display t)
 (images-dir (expand-file-name "examples/images/" org-test-dir))
 (org-logo-image (expand-file-name "Org mode logo mono-color.png" 
images-dir)))
;; `org-cycle' -(state)-> `'children' display child inline images.
(org-test-with-temp-text
(format "* Heading 1
[[file:%s]]
" org-logo-image)
  (org-overview)
  (org-cycle)
  ;; (org-cycle-internal-local)
  ;; (run-hook-with-args 'org-cycle-hook 'children)
  ;; (org-cycle-display-inline-images 'children)
  (org-next-link)
  ;; (should org-inline-image-overlays)
  (should (overlays-at (point)))
  (org-toggle-inline-images)
  (should-not (overlays-at (point

;; `org-cycle' -(state)-> `'subtree' display subtrees inline images.
(org-test-with-temp-text
(format "* Heading 1
[[file:%s]]
** Subheading 1
[[file:%s]]
** Subheading 2
[[file:%s]]" org-logo-image org-logo-image org-logo-image)
  (org-overview)
  (org-cycle)
  (org-cycle)
  ;; (org-cycle-internal-global)
  ;; (run-hook-with-args 'org-cycle-hook 'subtree)
  (org-next-link)
  (org-next-link)
  ;; (should org-inline-image-overlays)
  (should (overlays-at (point)))
  (org-toggle-inline-images)
  (should-not (overlays-at (point

;; `org-cycle' -(state)-> `'folded' remove inline image overlays.
(org-test-with-temp-text
(format "* Heading 1
[[file:%s]]
** Subheading 1
[[file:%s]]
** Subheading 2
[[file:%s]]" org-logo-image org-logo-image org-logo-image)
  (org-overview)
  (org-show-subtree)
  (org-fold-subtree t)
  (run-hook-with-args 'org-cycle-hook 'folded)
  (should (null org-inline-image-overlays))
  (should (null (overlays-in (point-min) (point-max
  (org-show-subtree)
  (should-not org-inline-image-overlays)
  (should-not (overlays-in (point-min) (point-max))
#+end_src

-- 

[ stardiviner ]
I try to make every word tell the meaning that I want to express without 
misunderstanding.

Blog: https://stardiviner.github.io/
IRC(libera.chat, freenode): stardiviner, Matrix: stardiviner
GPG: F09F650D7D674819892591401B5DF1C95AE89AC3


signature.asc
Description: PGP signature

Re: [BUG] Re: when ellipsis are "removed", org-cycle doesn't work "correctly" on list

[Ihor Radchenko]

Ihor Radchenko  writes:

> The bug is triggered by incorrect result of org-list-struct.
> In org-list-struct with the above invisibility settings,
> current-indentation incorrectly returns 0 on "a", "b", and "c" items. I
> suspect Emacs bug.

After discussion with Emacs devs [1], I have found where the problem is
coming from. `current-indentation' used by Org parser returns the
_visible_ indentation and has undefined behaviour when the line is
invisible. This undefined behaviour worked in older versions of Emacs,
but not newer.

Fixed.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=9db57aee3e86dc47771840d21a19dc2e21e52299

[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=56837

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

Re: Org and Hyperbole

[Payas Relekar]

Robert Weiner  writes:

> Thanks, Jean.  We have started work on a note-taking subsystem for
> Hyperbole that will store UUIDs per note and will likely support backlinks
> too.  We are seeing if we can make it support Koutlines, Emacs Outlines,
> Org mode files and Markdown files, searching across all formats at the same
> time.  The default for creating new notes will likely be a personal
> Koutline file.

Not Jean, but as someone using Org with Hyperbole, this is a great news!

> We welcome brief summaries of features you need for effective note taking
> in Emacs.  We are not looking to do much with images or on mobile devices,
> just focused on people who spend a lot of time in Emacs and want an
> easy-to-use notes system that does not require any external packages like
> SQLite.

For my 2c:

- Multiple small files vs single large file.
  I currently have former, with org-roam taking care of finding, linking
  and backlinking between files, making it a non-issue to easily build a
  network of connected topics/thoughts

- Daily notes
  Every day gets its own note, only generated if visited. This allows
  dumping the thoughts at that moment rather than first hunting the
  correct node. Then they can be easily filtered into actual topic note,
  or just be referenced via backlinks buffer

- sqlite might just be better, considering overhead of opening and
  parsing hundreds-thousands of small files is non-negligible.

- Refiling
  Refile/move the subtree (in Org terms) can be easily moved to another
  file and the links automatically point to new location. This means I
  can always know rearranging stuff later is a possibility, and its less
  cognitive burden to organize.

In short, the framework takes care of organization and makes retrieval
easy and all I have to worry about is the content.

Thanks,
Payas

--

Re: Org mode links: Open a PDF file at a given page and highlight a given string

[Ihor Radchenko]

Rodrigo Morales  writes:

> Debugger entered--Lisp error: (wrong-type-argument stringp nil)

I can no longer reproduce on the latest main.
Closing the bug report.

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

Fixed.

Re: Org and Hyperbole

[Robert Weiner]

Another good thought.  Anyone can add an embeddable export of Koutlines; I
don't think we'll find time to do that in the mainline development branch
though.

On Tue, Sep 27, 2022 at 10:45 AM Jean Louis  wrote:

> * Robert Weiner  [2022-06-25 23:52]:
> > 2. We have not yet integrated org-export with the Koutliner but want
> > to.  You can convert a Koutline to a star outline and call it an Org
> > file, so it wouldn’t be too hard.  It has its own builtin export to
> > HTML from which you could get to pdf as well, I imagine.
>
> Kotl should not depend of the HTML template.
>
> Kotl shall have possible export without headers, and styles. It would
> be best if style is built in the lines, and not part of the 
> section.
>
> That way kotl would be embeddable in various HTML templates.
>
> --
> Jean
>
> Take action in Free Software Foundation campaigns:
> https://www.fsf.org/campaigns
>
> In support of Richard M. Stallman
> https://stallmansupport.org/
>

Re: Org and Hyperbole

[Robert Weiner]

Thanks, Jean.  We have started work on a note-taking subsystem for
Hyperbole that will store UUIDs per note and will likely support backlinks
too.  We are seeing if we can make it support Koutlines, Emacs Outlines,
Org mode files and Markdown files, searching across all formats at the same
time.  The default for creating new notes will likely be a personal
Koutline file.

We welcome brief summaries of features you need for effective note taking
in Emacs.  We are not looking to do much with images or on mobile devices,
just focused on people who spend a lot of time in Emacs and want an
easy-to-use notes system that does not require any external packages like
SQLite.


On Tue, Sep 27, 2022 at 10:00 AM Jean Louis  wrote:

> * Robert Weiner  [2022-06-24 12:53]:
> > Hyperbole does not have bi-directional links, only a history
> > function to move back through followed node paths.  We have started
> > thinking about this need recently.
>
> If at all it is useful.
>
> As you know I am using database backed Dynamic Knowledge Repository
> Hyperscope. It has hyobjects table, and there is hyobjectrelations
> table that keeps track of related hyobjects.
>
> The workflow to record back links for any document is following:
>
> - all links have to be stored somewhere, so that they get their
>   reference; with Emacs 29 and built-in SQLite database that could be
>   one way to go. Other way is to keep stored values in files, and have
>   for each link some UUID or similar.
>
> - there must be table of relations or file containing relations, in
>   such file one would record the file name where link was inserted,
>   and the link's UUID;
>
> - functions to insert links in any lightweight markup file would need
>   to be rewritten so that they:
>
>   1. Verify that link has got its reference, UUID or some other
>  reference. That can work automatically. If I am inserting
>  hyperlink such as "ABC" to file "/tmp/my-file.txt" with line
>  number 3, then as soon as I have decided it, the function would
>  insert it into the tracking file or database table;
>
>   2. Function would also remember that file "/tmp/my-file.txt" has go
>  the link "ABC", and would at least try to remember its line
>  number or surrounding text. This information would be stored in
>  backlinks file or backlinks table;
>
> By using the above principle one could record backlinks, both in Org
> mode or any other mode.
>
> --
> Jean
>
> Take action in Free Software Foundation campaigns:
> https://www.fsf.org/campaigns
>
> In support of Richard M. Stallman
> https://stallmansupport.org/
>

Habit tracking (add "DONE" state with configurable date/time)

[Angel de Vicente]

Hello,

I'm lately finding myself in this situation: I have a number of habits
that I track, and I want to mark one of them to "DONE", but registering
not the date when I change its state, but some other date/time (this
usually happens, for example, with my "sports" habit, which I do late at
night, so it is only next day when I turn on the computer that I can
change its state, but I want to register the state change date/time as
that of the previous day).

I thought that `C-u C-c C-t' might do this, but that apparently lets me
change the state but not the date.

Any ideas? Thanks
-- 
Ángel de Vicente
 Research Software Engineer (Supercomputing and BigData)
 Instituto de Astrofísica de Canarias (https://www.iac.es/en)