[-- Attachment #1: Type: text/plain, Size: 439 bytes --] Hi there, I’ve noticed that `org-element-parser` upcases the keywords, even though the standard established in 13424336a6f30c50952d291e7a82906c1210daf0 is to ‘Prefer lower case letters for blocks and keywords’. I’ve changed it to `downcase` to maintain consistency. This might cause problems with some hard-coded upper case letters in the codebase, but I haven’t run into any issue so far. HTH, -- Leo Vivier [-- Attachment #2: 0001-org-element.el-Fix-properties-being-upcased-by-parse.patch --] [-- Type: text/x-patch, Size: 1309 bytes --] From 574549a1ab07fd1500111a25d3f1caec4aa40bfb Mon Sep 17 00:00:00 2001 From: Leo Vivier <leo.vivier+dev@gmail.com> Date: Mon, 8 Jun 2020 12:14:55 +0200 Subject: [PATCH] org-element.el: Fix properties being upcased by parser MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * org-element.el (org-element-keyword-parser): Downcase properties instead of upcasing them. This is to follow the standard established by 13424336a6f30c50952d291e7a82906c1210daf0 to ‘Prefer lower case letters for blocks and keywords’. TINY CHANGE --- lisp/org-element.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/org-element.el b/lisp/org-element.el index ac41b7650..e73b37b2b 100644 --- a/lisp/org-element.el +++ b/lisp/org-element.el @@ -2184,7 +2184,7 @@ containing `:key', `:value', `:begin', `:end', `:post-blank' and (let ((begin (or (car affiliated) (point))) (post-affiliated (point)) (key (progn (looking-at "[ \t]*#\\+\\(\\S-*\\):") - (upcase (match-string-no-properties 1)))) + (downcase (match-string-no-properties 1)))) (value (org-trim (buffer-substring-no-properties (match-end 0) (point-at-eol)))) (pos-before-blank (progn (forward-line) (point))) -- 2.26.2
Hello,
Leo Vivier <leo.vivier+dev@gmail.com> writes:
> I’ve noticed that `org-element-parser` upcases the keywords, even though
> the standard established in 13424336a6f30c50952d291e7a82906c1210daf0 is
> to ‘Prefer lower case letters for blocks and keywords’.
>
> I’ve changed it to `downcase` to maintain consistency. This might cause
> problems with some hard-coded upper case letters in the codebase, but
> I haven’t run into any issue so far.
This is unrelated to capitalization usage in Org buffers. Upcasing is
used to tell the difference between, e.g., :value and :VALUE.
Regards,
--
Nicolas Goaziou
Hello,
Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
> This is unrelated to capitalization usage in Org buffers. Upcasing is
> used to tell the difference between, e.g., :value and :VALUE.
I understand, but I think the function is also used to modify
file-parameters like `#+title`. If you run `org-element-parse-buffer`
on a buffer with the following content:
--------------------------------[START]--------------------------------
#+title: Foo
---------------------------------[END]---------------------------------
Here’s what you get:
--------------------------------[START]--------------------------------
(org-data
nil
(section
(:begin 1
:end 14
:contents-begin 1
:contents-end 14
:post-blank 0
:post-affiliated 1
:parent #0)
(keyword
(:key "TITLE" ; <----------
:value "Foo"
:begin 1
:end 14
:post-blank 0
:post-affiliated 1
:parent #1))))
---------------------------------[END]---------------------------------
This caused us some head-scratching when we updated Org-roam to use
lower case file-parameters.
Here’s how my Edebug session went:
org-element-parse-buffer
-> org-element--parse-elements
-> org-element--current-element
--------------------------------[START]--------------------------------
((looking-at "\\+\\S-+:")
(beginning-of-line)
(org-element-keyword-parser limit affiliated))
---------------------------------[END]---------------------------------
Ultimately, it’s not changing anything for the users, but I did find it
a little counterintuitive.
HTH,
--
Leo Vivier
Leo Vivier <leo.vivier+dev@gmail.com> writes: > I understand, but I think the function is also used to modify > file-parameters like `#+title`. If you run `org-element-parse-buffer` > on a buffer with the following content: > > --------------------------------[START]-------------------------------- > #+title: Foo > ---------------------------------[END]--------------------------------- > > > Here’s what you get: > > --------------------------------[START]-------------------------------- > (org-data > nil > (section > (:begin 1 > :end 14 > :contents-begin 1 > :contents-end 14 > :post-blank 0 > :post-affiliated 1 > :parent #0) > (keyword > (:key "TITLE" ; <---------- Keywords are stored in a normalized form. In this case, this is uppercase, for reasons. I don't see an issue here. The docstring could specify it, tho. > Ultimately, it’s not changing anything for the users, but I did find it > a little counterintuitive. IMO, this is not worth changing. Besides, I'm quite sure it will break some code elsewhere. Why bother?
Hi there,
Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
> IMO, this is not worth changing. Besides, I'm quite sure it will break
> some code elsewhere. Why bother?
Yeah, I’ve reached the same conclusion, and I agree that we could
mention the normalisation in a docstring. Do you want me to take care
of it?
Best,
--
Leo Vivier
Leo Vivier <leo.vivier+dev@gmail.com> writes:
> Yeah, I’ve reached the same conclusion, and I agree that we could
> mention the normalisation in a docstring. Do you want me to take care
> of it?
Sure! Thank you.
[-- Attachment #1: Type: text/plain, Size: 348 bytes --] Hello, Nicolas Goaziou <mail@nicolasgoaziou.fr> writes: > Leo Vivier <leo.vivier+dev@gmail.com> writes: > >> Yeah, I’ve reached the same conclusion, and I agree that we could >> mention the normalisation in a docstring. Do you want me to take care >> of it? > > Sure! Thank you. The patch is attached. HTH, -- Leo Vivier [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 0001-org-element.el-Update-comment.patch --] [-- Type: text/x-patch, Size: 1190 bytes --] From e96e96931109026f406b3cabb0186319e902aca7 Mon Sep 17 00:00:00 2001 From: Leo Vivier <leo.vivier+dev@gmail.com> Date: Fri, 12 Jun 2020 06:45:32 +0200 Subject: [PATCH] org-element.el: Update comment * org-element.el (org-element-keyword-parser): Mention that `keyword' is normalized by being upcased --- lisp/org-element.el | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/lisp/org-element.el b/lisp/org-element.el index a5641e6ee..a693cb68d 100644 --- a/lisp/org-element.el +++ b/lisp/org-element.el @@ -2174,9 +2174,9 @@ the buffer position at the beginning of the first affiliated keyword and CDR is a plist of affiliated keywords along with their value. -Return a list whose CAR is `keyword' and CDR is a plist -containing `:key', `:value', `:begin', `:end', `:post-blank' and -`:post-affiliated' keywords." +Return a list whose CAR is a normalized `keyword' (uppercase) and +CDR is a plist containing `:key', `:value', `:begin', `:end', +`:post-blank' and `:post-affiliated' keywords." (save-excursion ;; An orphaned affiliated keyword is considered as a regular ;; keyword. In this case AFFILIATED is nil, so we take care of -- 2.26.2
Hello,
Leo Vivier <leo.vivier+dev@gmail.com> writes:
> From e96e96931109026f406b3cabb0186319e902aca7 Mon Sep 17 00:00:00 2001
> From: Leo Vivier <leo.vivier+dev@gmail.com>
> Date: Fri, 12 Jun 2020 06:45:32 +0200
> Subject: [PATCH] org-element.el: Update comment
>
> * org-element.el (org-element-keyword-parser): Mention that `keyword'
> is normalized by being upcased
Applied. Thank you.
Regards,
--
Nicolas Goaziou