Re: [BUG] Consider replacing bachload with batch in ob-maxima. [9.6.6 (release_9.6.6 @ /usr/share/emacs/30.0.50/lisp/org/)]

[Vladimir Nikishkin]

Leo Butler  writes:

> On Sat, Sep 02 2023, Ihor Radchenko  wrote:
>
>> Lockywolf  writes:
>>
>>> At the moment, ob-maxima has a straightforward way of evaluating
>>> babel blocks,
>>>
>>> #+begin_src shell
>>> maxima --very-quiet -r batchload\(\"/tmp/ob-maximaFOOBAR.mac\"\)\$
>>> #+end_src
>>> (line 87 of ob-maxima.el),
>>>
>>> I suggest replacing batchload with batch(), and changing line 73 from
>>> "gnuplot_close ()$" to  "gnuplot_close ()$ \nquit();"
>>>
>>> The difference between "batch" and "batchload" is that "batch" can
>>> process :lisp expressions in addition to maxima's own, and it prints
>>> input/output labels. However, it is possible to customise label printing
>>> from maxima's own code, and being able to evaluate :lisp just seems
>>> uncontrovercially good.
>>>
>>> It might be that I am missing something, but batch seems a better fit
>>> for Org-Babel.
>>
>> May you please explain more about :lisp expressions?
>
> This special syntax is not necessary. A recent change introduced the
> function `eval_string_lisp' that removes the need for it. I.e. one can
> batchload a file and execute lisp code inside a call to eval_string_lisp.
>

Well, necessary or not, but it existed for many years, and continues to
be a valid part of maxima so far. It is surprising for new users to not
see it working when quite a lot of howtos use it. (Especially the famous
pattern-matching howto from Michael Talon.)

Also, I would be hesitant to say that it "removes the need for it",
because a "valid expression" is not the same thing as a "string". In
particular, error processing should be different.

>>
>> Also, what is the benefit/downside of printing input/output labels? Is
>> there any chance they will be caught into the source block output? If
>> so, it would be a breaking change.
>
> Yes, his requests are breaking changes. That is why I suggested opening
> up the internals a bit so that one can alter the behavior while
> maintaining the same default.
>
> Leo

Well, this change is "breaking", in the sense that it would make the
output of ob-maxima be more consistent with what, say, imaxima is doing.
However, I thing that there is a way to make it non-breaking, by
prepending some maxima code which would make adjust maxima using "batch"
to have the same output as "batchload". Something like
src_maxima{programmode: true; nolabels: true;} should turn off labels
if that is desired.

But I would agree with Leo Butler that customisation is the best
solution here. Both "full batch", and "pseudo-interactive" modes are
useful.

-- 
Your sincerely,
Vladimir Nikishkin (MiEr, lockywolf)
(Laptop)

Re: [ANM] org-timeblock: Schedule your day visually, using timeblocking technique inside Emacs

[Dr. Arne Babenhauserheide]

Ilya Chernyshov  writes:

> Recently, I implemented multi-day views feature for org-timeblock. You
> can now choose the number of days (1-7) displayed via command
> org-timeblock-switch-view. Here's a screenshot:
>
> https://raw.githubusercontent.com/ichernyshovvv/org-timeblock/master/screenshots/multi-day-view.png
>
> Quick video demo of multi-day views: 
> https://www.youtube.com/watch?v=aOkRw03Wg3o
>
> Link: https://github.com/ichernyshovvv/org-timeblock

I started using this, and it’s great! Thank you!

I also found an edge case: I have a deadline set to 23:59, and that
deadline is only visible in the timeblocks when I only have that task in
and switch to hiding all hours before the task (then 23:00 to 0:00 is
large enough that the task shows at the end).

Is there a way to switch the day view to include additional space at the
bottom so tasks at the end of the day are visible?

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de


signature.asc
Description: PGP signature

Re: Fallback fonts in LaTeX export for non latin scripts

[Juan Manuel Macías]

Finally I can upload some usable code here, in this case to be able to
load and manage fonts for languages with non-Latin scripts, through
babel and fontspec (in LuaLaTeX). It is an attempt to simplify from Org
the multiform syntax of babel + fontspec. Of course, it is more limited,
but for regular use I think it may be enough.

Since this code is mostly a proof of concept and the names of many
things (and the things themselves) are still tentative, I thought it
would be more useful to attach it in an *.el file, rather than a regular
patch. Loading that file everything should work fine. I also attach an
org document with some examples of use. In any case, there are more
explanations inside the .el file.

One of the big problems I have encountered when trying to create a
"(LaTeX) Babel interface in Org" is the *horrible* multiplicity that
Babel has for language names. That is the reason for the :babel-alt
property in 'org-latex-language-alist', which collects the names that
babel supports for \babelprovide, which are not always the same as the
'classic' babel syntax.

Finally, I find this way more useful (that is, loading fonts with
language support), instead of a fallback font system based only on the
Unicode scripts. It is less 'automatic', but more precise, and it also
does not require much 'specialized' intervention on the part of the
user.

Best regards,

-- 
Juan Manuel Macías

https://juanmanuelmacias.com

https://lunotipia.juanmanuelmacias.com

https://gnutas.juanmanuelmacias.com



test-lang.org
Description: Lotus Organizer
;; -*- lexical-binding: t; -*-

;; A proof of concept for Unicode font support in LaTeX export, using
;; babel and fontspec, with luatex as the default compiler.

;; Use example:

;; It is not necessary to load languages with non-Latin alphabet in babel 
options:
;; #+LaTeX_Header: \usepackage[AUTO]{babel}

;; Languages and fonts (there may be multiple lines):

;; #+LaTeX_Header: % !enable-fonts-for ancientgreek:Linux Libertine 
O(Scale=MatchLowercase)
;; #+LaTeX_Header: % !enable-fonts-for 
russian:FreeSerif(Numbers=Lowercase,Color=blue) :: arabic

;; Explanation:

;; - lang = enable default font for lang
;; - lang:font = enable font for lang in current document
;; - lanf:font(options) = enable font for lang in this document with options
;; - :: = separator


;; code

;;  This is supposed to be a defcustom.

(setq org-latex-uc-fonts-support t)

;; A mini version of `org-latex-language-alist', for this proof of
;; concept. Babel uses various names for languages. The ones that
;; interest us here are those collected in `:babel-alt', which is
;; always a list. The names sometimes match the `classic' babel name
;; and other times they don't. And in the case of "el-polyton" there
;; are two possible names. For a list of these names see:
;; [[https://CTAN/macros/latex/required/babel/base/babel.pdf]],
;; p. 22.

(defconst org-latex-language-alist
  '(("en"  :babel "american" :babel-alt ("english-unitedstates") :polyglossia 
"english" :polyglossia-variant "usmax" :lang-name "English" :script "latin" 
:code "latn")
("ar" :babel "arabic" :babel-alt ("arabic") :polyglossia "arabic" 
:lang-name "Arabic" :script "arabic" :code "arab")
("el"  :babel "greek" :babel-alt ("greek") :polyglossia "greek" :lang-name 
"Greek" :script "greek" :code "grk")
("el-polyton" :babel "polutonikogreek" :babel-alt ("ancientgreek" 
"polytonicgreek") :polyglossia "greek" :polyglossia-variant "polytonic" 
:lang-name "Polytonic Greek" :script "greek" :code "grk")
("ru"  :babel "russian" :babel-alt ("russian") :polyglossia "russian" 
:lang-name "Russian" :script "cyrillic" :code "cyrl"))
  "TODO")

;; This is supposed to be a defcustom for the main fonts. `'default'
;; means 'use the main default fonts'. Otherwise, the value must be
;; a plist. Valid props. are:

;; - :main = roman font
;; - :sans = sans font
;; - :mono = mono font
;; - :math = math font
;; - :...-options = font options

;; For the font options and the fontspec package syntax, see
;; [[https://CTAN/macros/unicodetex/latex/fontspec/fontspec.pdf]]

(setq org-latex-uc-fonts-support-default-main-fonts
  '(:main "FreeSerif" :mono "inconsolatan" :mono-options "Scale=0.95"))

;; This is supposed to be a defcustom. Each element has the structure:
;; script - font - (optional) font options

(setq org-latex-uc-fonts-support-default-scripts-fonts
  '(("greek" "Linux Libertine")
("cyrillic" "Old Standard")
("arabic" "FreeSerif")))

;; Get main fonts (declared in
;; `org-latex-uc-fonts-support-default-main-fonts')

(defun org-latex-uc-fonts-support-get-main-fonts (plist prop)
  (let ((format))
(if (not
 (plist-member plist prop))
(ignore)
  (let* ((value (plist-get plist prop))
 (prop-name
  (replace-regexp-in-string ":" "" (symbol-name prop)))
 (options (plist-get
   plist
   (intern
(format
   

Re: [BUG] Consider replacing bachload with batch in ob-maxima. [9.6.6 (release_9.6.6 @ /usr/share/emacs/30.0.50/lisp/org/)]

[Leo Butler]

On Sat, Sep 02 2023, Ihor Radchenko  wrote:

> Lockywolf  writes:
>
>> At the moment, ob-maxima has a straightforward way of evaluating
>> babel blocks,
>>
>> #+begin_src shell
>> maxima --very-quiet -r batchload\(\"/tmp/ob-maximaFOOBAR.mac\"\)\$
>> #+end_src
>> (line 87 of ob-maxima.el),
>>
>> I suggest replacing batchload with batch(), and changing line 73 from
>> "gnuplot_close ()$" to   "gnuplot_close ()$ \nquit();"
>>
>> The difference between "batch" and "batchload" is that "batch" can
>> process :lisp expressions in addition to maxima's own, and it prints
>> input/output labels. However, it is possible to customise label printing
>> from maxima's own code, and being able to evaluate :lisp just seems
>> uncontrovercially good.
>>
>> It might be that I am missing something, but batch seems a better fit
>> for Org-Babel.
>
> May you please explain more about :lisp expressions?

This special syntax is not necessary. A recent change introduced the
function `eval_string_lisp' that removes the need for it. I.e. one can
batchload a file and execute lisp code inside a call to eval_string_lisp.

>
> Also, what is the benefit/downside of printing input/output labels? Is
> there any chance they will be caught into the source block output? If
> so, it would be a breaking change.

Yes, his requests are breaking changes. That is why I suggested opening
up the internals a bit so that one can alter the behavior while
maintaining the same default.

Leo

Re: [BUG] Consider replacing bachload with batch in ob-maxima. [9.6.6 (release_9.6.6 @ /usr/share/emacs/30.0.50/lisp/org/)]

[Leo Butler]

On Sat, Sep 02 2023, Ihor Radchenko  wrote:

> Leo Butler  writes:
>
>> I think that your request may be handled by one of two improvements:
>>
>> 1. Implement session support in ob-maxima.el; and
>> 2. Many of the design decisions in the existing ob-maxima code should be
>> customizable.
>
>> I am attaching a patch to address 2. Please try it out, I think that it
>> will satisfy your requests. Feedback is welcome.
>
> Thanks for the patch!
>
>> +(defcustom org-babel-maxima-command-arguments
>> +  "--very-quiet"
>
>> +(defcustom org-babel-maxima-batch/load
>> +  "batchload"
>> +
>> +(defcustom org-babel-maxima-graphic-file-format-string
>> +  "(set_plot_option ('[gnuplot_term, png]), set_plot_option 
>> ('[gnuplot_out_file, %S]))$"
>> +
>> +(defcustom org-babel-maxima-default-epilogue
>> +  "gnuplot_close ()$"
>
> This might be fine, but may you please explain what would be the purpose
> of customizing each of these options?

I am not sure of your request: do you want me to elaborate in the
docstrings? Or here?

>
> IMHO, in their current state, if a user mindlessly customizes these
> options without knowing how ob-maxima internals work, ob-maxima may
> simply be broken.

I think there is a fine line between being too rigid but working within
a limited scope (as ob-maxima is now), or providing enough customizable
options to let users do what they want. I would prefer the latter,
if the defaults provide a working configuration.

Note that I do attempt to suggest other working options in the defcustom
definitions.

> It is also not very clear what would be the benefit
> customizing any of the proposed options.

I had planned to update the worg documentation with some examples, but
here is one that answers the OP's original question:

>> +(defcustom org-babel-maxima-command-arguments
>> +  "--very-quiet"

This is the current setting.

It can be useful to include the build information that Maxima provides
on start-up, which would mean setting this to "".

>
>> +(defcustom org-babel-maxima-batch/load
>> +  "batchload"

This is the current setting.

Another option suggested is "batch". That is what the OP originally
requested.

>> +
>> +(defcustom org-babel-maxima-graphic-file-format-string
>> +  "(set_plot_option ('[gnuplot_term, png]), set_plot_option 
>> ('[gnuplot_out_file, %S]))$"

This is the current setting.

An alternative is to use the `draw' package, which is a suggested
option. Draw, in my opinion, is a much better package for plotting.

>> +
>> +(defcustom org-babel-maxima-default-epilogue
>> +  "gnuplot_close ()$"

This is the current setting.

The current setting is not needed in recent versions of Maxima (since
roughly 2010, I believe), except possibly on Windows. And, it is only
needed if `:results graphics file' is included as a src header.

On the other hand, the OP had requested adding

"quit() $"

to this setting. I don't think that is needed, but Maxima is built with
more than 6 different common-lisp implementations so there can be lots
of variability in how common tasks are performed...

>
> As a general rule, we do not expose internal details that are _required_
> for things to work to users.

I understand this principle, but, why not provide enough options for
users to configure a package to do what they want? Yes, that may mean
they break the package--but only temporarily, because returning to the
default options will return the package to a working state.

> In the above, `org-babel-maxima-default-epilogue' appears to be paired
> with `org-babel-maxima-graphic-file-format-string' and may need to be
> changed depending on its value.

No, they are not closely connected. Both plot and draw use gnuplot as
the graphing backend (although draw might be able to use vtk, that
capability has not been maintained...).

> Also, I am not sure if removing --very-quiet may
> not affect :results output.

Yes, it will. But that is what the OP is asking for.



I think that the original intention of ob-maxima was to provide a simple
`calculator'-like interface to Maxima. In many cases, though, one wants
to show a sequence of calculations that lead to the final answer. That
is why being able to configure some of these hard-coded settings is
desirable: to be able to modify how the input and output are presented.

Best regards,
Leo

Re: [RFC] Quoting property names in tag/property matches

[Jens Schmidt]

On 2023-09-02  09:10, Ihor Radchenko wrote:
> Jens Schmidt  writes:

>> - Even if we made "&" mandatory, it would not really solve the quoting
>>   problem, since the parser is rather hacky and other quoting and
>>   context issues would still be there.
> 
> But at this point you are more familiar with that parser than I am, so
> my idea does not seem to be viable.

I think so, yes.

That would mean that my pending patch could be merged, right?  (Sorry for
being impertinent here, but I'd like to get that thing off my stack.)

Re: Redoing the current tag/property parser in a real grammar [was: Re: [RFC] Quoting property names in tag/property matches]

[Jens Schmidt]

On 2023-09-02  09:10, Ihor Radchenko wrote:
> Jens Schmidt  writes:

>> This all calls for a proper parser, based on peg or bovine or whatever.
>> Hopefully that parser would still keep backward compatibility, but
>> that's probably wishful thinking.
> 
> Backward compatibility will be easy - just leave the current code when
> old query version is detected. We should better focus on the new syntax
> in future and leave the current syntax as compatibility layer that will
> be eventually deprecated.

Agreed except for the deprecation part.  I think Org should be big enough
to have two parsers: One along the lines of the current one (infix, DWIM,
easy to type) and one along the lines of org-ql (sexp, better extensible,
more flexible, harder to type).  Ideally, it should be even possible to
embed the infix-one into the sexp-one.

It should also be possible to put the current infix parser onto a more
stable ground as well, based on a formal grammar, providing at least
parentheses for grouping and negation, and that without breaking backward
compatibility.

Let's rephrase that way: If I were to redo the current parser as
mentioned in the previous paragraph, would these changes "eventually be
deprecated"?  (Which doesn't necessarily mean that I promise to do so,
of course.)

[DISCUSSION] Re-design of inlinetasks

[Maske]

Hi

I am sorry, I don't know the appropriate terminology.


Could be used

*** END

or a different special string, to end any headline scope? Like an "end 
parenthesis" for the headline just above it.


Maybe in this way, all headlines would be the same: if the special 
string appears, the headline scope ends there (inlinetask). If no 
special string, the scope would end before the next headline (or at the 
end of the document).

[BUG] URI handling is overly complicated and nonstandard [9.6.7 (N/A @ /gnu/store/mg7223g8mw90lccp6mm5g6f3mpjk70si-emacs-org-9.6.7/share/emacs/site-lisp/org-9.6.7/)]

[Max Nikulin]

On 01/09/2023 16:04, Ihor Radchenko wrote:

Max Nikulin writes:


However I do not mind to have an easy way to delegate URI from :export
function to the link transcoder of active export backend.



Just make the :export function return nil.


I missed this feature, but anyway it does not work as expected.

  (org-link-set-parameters "tel")

or

  (org-link-set-parameters
   "tel"
   :export (lambda (_path _descr _backend) nil))

strips link type and exports links as e.g.

  \href{321}{call}

"tel:" is missed. Each backend has its own hardcoded list of blessed 
link types to preserve link type/protocol/scheme:

- LaTeX: "http" "https" "ftp" "mailto" "doi"
- HTML:  "http" "https" "ftp" "mailto" "news"

Actually I had in mind more flexible delegation. :export functions 
should be able to alter URI, attributes and to provide description if it 
is missed, but did not care if '' or '\href{}{}' should 
be used.


Easy way to add protocol/scheme should include :follow with `browse-url' 
as well.

Re: [FR] Enhancing footnote managment (via indirect buffer)?

[Ihor Radchenko]

Ihor Radchenko  writes:

> Andrea Lazzarini  writes:
>
>> I was busy with work and had less time to focus on this, sorry!
>
> No problem. Just wanted to make sure that this thread did not fall
> through the cracks.

It has been two months since the last message here.
If you encounter any difficulties, feel free to ask me anything.

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

Re: [DISCUSSION] May we recognize everything like [[protocol:uri]] as a non-fuzzy link? (was: [BUG] URI handling is overly complicated and nonstandard [9.6.7 (N/A @ /gnu/store/mg7223g8mw90lccp6mm5g6f3

[Dr. Arne Babenhauserheide]

Ihor Radchenko  writes:

> Then, ox.el and other link processing code, when encountering a link
> type that is not registered, will fall back to searching "fuzzy" link.
>
> So, export, and following the link should not be affected.

This resolves my worry — thank you!

> There might be caveats related to parser though.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de


signature.asc
Description: PGP signature

Re: [DISCUSSION] May we recognize everything like [[protocol:uri]] as a non-fuzzy link? (was: [BUG] URI handling is overly complicated and nonstandard [9.6.7 (N/A @ /gnu/store/mg7223g8mw90lccp6mm5g6f3

[Ihor Radchenko]

Tom Gillespie  writes:

> My suggestion is as follows. Schemes/prefixes defined by the
> #+link: keyword can be used without surrounding syntax markers
> but may not contain spaces etc.

> ... To support this Org parsers
> should always parse prefix:suffix as a _putative_ link which
> must then be checked against a list of known schemes that
> are either built in or have been declared by the user to indeed
> be legitimate schemes.
>
> In the tel: case, the way to solve the original bug is simply
> to add the line #+link: tel tel: which would tell Org that e.g.
> tel:555-555- is a real uri, and that it should expand to
> itself.

Currently, link abbreviations are explicitly allowed in bracket links
and only bracket links.

The currently available  way to force tel: link type is using angle
links:



No special #+link keyword is needed in the above example.

> At the same time this solution would avoid Arne's issue
> (which I also have in some of my documents where I have
> use fig: and tbl: as prefixes in names and reference them
> via [[fig:figure-name]]) because the parser would only treat
> prefix: in an internal link as a scheme if it is defined explicitly
> by the user in a #+link: keyword or in their init.el.

The most annoying part is that we have three not fully consistent link
markups:

http://plain-link.com

[[http://bracket-link.com]]

The plain link only works for `org-link-types' - registered link types.

The angle link works all the time, unconditionally parsing 
with "foo" being link type and "bar" being link path. Abbreviations are ignored.

The bracket link works only for `org-link-types' __and__ link
abbreviations. If whatever inside brackets is not matching know link
type or abbreviation, it is considered a fuzzy link.


As you see, the situation might easily get confusing in corner cases.

My proposal aims to extend the bracket link a bit - the most commonly
used link type. However, it creates a problem with fuzzy links.
Even more problematic is plain link type where any kind of open syntax
will likely clash with normal text flow with innocent text like A:B
being suddenly considered a link.

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

Re: [DISCUSSION] May we recognize everything like [[protocol:uri]] as a non-fuzzy link?

[Ihor Radchenko]

Jens Lechtenboerger  writes:

> On 2023-09-01, Ihor Radchenko wrote:
>
>> In theory, we might change the parser to treat anything like foo:bar or
>>  or [[foo:bar]] as a link with "foo" protocol and "bar" URI.
>> And introduce [[::fig:something]] to allow explicit internal links.
>> But, despite simplifying the parser, it will certainly be a breaking
>> change.
>
> What would the implications be?  FAQ 18.25 [1] contains a recipe to
> use colors on text like this: [[color:red][red]]
>
> Would that be a problem?
>
> Also, I use custom link types for additional markup like this:
>
> [[basic:https://en.wikipedia.org/wiki/Cache_(computing)][Caching]]
>
> In both cases, the part before the first colon is certainly no
> protocol.

Sorry for the confusion. I mean link type in Org parser terms, not
protocol.

Your examples will not be affected. What will be affected is fuzzy
internal links.

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

Re: [DISCUSSION] May we recognize everything like [[protocol:uri]] as a non-fuzzy link? (was: [BUG] URI handling is overly complicated and nonstandard [9.6.7 (N/A @ /gnu/store/mg7223g8mw90lccp6mm5g6f3

[Ihor Radchenko]

"Dr. Arne Babenhauserheide"  writes:

>> May you elaborate about what is going to be broken?
>
> I have many links where I use <> along with
> [[sec:spielbeispiel]], often along with
> @@latex:\phantomsection\label{sec:spielbeispiel}@@ to enable reliable
> inline linking inside org-mode and across different export formats.
>
> If I understood the proposal right, all of these would break. Or did I
> misundestand that?

What I had in mind is that only parser will be changed.
Now, [[sec:spielbeispiel]] is

(link :type "fuzzy" :path "sec:spielbeispiel" ...)

With my proposal, it would become

(link :type "sec" :path "spielbeispiel" ...)

However, "sec" link type will still not be listed in the output
`org-link-types' (not registered).

Then, ox.el and other link processing code, when encountering a link
type that is not registered, will fall back to searching "fuzzy" link.

So, export, and following the link should not be affected.

There might be caveats related to parser though.

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

Re: [BUG] Consider replacing bachload with batch in ob-maxima. [9.6.6 (release_9.6.6 @ /usr/share/emacs/30.0.50/lisp/org/)]

[Ihor Radchenko]

Leo Butler  writes:

> I think that your request may be handled by one of two improvements:
>
> 1. Implement session support in ob-maxima.el; and
> 2. Many of the design decisions in the existing ob-maxima code should be
> customizable.

> I am attaching a patch to address 2. Please try it out, I think that it
> will satisfy your requests. Feedback is welcome.

Thanks for the patch!

> +(defcustom org-babel-maxima-command-arguments
> +  "--very-quiet"

> +(defcustom org-babel-maxima-batch/load
> +  "batchload"
> +
> +(defcustom org-babel-maxima-graphic-file-format-string
> +  "(set_plot_option ('[gnuplot_term, png]), set_plot_option 
> ('[gnuplot_out_file, %S]))$"
> +
> +(defcustom org-babel-maxima-default-epilogue
> +  "gnuplot_close ()$"

This might be fine, but may you please explain what would be the purpose
of customizing each of these options?

IMHO, in their current state, if a user mindlessly customizes these
options without knowing how ob-maxima internals work, ob-maxima may
simply be broken. It is also not very clear what would be the benefit
customizing any of the proposed options.

As a general rule, we do not expose internal details that are _required_
for things to work to users. In the above,
`org-babel-maxima-default-epilogue' appears to be paired with
`org-babel-maxima-graphic-file-format-string' and may need to be changed
depending on its value. Also, I am not sure if removing --very-quiet may
not affect :results output.

-- 
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]

[Ihor Radchenko]

Jens Schmidt  writes:

> TL;DR:
>
> - I think we cannot make "&" mandatory because of backward compatibility.

Sorry for the confusion. I did not mean that "&" should be mandatory,
just that "&" might make it easier to avoid a need to escape things. So,
it could be used _instead_ of escaping.

> - Even if we made "&" mandatory, it would not really solve the quoting
>   problem, since the parser is rather hacky and other quoting and
>   context issues would still be there.

But at this point you are more familiar with that parser than I am, so
my idea does not seem to be viable.

> This all calls for a proper parser, based on peg or bovine or whatever.
> Hopefully that parser would still keep backward compatibility, but
> that's probably wishful thinking.

Backward compatibility will be easy - just leave the current code when
old query version is detected. We should better focus on the new syntax
in future and leave the current syntax as compatibility layer that will
be eventually deprecated.

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

Re: [BUG] Consider replacing bachload with batch in ob-maxima. [9.6.6 (release_9.6.6 @ /usr/share/emacs/30.0.50/lisp/org/)]

[Ihor Radchenko]

Lockywolf  writes:

> At the moment, ob-maxima has a straightforward way of evaluating
> babel blocks,
>
> #+begin_src shell
> maxima --very-quiet -r batchload\(\"/tmp/ob-maximaFOOBAR.mac\"\)\$
> #+end_src
> (line 87 of ob-maxima.el),
>
> I suggest replacing batchload with batch(), and changing line 73 from
> "gnuplot_close ()$" to"gnuplot_close ()$ \nquit();"
>
> The difference between "batch" and "batchload" is that "batch" can
> process :lisp expressions in addition to maxima's own, and it prints
> input/output labels. However, it is possible to customise label printing
> from maxima's own code, and being able to evaluate :lisp just seems
> uncontrovercially good.
>
> It might be that I am missing something, but batch seems a better fit
> for Org-Babel.

May you please explain more about :lisp expressions?

Also, what is the benefit/downside of printing input/output labels? Is
there any chance they will be caught into the source block output? If
so, it would be a breaking change.

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