Re: Heading toward Org 9.5
Bastien writes: > I'll work on integrating small bug fixes and feature improvements > listed on https://updates.orgmode.org during this week, aiming at > releasing Org 9.5 over the next week-end. > > If your patch does not appear on updates.orgmode.org and didn't > receive an answer on the list, please send me an email pointing at > the reference on orgmode.org/list. Hi Bastien, Back in July I mentioned a bug I found: https://lists.gnu.org/archive/html/emacs-orgmode/2021-07/msg00603.html If this could be addressed for Org 9.5, I would be grateful. As it is, it makes it difficult to keep my org-super-agenda tests working cleanly on Org versions both before and after 9.4.6. -- Thanks, Adam
[BUG] Possible Outdated Documentation, Possible Bug. "Can't compile a java block without a classname." Org-babel babel java
[Java Source Code Blocks in Org
Mode](https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-java.html)
says the following:
"It is not necessary to include the class statement or define a main method.
ob-java will wrap a source code block in boilerplate class and main method
definitions if they are omitted. If :classname and the class definition in the
source code block are both omitted, the class will be named Main."
The following example is provided:
#+begin_src java :results output
System.out.print("hello, world");
#+end_src
This returns error "can't compile a java block without a classname." This
contradicts the documentation.
This has been duplicated on Gentoo and Ubuntu 20.04 in Emacs version 27.2. org
version 9.4.4, 9.4.6 and 26.3 9.1.9 using the following .emacs.el:
(require 'org)
(org-babel-do-load-languages
'org-babel-load-languages
'(
(java . t)
))
The documentation appears to be outdated or misleading, or missing some crucial
piece of information that a newbie needs to be aware of. Please advise on
whether this is a bug and how to fix it. I am new to using the mailing list.
Upgrading to 9.4.6 did not fix this
Re: [PATCH] lisp/ox-html.el: Restore org-svg class
Bumping this patch for 9.5. On Fri, Jul 30, 2021 at 8:59 PM Tom Gillespie wrote: > > Hi, >This patch restores the addition of class="org-svg" to svg images > during html export. Best! > Tom
Re: Org lint and named source blocks
> Should we allow syntax like #+KEYWORD:value to be correct or do we > require a whitespace/space after colon all the time? The spec as written is ambiguous/silent on this issue. In my work on laundry tokenizer and grammar I have found keyword syntax to be a thorny issue, and I strongly suggest that for the time being we either make no ruling on this or we state that the colon that ends the keyword should be followed by a space as a precautionary measure. The safe thing to do is to always require whitespace after the colon because it guarantees correct interpretation. Requiring whitespace after the colon simplifies the grammar, however it means that you can't compact keyword lines, and it induces an annoying failure mode where missing spaces are no longer keywords. However, it is technically possible to make keywords work without the whitespace, so long as there is at least one whitespace prior to the next colon (but not contained in square brackets, e.g. #+key:lol[ a b c ]:value is a well formed keyword under a slighly generalized grammar). The problem is that we would like to make keyword syntax fully closed, and I need a bit more time to get that worked out before any definitive conclusions are drawn. The complexity of the generalized keyword syntax can be seen here https://github.com/tgbugs/laundry/blob/5a396bef98d9a3cd9ee929f21cd47612dd6cb1ac/laundry/lex-abbrev.rkt#L107-L249 Best, Tom
Re: [PATCH] ox.el: add smart quotes for Greek
Hi Maxim, Max Nikulin writes: > [...] > Possible options: > - Add the note directly to the .el file. I am afraid, as inline > comment it could be considered too long. > - To a file in the "doc" directory dedicated to such decisions (there > is no such file yet however) with a reference from the .el file. > - Commit message. It is acceptable but not apparent for a person who > reads the code that git log may provide detailed explanation of > particular choice. Thanks for your suggestions. Maybe I could add a link to the Haralambous paper in the commit message, along with a very short note... In any case, the only issue is with the second level opening quotes. Haralambous asserts that the (pretty rare) character U+201F must be used, and not the character U+201C, which is the one used in English (among many other languages) and in Spanish second level quotes, and the one that I have applied (proposed by Protesilaos) to the patch. Haralambous is a great TeX guru, and a great scholar and theorist of Greek typography, but... I would say that in this case his mind is more focused on a historical tradition probably abandoned before the digital age. I really don't know. Moreover, it is difficult to find specimens of the use of second-level quotation marks. I have looked in Greek books printed in the early and middle of the last century, and I have not found anything. My suspicion is that in Greek nowadays the character U+201C (common in other languages ---as I said before--- and therefore better known) has ended up standardizing for second level opening quotes. Maybe all the above could be summarized in less than one line inside the commit message ;-). A quick search, by the way, of the term 'εισαγωγικά' (= 'quotation marks') on www.greek-language.gr returns this result, where it is seen clearly the character U+201C: ... (« » ή “ ”) ... https://www.greek-language.gr/greekLang/modern_greek/tools/lexica/search.html?lq=%CE%B5%CE%B9%CF%83%CE%B1%CE%B3%CF%89%CE%B3%CE%B9%CE%BA%CE%AC Best regards, Juan Manuel
Re: BUG Visibility Cycling with inline tasks
Hi Ihor, Thanks for checking. I could narrow down on the issue. It happens after (require 'org-inlinetask) is executed. So to reproduce: 1. emacs -Q 2. paste the following snipped (right into the scratch buffer) 3. execute the two commands at the end C-x C-e for each 4. collapse all (TAB TAB) 5. expand Example (TAB) 5. go to heading 2 and expand it (TAB) This should surface the issue. >>> * Example ** heading 1 x ** heading 2 *** TODO Test access with provided credentials x *** END ** heading 3 *** TODO State "high value" targets :@CB: x *** END ** heading 4 x (org-mode) (require 'org-inlinetask) <<< Am Mo., 20. Sept. 2021 um 10:21 Uhr schrieb Ihor Radchenko < yanta...@gmail.com>: > Michael Dauer writes: > > > What I get after the first org-cycle is: > > * Example > > ** heading 1 > > ** heading 2 > > * ** TODO Test access with provided credentials > > ** heading 3 > > x > > * ** END > > ** heading 4 > > x > > > > I cannot reproduce on latest master and with Org 9.4.4. What I am seeing > is: > > * Example > ** heading 1... > ** heading 2 > * ** TODO Test access with provided credentials... > * ** END > * heading 3... > * heading 4 > > Another cycle reveals the inlinetask contents: > > * Example > ** heading 1... > ** heading 2 > * ** TODO Test access with provided credentials > x > * ** END > * heading 3... > * heading 4 > > Maybe something with your config? Can you reproduce starting from emacs -Q? > > Best, > Ihor >
Re: [patch suggestion] Mitigating the poor Emacs performance on huge org files: Do not use overlays for PROPERTY and LOGBOOK drawers
I’m suspect it too short notice for such a large change to make its way into Org 9.5, but Bastien’s release email is certainly a good prompt to bump this. Bastien writes: > Thank you *very much* for this work and sorry for the slow reply. > > I urge everyone to test this change, as I’d like to include it in > Org 9.5 if it’s ready. > > I will test this myself this week and report. All the best, Timothy
Re: Org lint and named source blocks
Dominik Schrempf writes: > Running =org-lint= on an Org file containing > > #+NAME:Hello > #+BEGIN_SRC emacs-lisp :exports code > #+END_SRC > > I get the following error: > #+begin_quote > Debugger entered--Lisp error: (search-failed "^[ \11]*#\\+[A-Za-z]+: +Hello > *$") > #+end_quote Confirmed. This one is tricky. The linter (org-lint-duplicate-name) expects that NAME keyword must have space before value. However, the actual Org parser (org-element--collect-affiliated-keywords) does not care about space. My intuition says that the parser behaviour is unintentional. However, not requiring a whitespace may also be a valid syntax. Dear Orgers, Should we allow syntax like #+KEYWORD:value to be correct or do we require a whitespace/space after colon all the time? Best, Ihor
Re: Org lint and Haskell source code blocks
Dominik Schrempf writes: > Thank you, org-lint works just fine after applying your patch! The patch is applied to master as c9dc6603a. Best, Ihor
Org lint and named source blocks
Thank you for the Haskell fix! I found another issue (not a bug but could be handled better): Running =org-lint= on an Org file containing #+NAME:Hello #+BEGIN_SRC emacs-lisp :exports code #+END_SRC I get the following error: #+begin_quote Debugger entered--Lisp error: (search-failed "^[ \11]*#\\+[A-Za-z]+: +Hello *$") #+end_quote The code is faulty because there should be a space between #+NAME: and Hello, like so: #+NAME: Hello #+BEGIN_SRC emacs-lisp :exports code #+END_SRC However, this should probably be reported by =org-lint= as an Org syntax error, and not lead to an error when executing =org-lint=. What do you think? Thank you, Dominik
Re: Org lint and Haskell source code blocks
Thank you, org-lint works just fine after applying your patch! Ihor Radchenko writes: > Dominik Schrempf writes: > >> whenever I have a Haskell source code block in my Org mode file, and I >> execute >> =org-lint=, I get the following error: > > Confirmed. > > Can you try with the attached patch? > > Best, > Ihor > > [2. text/x-diff; > 0001-Fix-org-babel-header-args-haskell-not-being-an-alist.patch] > From f640249d08a14bfde417c38274634b88c789d1c7 Mon Sep 17 00:00:00 2001 > Message-Id: > > From: Ihor Radchenko > Date: Tue, 21 Sep 2021 15:10:45 +0800 > Subject: [PATCH] Fix org-babel-header-args:haskell not being an alist > > * lisp/ob-haskell.el (org-babel-header-args:haskell): The old value of > the variable was not argument alist, as expected by Org babel code. > > Fixes https://orgmode.org/list/87fsty7750@gmail.com > --- > lisp/ob-haskell.el | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/lisp/ob-haskell.el b/lisp/ob-haskell.el > index a6f0e55f7..971e1ce6a 100644 > --- a/lisp/ob-haskell.el > +++ b/lisp/ob-haskell.el > @@ -70,7 +70,7 @@ (defcustom org-babel-haskell-compiler "ghc" >:package-version '(Org "9.4") >:type 'string) > > -(defconst org-babel-header-args:haskell '(compile . :any) > +(defconst org-babel-header-args:haskell '((compile . :any)) >"Haskell-specific header arguments.") > > (defun org-babel-haskell-execute (body params)
Re: Org lint and Haskell source code blocks
Dominik Schrempf writes: > whenever I have a Haskell source code block in my Org mode file, and I execute > =org-lint=, I get the following error: Confirmed. Can you try with the attached patch? Best, Ihor >From f640249d08a14bfde417c38274634b88c789d1c7 Mon Sep 17 00:00:00 2001 Message-Id: From: Ihor Radchenko Date: Tue, 21 Sep 2021 15:10:45 +0800 Subject: [PATCH] Fix org-babel-header-args:haskell not being an alist * lisp/ob-haskell.el (org-babel-header-args:haskell): The old value of the variable was not argument alist, as expected by Org babel code. Fixes https://orgmode.org/list/87fsty7750@gmail.com --- lisp/ob-haskell.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/ob-haskell.el b/lisp/ob-haskell.el index a6f0e55f7..971e1ce6a 100644 --- a/lisp/ob-haskell.el +++ b/lisp/ob-haskell.el @@ -70,7 +70,7 @@ (defcustom org-babel-haskell-compiler "ghc" :package-version '(Org "9.4") :type 'string) -(defconst org-babel-header-args:haskell '(compile . :any) +(defconst org-babel-header-args:haskell '((compile . :any)) "Haskell-specific header arguments.") (defun org-babel-haskell-execute (body params) -- 2.32.0
Org lint and Haskell source code blocks
Hi,
whenever I have a Haskell source code block in my Org mode file, and I execute
=org-lint=, I get the following error:
#+begin_quote
Debugger entered--Lisp error: (wrong-type-argument listp :any)
#+end_quote
(This was obtained with a minimal file just having:
#+BEGIN_SRC haskell
inc n = n+1
#+END_SRC
)
Do you have an idea about what could be the problem? =org-lint= works just fine
in other buffers without Haskell code blocks.
Please find the full error message below.
Thank you,
Dominik
--
Debugger entered--Lisp error: (wrong-type-argument listp :any)
mapcar(car (compile . :any))
#f(compiled-function (l) #)("haskell")
mapcan(#f(compiled-function (l) #) ("haskell"))
cl-mapcan(#f(compiled-function (l) #) ("haskell"))
#f(compiled-function (datum language headers) #)((src-block (:language "haskell" :switches nil :parameters nil
:begin 1 :end 43 :number-lines nil :preserve-indent nil :retain-labels t
:use-labels t :label-fmt nil :value "inc n = n+1\n" :post-blank 0
:post-affiliated 1 :parent (section (:begin 1 :end 43 :contents-begin 1
:contents-end 43 :post-blank 0 :post-affiliated 1 :parent (org-data nil #31))
#1))) "haskell" nil)
#f(compiled-function (datum) #)((src-block (:language
"haskell" :switches nil :parameters nil :begin 1 :end 43 :number-lines nil
:preserve-indent nil :retain-labels t :use-labels t :label-fmt nil :value "inc
n = n+1\n" :post-blank 0 :post-affiliated 1 :parent (section (:begin 1 :end 43
:contents-begin 1 :contents-end 43 :post-blank 0 :post-affiliated 1 :parent
(org-data nil #31)) #1
#f(compiled-function (--data) #)((src-block (:language
"haskell" :switches nil :parameters nil :begin 1 :end 43 :number-lines nil
:preserve-indent nil :retain-labels t :use-labels t :label-fmt nil :value "inc
n = n+1\n" :post-blank 0 :post-affiliated 1 :parent (section (:begin 1 :end 43
:contents-begin 1 :contents-end 43 :post-blank 0 :post-affiliated 1 :parent
(org-data nil #31)) #1
mapc(#f(compiled-function (--data) #) ((src-block
(:language "haskell" :switches nil :parameters nil :begin 1 :end 43
:number-lines nil :preserve-indent nil :retain-labels t :use-labels t
:label-fmt nil :value "inc n = n+1\n" :post-blank 0 :post-affiliated 1 :parent
(section (:begin 1 :end 43 :contents-begin 1 :contents-end 43 :post-blank 0
:post-affiliated 1 :parent (org-data nil #33)) . #2)
#f(compiled-function (--data) #)((section (:begin 1 :end
43 :contents-begin 1 :contents-end 43 :post-blank 0 :post-affiliated 1 :parent
(org-data nil #1)) (src-block (:language "haskell" :switches nil :parameters
nil :begin 1 :end 43 :number-lines nil :preserve-indent nil :retain-labels t
:use-labels t :label-fmt nil :value "inc n = n+1\n" :post-blank 0
:post-affiliated 1 :parent #1
mapc(#f(compiled-function (--data) #) ((section (:begin 1
:end 43 :contents-begin 1 :contents-end 43 :post-blank 0 :post-affiliated 1
:parent (org-data nil . #2)) (src-block (:language "haskell" :switches nil
:parameters nil :begin 1 :end 43 :number-lines nil :preserve-indent nil
:retain-labels t :use-labels t :label-fmt nil :value "inc n = n+1\n"
:post-blank 0 :post-affiliated 1 :parent #3)
#f(compiled-function (--data) #)((org-data nil (section
(:begin 1 :end 43 :contents-begin 1 :contents-end 43 :post-blank 0
:post-affiliated 1 :parent #1) (src-block (:language "haskell" :switches nil
:parameters nil :begin 1 :end 43 :number-lines nil :preserve-indent nil
:retain-labels t :use-labels t :label-fmt nil :value "inc n = n+1\n"
:post-blank 0 :post-affiliated 1 :parent #4)
org-element-map((org-data nil (section (:begin 1 :end 43 :contents-begin 1
:contents-end 43 :post-blank 0 :post-affiliated 1 :parent #1) (src-block
(:language "haskell" :switches nil :parameters nil :begin 1 :end 43
:number-lines nil :preserve-indent nil :retain-labels t :use-labels t
:label-fmt nil :value "inc n = n+1\n" :post-blank 0 :post-affiliated 1 :parent
#4 (babel-call inline-babel-call inline-src-block keyword node-property
src-block) #f(compiled-function (datum) #))
org-lint-wrong-header-argument((org-data nil (section (:begin 1 :end 43
:contents-begin 1 :contents-end 43 :post-blank 0 :post-affiliated 1 :parent #1)
(src-block (:language "haskell" :switches nil :parameters nil :begin 1 :end 43
:number-lines nil :preserve-indent nil :retain-labels t :use-labels t
:label-fmt nil :value "inc n = n+1\n" :post-blank 0 :post-affiliated 1 :parent
#4)
#f(compiled-function (c) #)(#s(org-lint-checker :name
wrong-header-argument :description "Report wrong babel headers" :categories
(babel) :trust high))
mapcan(#f(compiled-function (c) #) (#s(org-lint-checker
:name duplicate-custom-id :description "Report duplicates CUSTOM_ID prop..."
:categories (link) :trust high) #s(org-lint-checker :name duplicate-name
:description "Report duplicate NAME values" :categories (babel link) :trust
high) #s(org-lint-checker :name duplicate-target :description "Report duplicate
targets"
