Matt Huszagh <[email protected]> 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.
