emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Matt Huszagh <huszaghmatt@gmail.com>
To: Timothy <tecosaur@gmail.com>
Cc: , emacs-orgmode@gnu.org
Subject: Re: [PATCH] Fix regex for determining image width from attribute
Date: Sun, 21 Nov 2021 11:51:57 -0800	[thread overview]
Message-ID: <87a6hxuw0y.fsf@gmail.com> (raw)
In-Reply-To: <87ilwl71gh.fsf@gmail.com>

Timothy <tecosaur@gmail.com> writes:

> 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.

Thanks for explaining the logic behind the current implementation.

Unfortunately, I think this makes a valid use case
impossible. Specifically, I like to be able to set an image width
explicitly with #+attr_org (or some other attr_ for the corresponding
export) and fall back to the actual image width when this isn't
specified. This includes the ability to use the actual image width in an
org buffer, but an explicitly-set image width for export. For example,
for my blog I often have attr_html set, but I want the image to use its
actual width when displayed in org. I don't see how this is possible
with the current implementation. But, it works naturally with the
implementation I have in mind (IIRC this is how it previously worked,
but I could be mistaken).

I do understand the desire to avoid specifying a whole bunch of
redundant attr_ settings, but I don't think it should make fine-tuned
use cases like the one above impossible. I also find the current
implementation a bit counterintuitive, if less verbose. 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.

Matt



  reply	other threads:[~2021-11-21 19:53 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 [this message]
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 \
    --in-reply-to=87a6hxuw0y.fsf@gmail.com \
    --to=huszaghmatt@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=tecosaur@gmail.com \
    /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
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

	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).