From: Matt Huszagh <email@example.com>
To: Timothy <firstname.lastname@example.org>
Cc: , email@example.com
Subject: Re: [PATCH] Fix regex for determining image width from attribute
Date: Mon, 22 Nov 2021 08:11:11 -0800 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
Timothy <email@example.com> writes:
> Actually, it’s almost possible with the current implementation. Consider this
> │ #+attr_org: :width t
> │ #+attr_html: :width 20%
> │ [[file:image.png]]
> At the moment Org tries to interpret `t' as a number (and obviously fails),
> however with a small tweak that I think would be very reasonable to make, this
> would cause the behaviour you describe.
> What do you think?
Yeah, I think it's ok. To be perfectly honest, I still don't love it,
but I understand now that my disagreement was with a decision made a
while ago (from a quick look at the commit history, 2012 or before), not
with the one you made recently.
In my opinion the most logical solution would be for the width to fall
back on specifically attr_org, not just any attr_ when
`org-image-actual-width' is nil. To clarify further, my main
disagreement is with the idea that setting attr_html (for example)
implies that one wants the same setting in the org buffer. But, it seems
that ship sailed a while ago and now this would be a breaking change.
So, given that, I concede and I think attr_org: :width t is an
acceptable compromise. Thanks for coming up with that!
>> (IIRC this is how it previously worked, but I could be mistaken).
> You are mistaken. The previous implementation looked for `#+attr_*' too, but
> didn’t recognise proportional values.
Ok, thanks for clarifying.
>> Maybe a solution to accomplish all goals would be to add an #+attr_fallback
>> (or attr_default, attr_any, attr_all, etc.) that is used for any backend
>> unless a specific setting is made for that backend.
> Hmmm, I’m not sure this is called for.
Yeah, I agree this is wrong. I'd misunderstood the current behavior.
next prev parent reply other threads:[~2021-11-22 16:12 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
2021-11-21 19:51 ` Matt Huszagh
2021-11-22 8:29 ` Timothy
2021-11-22 16:11 ` Matt Huszagh [this message]
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).