From: Tim Cross <firstname.lastname@example.org> To: email@example.com 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: <firstname.lastname@example.org> (raw) In-Reply-To: <email@example.com> Matt Huszagh <firstname.lastname@example.org> 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 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] 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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: Why is an image width restricted to being between 0 and 200% of the text area' \ /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).