Extending svg.el

Extending svg.el

[Ulf Jasper]

Hi Lars,

[I am cc-ing emacs-devel as this may be of general interest.]

the other day I became aware of the new libraries 'svg.el' and 'dom.el'.
They appeared to be just what I was missing when I wrote 'svg-clock.el'
and so I started re-writing 'svg-clock.el'.  I just finished that and
pushed the result to elpa.  However, in the end I only used very few
functions from 'svg.el', but wrote a handful of new functions and even
"re-invented" some functions (e.g. 'svg-line').  The reason is that many
of the functions in 'svg.el' produce side-effects (via 'svg-append' and
'svg-possibly-update-image'). Besides that adding attributes to svg
primitives appears to have an effect on the containing xml tree (via
'svg-arguments').

I think it may be good to separate the demonstration part of 'svg.el'
from the library part: Interactive commands here and side-effect free
functions there.  (Besides one may simplify the handling of attributes.)

What do you say?

Best,
Ulf

Re: Extending svg.el

[Lars Magne Ingebrigtsen]

Ulf Jasper <ulf.jasper@web.de> writes:

> However, in the end I only used very few
> functions from 'svg.el', but wrote a handful of new functions and even
> "re-invented" some functions (e.g. 'svg-line').  The reason is that many
> of the functions in 'svg.el' produce side-effects (via 'svg-append' and
> 'svg-possibly-update-image'). Besides that adding attributes to svg
> primitives appears to have an effect on the containing xml tree (via
> 'svg-arguments').

Yes, svg.el is not an immutable functional-type library, but an
object-oriented one that works on an XML tree.

If you want a function variant of the same, you can just copy the DOM
before you pass it in.  Perhaps add a `dom-copy' function to dom.el?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Extending svg.el

[Ulf Jasper]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Ulf Jasper <ulf.jasper@web.de> writes:
>
>> However, in the end I only used very few
>> functions from 'svg.el', but wrote a handful of new functions and even
>> "re-invented" some functions (e.g. 'svg-line').  The reason is that many
>> of the functions in 'svg.el' produce side-effects (via 'svg-append' and
>> 'svg-possibly-update-image'). Besides that adding attributes to svg
>> primitives appears to have an effect on the containing xml tree (via
>> 'svg-arguments').
>
> Yes, svg.el is not an immutable functional-type library, but an
> object-oriented one that works on an XML tree.
>
> If you want a function variant of the same, you can just copy the DOM
> before you pass it in.  Perhaps add a `dom-copy' function to dom.el?

Agreed.  Implicitly, without realising it myself, I was expecting a
functional-type library but not an object-oriented one or anything else.
My mistake.

Ulf