From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id GKweBEcvImBbdAAA0tVLHw (envelope-from ) for ; Tue, 09 Feb 2021 06:44:23 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id KIpsO0YvImCNQgAAbx9fmQ (envelope-from ) for ; Tue, 09 Feb 2021 06:44:22 +0000 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 684D094071B for ; Tue, 9 Feb 2021 06:44:22 +0000 (UTC) Received: from localhost ([::1]:38366 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l9Ml3-0005S4-B4 for larch@yhetil.org; Tue, 09 Feb 2021 01:44:21 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:38606) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l9MkH-0005Qz-RS for emacs-orgmode@gnu.org; Tue, 09 Feb 2021 01:43:34 -0500 Received: from mail-pg1-x52d.google.com ([2607:f8b0:4864:20::52d]:40589) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1l9MkD-0002Ng-NF for emacs-orgmode@gnu.org; Tue, 09 Feb 2021 01:43:33 -0500 Received: by mail-pg1-x52d.google.com with SMTP id b21so11842023pgk.7 for ; Mon, 08 Feb 2021 22:43:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version; bh=j+xcfE6zAlQg43r39Mhtkopfb3BH6tyN9WpvbvG7Pdg=; b=VOCj7CnBYPzt49LotlgEMxMBA7hqxpyyFMh/aazi6dlbQAavXsNIgWmus8yACiWCgO e9llXHtbjU9yvpIRH3PhJPL0SB4HcgAn+lI5QyR6GdAtw3RWq5UH97XdGe9rb3FGH4Tg Zx8fVlJEv2HyWFfhMz0cHjiS2HMy0XJSIIOvxjRaTiGvmm0R10DMx9JLTLSO7a0Yvcy3 iIi/pB7mXVRNAA2R4aI4ij7ozay+WlLdkce8vf2aZryCZG0Ig88iIXltqfelGzx/vR59 2GVlv3P7ywv1UoGsIyw4Cj2FinhLzPc18EpafMqKtO6jOjSTCax+h9xQoaJeS8qxmqAA W4jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version; bh=j+xcfE6zAlQg43r39Mhtkopfb3BH6tyN9WpvbvG7Pdg=; b=ub+J14nopsZPgQLOPlmfgHo1Z5ZFWV81zB5795cznXxN8rDKru266Il/JTyLoJTXON 3M8SzSv6hGtwyLdWyK+MJbhMEqxkVNqL4rggk00ElAH24M3LWAHW0mZW33mU03TBaPlL tnh0+cyeqsSKyTEVvZTsYZdEB25arW9srykDWfAgVTY9OuuSm3jobe23lI4g1kS1Vm24 3ASnaZmTVU+DaBBdVJfNgEF730k10Fd3hgF2ssUdBBZxV3U+hI1T5CtNqS3rDLwUriCb IyCkUybmWRdNsPZrtAJ7pM3rKqykHHUVEzcfsnYMFlupoJhMBCF4nwr0w6l4nXBPUib3 LmBw== X-Gm-Message-State: AOAM532VmBI4C28yzwe+v/Yi2cI/x9mLGCiR6DpaqFaZbT2SIxCAOh/Z u4+sVtXB5Egqbx5uMRtRqgEDQfLE+YTugg== X-Google-Smtp-Source: ABdhPJyxp3o2GiTVtvhnkz7EfOrFV9GZCo7hGU//sfPv+01FofPB5+g+d1rDnovuZWJ1ceWJ2gFX/w== X-Received: by 2002:a63:5b43:: with SMTP id l3mr20408593pgm.369.1612853007046; Mon, 08 Feb 2021 22:43:27 -0800 (PST) Received: from ryzen3950 (c-73-71-89-135.hsd1.ca.comcast.net. [73.71.89.135]) by smtp.gmail.com with ESMTPSA id s23sm21143642pgj.29.2021.02.08.22.43.25 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Feb 2021 22:43:26 -0800 (PST) From: Matt Huszagh To: Cc: "emacs-orgmode@gnu.org" Subject: Account for latex snippet width in fill paragraph Date: Mon, 08 Feb 2021 22:43:21 -0800 Message-ID: <87sg65d9me.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::52d; envelope-from=huszaghmatt@gmail.com; helo=mail-pg1-x52d.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, FREEMAIL_FROM=0.001, 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.23 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" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -3.06 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=VOCj7CnB; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Migadu-Queue-Id: 684D094071B X-Spam-Score: -3.06 X-Migadu-Scanner: scn0.migadu.com X-TUID: tqDyjCUID/3b Hello, I make extensive use of inline latex image snippets in my Org buffers. One thing that has annoyed me for a while is that `org-fill-paragraph' (unsurprisingly) uses the width of the underlying text when determining the characters which make up each line. Because the characters which make up the source of an image are typically wider than the image itself, this creates short lines when many snippets are used. For example, the following text ``` This gives some degree of temperature-stability because although \(V_{\mathrm{BE}}\) changes somewhat with temperature, the change is small. If the quiescent output voltage is designed for say \(10V_{\mathrm{BE}}\), and \(V_{\mathrm{BE}}\) varies \(\SI{0.1}{V}\) over temperature changes, then the quiescent point will vary \(\SI{1}{V}\) over temperature changes. This isn't great, but may sometimes be good enough. ``` appears something like ``` This gives some degree of temperature-stability because although VBE changes somewhat with temperature, the change is small. If the quiescent output voltage is designed for say 10VBE, and VBE varies 0.1V over temperature changes, then the quiescent point will vary 1V over temperature changes. This isn't great, but may sometimes be good enough. ``` Before I take a crack at this, has anyone else attempted to remedy this? I wasn't able to find anything on the mailing list. Would anyone else be interested in this functionality? I figure a proper solution would appear to the user as a configurable variable that could enable filling based on image width (this behavior might be undesirable in some cases). My currently uninformed view is that it should be possible to query the overlay image width and perform a fill based on that. Any thoughts, concerns, etc. are appreciated. Matt