org-bibtex manual

[Ypo]

Hi

I have been reading about org-bibtex, and I think the mail list were 
right when advised it to me 
(https://lists.gnu.org/archive/html/emacs-orgmode/2021-10/msg00621.html).


Now... I would like to start using it. I have seen it has a kind of 
org-capture template (M-x org-bibtex-create-in-current-entry).


If I wanted to add more properties:

- How should the different properties be named and filled to work correctly?

- Should the names of the properties be exactly like in Bibtex?

- Are there any existing org-capture templates with the properties each 
entry type could have? Or could you advise a manual of bibtex to create 
myself some complete templates?



Thanks!

[PATCH] Testing: Add tests for 'org-agenda-skip-if'

[Morgan Smith]

* testing/lisp/test-org-agenda.el (test-org-agenda/skip-if): New test.
(test-org-agenda/non-scheduled-re-matces): Fix typo by changing name
to 'test-org-agenda/non-scheduled-re-matches'.
---
 testing/lisp/test-org-agenda.el | 62 -
 1 file changed, 61 insertions(+), 1 deletion(-)

diff --git a/testing/lisp/test-org-agenda.el b/testing/lisp/test-org-agenda.el
index 22e3106ec..c4bd4f0a7 100644
--- a/testing/lisp/test-org-agenda.el
+++ b/testing/lisp/test-org-agenda.el
@@ -99,7 +99,7 @@
  (looking-at " *agenda-file:Scheduled: *test agenda"
 (org-test-agenda--kill-all-agendas)))
 
-(ert-deftest test-org-agenda/non-scheduled-re-matces ()
+(ert-deftest test-org-agenda/non-scheduled-re-matches ()
   "Make sure that scheduled-looking elements do not appear in agenda.
 See https://list.orgmode.org/20220101200103.gb29...@itccanarias.org/T/#t.;
   (cl-assert (not org-agenda-sticky) nil "precondition violation")
@@ -269,6 +269,66 @@ See 
https://list.orgmode.org/06d301d83d9e$f8b44340$ea1cc9c0$@tomdavey.com;
   (should (not (invisible-p (1- (search-forward "TODO Foo")))
   (org-toggle-sticky-agenda))
 
+(ert-deftest test-org-agenda/skip-if ()
+  "Test `org-agenda-skip-if'."
+  (dolist (options '((scheduled) (notscheduled)
+ (deadline) (notdeadline)
+ (timestamp) (nottimestamp)
+ (regexp "hello") (notregexp "hello")
+ ;; TODO: Test for specific TODO keywords
+ (todo ("*")) (nottodo ("*"
+(should
+ (equal
+  (if (memq (car options) '(notscheduled notdeadline nottimestamp regexp 
nottodo))
+  8
+nil)
+  (org-test-with-temp-text
+  "* hello"
+(org-agenda-skip-if nil options
+(should
+ (equal
+  (if (memq (car options) '(scheduled notdeadline timestamp regexp 
nottodo))
+  36
+nil)
+  (org-test-with-temp-text
+  "* hello
+SCHEDULED: <2023-07-15 Sat>"
+(org-agenda-skip-if nil options
+(should
+ (equal
+  (if (memq (car options) '(notscheduled deadline timestamp regexp 
nottodo))
+  35
+nil)
+  (org-test-with-temp-text
+  "* hello
+DEADLINE: <2023-07-15 Sat>"
+(org-agenda-skip-if nil options
+(should
+ (equal
+  (if (memq (car options) '(notscheduled notdeadline timestamp regexp 
nottodo))
+  25
+nil)
+  (org-test-with-temp-text
+  "* hello
+<2023-07-15 Sat>"
+(org-agenda-skip-if nil options
+(should
+ (equal
+  (if (memq (car options) '(notscheduled notdeadline nottimestamp 
notregexp nottodo))
+  10
+nil)
+  (org-test-with-temp-text
+  "* goodbye"
+(org-agenda-skip-if nil options
+(should
+ (equal
+  (if (memq (car options) '(notscheduled notdeadline nottimestamp 
notregexp todo))
+  26
+nil)
+  (org-test-with-temp-text
+  "* TODO write better tests"
+(org-agenda-skip-if nil options))
+
 (ert-deftest test-org-agenda/goto-date ()
   "Test `org-agenda-goto-date'."
   (unwind-protect
-- 
2.41.0

Re: [Pre-PATCH v2] Add the capability to specify lexical scope in tangled files (was: Add new :lexical header argument)

[Berry, Charles]

> On Jul 15, 2023, at 9:11 AM, Thomas S. Dye  wrote:
> 
> 
> Ihor Radchenko  writes:
> 
>> "Thomas S. Dye"  writes:
>> 
 Am I correct that language-specific header arguments are not yet covered
 in the manual?  I can't find any reference of "lexical" there.
>>> 
>>> Yes, I believe so.  Language-specific header arguments for many languages 
>>> are documented at 
>>> https://orgmode.org/worg/org-contrib/babel/languages/index.html. Several 
>>> languages are not documented there; in these cases the documentation is 
>>> typically in the source code.
>> 
>> It is actually slightly awkward that built-in babel backends are not
>> documented in the manual, while, for example, export backends are.
>> 
> Agreed, but the two differ.  With export, the goal is to produce code 
> recognized as correct by the target software.  With babel, the general goal 
> is to provide language agnostic literate programming, which often produces 
> something that meets standards of correctness not implemented in software.  
> The idea of built-in babel backends, as distinct from contributed backends, 
> or backends distributed by package archive is a function of maintenance 
> burden and distribution channel, rather than something intrinsic to the 
> backend itself and how it contributes to literate programming.  
>> However, unless my memory deceives me, Bastien or Nicolas previously
>> voiced against adding babel documentation. Though I cannot find the
>> relevant discussion now and cannot recall the arguments (if there was
>> such discussion at all).
> 
> IIRC, there wasn't much discussion.   The current situation doesn't seem ripe 
> for documentation in the manual.
> 


Agreed. Maybe it would suffice to use enhanced docstrings for the 
org-babel-execute: functions and point to them in the manual.


The params argument could list the language specific keys and the language 
specific handling of key common to all languages (e.g. `:results graphics' in R 
jumps through a number of hoops that might deserve mention)

Chuck 


> Here are some potential hurdles:
> - there are likely too many built-in backends;
> - the built-in backends are a mixed bag--ob-lua seems half-finished to me, 
> though I don't program in lua and struggled to set up the language to write 
> the documentation stub on Worg;
> - nearly a dozen of the built-in babel backends lack documentation outside 
> the source code (see 
> https://orgmode.org/worg/org-contrib/babel/languages/index.html#orgbc466c5); 
> and
> - language support is inconsistent (see 
> https://orgmode.org/worg/org-contrib/babel/languages/lang-compat.html), which 
> introduces complications for language agnostic literate programming.
> 
> One way forward might distinguish between babel backends for GNU software and 
> babel backends for non-GNU software, with the former built in, guaranteed to 
> be consistent to some standard (which needs to be formulated), and documented 
> in the manual and the latter moved to contrib or a package archive, with 
> documentation (if any) on Worg.
> 
> Others might have better ideas.
> 
> All the best,
> Tom
> -- 
> Thomas S. Dye
> https://tsdye.online/tsdye
> 
> 

Re: [Pre-PATCH v2] Add the capability to specify lexical scope in tangled files (was: Add new :lexical header argument)

[Thomas S. Dye]

Ihor Radchenko  writes:


"Thomas S. Dye"  writes:

Am I correct that language-specific header arguments are not 
yet 
covered

in the manual?  I can't find any reference of "lexical" there.


Yes, I believe so.  Language-specific header arguments for many 
languages are documented at 
https://orgmode.org/worg/org-contrib/babel/languages/index.html. 
Several languages are not documented there; in these cases the 
documentation is typically in the source code.


It is actually slightly awkward that built-in babel backends are 
not
documented in the manual, while, for example, export backends 
are.


Agreed, but the two differ.  With export, the goal is to produce 
code recognized as correct by the target software.  With babel, 
the general goal is to provide language agnostic literate 
programming, which often produces something that meets standards 
of correctness not implemented in software.  The idea of built-in 
babel backends, as distinct from contributed backends, or backends 
distributed by package archive is a function of maintenance burden 
and distribution channel, rather than something intrinsic to the 
backend itself and how it contributes to literate programming.  

However, unless my memory deceives me, Bastien or Nicolas 
previously
voiced against adding babel documentation. Though I cannot find 
the
relevant discussion now and cannot recall the arguments (if 
there was

such discussion at all).


IIRC, there wasn't much discussion.   The current situation 
doesn't seem ripe for documentation in the manual.


Here are some potential hurdles:
- there are likely too many built-in backends;
- the built-in backends are a mixed bag--ob-lua seems 
half-finished to me, though I don't program in lua and struggled 
to set up the language to write the documentation stub on Worg;
- nearly a dozen of the built-in babel backends lack 
documentation outside the source code (see 
https://orgmode.org/worg/org-contrib/babel/languages/index.html#orgbc466c5); 
and
- language support is inconsistent (see 
https://orgmode.org/worg/org-contrib/babel/languages/lang-compat.html), 
which introduces complications for language agnostic literate 
programming.


One way forward might distinguish between babel backends for GNU 
software and babel backends for non-GNU software, with the former 
built in, guaranteed to be consistent to some standard (which 
needs to be formulated), and documented in the manual and the 
latter moved to contrib or a package archive, with documentation 
(if any) on Worg.


Others might have better ideas.

All the best,
Tom
--
Thomas S. Dye
https://tsdye.online/tsdye

Re: [Pre-PATCH v2] Add the capability to specify lexical scope in tangled files (was: Add new :lexical header argument)

[Timothy]

Hi Ihor,

> I do not think that setting `lexical-binding’ file-local variable in an
> Org file makes much sense. I am sure that we can do better.

I suppose part of the question is what sort of way we treat it? In my mind,
considering the current way lexical scope is seen in Emacs (used everywhere in
modern elisp, not on-by-default because that would break compat, is my
impression). I think it would make sense if this eventually ends up with a
“globally enabled everywhere by default” setting, which is why I think a
defcustom may be the best fit.

> I can see that there are people in favour of :lexical feature.
> So, we can probably add it, but it should not be in ob-core.
> Instead, we should provide an infrastructure allowing ob-* backends to
> modify tangling. Maybe some kind of special function that will override
> default `org-babel-spec-to-string’ per backend?

Mmm, something generic for backend-specific modification sounds like a good idea
to me.

All the best,
Timothy

-- 
Timothy (‘tecosaur’/‘TEC’), Org mode contributor.
Learn more about Org mode at .
Support Org development at ,
or support my work at .

Re: [BUG]: No customization data for org-property-value face

[Mauro Aranda]

Ihor Radchenko  writes:

> Mauro Aranda  writes:
>
>> After emacs -Q:
>> 1. (require 'org)
>> 2. M-x customize-face RET org-property-value
>>
>> A custom buffer shows up, but it says:
>> NO CUSTOMIZATION DATA; not intended to be customized.
>
> Thanks for reporting!

Thanks for your quick response :-)

> I am attaching tentative patch that makes `org-property-value' face
> inherit from default face. This will preserve the existing look as Emacs
> falls back to default face for "nil" faces.
>
> Or do we want to change this face to inherit from something like
> font-lock-string-face?
>

Re: [BUG]: No customization data for org-property-value face

[Ihor Radchenko]

Mauro Aranda  writes:

> After emacs -Q:
> 1. (require 'org)
> 2. M-x customize-face RET org-property-value
>
> A custom buffer shows up, but it says:
> NO CUSTOMIZATION DATA; not intended to be customized.

Thanks for reporting!

I am attaching tentative patch that makes `org-property-value' face
inherit from default face. This will preserve the existing look as Emacs
falls back to default face for "nil" faces.

Or do we want to change this face to inherit from something like
font-lock-string-face?

>From 52594ea5d3e1fa5c110304fb22147713d1226198 Mon Sep 17 00:00:00 2001
Message-ID: <52594ea5d3e1fa5c110304fb22147713d1226198.1689431152.git.yanta...@posteo.net>
From: Ihor Radchenko 
Date: Sat, 15 Jul 2023 17:20:54 +0300
Subject: [PATCH] org-property-value: Define face as non-nil

* lisp/org-faces.el (org-property-value): Set default value to inherit
from `font-lock-string-face' instead of using invalid face value of
nil.

Reported-by: Mauro Aranda 
Link: https://orgmode.org/list/41956a5a-44c2-c1ea-e1e5-d018a8656...@gmail.com
---
 lisp/org-faces.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/org-faces.el b/lisp/org-faces.el
index b3f8e419c..436552cb2 100644
--- a/lisp/org-faces.el
+++ b/lisp/org-faces.el
@@ -108,7 +108,7 @@ (defface org-drawer	   ;Copied from `font-lock-function-name-face'
   "Face used for drawers."
   :group 'org-faces)
 
-(defface org-property-value nil
+(defface org-property-value '((t :inherit default))
   "Face used for the value of a property."
   :group 'org-faces)
 
-- 
2.41.0


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

[BUG]: No customization data for org-property-value face

[Mauro Aranda]

After emacs -Q:
1. (require 'org)
2. M-x customize-face RET org-property-value

A custom buffer shows up, but it says:
NO CUSTOMIZATION DATA; not intended to be customized.

Could you please change this definition of org-property-value?
(defface org-property-value nil
  "Face used for the value of a property."
  :group 'org-faces)

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

[Ihor Radchenko]

Mehmet Tekman  writes:

> ... I will rewrite to to conform to the
> `org-test-with-temp-text' examples.

Two months have passed since the last message in this thread.
Mehmet, have you had a chance to work on this? May you need any help?

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

Re: [PATCH] Re: what is the purpose of "This link has already been stored"?

[Ihor Radchenko]

Ihor Radchenko  writes:

> From a05e2cc235b10a7096538da4f6ae6d17c82a6b25 Mon Sep 17 00:00:00 2001
> Message-ID: 
> 
> From: Ihor Radchenko 
> Date: Wed, 5 Jul 2023 13:14:56 +0300
> Subject: [PATCH] org-store-link: Move already stored link to front by default

Applied, onto main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=c0dbcf361

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

Re: [Pre-PATCH v2] Add the capability to specify lexical scope in tangled files (was: Add new :lexical header argument)

[Ihor Radchenko]

"Thomas S. Dye"  writes:

>> Am I correct that language-specific header arguments are not yet 
>> covered
>> in the manual?  I can't find any reference of "lexical" there.
>
> Yes, I believe so.  Language-specific header arguments for many 
> languages are documented at 
> https://orgmode.org/worg/org-contrib/babel/languages/index.html. 
> Several languages are not documented there; in these cases the 
> documentation is typically in the source code.

It is actually slightly awkward that built-in babel backends are not
documented in the manual, while, for example, export backends are.

However, unless my memory deceives me, Bastien or Nicolas previously
voiced against adding babel documentation. Though I cannot find the
relevant discussion now and cannot recall the arguments (if there was
such discussion at all).

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

Re: [PATCH] testing: Delete duplicate tests

[Ihor Radchenko]

Max Nikulin  writes:

> The idea to find duplicated tests is bright. The code may be transformed 
> in a dedicated unit test. I would not drop existing tests blindly though.

Very good idea indeed.

One gotcha is that not every should form is next level after
ert-deftest. And there are also "should-not" and "should-error" forms.

So, we may compare only forms at the same sexp depth for equality,
without restricting to "should".

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

Re: [Pre-PATCH v2] Add the capability to specify lexical scope in tangled files (was: Add new :lexical header argument)

[Ihor Radchenko]

Timothy  writes:

> It occurs to me that this use case could also perhaps be satisfied by 
> file-local
> variables? If we presume that mixing tangling to lexically-bound and
> non-lexically bound elisp files is a corner case we don’t care that much 
> about,
> a `org-babel-elisp-lexical' variable could be used to set the behaviour, and
> modified using file-local variable forms as usual.

I do not think that setting `lexical-binding' file-local variable in an
Org file makes much sense. I am sure that we can do better.

I can see that there are people in favour of :lexical feature.
So, we can probably add it, but it should not be in ob-core.
Instead, we should provide an infrastructure allowing ob-* backends to
modify tangling. Maybe some kind of special function that will override
default `org-babel-spec-to-string' per backend?

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

Re: [PATCH worg] Fix broken link

[Ihor Radchenko]

Evgenii Klimov  writes:

> From ed39640d75df231c8826191f2576fcfd6a5aa723 Mon Sep 17 00:00:00 2001
> From: Evgenii Klimov 
> Date: Sat, 15 Jul 2023 00:34:58 +0100
> Subject: [PATCH] org-contrib/babel/languages/index.org: Fix broken link

Thanks!
Applied, onto master.
https://git.sr.ht/~bzg/worg/commit/368356cd

Contributing to WORG does not require FSF copyright assignment.

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

Re: [BUG] org-babel-result-to-file failed when buffer is narrowed [9.7 (9.7-??-f7aa8c1 @ c:/Users/yhht/.config/emacs/.local/straight/build-29.0.60/org/)]

[Ihor Radchenko]

赵一宇  writes:

> When I try to execute ob-block in a narrowed buffer, there seems to have
> a error on org-babel-result-to-file, with msg "wrong argument type
> stringp, nil"
> 
> and the reason is at line marked as -2->, which "buffer-file-name" would
> be nil when in narrowed buffer.

Thanks for the report, but there seems to be either some terminology
issue of a problem with analysis.

Narrowing a buffer (`narrow-to-region') definitely does not change
`buffer-file-name'; it just limits the visible and accessible text in
buffer to a subset of text in buffer.

Maybe you mean indirect buffer? But `buffer-base-buffer' should take
care about this.

So, may you please provide a reproducer, so that I can see and
investigate the problem on my side? See
https://orgmode.org/worg/org-faq.html#bug-reporting

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