From: Tim Cross <theophilusx@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: Why is an image width restricted to being between 0 and 200% of the text area
Date: Tue, 23 Nov 2021 19:14:51 +1100 [thread overview]
Message-ID: <87a6hvxovh.fsf@gmail.com> (raw)
In-Reply-To: <87pmqrpda5.fsf@gmail.com>
Matt Huszagh <huszaghmatt@gmail.com> writes:
> I agree that requesting an image to be >2x the buffer text width is a
> strange request, and it's not one I've ever tried to give. But, I think
> the salient point is that it's a very clear request, and I think org
> should carry it out. I'm all in favor of org helping people not shoot
> themselves in the foot, but I don't think it should prevent people from
> doing so, especially when they're clear about their intentions. I also
> think this qualifies as a case where someone /might/ have a valid reason
> for doing this.
+1M. We need to ensure org does not become too opinionated regarding
what is reasonable. If there is no good reason to impose an upper limit,
we should avoid doing so. Org is so powerful and open to customisation,
it is unlikely any of us can foresee all possible scenarios, so we need
to be careful not to artificially constrain the possibilities. ,
>
> I guess we could make the upper limit customizable and default to
> 2.0. But, this is a bit confusing because it doesn't apply to the
> original image width. I also think adding too many customizable
> variables adds to complexity. I don't know. Thoughts? This also isn't a
> feature I've ever needed... so I'm happy to concede and revisit it in
> the future if I have a valid use case for it.
>
+1M. Org already has an excessive number of custom settings. We need to
actively avoid adding mor whenever we can. At first glance, a custom
variable seems to be a good option. However, once you take testing and
maintenance into consideration and think about the basic testing
principal of ensuring all possible paths are tested, you soon see why
adding such custom options really increases maintenance overhead.
If there is a legitimate technical reason to set an upper limit, then
that is fine. However, setting a limit because you cannot imagine anyone
wanting to go above it is probably not.
next prev parent reply other threads:[~2021-11-23 8:23 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-23 6:16 Why is an image width restricted to being between 0 and 200% of the text area Matt Huszagh
2021-11-23 6:17 ` Timothy
2021-11-23 7:00 ` Matt Huszagh
2021-11-23 7:01 ` Timothy
2021-11-23 7:21 ` Matt Huszagh
2021-11-23 8:14 ` Tim Cross [this message]
-- strict thread matches above, loose matches on Subject: below --
2021-11-23 11:16 autofrettage
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=87a6hvxovh.fsf@gmail.com \
--to=theophilusx@gmail.com \
--cc=emacs-orgmode@gnu.org \
/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).