From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id 8DWfFzIxeWfxUwEAe85BDQ:P1 (envelope-from ) for ; Sat, 04 Jan 2025 13:01:38 +0000 Received: from aspmx1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id 8DWfFzIxeWfxUwEAe85BDQ (envelope-from ) for ; Sat, 04 Jan 2025 14:01:38 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=TozkheKl; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=posteo.net ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1735995697; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=6iSjWLe38m1sc9Ij8zOOnWttLqz+JmQHR+LsXDEcO9M=; b=doLGWv5FuEGo5ywm4u69kCfdnPF8As6YUUWVrbpvGmceDUJj5iRndEOpL3TQW2FtXaCXGa L8QzklhvKR/KZEnl+4HX+iuEIAhdxR7APvq1y3ktkTREbTiXwT9qOOlUTXGKmLOhqk4Msb WmnQugI6MBBcb8KL5Hb1g1Ji8yROGRFiHThR4vpWvue76NJ9aYc182U7fW9ORDgENIq5cu Ko8o24D0UixFM+nU2uqpJr4smCaHgJPMF/35v0mCygpx5Vtv2J7qtL4cclHJKFWqb1h7yW 6F/kPxF9/m/53iPVcE693+cTSq+mJFcUXRlfM/v7qGq+lfN0fRCk64AFYznbAg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=TozkheKl; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=posteo.net ARC-Seal: i=1; s=key1; d=yhetil.org; t=1735995697; a=rsa-sha256; cv=none; b=rYy0mzly/wyvYe4q13POCnfX573I0dJVFwxMC8xWs5f5+LAIn9X01PNeRB50GMlv6o0T6D LDv4d7Ptv3//dVm4vOsV90RzeSlVFEHPsMDp1WRAQGadmBuUwZ3NPtKkaACAzQbKF4PqPy sw/t6vnkFqw9bcqBo2L9HN+GbHcRM0wFZJRdTyCl/ijJuwBWPLW7fPVVfK42J09hJvM8I1 u4MKYD5j+W+QyjbSglhIJSYJq9Aimj3v8bkBbtDpmtVHGbJUgOjc/rCsmeZr0VgwR9Q1RV mMht21YvA7qCb/cWoY3WznyZUz7r5F7Ug+sicyJbThIrBVXsTM5gYUAZtKw8bg== Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 4C7E1B3A for ; Sat, 04 Jan 2025 14:01:37 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tU3l1-0001Xj-5L; Sat, 04 Jan 2025 07:59:59 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tU3kz-0001Xb-QN for emacs-orgmode@gnu.org; Sat, 04 Jan 2025 07:59:57 -0500 Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tU3kx-0003bb-1R for emacs-orgmode@gnu.org; Sat, 04 Jan 2025 07:59:57 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id F3C82240027 for ; Sat, 4 Jan 2025 13:59:52 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1735995592; bh=AUAH9sp4BVVp37ULIDBAajpOmf1/i146qRBKeSRX1mY=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=TozkheKlOY6zmwL5tajsXaDPbYq/eBWJQkjR9ANEZ6+5W5DzrXuQc4zCwtBsLCYdV wVPAK5VJXtVAC5/R/UuxZlBbWTqjeJtbN6M1TzrPYjo1enx2M9kFc/obyTvH4ujO0L E86/MvWLihum4PlmIuGg7UpPyRxfR3ezyIJ8iVnjd+o+XwBoMMvyta5aKjEfAj69XE 17YTSDUigNVG73KhDLnpp87udxgwzlGuIK6KaHob5pOdOaPAQcoxgvBAkzxaY/2F4V g8myfw+XFvMP7HhBlZZEEXL4Uk0tRKIIEELvGkLdjaUUPtQzbnWeEhgK6xbQV7geNe 3U/R1v/cFxSeA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4YQLBc2R11z6tm4; Sat, 4 Jan 2025 13:59:52 +0100 (CET) From: Ihor Radchenko To: John C Cc: emacs-orgmode@gnu.org Subject: Re: ob-octave: improve MATLAB support In-Reply-To: References: <87pln4g3b2.fsf@localhost> <87cyim9c4t.fsf@localhost> <87o712lv3t.fsf@localhost> <87msgfvssp.fsf@localhost> Date: Sat, 04 Jan 2025 13:02:03 +0000 Message-ID: <87ldvqg2b8.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Scanner: mx12.migadu.com X-Migadu-Spam-Score: -3.16 X-Spam-Score: -3.16 X-Migadu-Queue-Id: 4C7E1B3A X-TUID: ye3TTxY20IWH John C 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 . Support Org development at , or support my work at