Re: [WORG] 2680e65 * org-maintenance.org (Copyright assignments): Minor improvements

[Samuel Wales]

not following this.

but it amused me:

>>   In rare cases, an inquiry from an
>> +Org maintainer gets the process moving again.
>
> may be missing something, but the last sentence now reads like our
>(Org maintainer's) inquiry rarely works.

while it can definitely read that way, to me as a native speaker at least,
it is reasonably ok, although ambiguous.  it is saying, somewhat casually,
that in rare cases it is /needed/ for the org maintainer to intervene and
he or she does so successfully or so.  removing ambiguity would  help, but
nto a huge deal.

apropos of nothing, ambiguity should be eliminated from medical textbooks
and papers.  "rarely, " can be interpreted like, it's rare so look for
horses not zebras [neglecting that zebras exist], or it's rare but consider
it and find out more about it, or various other things.



-- 
The Kafka Pandemic

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

Re: [WORG] 2680e65 * org-maintenance.org (Copyright assignments): Minor improvements

[Adam Porter]

On 4/2/24 06:20, Ihor Radchenko wrote:

I just looked into changing this TODO into inlinetask and that would 
require adding a style for inlinetasks. While looking, I noticed a 
commented section in worg-editing.org:


...

Also, the above macros may we one existing way to provide
highlighting we discussed earlier.

WDYT?


A few thoughts:

1.  Having to use separate BEGIN and END macros is less convenient than 
more Lispy constructs, like a macro call with a string argument.  But I 
guess, to wrap Org elements, like a TODO heading or inline task, it 
would be necessary.  A macro call with the text as an argument wouldn't 
be a task in Org syntax, which would make it less useful outside of 
rendered HTML.


2.  Those macros, or one much like them, could be useful for the use 
case of centering text to stand out, as discussed in the other thread.


3.  For cases that don't potentially involve wrapping Org elements, 
having a simple macro with the text as its argument might be preferable 
to having separate BEGIN and END macros.  I wonder if we could have 
non-begin-end equivalents of the begin-and-end macros listed there.


--Adam

Re: [PATCH] lisp/ox-html.el: Add avif support for html export inline images

[Adam Porter]

Hi Ihor,

I noticed what appears to be a typo in this commit: 
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=1be2f9693



+*** =.avif= images are not recognized in ~org-html-inline-image-rules~
  ^

Unless I misunderstand something, I guess it's supposed to say "now 
recognized."  :)


--Adam

[PATCH] org-manual: Document Org Plot option "timeind"

[Morgan Smith]

* doc/org-manual.org (Plot options): Document "timeind".  Also fix the
formatting for a couple other entries.
---
 doc/org-manual.org | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index ad5c85e2a..69c760c8b 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -2991,6 +2991,11 @@  Plot options
 
   Specify which column of the table to use as the =x= axis.
 
+- =timeind= ::
+
+  Specify which column of the table to use as the =x= axis as a time
+  value.
+
 - =deps= ::
 
   Specify the columns to graph as a Lisp style list, surrounded by
@@ -2998,7 +3003,7 @@  Plot options
   the third and fourth columns.  Defaults to graphing all other
   columns aside from the =ind= column.
 
-- transpose ::
+- =transpose= ::
 
   When =y=, =yes=, or =t= attempt to transpose the table data before
   plotting.  Also recognizes the shorthand option =trans=.
@@ -3033,21 +3038,21 @@  Plot options
   When plotting =3d= or =grid= types, set this to =t= to graph a flat
   mapping rather than a =3d= slope.
 
-- min ::
+- =min= ::
 
   Provides a minimum axis value that may be used by a plot type.
   Implicitly assumes the =y= axis is being referred to.  Can
   explicitly provide a value for a either the =x= or =y= axis with
   =xmin= and =ymin=.
 
-- max ::
+- =max= ::
 
   Provides a maximum axis value that may be used by a plot type.
   Implicitly assumes the =y= axis is being referred to.  Can
   explicitly provide a value for a either the =x= or =y= axis with
   =xmax= and =ymax=.
 
-- ticks ::
+- =ticks= ::
 
   Provides a desired number of axis ticks to display, that may be used
   by a plot type.  If none is given a plot type that requires ticks
-- 
2.41.0

Re: [BUG] FAILED test-ob-python/session-multiline

[Ihor Radchenko]

Ihor Radchenko  writes:

> Jack Kamm  writes:
>
>> Ihor Radchenko  writes:
>>
>> ...
>> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=1eb598758980d5fa4d7bb21c98dfc56f42cae59a
>>
>> Please let me know whether the problem continues, or whether it seems to
>> improve.
>
> As soon as we fix CI :/ I think it is not working for the last month.

I am no longer seeing the failures.
Fixed.

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

Re: [BUG] org-export-table-row-number off by one when special row present [9.6.23 ( @ /home/jet/.config/emacs/elpa/org-9.6.23/)]

[Ihor Radchenko]

Jeff Trull  writes:

>> During export, table may be not the same as it appears in the original
>> document - some rows may be omitted. `org-export-table-row-number'
>> returns the coordinates in as-exported table, not in the original table.
>>
>
> Agreed. I believe this behavior contradicts its documentation string:
>
> "... Return value is zero-indexed and ignores separators.  The function
> returns nil
> for special rows and separators."
>
> The language is different for what rows are ignored ("separators") and for
> what cells it will
> return nil ("special rows and separators"). This is consistent with the
> user-facing addresses,
> which do not consider separator rows, but do consider column alignment rows.

What about the attached patch?
>From 6457e6e3a9c112b9a1bc3a549a93f3cd6a64b2c3 Mon Sep 17 00:00:00 2001
Message-ID: <6457e6e3a9c112b9a1bc3a549a93f3cd6a64b2c3.1712062152.git.yanta...@posteo.net>
From: Ihor Radchenko 
Date: Tue, 2 Apr 2024 15:49:01 +0300
Subject: [PATCH] lisp/ox.el (org-export-table-row-number): Clarify docstring

---
 lisp/ox.el | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lisp/ox.el b/lisp/ox.el
index c794c570f..8c7e092e3 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -5432,7 +5432,8 @@ (defun org-export-table-row-number (table-row info)
   "Return TABLE-ROW number.
 INFO is a plist used as a communication channel.  Return value is
 zero-indexed and ignores separators.  The function returns nil
-for special rows and separators."
+for separators and table rows that are marked to be ignored according
+to the INFO plist."
   (when (eq (org-element-property :type table-row) 'standard)
 (let* ((cache (or (plist-get info :table-row-number-cache)
 		  (let ((table (make-hash-table :test #'eq)))
-- 
2.44.0


> In this case, it's not specific to any exporter. org-export--skip-p returns
> true for column alignment rows with the following code:
>
> (table-cell
>  (and (org-export-table-has-special-column-p
>   (org-export-get-parent-table datum))
>  (org-export-first-sibling-p datum options)))

This part of the code is not for alignment rows, it is for special
columns.

> So these rows will be in the ignore-list for all exporters.

This is no longer true on main.

> ... And that's reasonable - when ignore-list is being used for
> deciding what to export. The problem, as I see it, is that
> org-export-table-row-number does not consider this when determining
> the "address" of a cell.

?? `org-export-table-row-number' considers the ignore list because
`org-element-map' considers it.

> So, there is no bug here.
>>
>
> I  disagree :) and suggest the following change to org-export-row-number
> (line 5390):
>
> info))
>
> should become:
>
>   (org-plist-delete info 'ignore-list)))
>
> which will make it consistent with its docstring and with user-facing
> addresses.

The docstring should be fixed, not the function behaviour.

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

Re: [FR] 'org-columns-next-allowed-value' for 'summary-checkbox'es functions should have 'intermediate state' '[-]'

[Ihor Radchenko]

Sławomir Grochowski  writes:

> After careful consideration, I believe it is most prudent to only
> introduce a defcustom variable. This will allow for modification while
> simultaneously preserving the current behavior.
> ...
> What do you think?
> Patch in attachment.

This patch will be an improvement.

> ...
> +*** New option ~org-columns-checkbox-states~
> +
> +This would allow to use more than two states ("[ ]", "[X]") in 
> "org-columns-checkbox".
> +In e.g to add an intermediate state ("[-]") which is also present in 
> "org-checkbox".

It is not very clear when this feature is useful. May you provide a
small example as a part of the news entry and also
`org-columns-checkbox-states' docstring?

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

Re: [FR] 'org-columns-next-allowed-value' for 'summary-checkbox'es functions should have 'intermediate state' '[-]'

[Sławomir Grochowski]

After careful consideration, I believe it is most prudent to only
introduce a defcustom variable. This will allow for modification while
simultaneously preserving the current behavior.

Currently we can change the value of "org-columns-checkbox" with the
following keybindings:

(1)C-c C-c (org-columns-toggle-or-columns-quit)

   Same behavior to toggle checkbox as 'C-c C-c (org-toggle-checkbox)' on
   "org-checkbox".

   It's a great idea that keybinding works in the same way as in the
   case of a regular checkbox. This provides a consistent interface
   for the "org-checkbox" and "org-columns-checkbox".
   
   So every user who starts using "org-columns" will try to use the same
   keybinding they used for "org-checkbox". That's how I used it too.

   But I would not implement other keybindings from "org-checkbox":
   C-u C-c C-c (org-toggle-checkbox) - add or remove checkboxes.
   C-u C-u C-c C-c (org-toggle-checkbox) - set the checkbox to "[-]".
   Because there are too complicated and uncomfortable.
   And this functionality can be easily replaced by adding defcustom
   variable and using keybinding describe in point (3) of this mail.  

(2)n or S-RIGHT (org-columns-next-allowed-value)
   p or S-LEFT (org-columns-previous-allowed-value)

   Later on, I started using S-RIGHT & S-LEFT. It's simply more
   convenient than 'C-c C-c' because in "org-columns" we navigate
   with arrow keys. So, the right hand is always on the arrow keys, making
   it easier now to press just one SHIFT key with the left hand to
   change the value.

   When we have the default two states "[X]" and "[ ]", behavior is
   same as 'C-c C-c' - toggle within these two states. 

   But if we add the third state "[-]", it might not be
   well-received by users who use these keybindings, because now they
   would have to additionally cycle between those three states, not
   just two. And unfortunately, they wouldn't be able to change
   it. That's why I believe it's worth introducing a defcustom
   variable.

(3)1..9,0 

   "Directly select the Nth allowed value, 0 selects the 10th
   value." 

   Now that's how I change the values in the "org-columns-checkbox".
   Because it's by far the fastest, simplest, and most convenient
   way. Only one key and I immediately have the state I want.

   Right now I'm using 4 states for "org-columns-checkbox":
   (setq org-columns-checkbox-states '("[X]" "[-]" "[ ]" "" ))

   So empty state "" at digit '4' I have option to remove checkbox.
   Digit '2' is "[-]".
   Super easy and convenient in comparison to:
   C-u C-c C-c (org-toggle-checkbox) - add or remove checkboxes.
   C-u C-u C-c C-c (org-toggle-checkbox) - set the checkbox to
   "[-]".

What do you think?
Patch in attachment.

>From 6f8e56cb3d20977e0f4c77c1be913dfb61480cfc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C5=82awomir=20Grochowski?= 
Date: Sat, 16 Mar 2024 13:29:53 +0100
Subject: [PATCH] lisp/org-colview.el: Add defcustom
 `org-columns-checkbox-states'

* lisp/org-colview.el Add defcustom `org-columns-checkbox-states'.
(org-columns-next-allowed-value): Introduce variable `org-columns-checkbox-states'.

This would allow to use more than two states ("[ ]", "[X]") in "org-columns-checkbox".
In e.g to add an intermediate state ("[-]") which is also present in "org-checkbox".

* etc/ORG-NEWS New option ~org-columns-checkbox-states~
---
 etc/ORG-NEWS| 5 +
 lisp/org-colview.el | 7 ++-
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index ca73f06e7..1cb4b0c8e 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -1753,6 +1753,11 @@ following properties: ~:hook~, ~:prepare-finalize~,
 prior to their global counterparts for the selected template.
 
 ** New options
+*** New option ~org-columns-checkbox-states~
+
+This would allow to use more than two states ("[ ]", "[X]") in "org-columns-checkbox".
+In e.g to add an intermediate state ("[-]") which is also present in "org-checkbox".
+
 *** A new option for custom setting ~org-refile-use-outline-path~ to show document title in refile targets
 
 Setting ~org-refile-use-outline-path~ to ~'title~ will show title
diff --git a/lisp/org-colview.el b/lisp/org-colview.el
index d71c84a76..eac85d3d6 100644
--- a/lisp/org-colview.el
+++ b/lisp/org-colview.el
@@ -59,6 +59,11 @@
 
 ;;; Configuration
 
+(defcustom org-columns-checkbox-states '("[ ]" "[X]")
+  "Checkbox states to cycle between."
+  :group 'checkbox
+  :type '(repeat string))
+
 (defcustom org-columns-modify-value-for-display-function nil
   "Function that modifies values for display in column view.
 For example, it can be used to cut out a certain part from a time stamp.
@@ -737,7 +742,7 @@ an integer, select that value."
 	  (let ((all
 		 (or (org-property-get-allowed-values pom key)
 		 (pcase (nth column 

Re: [WORG] 2680e65 * org-maintenance.org (Copyright assignments): Minor improvements

[Ihor Radchenko]

Adam Porter  writes:

>> I am inclined to remove this todo - I already asked gnulib guys and they
>> contacted FSF about the latest version of the form. Until we get a
>> reply, there is nothing we can act upon. See
>> https://lists.gnu.org/archive/html/bug-gnulib/2024-03/msg00060.html
>
> FWIW, I'd be inclined to leave the task for future action, perhaps 
> changing it to a WAITING keyword with a state-change note explaining the 
> status (that's what I use in my system, anyway).  But if you disagree, I 
> won't argue.

I do not mind. I can also add a link to my email there.

I just looked into changing this TODO into inlinetask and that would
require adding a style for inlinetasks. While looking, I noticed a
commented section in worg-editing.org:

- BeginMiniPage ... EndMiniPage :: creates a mini page with a border. Used 
to
 demonstrate layouts (see: 
[[file:./org-tutorials/images-and-xhtml-export.org]] for
 an example).

- BeginInfoBox ... EndInfoBox :: inserts a box with a little info icon on 
the
 left. The text inside flows around the icon. Both, info and warning 
boxes,
 use the styles for =.org-info-box= in 
[[file:style/worg.css][worg.css]].

- BeginWarningBox ... EndWarningBox :: Like =BeginInfoBox= and 
=EndInfoBox=. The
 icon used is different.

- BeginBlindText ... EndBlindText :: creates a == element, that
 greys out the text. Used for text that is there just to fill paragraphs
 to demonstrate text flow (see:
 [[file:./org-tutorials/images-and-xhtml-export.org]] for an example).

In particular, BeginWarningBox (see
https://orgmode.org/worg/org-tutorials/images-and-xhtml-export.html)
might be a basis of inlinetask css.

Or we may be copy the style from ox-html.

Also, the above macros may we one existing way to provide highlighting
we discussed earlier.

WDYT?

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