Re: org-super-agenda global list of TODO items

[Angel de Vicente]

Hello,

Ihor Radchenko  writes:

> Could you please elaborate what you mean by "organize"?

Maybe the best is an image... If you look at
https://github.com/alphapapa/org-super-agenda/blob/master/images/screenshots/index.org,
you can see that the TODO items for a given date in the agenda are
neatly organized by using org-super-agenda into user-defined groups
(Important, Personal, etc.).

I got this working fine, but then I have a long list of TODO items with
no scheduled date. I was hoping that org-super-agenda would also work on
those items, so that similar grouping would be applied to them, but I
don't know if this is not possible or I'm missing something.

As an example, my agenda now looks like the following, where the
grouping is not applied to the Global list of TODO items (which I would
like):

,
| Day-agenda (W37):
| Tuesday13 September 2022
| 
|  Schedule
|6:35.. now - - - - - - - - - - - - - - - - - - - - - - - - 
-
|8:00.. 
|   10:00.. 
|   12:00.. 
|   14:00.. 
|   16:00.. 
|   diary:  17:30-18:30 Timaginas Teatro 
|   18:00.. 
|   20:00.. 
| 
|  Important
|   TODO_personal:Scheduled:  TODO [#A] Revisión óptica
:personal:
| 
|  Personal
|   TODO_personal:Scheduled:  TODO Call city hall  
:personal:
| 
| 
===
| Global list of TODO items of type: ALL
| 
|  Schedule
|   TODO_wprogress:TODO [#A] P-CORONA (open source version) [2/11]
:polmag:
|   TODO_personal:TODO [#B] Oculista Alex   
:personal:
|   TODO_personal:TODO [#B] Imprimir detalles Pelayo
:personal:
|   TODO_wprogress:TODO Leer:   
:astrophysics:
|   TODO_wprogress:TODO PORTA: Prepare citation file  
:polmag:
`

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

Re: per-file (or, really, per buffer) allowing/disallowing code block execution

[Greg Minshall]

hi, Tim,

> There are valid use cases for a configuration which does not require
> user interaction (to answer questions on block evaluation), for example,
> when you want to process many org files in a batch process without user
> interaction. Likewise, I don'tg want Emacs to become too much of a
> 'nanny'. If I decide the code in a file is safe and permanently safe, I
> want to be able to disable the queries on that file permanently. I'm
> happy using local variables to do this, though I would also like a
> global option as well.

sorry, i don't think i was clear.  i wasn't suggesting changing the
behavior if =org-confirm-babel-evaluate= is =nil= (either as a
buffer-local, or globally).  the trigger for prompting for "[y,n,Y,N,?]"
or long/short some such would be if it were =t= (i think?).

> With regard to long or short answers to such questions, I think the
> default should be the longer yes/no, but the user should be able to set
> it to y/n (i.e. same as normal Emacs behaviour). Ideally, this would
> fall under the same setting as the new y-or-n facility in recent emacs
> versions (replacing the old approaches like defalias).

ah, i didn't realize there was this configuration possibility.  that
makes sense.  thanks.

> Finally, while I can see there is a use case for being able to have fine
> grained control over individual block execution, I don't think having it
> as a prompt is the correct approach. Once you have many of these blocks
> in a file, that prompt will rapidly become annoying. When I've required
> this level of control, I've found header arguments work fine and I'm not
> sure the added complexity is worth it.

last time i tried to export a file with no buffer-local setting of
org-confirm-babel-evaluate, i was prompted on each code block.  and,
yes, it *is* annoying!  eliminating this behavior, while "preserving a
query", is what i find attractive in Fejda's proposal.

i apologize that i'm not sure of the header argument override?

but, still, i wouldn't argue for any new per-src-block-level
configuration.

cheers, Greg

Re: [BUG] org-agenda-list takes 4m compared to 27 that took 15 seconds [9.5.2 (release_9.5.2-25-gaf6f12 @ /usr/share/emacs/28.1/lisp/org/)]

[Ihor Radchenko]

andrés ramírez  writes:

> Hi. Ihor.
>
>> "Ihor" == Ihor Radchenko  writes:
>
> [...]
>
> Ihor> Can you then execute (setq org-element--cache-self-verify nil)
> Ihor> and repeat the steps?
>
> Done.
>
> The produced file.

Thanks!

Now, can you execute the following and let me know if the performance is
back to satisfactory?

(setq org-element--cache-self-verify nil)
(defun org-back-to-heading ( invisible-ok)
  "Go back to beginning of heading."
  (beginning-of-line)
  (or (org-at-heading-p (not invisible-ok))
  (if (org-element--cache-active-p)
  (let ((heading (org-element-lineage (org-element-at-point)
   '(headline inlinetask)
   'include-self)))
(when heading
  (goto-char (org-element-property :begin heading)))
(while (and (not invisible-ok)
heading
(org-fold-folded-p))
  (goto-char (org-fold-core-previous-visibility-change))
  (setq heading (org-element-lineage (org-element-at-point)
  '(headline inlinetask)
  'include-self))
  (when heading
(goto-char (org-element-property :begin heading
(unless heading
  (user-error "Before first headline at position %d in buffer %s"
  (point) (current-buffer)))
(point))
(let (found)
  (save-excursion
;; At inlinetask end.  Move to bol, so that the following
;; search goes to the beginning of the inlinetask.
(when (and (featurep 'org-inlinetask)
   (fboundp 'org-inlinetask-end-p)
   (org-inlinetask-end-p))
  (goto-char (line-beginning-position)))
(while (not found)
  (or (re-search-backward (concat "^\\(?:" outline-regexp "\\)")
  nil t)
  (user-error "Before first headline at position %d in buffer 
%s"
  (point) (current-buffer)))
  ;; Skip inlinetask end.
  (if (and (featurep 'org-inlinetask)
   (fboundp 'org-inlinetask-end-p)
   (org-inlinetask-end-p))
  (org-inlinetask-goto-beginning)
(setq found (and (or invisible-ok (not (org-fold-folded-p)))
 (point))
  (goto-char found)
  found

-- 
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-assert-version considered harmful

[Ihor Radchenko]

Stefan Monnier  writes:

>> Does it help if you run make autoloads after git fetch?
>
> Not that I can tell, no.  But note that I'm not using Org's makefile to
> compile the files, I'm using the elpa.git scripts instead, which don't
> take into account dependencies between files.
>
> So the situation is simply something like:
>
> - git pull  =>  switches to 9.5.5, but several .el files are left unchanged.
> - make autoloads  =>  this refreshes the autoloads, but the .elc files
>   of those .el files which didn't change still won't be recompiled.

Isn't it a bug in the elpa scripts then?
If a macro definition is changed and the .elc file using that macro is
not changed, it still needs to be re-compiled. Otherwise, all kinds of
unexpected side effects may appear.

> I'm not really reporting a bug; I'm not sure how to solve the problem
> without throwing away the benefits of `org-assert-version`.  But I just
> wanted to mention that it has unintended side effects :-)

I understand. As Timothy proposed, we can make less strict checks for Org
version consistency. But the question is whether we really need to make
a more lax assertion or maybe it is better to keep the assertion as is
and use it to catch potential issues e.g. in Elpa.

> PS: BTW, I notice that when Org is installed as a normal `package.el`
> package, in Emacs≥28 it will be activated before the `.emacs` file
> is loaded, which should prevent occurrence of the problems that
> `org-assert-version` aims to catch (unless you use, say, an
> org-babel file for the `early-init.el` :-)

Indeed. Version mismatch issue has been fixed in package.el years back.
But it is starting to pop up again as alternative package managers are
getting traction. There is a constant influx of bug reports caused by
mixed installation. Especially by users of Doom Emacs and straight.el.

Unfortunately, the problem cannot be easily solved, say, on straight.el
side --- straight.el basic design is causing the issue to appear.

> PPS: Maybe instead of calling `org-assert-version` everywhere, the
>  `org-autoloads.el` (i.e. the file that sets up the `load-path` and
>  the autoloads) could look for traces of Org files in the
>  `load-history` and signal an error if such files are found coming
>  from a different directory.

No, unfortunately.

org-autoloads, when loaded from built-in Emacs version will not help
to catch newer Org libraries being loaded after built-in Org version is
loaded.

Moreover, I consider loading personal forks of built-in Org libraries a
valid use-case. Demanding all the org libraries to be loaded from the
same directory will limit this possibility.

-- 
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-agenda-list takes 4m compared to 27 that took 15 seconds [9.5.2 (release_9.5.2-25-gaf6f12 @ /usr/share/emacs/28.1/lisp/org/)]

[Ihor Radchenko]

andrés ramírez  writes:
> Ihor> Can you please 1. run M-x profiler-start  cpu  2. run 
> your agenda 3. M-x
> Ihor> profiler-report  4. M-x profiler-report-write-profile  
> cpu-profile.el 5. Share
> Ihor> the file produced in 4
>
> The file produced.

Thanks!

Can you then execute
(setq org-element--cache-self-verify nil)

and repeat the steps?

-- 
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-assert-version considered harmful

[Stefan Monnier]

Ihor Radchenko [2022-09-13 09:52:37] wrote:
> Stefan Monnier  writes:
>> I can see the reason for this macro, and I don't really have a better
>> solution to offer, but as someone who has a Git clone of Org that is
>> regularly updated using (basically) the normal compilation
>> system used in Emacs (i.e. not systematically recompiling all the files,
>> but only those whose `.el` is more recent than their `.elc`), it means
>> that whenever Org's version changes, I have to manually erase all the
>> `.elc` files otherwise this macro will (incorrectly)
>> complain everywhere  :-(
> Does it help if you run make autoloads after git fetch?

Not that I can tell, no.  But note that I'm not using Org's makefile to
compile the files, I'm using the elpa.git scripts instead, which don't
take into account dependencies between files.

So the situation is simply something like:

- git pull  =>  switches to 9.5.5, but several .el files are left unchanged.
- make autoloads  =>  this refreshes the autoloads, but the .elc files
  of those .el files which didn't change still won't be recompiled.

I'm not really reporting a bug; I'm not sure how to solve the problem
without throwing away the benefits of `org-assert-version`.  But I just
wanted to mention that it has unintended side effects :-)


Stefan


PS: BTW, I notice that when Org is installed as a normal `package.el`
package, in Emacs≥28 it will be activated before the `.emacs` file
is loaded, which should prevent occurrence of the problems that
`org-assert-version` aims to catch (unless you use, say, an
org-babel file for the `early-init.el` :-)

PPS: Maybe instead of calling `org-assert-version` everywhere, the
 `org-autoloads.el` (i.e. the file that sets up the `load-path` and
 the autoloads) could look for traces of Org files in the
 `load-history` and signal an error if such files are found coming
 from a different directory.

Re: [BUG] org-paste-subtree inserts empty line above paste

[Ihor Radchenko]

Felix Wiemuth  writes:

> Emacs 28.1
> Orgmode 9.5.2 (but discovered already 2020-01-20)
>
> When pasting a subtree (of whichever level) with org-paste-subtree at 
> any position (can be an empty line or a line with a header prefix, e.g. 
> "*** "), always an empty line is inserted above the inserted subtree.
>
> I would expect no new line to be inserted, and I think this was the 
> behaviour before I noticed this.

I am unable to reproduce.
Could you please detail what exactly you tried step by step?
See https://orgmode.org/manual/Feedback.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: Suggested Syntax for cancelled checkboxes: [-] as non-blocking dependency

[Ihor Radchenko]

Karl Voit  writes:

> I was using list checkboxes like that:
>
> - [ ] open task
> - [X] closed task
> - [-] cancelled task
>
> The latter one is supported via C-u C-u C-c C-c.

>From the manual (5.6 Checkboxes):

‘C-c C-x C-b’ (‘org-toggle-checkbox’)
 Toggle checkbox status or—with prefix argument—checkbox presence at
 point.  With double prefix argument, set it to ‘[-]’, which is
 considered to be an intermediate state.

[-] is not considered done by our conventions

   Here is an example of a checkbox list.

 * TODO Organize party [2/4]
   - [-] call people [1/3]
 - [ ] Peter
 - [X] Sarah
 - [ ] Sam
   - [X] order food
   - [ ] think about what music to play
   - [X] talk to the neighbors

> However, when I'm using:
>
> (setq org-enforce-todo-checkbox-dependencies t)
>
> ... any [-] checkbox will be regarded as non-finished contrary to
> the behavior of TODO/DONE/CANCELLED heading states.
>
> As a workaround, I may use:
>
> - +[ ]+ cancelled task
>
> ... but this is tedious.
>
> Therefore I'm asking if this might be a viable syntax change:
> handling [-] list items similar to CANCELLED headings as
> non-blocking when used with org-enforce-todo-checkbox-dependencies.

As you can see, we already have conflicting convention, and we cannot
change it without breaking backwards compatibility.

`org-block-todo-from-checkboxes', currently uses

(org-list-search-forward
 (concat (org-item-beginning-re)
 "\\(?:\\[@\\(?:start:\\)?\\([0-9]+\\|[A-Za-z]\\)\\][ 
\t]*\\)?"
 "\\[[- ]\\]")
 end t)

as a condition that some list items are marked incomplete.

So, you can use something like
 - [C] cancelled task

But beware that this is an internal implementation detail that might be
changed in future unless we decide to document the existing behaviour.

-- 
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-assert-version considered harmful

[Timothy]

Hi Ihor and Stefan,

Considering the separate cases of:
• Installing an Org version different to the bundled Org
• Having a development Org version with some slightly-out-of-date cache/autoload
  files.

I’d think the second case has a dramatically reduced chance of issues. Could it
be reasonable to change the `org-assert-version' check to act like so?
• Check if `org-version' matches, if not error
• If `org-version' matches, but `org-git-version' does not, show a warning 
message.

Alternatively, we could create a variable 
`org-assert-version-allow-git-mismatch'
which can be set before loading Org (by people who know what they’re doing, e.g.
Stefan) to enable this proposed behaviour.

What do you think?

All the best,
Timothy

Re: [BUG] org-agenda-list takes 4m compared to 27 that took 15 seconds [9.5.2 (release_9.5.2-25-gaf6f12 @ /usr/share/emacs/28.1/lisp/org/)]

[Ihor Radchenko]

andrés ramírez  writes:

> Ihor> The slowdown is possible as a side-effect of some bugfixes.  
> However, the newest
> Ihor> development version of Org should not have these performance issues.
>
> I have just tried 9.6. org-agenda-list generation time was 1m20s. More
> than one minute more than emacs-27.

Can you please
1. run M-x profiler-start  cpu 
2. run your agenda
3. M-x profiler-report 
4. M-x profiler-report-write-profile  cpu-profile.el
5. Share the file produced in 4 

-- 
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-assert-version considered harmful

[Ihor Radchenko]

Stefan Monnier  writes:

> I can see the reason for this macro, and I don't really have a better
> solution to offer, but as someone who has a Git clone of Org that is
> regularly updated using (basically) the normal compilation
> system used in Emacs (i.e. not systematically recompiling all the files,
> but only those whose `.el` is more recent than their `.elc`), it means
> that whenever Org's version changes, I have to manually erase all the
> `.elc` files otherwise this macro will (incorrectly)
> complain everywhere  :-(

Does it help if you run make autoloads after git fetch?

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

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

[Christopher M. Miles]

"Christopher M. Miles"  writes:

Ihor, My new patch still have some issue in the 'fold state which I
added "FIXME" marker. Hope can get some solution from you.

From 4a56ec6b09e09d92a81e3aa72f4197d716d0ca87 Mon Sep 17 00:00:00 2001
From: stardiviner 
Date: Mon, 12 Sep 2022 09:45:09 +0800
Subject: [PATCH 1/2] org.el: Support subtree-level image width specification

* lisp/org.el (org-display-inline-image--width): Detect subtree-level
property "ORG-IMAGE-ACTUAL-WIDTH" value as image width before fallback.
---
 lisp/org.el | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 4eef56f45..07c86229b 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -12128,7 +12128,8 @@ but in some other way.")
 "EXPORT_OPTIONS" "EXPORT_TEXT" "EXPORT_FILE_NAME"
 "EXPORT_TITLE" "EXPORT_AUTHOR" "EXPORT_DATE" "UNNUMBERED"
 "ORDERED" "NOBLOCKING" "COOKIE_DATA" "LOG_INTO_DRAWER" "REPEAT_TO_STATE"
-"CLOCK_MODELINE_TOTAL" "STYLE" "HTML_CONTAINER_CLASS")
+"CLOCK_MODELINE_TOTAL" "STYLE" "HTML_CONTAINER_CLASS"
+"ORG-IMAGE-ACTUAL-WIDTH")
   "Some properties that are used by Org mode for various purposes.
 Being in this list makes sure that they are offered for completion.")
 
@@ -16164,14 +16165,19 @@ buffer boundaries with possible narrowing."
(org-element-property :begin par)
  (re-search-forward attr-re par-end t)))
   (match-string 1)))
+   ;; support subtree-level property "ORG-IMAGE-ACTUAL-WIDTH" specified width.
+   (subtree-property-width
+(ignore-errors (org-property-or-variable-value 'ORG-IMAGE-ACTUAL-WIDTH)))
(width
 (cond
  ;; Treat :width t as if `org-image-actual-width' were t.
  ((string= attr-width "t") nil)
- ;; Fallback to `org-image-actual-width' if no interprable width is given.
  ((or (null attr-width)
   (string-match-p "\\`[^0-9]" attr-width))
-  (car org-image-actual-width))
+  ;; Try to use subtree-level width before fallback.
+  (or subtree-property-width
+  ;; Fallback to `org-image-actual-width' if no interprable width is given.
+  (car org-image-actual-width)))
  ;; Convert numeric widths to numbers, converting percentages.
  ((string-match-p "\\`[0-9.]+%" attr-width)
   (/ (string-to-number attr-width) 100.0))
-- 
2.37.2

From 2fc76c4581b60c6631186bfdc489732075432c26 Mon Sep 17 00:00:00 2001
From: stardiviner 
Date: Tue, 13 Sep 2022 09:04:03 +0800
Subject: [PATCH 2/2] org.el: Add hook function to auto display inline images
 of subtree

* lisp/org.el (org-display-subtree-with-inline-images): Add an option
and hook function to auto display of inline images under current
expanded visible subtree.
---
 lisp/org.el | 43 +++
 1 file changed, 43 insertions(+)

diff --git a/lisp/org.el b/lisp/org.el
index 07c86229b..0bd942e07 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -1104,6 +1104,13 @@ the following lines anywhere in the buffer:
   :version "24.1"
   :type 'boolean)
 
+(defcustom org-cycle-display-inline-images nil
+  "Non-nil means auto display inline images under subtree when `org-cycle'
+by the function `org-display-subtree-with-inline-images' on hook `org-cycle-hook'."
+  :group 'org-startup
+  :version "24.1"
+  :type 'boolean)
+
 (defcustom org-startup-with-latex-preview nil
   "Non-nil means preview LaTeX fragments when loading a new Org file.
 
@@ -16139,6 +16146,42 @@ buffer boundaries with possible narrowing."
 (overlay-put ov 'keymap image-map))
 			  (push ov org-inline-image-overlays
 
+(defun org-display-subtree-inline-images ( state)
+  "Toggle the display of inline images under current expanded visible subtree.
+This hook function will auto display or hide inline images after `org-cycle'.
+It is used to hook on `org-cycle-hook'.
+The function behavior is controlled by `org-cycle-display-inline-images'."
+  (interactive)
+  (when (and org-cycle-display-inline-images
+ ;; not global state change from `org-cycle-global'.
+ (not (memq state '(overview contents all
+(pcase state
+  ('children
+   (save-excursion
+ (save-restriction
+   (org-narrow-to-subtree)
+   ;; If has nested headlines, beg,end only from parent headling
+   ;; to first child headline which reference to upper let-binding
+   ;; `org-next-visible-heading'.
+   (org-display-inline-images t t (point-min) (progn (org-next-visible-heading 1) (point))
+  ('subtree
+   (save-excursion
+ (save-restriction
+   (org-narrow-to-subtree)
+   ;; If has nested headlines, also display inline images under all subtrees.
+   (org-display-inline-images t t (point-min) (point-max)
+  

Re: org-super-agenda global list of TODO items

[Ihor Radchenko]

Angel de Vicente  writes:

> I managed to organize my todo
> items in the daily agenda view without issues, but I'm not sure what I
> have to do to organize the items in the "Global list of TODO items". Is
> this possible? Any examples to point me in the right direction?

Could you please elaborate what you mean by "organize"?

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

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

[Christopher M. Miles]

"Christopher M. Miles"  writes:

> [[PGP Signed Part:Undecided]]
>
> Ihor Radchenko  writes:
>
>> "Christopher M. Miles"  writes:
>>
 When I put it on beginning of org document, then preview inline images, 
 but those global attributes
 not affected. The inline images still display in actual image size. I want 
 to specify image size
 under headline properties. Is it possible to do this?
>>>
>>> I implemented this feature by written a hook. Hope this can be helpful
>>> for someone who also has this needs. Here is the code:
>>
>> This looks useful.
>> Would you be interested to write a patch?
>
> The is the new patch which updated the defcustom variable docstring has 
> correct description.
>
> [2. text/x-patch; 
> 0001-org.el-Add-hook-function-to-auto-display-inline-imag.patch]...

I found an issue of this patch, this patch logic will ignore existing 
~#+ATTR_ORG:~ size. How to let
this patch code also obey the ~#+ATTR_ORG:~ size too?

For example:

* heading 1
:PROPERTIES:
:INLINE-IMAGE-WIDTH: 100
:END:

#+ATTR_ORG: :width 300
#+ATTR_LATEX: :width 3.0in
#+ATTR_HTML: :width 300px
[[file:image-displayed-in-300-width.png]]


[[file:image-displayed-in-100-width.png]]

-- 

[ 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

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

[Christopher M. Miles]

Ihor Radchenko  writes:

> "Christopher M. Miles"  writes:
>
>> Ihor Radchenko  writes:
>>
>>> "Christopher M. Miles"  writes:
>>>
> When I put it on beginning of org document, then preview inline images, 
> but those global attributes
> not affected. The inline images still display in actual image size. I 
> want to specify image size
> under headline properties. Is it possible to do this?

 I implemented this feature by written a hook. Hope this can be helpful
 for someone who also has this needs. Here is the code:
>>>
>>> This looks useful.
>>> Would you be interested to write a patch?
>>
>> The is the new patch which updated the defcustom variable docstring has 
>> correct description.
>
> Thanks for the patch!
> Before extending org-cycle functionality, let's first try to sort out
> subtree-level setting of the image size.

This is implemented by retrieve subtree-level property value in function
~~org-display-inline-image--width~~.

I submitted two separated patches.

>
> In the patch, you are suggesting to use INLINE-IMAGE-WIDTH property.
> However, if we apply the patch as is, this property will only be useful
> when calling a single function -
> `org-display-subtree-with-inline-images'.
> It is not ideal.

The patch's purpose is auto display inline images when [TAB] (~org-cycle~) 
expanding heading or
subtrees. Not for global ~org-toggle-inline-images~. Also, introduce a new 
extra argument "~state~" for
~org-display-inline-images~ like bellowing is not ideal. I think should 
separate the ~org-cycle~ logic
instead of put in ~org-display-inline-images~. In global scope, 
~org-toggle-inline-images~ already
respect the updated function ~org-display-inline-image--width~, it should 
respect the subtree property width.

#+begin_src emacs-lisp
;;   V
;;  -
(defun org-display-inline-images ( state include-linked refresh beg 
end)
  ...)
#+end_src

*NOTE*: Because ~org-cycle-hook~ will pass a ~state~ variable to hook function.

>
> If we introduce subtree-level setting for inline image size, it should
> also work when displaying inline images by other existing means
> (org-toggle-inline-images).

This is implemented by retrieve subtree-level property value in function
~~org-display-inline-image--width~~.

>
> Instead of working around the existing code of
> `org-display-inline-images' and setting a custom
> `org-image-actual-width' variable in buffer, it is much better to change
> `org-display-inline-images' directly. At the end, the patch is not bound
> to your personal config - feel free to alter the existing Org functions.

This is implemented by retrieve subtree-level property value in function
~~org-display-inline-image--width~~.

>
> Similarly, you do not need to do
> (add-to-list 'org-default-properties "INLINE-IMAGE-WIDTH")
> Simply change the default value of `org-default-properties'.

Updated

>
> Finally, it will be more consistent to name the property closer to the
> variable name: ORG-IMAGE-ACTUAL-WIDTH.

Updated

From cc322145c2248e95bc76fee7e6d33f575d93e79f Mon Sep 17 00:00:00 2001
From: stardiviner 
Date: Mon, 12 Sep 2022 09:45:09 +0800
Subject: [PATCH 1/2] org.el: Support subtree-level image width specification

* lisp/org.el (org-display-inline-image--width): Detect subtree-level
property "ORG-IMAGE-ACTUAL-WIDTH" value as image width before fallback.
---
 lisp/org.el | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 6e6c437d5..70333c609 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -12199,7 +12199,8 @@ but in some other way.")
 "EXPORT_OPTIONS" "EXPORT_TEXT" "EXPORT_FILE_NAME"
 "EXPORT_TITLE" "EXPORT_AUTHOR" "EXPORT_DATE" "UNNUMBERED"
 "ORDERED" "NOBLOCKING" "COOKIE_DATA" "LOG_INTO_DRAWER" "REPEAT_TO_STATE"
-"CLOCK_MODELINE_TOTAL" "STYLE" "HTML_CONTAINER_CLASS")
+"CLOCK_MODELINE_TOTAL" "STYLE" "HTML_CONTAINER_CLASS"
+"ORG-IMAGE-ACTUAL-WIDTH")
   "Some properties that are used by Org mode for various purposes.
 Being in this list makes sure that they are offered for completion.")
 
@@ -16241,14 +16242,19 @@ buffer boundaries with possible narrowing."
(org-element-property :begin par)
  (re-search-forward attr-re par-end t)))
   (match-string 1)))
+   ;; support subtree-level property "ORG-IMAGE-ACTUAL-WIDTH" specified width.
+   (subtree-property-width
+(ignore-errors (org-property-or-variable-value 'ORG-IMAGE-ACTUAL-WIDTH)))
(width
 (cond
  ;; Treat :width t as if `org-image-actual-width' were t.
  ((string= attr-width "t") nil)
- ;; Fallback to `org-image-actual-width' if no interprable width is given.
  ((or (null attr-width)
   (string-match-p "\\`[^0-9]" attr-width))
-  (car 

Use lexical-scoping in tests

[Stefan Monnier]

The patch below simply enables `lexical-binding` in all the test files.
As far as I can tell, it's all that's needed (beside a missing
`require`).


Stefan
diff --git a/testing/examples/babel.el b/testing/examples/babel.el
index a7bb0ccf52..cbd522e243 100644
--- a/testing/examples/babel.el
+++ b/testing/examples/babel.el
@@ -1,3 +1,4 @@
+;; -*- lexical-binding: t; -*-
 (string-match-p "^#[[:digit:]]+$" "#123")
 
 ;; [[id:73115FB0-6565-442B-BB95-50195A499EF4][detangle:1]]
diff --git a/testing/lisp/test-ob-C.el b/testing/lisp/test-ob-C.el
index 5f1dd1acb7..793ca31684 100644
--- a/testing/lisp/test-ob-C.el
+++ b/testing/lisp/test-ob-C.el
@@ -1,4 +1,4 @@
-;;; test-ob-C.el --- tests for ob-C.el
+;;; test-ob-C.el --- tests for ob-C.el  -*- lexical-binding: t; -*-
 
 ;; Copyright (c) 2010-2014, 2019 Sergey Litvinov, Thierry Banel
 ;; Authors: Sergey Litvinov, Thierry Banel
diff --git a/testing/lisp/test-ob-R.el b/testing/lisp/test-ob-R.el
index 1e60ae903f..98d73dea91 100644
--- a/testing/lisp/test-ob-R.el
+++ b/testing/lisp/test-ob-R.el
@@ -1,4 +1,4 @@
-;;; test-ob-R.el --- tests for ob-R.el
+;;; test-ob-R.el --- tests for ob-R.el  -*- lexical-binding: t; -*-
 
 ;; Copyright (c) 2011-2014, 2019 Eric Schulte
 ;; Authors: Eric Schulte
diff --git a/testing/lisp/test-ob-awk.el b/testing/lisp/test-ob-awk.el
index 21151b21fc..874d2c0268 100644
--- a/testing/lisp/test-ob-awk.el
+++ b/testing/lisp/test-ob-awk.el
@@ -1,4 +1,4 @@
-;;; test-ob-awk.el --- tests for ob-awk.el
+;;; test-ob-awk.el --- tests for ob-awk.el  -*- lexical-binding: t; -*-
 
 ;; Copyright (c) 2010-2014, 2019 Sergey Litvinov
 ;; Authors: Sergey Litvinov
diff --git a/testing/lisp/test-ob-clojure.el b/testing/lisp/test-ob-clojure.el
index 609fc0ea85..3a21498b4a 100644
--- a/testing/lisp/test-ob-clojure.el
+++ b/testing/lisp/test-ob-clojure.el
@@ -1,4 +1,4 @@
-;;; test-ob-clojure.el
+;;; test-ob-clojure.el  -*- lexical-binding: t; -*-
 
 ;; Copyright (c) 2018-2022 Free Software Foundation, Inc.
 ;; Authors: stardiviner
diff --git a/testing/lisp/test-ob-emacs-lisp.el b/testing/lisp/test-ob-emacs-lisp.el
index e7b85d5ba5..c7bf17784b 100644
--- a/testing/lisp/test-ob-emacs-lisp.el
+++ b/testing/lisp/test-ob-emacs-lisp.el
@@ -1,4 +1,4 @@
-;;; test-ob-emacs-lisp.el
+;;; test-ob-emacs-lisp.el  -*- lexical-binding: t; -*-
 
 ;; Copyright (c) 2012-2022 Free Software Foundation, Inc.
 ;; Authors: Eric Schulte, Martyn Jago
diff --git a/testing/lisp/test-ob-eshell.el b/testing/lisp/test-ob-eshell.el
index d74742690b..4430a21c7a 100644
--- a/testing/lisp/test-ob-eshell.el
+++ b/testing/lisp/test-ob-eshell.el
@@ -1,4 +1,4 @@
-;;; test-ob-eshell.el
+;;; test-ob-eshell.el  -*- lexical-binding: t; -*-
 
 ;; Copyright (c) 2018 stardiviner
 ;; Authors: stardiviner
diff --git a/testing/lisp/test-ob-exp.el b/testing/lisp/test-ob-exp.el
index 1289745aea..b85db33401 100644
--- a/testing/lisp/test-ob-exp.el
+++ b/testing/lisp/test-ob-exp.el
@@ -1,4 +1,4 @@
-;;; test-ob-exp.el
+;;; test-ob-exp.el  -*- lexical-binding: t; -*-
 
 ;; Copyright (c) 2010-2015, 2019 Eric Schulte
 ;; Authors: Eric Schulte
diff --git a/testing/lisp/test-ob-fortran.el b/testing/lisp/test-ob-fortran.el
index 79a35d58e8..3f821e4dac 100644
--- a/testing/lisp/test-ob-fortran.el
+++ b/testing/lisp/test-ob-fortran.el
@@ -1,4 +1,4 @@
-;;; test-ob-fortran.el --- tests for ob-fortran.el
+;;; test-ob-fortran.el --- tests for ob-fortran.el  -*- lexical-binding: t; -*-
 
 ;; Copyright (c) 2010-2014, 2019 Sergey Litvinov
 ;; Authors: Sergey Litvinov
diff --git a/testing/lisp/test-ob-header-arg-defaults.el b/testing/lisp/test-ob-header-arg-defaults.el
index 1106892d55..beb3ea5b8a 100644
--- a/testing/lisp/test-ob-header-arg-defaults.el
+++ b/testing/lisp/test-ob-header-arg-defaults.el
@@ -1,4 +1,4 @@
-;;; test-ob-header-arg-defaults.el --- tests for default header args from properties
+;;; test-ob-header-arg-defaults.el --- tests for default header args from properties  -*- lexical-binding: t; -*-
 
 ;; Copyright (c) 2013, 2014, 2019 Achim Gratz
 ;; Authors: Achim Gratz
diff --git a/testing/lisp/test-ob-java.el b/testing/lisp/test-ob-java.el
index 56ced23740..1a79fc66a1 100644
--- a/testing/lisp/test-ob-java.el
+++ b/testing/lisp/test-ob-java.el
@@ -1,4 +1,4 @@
-;;; test-ob-java.el --- tests for ob-java.el
+;;; test-ob-java.el --- tests for ob-java.el  -*- lexical-binding: t; -*-
 
 ;; Copyright (c) 2020-2022 Free Software Foundation, Inc.
 ;; Authors: Eric Schulte
diff --git a/testing/lisp/test-ob-julia.el b/testing/lisp/test-ob-julia.el
index f6d21726aa..b25235f5fa 100644
--- a/testing/lisp/test-ob-julia.el
+++ b/testing/lisp/test-ob-julia.el
@@ -1,4 +1,4 @@
-;;; test-ob-python.el --- tests for ob-python.el
+;;; test-ob-python.el --- tests for ob-python.el  -*- lexical-binding: t; -*-
 
 ;; Copyright (c) 2011-2014, 2019, 2021 Eric Schulte
 ;; Authors: Pedro Bruel, based on test-ob-python.el by Eric Schulte
diff --git a/testing/lisp/test-ob-lilypond.el b/testing/lisp/test-ob-lilypond.el
index 

Re: per-file (or, really, per buffer) allowing/disallowing code block execution

[Tim Cross]

Greg Minshall  writes:

> Ihor, Fedja, et al.,
>
> i think this is very good.
>
> my suggestion would be to *not* permanently mark a file as safe (i.e., i
> would vote against org-confirm-babel-evaluate-safe-paths); rather, let a
> local variable do that.  i worry about keeping state in "side cars" (if
> one calls them that), as it may be harder for the user to "grep" to find
> why some expected behavior is occurring, etc.
>
> in the "default" setting, asking to evaluate a src block would ask:
> - "yes" [y]
> - "no" [n]
> - "always this buffer" [Y?]
> - "never this buffer" [N?]
>
> the last two would only survive this buffer; once the buffer is closed
> and re-opened, you're back to "default" (unless, of course, there's a
> local variable set).
>
> Ihor, you suggested other meanings for "yes +".  while they all are
> useful, i like the simplicity of just the "always for this buffer".
> and, per-src block seems overkill, and too complicated, too much state
> for the user to remember (but, i'm old, so memory is *always* an issue!
> :).
>
> when the user responds "always this buffer", maybe a message that, if
> they want the same behavior for future buffers of this same file, add a
> local variable.
>
> anyway, that's my 2 cents.
>
> cheers, Greg
>
> ps -- i'm neutral w.r.t. single letter versus word-length, completing
> read, prompts [the above suggestions notwithstanding].

All the points listed here seem reasonable at various levels. However, I
do think we need to be careful not to go too far in the other
direction. If the user wants a foot gun, they should be allowed to have
one, we should not give them one by default though.

There are valid use cases for a configuration which does not require
user interaction (to answer questions on block evaluation), for example,
when you want to process many org files in a batch process without user
interaction. Likewise, I don'tg want Emacs to become too much of a
'nanny'. If I decide the code in a file is safe and permanently safe, I
want to be able to disable the queries on that file permanently. I'm
happy using local variables to do this, though I would also like a
global option as well.

With regard to long or short answers to such questions, I think the
default should be the longer yes/no, but the user should be able to set
it to y/n (i.e. same as normal Emacs behaviour). Ideally, this would
fall under the same setting as the new y-or-n facility in recent emacs
versions (replacing the old approaches like defalias). 

Finally, while I can see there is a use case for being able to have fine
grained control over individual block execution, I don't think having it
as a prompt is the correct approach. Once you have many of these blocks
in a file, that prompt will rapidly become annoying. When I've required
this level of control, I've found header arguments work fine and I'm not
sure the added complexity is worth it.

org-assert-version considered harmful

[Stefan Monnier]

I can see the reason for this macro, and I don't really have a better
solution to offer, but as someone who has a Git clone of Org that is
regularly updated using (basically) the normal compilation
system used in Emacs (i.e. not systematically recompiling all the files,
but only those whose `.el` is more recent than their `.elc`), it means
that whenever Org's version changes, I have to manually erase all the
`.elc` files otherwise this macro will (incorrectly)
complain everywhere  :-(


Stefan

Re: [BUG] org-agenda-list takes 4m compared to 27 that took 15 seconds [9.5.2 (release_9.5.2-25-gaf6f12 @ /usr/share/emacs/28.1/lisp/org/)]

[andrés ramírez]

Hi. Ihor.

> "Ihor" == Ihor Radchenko  writes:


[...]

Ihor> The slowdown is possible as a side-effect of some bugfixes.  However, 
the newest
Ihor> development version of Org should not have these performance issues.

I have just tried 9.6. org-agenda-list generation time was 1m20s. More
than one minute more than emacs-27.

Best Regards
ps: JIC org-9.6snapshot0.20220909.131646.tar

Org version mismatch -- hooray!

[Greg Minshall]

i updated org, and in an existing emacs instance did something (in a
.org file), and got

byte-code: Org version mismatch.  Make sure that correct ‘load-path’ is set 
early in init.el


which i think is great!  thanks very much!

cheers, Greg

Re: [PATCH v2] Re: Adding target and custom id links doesn't ask for description

[Max Nikulin]

On 12/09/2022 18:02, Ihor Radchenko wrote:

Max Nikulin writes:


Unfortunately, your patch does not fix the real issue. The title (not
nil) should be saved for link description when the heading contains the
CUSTOM_ID property. I tried to address it in the following patches:

Max Nikulin. Re: Bug: org-store-link uses CUSTOM_ID instead of target
point. Sat, 6 Nov 2021 19:51:29 +0700.
https://list.orgmode.org/e2c807a7-1924-6f08-9e63-4f70aee9d...@gmail.com


Does it mean that my patch + the patch you linked can be used to fix the
issue reported in this thread?


To fix the #custom_id issue it is enough to commit 2 patches from the 
linked thread: reverting the change caused duplication of stored 
#custom_id links and an alternative fix to store link to <>.


As to <> links, I am unsure what description should be stored 
for <>. I do not think it should be heading title and I do not 
like /full/path/file.org::target that looks strange when file is 
stripped for a link to the same file, but description contains full 
path. I proposed (3rd patch) to store just "target" as description, you 
may prefer nil. Both approaches allows to bypass broken auto-desc logic 
(which I would like to remove) and to show the prompt for description.


I consider your patch as a general improvement because it allows to 
avoid description = link in more cases.

BUG: org-show-context 'lineage not showing direct parent of inlinetask

[Michael Dauer]

This e.g. affects pressing TAB on an inlinetask in the agenda view.

Org mode version 9.5 (9.5-gced2b3

[BUG] org-paste-subtree inserts empty line above paste

[Felix Wiemuth]

Emacs 28.1
Orgmode 9.5.2 (but discovered already 2020-01-20)

When pasting a subtree (of whichever level) with org-paste-subtree at 
any position (can be an empty line or a line with a header prefix, e.g. 
"*** "), always an empty line is inserted above the inserted subtree.


I would expect no new line to be inserted, and I think this was the 
behaviour before I noticed this.


The value of "org-blank-before-new-entry" is "((heading) 
(plain-list-item))".

Re: per-file (or, really, per buffer) allowing/disallowing code block execution

[Greg Minshall]

Ihor, Fedja, et al.,

i think this is very good.

my suggestion would be to *not* permanently mark a file as safe (i.e., i
would vote against org-confirm-babel-evaluate-safe-paths); rather, let a
local variable do that.  i worry about keeping state in "side cars" (if
one calls them that), as it may be harder for the user to "grep" to find
why some expected behavior is occurring, etc.

in the "default" setting, asking to evaluate a src block would ask:
- "yes" [y]
- "no" [n]
- "always this buffer" [Y?]
- "never this buffer" [N?]

the last two would only survive this buffer; once the buffer is closed
and re-opened, you're back to "default" (unless, of course, there's a
local variable set).

Ihor, you suggested other meanings for "yes +".  while they all are
useful, i like the simplicity of just the "always for this buffer".
and, per-src block seems overkill, and too complicated, too much state
for the user to remember (but, i'm old, so memory is *always* an issue!
:).

when the user responds "always this buffer", maybe a message that, if
they want the same behavior for future buffers of this same file, add a
local variable.

anyway, that's my 2 cents.

cheers, Greg

ps -- i'm neutral w.r.t. single letter versus word-length, completing
read, prompts [the above suggestions notwithstanding].

Suggested Syntax for cancelled checkboxes: [-] as non-blocking dependency

[Karl Voit]

Hi,

I was using list checkboxes like that:

- [ ] open task
- [X] closed task
- [-] cancelled task

The latter one is supported via C-u C-u C-c C-c.

However, when I'm using:

(setq org-enforce-todo-checkbox-dependencies t)

... any [-] checkbox will be regarded as non-finished contrary to
the behavior of TODO/DONE/CANCELLED heading states.

As a workaround, I may use:

- +[ ]+ cancelled task

... but this is tedious.

Therefore I'm asking if this might be a viable syntax change:
handling [-] list items similar to CANCELLED headings as
non-blocking when used with org-enforce-todo-checkbox-dependencies.


Tested with Org mode version 9.5.3.

-- 
get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode:
   > get Memacs from https://github.com/novoid/Memacs <
Personal Information Management > http://Karl-Voit.at/tags/pim/
Emacs-related > http://Karl-Voit.at/tags/emacs/

Re: Images in org-mode

[Timothy]

Hi Ihor,

> Max Nikulin  writes:
>
>> Matt Huszagh. [PATCH] Fix regex for determining image width from
>> attribute. Sun, 21 Nov 2021 11:08:54 -0800.
>> 
>
> Did it get merged? There are several patches proposed in that thread,
> but I do not see them being actually merged upstream.

Mmm, that thread ends with me proposing a specific approach and Matt saying it
sounds good (, quoted below),
but from there no further patches are provided (unless I missed something).

  > Thanks for continuing with this. Moving forward, I think it would be 
best to:
  > ⁃ Make a patch just for prioritising `#+attr_org’
  > ⁃ Make a patch just improving the regex (before or after the 
`#+attr_org’ patch)
  > ⁃ Discuss changing the behaviour of image previews separately later / 
in another
  >   thread, linking to this thread when doing so.
  >
  > How does that sound?

  Yep, sounds good.

All the best,
Timothy

Re: Report error in scheme evaluation

[Ihor Radchenko]

Felipe Lema  writes:

> Let me know if I'm missing anything so this can be merged. It is correct to 
> report errors this way, right?

I am going through old patch submission that have not been resolved.
Note that this is not a patch, but a diff.

Also,

> +  (when-let* ((err (geiser-eval--retort-error ret)))

err variable binding here is unused in the code.
Is it an oversight?

-- 
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: Images in org-mode

[Ihor Radchenko]

Max Nikulin  writes:

> Matt Huszagh. [PATCH] Fix regex for determining image width from 
> attribute. Sun, 21 Nov 2021 11:08:54 -0800. 
> https://list.orgmode.org/87czmtuy0p@gmail.com

Did it get merged? There are several patches proposed in that thread,
but I do not see them being actually merged upstream.

-- 
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 v2] Re: Adding target and custom id links doesn't ask for description

[Ihor Radchenko]

Max Nikulin  writes:

> Unfortunately, your patch does not fix the real issue. The title (not 
> nil) should be saved for link description when the heading contains the 
> CUSTOM_ID property. I tried to address it in the following patches:
>
> Max Nikulin. Re: Bug: org-store-link uses CUSTOM_ID instead of target 
> point. Sat, 6 Nov 2021 19:51:29 +0700. 
> https://list.orgmode.org/e2c807a7-1924-6f08-9e63-4f70aee9d...@gmail.com

Does it mean that my patch + the patch you linked can be used to fix the
issue reported in this thread?

-- 
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] New: auto display inline images under subtree when `org-cycle'.

[Ihor Radchenko]

"Christopher M. Miles"  writes:

> Ihor Radchenko  writes:
>
>> "Christopher M. Miles"  writes:
>>
 When I put it on beginning of org document, then preview inline images, 
 but those global attributes
 not affected. The inline images still display in actual image size. I want 
 to specify image size
 under headline properties. Is it possible to do this?
>>>
>>> I implemented this feature by written a hook. Hope this can be helpful
>>> for someone who also has this needs. Here is the code:
>>
>> This looks useful.
>> Would you be interested to write a patch?
>
> The is the new patch which updated the defcustom variable docstring has 
> correct description.

Thanks for the patch!
Before extending org-cycle functionality, let's first try to sort out
subtree-level setting of the image size.

In the patch, you are suggesting to use INLINE-IMAGE-WIDTH property.
However, if we apply the patch as is, this property will only be useful
when calling a single function -
`org-display-subtree-with-inline-images'.
It is not ideal.

If we introduce subtree-level setting for inline image size, it should
also work when displaying inline images by other existing means
(org-toggle-inline-images).

Instead of working around the existing code of
`org-display-inline-images' and setting a custom
`org-image-actual-width' variable in buffer, it is much better to change
`org-display-inline-images' directly. At the end, the patch is not bound
to your personal config - feel free to alter the existing Org functions.

Similarly, you do not need to do
(add-to-list 'org-default-properties "INLINE-IMAGE-WIDTH")
Simply change the default value of `org-default-properties'.

Finally, it will be more consistent to name the property closer to the
variable name: ORG-IMAGE-ACTUAL-WIDTH.

-- 
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-blank-field keybinding [9.5.4 (N/A @ /gnu/store/sry9khwisaq1jnrjbfnhx6ki8qy2z0db-emacs-org-9.5.4/share/emacs/site-lisp/org-9.5.4/)]

[Ihor Radchenko]

Bastien, could you kindly confirm that this kind of patch fits into
TINYCHANGE? The changes are trivial, so we should not need to look at
the line count here, right?

André A. Gomes  writes:

> Also, it might be worth mentioning in the manual that this command works
> when a region is selected.

 Indeed M-x  does work when region is selected. Just
 as documented.
>>>
>>> I meant in the manual, not in the docstring.  But perhaps it does
>>> suffice as it is.
>>
>> Would you mind making a patch for the manual?
>> See https://orgmode.org/worg/org-contribute.html
>
> Please find the patch attached.  Thanks.

The patch appears to be for
https://orgmode.org/list/878s1xupey@gmail.com
André A. Gomes  (2021-07-23)
Subject: Headings and Headlines

where we agreed to rename "headline" to "heading" in the manual,
function names, and comments.

Note that this thread is about a different manual issue -
org-table-blank-field documentation.

In any case, thank you very much for the patch. Even though it is
related to a different email thread, it is still providing an improvement
to our manual.

Note that "Fix documentation" is very vague. In future, please try to be
more specific about what the patch does. E.g.

Rename "headline" to "heading" in documentation

You can refer to
https://orgmode.org/worg/org-contribute.html#commit-messages for the
conventions we use in the commit messages.

I am not yet merging the patch until Bastien confirms that the patch can
be marked TINYCHANGE and does not require copyright assignment (see
https://orgmode.org/worg/org-contribute.html#copyright). Otherwise, the
patch looks good.

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

org-super-agenda global list of TODO items

[Angel de Vicente]

Hello,

I just learnt about org-super-agenda today and it looks brilliant to
keep my agenda a bit better organized. But I tend to use the "C-c a h"
to view the daily agenda and the tasks. I managed to organize my todo
items in the daily agenda view without issues, but I'm not sure what I
have to do to organize the items in the "Global list of TODO items". Is
this possible? Any examples to point me in the right direction?

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