From: Ihor Radchenko <yantar92@posteo.net>
To: John C <john.ciolfi.32@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: ob-octave: improve MATLAB support
Date: Sat, 04 Jan 2025 13:02:03 +0000 [thread overview]
Message-ID: <87ldvqg2b8.fsf@localhost> (raw)
In-Reply-To: <CACb3vdSc2ypq5hdd3Kgb3K+wek-0LDwUqUPugzUr2tt5yyg23Q@mail.gmail.com>
John C <john.ciolfi.32@gmail.com> writes:
> Thanks for the feedback. See updated org-matlab.patch. Note code evaluation
> will now error out when using an out-of-date matlab-mode (rather than
> generating a warning) because when using an older matlab-mode, code block
> evaluation doesn't work. We need to wait for the matlab-shell to be ready.
> Without that capability found in newer matlab-mode, the errors are very
> hard to understand.
Maybe you can use `org-require-package'.
Note that we generally guarantee support for the latest stable
third-party library release. Not older. So, failing to work with old
matlab-mode is not a problem.
See https://orgmode.org/worg/org-maintenance.html#emacs-compatibility
> You mentioned that we should expect org users to understand sessions,
> however the doc on sessions is a bit light. Searching
> https://orgmode.org/org.html for "session", we see it used two different
> ways "Emacs session" and babel code block evaluations sessions described in
> "Using sessions". What is there is okay, but doesn't really help one
> understand when they should/shouldn't use babel code block evaluation
> sessions. What would be nice is if "Using sessions" were titled "Babel code
> block evaluation sessions" containing the existing content minus the "Only
> languages that provide interactive evaluation ..." paragraph because this
> is vague.
Feel free to submit a patch improving the manual.
> ... In addition, each language should have a way of describing what
> :session means to them, perhaps by extracting this info from ob-LANGUAGE.el
> or maybe ob-LANGUAGE.org, or maybe something else that inserts the language
> specific into the org manual.
See https://list.orgmode.org/877c83h09b.fsf@localhost/T/#t
[TASK] Move babel backend docs from WORG to Org manual
> * lisp/ob-comint.el: enhanced org-babel-comint-with-output
> - The META argument of org-babel-comint-with-output now supports an
> optional
> STRIP-REGEXPS which can be used to remove content from the returned
> output.
Please document this change in "New functions and changes in function
arguments" section of ORG-NEWS.
> * testing/org-test.el
> - Added org-test-get-code-block which is for use by testing/lisp/test*.el
> files
> to extract code blocks from testing/examples/*.org files for on-the-fly
> testing using org-test-with-temp-text.
I am not sure if it is really needed.
Why not directly using `org-test-with-temp-text' and putting the src
block there? Having the tested src block away from the test itself makes
it hard to read tests.
> -(defvar org-babel-default-header-args:matlab '())
> +(defvar org-babel-default-header-args:matlab '((:session . "*MATLAB*"))
> + "Reuse the matlab-shell buffer for code block evaluations.
> +Add the MATLAB clear command to your code block to clear the
> +MATLAB workspace.")
This docstring is not appropriate.
A docstring should describe what variable does in the first line.
Optionally, it can also describe the default value; but not as the first line.
For example, this is what I have on one of WIP branches:
(defvar org-babel-default-header-args:matlab '()
"Default header arguments for Matlab code blocks.")
(defvar org-babel-default-header-args:octave '()
"Default header arguments for Octave code blocks.")
See "D.6 Tips for Documentation Strings" in Elisp manual.
> +(defun org-babel-matlab-shell ()
> + "Start and/or wait for MATLAB shell."
> + (require 'matlab-shell) ;; make `matlab-shell-busy-checker' available
Maybe use `org-require-package' here.
> + (const :tag "MATLAB" matlab)
> (const :tag "Maxima" maxima)
> (const :tag "OCaml" ocaml)
> - (const :tag "Octave and MatLab" octave)
> + (const :tag "Octave" octave)
This makes me wonder if ob-matlab and ob-octave diverged enough to put
matlab-specific code into ob-matlab itself.
--
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
prev parent reply other threads:[~2025-01-04 13:01 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-08 19:30 ob-octave: improve MATLAB support John C
2024-11-09 9:32 ` Ihor Radchenko
2024-11-13 19:10 ` John C
2024-11-15 13:29 ` John C
2024-11-23 15:57 ` Ihor Radchenko
[not found] ` <87o712lv3t.fsf@localhost>
2024-12-29 3:04 ` John C
2024-12-29 7:42 ` Ihor Radchenko
2025-01-02 23:55 ` John C
2025-01-02 23:56 ` John C
2025-01-04 13:02 ` Ihor Radchenko [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ldvqg2b8.fsf@localhost \
--to=yantar92@posteo.net \
--cc=emacs-orgmode@gnu.org \
--cc=john.ciolfi.32@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).