Re: org-bibtex manual

[Ihor Radchenko]

Ypo  writes:

> And ChatGPT offers me this alternative, which doesn't seem to work (BTW, 
> I am not able to install asoc.el):

You do not need asoc.el.. `assoc' is the built-in function.

> #+begin_src emacs-lisp
> (defun my-org-bibtex-headline-format (entry)
>    "Custom function to generate the headline text for org-bibtex-write."
>    (let* ((title (cdr (assoc :title entry)))
>   (author (cdr (assoc :author entry
>      (concat "Mi encabezado personalizado: " title " - " author)))
>
> (setq org-bibtex-headline-format #'my-org-bibtex-headline-format)
> #+end_src

This is correct, but this customization only works in
`org-bibtex-write', which works together with `org-bibtex-read-buffer' /
`org-bibtex-read-file'.

`org-bibtex-create' hard-codes heading to be the same with BiBTeX :title
field.

Yes, org-bibtex is not very polished.

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

Re: org-bibtex manual

[Ihor Radchenko]

Ypo  writes:

> I would like to customize the name of the heading. I think it should be 
> customized this function: "Org Bibtex Headline Format Function".
>
> Is there a guide to do this?
>
> I can see the default is:
>
> #[257 "\300.\236A\207"
>    [:title]
>    3 "\n\n(fn ENTRY)"]
>

That's a bit misleading because of compilation.
The original code is

(defcustom org-bibtex-headline-format-function
  (lambda (entry) (cdr (assq :title entry)))
  "Function returning the headline text for `org-bibtex-write'.
It should take a single argument, the bibtex entry (an alist as
returned by `org-bibtex-read').  The default value simply returns
the entry title."
  :group 'org-bibtex
  :version "26.1"
  :package-version '(Org . "9.1")
  :type 'function)

I should factor out that lambda into a separate readable function name,
like `org-bibtex-headline-from-title'.

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

Re: org-bibtex manual

[Ypo]

Thanks, Ihor.

I would like to customize the name of the heading. I think it should be 
customized this function: "Org Bibtex Headline Format Function".


Is there a guide to do this?

I can see the default is:

#[257 "\300
\236A\207"
  [:title]
  3 "\n\n(fn ENTRY)"]


But I don't know how to customize it.

ChatGPT says:

"Unless you are an advanced Emacs Lisp developer and have a specific 
need to work with byte-compiled code, you generally don't need to 
interact with or modify this representation directly. Instead, you can 
work with the function using its regular name and definition."



And ChatGPT offers me this alternative, which doesn't seem to work (BTW, 
I am not able to install asoc.el):


#+begin_src emacs-lisp
(defun my-org-bibtex-headline-format (entry)
  "Custom function to generate the headline text for org-bibtex-write."
  (let* ((title (cdr (assoc :title entry)))
 (author (cdr (assoc :author entry
    (concat "Mi encabezado personalizado: " title " - " author)))

(setq org-bibtex-headline-format #'my-org-bibtex-headline-format)
#+end_src


Best regards

Re: [TASK] Ensure built-in babel backend consistency (standard header support) and ad documentation to the manual (was: [Pre-PATCH v2] Add the capability to specify lexical scope in tangled files (was

[Thomas S. Dye]

Ihor Radchenko  writes:


"Thomas S. Dye"  writes:


AFAIK, most people assume that built-in backends are stable.
If they are not, it is a bug anyway. Or we should declare that 
we do not

maintain them.

I thought "declare that we do not maintain them" meant "move 
them 
to org-contrib".  I'm not sure what you have in mind here.


I mean that we should work towards developing all the built-in 
backends

up to standards.

Basically, if a backend does not support a standard behaviour 
described
in the manual, I call it a legitimate bug we should fix (sooner 
or
later). 


Great!

All the best,
Tom

--
Thomas S. Dye
https://tsdye.online/tsdye

Re: [TASK] Ensure built-in babel backend consistency (standard header support) and ad documentation to the manual (was: [Pre-PATCH v2] Add the capability to specify lexical scope in tangled files (was

[Ihor Radchenko]

"Thomas S. Dye"  writes:

>> AFAIK, most people assume that built-in backends are stable.
>> If they are not, it is a bug anyway. Or we should declare that 
>> we do not
>> maintain them.
>>
> I thought "declare that we do not maintain them" meant "move them 
> to org-contrib".  I'm not sure what you have in mind here.

I mean that we should work towards developing all the built-in backends
up to standards.

Basically, if a backend does not support a standard behaviour described
in the manual, I call it a legitimate bug we should fix (sooner or
later). 

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

Re: [TASK] Ensure built-in babel backend consistency (standard header support) and ad documentation to the manual (was: [Pre-PATCH v2] Add the capability to specify lexical scope in tangled files (was

[Thomas S. Dye]

Ihor Radchenko  writes:


"Thomas S. Dye"  writes:

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;
...
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.


We have recently reduced the number of built-in backends:
https://list.orgmode.org/orgmode/87bl9rq29m@gnu.org/
Presumably, all that's left is useful is worth maintaining 
upstream.


Yes, thanks for the link.  I read this thread as a first step 
toward enlisting maintainers for built-in backends. This effort 
had some success--20 packages have a designated maintainer--but 
still leaves 23 packages for the Org mode programmers, which seems 
like a lot to me.


 - 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;


AFAIK, most people assume that built-in backends are stable.
If they are not, it is a bug anyway. Or we should declare that 
we do not

maintain them.

I thought "declare that we do not maintain them" meant "move them 
to org-contrib".  I'm not sure what you have in mind here.


 - 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.


That's what we should work on.


Wonderful!

All the best,
Tom

--
Thomas S. Dye
https://tsdye.online/tsdye

[BUG] [PATCH] Avoid interaction in test ~ob-tangle/detangle-false-positive~

[Evgenii Klimov]

Test ~ob-tangle/detangle-false-positive~ asks for confirmation to kill
the buffer, connected to testing/examples/babel.org file, that is
modified during the couse of the test.

Way to reproduce the bug (from projects main dir):

#+BEGIN_SRC sh :dir (expand-file-name ".")
emacs -Q \
  -L lisp/ -L testing/ -L testing/lisp -l lisp/org.el \
  -l lisp/org-id.el -l testing/org-test.el -l 
testing/lisp/test-ob-tangle.el \
  --eval "(progn (org-reload) (setq org-confirm-babel-evaluate nil) \
  (org-babel-do-load-languages 'org-babel-load-languages \
  '((emacs-lisp . t) (shell . t) (org . t" \
  --eval '(ert "ob-tangle/detangle-false-positive")'
#+END_SRC

>From 5905e37a581d4cf2a4a517593c91730d836b6471 Mon Sep 17 00:00:00 2001
From: Evgenii Klimov 
Date: Sun, 16 Jul 2023 13:14:38 +0100
Subject: [PATCH] testing/lisp/test-ob-tangle.el: Avoid interaction in test

* testing/lisp/test-ob-tangle.el (ob-tangle/detangle-false-positive):
Unset modification flag from buffer to kill
(testing/examples/babel.org) in tear down step of test to avoid Emacs
asking for confirmation during interactive testing from within Emacs.
---
 testing/lisp/test-ob-tangle.el | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/testing/lisp/test-ob-tangle.el b/testing/lisp/test-ob-tangle.el
index b1b0a0a53..07e75f4d3 100644
--- a/testing/lisp/test-ob-tangle.el
+++ b/testing/lisp/test-ob-tangle.el
@@ -565,6 +565,8 @@ another block
 	(should (equal (string-trim (org-element-property
 	 :value (org-element-at-point)))
 			   ";; detangle changes"
+  (with-current-buffer buffer
+(set-buffer-modified-p nil))
   (kill-buffer buffer
 
 (provide 'test-ob-tangle)
-- 
2.34.1

Re: [BUG] WORG example for ob-lilypond is no longer working as described

[Ihor Radchenko]

Graham King  writes:

> I'm late to this thread, and I might be missing some crucial aspect of the 
> problem, but if you just want to integrate lilypond scores and fragments into 
> a LaTeX document, and you're able to choose to use Luatex, the lyluatex and 
> lilyglyphs packages work beautifully with the latest Lilypond versions.

ob-lilypond currently does not support :results latex and :results html.
Of course, it could, and not only via LuaTeX.
https://lilypond.org/doc/v2.21/Documentation/usage/html
https://lilypond.org/doc/v2.21/Documentation/usage/latex

But we currently don't have a maintainer for ob-lilypond to work on this...

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

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

[Ihor Radchenko]

Morgan Smith  writes:

> * 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'.

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

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

Re: org-bibtex manual

[Ihor Radchenko]

Ypo  writes:

> 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?

In general, the types of properties are dictated by `org-bibtex-types',
which is declaring Bibtex standards. With C-u argument, you will be
asked for optional properties.

If you want to add non-standard properties, org-set-property will work.

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

Yes. Either exact, or prefixed with `org-bibtex-prefix'. Mixing
with/without prefix will also work.

See also `org-bibtex-export-arbitrary-fields'.

> - 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?

You can create a template by adding `org-bibtex-create'
to :hook property of your capture template:

(setq org-capture-templates '(("a" "test" entry (file "/tmp/1.org") "" :hook 
org-bibtex-create)))

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

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

[Mehmet Tekman]

Apologies, this patch has been burning in the back of mind for a
while now, but I keep getting distracted with other random side
projects.

I appreciate the wake up call, and I will refocus my efforts next
week in my free time.

Best,
Mehmet

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

[Ihor Radchenko]

Timothy  writes:

>> 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.

Do you mean to enable :lexical t in all the elisp source blocks?
It is already possible (and done) using 
`org-babel-default-header-args:emacs-lisp'.

-- 
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]

"Berry, Charles"  writes:

>> 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.

IMHO, this is worse than pointing to WORG pages, as we currently do.

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

[TASK] Ensure built-in babel backend consistency (standard header support) and ad documentation to the manual (was: [Pre-PATCH v2] Add the capability to specify lexical scope in tangled files (was: Ad

[Ihor Radchenko]

"Thomas S. Dye"  writes:

> 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;
> ...
> 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.

We have recently reduced the number of built-in backends:
https://list.orgmode.org/orgmode/87bl9rq29m@gnu.org/
Presumably, all that's left is useful is worth maintaining upstream.

>  - 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;

AFAIK, most people assume that built-in backends are stable.
If they are not, it is a bug anyway. Or we should declare that we do not
maintain them.

>  - 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.

That's what we should work on.

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

Re: [PATCH] Keep the link if the command was cancelled

[Ihor Radchenko]

Max Nikulin  writes:

> On 03/07/2023 22:28, Ihor Radchenko wrote:
>> If necessary, removing stored links without inserting can be made as an
>> effect of negative prefix argument in `org-insert-link' or in
>> `org-insert-all-links'.
>
> I do not think it would be a noticeable improvement. It increases code 
> complexity, but `org-insert-link' + `undo' requires the same amount of 
> keystrokes.
>
> Maybe I just do not like prefix argument. Instead of triple C-u to keep 
> the link I would prefer to be able to activate it from the link prompt 
> (something similar to to M-s i switches for incremental search).
>
> It might be more reasonable to have some binding to cancel 
> `org-store-links' immediately after this command.

I feel like this direction is overcomplicating things.
What about trying to mimic some of the existing Emacs behaviours, like
kill ring.

What I have in mind is how M-w C-y M-y M-y ... works.
We may have a command to replace the last inserted link with previous
link in the org-stored-links when previous command was org-insert-link.

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

Re: [PATCH 2/2] doc/org-manual.org: Document org-clock-{in,out}-switch-to-state

[Ihor Radchenko]

Canceled.
See https://orgmode.org/list/875y6kjmfb.fsf@localhost

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

Re: [PATCH v2 2/2] doc/org-manual.org: Document org-clock-{in,out}-switch-to-state

[Ihor Radchenko]

"Samuel W. Flint"  writes:

> * doc/org-manual.org (Clocking commands): Document operation of
> org-clock-{in,out}-switch-to-state.

Canceled.
See https://orgmode.org/list/875y6kjmfb.fsf@localhost

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

Re: [PATCH v2 1/2] lisp/org-clock.el: Make switching states on clock-in/-out easier

[Ihor Radchenko]

Ihor Radchenko  writes:

> Before we continue, could you please confirm if you have FSF copyright
> assignment? My records show that you have made two commits to Org mode
> previously, and they total LOC is 15, which is maximum allowed
> contribution that does not require copyright assignment. See
> https://orgmode.org/worg/org-contribute.html#copyright

Unfortunately, the copyright assignment got stuck in the process because
of university bureaucracy.

Canceled.

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