Re: Interest in an Org video meetup?

[Adham Omran]

> Would there be any interest in a monthly 1-2 hour long ad-hoc screen
> sharing and video discussion for Org-mode?

I'm interested.

- Adham Omran

Re: [Uploaded Edebug video] Re: [EasyPG (epa)] Emacs can't save modified encrypted file

[Ihor Radchenko]

Some more info: 
https://old.reddit.com/r/emacs/comments/137r7j7/gnupg_241_encryption_issues_with_emacs_orgmode/

Re: [PATCH] epm.el: A CLI tool for package.el

[Max Nikulin]

On 04/05/2023 17:24, Ihor Radchenko wrote:

Max Nikulin writes:

For those who are not familiar with convention any target may be
specified in docs, keeping usual meaning of the default "all" target.


I am mostly concerned about the existing users who are already settled
on running the default "make". Their workflow will be broken with your
suggestion.


I hope, it is possible to achieve helpful error message with a link 
explaining change.



An I am unsure concerning user prompt.


My main concern is for the users who changed their elpa directory
location. They might run into issues unexpectedly.


My opinion is that an error is better for make than user prompt. Try to 
load from default `package-user-dir' but install there only if it is 
explicitly enabled.



#!/bin/sh
":"; # -*- mode: emacs-lisp; lexical-binding: t; -*-
":"; exec emacs --script "$0" "$@"


Let's not lock to bash. AFAIK, our makefiles can currently work on
Windows. Using /bin/sh will lead to regression.


I thought that more portable way is using "env".


Either env would invoke sh anyway (like in org publish scripts) or it is 
necessary to use env -S feature of relatively recent GNU env. For 
cmd.exe it is better to provide a .bat file running


emacs --script epm.el ...(something for POSIX $@)


+(defun epm-nonempty-p (s)
+  (and s (not (string-empty-p s


Can just use `seq-empty-p'.


I am neutral in respect to such change. I just decided to minimize 
dependencies.



+  ;; TODO (load site-run-file 'no-error 'no-message)
+  ;; may be necessary to load elpa-* deb packages when -Q option
+  ;; is used. See Info node "(elisp) Init File".


Given the explanation in the top comment, is this necessary?


Do you have any arguments against switching from emacs -Q to emacs -q? I 
am still unsure if it is safe enough, but not doing it is not better. I 
am considering adding -q to this script when it is called directly. 
Unfortunately Emacs does not have an option to override effect of -q.

Re: [PATCH] ob-sqlite: Use a transient in-memory database by default

[Ihor Radchenko]

Max Nikulin  writes:

>> I am unsure what is better, to add a fallback here or to add :db 
>> ":memory" to the org-babel-default-header-args:sqlite variable.
>
> Perhaps it is better to keep current behavior with error by default and 
> just to recommend more prominently using file local header arguments
>
> #+PROPERTY: header-args:sqlite :db ":memory"
>
> Changing defaults is a compromise. Perhaps you mostly use src blocks as 
> playground and in-memory database is really convenient for you. However 
> missed :db file in a block creating tables may cause a *delayed* error 
> that will happen on attempt to insert some data to these tables later. 
> It is harder to figure out that :db parameter was forgotten several 
> screens above. The cost of debugging might be higher than adding a 
> property line to files where a user is experimenting with sqlite features.

We can simply display a warning when :db is not specified. Something
like

"ob-sql: :db header argument not specified.  Using in-memory database"

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

Re: [PATCH] epm.el: A CLI tool for package.el

[Ihor Radchenko]

Max Nikulin  writes:

>> Good idea. Although, we should not overdo this package management thing.
>> If we really need complex functionality here, we should better just use
>> cask/eldev instead of re-inventing the wheel.
>
> I have not tried cask or eldev, so I can not reason on supposed workflow.

Cask basically solves dependency management, including tracking outdated
dependencies. See
https://cask.readthedocs.io/en/latest/guide/usage.html#quickstart
It can also be used from Makefile.
The downside is that it has to be installed separately.

>> Are you willing to improve the draft to be ready for upstream?
>
> See the attachment. Interface is subject to change to better fit 
> particular use cases.

Thanks!

>> 2. By ordinary users, not necessarily familiar with GNU make and all the
>> associated build process conventions.
>
> For those who are not familiar with convention any target may be 
> specified in docs, keeping usual meaning of the default "all" target.

I am mostly concerned about the existing users who are already settled
on running the default "make". Their workflow will be broken with your
suggestion. 

>> However, make repro and
>> optionally make docs should avoid re-using user packages as it may cause
>> inconsistent results if the `package-user-dir' is messed up.
>
> I agree concerning "make repro", but unsure for docs.

I am also unsure about docs. Might be either way.

> In general I agree that strategy may depend on specified target. The 
> only issue that make allows to specify several targets.

I am not sure what will be the problem there. make all is also
technically several targets. And running something like
 make compile repro is a bit silly anyway.

> An I am unsure concerning user prompt.

My main concern is for the users who changed their elpa directory
location. They might run into issues unexpectedly.

>> I think that it is stretching a bit beyond the complexity we should
>> allow within Org build system. In your scenario, I can simply do
>> make cleanpkg and re-download the latest dependencies.
>
> I would prefer clear error message that package version is not 
> satisfactory. However such feature may be added later.

I think package.el technically suffers from the same problem. I do not
think that we need to work around it ahead of Emacs. Not until it proves
necessary. (and even then, we should better contribute upstream anyway)

>>> #!/bin/sh
>>> ":"; # -*- mode: emacs-lisp; lexical-binding: t; -*-
>>> ":"; exec emacs --script "$0" "$@"
>> 
>> Let's not lock to bash. AFAIK, our makefiles can currently work on
>> Windows. Using /bin/sh will lead to regression.
>
> It is POSIX shell, not BASH. I am unsure if make can be used on windows 
> when e.g. cygwin is not available. Makefiles are full of POSIX tool 
> invocations.

I thought that more portable way is using "env".

> +(defun epm-nonempty-p (s)
> +  (and s (not (string-empty-p s

Can just use `seq-empty-p'.

> +  ;; TODO (load site-run-file 'no-error 'no-message)
> +  ;; may be necessary to load elpa-* deb packages when -Q option
> +  ;; is used. See Info node "(elisp) Init File".

Given the explanation in the top comment, is this necessary?

> +(defun epm-library-unavailable-p (lib)
> +  (unless (locate-library lib)
> +lib))

> +(defun epm-missing (libs)
> +  ;; TODO consider `require' catching load errors
> +  (delq nil (mapcar #'epm-library-unavailable-p libs)))

Maybe just (cl-remove-if #'locate-library libs)?

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

[POLL] Will it be ok to allow HABIT property inheritance? (optionally) (was: [BUG] org-habit does not respect STYLE property inheritance)

[Ihor Radchenko]

Дмитрий Логвиненко  writes:

> I've noticed that org-habits does not take an inherited STYLE property
> when it searches entries.
> 
> ;; Proposed
> (defun org-is-habit-p ( pom)
>   "Is the task at POM or point a habit?"
>   (string= "habit" (org-entry-get (or pom (point)) "STYLE" 'selective)))

I am not sure if it should be considered a bug.
Currently, sub-tasks under habits are not considered habits.

With your patch, they might be, if a user have customized
`org-use-property-inheritance' to t. (Of course, if user added "STYLE"
there, it is on purpose, and there is no problem).

I am generally in favour of allowing STYLE to be inherited, but it is
technically a breaking change, as I described.

Let's see if anyone voices against this change.

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

Re: Babel results don't respect narrowing

[Ihor Radchenko]

Sebastian Wålinder  writes:

> When org-babel inserts results after evaluating a org-babel block, the 
> current narrowing isn't respected.
>
> Org searches outside of the current narrowing to find a result block, then 
> updates that.

Yes, it is on purpose:

2f2a80fe062df5eaacbd5bc3a34a52f6684dcee9
Author: Nicolas Goaziou 
AuthorDate: Wed Oct 24 17:23:20 2012 +0200
ob: Fix block evaluation in a narrowed buffer

* lisp/ob.el (org-babel-where-is-src-block-result): Insert new results
  keyword in current narrowed part of buffer, if necessary. Small
  refactoring.
(org-babel-insert-result): Do not widen buffer when new results have
to be inserted.  Therefore, results inserted after the last block of
a narrowed buffer still belong to the narrowed part of the buffer.
* testing/lisp/test-ob.el: Add tests.
* testing/lisp/test-ob-exp.el: Move test to test-ob.el

> This is an issue primarily with libraries that insert IDs where the results 
> are.
>
> Then, when the library searches for that ID it inserted in the narrowed 
> buffer that doesn't contain the RESULTS tag, it won't be able to find it, as 
> it's outside the view.

May you elaborate about what kind of library you are referring to?
Please describe the actual problem you ran into.

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