Re: image-transform.el and image-mode.el rewrite

[Stefan Monnier <monnier@iro.umontreal.ca>]

> With the exception of `image-mode-fit-frame` all renames either added or
> removed -mode- from the name. The rationale is very simple. Functions
> that operate on images and are meaningful outside of `image-mode` don't
> have -mode- in the name.

Makes sense.  So just include this explanation in the Commentary:.

>> I recommend you take a look at doc-view.el and plan on sharing some
>> of the code there as well. E.g. the image-scale-step should probably
>> be merged with doc-view-shrink-factor.
> Eventually all of the doc-view scaling and fitting should be based on
> image-manip. I plan to look into that once this patch is done with.

Perfect, thanks (tho the scaling at least should not be performed on
the png images, but rather (as is the case now) should be done as part
of the conversion to png, otherwise the loss of quality is annoying).

> It mimics convert/bash specification where boolean parameters are either
> there or not.  I would be happy to remove this feature, as it brings some
> additional complexities.

Then please remove it.  This complexity is not worth its weight.

> The `image-transform-features:convert' in the current form is at the
> core of image-transform.el. Convert specification is used as a canonical
> description of the transformations, thus ensuring compatibility between
> backeds. This allows for writing of generic code independently of the
> applied backend. Currently, any transformation chain that works under
> 'native backend will work with 'convert.

image-transform-features:convert includes an insane amount of things
additionally to what we can ever expect to see in the native backend(s).

> If 'native backend is extended in the future with more
> transformations, or new backends are added, old code will work happily
> with all of the new features.

I don't really like the idea of "convert" being the definition of what
can be done.  So I'd rather stick to a smaller subset, along with an
escape hatch, in case the program is OK with being dependent on the
presence of "convert".

An intermediate solution might be to auto-generate the
bulk of the image-transform-features:convert entries from something like
"convert --help".


        Stefan