Re: [PATCH] lisp/lisp/ob-core.el (org-babel-merge-params): Rename plists to alists

2024-06-23 Thread Ihor Radchenko
Matthias Hetzenberger  writes:

> I noticed that in the function org-babel-merge-params the arguments are
> alists rather than plists.
> To this end, I created a patch that updates the relevant variable names as
> well as the docstring (see attachment).

Thanks!
Applied, onto bugfix, after adding a proper commit message with
changelog entries and TINYCHANGE cookie (you do not appear to have FSF
copyright assignemnt).

https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?h=bugfix&id=bd16944e1

I also added you to the contributor list:
https://git.sr.ht/~bzg/worg/commit/6108ef9a

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



Re: Please document the caching and its user options

2024-06-23 Thread Björn Bidar
Eli Zaretskii  writes:

>> Eli Zaretskii  writes:
>> 
>> >> I was referring to some kind of global option that defines cache
>> >> directory, data directory, etc. Something akin XDG.
>> >
>> > We already have xdg-cache-home (and a few others in xdg.el).  Is that
>> > what you meant?
>> 
>> Yes, except that `xdg-cache-home' is limited:
>> 
>> 1. It cannot be customized by users
>
> Of course it can: just make the default value of a defcustom be
> derived by xdg-cache-home, and users can then customize the option to
> a different value if they want.

That and it can be overridden just like any XDG Directory variable using
environment variables.



Re: [ANN] lisp/ob-tangle-sync.el

2024-06-23 Thread Ihor Radchenko
João Pedro  writes:

> I'd like to ask if I could contribute to this. I have followed the
> discussion to a point, but would be more than happy to try and
> contribute to this so it gets merged for the next Org major version, as
> I've been waiting for this for quite a while now...

It has been over a month since the last email in this thread.
May I know if you need any further help from us?

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



Re: [Pre-PATCH] Overhaul of the LaTeX preview system

2024-06-23 Thread Ihor Radchenko
Yaroslav Drachov  writes:

> My system-configuration-features are
>
> "ACL GIF GLIB GMP GNUTLS JPEG JSON LCMS2 LIBXML2 MODULES NOTIFY KQUEUE NS 
> PDUMPER PNG RSVG SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP 
> XIM XWIDGETS ZLIB".
>
> RSVG is in the list.
>
> org-latex-preview-check-health diagnostic info:
> ...

May I know if this problem has been resolved?

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



Re: [Pre-PATCH] Overhaul of the LaTeX preview system

2024-06-23 Thread Yaroslav Drachov
Not yet.

Best wishes,
Yaroslav

> 23 июня 2024 г., в 13:53, Ihor Radchenko  написал(а):
> 
> Yaroslav Drachov  writes:
> 
>> My system-configuration-features are
>> 
>> "ACL GIF GLIB GMP GNUTLS JPEG JSON LCMS2 LIBXML2 MODULES NOTIFY KQUEUE NS 
>> PDUMPER PNG RSVG SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP 
>> XIM XWIDGETS ZLIB".
>> 
>> RSVG is in the list.
>> 
>> org-latex-preview-check-health diagnostic info:
>> ...
> 
> May I know if this problem has been resolved?
> 
> -- 
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 




Re: ox-icalendar: Filter todo-types

2024-06-23 Thread Ihor Radchenko
Jack Kamm  writes:

> Perhaps we could have an option ox-icalendar-export-todo-keywords-as
> which could determine whether a keyword should be exported, and if so
> with what status, e.g.:
>
> (defcustom ox-icalendar-export-todo-keywords-as
>  '((no-export . ("SKIP"))
>(cancelled . ("KILLED" "CANCELLED"))
>(in-process . ("PROG"

Maybe we can expand the allowed values of `org-icalendar-include-todo' instead?

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



Re: Please document the caching and its user options

2024-06-23 Thread Daniel Clemente
>
> Thanks!
> I am attaching tentative patch that improve the documentation. I hope
> that it clarifies things for you.
>
>


Thanks. I'm not sure about the "unless" part here:

> Persisting the cache to disk […]
> It is not recommended if the Org files
> include sensitive data, unless the data is encrypted via `org-crypt'.")

I first mentioned org-crypt because users of org-crypt may be
surprised if they see encrypted data stored unencrypted in disk, due
to this cache.
A user has somefile.org which contains some headers marked with the
"crypt" tag. Only those headers are encrypted. The org-element cache
may now cache the whole file, including the encrypted headers (this is
ok). Now the user temporarily decrypts the encrypted header, works on
it some time (including closing the file and opening it again) then
encrypts the section again. During the time that the header was
unencrypted, the org-element cache was storing information about
unencrypted data in ~/.cache/org-persist, which could even be a remote
server (NFS, SMB etc), not as private as the org file itself.

Apparently the data stored in the cache doesn't contain the actual
paragraphs of text but it still contains plain text (like: names of
tags, properties, files, macros, scheduling information), which I
would call private if I'm using org-crypt.


I saw some code related to the org-element cache to avoid putting
encrypted files in the cache, but if I remember correctly that would
be just for whole encrypted files.
The part about how org-crypt works with caching could also be
documented in org-crypt instead, or in the manual.


The rest of the documentation change seems good, it improves things.
I would just mention the shortcomings or disclaimers, if there are.
For instance I worry about what may happen when different Emacs
processes load the same Org files at the same time (e.g. I run several
automated batch export jobs). And I guess that having a disk cache
creates new problems, like when in a web browser a simple F5 won't
refresh and you need S-F5.
But if there are no shortcomings (i.e. all operations will always use
up to date information and everything will keep working as usual when
you enable on-disk cache), it's ok like it is. It's also good if it's
explicitly mentioned. It could also be mentioned somewhere else, like
in a cache section in the manual, if it gets one.


> > My own experience, very subjective and it may be an edge case, is that
> > enabling org-element-cache-persistent didn't make loading my org files
> > faster; on the contrary, it made some things slower (including closing
> > Emacs).
>
> What happens if you set `org-persist--report-time' to t in your config
> and examine *Messages* buffer after opening/closing some Org files?
> Look for "org-persist:..." messages.

Thanks, I'll try that for some time and learn about org-persist and if
there are problems I'll continue in another thread.
For now I can say I see that each operation takes 0.00 or 0.01
seconds, but I have ~150 files so it amounts to a short delay (shorter
than the last time time I tried it).



Re: ox-icalendar: Filter todo-types

2024-06-23 Thread Michaël Cadilhac
On Sun, Jun 23, 2024 at 1:25 PM Ihor Radchenko  wrote:
>
> Jack Kamm  writes:
>
> > Perhaps we could have an option ox-icalendar-export-todo-keywords-as
> > which could determine whether a keyword should be exported, and if so
> > with what status, e.g.:
> >
> > (defcustom ox-icalendar-export-todo-keywords-as
> >  '((no-export . ("SKIP"))
> >(cancelled . ("KILLED" "CANCELLED"))
> >(in-process . ("PROG"

@Jack: That sounds good, and I'd defer to your knowledge of the RFC!

> Maybe we can expand the allowed values of `org-icalendar-include-todo' 
> instead?

I don't think this is the purpose of `include-todo', which seems to be
specific to VTODO vs VEVENT.  Do you have something in mind that
combines that feature with STATUS?



Re: ox-icalendar: Filter todo-types

2024-06-23 Thread Ihor Radchenko
Michaël Cadilhac  writes:

>> > Perhaps we could have an option ox-icalendar-export-todo-keywords-as
>> > which could determine whether a keyword should be exported, and if so
>> > with what status, e.g.:
>> >
>> > (defcustom ox-icalendar-export-todo-keywords-as
>> >  '((no-export . ("SKIP"))
>> >(cancelled . ("KILLED" "CANCELLED"))
>> >(in-process . ("PROG"
> ...
>> Maybe we can expand the allowed values of `org-icalendar-include-todo' 
>> instead?
>
> I don't think this is the purpose of `include-todo', which seems to be
> specific to VTODO vs VEVENT.  Do you have something in mind that
> combines that feature with STATUS?

You are right that `org-icalendar-include-todo' is only affecting VTODO,
but not VEVENT.

My concern is mostly that "(no-export . ("SKIP"))" is somewhat similar
to `org-icalendar-include-todo' set to a list of todo keywords.  So, it
may be confused with VTODO-specific option.

Another concern is that we already have `org-export-with-tasks' where
you can specify which todo keywords should be exported and which
headings should be exported, according to their todo keyword. So,
"no-export" appears to unnecessary.

What is unique to icalendar exporter is the STATUS property. Having a
setting to set it according to todo keyword would indeed make sense.

However, after I looked at the RFC in more details now, I can see that
the values of STATUS property depend on the entry type:

   statvalue-event = "TENTATIVE";Indicates event is tentative.
   / "CONFIRMED";Indicates event is definite.
   / "CANCELLED";Indicates event was cancelled.
   ;Status values for a "VEVENT"

   statvalue-todo  = "NEEDS-ACTION" ;Indicates to-do needs action.
   / "COMPLETED";Indicates to-do completed.
   / "IN-PROCESS"   ;Indicates to-do in process of.
   / "CANCELLED";Indicates to-do was cancelled.
   ;Status values for "VTODO".

   statvalue-jour  = "DRAFT";Indicates journal is draft.
   / "FINAL";Indicates journal is final.
   / "CANCELLED";Indicates journal is removed.
  ;Status values for "VJOURNAL".

Maybe we can introduce separate variables mapping todo keyword to status
depending on the entry type (VTODO vs. VEVENT; we do not export VJOURNAL)?

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



Re: Add 'readonly' option to ob-sqlite

2024-06-23 Thread dmg


hi Ihor,

Ihor Radchenko  writes:

> "Daniel M. German"  writes:
>
>> Sometimes I think it is useful to open a DB in readonly mode
>>
>> eg. to avoid modifying by mistake
>>
>> This is a patch to ob-sqlite.el to accomplish that
>>
>> It adds support for opening a sqlite database in readonly only.
>>
>> It does it by adding a babel parameter readonly. If present, the
>> database will be opened in readonly mode. Example:
>>
>> #+begin_src sqlite :readonly :db /tmp/rip.db
>> insert into a values (1,2);
>> select * from a;
>> #+end_src
>
> Thanks for the patch!
>
> May you please change the patch to avoid header arguments without value?
> What ob-sqlite doing with "others" is not right because it prevents
> setting ":readonly yes" as default header argument and then selectively
> disabling it via ":readonly no".
>
> Also, since you are adding a new feature, please announce it in
> etc/ORG-NEWS and document it in
> https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-sqlite.html
> (the source code is in
> https://git.sr.ht/~bzg/worg/tree/master/item/org-contrib/babel/languages/ob-doc-sqlite.org)


I have changed the code.

1. It is enabled only with ":readonly yes. Disabled with any other value

2. Documented change in NEWS

3. Added a patch for Worg

Thanks again,

--daniel

>From 2949d23c1e06f5cb9c4a07a4b7ec5322b87d8b8e Mon Sep 17 00:00:00 2001
From: Daniel M German 
Date: Sun, 23 Jun 2024 13:55:57 -0700
Subject: [PATCH] Documenting readonly parameter for sqlite's babel

org-contrib/babel/languages/ob-doc-sqlite.org:
	new option :readonly  to ob-sqlite to open the database
	in readonly mode:
---
 org-contrib/babel/languages/ob-doc-sqlite.org | 21 +++
 1 file changed, 21 insertions(+)

diff --git a/org-contrib/babel/languages/ob-doc-sqlite.org b/org-contrib/babel/languages/ob-doc-sqlite.org
index d7febb0c..d909d24b 100644
--- a/org-contrib/babel/languages/ob-doc-sqlite.org
+++ b/org-contrib/babel/languages/ob-doc-sqlite.org
@@ -110,6 +110,7 @@ There are 11 SQLite-specific header arguments.
 SQLite `list' output mode and by the SQLite dot command
 =.import=. 
  - nullvalue :: a string to use in place of NULL values.
+ - readonly :: if yes, open the database in readonly mode.
 
 *** Variables 
 
@@ -252,3 +253,23 @@ where exists (select * from updates where updates.id = bookreview.id);
 By editing the intermediary table to replace "null" values with a
 numerical rating, and then running the second source block, the SQLite
 table will be updated correctly.
+
+** Open database in read-only mode
+
+Sometimes it is useful to open the database in readonly mode to make sure no
+modifications are made to it.
+
+#+BEGIN_EXAMPLE
+,#+begin_src sqlite :readonly yes :db /tmp/test.db
+create table atable(a int, b int);
+,#+end_src
+#+END_EXAMPLE
+
+Attempting to run this block will generate the following error:
+
+#+BEGIN_EXAMPLE
+Runtime error near line 2: attempt to write a readonly database (8)
+[ Babel evaluation exited with code 1 ]
+#+END_EXAMPLE
+
+
-- 
2.45.2

>From 0491d3a672e7a99142da6ac6ade2ae809b04 Mon Sep 17 00:00:00 2001
From: Daniel M German 
Date: Sun, 23 Jun 2024 13:48:57 -0700
Subject: [PATCH] ob-sqlite: Added ability to open a database in readonly mode

Added option :readonly to ob-sqlite.

lisp/ob-sqlite.el:
When :readonly=true the database is opened in readonly mode.
For example:

#+begin_src sqlite :db /tmp/rip.db  :readonly yes  :exports both
create table rip(a,b);
#+end_src

This results in an error such as:

Runtime error near line 2: attempt to write a readonly database (8)

etc/ORG-NEWS:
documented changes
---
 etc/ORG-NEWS  | 18 ++
 lisp/ob-sqlite.el | 10 +++---
 2 files changed, 25 insertions(+), 3 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 1252bbca1..357c41bb2 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -51,6 +51,24 @@ all the references are resolved in the generated png.
 
 # This also includes changes in function behavior from Elisp perspective.
 
+*** ob-sqlite: Added ability to open a database in readonly mode
+
+Added option :readonly to ob-sqlite.
+
+When :readonly=true the database is opened in readonly mode. For example:
+
+#+begin_src sqlite :db /tmp/rip.db  :readonly yes  :exports both
+create table rip(a,b);
+#+end_src
+
+This results in an error such as:
+
+#+begin_example
+Runtime error near line 2: attempt to write a readonly database (8)
+[ Babel evaluation exited with code 1 ]
+#+end_example
+
+
 ** Miscellaneous
 
 * Version 9.7
diff --git a/lisp/ob-sqlite.el b/lisp/ob-sqlite.el
index 96d93b815..e125d927c 100644
--- a/lisp/ob-sqlite.el
+++ b/lisp/ob-sqlite.el
@@ -52,7 +52,8 @@
 (line  . :any)
 (list  . :any)
 (separator . :any)
-(nullvalue . :any))
+(nullvalue . :any)
+(readonly-p . :any))
   "Sqlite specific header args.")
 
 (defun org-babel-expand-body:sqlite (body params)
@@ 

Re: Variable Hyperlinks ?

2024-06-23 Thread David Masterson
Ihor Radchenko  writes:

> David Masterson  writes:
>
>> I use Org with Emacs 28.2 on Linux and BeOrg on iPhones.  I don't
>> believe iPhones support "symbolic links".  Therefore, where I mount a
>> USB key on each is going to be a different directory.  I'd like to store
>> pictures on my USB key and reference them via "file:" hyperlinks in
>> Org. My problem is accounting for the different directory locations.
>>
>> Can I create a variable (property? tag?) in my Org file that will have
>> the path to the USB key directory and use that in an Org hyperlink?
>
> You can have environment variables in link paths:
>
> [[file:$HOME/wallpaper.png]]

Hmm. iOS (Beorg) doesn't handle environment variables (I think).  But
maybe I can hide that...?  Hmm.

> Alternatively, you can define a link abbreviation:
>
> #+link: local-file /home/user/
>
> [[local-file:wallpaper.png]]
>
> and then load it via #+SETUPFILE with different setupfiles on PC and
> phone.

That looks good.  I'll have to experiment with that on Beorg and as on
the Beorg forum.

> Or you can have a custom link type.

I hope I don't have to get that complicated. ;-)

-- 
David Masterson



Re: ox-icalendar: Filter todo-types

2024-06-23 Thread Jack Kamm
Ihor Radchenko  writes:

> Another concern is that we already have `org-export-with-tasks' where
> you can specify which todo keywords should be exported and which
> headings should be exported, according to their todo keyword. So,
> "no-export" appears to unnecessary.

That's a good point. Michael, does `org-export-with-tasks' suffice for
your original need/request?

> However, after I looked at the RFC in more details now, I can see that
> the values of STATUS property depend on the entry type:
>
>statvalue-event = "TENTATIVE";Indicates event is tentative.
>/ "CONFIRMED";Indicates event is definite.
>/ "CANCELLED";Indicates event was cancelled.
>;Status values for a "VEVENT"
>
>statvalue-todo  = "NEEDS-ACTION" ;Indicates to-do needs action.
>/ "COMPLETED";Indicates to-do completed.
>/ "IN-PROCESS"   ;Indicates to-do in process of.
>/ "CANCELLED";Indicates to-do was cancelled.
>;Status values for "VTODO".
>
>statvalue-jour  = "DRAFT";Indicates journal is draft.
>/ "FINAL";Indicates journal is final.
>/ "CANCELLED";Indicates journal is removed.
>   ;Status values for "VJOURNAL".
>
> Maybe we can introduce separate variables mapping todo keyword to status
> depending on the entry type (VTODO vs. VEVENT; we do not export VJOURNAL)?

Sure, but we should also consider the STATUS for VEVENTs created from
non-TODO entries.

Perhaps these variables could map tags as well as todo keywords to
status? E.g., in the following:

(setq org-icalendar-event-status-map
  '((cancelled . ("KILLED" "cancelled"

Then any VEVENT created from entries whose todo-keyword or tag matches
the above would have STATUS set to CANCELLED. For example, both of the
following entries would contain VEVENTs exported as such:

* An event that was cancelled :cancelled:

  A non-todo entry with active timestamp <2024-06-23>.
  It will be exported with STATUS as CANCELLED.

* KILLED A todo that was cancelled
  SCHEDULED: <2024-06-22>

  This todo entry has both a scheduling timestamp as well as an active
  timestamp <2024-06-23>, and may create both VEVENT and VTODO. Any
  VEVENTs created will have STATUS as CANCELLED, due to "KILLED" being
  in org-icalendar-event-status-map.  Any VTODO created will have STATUS
  set according to org-icalendar-todo-status-map instead.