emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
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.


  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 \
    --in-reply-to=87a6hvxovh.fsf@gmail.com \
    --to=theophilusx@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --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).