From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:303:5f26::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id EAczKbiDlGWQeAAAkFu2QA (envelope-from ) for ; Tue, 02 Jan 2024 22:44:24 +0100 Received: from aspmx1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id YEdeIriDlGUa5AAAqHPOHw (envelope-from ) for ; Tue, 02 Jan 2024 22:44:24 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=YNX1MGTj; 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=1704231864; 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=XgrMFjW563e53fY3Nmy6cGtM3UvLpDAmEh1ByxuwUWo=; b=gGfIT2NBqq8XhjwxUrnwQCqRL/xCdJQr7einSYLmAgjPKuKlVReiBrijWloSY5J97to4yo 38B+qVAw00/JO7DI9TdP3N9gEkl/ulvK2VNOChB488KMl6Ne0fsmXeDMtq1YTbbrBbMT/A uwv9jqc17G5YPoGQoB2yXLLbP2gpNH3T7zoTxtcspt9npJTev2Q9HFKXA+/enYvyk/FqAA /Wua3f3Bhai3Rm8DYXo7UAXDzTWqZtxVwDBYqS1ilMsCT9ZvPgbUGaKx+kv9ZUTRr5r6hB bO23sAe3z1rOyNwCpQ9lM0tuzuKPWNGtyyAB3ub8x0TOW6x3K2mf50X2S4Ug7w== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1704231864; a=rsa-sha256; cv=none; b=k9Y7Js+HqibvAczGwspbMwFOYn4nv2o/3d49bqCp+fSROqmRI9E9DS5dQB4Ua+Y0/UxgZ2 VNHY60aHcIaDJtBPj4VI3Q//b1uP6gTcsEjaB9Sf689sxQ9AI0TbAxyDfGx3ZFQ9veRuH7 EgszHZTFmGqee9d8ckfUPyizwYW0p7mvXbRR0ddZXkyZGZaVhaqT3xL3bV/h+vsNS+xpep Skko23myIMJPJn3xqkah2+jfhmxZklJWCP3T9GWdRCEZVN7Gt0UewfwWD0gY1gKtvk6JSR xgcXVlyy1qwtvUg1TRo655O26krDjtV8yiJAKAHe0IMTEWBBZLwIpcjYZXkYjA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=YNX1MGTj; 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 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 17F5714B3A for ; Tue, 2 Jan 2024 22:44:24 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rKmXo-0006tT-N9; Tue, 02 Jan 2024 16:43:28 -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 1rKmXn-0006t6-0a for emacs-orgmode@gnu.org; Tue, 02 Jan 2024 16:43:27 -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 1rKmXk-0007gH-PU for emacs-orgmode@gnu.org; Tue, 02 Jan 2024 16:43:26 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 84A9E240027 for ; Tue, 2 Jan 2024 22:43:19 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1704231799; bh=AzFc4Yfz+/MWXjXj2ioFwkcY9WBeHBMaPQ7aoCF8314=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version: Content-Transfer-Encoding:From; b=YNX1MGTjgYZUNu5Ee7CUklgIRrNFvdigFF1jdIwamTEcAsb2Tf24JXw2xkRWWKxDm 2ViRy1hWBjUnN4bay85BVYQoh98T8stDOHpNaCwbkYv0JLLuJ/119apA5ZGS6RsW7z hxGTBfsLJSFRIZqUnqw0Tfabj/J3c2M+oCS5lSja2VlDYUMM+uywAPVvsXGs4bvep7 LfjEy6jCtjgEY2XDFoAbs4Ng8wttMjFJ+JTlgz+2ogjmge9R3utKHX70xppix3Nv44 imxZ7a/aEgjwZcZI78IPlmTtIqDuV6SpISPAmzGoTKZANUbaGYWFJ3HagaIIeGVuDv hxU2aQUZwyKyA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4T4RDQ603Lz6twJ; Tue, 2 Jan 2024 22:43:18 +0100 (CET) From: =?utf-8?Q?Juan_Manuel_Mac=C3=ADas?= To: Ihor Radchenko Cc: orgmode Subject: Re: Are 'placement' and 'float' "obsolete terms" in inline images export In-Reply-To: <87il6td9tv.fsf@localhost> (Ihor Radchenko's message of "Thu, 26 Oct 2023 09:14:36 +0000") References: <877cneicop.fsf@posteo.net> <87zg098z93.fsf@localhost> <87o7gpjhaf.fsf@posteo.net> <87il6td9tv.fsf@localhost> Date: Tue, 02 Jan 2024 21:43:16 +0000 Message-ID: <878r57jtsb.fsf@posteo.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=185.67.36.65; envelope-from=maciaschain@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_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 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-Spam-Score: -9.99 X-Spam-Score: -9.99 X-Migadu-Queue-Id: 17F5714B3A X-Migadu-Scanner: mx12.migadu.com X-TUID: AJMnFaEDN4jB Apologies for my delay in answering all the interesting questions you raised in this last message. November and December have been horrible work days for me (all publishers are always in a hurry) and I haven't been able to attend to the mailing list as I would like... Ihor Radchenko writes: > Juan Manuel Mac=C3=ADas writes: > >>> What about :wrap? >> >> I like :wrap. What's more, remembering that old thread where >> some questions about code before/after the image were discussed, >> what if the expected value of :wrap were a kind of template? This would >> allow code to be placed before and/or after (not just an environment) >> the image, always within the float environment, if it exists. Something >> like this: >> >> #+ATTR_LaTeX: :float nil :wrap \begin{minipage}[b]{10pc}\small\n%s\n\end= {minipage}=20 >> #+CAPTION: caption >> [[file:foo.png]] >> ... >> #+ATTR_LaTeX: :float minipage :placement [b]{10pc} :caption \captionof{f= igure}{caption}=20 >> [[file:foo.png]] >> >> I don't know if it would be appropriate to explain in the Manual that >> doing so would not be... "correct"? I don't know if there is any term in >> programming to designate these situations which, without being bugs, are >> functionalities not consciously sought... > > What about making :wrap override :float completely + obsoleting :float. > We can allow wrap to have special values like in float: > > :wrap t/:wrap multicolumn/:wrap sideways > > With these special values, :placement will be taken into account. +1. Great idea. > Further, we can make templates a bit more detailed. > Starting from similar to what you proposed in the above > > :wrap \begin{minipage}[b]{10pc}\small\n%{body}\n\end{minipage} > > to more granular control over caption, centering, comment-include, > and image-code: > > %{caption} %{caption-text} %{centering} %{comment} %{comment-text} > %{image} %{image-path}. > > If the :wrap text does not contain %{...} placeholder, it will be > treated as what :float artbirary-environment does. > > We may even consider something like > > #+name: latex-template > #+begin_src latex :export none > > \begin{minipage}[b]{10pc}\small > %{body} > \end{minipage} > #+end_src > > #+attr_latex: :wrap latex-template[] > > As a bonus, :wrap may allow prepending/appending arbitrary code to > headings: > > * Heading starting at a new page > :PROPERTIES: > :ATTR_LATEX: :wrap \clarpage%{default} > :END: I really like what you propose, both the idea and the syntax. I think that such a versatile template system (with such a level of granularity but with a clear syntax at the same time) would be a killer feature. It wouldn't be bad to also extend it to the case of tables and other backends, such as html. I also think it would solve a "classic" Org syntax issue (in my opinion) which is the difficulty in 'nesting things'. Well, it can be done currently (for example, the special blocks do their job pretty well), but at the cost of increasing the verbosity of the code (I am thinking, for example, of using the LaTeX threeparttable package through nested special blocks...) Best regards, and happy New Year --=20 Juan Manuel Mac=C3=ADas