[PATCH] Create commands for org-read-date-minibuffer-local-map

2024-03-25 Thread Laurence Warne
Hi,

I have attached a small patch which switches out inline commands in
org-read-date-minibuffer-local-map for new analogous commands.

The intent is to aid documentation and user configuration, so the user gets
a nice description and source code when any corresponding key is looked up
via help, and can rebind it without copying the lambda themselves.

Any comments are welcome!

Thanks, Laurence
From f10dc28a72c8c0fb179b0446b4869c71b24c4e52 Mon Sep 17 00:00:00 2001
From: Laurence Warne 
Date: Sun, 24 Mar 2024 15:10:25 +
Subject: [PATCH] Create commands for org-read-date-minibuffer-local-map

Create commands for org-read-date-minibuffer-local-map for use in
place of the inline lambda commands in order to aid user discoverability.

* org.el (org-calendar-goto-today-or-insert-dot)
(org-calendar-goto-today, org-calendar-backward-month)
(org-calendar-forward-month, org-calendar-backward-year)
(org-calendar-forward-year, org-calendar-backward-week)
(org-calendar-forward-week, org-calendar-backward-day)
(org-calendar-forward-day, org-calendar-view-entries)
(org-calendar-scroll-month-left, org-calendar-scroll-month-right)
(org-calendar-scroll-three-months-left)
(org-calendar-scroll-three-months-right): New functions
* org-keys.el (org-read-date-minibuffer-local-map): Use new functions
for keybindings instead of inline functions
---
 lisp/org-keys.el | 99 +---
 lisp/org.el  | 86 +
 2 files changed, 120 insertions(+), 65 deletions(-)

diff --git a/lisp/org-keys.el b/lisp/org-keys.el
index eb5b98726..50e05efa1 100644
--- a/lisp/org-keys.el
+++ b/lisp/org-keys.el
@@ -90,6 +90,21 @@
 (declare-function org-end-of-line "org" ( n))
 (declare-function org-entry-put "org" (pom property value))
 (declare-function org-eval-in-calendar "org" (form  keepdate))
+(declare-function org-calendar-goto-today-or-insert-dot "org" ())
+(declare-function org-calendar-goto-today "org" ())
+(declare-function org-calendar-backward-month "org" ())
+(declare-function org-calendar-forward-month "org" ())
+(declare-function org-calendar-backward-year "org" ())
+(declare-function org-calendar-forward-year "org" ())
+(declare-function org-calendar-backward-week "org" ())
+(declare-function org-calendar-forward-week "org" ())
+(declare-function org-calendar-backward-day "org" ())
+(declare-function org-calendar-forward-day "org" ())
+(declare-function org-calendar-view-entries "org" ())
+(declare-function org-calendar-scroll-month-left "org" ())
+(declare-function org-calendar-scroll-month-right "org" ())
+(declare-function org-calendar-scroll-three-months-left "org" ())
+(declare-function org-calendar-scroll-three-months-right "org" ())
 (declare-function org-evaluate-time-range "org" ( to-buffer))
 (declare-function org-export-dispatch "org" ( arg))
 (declare-function org-feed-goto-inbox "org" (feed))
@@ -349,71 +364,25 @@ COMMANDS is a list of alternating OLDDEF NEWDEF command names."
 (defvar org-read-date-minibuffer-local-map
   (let* ((map (make-sparse-keymap)))
 (set-keymap-parent map minibuffer-local-map)
-(org-defkey map (kbd ".")
-(lambda () (interactive)
-		  ;; Are we at the beginning of the prompt?
-		  (if (looking-back "^[^:]+: "
-(let ((inhibit-field-text-motion t))
-  (line-beginning-position)))
-		  (org-eval-in-calendar '(calendar-goto-today))
-		(insert "."
-(org-defkey map (kbd "C-.")
-(lambda () (interactive)
-		  (org-eval-in-calendar '(calendar-goto-today
-(org-defkey map (kbd "M-S-")
-(lambda () (interactive)
-  (org-eval-in-calendar '(calendar-backward-month 1
-(org-defkey map (kbd "ESC S-")
-(lambda () (interactive)
-  (org-eval-in-calendar '(calendar-backward-month 1
-(org-defkey map (kbd "M-S-")
-(lambda () (interactive)
-  (org-eval-in-calendar '(calendar-forward-month 1
-(org-defkey map (kbd "ESC S-")
-(lambda () (interactive)
-  (org-eval-in-calendar '(calendar-forward-month 1
-(org-defkey map (kbd "M-S-")
-(lambda () (interactive)
-  (org-eval-in-calendar '(calendar-backward-year 1
-(org-defkey map (kbd "ESC S-")
-(lambda () (interactive)
-  (org-eval-in-calendar '(calendar-backward-year 1
-(org-defkey map (kbd "M-S-")
-(lambda () (interactive)
-  (org-eval-in-calendar '(calendar-forward-year 1
-(org-defkey map (kbd "ESC S-")
-(lambda () (interactive)
-  (org-eval-in-calendar '(calendar-forward-year 1
-(org-defkey map (kbd "S-")
-(lambda () (interactive)
-  (org-eval-in-calendar '(calendar-backward-week 1
-(org-defkey map (kbd "S-")
-(lambda () (interactive)
- 

Re: [BUG] org-clock-sum: Wrong type argument: fixnump, nil [9.7-pre (release_9.6.22-1309-g8507ef @ /home/grfz/src/org-mode/lisp/)]

2024-03-25 Thread Gregor Zattler
Hi Ihor,
* Ihor Radchenko  [2024-03-25; 18:20 GMT]:
> Gregor Zattler  writes:
>
>> I did
>>
>> rm -rf *; git checkout -f; make repro
>>
>> in ~/src/org-mode.  make repro is very quick.
>>
>> Then I tested again with the above mentioned clock
>> table frame and emacs command line invocation: Same
>> result.  No backtrace.
>>
>> Am I missing something?
>
> Looks like some caller is intercepting errors, demoting them to messages.
>
> What happens if you run M-: (org-clock-sum)  directly in the
> problematic buffer?

on the clock table frame?

0 (#o0, #x0, ?\C-@)

I don't know what that means.

In the file.org_archive, with point on a clock line:

Debugger entered--Lisp error: (wrong-type-argument fixnump nil)
  encode-time((0 nil nil nil nil nil nil -1 nil))
  (float-time (encode-time (list 0 (org-element--property :minute-start 
timestamp nil nil) (org-element--property :hour-start timestamp nil nil) 
(org-element--property :day-start timestamp nil nil) (org-element--property 
:month-start timestamp nil nil) (org-element--property :year-start timestamp 
nil nil) nil -1 nil)))
  (let* ((timestamp (org-element--property :value element nil nil)) (ts 
(float-time (encode-time (list 0 (org-element--property :minute-start timestamp 
nil nil) (org-element--property :hour-start timestamp nil nil) 
(org-element--property :day-start timestamp nil nil) (org-element--property 
:month-start timestamp nil nil) (org-element--property :year-start timestamp 
nil nil) nil -1 nil (te (float-time (encode-time (list 0 
(org-element--property :minute-end timestamp nil nil) (org-element--property 
:hour-end timestamp nil nil) (org-element--property :day-end timestamp nil nil) 
(org-element--property :month-end timestamp nil nil) (org-element--property 
:year-end timestamp nil nil) nil -1 nil (dt (- (if tend (min te tend) te) 
(if tstart (max ts tstart) ts (if (> dt 0) (progn (setq t1 (+ t1 (floor dt 
60))
  (cond ((and (eq element-type 'clock) (match-end 2)) (let* ((timestamp 
(org-element--property :value element nil nil)) (ts (float-time (encode-time 
(list 0 ... ... ... ... ... nil -1 nil (te (float-time (encode-time (list 0 
... ... ... ... ... nil -1 nil (dt (- (if tend (min te tend) te) (if tstart 
(max ts tstart) ts (if (> dt 0) (progn (setq t1 (+ t1 (floor dt 60))) 
((match-end 4) (setq t1 (+ t1 (string-to-number (match-string 5)) (* 60 
(string-to-number (match-string 4)) ((memq element-type '(headline 
inlinetask)) (if (and org-clock-report-include-clocking-task (eq 
(org-clocking-buffer) (current-buffer)) (eq (marker-position 
org-clock-hd-marker) (point)) tstart tend (>= (float-time org-clock-start-time) 
tstart) (<= (float-time org-clock-start-time) tend)) (progn (let ((time (floor 
... 60))) (setq t1 (+ t1 time) (let* ((headline-forced (get-text-property 
(point) :org-clock-force-headline-inclusion)) (headline-included (or (null 
headline-filter) (save-excursion (let ... ...) (setq level (- (match-end 1) 
(match-beginning 1))) (if (>= level lmax) (progn (progn (setq ltimes (vconcat 
ltimes ...)) (setq lmax (* 2 lmax) (if (or (> t1 0) (> (aref ltimes level) 
0)) (progn (if (or headline-included headline-forced) (progn (if 
headline-included ...) (setq time ...) (goto-char ...) (put-text-property ... 
... ... time) (if headline-filter ...))) (setq t1 0) (let* ((l level) 
(--cl-var-- ...)) (while (<= l --cl-var--) (aset ltimes l 0) (setq l ...)) 
nil))
  (let* ((element (let ((saved-match-data (match-data))) (unwind-protect (progn 
(org-element-at-point)) (set-match-data saved-match-data t (element-type 
(org-element-type element))) (cond ((and (eq element-type 'clock) (match-end 
2)) (let* ((timestamp (org-element--property :value element nil nil)) (ts 
(float-time (encode-time ...))) (te (float-time (encode-time ...))) (dt (- (if 
tend ... te) (if tstart ... ts (if (> dt 0) (progn (setq t1 (+ t1 ...)) 
((match-end 4) (setq t1 (+ t1 (string-to-number (match-string 5)) (* 60 
(string-to-number (match-string 4)) ((memq element-type '(headline 
inlinetask)) (if (and org-clock-report-include-clocking-task (eq 
(org-clocking-buffer) (current-buffer)) (eq (marker-position 
org-clock-hd-marker) (point)) tstart tend (>= (float-time org-clock-start-time) 
tstart) (<= (float-time org-clock-start-time) tend)) (progn (let ((time ...)) 
(setq t1 (+ t1 time) (let* ((headline-forced (get-text-property (point) 
:org-clock-force-headline-inclusion)) (headline-included (or (null 
headline-filter) (save-excursion ... (setq level (- (match-end 1) 
(match-beginning 1))) (if (>= level lmax) (progn (progn (setq ltimes ...) (setq 
lmax ... (if (or (> t1 0) (> (aref ltimes level) 0)) (progn (if (or 
headline-included headline-forced) (progn ... ... ... ... ...)) (setq t1 0) 
(let* (... ...) (while ... ... ...) nil)))
  (while (re-search-backward re nil t) (let* ((element (let ((saved-match-data 
(match-data))) (unwind-protect (progn (org-element-at-point)) 

Re: [BUG] org-clock-sum: Wrong type argument: fixnump, nil [9.7-pre (release_9.6.22-1309-g8507ef @ /home/grfz/src/org-mode/lisp/)]

2024-03-25 Thread Ihor Radchenko
Gregor Zattler  writes:

> I did
>
> rm -rf *; git checkout -f; make repro
>
> in ~/src/org-mode.  make repro is very quick.
>
> Then I tested again with the above mentioned clock
> table frame and emacs command line invocation: Same
> result.  No backtrace.
>
> Am I missing something?

Looks like some caller is intercepting errors, demoting them to messages.

What happens if you run M-: (org-clock-sum)  directly in the
problematic buffer?

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



Re: Pending contents in org documents (Re: Asynchronous blocks for everything (was Re: ...))

2024-03-25 Thread Bruno Barbier


Hi Ihor,

Thanks for your review and detailed explanations.

I've pushed an update that should address most of your comments.

Let me answer point by point below.

Ihor Radchenko  writes:

> Bruno Barbier  writes:
>
>>> I feel that org-pending-penreg (org-pending-) is
>>> redundant. Maybe better use org-pending-region?
>>
>> PENREG is the name of the structure; the "org-pending" is the
>> mandatory library prefix; this mechanically gives the name.  A PENDREG
>> object is not a "region" in Emacs sense.
>>
>> Do you see a better name for the structure PENREG, so that it doesn't
>> sound like a "region" ?
>
> Library prefix is also a part of the name and delivers useful
> information. "org-pending-region" and "region" and not the same names.
>
> We make use of prefix semantic in various places:
> - org-export-backend, implying not just "backend", but also "export"
> - org-cite-processor, implying not just "processor", but also "cite"
> - org-lint-checker - "org-lint" + "checker"
> - org-element-deferred - "org-element" + "deferred"
>
> So, there is no need to duplicate information from the prefix - it is an
> integral part of the struct name. Doing otherwise would go again the
> existing naming in Org code base.

Got it. Thanks for the explanation.

I've found a better name: I'm now calling it a "lock".  So I renamed
"PENREG" into "REGLOCK" as "region lock".  The structure is now
`org-pending-reglock'.


>>> 1. It is not clear why you need a separate ~virtual~ field. When
>>>~region~ is nil it already implies that the pending region is
>>>virtual.
>>
[...]
> Also, ~virtual~ field is unused. So, maybe we can even drop it
> completely. We can always add new fields in future, if a need arises.

The region is not allowed to be nil anymore. All "virtual" issues
are solved! :)


>>> 3. ~source~ field must match the ~region~ marker buffer. Then, why do we
>>>need this field at all? May as well just use (marker-buffer (car region))
>>
>> The "source" is the region requesting the update.
>
> The docstring of `org-pending' states that it is a buffer position:
>
> The SOURCE is the buffer position that requested this pending region.

Sorry. It was, yes.

>> ... The pending region
>> is the "target" of the update, i.e. the region that will be updated.
>>
>>
>> For example, in DEMO_ONLY, with org-babel, these 2 regions are never
>> the same:
>>1. the source is the source code block,
>>2. the target (pending region) is the result region.
>
> I am wondering why source must be a buffer position.
> What if we want to mark a region pending for some task not associated
> with a source? And why do we need to know the source at all?

Good point. It was to allow the user to quickly jump to the source
code block; I removed it from org-pending.



>>  2. insert-details: If, and only if, the user decides to
>>  investigate what happened, Emacs will ask the task if it has any
>>  details to add, that might help the user (like exit-code for an
>>  OS process, stderr for an OS process or link to a log file, etc.)
>
> I have to say that I am confused about "insert-details" part. Mostly
> because it is not per se connected to the associated task. It is rather
> an additional handler used to provide debug information about the task
> status and outcome.
> AFAIU, it is conceptually very similar to HANDLE-RESULT function.

You're right: it was confusing.  It's now like a hook, that
org-pending-describe-reglock will use.  It should now be clearer that
it's for "information purposes" only.


> I think that rather than handing HANDLE-RESULT and also TASK-CONTROL, we
> may reduce everything to a single "handler" object that will serve as a
> way for PENREG to communicate back to Elisp. That way, we do not need to
> have a concept of a "task".

I removed the task-control, and, the concept of "task".  HANDLE-RESULT
is gone from org-pending.  `org-pending' has a new keyword: :on-outcome
that will allow to do anything, both on success and on failure.

> Instead, it will be a familiar async API
> with ability to (1) create (2) send signals to (3) receive signals from
> PENREG object.
> `org-pending' will be the entry point to create PENREG object.
>
> `org-pending-ti-send-update' (or maybe simply
> `org-pending-send-update'?) will be a way to send data to PENREG object.
>

I've renamed org-pending-ti-send-update to org-pending-send-update
(now that the task control is gone, the prefix becomes useless).


> HANLDER will be another object we may expose via something like
> (org-pending-handler ( on-success-function on-cancel-function on-await 
> on-insert-logs) ...)
> Then, PENREG will call appropriate handler function as needed.

As the task-control is now gone:
  - get/await is gone,
  - cancel is now a hook/function of REGLOCK,
  - insert-details is now a hook/function too of REGLOCK.


>>>If the argument to ~org-pending-task-connect~ is a lambda, we can use
>>>the current approach you implemented 

Re: [BUG] org-clock-sum: Wrong type argument: fixnump, nil [9.7-pre (release_9.6.22-1309-g8507ef @ /home/grfz/src/org-mode/lisp/)]

2024-03-25 Thread Gregor Zattler
Hi Ihor,
* Ihor Radchenko  [2024-03-24; 13:27 GMT]:
> Gregor Zattler  writes:
>
>> with point on the following frame for a clock table:
>>
>> #+BEGIN: clocktable :scope ("/home/absolute/path/file.org_archive")
>> #+END:
>> ...
>> If instead I use a very fresh org-mode from main, specifically
>>
>> Org mode version 9.7-pre (release_9.6.22-1309-g8507ef @ 
>> /home//src/org-mode/lisp/)
>>
>> like so:
>>
>> emacs -L ~/src/org-mode/lisp -L ~/src/org-mode/contrib/lisp -Q
>>
>> org-clock-report
>>
>> with point on said frame of a clock table produces
>>
>> Updating dynamic block ‘clocktable’ at line 13...
>> org-clock-sum: Wrong type argument: fixnump, nil
>
> What if you do the same starting from "make repro" in ~/src/org-mode ?
> The backtrace should then appear rather than just an error line.

I did

rm -rf *; git checkout -f; make repro

in ~/src/org-mode.  make repro is very quick.

Then I tested again with the above mentioned clock
table frame and emacs command line invocation: Same
result.  No backtrace.

Am I missing something?

> I would like to see that backtrace to understand what went wrong.

Do you have further hints how to produce this
backtrace?

Ciao; Gregor



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

2024-03-25 Thread Adam Porter

On 3/24/24 07:35, Ihor Radchenko wrote:

+New contributors need to submit the 
[[https://orgmode.org/request-assign-future.txt][form]] to the FSF.
+#+begin_center
...
+TODO: Get updated version of form from Emacs maintainers that includes the 
line asking the secretary to send confirmation to interested parties (i.e. the 
Org maintainers).
+#+end_center


I think that we are not very accurate here.
According to
https://www.gnu.org/prep/maintain/maintain.html#Copyright-Papers:

Once the conversation is under way and the contributor is ready for more
details, you should send one of the templates that are found in the
directory /gd/gnuorg/Copyright/; they are also available from the
doc/Copyright/ directory of the gnulib project at
https://savannah.gnu.org/projects/gnulib. This section explains which
templates you should use in which circumstances. Please don’t use any of
the templates except for those listed here, and please don’t change the
wording.

We must use a specific form from a specific URL.


That isn't how the Emacs maintainers handle it.  They send a form by 
email when asked, or direct users to use the one in the Emacs git repo. 
AFAICT, they are equivalent, if not identical.


Regardless, it would be nice to have a canonical answer to this.  The 
gnu.org site says one thing, the emacs.git repo says another, 
org-mode.git says another, the people on the mailing say another, and 
Worg says another--all slightly different for no apparent reason. 
(There's also the Emacs manual, which probably mentions it too.)



Also, about the changes to the FSF form that Stefan mentioned in
https://yhetil.org/emacs-devel/jwvh6hne6nv.fsf-monnier+em...@gnu.org/
It does not look like they are official yet. See
https://lists.gnu.org/archive/html/bug-gnulib/2024-03/msg00060.html


AFAICT the only change is the line that asks the FSF to send additional 
confirmation to some other interested parties.  Does that need to be 
officially official in order to use it?  The alternative is having the 
contributor ask by writing in the email message, which seems equivalent. 
 IOW, it doesn't change the form, it just adds an extra request.



+The assignment process does not always go quickly; occasionally it may
+get stuck or overlooked at the FSF.  The contact at the FSF for this
+is: =copyright-clerk AT fsf DOT org=.  In rare cases, an inquiry from an
+Org maintainer gets the process moving again.


I may be missing something, but the last sentence now reads like our
(Org maintainer's) inquiry rarely works.

The previous version is very different, IMHO:


-Emails from the paper submitter have been ignored in the past, but an
-email from the maintainers of Org mode has usually fixed such cases
-within a few days.


I would have preferred to omit all the language about the process 
sometimes not going quickly or smoothly; it doesn't seem necessary or 
helpful to publish such words, because they seem accusatory toward the 
FSF volunteers.  But in the spirit of preserving earlier contributors' 
intent rather than erasing it and just putting my own words, I left it.




Re: [Worg] CSS improvements

2024-03-25 Thread Adam Porter

On 3/24/24 03:56, Ihor Radchenko wrote:

Adam Porter  writes:


I am not sure if centered text should stand out.
AFAIU, you want to add this style for the sole purpose of highlighting


What is the purpose of centering text if not to make it stand out?


To align text. I am not sure why anything more is necessary - it
is certainly counter-intuitive for me that "center" means something more
than just alignment.


Again, what is the purpose of centering text?  The answer, "To align 
text," is tautological.


Especially, on Worg, where the whole site serves as a kind of extended 
user manual, the purpose of centering text is, what, if not to make it 
stand out?



If you need extra highlighting, we may introduce a dedicated style and
apply it via special block.


Why, when we already have #+begin_center?  Currently it's not even used 
at all.  This would not change anything that already exists; it would 
make something that already exists useful.



Mostly because it is unexpected, as I described above.
I'd prefer to stick closer to the semantics and just apply alignment to
center blocks.


*shrug*  Worg has existed for years without even doing anything with 
#+begin_center blocks--not even centering them.  I propose that we make 
it useful and serve its natural purpose, rather than adding a special 
new block that most users won't even know about (having to find it in 
the voluminous Worg content isn't likely to happen for most users).




Re: [BUG] LaTeX preview should use a subdirectory in /tmp

2024-03-25 Thread Max Nikulin

On 25/03/2024 18:40, Ihor Radchenko wrote:

Max Nikulin writes:

This feature should not write temporary files to /tmp directly


See the attached tentative patch.


Thanks for prompt reaction.


+++ b/lisp/org.el
@@ -16361,7 +16361,7 @@ (defun org-create-formula-image
   org-format-latex-header
   'snippet)))
 (latex-compiler (plist-get processing-info :latex-compiler))
-(tmpdir temporary-file-directory)
+(tmpdir (concat temporary-file-directory "orgtex/"))
 (texfilebase (make-temp-name
   (expand-file-name "orgtex" tmpdir)))


Since directory name already contains "org", it may be shortened to just 
"tex"



 (texfile (concat texfilebase ".tex"))


I would use `make-temp-file' to create TEXFILE and would derive 
TEXFILEBASE from it. In general it is safer.


To create directory I expect a call of a function similar to the 
following one. Perhaps it exists already somewhere.


(defun org-ensure-tmp-dir (dir-symbol prefix)
  (let ((dir (symbol-value dir-symbol)))
;; Temporary directory has not been cleaned.
(or (and dir (file-directory-p dir) dir)
(setf (symbol-value dir-symbol)
  (make-temp-file (or prefix "orgtmp-") 'dir)

(defvar org-tex-tmpdir nil)

Usage example: (org-ensure-tmp-dir 'org-tex-tmpdir "orgtex-")

Fixed directory name is not friendly for multi-user systems and 
predictable name in /tmp might be a source of security issues.





Re: [BUG] LaTeX preview should use a subdirectory in /tmp

2024-03-25 Thread Ihor Radchenko
Max Nikulin  writes:

> This feature should not write temporary files to /tmp directly, some 
> subdirectory should be created for this purpose. The idea is to mitigate 
> consequences if a user opens a file from a compromised or a malicious 
> source and gets /tmp flooded with a crowd of files. It is easier to 
> delete single directory than to spent time trying to figure out what 
> files are necessary for other applications and what ones are generated 
> by LaTeX code.

See the attached tentative patch.

>From df4d827d98063ee665d71906f358ca08ad4d0023 Mon Sep 17 00:00:00 2001
Message-ID: 
From: Ihor Radchenko 
Date: Mon, 25 Mar 2024 14:38:42 +0300
Subject: [PATCH] org-create-formula-image: Keep temporary LaTeX files in
 subfir of /tmp

* lisp/org.el (org-create-formula-image): When compiling formula
images, keep temporary LaTeX logs in a subdirectory of
`temporary-file-directory' instead of littering the top-level /tmp.

Reported-by: Max Nikulin 
Link: https://orgmode.org/list/utrkah$4s0$1...@ciao.gmane.io
---
 lisp/org.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/org.el b/lisp/org.el
index f0f85822f..0793b72d6 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -16361,7 +16361,7 @@ (defun org-create-formula-image
 	   org-format-latex-header
 	   'snippet)))
 	 (latex-compiler (plist-get processing-info :latex-compiler))
-	 (tmpdir temporary-file-directory)
+	 (tmpdir (concat temporary-file-directory "orgtex/"))
 	 (texfilebase (make-temp-name
 		   (expand-file-name "orgtex" tmpdir)))
 	 (texfile (concat texfilebase ".tex"))
-- 
2.44.0


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


[BUG] ox-html output does not pass validation for html4-strict doctype [9.7-pre (release_9.6.23-1423-gcea6a1.dirty @ /home/yantar92/.emacs.d/straight/build/org/)]

2024-03-25 Thread Ihor Radchenko

Setting (setq org-html-doctype "html4-strict") and exporting a trivial
Org document (like the attached) to HTML fails to pass validation at
https://validator.w3.org/

The error is

 Line 6, Column 72: character data is not allowed here


 using XHTML-style self-closing tags (such as ) in HTML
 4.01 or earlier. To fix, remove the extra slash ('/') character. For
 more information about the reasons for this, see Empty elements in
 SGML, HTML, XML, and XHTML.

caused by /> self-closing tag.

However, dropping /> will lead to validation failing for the default
value of `org-html-doctype' - "xhtml-strict".

I am wondering whether it is at all possible to use the same syntax and
yet pass validation for all the allowed values of `org-html-doctype':
"html4-strict", "html4-transitional", "html4-frameset", "xhtml-strict",
"xhtml-transitional", "xhtml-frameset", "xhtml-11", "html5", "xhtml5".



20240322205907-testmath.org
Description: Lotus Organizer

Emacs  : GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.41, 
cairo version 1.18.0)
 of 2024-03-24
Package: Org mode version 9.7-pre (release_9.6.23-1423-gcea6a1.dirty @ 
/home/yantar92/.emacs.d/straight/build/org/)
-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 


[BUG] LaTeX preview should use a subdirectory in /tmp

2024-03-25 Thread Max Nikulin

This is a follow-up to recent changes related to LaTeX preview.

This feature should not write temporary files to /tmp directly, some 
subdirectory should be created for this purpose. The idea is to mitigate 
consequences if a user opens a file from a compromised or a malicious 
source and gets /tmp flooded with a crowd of files. It is easier to 
delete single directory than to spent time trying to figure out what 
files are necessary for other applications and what ones are generated 
by LaTeX code.


P.S. I do not mind double level structure: all temporary Org mode files 
(babel, etc.) are created in single (per Emacs process) directory in tmp 
and each task creates its own subdirectory there.





Re: [DISCUSSION] Add "Recent News" to orgmode.org

2024-03-25 Thread Ihor Radchenko
Bastien Guerry  writes:

> Ihor Radchenko  writes:
>
>> It looks like there is some problem with publishing index.org in
>> particular. I made several changes, but none of them is visible on
>> orgmode.org. At the same time, my changes to tools.org page are
>> visible.
>
> Yes -- perhaps this error has something to do with this:
> https://builds.sr.ht/~bzg/job/1176324#task-build-41

I tried to add news.org to safe remote resources in
https://git.sr.ht/~bzg/orgweb/commit/0b2d6c49efce02b0ae6736f0d8863fc5c2ebeb9f

However, the page is still not updated.
And there is no trace of build failure in
https://lists.sr.ht/~bzg/org-build-failures (understandably, because the
errors are suppressed in publish.sh)

Maybe we should add an equivalent of `worg-publish-stop-on-error' to
orgweb publish process?

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



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

2024-03-25 Thread Bastien Guerry
Ihor Radchenko  writes:

> Sounds reasonable.

OKay -- feel free to go ahead with whatever version you find best.

> It is a longer period compared to 5 business days mentioned in
> https://www.gnu.org/prep/maintain/maintain.html, but the copyright clerk
> is just a single guy taking care about all the requests...

Hence my proposal to wait at least for one month. 

IMO it is not a problem if Org and other GNU packages propose distinct
ping'ing policies as long as the shorter period (one month for Org) is
not shorter than the one proposed for GNU in general (one week, IIUC.)

-- 
 Bastien Guerry