Fwd: [BUG] text-property displayed image has a center-line when the text face has underline attribute

[Christopher M. Miles]

Ihor Radchenko  writes:

> "Christopher M. Miles"  writes:
>
>> I replaced step 5 with step 6 by extracting the logic code of
>> org-link-beautify, but I found it does not have center-line. That's
>> really weird.
>> ...
>>(put-text-property
>> start end
>> 'display (create-image 
>> "~/Downloads/.thumbnails/3veEPJrQrV1EtpH9.png" nil nil :ascent 'center 
>> :max-height 512))
>>(make-local-variable 'image-map)
>>(define-key image-map (kbd "") 'org-open-at-point))
>>  #+end_src
>
> On my side, the put-text-property does have center-line.
> But only when buffer is in Org mode.
> Yet, it is not Org's fault.
>
> The reason you are seeing the horizontal line is org-link face.
> org-link has underline. And the "center" line you are seeing is actually
> underline coming from the face. I'd say it is emacs bug.

Thanks very much for figuring out this issue, Ihor.

I see, I originally post this issue on Emacs-help mailing list, Eli let
me forward this thread to Org mode mailing list. Now I need to forward
to Emacs-devel mailing list.

In case the background info is missing, link original message here:

https://list.orgmode.org/87mtae2718.fsf@localhost/T/#m35d40f37fdf80f413ddb8d40e3017a6f102651e9

-- 

[ 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: Code block syntax highlighting in async export

[Ihor Radchenko]

David Lukeš  writes:

> I get different syntax highlighting in code blocks when using async
> export: no colors, just bold, italics and underlines. Is this expected,
> and if so, is there maybe an easy fix I just don’t know about?

Could you please provide an example?
See https://orgmode.org/manual/Feedback.html

> I found a similar problem in [batch export], but the workaround seems
> relatively complicated and brittle.

That is likely a different problem. In batch mode, Emacs disabled
font-lock-mode unconditionally, which makes fontification in some major
modes broken.

-- 
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] ox-odt: Prevent auto-formatting in export buffers

[Ihor Radchenko]

David Lukes  writes:

> * lisp/ox-odt.el (org-odt-template, org-odt--export-wrap):
> `write-region' instead of `save-buffer'.

Let us know when you manage to get the FSF assignment.

-- 
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] Unit-test for Please add support for dlangs packagemanager to ob-C.el

[Ihor Radchenko]

Max Nikulin  writes:

> I am unsure concerning general policy related to org-babel test, so the 
> following is rather discussion than a direct request to change the test.
>
> Is there a way to avoid dependency on remote resources? My concern is 
> test results affected by network issues. In addition, more required 3rd 
> party tools means less probability that a developer after modification 
> of generic babel code noticed that the changes break D backend because 
> missing tool on the development machine. I have no idea how much efforts 
> is required to create a mock for isolated environment.

Tests must not rely on remote resources.
However, it does not mean that we cannot test remote resources in Org
tests. One simply needs to mock the url-retrieve or whatever function is
used to retrieve remove resource.

> Another point is that missed dub binary is not reflected in test report. 
> If `skip-unless' feature of ert is available in Emacs-26 then it should 
> be used.

The current approach to optional binaries is throwing
'missing-test-dependency error when the binary is not available.

-- 
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: Fwd: [BUG] text-property displayed image has a center-line when the text face has underline attribute

[Eli Zaretskii]

> From: "Christopher M. Miles" 
> Cc: "Christopher M. Miles" , Org Mode
>  
> Date: Sun, 02 Oct 2022 15:03:26 +0800
> 
> Ihor Radchenko  writes:
> 
> > "Christopher M. Miles"  writes:
> >
> >> I replaced step 5 with step 6 by extracting the logic code of
> >> org-link-beautify, but I found it does not have center-line. That's
> >> really weird.
> >> ...
> >>(put-text-property
> >> start end
> >> 'display (create-image 
> >> "~/Downloads/.thumbnails/3veEPJrQrV1EtpH9.png" nil nil :ascent 'center 
> >> :max-height 512))
> >>(make-local-variable 'image-map)
> >>(define-key image-map (kbd "") 'org-open-at-point))
> >>  #+end_src
> >
> > On my side, the put-text-property does have center-line.
> > But only when buffer is in Org mode.
> > Yet, it is not Org's fault.
> >
> > The reason you are seeing the horizontal line is org-link face.
> > org-link has underline. And the "center" line you are seeing is actually
> > underline coming from the face. I'd say it is emacs bug.
> 
> Thanks very much for figuring out this issue, Ihor.
> 
> I see, I originally post this issue on Emacs-help mailing list, Eli let
> me forward this thread to Org mode mailing list. Now I need to forward
> to Emacs-devel mailing list.
> 
> In case the background info is missing, link original message here:
> 
> https://list.orgmode.org/87mtae2718.fsf@localhost/T/#m35d40f37fdf80f413ddb8d40e3017a6f102651e9

Please report this as a bug, with "M-x report-emacs-bug", and please
include there all the details, including the recipe to reproduce the
issue.

Thanks.

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

[Ihor Radchenko]

Ihor Radchenko  writes:

> Max Nikulin  writes:
>
>>> I do not think that it is a good idea. We currently promise to use the
>>> first function in the list to generate the IDs. Other functions are
>>> mostly a fallback to catch the existing attach dirs created in the past
>>> using different ID scheme.
>>
>> My idea is to add an extra check that filters out nil values. I do not 
>> mind to signal a user error if first entry from 
>> `org-attach-id-to-path-function-list' returns nil and paths returned by 
>> other function do not exist.
>
> This would be possible, in addition to the patch above.
> Or do you mean the default ts/uuid format functions to return nil to
> short IDs as well?

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.

>From ac88b8ac1117007eca49a0b229d8cee6cba8bc87 Mon Sep 17 00:00:00 2001
Message-Id: 
From: Ihor Radchenko 
Date: Sat, 23 Jul 2022 13:13:24 +0800
Subject: [PATCH v4] org-attach-dir-from-id: Do not rely on ID being over 6
 chars long

* lisp/org-attach.el (org-attach-id-uuid-folder-format): Fall back to
"__/ID" when the ID contains 2 chars or less and cannot be split into
the "xy/z" path.
(org-attach-id-ts-folder-format): Fall back to "__/ID" path format
when the ID contains less than 7 chars and cannot be split into the
"MM/rest" path.

(org-attach-dir-from-id): Allow all but first function return nil and
be ignored.
(org-attach-id-to-path-function-list): Document that all but first
function can return nil.

Fixes https://orgmode.org/list/KC8PcypJapBpJQtJxM0kX5N7Z0THL2Lq6EQjBMzpw1-vgQf72egZ2JOIlTbPYiqAVD4MdSBhrhBZr2Ykf5DN1mocm1ANvvuKKZShlkgzKYM=@pm.me
---
 lisp/org-attach.el | 43 ++-
 1 file changed, 30 insertions(+), 13 deletions(-)

diff --git a/lisp/org-attach.el b/lisp/org-attach.el
index 8509a6564..e4511794f 100644
--- a/lisp/org-attach.el
+++ b/lisp/org-attach.el
@@ -162,19 +162,27 @@ (defcustom org-attach-archive-delete nil
 (defun org-attach-id-uuid-folder-format (id)
   "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)))
+attachments.  Useful if ID is generated with UUID.
+
+When ID is too short (less than 3 chars), return \"__/ID\"."
+  (if (< (length id) 3)
+  (format "__/%s" 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)))
+year-month, the rest.
+
+When ID is too short (less than 7 chars), return \"__/ID\"."
+  (if (< (length id) 7)
+  (format "__/%s" id)
+(format "%s/%s"
+	(substring id 0 6)
+	(substring id 6
 
 (defcustom org-attach-id-to-path-function-list '(org-attach-id-uuid-folder-format
 		 org-attach-id-ts-folder-format)
@@ -182,7 +190,12 @@ (defcustom org-attach-id-to-path-function-list '(org-attach-id-uuid-folder-forma
 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.
+
+The functions must either return string or nil.  If a function returns
+nil, its return value will be ignored when looking for existing
+attachment folders.  The first function in the list must always return
+string."
   :group 'org-attach
   :package-version '(Org . "9.3")
   :type '(repeat (function :tag "Function with ID as input")))
@@ -400,11 +413,15 @@ (defun org-attach-dir-from-id (id  &optional try-all)
 			   (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)))
+	  (fun-list (cdr org-attach-id-to-path-function-list))
+  rtn)
 	  (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 rtn (funcall (car fun-list) id))
+;; Skip nil return values.
+(when rtn
+	  (setq attach-dir (expand-file-name
+			rtn
+			(expand-file-name org-attach-id-dir
 	(setq fun-list (cdr fun-list)))
 	  (if (file-directory-p attach-dir)
 	  attach-dir
-- 
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

[HELP] Help implementing org-lint/warnings buffer during export (was: Org HTML export accessibility (was: org exported pdf files))

[Ihor Radchenko]

Tim Cross  writes:

> From an org-mode perspective, the key things which need to be maintained
> (and which perhaps we could make even easier or possibly have
> 'defaults') is the ability to add the alt attribute to any non-text
> element. For example, images, videos, sound files etc. All such content
> should always have some text describing the 'element'. However, it is
> also important to be able to not have an alt tag in some situations (for
> example, when using images as 'spacers' for formatting etc, we don't
> want an alt tag. Things to be aware of are things like using single
> characters or symbols (e.g. < and > for previous/next) or using unicode
> and other symbols whose meaning/purpose may seem very obvious when
> viewed, but is less so when 'spoken'. 
>
> From an authoring perspective, it probably would be good if org mode was
> able to alert the user to content which lacks an alt attribute but which
> probably should have one e.g. an image with no caption, a link to a
> video/audio file etc.

This sounds like a good idea.

Org currently attempts to be slightly helpful by indicating, for
example, LaTeX compilation warnings. However, it is just done by writing
a simple message in the echo area.

What would be more useful is the kind of buffer displayed by org-lint,
but instead used during export:
- If there are any export issues (LaTeX errors/warnings) they can appear
  in the buffer
- If there are any stylistic issues (like lack of alt attributes during
  html export), they can also appear

Ideally, we should be able to jump directly to the line containing
error.

org-lint code could be used as a base, but otherwise we need to
implement something generic way to check style/export warnings on
per-backend basis.

This is probably something we need to do before we dive into the
accessibility specifics. AFAIU from the Tim's reply, many of the
accessibility guidelines may need to be decided by the document author.
Tim, let me know if I am wrong and some of the accessible tagging must
be done unconditionally.

I am marking this as a help request.

Let me know what you think.

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

[Fraga, Eric]

Hello all,

I like the idea of inline special blocks.  Given that we have recently
introduced [cite:...] as new syntax, could we generalise this and allow
any xxx in [xxx:...]?

With this, the example Max gave from texinfo:

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

could look like

   By convention, the dynamic library for [var:language] is
   [code:libtree-{sitter}-[var:"language"].[var:ext]], where [var:ext]
   is the system-specific extension for dynamic libraries.

noting the recursive embedded syntax.  (and not knowing texinfo, I've
assumed that @{ and @} are escapes for the braces but could be something
else.)

Obviously, this would be a breaking change for any documents that
actually had anything along the lines of [xxx:...] in their text.

Just musing out loud. ;-) And procrastinating from preparing my lectures
for tomorrow... Feel free to ignore of course.

eric
-- 
: Eric S Fraga, with org release_9.5.5-851-ge9781f in Emacs 29.0.50

[CLOSED] text-property displayed image has a center-line when the text face has underline attribute

[Christopher M. Miles]

I hate to rewrite those steps more than 3 times. But I also know Emacs
contributors should not be forced to fix bug for me. Also I can't fix
this bug by myself. So I think it's not a bug, I can tolerate this
center line. Maybe I mastered skill for modify code in Emacs, I might
come back to fix this bug by myself. But now, let me close it. I'm not
hating anybody, just hate this process. Thanks for checking out.

Eli Zaretskii  writes:

>> From: "Christopher M. Miles" 
>> Cc: "Christopher M. Miles" , Org Mode
>>  
>> Date: Sun, 02 Oct 2022 15:03:26 +0800
>> 
>> Ihor Radchenko  writes:
>> 
>> > "Christopher M. Miles"  writes:
>> >
>> >> I replaced step 5 with step 6 by extracting the logic code of
>> >> org-link-beautify, but I found it does not have center-line. That's
>> >> really weird.
>> >> ...
>> >>(put-text-property
>> >> start end
>> >> 'display (create-image 
>> >> "~/Downloads/.thumbnails/3veEPJrQrV1EtpH9.png" nil nil :ascent 'center 
>> >> :max-height 512))
>> >>(make-local-variable 'image-map)
>> >>(define-key image-map (kbd "") 'org-open-at-point))
>> >>  #+end_src
>> >
>> > On my side, the put-text-property does have center-line.
>> > But only when buffer is in Org mode.
>> > Yet, it is not Org's fault.
>> >
>> > The reason you are seeing the horizontal line is org-link face.
>> > org-link has underline. And the "center" line you are seeing is actually
>> > underline coming from the face. I'd say it is emacs bug.
>> 
>> Thanks very much for figuring out this issue, Ihor.
>> 
>> I see, I originally post this issue on Emacs-help mailing list, Eli let
>> me forward this thread to Org mode mailing list. Now I need to forward
>> to Emacs-devel mailing list.
>> 
>> In case the background info is missing, link original message here:
>> 
>> https://list.orgmode.org/87mtae2718.fsf@localhost/T/#m35d40f37fdf80f413ddb8d40e3017a6f102651e9
>
> Please report this as a bug, with "M-x report-emacs-bug", and please
> include there all the details, including the recipe to reproduce the
> issue.
>
> Thanks.


-- 

[ 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: [CLOSED] text-property displayed image has a center-line when the text face has underline attribute

[Ihor Radchenko]

On Sun, Oct 2, 2022 at 6:51 PM Christopher M. Miles 
wrote:

>
> I hate to rewrite those steps more than 3 times. But I also know Emacs
> contributors should not be forced to fix bug for me. Also I can't fix
> this bug by myself. So I think it's not a bug, I can tolerate this
> center line. Maybe I mastered skill for modify code in Emacs, I might
> come back to fix this bug by myself. But now, let me close it. I'm not
> hating anybody, just hate this process. Thanks for checking out.
>
> Come on.

1. find an image file in your system
2. emacs -Q
3. M-: (erase-buffer)
4. Insert "askdjaklsdj lasasd"
5. M-: (require 'org)
6. M-x font-lock-mode
7. M-: (put-text-property (point-min) (point-max) 'face 'org-link)
8.  M-: (put-text-property (point-min) (point-max) 'display (create-image
"/path/to/image" nil nil :ascent 'center :max-height 512))

Re: Apology [

[Fraga, Eric]

Dear Tim,

thank you very much for the long email.  It is very helpful, at least
for me, to have a much better understanding of accessibility issues.

And, by the way, I did not think you had been overly negative and
definitely no apology was required.

take care,
eric

-- 
: Eric S Fraga, with org release_9.5.5-851-ge9781f in Emacs 29.0.50

Re: [CLOSED] text-property displayed image has a center-line when the text face has underline attribute

[Eli Zaretskii]

> From: "Christopher M. Miles" 
> Cc: numbch...@gmail.com, yanta...@gmail.com, emacs-de...@gnu.org,
>  emacs-orgmode@gnu.org
> Date: Sun, 02 Oct 2022 18:45:41 +0800
> 
> I hate to rewrite those steps more than 3 times.

The problem is, I've read the correspondence on the Org list, and I
still don't understand what are the steps needed, that don't require
the extra Org package.  That is why I( asked for the details: so that
the bug tracker could have them clearly and unambiguously.

I do want to look into the issue and see if there's anything that
needs to be fixed in Emacs.

> But I also know Emacs
> contributors should not be forced to fix bug for me. Also I can't fix
> this bug by myself. So I think it's not a bug, I can tolerate this
> center line. Maybe I mastered skill for modify code in Emacs, I might
> come back to fix this bug by myself. But now, let me close it. I'm not
> hating anybody, just hate this process. Thanks for checking out.

I'm sorry you feel like that.  Perhaps Ihor or someone else could fill
in the blanks and allow us to investigate.

Thanks.

Re: [CLOSED] text-property displayed image has a center-line when the text face has underline attribute

[Eli Zaretskii]

> From: Ihor Radchenko 
> Date: Sun, 2 Oct 2022 18:57:56 +0800
> Cc: Eli Zaretskii , emacs-de...@gnu.org, emacs-orgmode@gnu.org
> 
> 1. find an image file in your system
> 2. emacs -Q
> 3. M-: (erase-buffer)
> 4. Insert "askdjaklsdj lasasd"
> 5. M-: (require 'org)
> 6. M-x font-lock-mode
> 7. M-: (put-text-property (point-min) (point-max) 'face 'org-link)
> 8.  M-: (put-text-property (point-min) (point-max) 'display (create-image
> "/path/to/image" nil nil :ascent 'center :max-height 512))

Thanks.

This is because of the ":ascent 'center" part, isn't it?

What would you want Emacs to do instead in this case?

Re: [CLOSED] text-property displayed image has a center-line when the text face has underline attribute

[Ihor Radchenko]

>
> This is because of the ":ascent 'center" part, isn't it?
>
I guess so. The image bottom is below the text baseline and thus the
underline cuts through the image.


> What would you want Emacs to do instead in this case?
>

I do understand how Emacs renders what we get here from the perspective of
glyph composition. Putting underline over the glyph does make sense in many
cases. However, it is clearly not expected in this specific scenario of a
bitmap image.

I think that it could be useful to allow images to be drawn "on top" of the
underlines, cross-lines, etc.

Best,
Ihor

Re: Test email

[Timothy]

Hi me,

Testing a tweaked signature:

All the best,
Timothy

-- 
Timothy (`tecosaur'/`TEC'), Org mode contributor.
Learn more about Org mode at .
Support Org development at ,
or support my work at .

Re: Test email

[Timothy]

Hi Org ML folks,

As you may have guessed, I’m currently tweaking the email setup I have for
interacting with the Org ML, and the “testing” email is an accidental
consequence of that.

Clearly the “Automatically set `To:' on all emails to emacs-orgmode@gnu” hook 
has
to go 😓.

Hopefully this will be the last you (unintentionally, at least) hear about me
tweaking my email setup.

All the best,
Timothy

-- 
Timothy (`tecosaur'/`TEC'), Org mode contributor.
Learn more about Org mode at .
Support Org development at ,
or support my work at .

Re: Code block syntax highlighting in async export

[Max Nikulin]

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

David Lukeš writes:


I get different syntax highlighting in code blocks when using async
export: no colors, just bold, italics and underlines. Is this expected,
and if so, is there maybe an easy fix I just don’t know about?


Could you please provide an example?
See https://orgmode.org/manual/Feedback.html


I found a similar problem in [batch export], but the workaround seems
relatively complicated and brittle.


That is likely a different problem. In batch mode, Emacs disabled
font-lock-mode unconditionally, which makes fontification in some major
modes broken.


Certainly more details is necessary, even export format (backend) is not 
specified.


A problem that has some similar symptoms:
M. Pger. Re: no syntax highlighting for code blocks with org-publish. 
Mon, 18 Jul 2022 22:55:15 +. 
https://list.orgmode.org/inTtQOKWAhnFydjBE9fQOOdo_oV6kIPG5_E0d8DsfFiYMIJ4RNLRk68Id6dyrzy1qIDK8YJu0Wty7objv22vR31PNrh-qB9vKxMgHPxNAu8=@protonmail.com

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

[Ihor Radchenko]

"Fraga, Eric"  writes:

> I like the idea of inline special blocks.  Given that we have recently
> introduced [cite:...] as new syntax, could we generalise this and allow
> any xxx in [xxx:...]?

This syntax will make it difficult to pass optional arguments, like in
@abbr{FSF, Free Software Foundation}. Also, escaping "]" will be tricky.

> With this, the example Max gave from texinfo:
>
>> By convention, the dynamic library for @var{language} is
>> @code{libtree-@{sitter@}-@var{"language"}.@var{ext}}, where @var{ext} is 
>> the
>> system-specific extension for dynamic libraries.
>
> could look like
>
>By convention, the dynamic library for [var:language] is
>[code:libtree-{sitter}-[var:"language"].[var:ext]], where [var:ext]
>is the system-specific extension for dynamic libraries.

I am thinking about something like

_name{}
_name{{}}  <--- extra {} is added as needed for escaping
_name[:key value ...]{}

The syntax idea is to follow the relevance between [[links]] and 
[cite:citations]
but here we have src_name[...]{...} and _name[...]{} instead.

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

We may even follow Max's idea about AST and make it so that
_bold{contents} will be parsed just like *contents*.

> noting the recursive embedded syntax.  (and not knowing texinfo, I've
> assumed that @{ and @} are escapes for the braces but could be something
> else.)

Yep, @{ and @} are the escaped { and } in Texinfo.

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

Re: Issue with export of inlinetasks

[Michael Dauer]

org-version reports the same version, but now the same code (posted before)
works. So it's fixed.

But shouldn't org-version report 9.5.5 instead of 9.5?

Ihor Radchenko  schrieb am Fr., 30. Sep. 2022, 10:22:

> Michael Dauer  writes:
>
> > This is the latest commit on main, isn't it?
> > Head: main fixup! org-fold-core: Respect 'ignore-indirect
> optimization
> > better
> > Merge:origin/main fixup! org-fold-core: Respect 'ignore-indirect
> > optimization better
> > Tag:  release_9.5.5 (852)
>
> Yes, it is.
>
> Org repo is at https://git.savannah.gnu.org/cgit/emacs/org-mode.git/
> Also referenced at https://orgmode.org/
>
> --
> 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

[Fraga, Eric]

On Sunday,  2 Oct 2022 at 21:02, Ihor Radchenko wrote:
>
> _name{}
> _name{{}}  <--- extra {} is added as needed for escaping
> _name[:key value ...]{}

I'd be okay with this as well.


-- 
: Eric S Fraga, with org release_9.5.5-851-ge9781f in Emacs 29.0.50

Re: [BUG] org-timer-start doesn't seem to take the timer string at point [9.5.5 (release_9.5.5 @ z:/emacs-i686/share/emacs/28.2/lisp/org/)]

[Ihor Radchenko]

Ypo  writes:

> In the manual, it says:
>
>> C-c C-x 0 (|org-timer-start|)
>>
>> ... If there is a timer string at point, this is taken as the
>> default, providing a convenient way to restart taking notes after
>> a break in the process...
>> https://orgmode.org/manual/Timers.html
>>
>
> I am trying it, but the timer starts at 0:00:00

You missed the previous sentence in the manual.

When called with a ‘C-u’ prefix, prompt the user for a starting
offset.  If there is a timer string at point, this is taken as the
default, ...

The value at point is only taken into account with prefix argument.

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

Re: [BUG] org-timer-start doesn't seem to take the timer string at point [9.5.5 (release_9.5.5 @ z:/emacs-i686/share/emacs/28.2/lisp/org/)]

[Ypo]

Oh! Thanks

I didn't understand. Maybe this would be more understandable?:


  When called with a ‘C-u’ prefix, prompt the user for a starting
 offset or, if there is a timer string at point, this is taken as the
 default, ...

Or:


  When called with a ‘C-u’ prefix, there are 2 options: prompt the user for a 
starting
 offset.  Or, if there is a timer string at point, this is taken as the
 default, ...



El 02/10/2022 a las 15:37, Ihor Radchenko escribió:

Ypo  writes:


In the manual, it says:


C-c C-x 0 (|org-timer-start|)

 ... If there is a timer string at point, this is taken as the
 default, providing a convenient way to restart taking notes after
 a break in the process...
 https://orgmode.org/manual/Timers.html


I am trying it, but the timer starts at 0:00:00

You missed the previous sentence in the manual.

 When called with a ‘C-u’ prefix, prompt the user for a starting
 offset.  If there is a timer string at point, this is taken as the
 default, ...

The value at point is only taken into account with prefix argument.

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

[Juan Manuel Macías]

Ihor Radchenko writes:

> _name{}
> _name{{}}  <--- extra {} is added as needed for escaping
> _name[:key value ...]{}
>
> The syntax idea is to follow the relevance between [[links]] and 
> [cite:citations]
> but here we have src_name[...]{...} and _name[...]{} instead.

And how about this:

%_name{}
%_name{{}}  <--- extra {} is added as needed for escaping
%_name[:key value ...]{}

or any other symbol instead of "%" ?

N.B.: I must admit this is more for an "aesthetic" reason. Although
perhaps it can be useful to search in the documents.

Best regards,

Juan Manuel

--
--
--
Juan Manuel Macías

https://juanmanuelmacias.com

https://lunotipia.juanmanuelmacias.com

https://gnutas.juanmanuelmacias.com

[BUG] org-timer-start doesn't seem to take the timer string at point [9.5.5 (release_9.5.5 @ z:/emacs-i686/share/emacs/28.2/lisp/org/)]

[Ypo]

In the manual, it says:


C-c C-x 0 (|org-timer-start|)

... If there is a timer string at point, this is taken as the
default, providing a convenient way to restart taking notes after
a break in the process...
https://orgmode.org/manual/Timers.html



I am trying it, but the timer starts at 0:00:00




Emacs  : GNU Emacs 28.2 (build 2, x86_64-w64-mingw32)
 of 2022-09-13
Package: Org mode version 9.5.5 (release_9.5.5 @ 
z:/emacs-i686/share/emacs/28.2/lisp/org/)


current state:
==
(setq
 org-link-elisp-confirm-function 'yes-or-no-p
 org-bibtex-headline-format-function #[257 "\300
\236A\207" [:title] 3 
"\n\n(fn ENTRY)"]

 org-export-before-parsing-hook '(org-attach-expand-links)
 org-archive-hook '(org-attach-archive-delete-maybe)
 org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
          org-cycle-show-empty-lines
          org-optimize-window-after-visibility-change)
 org-mode-hook '(#[0 "\300\301\302\303\304$\207"
           [add-hook change-major-mode-hook org-show-all append local]
           5]
         #[0 "\300\301\302\303\304$\207"
           [add-hook change-major-mode-hook org-babel-show-result-all
        append local]
           5]
         org-babel-result-hide-spec org-babel-hide-all-hashes)
 org-confirm-shell-link-function 'yes-or-no-p
 outline-isearch-open-invisible-function 'outline-isearch-open-invisible
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-src-mode-hook '(org-src-babel-configure-edit-buffer
         org-src-mode-configure-edit-buffer)
 org-confirm-elisp-link-function 'yes-or-no-p
 org-speed-command-hook '(org-speed-command-activate
              org-babel-speed-command-activate)
 org-tab-first-hook '(org-babel-hide-result-toggle-maybe
          org-babel-header-arg-expand)
 org-link-shell-confirm-function 'yes-or-no-p
 org-babel-pre-tangle-hook '(save-buffer)
 org-agenda-loop-over-headlines-in-active-region nil
 org-occur-hook '(org-first-headline-recenter)
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-link-parameters '(("attachment" :follow org-attach-follow :complete
            org-attach-complete-link)
           ("id" :follow org-id-open)
           ("eww" :follow org-eww-open :store org-eww-store-link)
           ("rmail" :follow org-rmail-open :store
            org-rmail-store-link)
           ("mhe" :follow org-mhe-open :store org-mhe-store-link)
           ("irc" :follow org-irc-visit :store org-irc-store-link
            :export org-irc-export)
           ("info" :follow org-info-open :export org-info-export
            :store org-info-store-link)
           ("gnus" :follow org-gnus-open :store
            org-gnus-store-link)
           ("docview" :follow org-docview-open :export
            org-docview-export :store org-docview-store-link)
           ("bibtex" :follow org-bibtex-open :store
            org-bibtex-store-link)
           ("bbdb" :follow org-bbdb-open :export org-bbdb-export
            :complete org-bbdb-complete-link :store
            org-bbdb-store-link)
           ("w3m" :store org-w3m-store-link)
           ("doi" :follow org-link-doi-open :export
            org-link-doi-export)
           ("file+sys") ("file+emacs")
           ("shell" :follow org-link--open-shell)
           ("news" :follow
            #[514 "\301\300\302Q\"\207"
              ["news" browse-url ":"] 6 "\n\n(fn URL ARG)"]
            )
           ("mailto" :follow
            #[514 "\301\300\302Q\"\207"
              ["mailto" browse-url ":"] 6 "\n\n(fn URL ARG)"]
            )
           ("https" :follow
            #[514 "\301\300\302Q\"\207"
              ["https" browse-url ":"] 6 "\n\n(fn URL ARG)"]
            )
           ("http" :follow
            #[514 "\301\300\302Q\"\207"
              ["http" browse-url ":"] 6 "\n\n(fn URL ARG)"]
            )
           ("ftp" :follow
            #[514 "\301\300\302Q\"\207" ["ftp" browse-url ":"]
              6 "\n\n(fn URL ARG)"]
            )
           ("help" :follow org-link--open-help :store
            org-link--store-help)
           ("file" :complete org-link-complete-file)
           ("elisp" :follow org-link--open-elisp))
 org-metaup-hook '(org-babel-load-in-session-maybe)
 )

Re: [CLOSED] text-property displayed image has a center-line when the text face has underline attribute

[Christopher M. Miles]

Eli Zaretskii  writes:

>> From: "Christopher M. Miles" 
>> Cc: numbch...@gmail.com, yanta...@gmail.com, emacs-de...@gnu.org,
>>  emacs-orgmode@gnu.org
>> Date: Sun, 02 Oct 2022 18:45:41 +0800
>> 
>> I hate to rewrite those steps more than 3 times.
>
> The problem is, I've read the correspondence on the Org list, and I
> still don't understand what are the steps needed, that don't require
> the extra Org package.  That is why I( asked for the details: so that
> the bug tracker could have them clearly and unambiguously.
>
> I do want to look into the issue and see if there's anything that
> needs to be fixed in Emacs.
>
>> But I also know Emacs
>> contributors should not be forced to fix bug for me. Also I can't fix
>> this bug by myself. So I think it's not a bug, I can tolerate this
>> center line. Maybe I mastered skill for modify code in Emacs, I might
>> come back to fix this bug by myself. But now, let me close it. I'm not
>> hating anybody, just hate this process. Thanks for checking out.
>
> I'm sorry you feel like that.  Perhaps Ihor or someone else could fill
> in the blanks and allow us to investigate.
>
> Thanks.

No, it's my personal character and feeling caused this behavior. Not
your fault. I really don't blame anybody.

In bellowing Ihor's email wrote the reproduce steps. Thanks very much Ihor.

-- 

[ 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: [HELP] Fwd: Org format as a new standard source format for GNU manuals

[Max Nikulin]

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

Max Nikulin writes:


This can help with escaping syntax and spaces in verbatim.


It should be enough to create nested "code" or "verbatim" inline objects
with some attribute like :class file, :class var, :class dfn, etc.
Export backend may interpret this attribute to create proper texinfo
commands or more precisely choose HTML element.


I do recall you mentioned this idea in one of the earlier threads.
https://orgmode.org/list/sokqa3$e8s$1...@ciao.gmane.io
Max Nikulin (2021-12-06)
Subject: Raw Org AST snippets for "impossible" markup


It was using links, not source blocks. Typing AST directly is a kind of
last resort. Now I am writing about some higher level markup with a
parser that allows nested element and uses just a few special characters
to denote commands. It is a kind of trade-off between brevity of
lightweight markup and flexibility of more verbose language with ability
to more precisely express intentions.


I am not sure if I understand the details of what you are referring to.

Can you please illustrate how to use the described AST markup for the
following Texinfo snippet:

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


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

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


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

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.

or

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

where src_alt{ext} is the
system-specific extension for dynamic libraries.

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

Re: Markup page 404

[kalathilvishal1]

Update the page on Literal Examples also 404s.
https://orgmode.org/guide/Literal-Examples.html

On Sun, Oct 2 2022 at 06:05:16 PM +05:30:00 +05:30:00, 
kalathilvish...@gmail.com wrote:

Hello,
	This is regarding the compact orgmode guide. The 11th unit's main 
page (Markup for Rich Contents) 404s.


The page at https://orgmode.org/guide/Markup.html#Markup does not 
exist. However all the pages under it, i.e. 11.1, 11.2, etc all seem 
to work.


Hopefully you can fix this minor error. Apologies if any section of 
my email was not clear.


Yours,
Vishal Kalathil

Markup page 404

[kalathilvishal1]

Hello,
	This is regarding the compact orgmode guide. The 11th unit's main page 
(Markup for Rich Contents) 404s.


The page at https://orgmode.org/guide/Markup.html#Markup does not 
exist. However all the pages under it, i.e. 11.1, 11.2, etc all seem to 
work.


Hopefully you can fix this minor error. Apologies if any section of my 
email was not clear.


Yours,
Vishal Kalathil

Re: Markup page 404

[Bastien]

Hi Vishal,

thanks for reporting this, this is fixed now.

Best,

-- 
 Bastien

Re: Markup page 404

[Bastien]

kalathilvish...@gmail.com writes:

> Update the page on Literal Examples also 404s.
> https://orgmode.org/guide/Literal-Examples.html

Fixed too, thanks!

-- 
 Bastien

Planning links to tasks

[Eduardo Suarez]

This mail is related to 'Manual Ordering and Dynamic Priority' thread.
https://lists.gnu.org/archive/html/emacs-orgmode/2022-09/msg00091.html

Hi, I have just implemented an approach to creating a hierarchy of links to
tasks, so the hierarchy can be thought of a dependency tree (something like a
Gantt but with no dates). This approach may be suitable if your org hierarchy
is not already based on todo dependencies, and there are too many tasks to
review them often.

The idea is to be able to:

- easily add an item to a plain list in a section named (e.g.)
  "Planning/Unplanned tasks", consisting of a link to a task in the same
  buffer (=org-plk-insert=),

- move by text editing this list item into a hierarchy of items in a section
  named (e.g.) "Planning/Planned tasks", so hierarchy means dependency
  (somehow).

BEGIN ORG SAMPLE

...
* Planning
** Planned tasks
- [[#task4][My task 4 header]]
  - [[#task5][My task 5 header]]
  - [[#task1][My task 1 header]]
- [[#task2][My task 2 header]]
  - [[#task7][My task 7 header]]
- [[#task6][My task 6 header]]
  - [[#task3][My task 3 header]]
** Planned tasks
- [[#task8][My task 8 header]]
- [[#task9][My task 9 header]]

END ORG SAMPLE

When planning:

- go to "Planning/Planned tasks", and click on any task link, modify whatever
  (todo keyword, tags, timestamps) and get back with 'org-mark-ring-goto' to
  continue your planning.

- Once finished, update all link descriptions to tasks
  (=edu/org-plk-update-descriptions=).

In the code below, I have set a custom description for the links so I can see
more details about the tasks. I have also added a suffix to the description so
I can check whether a link is a planning link or not.

A capture template is required, and an ID property before storing the link,
which can be set automatically with:

  (setq org-id-link-to-org-use-id 'create-if-interactive-and-no-custom-id)

I'm not an (e)lisp coder, so any comments about the code (or whatever) are
welcome.

Some improvements would be great:
  - update link description at point,
  - nice looking planning links (fontify?, have no idea),
  - use another flag for planning link instead of suffix,
  - check for planning links duplicates.

CODE BEGIN HERE

;;; Code:

;; Create an org-capture-template like this:
;;
;; ("xp"
;;  "Planning Link"
;;  item
;;  (file+olp buffer-name "Planning" "Unplanned")
;;  ;; Insert date timestamp to keep track of link creation
;;  "%<%Y%m%d> [[%L][%(edu/org-plk-insert-last-description)]]"
;;  :immediate-finish t
;;  :jump-to-captured t)

(defcustom edu/org-plk-suffix " (plk)"
  "Custom suffix for Planning Links"
  :group 'edu
  :type 'string)

(defcustom edu/org-plk-template-keys "xp"
  "Custom templates keys to insert a Planning Link"
  :group 'edu
  :type 'string)

(defvar edu/org-plk-last-description ""
  "Last description for Planning Link")

(defun edu/org-plk-format-description ()
  "Format description for Planning Link"
  (let* ((components (org-heading-components))
 (todo (nth 2 components))
 (priority (nth 3 components))
 (headline (nth 4 components))
 (tags (nth 5 components))
 (scheduled (org-entry-get nil "SCHEDULED"))
 (deadline (org-entry-get nil "DEADLINE")))
(format "[%s/%c/%c%c] %s %s%s"
(or todo "")
(or priority ?-)
(if scheduled ?S ?-)
(if deadline ?D ?-)
headline
(or tags "::")
edu/org-plk-suffix)))

(defun edu/org-plk-description-from-id (target-id)
  "Planning link description from Link ID"
  (catch 'found
(org-map-entries
 ;; break on first element found
 #'(throw 'found (edu/org-plk-format-description))
 (format "ID=\"%s\"" target-id

(defun edu/org-plk-p (link &optional shift)
  "Predicate to check if link is a Planning Link"
  (let ((shift (or shift 0)))
(and (string= (org-element-property :type link) "id")
 (string-suffix-p
  edu/org-plk-suffix
  (buffer-substring (+ shift (org-element-property :contents-begin 
link))
(+ shift (org-element-property :contents-end 
link)))

;; based on 'us/update-internal-link-descriptions'
;; https://stackoverflow.com/a/71508831
(defun edu/org-plk-update-descriptions ()
  "Update all Planning Link descriptions in buffer"
  (interactive)
  (save-excursion
(let ((shift 0))
  ;; map over all links in the buffer
  (org-element-map (org-element-parse-buffer) 'link
(lambda (link)
  (when (edu/org-plk-p link shift)  ;; filter-in plk's
(let* ((new-desc-text
(edu/org-plk-description-from-id (org-element-property 
:path link)))
   ;; shifted because of previous description updates in this 
run
   (old-desc-start (+ shift (org-element-property 
:contents-begin link)))
   (old-desc-end (+ shift (org-element-property :contents-end 
link
 

Some links in online manual do not work

[Tim Landscheidt]

Hi,

at https://orgmode.org/manual/HTML-Export.html, the links
for the first five (5) and the last two (2) subsections
work, the links for:

- "Headlines in HTML export"
  (https://orgmode.org/manual/Headlines-in-HTML-export.html)
- "Links in HTML export"
  (https://orgmode.org/manual/Links-in-HTML-export.html)
- "Tables in HTML export"
  (https://orgmode.org/manual/Tables-in-HTML-export.html)
- "Images in HTML export"
  (https://orgmode.org/manual/Images-in-HTML-export.html)
- "Math formatting in HTML export"
  (https://orgmode.org/manual/Math-formatting-in-HTML-export.html)
- "Text areas in HTML export"
  (https://orgmode.org/manual/Text-areas-in-HTML-export.html)

however all return "301 Moved Permanently", pointing back to
"HTML-Export.html".

The fact that all failing links are named
"Something-in-HTML-export.html" might suggest an issue with
the webserver configuration.

Tim

Re: [HELP] Help implementing org-lint/warnings buffer during export (was: Org HTML export accessibility (was: org exported pdf files))

[Tim Cross]

Ihor Radchenko  writes:

> Tim Cross  writes:
>
>> From an org-mode perspective, the key things which need to be maintained
>> (and which perhaps we could make even easier or possibly have
>> 'defaults') is the ability to add the alt attribute to any non-text
>> element. For example, images, videos, sound files etc. All such content
>> should always have some text describing the 'element'. However, it is
>> also important to be able to not have an alt tag in some situations (for
>> example, when using images as 'spacers' for formatting etc, we don't
>> want an alt tag. Things to be aware of are things like using single
>> characters or symbols (e.g. < and > for previous/next) or using unicode
>> and other symbols whose meaning/purpose may seem very obvious when
>> viewed, but is less so when 'spoken'. 
>>
>> From an authoring perspective, it probably would be good if org mode was
>> able to alert the user to content which lacks an alt attribute but which
>> probably should have one e.g. an image with no caption, a link to a
>> video/audio file etc.
>
> This sounds like a good idea.
>
> Org currently attempts to be slightly helpful by indicating, for
> example, LaTeX compilation warnings. However, it is just done by writing
> a simple message in the echo area.
>
> What would be more useful is the kind of buffer displayed by org-lint,
> but instead used during export:
> - If there are any export issues (LaTeX errors/warnings) they can appear
>   in the buffer
> - If there are any stylistic issues (like lack of alt attributes during
>   html export), they can also appear
>
> Ideally, we should be able to jump directly to the line containing
> error.
>
> org-lint code could be used as a base, but otherwise we need to
> implement something generic way to check style/export warnings on
> per-backend basis.
>
> This is probably something we need to do before we dive into the
> accessibility specifics. AFAIU from the Tim's reply, many of the
> accessibility guidelines may need to be decided by the document author.
> Tim, let me know if I am wrong and some of the accessible tagging must
> be done unconditionally.
>
> I am marking this as a help request.
>
> Let me know what you think.

I had a very similar idea wrt lint like functionality to alert user to
possible 'stylistic' and/or other problems in exported content. Adding
accessibility to that would then be the next step.

I'm very much against enforcing standards. Experience has taught me that
these sorts of thing change more frequently then you might expect. Also,
like the old sayings go "every rule has an exception" "you need to know
the rules before you can break them", etc. Far better to provide the
tools which can assist the author, but avoid enforcing some particular
view/opinion.

We would probably want to make the linting rules dynamic - allowing easy
add/removal/update of rules. People could then possibly use it to also
check for local policy/standard requirements by adding their own. 

Re: Some links in online manual do not work

[Tim Cross]

Tim Landscheidt  writes:

> Hi,
>
> at https://orgmode.org/manual/HTML-Export.html, the links
> for the first five (5) and the last two (2) subsections
> work, the links for:
>
> - "Headlines in HTML export"
>   (https://orgmode.org/manual/Headlines-in-HTML-export.html)
> - "Links in HTML export"
>   (https://orgmode.org/manual/Links-in-HTML-export.html)
> - "Tables in HTML export"
>   (https://orgmode.org/manual/Tables-in-HTML-export.html)
> - "Images in HTML export"
>   (https://orgmode.org/manual/Images-in-HTML-export.html)
> - "Math formatting in HTML export"
>   (https://orgmode.org/manual/Math-formatting-in-HTML-export.html)
> - "Text areas in HTML export"
>   (https://orgmode.org/manual/Text-areas-in-HTML-export.html)
>
> however all return "301 Moved Permanently", pointing back to
> "HTML-Export.html".
>
> The fact that all failing links are named
> "Something-in-HTML-export.html" might suggest an issue with
> the webserver configuration.
>

This looks like the nginx case issue again.

I've looked at this and there does not seem to be any 'clean' way to fix
this which also doesn't have significant processing overhead or a
maintenance burden.

I wonder if it would be worthwhile adding an option to HTML export which
would force all link targets and exported filenames to lower case,
thereby avoiding issues on platforms and with web servers which have
different positions wrt case sensitivity?

Re: Issue with export of inlinetasks

[Ihor Radchenko]

Michael Dauer  writes:

> org-version reports the same version, but now the same code (posted before)
> works. So it's fixed.
>
> But shouldn't org-version report 9.5.5 instead of 9.5?

It should. The latest stable version of Org is 9.5.5. The latest
development version is 9.6-pre.

If you get something different from the above, you are using some
different version of Org.

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

Re: [BUG] org-timer-start doesn't seem to take the timer string at point [9.5.5 (release_9.5.5 @ z:/emacs-i686/share/emacs/28.2/lisp/org/)]

[Ihor Radchenko]

Ypo  writes:

> Oh! Thanks
>
> I didn't understand. Maybe this would be more understandable?:
>
>>   When called with a ‘C-u’ prefix, prompt the user for a starting
>>  offset or, if there is a timer string at point, this is taken as the
>>  default, ...
> Or:
>
>>   When called with a ‘C-u’ prefix, there are 2 options: prompt the user for 
>> a starting
>>  offset.  Or, if there is a timer string at point, this is taken as the
>>  default, ...

Your versions still feel a bit confusing.
What about the attached patch?

>From 1efdf049475dfa9d4cdf219d665c4afcb32ed7cc Mon Sep 17 00:00:00 2001
Message-Id: <1efdf049475dfa9d4cdf219d665c4afcb32ed7cc.1664765817.git.yanta...@gmail.com>
From: Ihor Radchenko 
Date: Mon, 3 Oct 2022 10:55:33 +0800
Subject: [PATCH] org-manual: Clarify `org-timer-start' command description

* doc/org-manual.org (Taking Notes with a Relative Timer): Emphasize
that timer at point is only taken into account when called with prefix
argument.

Reported-by: Ypo 
Link: https://orgmode.org/list/ae3befcf-1f62-fc84-e63c-16cd45bba...@gmail.com
---
 doc/org-manual.org | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index d249f32d6..618feb5fd 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -7126,12 +7126,12 @@ ** Taking Notes with a Relative Timer
   #+findex: org-timer-start
   Start or reset the relative timer.  By default, the timer is set
   to 0.  When called with a {{{kbd(C-u)}}} prefix, prompt the user for
-  a starting offset.  If there is a timer string at point, this is
-  taken as the default, providing a convenient way to restart taking
-  notes after a break in the process.  When called with a double
-  prefix argument {{{kbd(C-u C-u)}}}, change all timer strings in the
-  active region by a certain amount.  This can be used to fix timer
-  strings if the timer was not started at exactly the right moment.
+  a starting offset.  The prompt will default to a timer string at
+  point (if any), providing a convenient way to restart taking notes
+  after a break in the process.  When called with a double prefix
+  argument {{{kbd(C-u C-u)}}}, change all timer strings in the active
+  region by a certain amount.  This can be used to fix timer strings
+  if the timer was not started at exactly the right moment.
 
 - {{{kbd(C-c C-x ;)}}} (~org-timer-set-timer~) ::
 
-- 
2.35.1



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

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

[Ihor Radchenko]

"Christopher M. Miles"  writes:

> +*** New ~org-cycle-hook~ function ~org-cycle-display-inline-images~ for auto 
> displaying subtree inline images
> +
> +This behavior is toggled by custom option ~org-cycle-inline-images-display~.
> +

I'd be a bit more direct. Something like "Outline cycling can now
include inline image visibility".

Also, it is a good idea to document the new feature in the manual (12.7
Images section and 2.2.1 Global and local cycling section).

> +
> +;; `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-cycle)
> +;;   (org-cycle)
> +;;   (org-cycle)
> +;;   ;; TODO: how to detect inline image overlays are deleted after 
> folded?

> I commented out the third test if someone can do this. I don't now how to 
> test in fold state.

You can, for example, check org-inline-image-overlays and (overlays-in
(point-min) (point-max))

>
> Because I got error when running command "make test". I checked org-mode
> source code repo, the ob-vala.el is removed, don't know where it is
> introduced.

I've seen this around the time we removed org-contrib.
I suggest you to re-clone Org repo into a clean folder.

> Started at:   2022-10-01 17:46:30+0800
> Finished.
> Finished at:  2022-10-01 17:46:31+0800
>
> F
>
> F test-org-fold/org-fold-display-inline-images
> Test inline images displaying when cycling.
> (ert-test-failed
>  ((should
>(overlays-at
> (point)))
>   :form
>   (overlays-at 130)
>   :value nil))
> #+end_example

Please do not use org-cycle in tests. It is an interactive command and
makes a number of assumptions about `this-command' and `last-command'
values. Instead, prefer more direct `org-show-subtree'/`org-show-children'.

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

Re: [HELP] Help implementing org-lint/warnings buffer during export (was: Org HTML export accessibility (was: org exported pdf files))

[Ihor Radchenko]

Tim Cross  writes:

> I had a very similar idea wrt lint like functionality to alert user to
> possible 'stylistic' and/or other problems in exported content. Adding
> accessibility to that would then be the next step.
>
> I'm very much against enforcing standards. Experience has taught me that
> these sorts of thing change more frequently then you might expect. Also,
> like the old sayings go "every rule has an exception" "you need to know
> the rules before you can break them", etc. Far better to provide the
> tools which can assist the author, but avoid enforcing some particular
> view/opinion.
>
> We would probably want to make the linting rules dynamic - allowing easy
> add/removal/update of rules. People could then possibly use it to also
> check for local policy/standard requirements by adding their own. 

Agree. Note that we do have `org-lint-add-checker'.
Disabling/suppressing checks is also a good thing to add.

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

Re: Some links in online manual do not work

[Ihor Radchenko]

Tim Cross  writes:

> I wonder if it would be worthwhile adding an option to HTML export which
> would force all link targets and exported filenames to lower case,
> thereby avoiding issues on platforms and with web servers which have
> different positions wrt case sensitivity?

Could you please elaborate?

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

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

[Ihor Radchenko]

Max Nikulin  writes:

> On 01/10/2022 11:08, Ihor Radchenko wrote:
>> In particular, I suggest to (1) extend the existing special block elements
>> with Elisp-configurable :export settings; (2) add special block
>> equivalent object.
>
> While I do not mind to have flexible generic inline objects, I feel some 
> doubts.
>
> Export is already customizable through creation of derived backend. For 
> links :export property is merely an alternative way supposed to be more 
> convenient. In some sense it is a way to dispatch proper handler, a kind 
> of virtual function table, etc. I see a couple of limitations with link 
> export implementation.

Creating derived backend will force users to use that non-standard
backend for export - inconvenient. Especially for third-party backends.

:export property, among other things, can also provide a reasonable
fallback for arbitrary backend not considered in advance.

> 1. Interface is rather different from the derived backend property. 
> Instead of org-element object only selected properties (and backend 
> communication channel is available).

Is it? :export function for links is taking similar parameters with the
other export transcoders.

> 2. Unsure if there is a robust way to extend implementation of the 
> backend handler without replacing it completely. I mean a function that 
> modifies or sets some attributes and delegate real export to the default 
> handler.

We may provide something like :export-filter-object that will act
similar to `:filter-parse-tree' and replace the original link object
with arbitrary Org AST.

> Mentioned in this thread texinfo commands are not convincing reason for 
> special blocks from my point of view. They are different flavors of 
> verbatim (or code) object. If they are verbatim objects with some 
> additional property then they may be just exported by a backend that is 
> unaware of their kinds. It can be considered as graceful degradation. 
> For special blocks export handlers must be implemented for each backend 
> unless type hierarchy is someway declared.

No. There is no need to consider every possible backend. There could be
an export handler that will provide a fallback for unknown backend, if
needed.

> Earlier we discussed assigning attributes for inline objects. While 
> nesting is not involved, it may be a way to implement necessary texinfo 
> commands as verbatim with class or type attribute. I am unsure if 
> different types of special blocks is the best way to resolve nesting 
> problem. Verbatim custom objects require different rules of parsing.

Please do remember that texinfo commands, are _not_ verbatim. They can
contain other markup inside. I'd rather look at them as extended
emphasis. Their contents must be parsed as well.

> Actually I simplified things when wrote that a backend may be unaware of 
> verbatim type. When nesting is involved it should be ready at least to 
> nested verbatim object. E.g. markdown backend can not blindly wrap text 
> into backticks, it has to check if parent element is not a verbatim 
> snippet or a verbatim block.

Agree. See export filter idea.

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

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

[Ihor Radchenko]

Juan Manuel Macías  writes:

> And how about this:
>
> %_name{}
> %_name{{}}  <--- extra {} is added as needed for escaping
> %_name[:key value ...]{}
>
> or any other symbol instead of "%" ?
>
> N.B.: I must admit this is more for an "aesthetic" reason. Although
> perhaps it can be useful to search in the documents.

I have to admit that I am not a big fan of underscore in _name myself.
Just wanted to keep some resemblance of src_name{} yet not
making things too verbose (like block_name{}).

If I were to choose an alternative symbol other than "_", I'd choose
"@":

@name{}
@name{{}

1. It is similar to Texinfo
2. It does not clash with TeX
3. We already use @ in the inline export snippets.

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

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

[Ihor Radchenko]

Max Nikulin  writes:

> On 02/10/2022 11:59, Ihor Radchenko wrote:
>> Can you please illustrate how to use the described AST markup for the
>> following Texinfo snippet:
>> 
>>  By convention, the dynamic library for @var{language} is
>>  @code{libtree-@{sitter@}-@var{"language"}.@var{ext}}, where @var{ext} 
>> is the
>>  system-specific extension for dynamic libraries.
>
> 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.

> 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 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}- class="var">"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}}.

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

The problem with src block emitting AST is clashing with the way src
blocks work during export. What `org-export-as' does is replacing/adding
src block output into the actual Org buffer text before the parsing is
done.

Handling direct AST sexps will require a rewrite on how babel
integration with export works.

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

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

[Christopher M. Miles]

Finally finished and passed the test. Here I attached the new patch.

From c36122f818289cbd26026ae75ce480b03e03f61a Mon Sep 17 00:00:00 2001
From: stardiviner 
Date: Wed, 28 Sep 2022 20:46:52 +0800
Subject: [PATCH] org.el: Support auto display inline images when cycling

* lisp/org.el (org-toggle-inline-images): Support region.
(org-display-inline-images): Fix refresh argument logic.
(org-remove-inline-images): Support region.

* lisp/org-keys.el (org-toggle-inline-images): Update arguments.

* lisp/org-cycle.el (org-cycle-inline-images-display): Add new option to
control whether auto display inline images when cycling.
(org-cycle-display-inline-images): Add new hook function to auto display
inline images when cycling.
(org-cycle-hook): Add `org-cycle-display-inline-images' into cycling
hook by default.

* testing/lisp/test-org-fold.el (test-org-fold/org-fold-display-inline-images):
Add test for inline image displaying when cycling.
---
 doc/org-manual.org|  12 
 etc/ORG-NEWS  |   5 ++
 lisp/org-cycle.el |  38 -
 lisp/org-keys.el  |   2 +-
 lisp/org.el   |  21 ---
 .../images/Org mode logo mono-color.png   | Bin 0 -> 7523 bytes
 testing/lisp/test-org-fold.el |  52 ++
 7 files changed, 119 insertions(+), 11 deletions(-)
 create mode 100755 testing/examples/images/Org mode logo mono-color.png

diff --git a/doc/org-manual.org b/doc/org-manual.org
index ab8a295e5..ec5b729be 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -475,6 +475,13 @@ Org uses just two commands, bound to {{{kbd(TAB)}}} and
   #+vindex: org-cycle-emulate-tab
   Point must be on a headline for this to work[fn:4].
 
+  #+vindex: org-cycle-inline-images-display
+  Outline cycling can now include inline image visibility. You can
+  enable this behavior by setting custom option
+  ~org-cycle-inline-images-display~ to non-~nil~. After enabled, when
+  you pressed {{{kbd(TAB)}}} on headline, the inline images under
+  subtree will be displayed automatically based on the ~org-cycle~ state.
+
 - {{{kbd(S-TAB)}}} (~org-global-cycle~), {{{kbd(C-u TAB)}}} ::
 
   #+cindex: global visibility states
@@ -11332,6 +11339,11 @@ command:
   - When set to nil, try to get the width from an =#+ATTR.*= keyword
 and fall back on the original width if none is found.
 
+Inline images under subtree can be auto displayed by enabling custom
+option ~org-cycle-inline-images-display~. After enabled, when you
+pressed {{{kbd(TAB)}}} on headline, the inline images under subtree
+will be displayed automatically based on the ~org-cycle~ state.
+
 ** Captions
 :PROPERTIES:
 :DESCRIPTION: Describe tables, images...
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index cab64317f..8832a5beb 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -307,6 +307,11 @@ to pass the contents of a named code block as a string argument.
 The new property =ORG-IMAGE-ACTUAL-WIDTH= can override the global
 variable ~org-image-actual-width~ value for inline images display width.
 
+*** New ~org-cycle-hook~ function ~org-cycle-display-inline-images~ for auto displaying subtree inline images
+
+Outline cycling can now include inline image visibility. This behavior
+is controlled by custom option ~org-cycle-inline-images-display~.
+
 *** New ~org-babel-tangle-finished-hook~ hook run at the very end of ~org-babel-tangle~
 
 This provides a proper counterpart to ~org-babel-pre-tangle-hook~, as
diff --git a/lisp/org-cycle.el b/lisp/org-cycle.el
index 656ca83f2..212d25a44 100644
--- a/lisp/org-cycle.el
+++ b/lisp/org-cycle.el
@@ -208,8 +208,9 @@ the values `folded', `children', or `subtree'."
   :type 'hook)
 
 (defcustom org-cycle-hook '(org-cycle-hide-archived-subtrees
-		   org-cycle-show-empty-lines
-		   org-cycle-optimize-window-after-visibility-change)
+org-cycle-show-empty-lines
+org-cycle-optimize-window-after-visibility-change
+org-cycle-display-inline-images)
   "Hook that is run after `org-cycle' has changed the buffer visibility.
 The function(s) in this hook must accept a single argument which indicates
 the new state that was set by the most recent `org-cycle' command.  The
@@ -229,6 +230,13 @@ normal outline commands like `show-all', but not with the cycling commands."
   :group 'org-cycle
   :type 'boolean)
 
+(defcustom org-cycle-inline-images-display nil
+  "Non-nil means auto display inline images under subtree when cycling."
+  :group 'org-startup
+  :group 'org-cycle
+  :package-version '(Org . "9.6")
+  :type 'boolean)
+
 (defvar org-cycle-tab-first-hook nil
   "Hook for functions to attach themselves to TAB.
 See `org-ctrl-c-ctrl-c-hook' for more information.
@@ -776,6 +784,32 @@ STATE should be one of the symbols listed in the docstring of
 		   "Subtree is archived and stays closed.  U

Re: Planning links to tasks

[Ihor Radchenko]

Eduardo Suarez  writes:

> Hi, I have just implemented an approach to creating a hierarchy of links to
> tasks, so the hierarchy can be thought of a dependency tree (something like a
> Gantt but with no dates). This approach may be suitable if your org hierarchy
> is not already based on todo dependencies, and there are too many tasks to
> review them often.
>
> The idea is to be able to:
>
> - easily add an item to a plain list in a section named (e.g.)
>   "Planning/Unplanned tasks", consisting of a link to a task in the same
>   buffer (=org-plk-insert=),
>
> - move by text editing this list item into a hierarchy of items in a section
>   named (e.g.) "Planning/Planned tasks", so hierarchy means dependency
>   (somehow).

Have you been using your code for some time now or is it just an
experiment implementing your idea?

> Some improvements would be great:
>   - update link description at point,
>   - nice looking planning links (fontify?, have no idea),
>   - use another flag for planning link instead of suffix,
>   - check for planning links duplicates.

It would be helpful if you provide a more detailed demonstration of your
approach. I imagine something similar (in terms of presentation) to
https://blog.jethro.dev/posts/capturing_inbox/

It is hard to comment anything on your ideas without seeing how your
code actually works.

Also, if you want to hear suggestions about particular parts of the
code, please provide those parts instead of throwing the whole code - it
will make things easier for people who are only interested to answer a
specific question of yours.

> (defun edu/org-plk-description-from-id (target-id)
>   "Planning link description from Link ID"
>   (catch 'found
> (org-map-entries
>  ;; break on first element found
>  #'(throw 'found (edu/org-plk-format-description))

This is not a valid Elisp syntax.
Check out 13.7 Anonymous Functions section of Elisp manual.

> (let ((shift 0))
>   ;; map over all links in the buffer
>   (org-element-map (org-element-parse-buffer) 'link
> (lambda (link)
>   (when (edu/org-plk-p link shift)  ;; filter-in plk's
> (let* ((new-desc-text
> (edu/org-plk-description-from-id (org-element-property 
> :path link)))
>;; shifted because of previous description updates in this 
> run
>(old-desc-start (+ shift (org-element-property 
> :contents-begin link)))
>(old-desc-end (+ shift (org-element-property :contents-end 
> link

You can also use a simple re-search-forward and not bother with `shift'.
Or use org-element-cache-map from the latest main.

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

Re: [BUG] Weird sparse tree folding [9.5 (release_9.5-225-g494c20.dirty @ /Users/carlos/Install/Source/org-mode/lisp/)]

[Ihor Radchenko]

Ihor Radchenko  writes:

> Confirmed on current main.
>
> Though I plan a bunch of commits that will also fix this particular
> issue.

I believe that the issue is no longer present on current main.
I am closing thus bug.

Let me know if you are still experiencing the issue.

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

Fixed.

Re: Some broken links in pages under https://orgmode.org/worg/org-contrib/babel

[Ihor Radchenko]

"Thomas S. Dye"  writes:

> A bad link blocked HTML compilation on the server.  Fixed now, 
> thanks.

I am thus closing this bug report.

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

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

[Ihor Radchenko]

Sébastien Miquel  writes:

> Fabio Natali writes:
>> Thanks for getting back to me and thank you very much for the code
>> snippet, which I think I'm going to integrate in my configuration.
>
> Thank you for the report. With regard to the snippet, It seems the
> advice function needs ~(&optional justify region)~ as arguments rather
> than ().

I am still getting the described behaviour.
However, it does not happen in Org mode itself.
`fill-paragraph' in emacs-lisp-mode does exactly the observed behaviour.

Try
1. emacs -Q
2. insert
;; A comment
(+ 2 2)
3. M-h M-q

Is it emacs-lisp-mode bug? Or is it illegal to fill-region in source
code buffers?

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