Re: make a drawing with Emacs

[Tomas Hlavaty]

On Thu 03 Sep 2020 at 09:38, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> 1) It is not clear upfront, when it does not work, as demonstrated with
>>    svg-image vs svg-print.
>>    This is general problem with foreign dependencies.
>
> I believe svg-image is the only exception and it's an intuitive one at
> that

Sorry it wasn't intuitive to me as I don't know emacs internals (yet?).

> since it is used to create an internal Emacs image object whose only
> use is to display the image inside an Emacs buffer.

There seem to be other uses as well, e.g. to save the image (image-save
function).  Maybe other uses like create a screenshot?

image.el also has some questionable constraints.  For example:

- Can an image have pages?
- What about tiff images?
- Why is pdf not an image?
- Can I implement new or redefine old image format in pure Elisp?  How?

Many modes depend on image.el which is hard to plug into when the
foreign libraries are not there.  That is why I have to reimplement more
than I like in emacs-framebuffer.el.  And probably the reason why there
are more than one pdf viewers.

>> 2) Elisp does not have keyword arguments.  However, svg.el works around
>>    that with rest arg plist.  This brings the worst of both worlds:
>>    complexity and useless tools.
>>
>>    For example, I use eldoc.  Eldoc hint for svg-circle is useless:
>>
>>       svg-circle: (SVG X Y RADIUS &rest ARGS)
>>
>>    I have to dig into the source code to find out what ARGS is.  Every
>>    time I use svg-circle.
>>
>> Writing own alternative to svg.el offers a chance to fix those problems.
>
> Or maybe you can improve the package instead of writing a new one.
> Code is sometimes called "software" because presumably it's more
> malleable than "hardware".

Maybe.  svg.el seems to be 4 years old and likely has many users
already.  The fake keyword args as rest args plist was a bad choice 4
years ago which will be hard to fix.  What would be the right way to do
this if not writing svg2.el?  Perhaps to implement proper keyword
support in Elisp?