Re: [PATCH] Add tests for ob-haskell (GHCi)

[Bruno Barbier]

Hi Ihor,

Ihor Radchenko  writes:

> A few months have passed since the last activity in this thread.
> Bruno, may I know if you are still interested to work on the patch?

Thanks for the reminder.  I'm definitely interested to closing that
thread.

I'll review my last changes and send my updated patch.

Thank you for your patience,

Bruno.

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

Re: [RFC] Quoting property names in tag/property matches [Was: [BUG?] Matching tags: & operator no more implicit between tags and special property]

[Jens Schmidt]

On 2023-08-24  10:52, Jens Schmidt wrote:
> On 2023-08-24  09:32, Ihor Radchenko wrote:

>> I prefer (B). And we will need to allow escaping of the "\" itself. Like
>> \\.
> 
> OK.  Since backslash is not used yet in the rest of the regexp, (B)
> should be rather edge-case-free.  So the corresponding subre to match
> property names would look like
> 
>   \(?5:\(?:[[:alnum:]]+\|\\[^[:space:]]\)+\)
> 
> IOW, backslash quotes everything except whitespace, which by definition
> cannot be part of a property name.
> 
> Will start on this, but with tests and documentation this might take
> some time.

Here comes a first patch ... please check.From 830750bfa10b52ac77abe8af1f2789057f9101c1 Mon Sep 17 00:00:00 2001
From: Jens Schmidt 
Date: Thu, 24 Aug 2023 22:38:02 +0200
Subject: [PATCH] org-make-tags-matcher: Re-add quoting of property names

* lisp/org.el (org-make-tags-matcher):
* testing/lisp/test-org.el (test-org/map-entries): Move special cased
handling of LEVEL properties.  Add tests for other special cased
properties TODO and CATEGORY.

* lisp/org.el (org-make-tags-matcher):
* doc/org-manual.org (Matching tags and properties):
* testing/lisp/test-org.el (test-org/map-entries): Re-add and extend
quoting of property names in search strings.

Link: https://orgmode.org/list/87h6oq2nu1@gmail.com
---
 doc/org-manual.org   | 20 +++
 lisp/org.el  | 55 
 testing/lisp/test-org.el | 34 +
 3 files changed, 66 insertions(+), 43 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 17b25fef4..10a03b344 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -9320,21 +9320,19 @@ With the regular =<= operator, the search would handle entries without
 an =EFFORT= property as having a zero effort and would include them in
 the result as well.
 
-Currently, you can use only property names including alphanumeric
-characters, underscores, and minus characters in search strings.  In
-addition, if you want to search for a property whose name starts with
-a minus character, you have to "quote" that leading minus character
-with an explicit positive selection plus character, like this:
+You can use all characters valid in property names when matching
+properties.  However, you have to quote some characters in property
+names with backslashes when using them in search strings, namely all
+characters different from alphanumerics and underscores[fn:: If you
+quote alphanumeric characters or underscores with a backslash, that
+backslash is ignored.].  For example, to search for all entries having
+a property =-long​=and\twisted:property.name*= with value =foo=, use
+search string
 
 #+begin_example
-+-long-and-twisted-property-name-="foo"
+\-long\=and\\twisted\:property\.name\*="foo"
 #+end_example
 
-#+texinfo: @noindent
-Without that extra plus character, the minus character would be taken
-to indicate a negative selection on search term
-=long-and-twisted-property-name-​="foo"=.
-
 You can configure Org mode to use property inheritance during
 a search, but beware that this can slow down searches considerably.
 See [[*Property Inheritance]], for details.
diff --git a/lisp/org.el b/lisp/org.el
index 50df1b2d9..78f8eb2e9 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -11328,15 +11328,14 @@ See also `org-scan-tags'."
   "\\(?2:"
   ;; tag regexp match
   "{[^}]+}\\|"
-  ;; LEVEL property match.  For sake of consistency,
-  ;; recognize starred operators here as well.  We do
-  ;; not need to process them below, however, since
-  ;; the LEVEL property is always present.
-  "LEVEL\\(?3:" opre "\\)\\*?\\(?4:[0-9]+\\)\\|"
-  ;; regular property match
+  ;; property match.  Try to keep this subre generic
+  ;; and rather handle special properties like LEVEL
+  ;; and CATEGORY further below.  This ensures that
+  ;; the same quoting mechanics can be used for all
+  ;; property names.
   "\\(?:"
   ;; property name [1]
-  "\\(?5:[[:alnum:]_-]+\\)"
+  "\\(?5:\\(?:[[:alnum:]_]+\\|[^[:space:]]\\)+\\)"
   ;; operator, optionally starred
   "\\(?6:" opre "\\)\\(?7:\\*\\)?"
   ;; operand (regexp, double-quoted string,
@@ -11353,13 +11352,19 @@ See also `org-scan-tags'."
  (start 0)
  tagsmatch todomatch tagsmatcher todomatcher)
 
-;; [1] The minus characters in property names do *not* conflict
-;; with the exclusion operator above, since the mandatory
-;; following operator distinguishes these both cases.
-;; Accordingly, minus characters do not need any special quoting,
-;; even if https://orgmode.org/list/87jzv67k3p.fsf@localhost and
-;; 

Re: [DISCUSSION] Re-design of inlinetasks

[Juan Manuel Macías]

Ihor Radchenko writes:

> 1. Inlinetasks should be exported as "boxes" - something similar to
>margin or inline notes
>- Can be used as a memo TODO in draft publication printout
>- As Samuel suggested, inlinetasks could be a basis of review
>  comments - like what GDocs/Office provides in margin "chat"

I think inlinetasks may also have a use for those sections that are not
"nested". In typography they are usually called "anonymous sections" and
they are separated by some symbol (asterisks, dinkus[1], etc.). They
behave like a true section, except that they are not headed by titles or
level numbers. I think Org's support for these types of sections would
be useful and novel, since there is (as far as I know) nothing similar
in other lightweight markup languages. Anonymous sections can be useful
not only in print or PDF texts but also on web pages.

https://en.wikipedia.org/wiki/Dinkus

Best regards,

Juan Manuel 

Re: Timed lists in org mode

[Russell Adams]

On Fri, Aug 25, 2023 at 01:55:03PM +, Ribeiro, Glauber wrote:
> All,
>
> I often document the running of complex processes such as software installs 
> by writing down a list with times like this:
>
> 08:00 – started
> 08:05 – prompt about debug data
> 08:07 – database update started
> …
>
> and so on. I seem to remember seeing a way to do this in org, where you just 
> hit “enter” and the next line already gets populated with a time stamp. 
> However, I haven’t been able to find it. Of course the format doesn’t need to 
> be exactly that. Just the convenience of automatically adding the timestamp 
> when I start a new line.
>
> Does this exist in org? Or did I imagine it?
>

https://orgmode.org/org.html#Timers

M-x org-timer-start

C-x C-c -   to insert the first line

Creates lines like this:

- 0:00:17 :: wugga
- 0:00:21 :: hi
- 0:00:23 :: this is a timer

After the first line, you can do M-Enter to create a new list item and
the timestamp automatically updates.


--
Russell Adamsrlad...@adamsinfoserv.com
https://www.adamsinfoserv.com/

Timed lists in org mode

[Ribeiro, Glauber]

All,

I often document the running of complex processes such as software installs by 
writing down a list with times like this:

08:00 – started
08:05 – prompt about debug data
08:07 – database update started
…

and so on. I seem to remember seeing a way to do this in org, where you just 
hit “enter” and the next line already gets populated with a time stamp. 
However, I haven’t been able to find it. Of course the format doesn’t need to 
be exactly that. Just the convenience of automatically adding the timestamp 
when I start a new line.

Does this exist in org? Or did I imagine it?

Thanks,

glauber
---
glauber.ribe...@experian.com

Re: Passing table to Ruby session

[Ihor Radchenko]

Ihor Radchenko  writes:

> Also, it looks like ruby sessions are broken now:

At least, this one is fixed.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=430c72924

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

Re: Unclear where ob-spice.el is being maintained

[Ihor Radchenko]

Jonas Bernoulli  writes:

> In 2022 I changed Melpa to get ob-spice.el from
> https://repo.or.cz/ob-spice.git in response to
> https://github.com/melpa/melpa/issues/7872#issuecomment-1034945112.

The last discussion was back in 2020 
https://list.orgmode.org/orgmode/cal1eyul8zzg-fdeedovbvm1cfc8w6ajwfr7cthvgs8owdwj...@mail.gmail.com/

However, your reference is 2022.
So, unless Christopher has something to say,
https://repo.or.cz/ob-spice.git is the last known active maintenance
location. The last commit is 2022
https://repo.or.cz/ob-spice.git/shortlog, and includes more changes
compared to ob-spice version in org-contrib.

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

Re: [MAINTENANCE] Org orphanage?

[Ihor Radchenko]

Jonas Bernoulli  writes:

> Thanks for offering to help out Corwin!
>
>>> Speaking for myself, I can help:
>>> [...]
>>> - review the bonafides (experience/involvement and, via Eli/SM,
>>> assignment status ) for prospective adopting maintainers
>>
>> Not sure about emacsorphanage side, but for things we decide to manage
>> on sr.ht, we can all discuss new maintainers on this mailing list. The
>> maintenance requests should also go here.
>
> The orphanage is often first brought up in the package's issue tracker,
> or on Melpa's issue tracker.  Sometimes I bring it up, sometimes a user
> of a package makes us aware of a stale package.

How do you determine when to bring up the issue? If we have a clear
criterion, I can see how Corwin or other volunteers may help - by
contacting the package authors by email/on forge they use.

> If you are interested in that kind of work looked through the list of
> orphaned packages for something that interests you and then offer to
> maintain that.

That reminds me of Emacs survey. Since the best source of maintainers is
package's own user base, may it be a good idea to ask in Emacs survey if
people use some orphaned packages?

>>> Irrespective of whether worg curators should help with this (or some
>>> other vols, or just the org maintainers, or...), I think it would make
>>> sense to document these "responsibilities" (and the detail of the
>>> plans made in this thread, in general), along with the whos and hows.
>>
>> +1
>
> I'll try collecting existing resources and maybe write some new ones,
> but I have a lot on my plate, so this will likely take a while.

A draft might be prepared by volunteers. Will it make things easier for
you?

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

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

Samuel Wales  writes:

> another idea, at the cost of 3 dumb messages in a row  there are
> annotation packages.  i wonder if integration of those is relevant.

Somewhat. The problem is when we want to associate inlinetask with
something more granular than a paragraph.

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

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

Samuel Wales  writes:

> i was also wondering if links and/or some type of transclusion could
> also obviate inline tasks.  the formerly-inline task would contain a
> link to a target above the paragraph.  c-c c-c on that location would
> take you back to the task.

I though about links to target paragraph. But that would require adding
#+name to paragraph in question or creating a long fuzzy search link -
very inconvenient when editing Org as plain text file. I'd prefer some
other approach, if possible.

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

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

spookygos...@gmail.com writes:

> Bastien Guerry  writes:
>> …
>> E.g. perhaps allowing a :noheadingexport: tag to prevent the export of
>> a heading would fit 90% of what is expected from inline tasks in the
>> example you gave.
>> …
> There is functionality for a `:noexport:'  tag already built in. Do you 
> intend `:noheadingexport:'  to apply only to the top level of the tree it is 
> applied to? If so, that would probably not play nicely with tag inheritance.

Tag inheritance is not a problem. We can always add special tags to 
`org-tags-exclude-from-inheritance'.

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

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

Russell Adams  writes:

>> > I think Markdown has different levels?
>>
>> Do you mean # title vs. ## title?
>
> https://www.markdownguide.org/basic-syntax
>
> look at the alternate syntax where they under line with different symbols.

Ah. That thing. It will move Org towards more complex syntax. I am not
in favour.

> We have a solid heading syntax, with one or more asterisks followed by
> keywords and heading metadata. Given we're talking about adding more
> flags in the metadata, I'm just asking if we should consider
> alternatives to just asterisks to help indicate differences.
>
> An inline task exempt from folding should be eye catching to
> differentiate it from other headings. Perhaps something other than
> asterisks is appropriate?

Bastien voiced against adding yet more syntax elements. So, let's try to
find some way that will not involve completely new syntax element and
instead stick closer to the existing syntax.

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

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

to...@tuxteam.de writes:

> Back to the case in question: Someone proposed intercalating a
> subsection instead of using an inline task, which would work
> if there were a way of "closing" that subsection; otherwise the
> idea messes with the document structure.

I see. This has been discussed previously. The main problem is that such
sections cannot be exported to latex/odt easily. So, we will complicate
export substantially.

And it will not be too different from the current approach. Even worse,
actually:

1. Similar to now, we will need to modify the parser, skipping some of
   the headings, that must no longer be considered proper headings, but
   rather "continuations"

2. We will have to allow nested proper headings inside sections, which
   will break logic all over the Org codebase.

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

[DISCUSSION] Re-design of inlinetasks (was: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?)

[Ihor Radchenko]

Bastien Guerry  writes:

> I suggest removing the support for inline tasks *as they are designed
> today*, yes.

What I have in mind is slightly different: Keep inlinetasks for now and
implement a better alternative, which we can hopefully come up with in
this discussion. Later, promote the alternative, slowly deprecating the
current inlinetask implementation. Eventually, remove inlinetask code
from Org in favour of the new alternative.

> ...  I suggest reassessing the real problem we are trying to
> solve here, and see if we can come up with an approach that does not
> complexify Org's core syntax too much.

> E.g. perhaps allowing a :noheadingexport: tag to prevent the export of
> a heading would fit 90% of what is expected from inline tasks in the
> example you gave.

>...  Again, if the core feature is
> to prevent some headings from being exported, then other approaches
> can be explored.

May you elaborate? Is it something similar to :ignore: tag from ox-extra
contributed package?

If so, it is not what the use-cases I have in mind are about:

1. Inlinetasks should be exported as "boxes" - something similar to
   margin or inline notes
   - Can be used as a memo TODO in draft publication printout
   - As Samuel suggested, inlinetasks could be a basis of review
 comments - like what GDocs/Office provides in margin "chat"

2. When folding, I expect inlinetasks to behave like drawers/blocks -
   not hiding the continuation text below.

>> Yup. That's why I think that we need to make inlinetasks have distinct
>> syntax.
>
> I'm reluctant to supercharge Org's core syntax for this feature.
> I may be wrong, but I'd love to see if inline tasks are widely used,
> and if so, for what specific purpose.

I understand and tend to agree that it would be best to avoid extending
Org syntax too much.

Generally, the two points I listed above can be accomplished if we use
ordinary headings with a special tag. However, I am also not fully sold
on such idea. It would be nice if inlinetasks would not require adding
many stars in front, even in deeply nested subtrees.

What about another popular request - people often want to turn plain
lists into a kind of headings? We might introduce a new list type

 ** TODO this is a list, serving just like inlinetask :tag1:tag2:
:PROPERTIES:
<...>
:END:
 *1. DONE numbered list

The idea is that one just needs two stars " **" to create such list -
very convenient and in line with the proper heading syntax.

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

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

Russell Adams  writes:

>> Is there any hurry to delete things? If we still keep a new syntax open
>> for discussion, I see no reason to remove anything.
>
> Certainly no hurry. Just expressing my opinion. You know the code much
> better than I, I'm just trying to defend maintainer time from extra
> work.

I am personally interested to maintain inlinetasks.

> Maybe start a new email thread for a RFC regarding a potential
> replacement inline task syntax that would be cleaner for the code,
> parser, and easier to maintain?

Yup. We are too far away from the subject now. I will start a new thread
in a reply to Bastien.

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

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

Russell Adams  writes:

> Do we have a concrete summary of individual features that inline tasks
> have?
>
> I'm hearing exempt from folding, and support for drawers/heading
> items.
>
> What else?

Well. Everything normal headings have, except things that cannot be done
the same way due to inlinetasks being surrounded by non-headline
elements.

In particular, export cannot be made the same - "inline" sections are
meaningless in most export backends, like latex or odt. Instead,
inlinetasks are exported as a kind of minipage/box.

Also, folding of inlinetasks is handled like folding of drawers/blocks -
separately from subtree cycling.

Similar story for M-/ - handled like drawers/blocks.

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

Re: [BUG] Failing tests for ob-clojure

[Daniel Kraus]

Ihor Radchenko  writes:

>> Unfortunately you're right and I would even say we can completely
>> remove `test-ob-clojure.el`.
>> There seems to be only tests for session support which currently
>> doesn't exist anymore and another one which tests plain tangle
>> and is not really Clojure specific.
>
> Done.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=fcca76274

Thanks!

Re: [BUG] ob-python hangs on second start [9.5.4 (release_9.5.4-763-g06373a @ ~/emacs/org-mode/lisp/)]

[Ihor Radchenko]

Peter Mao  writes:

> Expectation:  When running ob-python code blocks, I should be able to
> kill the python session in the *Python* buffer and run another code
> block (or the same one).
>
> Problem:  ob-python works fine on the first execution, but after
> `exit()`ing the python session, it hangs without executing the code.
> After a `C-g`, the prompt in the *Python* session shows up, but one then
> has to re-execute the code block, as none of it has run.

Confirmed.

It looks like `python-shell-first-prompt-hook' does not get triggered
in the described scenario with exit() and we enter infinite loop in the
code below.

(add-hook
 'python-shell-first-prompt-hook
 #'org-babel-python--setup-session
 nil 'local)))
;; Wait until Python initializes
;; This is more reliable compared to
;; `org-babel-comint-wait-for-output' as python may emit
;; multiple prompts during initialization.
(with-current-buffer py-buffer
  (while (not org-babel-python--initialized)
(org-babel-comint-wait-for-output py-buffer)))

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

Re: [BUG] org-cite-insert fails to open json format bibliographies that contain entries for books with editors but no authors [9.6.6 (release_9.6.6 @ /snap/emacs/current/usr/share/emacs/29.1/lisp/org/

[Ihor Radchenko]

Margaret Patterson  writes:

> Since upgrading to emacs 29.1 org-cite-insert no longer copes with 
> bibliography files in json format where there is an entry for a book 
> that has only editors and no author.

Thanks for reporting!
Does the attached patch fix the problem?

>From 9ca03cfb827b5691665b472f3c7086a1c033ce0a Mon Sep 17 00:00:00 2001
Message-ID: <9ca03cfb827b5691665b472f3c7086a1c033ce0a.1692952720.git.yanta...@posteo.net>
From: Ihor Radchenko 
Date: Fri, 25 Aug 2023 11:37:59 +0300
Subject: [PATCH] * lisp/oc-basic.el: Fix parsing "editor" field in json
 bibliographies

(org-cite-basic--parse-json): Parse "editor" field, not "editors".
"editors" is a typo - the common field name is "editor".  For example,
see https://www.bibtex.com/e/book-entry/.
---
 lisp/oc-basic.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/oc-basic.el b/lisp/oc-basic.el
index c4468e5a8..2b78d85d0 100644
--- a/lisp/oc-basic.el
+++ b/lisp/oc-basic.el
@@ -162,7 +162,7 @@ (defun org-cite-basic--parse-json ()
 (puthash (cdr (assq 'id item))
  (mapcar (pcase-lambda (`(,field . ,value))
(pcase field
- ((or 'author 'editors)
+ ((or 'author 'editor)
   ;; Author and editors are arrays of
   ;; objects, each of them designing a
   ;; person.  These objects may contain
-- 
2.41.0


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

Re: [BUG] When calling org-tree-to-indirect-buffer: (wrong-type-argument listp org-fold-outline) in org-fold-core-get-folding-spec-from-alias [9.6.6 (release_9.6.6 @ /gnu/store/c7vqk20kf6zw73klr8bacnh

[Ihor Radchenko]

Adam Porter  writes:

> Since upgrading to Emacs 29.1 and Org 9.6.6, I am getting an error when
> opening a bookmark to an Org subtree buffer created with burly.el.  When
> opening the bookmark, burly calls org-tree-to-indirect-buffer to make a
> new indirect buffer showing the subtree in question.  This worked fine
> in Emacs 28 and the previous Org version I was using, 9.5.something,
> IIRC.  Now I get this error (please see the attached backtrace, which is 
> abbreviated, and some functions were re-evaluated so as to be interpreted).

Thanks for reporting!

> Debugger entered--Lisp error: (wrong-type-argument listp org-fold-outline)
>   car(org-fold-outline)
>   alist-get(org-fold-outline ((:alias . org-link) (org-link . org-link) 
> (:alias . org-link-description) (org-link-description . org-link-description) 
> (property-drawer . org-fold-drawer) (drawer . org-fold-drawer) (:alias . 
> org-fold-drawer) (org-fold-drawer . org-fold-drawer) (verse-block . 
> org-fold-block) (src-block . org-fold-block) (special-block . org-fold-block) 
> (quote-block . org-fold-block) (export-block . org-fold-block) (example-block 
> . org-fold-block) (dynamic-block . org-fold-block) (comment-block . 
> org-fold-block) (center-block . org-fold-block) (block . org-fold-block) 
> (:alias . org-fold-block) (org-fold-block . org-fold-block) (plain-list . 
> org-fold-outline) (inlinetask . org-fold-outline) (outline . 
> org-fold-outline) (heading . org-fold-outline) (headline . org-fold-outline) 
> (:alias . org-fold-outline) (org-fold-outline . org-fold-outline)))
>   org-fold-core-get-folding-spec-from-alias(org-fold-outline)
>   org-fold-core--property-symbol-get-create(org-fold-outline)

This is a very strange backtrace.
When I run that `alist-get' call manually, there is no error. And
`alist-get' does not call `car'.

May you try to re-generate the backtrace again?

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

Re: Org mode version 9.7-pre (9.7-pre-n/a-g63e8ca @ /home/n/.emacs.d/elpaca/builds/org/); [PATCH] refactor org-babel-lilypond-compile-lilyfile

[Ihor Radchenko]

No Wayman  writes:

> The attached patch:
>
> - Improves the compilation message. (The target is the file, not 
>   LilyPond itself).
> - Refactors the body of the function to remove the many 
>   nondescript arg-n local variables.

Thanks! LGTM.

> - Removes the optional TEST parameter, which is unused and better 
>   served through debugging tools.  

This is technically a breaking change. So, we (1) need to mention it in
ORG-NEWS; (2) may consider (file-name  _) function definition
to be 100% sure that no existing code will be broken.

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

Re: Org mode version 9.7-pre (9.7-pre-n/a-g63e8ca @ /home/n/.emacs.d/elpaca/builds/org/); [PATCH]: fix ob-lilypond docstrings

[Ihor Radchenko]

No Wayman  writes:

> Fixed in attached patch.

Thanks!
Applied, onto main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=538ddecb3
  
>> What is ORG-BABEL-LILYPOND-ARRANGE-MODE?
> ...
> A minor mode would also obviate the need for 
> `org-babel-lilypond-toggle-arrange-mode'.
> Let's do that in a separate patch.

+1

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

Re: [BUG] "make check" reports a failure on test-org/insert-heading @ d5ee33f (this time with Emacs 29)

[Ihor Radchenko]

Jens Schmidt  writes:

>> There is no universal rule when and when not to add trailing spaces in
>> the tests.
>
> Not sure what you mean by that, but some tests rely on trailing spaces
> and fail when these are not present.  An explicit test on that would
> make the issue more visible.  See below for what I mean.  The only (?)
> downside is that this catches such errors in test-org.el only, and not
> in all the other tests, many of which also contain (on purpose or
> inadvertently) trailing whitespace:

That's what I mean. For some tests, we do want trailing whitespace. For
some - not. Imagine that we decide to change the test failing due to
whitespace cleanup, but leave your proposed test. Then, your test may be
failing, and it will be rather difficult to figure out why.

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

Re: [BUG] Failing tests for ob-clojure

[Ihor Radchenko]

Daniel Kraus  writes:

> Unfortunately you're right and I would even say we can completely
> remove `test-ob-clojure.el`.
> There seems to be only tests for session support which currently
> doesn't exist anymore and another one which tests plain tangle
> and is not really Clojure specific.

Done.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=fcca76274

> I would love to write new tests but as I just started a new job
> and got a new baby at the same time, I don't think I'll find the
> time for it the next 3-4 month :(

Understood. We are not in rush.

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