Citations: strip braces {} in titles in bibliographies in basic style?

[William Denton]

Let's say we have a file Basic.bib, like so, with one or two pairs of braces 
around words that need special case preservation:


@book{friends,
  title = {{LaTeX} and Friends},
  author = {van Dongen, M.R.C.},
  date = {2012},
  location = {Berlin},
  publisher = {Springer},
  doi = {10.1007/978-3-642-23816-1},
  isbn = {9783642238161}
}

@book{lispandc,
  title = {Lisp and {C}},
  author = {Example, Example},
  publisher = {Example},
  date = {2023}
}

Either one or two braces works and could well be used.  The Zotero extension 
Better Bibtex has a FAQ explaining why it uses two by default: "because the 
Bib(La)TeX case protection rules are incredibly convoluted."¹


We also have an Org file (where "/n" means no citation but the work 
stills goes in the bibliography; note that the basic citation style is set):


# -
#+bibliography: Basic.bib
#+cite_export: basic

[cite/n:@friends] [cite/n:@lispandc]

#+print_bibliography:
# --

Exporting to text (C-c C-e t A) gives this:

# --
Example, Example (2023). /Lisp and {C}/, Example.

van Dongen, M.R.C. (2012). /{{LaTeX}} and Friends/, Springer.
# --

The braces are there.  The're also visible in the HTML and ODT exports.  In 
LaTeX, in this example, they're exported but ultimately invisible because of how 
LaTeX handles "\textit{Lisp and {C}}".


Should they be stripped?  I suggest they should.

The basic style is very basic and doesn't do anything fancy in 
bibliographies---just some italics on titles, which it's showing in the text 
export with slashes, and does nicely in the others---but I wonder if it should 
remove the braces.  They are used to preserve case in titles, but the basic 
exporter doesn't change case.  Passing the braces through means people will have 
to edit them out in every basic export.



Bill

¹ https://retorque.re/zotero-better-bibtex/support/faq/#why-the-double-braces

--
William Denton
https://www.miskatonic.org/
Librarian, artist and licensed private investigator.
Toronto, Canada
CO₂: 421.66 ppm (Mauna Loa Observatory, 2023-12-11)

Faces for org blocks that are not "src"

[Maske]

Is it possible to change the face of org blocks that don't start by "src"?


For example:
 '(org-src-block-faces '(("ai" variable-pitch)))


I think it should affect to:

#+begin_ai blocks, but it doesn't seem to work for me.


Best regards

Re: oeg-add-note and double backslash ?

[David Masterson]

Ihor Radchenko  writes:

> Patches welcome.

* What is my status as far as submitting patches to documentation
  (including docstrings)?
* Is there a write-up on the process of "patching" I can follow?

-- 
David Masterson

Re: [BUG] "Safe" local values for org-entities-user not recognized as such [9.6.11 (release_9.6.11 @ /Applications/MacPorts/Emacs.app/Contents/Resources/lisp/org/)]

[Ihor Radchenko]

Aaron Madlon-Kay  writes:

>> This particular change should fit within TINYCHANGE, I think. So, you do
>> not need a copyright assignment (unless you have already exhausted the
>> 15LOC limit on Emacs patches, which I do not see in git logs).
>
> Ah, yes, that should be OK then. Please see attached.

Thanks!
Applied, onto bugfix.
Fixed.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=1ec18b8eb

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

Re: [BUG] "Safe" local values for org-entities-user not recognized as such [9.6.11 (release_9.6.11 @ /Applications/MacPorts/Emacs.app/Contents/Resources/lisp/org/)]

[Aaron Madlon-Kay]

> On Dec 12, 2023, at 23:15, Ihor Radchenko  wrote:
> 
> This particular change should fit within TINYCHANGE, I think. So, you do
> not need a copyright assignment (unless you have already exhausted the
> 15LOC limit on Emacs patches, which I do not see in git logs).

Ah, yes, that should be OK then. Please see attached.

Thanks,
Aaron



0001-lisp-org-entities.el-Fix-safe-value-predicate-for-or.patch
Description: Binary data

Re: Links & images with different attributes in the same paragraph

[Ihor Radchenko]

Max Nikulin  writes:

>> I believe that the right way to go here is what we previously discussed
>> as inline special block equivalent. That way, we will not need to create
>> workarounds with special link type.
>
> It is limitation of top-down parser that object of the same time can not 
> be nested, so I am unsure if special blocks would be solution in all cases.

Nested objects of the same type are not really a limitation of top-down
parser. It is the syntax of objects that might but does not have to be.
We might come up with a syntax that allow nesting.

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

Re: [BUG] "Safe" local values for org-entities-user not recognized as such [9.6.11 (release_9.6.11 @ /Applications/MacPorts/Emacs.app/Contents/Resources/lisp/org/)]

[Ihor Radchenko]

Aaron Madlon-Kay  writes:

> OK this was also wrong, because seq only matches a finite sequence. I couldn’t
> find a way to match an arbitrary-length list with pcase, so here’s my final
> attempt:
>
> ...
> This seems to handle all cases correctly, but again of course I leave the
> details to the devs (is seq-every-p allowed? is there actually a way to do it
> with just pcase?).

`seq-every-p' is perfectly fine. I am now aware about a way to do it just
with `pcase'.

May you turn your code into a proper patch?

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

Re: [PATCH] lisp/org-capture.el: use `org-store-link' for %K values

[Ihor Radchenko]

Kenny Ballou  writes:

> * org-capture.el (org-capture-fill-template): fill %K values using link
> value from `org-store-link', which respects `org-id-link-to-use-id'.
> * doc/ORG-NEWS: (Template variable expansion %K) Document new behavior.
>
> Reported-by: Nathaniel W Griswold 
> Signed-off-by: Kenny Ballou 
> Link: 
> https://list.orgmode.org/EF459D47-FCA4-4A18-AFC7-3E62159F186C@manicmind.earth/

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

You are now also listed as an Org contributor.
https://git.sr.ht/~bzg/worg/commit/dda15239

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

Re: [BUG] "Safe" local values for org-entities-user not recognized as such [9.6.11 (release_9.6.11 @ /Applications/MacPorts/Emacs.app/Contents/Resources/lisp/org/)]

[Aaron Madlon-Kay]

> On Dec 12, 2023, at 21:01, Aaron Madlon-Kay  wrote:
> 
>> On Dec 12, 2023, at 20:40, Aaron Madlon-Kay  wrote:
>> 
>> Locally redefining as follows results in the expected behavior:
> 
> The previous formulation was not very good. Actually it seems that the 
> existing
> function is correct except that the list case should be wrapped in (seq …).

OK this was also wrong, because seq only matches a finite sequence. I couldn’t
find a way to match an arbitrary-length list with pcase, so here’s my final
attempt:

(defun org-entities--user-safe-p (v)
  "Non-nil if V is a safe value for `org-entities-user'."
  (cond
   ((not v) t)
   ((listp v)
(seq-every-p
 (lambda (e)
   (pcase e
 (`(,(and (pred stringp)
  (pred (string-match-p "\\`[a-zA-Z][a-zA-Z0-9]*\\'")))
,(pred stringp) ,(pred booleanp) ,(pred stringp)
,(pred stringp) ,(pred stringp) ,(pred stringp))
  t)
 (_ nil)))
 v

This seems to handle all cases correctly, but again of course I leave the
details to the devs (is seq-every-p allowed? is there actually a way to do it
with just pcase?).

Thanks,
Aaron

Re: [BUG] "Safe" local values for org-entities-user not recognized as such [9.6.11 (release_9.6.11 @ /Applications/MacPorts/Emacs.app/Contents/Resources/lisp/org/)]

[Aaron Madlon-Kay]

> On Dec 12, 2023, at 20:40, Aaron Madlon-Kay  wrote:
> 
> Locally redefining as follows results in the expected behavior:

The previous formulation was not very good. Actually it seems that the existing
function is correct except that the list case should be wrapped in (seq …).

(defun org-entities--user-safe-p (v)
  "Non-nil if V is a safe value for `org-entities-user'."
  (pcase v
(`nil t)
((seq `(,(and (pred stringp)
  (pred (string-match-p "\\`[a-zA-Z][a-zA-Z0-9]*\\'")))
,(pred stringp) ,(pred booleanp) ,(pred stringp)
,(pred stringp) ,(pred stringp) ,(pred stringp)))
 t)
(_ nil)))

Regardless I leave the details to the developers.

-Aaron

Re: [BUG] Hard-coded and inconsistent todo states in org-agenda.el [9.7-pre (release_9.6.12-934-g4d72f3 @ /home/rst/Devel/org-mode/lisp/)]

[Ihor Radchenko]

Raffael Stocker  writes:

> Ihor Radchenko  writes:
>
>> May you try the attached patch?
>
> I tried it with a selection of different states (final and not) and it
> worked in every case.  Thanks!

Thanks for testing!
Fixed, on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=7505055f5

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

[BUG] "Safe" local values for org-entities-user not recognized as such [9.6.11 (release_9.6.11 @ /Applications/MacPorts/Emacs.app/Contents/Resources/lisp/org/)]

[Aaron Madlon-Kay]

Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.  You don't know how to make a good report?  See

 https://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org mailing list.


Local definitions for `org-entities-user` are not recognized as "safe"
even when they are in the correct format. For instance, including the
following local variables list in an org-mode file will still result in
Emacs prompting you to accept the value:

# Local Variables:
# org-entities-user: (("snowman" "[snowman]" nil "" "[snowman]" 
"[snowman]" "☃"))
# End:

Cause: The defcustom for `org-entities-user` has :safe set to the
function `org-entities--user-safe-p`. This function, however, appears to
be designed to validate a single entry of `org-entities-user`, rather
than the full value. Locally redefining as follows results in the
expected behavior:

(defun org-entities--user-safe-p (v)
  "Non-nil if V is a safe value for `org-entities-user'."
  (seq-every-p
   (lambda (e) (pcase e
(`nil t)
(`(,(and (pred stringp)
 (pred (string-match-p "\\`[a-zA-Z][a-zA-Z0-9]*\\'")))
   ,(pred stringp) ,(pred booleanp) ,(pred stringp)
   ,(pred stringp) ,(pred stringp) ,(pred stringp))
 t)
(_ nil)))
   v))

The difference is that the current logic has been supplied as a lambda
to `seq-every-p`.

Thank you,
Aaron

Emacs  : GNU Emacs 30.0.50 (build 1, x86_64-apple-darwin23.1.0, NS 
appkit-2487.20 Version 14.1.1 (Build 23B81))
of 2023-11-26
Package: Org mode version 9.6.11 (release_9.6.11 @ 
/Applications/MacPorts/Emacs.app/Contents/Resources/lisp/org/)

Re: Links & images with different attributes in the same paragraph

[Max Nikulin]

On 05/12/2023 20:46, Ihor Radchenko wrote:


We definitely need something to fine-tune export properties inline.
However, I am skeptical about using links for this purpose in Org
proper, not individual user configs.


Sometimes links are really links, however some links require some 
tuning. Global style or custom export backend that modifies all links is 
not always suitable.


Perhaps special :href values may be added to allow just decorations 
without hyperlinks.



I believe that the right way to go here is what we previously discussed
as inline special block equivalent. That way, we will not need to create
workarounds with special link type.


It is limitation of top-down parser that object of the same time can not 
be nested, so I am unsure if special blocks would be solution in all cases.


I have added a hack to allow definitions of links or their attributes 
outside of paragraphs. Noweb and source code blocks allow it. Perhaps is 
should be implemented as a filter to avoid tricks to get noexport source 
blocks


 8< 
A link defined in a source block
[[wrap:<> :attr_html ":class org"][Org mode]]

#+name: org-mode
#+begin_src elisp :exports none
:href "https://orgmode.org;
:attr_html ":title Org Mode — Your life in plain text"
#+end_src
 >8 

(defun nm/org-link-wrap-path-to-props (path  info)
  (let* ((with-broken-links (plist-get info :with-broken-links))
 (org-babel-noweb-error-all-langs
  (if (not with-broken-links)
  t
;; TODO Handle `mark', currently errors are ignored.
org-babel-noweb-error-all-langs))
 (expanded
  (org-babel-expand-noweb-references
   (list "elisp" path '(:noweb-prefix "no"))
   ;; Allow noweb references to code blocks
   ;; having ":exports none".
   (plist-get info :input-buffer
(read(concat "(" expanded ")"

(defun nm/org-link-wrap-assert-href (props path)
  (let ((href (plist-get props :href)))
(pcase href
  ((pred null) (signal
'org-link-broken
(list (format "no :href property in `%s'" path
  ((pred stringp) href)
  ((pred symbolp) (symbol-name href))
  (_ (signal
  'org-link-broken
  (list (format "Invalid :href type in `%s'" path)))

(defun nm/org-link-wrap-copy-props (props link)
  (while props
(let ((name (pop props))
  (value (pop props))
  (case-fold-search t))
  (org-element-put-property
   link
   name
   ;; `org-element--collect-affiliated-keywords'
   (if (string-match-p "\\`:attr_" (symbol-name name))
   (append (org-element-property name link) (list value))
 value)

(defun nm/org-link-wrap-export
(path description backend info)
  (let* ((props-all (nm/org-link-wrap-path-to-props path info))
 (href (nm/org-link-wrap-assert-href props-all path))
 ;; `org-plist-delete' removes other duplicated keys as well.
 (props (map-delete props-all :href))
 ;; Taken from `org-link-open-from-string'.
 (link (with-temp-buffer
 (let ((org-inhibit-startup nil))
   (insert "[[" (org-link-escape href) "]]")
   (org-mode)
   (goto-char (point-min))
   (org-element-link-parser)
(nm/org-link-wrap-copy-props props link)
(when description
  (org-element-set-contents link description))
(org-no-properties
 (org-export-data-with-backend link backend info

(defun nm/org-link-wrap-follow (path arg)
  (let* ((props (nm/org-link-wrap-path-to-props path))
 (href (nm/org-link-wrap-assert-href props path)))
(org-link-open-from-string
 (concat "[[" (org-link-escape href) "]]")
 arg)))

(org-link-set-parameters
 "wrap"
 :follow #'nm/org-link-wrap-follow
 :export #'nm/org-link-wrap-export)