emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Why is an image width restricted to being between 0 and 200% of the


From: Tim Cross
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
User-agent: mu4e 1.7.5; emacs 28.0.60

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]