From: Timothy <firstname.lastname@example.org>
To: Matt Huszagh <email@example.com>
Subject: Re: [PATCH] Fix regex for determining image width from attribute
Date: Mon, 22 Nov 2021 03:20:36 +0800 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
[-- Attachment #1: Type: text/plain, Size: 1444 bytes --]
> A recent patch started computing the inline image width from any attr_
> line. This is incorrect, as it matches settings like attr_latex, or
> attr_html. We only want to look for settings specifically for the org
> buffer. This patch fixes that.
Once again, thank you for the patch. The fact that the current regexp matches
`#+attr_latex' and `#+attr_html' is in fact by design though*. This is because I
consider it safe to assume that a `#+attr_*' which gives non-integer width between
0 and 2 can be safely assumed to be that proportion of the page width. e.g.
`#+attr_latex: :width 0.7\linewidth' or `#+attr_html: :width 70%'.
This way, a good guess can be made without having do have both an
`#+attr_latex/html' /and/ an `#+attr_org' line for the width. Should this assumption
be incorrect, a subsequent `#+attr_org' line will override the other `#+attr_*'.
Should there be edge-cases where this assumption doesn’t hold, I’d be interested
in patches that improves the logic here. As long as this holds more often than
not though, this should be a net positive for user experience as I see it.
Do please let me know if there are any good examples of unintended /
counter-intuitive behaviour you’re aware of.
All the best,
* Well, it’s worked this way for a while, and I made a deliberate choice to keep
this behaviour when expanding the width to recognise proportional values.
next prev parent reply other threads:[~2021-11-21 19:31 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-21 19:08 [PATCH] Fix regex for determining image width from attribute Matt Huszagh
2021-11-21 19:20 ` Timothy [this message]
2021-11-21 19:51 ` Matt Huszagh
2021-11-22 8:29 ` Timothy
2021-11-22 16:11 ` Matt Huszagh
2021-11-22 17:54 ` Timothy
2021-11-22 20:53 ` Matt Huszagh
2021-11-23 4:59 ` Kyle Meyer
2021-11-23 5:14 ` Timothy
2021-11-23 5:38 ` Matt Huszagh
2021-11-23 5:39 ` Timothy
2021-11-23 7:46 ` Matt Huszagh
2021-11-23 16:44 ` Max Nikulin
2021-11-24 1:57 ` Matt Huszagh
2021-11-24 14:48 ` Max Nikulin
2021-11-24 15:59 ` Matt Huszagh
2021-11-24 17:00 ` Max Nikulin
2021-11-25 16:43 ` Max Nikulin
2021-11-29 0:23 ` Matt Huszagh
2021-11-29 5:13 ` Timothy
2021-12-01 3:24 ` Matt Huszagh
2021-12-01 4:54 ` Timothy
2021-12-03 2:06 ` Matt Huszagh
2021-11-29 12:15 ` Max Nikulin
2021-11-22 14:30 ` Max Nikulin
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:
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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
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).