From: Timothy <firstname.lastname@example.org> To: Matt Huszagh <email@example.com> Cc: firstname.lastname@example.org Subject: Re: [PATCH] Fix regex for determining image width from attribute Date: Mon, 22 Nov 2021 03:20:36 +0800 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> [-- Attachment #1: Type: text/plain, Size: 1444 bytes --] Hi Matt, > 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, Timothy * 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 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
Reply instructions: 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: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: https://www.orgmode.org/ * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH] Fix regex for determining image width from attribute' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox: https://git.savannah.gnu.org/cgit/emacs/org-mode.git 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).