From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id eAvwJ2pSgWfPBQEA62LTzQ:P1 (envelope-from ) for ; Fri, 10 Jan 2025 17:01:30 +0000 Received: from aspmx1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id eAvwJ2pSgWfPBQEA62LTzQ (envelope-from ) for ; Fri, 10 Jan 2025 18:01:30 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=berkeley.edu header.s=google header.b=fou+LwBI; 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=reject) header.from=berkeley.edu ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1736528490; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=KuzWmh0zJeupJp/TUkW/FWi7yBBtFS/d3DQP3hQn6bI=; b=Icx2UApyDyT7bwJtLzilKvfpSIGY+HFw+PKNjcPbF7GwybwTvOr/fKbluw4XfRiBEThAF4 a3GQAgId7ko6IecuTRsYARzweCL53lcYWUCmWe6k6uNm2yJFFvMOgwPi9RxuoS2bOyrEmh Rz8W/nzSbZ7I+tvajX5hKR3Bjq5xysc1uEK1axW59H+G4bmKp5WWbYUEEtOM63U2nQTYq0 IasmMbBWv4jkFPbMOtGBjXnklgCNiuNntycp7kYhzf1fSf8Gc6y7AtN58+ZbWmZa4SKshZ EhrQ6UUbwRZaVkrgdOyCuMR/uUOchPUDgVb1DAALvWZNn+9Z9ynYIp0QkeV0pw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=berkeley.edu header.s=google header.b=fou+LwBI; 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=reject) header.from=berkeley.edu ARC-Seal: i=1; s=key1; d=yhetil.org; t=1736528490; a=rsa-sha256; cv=none; b=ssDaDWLN1GqCAQsRK4wXqLI7HM9/f2XLIWhYoEftt+uY267qwGim4gOFDP8HzCuuNQfi37 hbfTvUUaaOMyOf7qDYK4kzH44WyoOniA1D5RTZlSDwWeirW+fZX5iUytwk+rKaygpCl+m4 LhBNMklihxUIe09w1fhWsFpWOzm5MxFiIMxiiqv+fWWrs6mvmUGAmfnViAioEqDI23so7M tAeZBfLSdI2D4ezjBxvmB/AfQsJ4GBVLH2cgcQZZSNjf5PRkx0zSYRK42jXg8b8SCt/cJz /4J7dyT3YCzXc+SDBt0rhgklRWnpkVOspkJgKXs51j7NvS69Xls0OvSYgqoFiQ== 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 880458B64B for ; Fri, 10 Jan 2025 18:01:29 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tWINK-00011E-Kk; Fri, 10 Jan 2025 12:00:46 -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 1tWIMq-0000yc-Vp for emacs-orgmode@gnu.org; Fri, 10 Jan 2025 12:00:18 -0500 Received: from mail-pl1-x641.google.com ([2607:f8b0:4864:20::641]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tWIMo-0003XD-HH for emacs-orgmode@gnu.org; Fri, 10 Jan 2025 12:00:16 -0500 Received: by mail-pl1-x641.google.com with SMTP id d9443c01a7336-218c8aca5f1so47138205ad.0 for ; Fri, 10 Jan 2025 09:00:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=berkeley.edu; s=google; t=1736528409; x=1737133209; darn=gnu.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=KuzWmh0zJeupJp/TUkW/FWi7yBBtFS/d3DQP3hQn6bI=; b=fou+LwBIeR44swBK91oZ9ZinvJaEsfsBEd5EyA817LFd6UcRoI+Sx7fFtCybz9aChq C92bRaZKwgvYJBc+nVzJNOXvhFftXHvo4Lu2UQv6ovz57M3lZiltb+TMrqr44K8jnKHU aBr3Ml8/bbIlLzxRT5RmztFEQG9JVUNsq+X+jhs7GD67sVvumYXvdF+KrXY/ODqX7hC2 /GZ/2WVBzVG80w4crOb5TlpzHSe4INRHxXD7dkLHWsRkXNAk7WBMgl1j+ctPqZRzdbjK ZZeJKAqnIbPhbZd+IjzfWU1V4bC7Eacox0pgpoy78MRWH52xh6s78vs+uJ/6cCLbYZeH 3YPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736528409; x=1737133209; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=KuzWmh0zJeupJp/TUkW/FWi7yBBtFS/d3DQP3hQn6bI=; b=eOpbH/fZAzBg2rSbCP800gBfoPJ+NDLKES3qmbeybMvOol5P42gndiCR2iojJRxYFy uOPsnGQwq6TIeNPa31eAkRzPb8wh4Wh9e6CEMwRP8gZ6xhLAFPw8wWXSJJNYPHB7Uirm z5mUarPHV6fMYSJfGVO5vFP78X/bhK4AujrXIs/Uf3BmkxOsNeLxlZJeZXZW6tsn9Eui gH4fEPNZgZF8bTy6NtX3OVBPBBXiEqqHxjMTnT1bAzlgzsldFjz4GFVBAIwV0qGH31Ly mCSjxvHQ1bThb+FtdIPLn+71jRdvMrp3ZzfL7LYqp1/7EcV4tTFrgw/jXNQ+6poY6S3f 6mSw== X-Gm-Message-State: AOJu0YzUF5lmdFM90JAP4+5fEkmnNbMUj5/2x+TnXVmq9KrKM47D3BVM m9DchcvYktC2CZqp4C0zeSLV0vqj42t+pocpNCLQR4U9Yk4v1H7+wMNiNtfo8KCHctU9bjysNNX M/y4q X-Gm-Gg: ASbGnctf7GWifh4lVLhY+CJzpyakoOcVPVPsS2ycopP4+9ADwaB2+xfDnNGUOfIS2b0 VSJ9Dyjcf8Y698uj+9BISykOuRzE6nfpFtZzvQcY4m0RVUue42YH4ejP63QV7SzTYevoUTldfH6 YtJNOv3ghzhqXNlgVnChZWYh/5pTgtgc3AkQuzUHYd+el456CX9xdJLyDI8lFHbmdiAI2Yui62+ vltJ02EPjKDKyv523a8mA0tEz7DjgwUJXMYeR67//73FEPd/fpdUiCl9px94oe8w8N9XdYO4adO fv0thCeZINOqNGS40DBxvVyWT4adH1yQCDL6utSSBSLixnc= X-Google-Smtp-Source: AGHT+IE9KWf1CwoGbDDm6CtasCLoLz+I6zlrpw3a258omOI0ph5G9C+YYsDWoXjyj4uuWTTV396vfA== X-Received: by 2002:a17:902:db06:b0:216:725c:a12c with SMTP id d9443c01a7336-21a83f46a4dmr169435385ad.9.1736528408865; Fri, 10 Jan 2025 09:00:08 -0800 (PST) Received: from smtpclient.apple (157-131-199-171.fiber.dynamic.sonic.net. [157.131.199.171]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-21a9f2199ebsm15926645ad.143.2025.01.10.09.00.08 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Jan 2025 09:00:08 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.300.87.4.3\)) Subject: Re: How to specify column alignment in LaTeX table output? From: Richard H Stanton In-Reply-To: <87wmf3vw3i.fsf@rensoliemans.nl> Date: Fri, 10 Jan 2025 08:59:57 -0800 Cc: emacs-orgmode@gnu.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <87wmf4qoju.fsf@rensoliemans.nl> <9F2C7295-E505-47DA-BF76-078F0C28B9E6@berkeley.edu> <87wmf3vw3i.fsf@rensoliemans.nl> To: Rens Oliemans X-Mailer: Apple Mail (2.3826.300.87.4.3) Received-SPF: pass client-ip=2607:f8b0:4864:20::641; envelope-from=rhstanton@berkeley.edu; helo=mail-pl1-x641.google.com X-Spam_score_int: -24 X-Spam_score: -2.5 X-Spam_bar: -- X-Spam_report: (-2.5 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_MED=-0.369, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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: mx11.migadu.com X-Migadu-Spam-Score: -6.19 X-Spam-Score: -6.19 X-Migadu-Queue-Id: 880458B64B X-TUID: TtqnzT+rh55T > On Jan 10, 2025, at 1:47=E2=80=AFAM, Rens Oliemans = wrote: >=20 > Richard H Stanton writes: >=20 >> what are the recommended headers for a Python code block that exports = a table? For example, ":results output raw=E2=80=9D and ":results output = drawer=E2=80=9D both seem to work (without :wrap), while =E2=80=9C:results= output=E2=80=9D puts everything in an example block, which then seems = to get exported verbatim, not as a LaTeX table. >=20 > Take a look at > = https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-python.html. = I found > this link in the Org manual, "(org) Results of Evaluation", and then = to > "Documentation" link of python. =46rom that page: >=20 > :results {output, value}: Output results come from whatever the = python code > prints on stdout. Value results are the value of the last = expression > evaluated in the code block. Value mode is the default (as with = other > languages). In value mode you can use the following subtypes: >=20 > verbatim: value is returned as string. In particular, use this = to > prevent conversion of lists and tuples to tables. >=20 > table: (Org 9.7+) Try to convert the result to an Org table. = Dicts, > numpy arrays, and pandas DataFrames/Series can be returned as = tables > this way (by default, they are printed verbatim). Note that = lists and > tuples are already converted to table by default (use verbatim = to > prevent that). >=20 > So, ':results output' will output whatever python prints to stdout. = With > 'print()', I think that this will just be a string, and no conversion = will take > place. If you specify 'output raw', python will still just print the = string, but > *Org mode* will now interpret it as raw Org mode. This will probably = work fine, > but you'll have to add '|' and newlines in your string correctly. = Alternative: >=20 > ':results value', the default. In this case ob-python will convert = lists and > tuples to tables by default (and optionally, dicts and DataFrames as = well). >=20 > That would be my recommendation: a code block with the default = headers, which > returns a list of lists. I've attached an org file which does this. >=20 >> I actually generate this table from a Python code block. In the past, = I=E2=80=99ve often run into problems with raw output (like this), where = running the code block multiple times causes the output to appear = multiple times, rather than overwriting. >=20 > ':results append' will cause the output to appear multiple times, but = I expect > that it happened due to other circumstances (':results replace' is = default and I > expect you didn't change that). One such circumstance is when you, = say, add a > ':results output' header argument, and then change it back. For = reasons unknown > to me, Org mode will then see the previous #+RESULTS: block as = unrelated to the > current one, and will not replace it. >=20 > This is then kind of annoying, because you'll have to add the = #+ATTR_LATEX: line > to the table again. I'd fix this manually, but if it gets annoying you = can use > the suggestion by PA. Thanks, Rens. Lots of useful information! Regarding output appearing multiple times, I realize it=E2=80=99s not = tables that are the prime offender. It=E2=80=99s more when I=E2=80=99m = outputting text, usually trying to get Python to generate LaTeX code, = e.g., after symbolically solving a system of equations in Python. Here=E2=80=99s an example: #+begin_src python :results output replace raw=20 print("a") #+end_src Every time I run this code block, I get another line containing =E2=80=9Ca= =E2=80=9D. If I don't use the raw option, e.g., #+begin_src python :results output print("a") #+end_src the multiple-output problem goes away, but now it appears as=20 #+RESULTS: : a The extra =E2=80=9C: =E2=80=9C interferes with LaTeX if I=E2=80=99ve = just output something like =E2=80=9C\begin{equation}=E2=80=9D, which is = why I=E2=80=99m using raw in the first place. Wrapping the output in a LaTeX environment helps, e.g., #+begin_src python :results output raw :wrap flushleft print("a") #+end_src But is there a =E2=80=9Cpreferred=E2=80=9D way to output arbitrary text = (e.g., LaTeX equations) from Python code blocks so that they compile = fine *and* don=E2=80=99t append? Thanks for this discussion. This is about where I get to every time I = think I want to use org mode to create LaTeX documents with embedded, = live calculations, and then after wrestling with the headers for a while = I tend to go back again to separate .py and .tex files controlled by GNU = Make...