make a drawing with Emacs

[Emanuel Berg]

Hello everyone,

the project I'm currently working on is a tree house.
It has two floors and then several extension
platforms which are reachable by ropes. Here are some
photos [1] - the "new-deck" was completed only one
week ago or something :)

Anyway, I'd like to make a drawing of it. Any idea
what software might be used? Can Emacs do this?
Or can you input the data in an Emacs buffer, and
have it compile into an image using some
3rd-hand software?

Optimally I'd like to just measure everything, then
input the data - perhaps as geometrical figures?
(e.g., a tree could be a circle, I input the diameter
and relative position...) and then the programs
compiles and produce the image ... good idea, right?

Last time I asked this, several years ago and
regarding another project, someone said org-mode can
do this. I never used it, so are there some starters?
I know org-mode can do state diagrams and all
computer things, but can you have it draw arbitrary
figures? If so, how?

TIA


[1] https://dataswamp.org/~incal/work-photos/tree-house/

--
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

[to...@tuxteam.de]

On Mon, Aug 31, 2020 at 05:05:02AM +0200, Emanuel Berg via Users list for the GNU Emacs text editor wrote:
> Hello everyone,
>
> the project I'm currently working on is a tree house.
> It has two floors and then several extension
> platforms which are reachable by ropes. Here are some
> photos [1] - the "new-deck" was completed only one
> week ago or something :)
>
> Anyway, I'd like to make a drawing of it. Any idea
> what software might be used? Can Emacs do this?
> Or can you input the data in an Emacs buffer, and
> have it compile into an image using some
> 3rd-hand software?

If you are thinking 3D, then OpenSCAD [1] might suit
you: pametric, script-centric, text-friendly.

Available on most of your friendly distro dealers :-)

Cheers

[1] https://en.wikipedia.org/wiki/OpenSCAD
- t

[Marcin Borkowski]

artist-mode? ;-)

On a more serious note, how about tikz?

Hth,
mb

On 2020-08-31, at 05:05, Emanuel Berg via Users list for the GNU Emacs text editor <help-gn...@gnu.org> wrote:

> Hello everyone,
>
> the project I'm currently working on is a tree house.
> It has two floors and then several extension
> platforms which are reachable by ropes. Here are some
> photos [1] - the "new-deck" was completed only one
> week ago or something :)
>
> Anyway, I'd like to make a drawing of it. Any idea
> what software might be used? Can Emacs do this?
> Or can you input the data in an Emacs buffer, and
> have it compile into an image using some
> 3rd-hand software?
>

> Optimally I'd like to just measure everything, then
> input the data - perhaps as geometrical figures?
> (e.g., a tree could be a circle, I input the diameter
> and relative position...) and then the programs
> compiles and produce the image ... good idea, right?
>
> Last time I asked this, several years ago and
> regarding another project, someone said org-mode can
> do this. I never used it, so are there some starters?
> I know org-mode can do state diagrams and all
> computer things, but can you have it draw arbitrary
> figures? If so, how?
>
> TIA
>
>
> [1] https://dataswamp.org/~incal/work-photos/tree-house/


--

Marcin Borkowski
http://mbork.pl

[Carlo Tambuatco]

Blender.

On Sun, Aug 30, 2020, 11:05 PM Emanuel Berg via Users list for the GNU

[Emanuel Berg]

tomas wrote:

> If you are thinking 3D, then OpenSCAD might suit
> you: pametric, script-centric, text-friendly.

No no, 2D, top-view! Like an old school engineering
drawing, but less detailed. But with real units...

But thanks anyway. Maybe 3D will be the next step.

But then I think I'd make it a Quake level.
OTOH shouldn't normalize falling down from it :)

*gulp*

PS. Fun fact: How did the French secret service
reveal German spies? They said, "this place is
fine but there are no good drawings. maybe you
can make one?" a couple of days later, if they
got a drawing that was perfect in every detail -
bring the gun, it's a German spy for sure :)

[Emanuel Berg]

Marcin Borkowski wrote:

> On a more serious note, how about tikz?

Will check that out, thanks.

[Emanuel Berg]

Carlo Tambuatco wrote:

> Blender.

"Very fast and versatile 3D modeller/renderer"
(Debian repos)

Maybe it can do 2D as well...

[Yuri Khan]

On Tue, 1 Sep 2020 at 03:29, Emanuel Berg via Users list for the GNU
Emacs text editor <help-gn...@gnu.org> wrote:

> > If you are thinking 3D, then OpenSCAD might suit
> > you: pametric, script-centric, text-friendly.
>
> No no, 2D, top-view! Like an old school engineering
> drawing, but less detailed. But with real units...

You want 2D, get LibreCAD.

[Emanuel Berg]

Yuri Khan wrote:

>>> If you are thinking 3D, then OpenSCAD might suit
>>> you: pametric, script-centric, text-friendly.
>>
>> No no, 2D, top-view! Like an old school
>> engineering drawing, but less detailed. But with
>> real units...
>
> You want 2D, get LibreCAD.

I want to write code (data) and then have it
translate into a drawing. See the original post.
So no GUI, no actual "drawing". CAD doesn't sound
like that, but maybe I'm wrong?

[Gregory Heytings]

>
> Anyway, I'd like to make a drawing of it. Any idea what software might
> be used? Can Emacs do this? Or can you input the data in an Emacs
> buffer, and have it compile into an image using some 3rd-hand software?
>
> Optimally I'd like to just measure everything, then input the data -
> perhaps as geometrical figures? (e.g., a tree could be a circle, I input
> the diameter and relative position...) and then the programs compiles
> and produce the image ... good idea, right?
>

I would do that with MetaPost. It allows you to do exactly what you want:
input the data in an Emacs buffer (Emacs has a MetaPost mode), as a series
of geometrical figures and equations, which is compiled into an image.

Gregory

[Emanuel Berg]

Gregory Heytings via Users list for the GNU Emacs text editor wrote:

> I would do that with MetaPost. It allows you to do
> exactly what you want: input the data in an Emacs
> buffer (Emacs has a MetaPost mode), as a series of
> geometrical figures and equations, which is
> compiled into an image.

Wonderful! Yes, I have `metapost-mode'!

In the repos is texlive-metapost (and -doc)

That's it, I take it?

You have a small example I can compile?

Thanks anyway/already, now we're getting somewhere :)

[Yuri Khan]

On Tue, 1 Sep 2020 at 03:54, Emanuel Berg via Users list for the GNU
Emacs text editor <help-gn...@gnu.org> wrote:

> I want to write code (data) and then have it
> translate into a drawing. See the original post.
> So no GUI, no actual "drawing". CAD doesn't sound
> like that, but maybe I'm wrong?

Hm, why not just write SVG?

[Emanuel Berg]

Yuri Khan wrote:

>> I want to write code (data) and then have it
>> translate into a drawing. See the original post.
>> So no GUI, no actual "drawing". CAD doesn't sound
>> like that, but maybe I'm wrong?
>
> Hm, why not just write SVG?

I don't know? :)

[Dan Espen]

Emanuel Berg <moase...@zoho.eu> writes:

> Yuri Khan wrote:
>
>>> I want to write code (data) and then have it
>>> translate into a drawing. See the original post.
>>> So no GUI, no actual "drawing". CAD doesn't sound
>>> like that, but maybe I'm wrong?
>>
>> Hm, why not just write SVG?
>
> I don't know? :)

Yeah when you said you wanted to write code, SVG came to my mind too.
It's not that hard to learn, I got pretty good at it in a few days.
I don't remember any Emacs assists for it, I just coded it
up and used a web browser to look at the results.

The GUI approach isn't the worst thing in the world, right now
I'm trying to master Inkscape which can generate SVG.


--
Dan Espen

[Perry Smith]

> On Aug 31, 2020, at 4:04 PM, Emanuel Berg via Users list for the GNU Emacs text editor <help-gn...@gnu.org> wrote:
>
> Yuri Khan wrote:
>
>>> I want to write code (data) and then have it
>>> translate into a drawing. See the original post.
>>> So no GUI, no actual "drawing". CAD doesn't sound
>>> like that, but maybe I'm wrong?
>>
>> Hm, why not just write SVG?
>
> I don't know? :)

It may not be suited for general drawings but Graphiz has “pic” … a language (flat ASCII text) that defines “graphs”.

https://en.wikipedia.org/wiki/Graphviz <https://en.wikipedia.org/wiki/Graphviz>

[Ulrich Deiters]

If you need something that plots functions, data points, etc. (even
including parameter fitting, various interpolation methods), I
can offer "grafix". It abuses emacs as an XML editor and builds
a human-readable graphics file, and then translates that into
PostScript.

--
Prof. i.R. Dr. Ulrich K. Deiters ______________________________________
Institut f. Physikalische Chemie \ Greinstr. 4–6, D-50939 Köln
Universitaet zu Köln /\/\... \ Tel. +49 (0)2232 932964
_______________________L|L|__|_____\ http://www.uni-koeln.de/deiters/

[Peter Münster]

On Mon, Aug 31 2020, Gregory Heytings via Users list for the GNU Emacs text editor wrote:

> I would do that with MetaPost.

Or MetaFun (MetaPost with extensions).

--
Peter

[to...@tuxteam.de]

On Mon, Aug 31, 2020 at 10:52:59PM +0200, Emanuel Berg via Users list for the GNU Emacs text editor wrote:
> Yuri Khan wrote:
>
> >>> If you are thinking 3D, then OpenSCAD might suit
> >>> you: pametric, script-centric, text-friendly.
> >>
> >> No no, 2D, top-view! Like an old school
> >> engineering drawing, but less detailed. But with
> >> real units...
> >
> > You want 2D, get LibreCAD.
>

> I want to write code (data) and then have it
> translate into a drawing. See the original post.
> So no GUI, no actual "drawing". CAD doesn't sound
> like that, but maybe I'm wrong?

TiKZ and OpenSCAD qualify, but they cover different areas (the one
is for (gorgeous!) diagranms and the other is for (dimensional)
drawings.

Don't let the 'CAD' in OpenSCAD lead you astray: you specify the
drawings in a written language (somewhat reminiscent of C). You get
some help from a viewer and a rudimentary editor.

Cheers
- t

[to...@tuxteam.de]

On Tue, Sep 01, 2020 at 04:01:51AM +0700, Yuri Khan wrote:

> On Tue, 1 Sep 2020 at 03:54, Emanuel Berg via Users list for the GNU
> Emacs text editor <help-gn...@gnu.org> wrote:
>
> > I want to write code (data) and then have it
> > translate into a drawing. See the original post.
> > So no GUI, no actual "drawing". CAD doesn't sound
> > like that, but maybe I'm wrong?
>

> Hm, why not just write SVG?

I'd prefer writing Emacs lisp which writes SVG (actually I've dabbled
in that: much more fun!). Start about here:

(require 'svg)
(insert-image
(svg-image
(let ((svg (svg-create 100 100)))
(svg-circle svg 50 50 20 :stroke-width 6 :stroke 'blue :fill 'yellow)
svg)))

Of course, once you've got all the infrastructure for the drawings
of a tree house up and running, the tree might have grown out of
reach ;-)

Cheers
- t

[Emanuel Berg]

Yuri Khan wrote:

>> I want to write code (data) and then have it
>> translate into a drawing. See the original post.
>> So no GUI, no actual "drawing". CAD doesn't sound
>> like that, but maybe I'm wrong?
>
> Hm, why not just write SVG?

I think SVG seems like a really good alternative.
I can't find a complete syntax reference tho. This is
the best page I found so far:

https://flaviocopes.com/svg/

The .svg extension in Emacs gives me the major mode
`nxml-mode'

nXML mode defined in ‘nxml-mode.el’:
Major mode for editing XML.

So a file test.svg:

<svg width="10" height="10">
<rect
x="0"
y="0"
width="10"
height="10"
fill="blue"
/>
</svg>

works well! Only not in feh(1), my image viewer [1] -
but with

$ convert test.svg test.png

I get a PNG!

Great :D


[1] https://dataswamp.org/~incal/SOFTWARE

[Emanuel Berg]

tomas wrote:

> I'd prefer writing Emacs lisp which writes SVG
> (actually I've dabbled in that: much more fun!)

Please share <3

> Start about here:
>
> (require 'svg)
> (insert-image
> (svg-image
> (let ((svg (svg-create 100 100)))
> (svg-circle svg 50 50 20 :stroke-width 6 :stroke 'blue :fill 'yellow)
> svg)))

Yeah but ... what is the advantage with that compared
to editing a text file, using Emacs? Syntax?
User-defined functions? It's Lisp?

[Gregory Heytings]

>
>> I would do that with MetaPost. It allows you to do exactly what you
>> want: input the data in an Emacs buffer (Emacs has a MetaPost mode), as
>> a series of geometrical figures and equations, which is compiled into
>> an image.
>
> Wonderful! Yes, I have `metapost-mode'!
>
> In the repos is texlive-metapost (and -doc)
>
> That's it, I take it?
>

Yes, that's the (Debian) package, and all you need.

>
> You have a small example I can compile?
>

See http://tex.loria.fr/prod-graph/zoonekynd/metapost/metapost.html .

The MetaPost manual is quite readable, and contains many small examples :
https://www.tug.org/docs/metapost/mpman.pdf .

[to...@tuxteam.de]

On Tue, Sep 01, 2020 at 10:32:48AM +0200, Emanuel Berg via Users list for the GNU Emacs text editor wrote:
> Yuri Khan wrote:
>
> >> I want to write code (data) and then have it
> >> translate into a drawing. See the original post.
> >> So no GUI, no actual "drawing". CAD doesn't sound
> >> like that, but maybe I'm wrong?
> >
> > Hm, why not just write SVG?
>
> I think SVG seems like a really good alternative.
> I can't find a complete syntax reference tho. This is
> the best page I found so far:
>
> https://flaviocopes.com/svg/

Straight from the Horse's Mouth:

https://www.w3.org/TR/SVG11/

W3.org is the keeper of SVG. They have a ton of other resources
on it.

What I don't like about SVG:

- it's XML: XML is gross.
- It's not XML: there's a whole lot of sublanguage hidden
in the attribute strings which escapes the "XML lens".
This is even grosser.

But it's a nice output format, which is not only vector, but can
be extended (e.g. sub-elements can be URL links and such things).
It can be married to CSS. So that part is nice.

What I don't like about SVG in Emacs: for display, it is "flattened"
to a "dead image", so the nifty and dynamical things get lost.

But hey. Set up a crowdfunding and give me two years (or give Stefan
a quarter of a year ;-)

So much for SVG :-)

Cheers
- t

[to...@tuxteam.de]

On Tue, Sep 01, 2020 at 10:38:21AM +0200, Emanuel Berg via Users list for the GNU Emacs text editor wrote:
> tomas wrote:
>
> > I'd prefer writing Emacs lisp which writes SVG
> > (actually I've dabbled in that: much more fun!)
>
> Please share <3
>
> > Start about here:
> >
> > (require 'svg)
> > (insert-image
> > (svg-image
> > (let ((svg (svg-create 100 100)))
> > (svg-circle svg 50 50 20 :stroke-width 6 :stroke 'blue :fill 'yellow)
> > svg)))
>
> Yeah but ... what is the advantage with that compared
> to editing a text file, using Emacs? Syntax?
> User-defined functions? It's Lisp?

Mainly the last.

Once you've spent a week telling your stupid SVG "this triangle
goes to (23.2, 5.7), and this other goes to (29.7, 6.2)" you want
to be able to be more abstract and say "triangle C goes smack in
the middle of A and B" and "circle X goes somewhere between Y and
Z, but choose a spot which looks nice".

You want programmability.

Look into TiKZ (whether you end up using it or not) for some
inspiration on what you might want a drawing program to do for
you.

Or Metapost: as an heir to Metafont, it probably has that declarative
touch to it.

Cheers
- t

[Emanuel Berg]

tomas wrote:

> (require 'svg)
> (insert-image
> (svg-image
> (let ((svg (svg-create 100 100)))
> (svg-circle svg 50 50 20 :stroke-width 6 :stroke 'blue :fill 'yellow)
> svg)))

OK, I see the point, that makes sense and it seems
like a pleasant workbench.

Only, how do you get an image file?

Also, that evaluates to

image-type: Invalid image type ‘svg’

That might be an emacs-nox thing, perhaps?

[to...@tuxteam.de]

On Tue, Sep 01, 2020 at 02:22:32PM +0200, Emanuel Berg via Users list for the GNU Emacs text editor wrote:
> tomas wrote:
>
> > (require 'svg)
> > (insert-image
> > (svg-image
> > (let ((svg (svg-create 100 100)))
> > (svg-circle svg 50 50 20 :stroke-width 6 :stroke 'blue :fill 'yellow)
> > svg)))
>
> OK, I see the point, that makes sense and it seems
> like a pleasant workbench.
>
> Only, how do you get an image file?
>
> Also, that evaluates to
>
> image-type: Invalid image type ‘svg’
>
> That might be an emacs-nox thing, perhaps?

Your Emacs has to be able to display svg images. Your easiest bet is
that you are just missing librsvg (package librsvg2-2 or thereabouts,
if you are on Debian) -- but of course, your Emacs has to be compiled
with SVG support built in (no idea whether emacs-nox does).

Cheers
- t

[Marcin Borkowski]

On 2020-09-01, at 11:04, to...@tuxteam.de wrote:

> You want programmability.
>
> Look into TiKZ (whether you end up using it or not) for some
> inspiration on what you might want a drawing program to do for
> you.
>
> Or Metapost: as an heir to Metafont, it probably has that declarative
> touch to it.

To expand a bit (as a TikZ user and a former METAPOST user):

METAPOST is older, has (I think) less add-ons than TikZ, but has a few
very distinctive features, most notably drawing "nice" Bezier curves
without specifying the control points, and a declarative engine for
solving systems of linear equations - a very nice thing to have when you
want to find intersections of lines. (TikZ has the former if you use
LuaTeX and some package I don't remember the name of, and the latter
sort-of, i.e., much less general.)

METAPOST is rather sparsely documented (that said, I used it for
considerable time and was satisfied with it).

If you stick with METAPOST, consider looking at ConTeXt, which heavily
extends it with the so-called "METAFUN macros".

Most probably, you want TikZ. Excellent software, excellent
documentation, numerous add-ons. Nice things are:

- it has a _lot_ of ways to specify coordinates (2D, pseudo-3D, polar
coordinates and a lot more),

- there are a lot of ways to add various labels (called "nodes") to the
drawing.

Hth,

[Emanuel Berg]

tomas wrote:

> Your Emacs has to be able to display svg images.
> Your easiest bet is that you are just missing
> librsvg (package librsvg2-2 or thereabouts, if you
> are on Debian

OK... 1s, no I have it

i A librsvg2-2 - SAX-based renderer library for SVG f

Got into a discussion the other day, is Ubuntu
Debian? I think it is. What do you think?

Not that I don't use Debian :)

> ) -- but of course, your Emacs has to be compiled
> with SVG support built in (no idea whether
> emacs-nox does).

Me neither :)

[Emanuel Berg]

WOW, good post.

I don't know anything about this! What is
this software?

[to...@tuxteam.de]

On Tue, Sep 01, 2020 at 10:48:01PM +0200, Emanuel Berg via Users list for the GNU Emacs text editor wrote:
> Marcin Borkowski wrote:

[...]

> WOW, good post.
>
> I don't know anything about this! What is
> this software?

TiKZ is impressive. I found it a bit hard to wrap one's head
around it. It grew around the TeX and Metafont ideas. To get
a rough impression of what it's capable of, have a look at
their showcase

https://texample.net/

their "resources" page

https://texample.net/tikz/resources/

Their manual is recommended reading:

http://paws.wcu.edu/tsfoguel/tikzpgfmanual.pdf

also available in the dead tree version.

For a quick-and-dirty technical dimensioned drawing, I still
think you're better off with OpenSCAD. But the journey is the
reward, as they say.

Cheers
- t

[Tomas Hlavaty]

>> That might be an emacs-nox thing, perhaps?
>

> Your Emacs has to be able to display svg images.

It is a shame that image code in emacs is completely dependent on unsafe
foreign libraries and tightly coupled with graphics toolkits.

> Your easiest bet is that you are just missing librsvg (package

> librsvg2-2 or thereabouts, if you are on Debian) -- but of course,

> your Emacs has to be compiled with SVG support built in (no idea
> whether emacs-nox does).

Here is an alternative which works even on console without any graphics
toolkit compiled in:

(require 'xml)
(with-temp-buffer
(xml-print
'((svg
((xmlns . "http://www.w3.org/2000/svg")
(viewBox . "0 0 100 100"))
(circle
((cx . "50") (cy . "50") (r . "20"))))))
(write-file "/tmp/a.svg"))

The /tmp/a.svg file will contain the SVG image.

Now the nice part of doing it in pure Elisp is that you can refactor the
code into useful functions as you need. For example:

(defun svg (x y w h &rest body)
`((svg
((xmlns . "http://www.w3.org/2000/svg")
(viewBox . ,(format "%s %s %s %s" x y w h)))
,@body)))

(defun svg-circle (cx cy r)
`(circle
((cx . ,(format "%s" cx)
(cy . ,(format "%s" cy))
(r . ,(format "%s" r))))))

(with-temp-buffer
(xml-print
(svg 0 0 100 100 (svg-circle 50 50 20)))
(write-file "/tmp/a.svg"))

You can then display the generated image in the console using
https://logand.com/sw/emacs-framebuffer/file/emacs-framebuffer.el.html

[Emanuel Berg]

Tomas Hlavaty wrote:

> Here is an alternative which works even on console without any graphics
> toolkit compiled in:
>
> (require 'xml)
> (with-temp-buffer
> (xml-print
> '((svg
> ((xmlns . "http://www.w3.org/2000/svg")
> (viewBox . "0 0 100 100"))
> (circle
> ((cx . "50") (cy . "50") (r . "20"))))))
> (write-file "/tmp/a.svg"))
>
> The /tmp/a.svg file will contain the SVG image.
>
> Now the nice part of doing it in pure Elisp is that
> you can refactor the code into useful functions as

> you need. For example [...]

Indeed, that works great! Thanks a lot! Now I just
have to get the primitives from the W3C tutorial and
then implement neat little Elisp wrappers for all the
common stuff...

https://dataswamp.org/~incal/emacs-init/svg-my.el

> You can then display the generated image in the console using
> https://logand.com/sw/emacs-framebuffer/file/emacs-framebuffer.el.html

Really? :O

And... how do I get just the .el file?

[Stefan Monnier]

> Now the nice part of doing it in pure Elisp is that you can refactor the

> code into useful functions as you need. For example:

That's pretty much what the svg.el package mentioned earlier in the
thread does. Instead of `svg-image`, use `svg-print`.


Stefan

[Leo Butler]

Emanuel Berg via Users list for the GNU Emacs text editor

<help-gn...@gnu.org> writes:

> ********************************************************
> Caution: This message was sent from outside the University of Manitoba.
> ********************************************************

>
> Tomas Hlavaty wrote:
>
>> Here is an alternative which works even on console without any graphics
>> toolkit compiled in:
>>
>> (require 'xml)
>> (with-temp-buffer
>> (xml-print
>> '((svg
>> ((xmlns . "http://www.w3.org/2000/svg")
>> (viewBox . "0 0 100 100"))
>> (circle
>> ((cx . "50") (cy . "50") (r . "20"))))))
>> (write-file "/tmp/a.svg"))
>>
>> The /tmp/a.svg file will contain the SVG image.
>>

>> Now the nice part of doing it in pure Elisp is that
>> you can refactor the code into useful functions as

>> you need. For example [...]
>
> Indeed, that works great! Thanks a lot! Now I just
> have to get the primitives from the W3C tutorial and
> then implement neat little Elisp wrappers for all the
> common stuff...
>
> https://dataswamp.org/~incal/emacs-init/svg-my.el
>
>> You can then display the generated image in the console using
>> https://logand.com/sw/emacs-framebuffer/file/emacs-framebuffer.el.html
>
> Really? :O
>
> And... how do I get just the .el file?

Line 9 of the file:

Download: git clone https://logand.com/git/emacs-framebuffer.git

Interesting thread.

Leo

[Emanuel Berg]

Stefan Monnier wrote:

>> Now the nice part of doing it in pure Elisp is
>> that you can refactor the code into useful
>> functions as you need. For example [...]
>

> That's pretty much what the svg.el package
> mentioned earlier in the thread does. Instead of
> `svg-image`, use `svg-print`.

Did anyone do neat Elisp wrappers around the
essentials as well?

Because if the programmability was one of the main
advantages with Emacs vs. plain SVG (and I agree)
then that sounds like a natural step :)

I'm not lazy, and happy to do it myself, but, if
someone else already did it, I might prefer to use
that for quality concerns :)

[to...@tuxteam.de]

On Wed, Sep 02, 2020 at 11:10:29PM +0200, Tomas Hlavaty wrote:
> >> That might be an emacs-nox thing, perhaps?
> >
> > Your Emacs has to be able to display svg images.
>
> It is a shame that image code in emacs is completely dependent on unsafe
> foreign libraries and tightly coupled with graphics toolkits.

I think there is a misunderstanding. All the functions in 'svg
basically do what you sketch in your mail (i.e. manipulate a dom
as an abstract data structure with an XML representation: so
basically generate and serialize XML) and don't rely on librsvg
et al. (I guess that is what you chastise as "unsafe foreign
library").

Librsvg is used to display the svg in-buffer, as libpng is used
to display PNGs in-buffer. Feel free to re-implement that in
Emacs Lisp ;-)

[...]

> You can then display the generated image in the console using
> https://logand.com/sw/emacs-framebuffer/file/emacs-framebuffer.el.html

That's interesting -- and this is the part librsvg is an alternative
for.

How does the emacs framebuffer work? Can it display images as
parts of a regular Emacs buffer?

Cheers
- t

[Tomas Hlavaty]

On Wed 02 Sep 2020 at 18:28, Stefan Monnier <mon...@iro.umontreal.ca> wrote:
> That's pretty much what the svg.el package mentioned earlier in the
> thread does. Instead of `svg-image`, use `svg-print`.

Thanks for the info.

I see two problems with the svg.el package.

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.

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.

[Tomas Hlavaty]

On Thu 03 Sep 2020 at 09:14, <to...@tuxteam.de> wrote:
> On Wed, Sep 02, 2020 at 11:10:29PM +0200, Tomas Hlavaty wrote:
>> >> That might be an emacs-nox thing, perhaps?
>> >
>> > Your Emacs has to be able to display svg images.
>>
>> It is a shame that image code in emacs is completely dependent on unsafe
>> foreign libraries and tightly coupled with graphics toolkits.
>
> I think there is a misunderstanding. All the functions in 'svg
> basically do what you sketch in your mail (i.e. manipulate a dom
> as an abstract data structure with an XML representation: so
> basically generate and serialize XML) and don't rely on librsvg
> et al. (I guess that is what you chastise as "unsafe foreign
> library").

Not true. For example svg-image does rely on librsvg. There might be
other functions but I don't know that and there is no easy way to find
out except reading all that source code.

> How does the emacs framebuffer work? Can it display images as
> parts of a regular Emacs buffer?

Based on where the buffer is on the screen it calculates where to draw
the image on the Linux framebuffer. Then it works like w3m web browser.

[Stefan Monnier]

> 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 since it is used to create an internal Emacs image object whose
only use is to display the image inside an Emacs buffer.

> 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".


Stefan

[Tomas Hlavaty]

On Thu 03 Sep 2020 at 09:38, Stefan Monnier <mon...@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?

[Stefan Monnier]

>>> 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

It seems `svg-insert-image` is another exception.

> 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?

That doesn't seem related to `svg.el` which focuses on generating the
XML representation of an SVG image (with one or two extra help functions
like `svg-image` which also tries to help *display* that image).
Searching for `save` only finds a single match (and it's for
`save-excursion` and it's not even in the code but in a comment).

> image.el also has some questionable constraints.

`svg.el` is unrelated to `image.el` (except via `svg-image`, AFAIK).

>> 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.

Probably not "many", but then again, the more users it has, the higher
the benefit of improving it rather than writing another one.

> 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?

The answer probably depends on exactly how else you want to handle
those properties. I don't know what "proper keyword support" you're
thinking of, but if you're thinking of Common List keywords, then you
can simply change `defun` into `cl-defun` and then use `&key`.

BTW, if you're only concerned about the Eldoc and `C-h o` info, then you
can also just provide the more precise info in the docstring e.g.:

(defun svg-create (width height &rest args)
"Create a new, empty SVG image with dimensions WIDTH x HEIGHT.
ARGS can be used to provide `stroke' and `stroke-width' parameters to
any further elements added.

\(fn WIDTH HEIGHT &key STROKE STROKE-WIDTH)"
...)


-- Stefan

[Lars Magne Ingebrigtsen]

Tomas Hlavaty <t...@logand.com> writes:

> 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.

The arguments can be any attribute that's valid for an SVG element. I'm
not sure how digging into the source code helps you with determining
that -- you'd need to look at the SVG standards document to find out
what keywords/values are valid.

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

[Lars Magne Ingebrigtsen]

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

> The arguments can be any attribute that's valid for an SVG element. I'm
> not sure how digging into the source code helps you with determining
> that -- you'd need to look at the SVG standards document to find out
> what keywords/values are valid.

(That said, changing the signature on all these functions to

(cl-defun svg-... (... &key stroke-width stroke-color fill-color ... &allow-other-keys)

would be fine by me, and should be backwards-compatible.)

[Stefan Monnier]

>> The arguments can be any attribute that's valid for an SVG element. I'm
>> not sure how digging into the source code helps you with determining
>> that -- you'd need to look at the SVG standards document to find out
>> what keywords/values are valid.
>

> (That said, changing the signature on all these functions to
>
> (cl-defun svg-... (... &key stroke-width stroke-color fill-color ... &allow-other-keys)
>
> would be fine by me, and should be backwards-compatible.)

IIRC it would make the code slower, tho. It adds code like

(let ((stroke-color (cadr (plist-member args :stroke-color))))

which the compiler fails to optimize away when `stroke-color` is not used.


Stefan

[Lars Magne Ingebrigtsen]

Stefan Monnier <mon...@iro.umontreal.ca> writes:

> IIRC it would make the code slower, tho. It adds code like
>
> (let ((stroke-color (cadr (plist-member args :stroke-color))))
>
> which the compiler fails to optimize away when `stroke-color` is not used.

I didn't know that... but on the other hand, all these functions end up
calling this internal function:

(defun svg--arguments (svg args)
(let ((stroke-width (or (plist-get args :stroke-width)
(dom-attr svg 'stroke-width)))
(stroke-color (or (plist-get args :stroke-color)
(dom-attr svg 'stroke-color)))
(fill-color (plist-get args :fill-color))
attr)

Which could then lose these plist-gets, so we'd end up with
approximately the same slowness, I think. :-)

[Tomas Hlavaty]

On Thu 03 Sep 2020 at 19:28, Lars Magne Ingebrigtsen <la...@gnus.org> wrote:
> Lars Magne Ingebrigtsen <la...@gnus.org> writes:

>> The arguments can be any attribute that's valid for an SVG element. I'm
>> not sure how digging into the source code helps you with determining
>> that -- you'd need to look at the SVG standards document to find out
>> what keywords/values are valid.

At the moment, args is passed to svg--arguments.

But the point is that eldoc should be useful so that nobody needs to
look anywhere else.

> (That said, changing the signature on all these functions to
>
> (cl-defun svg-... (... &key stroke-width stroke-color fill-color ... &allow-other-keys)
>
> would be fine by me, and should be backwards-compatible.)

Why &allow-other-keys? How would you pass the other keys to
svg-arguments?

[Lars Magne Ingebrigtsen]

Tomas Hlavaty <t...@logand.com> writes:

> Why &allow-other-keys?

Because you can pass any SVG attributes you want and have them end up in
the resulting SVG document.

> How would you pass the other keys to svg-arguments?

Same as now.

[Lars Magne Ingebrigtsen]

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

>> How would you pass the other keys to svg-arguments?
>
> Same as now.

Sorry; forgot the &rest you also then need to actually get at the
unspecified keywords.

[Tomas Hlavaty]

On Thu 03 Sep 2020 at 19:45, Lars Magne Ingebrigtsen <la...@gnus.org> wrote:

> Stefan Monnier <mon...@iro.umontreal.ca> writes:
>
>> IIRC it would make the code slower, tho. It adds code like
>>
>> (let ((stroke-color (cadr (plist-member args :stroke-color))))
>>
>> which the compiler fails to optimize away when `stroke-color` is not used.
>

> I didn't know that... but on the other hand, all these functions end up
> calling this internal function:
>
> (defun svg--arguments (svg args)
> (let ((stroke-width (or (plist-get args :stroke-width)
> (dom-attr svg 'stroke-width)))
> (stroke-color (or (plist-get args :stroke-color)
> (dom-attr svg 'stroke-color)))
> (fill-color (plist-get args :fill-color))
> attr)
>
> Which could then lose these plist-gets, so we'd end up with
> approximately the same slowness, I think. :-)

&allow-other-keys does not make sense for functions.

svg--arguments is called in 9 places. Should it be possible to identify
all relevant keys for each use-case or is that not reasonable for svg?

[Tomas Hlavaty]

On Thu 03 Sep 2020 at 20:09, Lars Magne Ingebrigtsen <la...@gnus.org> wrote:
> Lars Magne Ingebrigtsen <la...@gnus.org> writes:
>

>>> How would you pass the other keys to svg-arguments?
>>
>> Same as now.
>

> Sorry; forgot the &rest you also then need to actually get at the
> unspecified keywords.

Exactly. Your suggestion:

(cl-defun svg-... (... &key stroke-width stroke-color fill-color
... &allow-other-keys)

did not make any sense.

- &allow-other-keys does not make any sense for functions

- &rest args &key a b is broken in eldoc

[Tomas Hlavaty]

On Thu 03 Sep 2020 at 20:29, Tomas Hlavaty <t...@logand.com> wrote:

> On Thu 03 Sep 2020 at 20:09, Lars Magne Ingebrigtsen <la...@gnus.org> wrote:
> (cl-defun svg-... (... &key stroke-width stroke-color fill-color
> ... &allow-other-keys)
>

> did not make any sense.
>
> - &allow-other-keys does not make any sense for functions

for functions without &rest &key