Re: [PATCH] oc-csl: Add support for sub-bibliographies

[Ihor Radchenko]

András Simonyi  writes:

> the attached patch adds support for filter-based sub-bibliographies in the 
> "csl"
> org-cite export processor. It supports the same syntax for specifying
> filters as the biblatex processor and supports some of the biblatex
> filter types, concretely, entry-type and keyword based filtering. It
> also supports filtering based on CSL type (as opposed to bib(la)tex
> type) and using any Lisp predicate as a filter.

Thanks! LGTM!

Can you please also document the new feature in the manual? Especially,
the CLS-specific filter options. It is not clear what are they.

Best,
Ihor

[FR] Make :var foo=name-of-src-block assign the source block code instead of currently assigned result of evaluation (was: [PATCH] Add :noweb-prefix and :noweb-trans babel header arguments)

[Ihor Radchenko]

Sébastien Miquel  writes:

> Ihor Radchenko writes:
>> Can you provide more concrete examples?
>>
>>> Some drawbacks:
>>>    + doesn't work for all languages (does work for LaTeX)
>> Which languages do not work?
> Most languages do not work. Using your proposed solution, what I'm
> trying to do is
>
> #+name:javascript-header
> #+begin_src javascript :tangle no
> some javascript, with \ and " to be escaped
> #+end_src
>
> #+name: string-escape
> #+begin_src emacs-lisp :var str="" :tangle no
> (prin1-to-string (string-trim-right str))
> #+end_src
>
> #+begin_src emacs-lisp :noweb yes :tangle yes
> (setq javascript-header <>)
> #+end_src
>
> If you replace javascript with latex, it happens to work, because when
> org executes a latex block, it prints its content.
>
> The goal is to tangle to some lisp code whose purpose is to generate
> LaTeX/javascript code. Quite niche admittedly, though as you showed,
> it could also be used to string-escape documentation.

Thanks for providing an example!

The current behaviour of :var foo=name-of-src-block is assigning result
of evaluation. However, this behaviour is actually not documented.
16.4 Environment of a Code Block section of the manual only documents
uses like
#+BEGIN_SRC emacs-lisp :var length=table-length()
or
#+BEGIN_SRC emacs-lisp :var input=double(input=1)

Currently,
#+BEGIN_SRC emacs-lisp :var length=table-length
is the same with
#+BEGIN_SRC emacs-lisp :var length=table-length()

Given that
#+BEGIN_SRC emacs-lisp :var x=literal-example

inserts the literal contents of the example block, I am voting to change
the current undocumented behaviour for assigning the code block
references.

This will make the discussed example work while not restricting the
existing features.

WDYT?

Best,
Ihor

Re: [PATCH v5] ol.el: add description format parameter to org-link-parameters

[Ihor Radchenko]

Hugo Heagren  writes:

>> Currently, the internal implementation will treat nil return value as if
>> there was no :default-description and org-link-make-description-function
>> were set to nil. We may probably document this. It sounds like a useful
>> behavior.
>
> I added some relevant documentation to the `:default-description' part
> of the `org-link-parameters' docstring. I also changed the
> previosly-failing test to expect the right value. All the tests pass
> now.

Thanks! Can you also update the documentation for
org-link-make-description-function?

> From cd5268bc05324140a4cf384ce12b99bba1ddab47 Mon Sep 17 00:00:00 2001
> From: Hugo Heagren 
> Date: Mon, 28 Mar 2022 23:18:45 +0100
> Subject: [PATCH] ol.el: add description format parameter to
>  org-link-parameters

Also, can you please review the comments from Max:
https://list.orgmode.org/877d4flu3x@heagren.com/T/#m3b48d0076a25eaf24b1af48df317984dd4e33fb0

> +;; Copy all keys in `parameters' and their original values to
> +;; `orig-parameters'.
> +(cl-loop for param in parameters by 'cddr
> + do (setq orig-parameters
> +  (plist-put orig-parameters param 
> (org-link-get-parameter type param

Thinking about this part a bit more, I have realized that even better
option would be using map-do.

Best,
Ihor

Re: org-capture and fast selection of tags

[Ihor Radchenko]

Christian Heinrich  writes:

> I looked at the code and came up with a patch that works for me (see below). 
> However, this may
> change behavior for others:

Thanks!

> 1. The original %^g will work on non-headlines, but if (org-set-tags-command) 
> is called as I do,
> this is no longer possible and would need to be checked (what would be a good 
> way here?)
>
> 2. Can I really deduce from (org-use-fast-tag-selection) being non-nil that 
> fast selection should be
> used in capture templates as well? Does it actually make sense to incorporate 
> this into %^g/G?
>
> I am neither a lisp programmer nor acquainted with the org codebase; this is 
> a draft I came up
> with. If you can provide me with further feedback, I'm willing to make this 
> more stable.

The idea is reasonable, but using org-set-tags-command is not ideal
indeed. Instead, you can take the relevant part of org-set-tags-command
(it is all but last line of the "t" cond clause) and put it into a
separate auxiliary function. Then, you can simply call that function
inside the org-set-tags-command and inside the capture template code.

Best,
Ihor

Re: missing a character / font in agenda?

[Ihor Radchenko]

Daniel Ortmann  writes:

> More information on that character:
>
>   position: 195 of 690 (28%), column: 26
>      character: ⭠ (displayed as ⭠) (codepoint 11104, #o25540, 
> #x2b60)
>    charset: unicode-bmp (Unicode Basic Multilingual Plane 
> (U+..U+))
> code point in charset: 0x2B60
>     script: symbol
>     syntax: _     which means: symbol
>   category: .:Base
>   to input: type "C-x 8 RET 2b60" or "C-x 8 RET LEFTWARDS 
> TRIANGLE-HEADED ARROW"
>    buffer code: #xE2 #xAD #xA0
>      file code: #xE2 #xAD #xA0 (encoded by coding system utf-8-unix)
>    display: no font available
>
> Character code properties: customize what to show
>    name: LEFTWARDS TRIANGLE-HEADED ARROW
>    general-category: So (Symbol, Other)
>    decomposition: (11104) ('⭠')

Would you mind sending a bug report to Emacs devs?
If you run (char-displayable-p ?⭠) on your side but yet not being able
to see the symbol properly, we can hopefully get some good suggestions
(or even a fix) from Emacs guys.

Best,
Ihor

Re: org-cature-ref

[Ihor Radchenko]

Henrik Frisk  writes:

>>> Is so, you probably need
>>>
>>> org-protocol://capture?template...
>>> instead of
>>> org-protocol://capture-html?template...
>>>
>>> Thanks, that was the issue and it works fine now. However, I can't seem
>> to get the org-capture-ref-get-bibtex-field to work by simply replacing 
>> org-capture-ref-headline-format
>> with it. Not sure where the ":bibtex-string" should go in the template
>> which is probably why it doesn't work.

Could you please provide a bit more details on what you did, what you
expected to get, and what you got?

Best,
Ihor

Re: [BUG] org-auto-repeat-maybe: error "Can’t expand minibuffer to full frame" and missing log note

[Ihor Radchenko]

Bhavin Gandhi  writes:

> Seems like soon I will cross the TINYCHANGE limit, so I will get the
> FSF copyright assignment done.

Note that FSF should reply within 5 working days. If not, we can help
you to push them.

Best,
Ihor

Re: [PATCH] New remote resource download policy

[Timothy]

Hi Max,

I’ve just made a few more tweaks, tested it, and pushed this as 0583a0c. We may
want to tweak this further before the next Org release, but I think this is a
good enough starting point.

> An idea: a menu entry that displays location in the org file that caused the
> prompt. However it may require enough work to pass context data to the 
> function
> rendering menu.

This could be added in future.

> I see you point concerning blocking modal prompt and I do not like it as well.
> Have you seen the following thread:
>
> Arthur Miller. Proposal: ’executable’ org-capture-templaes. Wed, 22 Jun 2022
> 14:13:51 +0200.
> 
>
> If it were merged already, would it be enough for you to implement the dialog 
> or
> the proposal lacks some features necessary for smooth user experience?

I have not read much of this thread, but from a brief glance — possibly.

> The reason why I asked about `org-mks’ is expectation of UI consistency 
> withing
> Org. It might help users having customized `display-buffer-alist’

Here I was more thinking of UI consistency within Emacs.

> I still do not like code adding a menu close enough to existing one, but I 
> will
> not object any more.

Since this is separate to the functionality, I’m going to push this for now, and
we can update the UI side of things later.

All the best,
Timothy

Re: babel output seems to drop anything before % (in session)

[Ihor Radchenko]

Daniele Pizzolli  writes:

> From 897ae50cf055d459d741c90f8de94dd56a8eb3d9 Mon Sep 17 00:00:00 2001
> From: Daniele Pizzolli 
> Date: Wed, 5 May 2021 17:00:28 +0200
> Subject: [PATCH 1/1] Add disabled test for % in babel shell output

Daniele, your patch is over 15LOC. Would you mind doing FSF paperwork
as described in https://orgmode.org/worg/org-contribute.html#copyright ?

Best,
Ihor

Re: [FR] Make :var foo=name-of-src-block assign the source block code instead of currently assigned result of evaluation (was: [PATCH] Add :noweb-prefix and :noweb-trans babel header arguments)

[Greg Minshall]

Ihor,

> The current behaviour of :var foo=name-of-src-block is assigning result
> of evaluation. However, this behaviour is actually not documented.
> 16.4 Environment of a Code Block section of the manual only documents
> uses like

in fact, the text of the info page (on my system?) says
> code block without arguments
>  A code block name, as assigned by ‘NAME’ keyword from the example
>  above, optionally followed by parentheses.

note the "optionally".

cheers, Greg

Re: [FR] Make :var foo=name-of-src-block assign the source block code instead of currently assigned result of evaluation (was: [PATCH] Add :noweb-prefix and :noweb-trans babel header arguments)

[Ihor Radchenko]

Greg Minshall  writes:

>> The current behaviour of :var foo=name-of-src-block is assigning result
>> of evaluation. However, this behaviour is actually not documented.
>> 16.4 Environment of a Code Block section of the manual only documents
>> uses like
>
> in fact, the text of the info page (on my system?) says
>> code block without arguments
>>  A code block name, as assigned by ‘NAME’ keyword from the example
>>  above, optionally followed by parentheses.
>
> note the "optionally".

Hmm. You are right. I missed "optionally".

Still, I find this idea as the best solution for people who want to
process the source block text during noweb expansion.

Alternative ideas are welcome though. I'd prefer to avoid breaking
change if we can find an equally simple syntax alternative to assign
source block code to a variable.

Best,
Ihor

Re: [FR] Make :var foo=name-of-src-block assign the source block code instead of currently assigned result of evaluation (was: [PATCH] Add :noweb-prefix and :noweb-trans babel header arguments)

[Greg Minshall]

Ihor,

> Alternative ideas are welcome though. I'd prefer to avoid breaking
> change if we can find an equally simple syntax alternative to assign
> source block code to a variable.

my two cents would be to avoid the breaking change.  (i notice, for
example, that i use this construct in some of my .org files.)

cheers, Greg

Org for developing LaTeX packages

[Juan Manuel Macías]

Hi all,

I am writing a package for LuaLaTeX and have decided to use Org for it.
The reasons: org is more powerful, more versatile and more cool than the
'official' LaTeX literate programming utility, docstrip.

Searching for information on this list I found this post from Marcin
Borkowski, from 2013, where he comments on very interesting things
regarding these topic:

https://list.orgmode.org/20130311230246.4c629e36@aga-netbook/

Out of curiosity, I wonder if Marcin or someone else finally got around
to implementing something concrete for this. I think some kind of
extension to org-babel-tangle that would generate the typical docstrip
.dtx and .ins files might be nice. Perhaps this would open up the use of
Org to LaTeX package developers, though admittedly docstrip is deeply
rooted in planet LaTeX and hardly anything else is used.

When I release my package I'll write a makefile, in the style of the
wallcalendar package, which is also written in Org:

https://github.com/profound-labs/wallcalendar/blob/master/Makefile

BTW, Wallcalendar is the only LaTeX package I know of (besides mine,
still work in progress) that is written in Org and not in docstrip. I
don't know if there are any more...

Best regards,

Juan Manuel 

Re: org-capture and fast selection of tags

[Christian Heinrich]

Hi Ihor,

thanks for your feedback. I attached a patch, but I'm not sure why you said 
"all but the last line".
That last line for me was (org-set-tags tags), which proved important as 
otherwise the tags were not
set in the buffer.

Anyways, please find the patch attached. Feedback is welcome, particularly on 
naming the auxiliary
function (org-input-tags does not seem like a great name).

I didn't sign any papers yet, but as this is just a minor refactoring without 
new logic, I'm not
sure whether it would be required.

Best
Christian

On Sat, 2022-07-16 at 17:12 +0800, Ihor Radchenko wrote:
> Christian Heinrich  writes:
> 
> > I looked at the code and came up with a patch that works for me (see 
> > below). However, this may
> > change behavior for others:
> 
> Thanks!
> 
> > 1. The original %^g will work on non-headlines, but if 
> > (org-set-tags-command) is called as I do,
> > this is no longer possible and would need to be checked (what would be a 
> > good way here?)
> > 
> > 2. Can I really deduce from (org-use-fast-tag-selection) being non-nil that 
> > fast selection
> > should be
> > used in capture templates as well? Does it actually make sense to 
> > incorporate this into %^g/G?
> > 
> > I am neither a lisp programmer nor acquainted with the org codebase; this 
> > is a draft I came up
> > with. If you can provide me with further feedback, I'm willing to make this 
> > more stable.
> 
> The idea is reasonable, but using org-set-tags-command is not ideal
> indeed. Instead, you can take the relevant part of org-set-tags-command
> (it is all but last line of the "t" cond clause) and put it into a
> separate auxiliary function. Then, you can simply call that function
> inside the org-set-tags-command and inside the capture template code.
> 
> Best,
> Ihor
diff --git a/lisp/org-capture.el b/lisp/org-capture.el
index 9ef160d16..4f7652ca3 100644
--- a/lisp/org-capture.el
+++ b/lisp/org-capture.el
@@ -72,6 +72,7 @@
 (defvar crm-separator)
 (defvar org-end-time-was-given)
 (defvar org-keyword-properties)
+(defvar org-use-fast-tag-selection)
 (defvar org-remember-default-headline)
 (defvar org-remember-templates)
 (defvar org-store-link-plist)
@@ -1751,21 +1752,8 @@ Expansion occurs in a temporary Org mode buffer."
 			 (org-global-tags-completion-table
 			  (cond ((equal key "G") (org-agenda-files))
 (file (list file))
-(t nil
-			(org-add-colon-after-tag-completion t)
-			(ins (mapconcat
-  #'identity
-  (let ((crm-separator "[ \t]*:[ \t]*"))
-(completing-read-multiple
- (if prompt (concat prompt ": ") "Tags: ")
- org-last-tags-completion-table nil nil nil
- 'org-tags-history))
-  ":")))
-		   (when (org-string-nw-p ins)
-			 (unless (eq (char-before) ?:) (insert ":"))
-			 (insert ins)
-			 (unless (eq (char-after) ?:) (insert ":"))
-			 (when (org-at-heading-p) (org-align-tags)
+(t nil)
+   (org-input-tags)))
 		((or "C" "L")
 		 (let ((insert-fun (if (equal key "C") #'insert
 	 (lambda (s) (org-insert-link 0 s)
diff --git a/lisp/org.el b/lisp/org.el
index dd33028c6..6631d2a0a 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -11445,49 +11445,53 @@ in Lisp code use `org-set-tags' instead."
 	   'region)
 	 (lambda () (when (org-invisible-p) (org-end-of-subtree nil t))
  (t
-  (save-excursion
-	(org-back-to-heading)
-	(let* ((all-tags (org-get-tags))
-	   (table (setq org-last-tags-completion-table
-			(org--tag-add-to-alist
-			 (and org-complete-tags-always-offer-all-agenda-tags
-  (org-global-tags-completion-table
-   (org-agenda-files)))
-			 (or org-current-tag-alist (org-get-buffer-tags)
-	   (current-tags
-		(cl-remove-if (lambda (tag) (get-text-property 0 'inherited tag))
-			  all-tags))
-	   (inherited-tags
-		(cl-remove-if-not (lambda (tag) (get-text-property 0 'inherited tag))
-  all-tags))
-	   (tags
-		(replace-regexp-in-string
-		 ;; Ignore all forbidden characters in tags.
-		 "[^[:alnum:]_@#%]+" ":"
-		 (if (or (eq t org-use-fast-tag-selection)
-			 (and org-use-fast-tag-selection
-			  (delq nil (mapcar #'cdr table
-		 (org-fast-tag-selection
-		  current-tags
-		  inherited-tags
-		  table
-		  (and org-fast-tag-selection-include-todo org-todo-key-alist))
-		   (let ((org-add-colon-after-tag-completion (< 1 (length table)))
- (crm-separator "[ \t]*:[ \t]*"))
-		 (mapconcat #'identity
-(completing-read-multiple
-			 "Tags: "
-			 org-last-tags-completion-table
-			 nil nil (org-make-tag-string current-tags)
-			 'org-tags-history)
-":"))
-	  (org-set-tags tags)
+  (org-input-tags)))
 ;; `save-excursion' may not replace the point at the right
 ;; position.
 (when (and (save-excursion (skip-chars-back

non requested string translation in timestamps

[Cédric Martínez Campos]

Hi there!

When I add a timestamp through, for instance, scheduling (C-c s), the
day abbreviation is translated to my local language, that is, Spanish.
However all calendar variables, calendar-*, and, more specifically,
calendar-day-{name,header,abbrev}-array have not been modified and
keep their default values in English.

I would like to know how is this happening. Is this a bug or somehow intended?

Thx in advance,
Cédric M. Campos

Version: Emacs 28.1
Mod: Spacemacs 0.999 (fully updated develop branch)
Distro: Manjaro 21.3.3 / Ubuntu 22.4 LTS

Re: Org and Hyperbole

[Robert Weiner]

And it does highly complex context matching for many common patterns out of the 
box with no need for customization.

— rsw

> On Jul 7, 2022, at 8:26 AM, Ihor Radchenko  wrote:
> 
> Max Brieiev  writes:
> 
>> Embark defines the following targets: file, symbol, URL, s-expression,
>> defun, etc. It seems it is conceptually the same as implicit buttons in
>> Hyperbole. Is this correct?
> 
> AFAIK, the strength of Hyperbole is that you can easily define custom
> targets.
> 
> Best,
> Ihor

Re: Org and Hyperbole

[Robert Weiner]

Just noting that we have seen this and will have a look.

-- rsw

> On Jul 16, 2022, at 7:16 PM, Robert Weiner  wrote:
> 
> And it does highly complex context matching for many common patterns out of 
> the box with no need for customization.
> 
> — rsw
> 
>> On Jul 7, 2022, at 8:26 AM, Ihor Radchenko  wrote:
>> 
>> Max Brieiev  writes:
>> 
>>> Embark defines the following targets: file, symbol, URL, s-expression,
>>> defun, etc. It seems it is conceptually the same as implicit buttons in
>>> Hyperbole. Is this correct?
>> 
>> AFAIK, the strength of Hyperbole is that you can easily define custom
>> targets.
>> 
>> Best,
>> Ihor

Re: non requested string translation in timestamps

[Tim Cross]

Cédric Martínez Campos  writes:

> Hi there!
>
> When I add a timestamp through, for instance, scheduling (C-c s), the
> day abbreviation is translated to my local language, that is, Spanish.
> However all calendar variables, calendar-*, and, more specifically,
> calendar-day-{name,header,abbrev}-array have not been modified and
> keep their default values in English.
>
> I would like to know how is this happening. Is this a bug or somehow intended?
>

I'm assuming your question is why is Emacs able to put in timestamps
using my locale names for date components, but teh calendar does not?
Not sure on the answer. However, I do see that you can use M-x
cusotmize-group  calendar and from there edit the values to
whatever you want. I don't know why Emacs doesn't pick up on your locale
settings and do this automatically.

Note that calendar is part of core Emacs. You might get a better answer
if you ask this question on the emacs.devel list. Org just uses the
built in functionality, but does not implement the calendar (it does do
the timestamp bits, but these appear to be working). 

Re: [PATCH v5] ol.el: add description format parameter to org-link-parameters

[Max Nikulin]

Hi,

Ihor, Hugo raised a question how to interpret nil returned by 
:insert-description functions. Do you have any opinion? I do not like 
the idea to consider it as an error since string is expected. I would 
prefer to call `org-link-make-description-function' as a fallback.


On 17/07/2022 04:20, Hugo Heagren wrote:

Can you also update the documentation for
org-link-make-description-function?


I'm not sure what sort of documentation you have in mind? What should
I add?


I have no idea what Ihor means. From my point of view, mention of 
:insert-description and `org-link-parameters' may give a hint to users.



Have I missed something or the whole macro may be simplified to just
copy `org-link-parameters'?

`(let ((org-link-parameters (copy-tree org-link-parameters)))
   (org-link-set-parameters ,type ,@parameters)
   ,@body))


I had the same thought. I doesn't work though. `copy-tree' and
`copy-sequence' only make shallow copies of each element in a
sequence. `org-link-set-parameters' then uses side effects to alter
the `org-link-parameters', so these changes are propagated to the
copy. This means the values in the copy and the real
`org-link-parameters' are always the same, and so we can't use the
copy to store the original values (which is what we need it to do).


I have tried it again (Emacs-26.3). I agree that `copy-sequence' and 
shallow copy is not enough, but `copy-tree' works for me. It rather a 
curiosity than demanding related changes.


(defmacro nm-with-org-link-parameters (type parameters &rest body)
  (declare (indent 2))
  `(let ((org-link-parameters (copy-tree org-link-parameters)))
 (org-link-set-parameters ,type ,@parameters)
 ,@body))

(nm-with-org-link-parameters "help" (:insert-description (lambda (_link 
_descr) "h1"))

  (assoc "help" org-link-parameters))
=> ("help" :follow org-link--open-help :store org-link--store-help 
:insert-description (lambda (_link _descr) "h1"))


(assoc "help" org-link-parameters)
=> ("help" :follow org-link--open-help :store org-link--store-help)


I have never used `declare' before. I looked it up in the Elisp manual
and read the docstring, but I couldn't understand how it specifies
which argument is considered the body. I'm also not aware of what this
does/why this is useful? (not a criticism, I just haven't learned this
yet).


See info "(elisp) Indenting Macros". Without `declare' automatic 
indentation is the following:


(nm-with-org-link-parameters "help" (:insert-description (lambda (_link 
_descr) "h1"))

 (assoc "help" org-link-parameters))


and maybe even be a sibling of
 (def (org-link-get-parameter type
to keep related code more local.


This isn't possible, because that's a clause in a `let' call, which is
itself inside a `cond' clause, and the `CONDITION' of that clause uses
`type', so it has to be defined at a higher level.


It was written with assumption that `or' is used instead of `cond' to 
call `org-link-make-description-function' if :insert-description returns 
nil.



I have not tested, so I may be wrong in respect to the following. It
seems, you rises priority of desc value that earlier was a fallback.
The reason why I am in doubts, is that it seems, desc is initialized
from current link description when point is withing an existing link
and in such cases desc likely should be preserved. I can not say
that I like that it is responsibility of all description functions
to return the desc argument if it is supplied.


It's right that `desc' is initialized from current link description
when point is withing an existing link.

Previously, `desc' was only used when
`org-link-make-description-function' was nil. This seems to me a very
odd behaviour: preserve the current link description, but only when
`org-link-make-description-function' is nil. Especially considering
that `org-insert-link' is also used for editing already-existing
links. So in the original version, in some situations,
`org-link-make-description-function' had a higher priority than
`desc', which seems wrong.


In addition to changing behavior, you decision is still a trade-off. 
Consider the case when, editing some link, a user changes link path and 
expects to get new default description. When description function is 
called, to respect existing description, it may be defined as


(lambda (link desc)
 (or (org-string-nw-p desc)
 (format-string "My link %s" link)))

I do not like that in such approach checking of DESC is mandatory, so it 
is OK for me to commit your variant with high priority of DESC and to 
postpone discussion of possible improvements.


A side-note: see the following thread for a feedback form a user who is 
not happy with current prompt for description:
Visuwesh. [BUG] org-insert-link should use DEFAULT in read-string when 
asking for description. Fri, 25 Feb 2022 19:49:23 +0530. 
https://list.orgmode.org/87sfs7jafo@gmail.com



+  (t (condition-case nil
+