bug#32359: [PATCH] Add svg-path

bug#32359: [PATCH] Add svg-path

[Felix E. Klee]

[-- Attachment #1: Type: text/plain, Size: 215 bytes --]

The patch adds `svg-path'. Among other things, this function makes it
possible to add arcs to SVG images. A path is drawn using commands
defined by the SVG standard:

https://www.w3.org/TR/SVG11/paths.html#PathData

[-- Attachment #2: add-svg-path.patch --]
[-- Type: application/octet-stream, Size: 1784 bytes --]

diff --git a/ChangeLog.3 b/ChangeLog.3
index a0a4794b4e..2a9832b67b 100644
--- a/ChangeLog.3
+++ b/ChangeLog.3
@@ -1,3 +1,7 @@
+2018-08-03  Felix E. Klee  <felix.klee@inka.de>
+
+	* lisp/svg.el (svg-path): New function.
+
 2018-07-01  Paul Eggert  <eggert@cs.ucla.edu>
 
 	* etc/HISTORY: Cite Brinkhoff on early history.
diff --git a/doc/lispref/display.texi b/doc/lispref/display.texi
index fef5188197..d45f68d95b 100644
--- a/doc/lispref/display.texi
+++ b/doc/lispref/display.texi
@@ -5541,6 +5541,19 @@ that describe the outer circumference of the polygon.
 @end lisp
 @end defun
 
+@defun svg-path svg commands &rest args
+Add the outline of a shape to @var{svg}. The @var{commands} follow the
+Scalable Vector Graphics standard. This function can be used to create
+arcs.
+
+@lisp
+(svg-path svg '((M 100 300)
+                (A 300 300 0 0 0 300 100)
+                (Z))
+          :stroke-color "blue" :fill-color "yellow")
+@end lisp
+@end defun
+
 @defun svg-text svg text &rest args
 Add a text to @var{svg}.
 
diff --git a/lisp/svg.el b/lisp/svg.el
index 1178905546..e5c4e1383a 100644
--- a/lisp/svg.el
+++ b/lisp/svg.el
@@ -138,6 +138,17 @@ POINTS is a list of x/y pairs."
 			    ", "))
       ,@(svg--arguments svg args)))))
 
+(defun svg-path (svg commands &rest args)
+  "Add the outline of a shape to SVG. The COMMANDS follow the
+Scalable Vector Graphics standard. This function can be used to
+create arcs."
+  (let ((d (mapconcat 'prin1-to-string (apply 'append commands) " ")))
+    (svg--append
+     svg
+     (dom-node 'path
+	       `((d . ,d)
+	         ,@(svg--arguments svg args))))))
+
 (defun svg-embed (svg image image-type datap &rest args)
   "Insert IMAGE into the SVG structure.
 IMAGE should be a file name if DATAP is nil, and a binary string

bug#32359: [PATCH] Add svg-path

[Eli Zaretskii]

> From: "Felix E. Klee" <felix.klee@inka.de>
> Date: Fri, 3 Aug 2018 13:07:42 +0200
> 
> The patch adds `svg-path'. Among other things, this function makes it
> possible to add arcs to SVG images. A path is drawn using commands
> defined by the SVG standard:
> 
> https://www.w3.org/TR/SVG11/paths.html#PathData

Thanks.  This contribution can be accepted without legal paperwork,
but the next one will need a copyright assignment, so I'd encourage
you to start your paperwork now.

A few comments, mainly about the documentation parts.

> diff --git a/ChangeLog.3 b/ChangeLog.3
> index a0a4794b4e..2a9832b67b 100644
> --- a/ChangeLog.3
> +++ b/ChangeLog.3
> @@ -1,3 +1,7 @@
> +2018-08-03  Felix E. Klee  <felix.klee@inka.de>
> +
> +	* lisp/svg.el (svg-path): New function.
> +

We don't maintain a ChangeLog file; the above should be the commit log
message.

> +@defun svg-path svg commands &rest args
> +Add the outline of a shape to @var{svg}. The @var{commands} follow the
> +Scalable Vector Graphics standard. This function can be used to create
> +arcs.

This is too cryptic for the manual, and the example doesn't help
enough.  We should at least explain what "arcs" means in this context,
and in general what is this function about; also what kind of object
is SCG.

Also, please observe our standard of having 2 spaces between
sentences.

In general, GNU Coding Standards frown upon using "path" for anything
that is not PATH-style directory lists, so maybe use a different name
or explain what kind of "path" is being referenced here.  E.g., the
Web page to which you pointed does include a definition of "path" in
this context.

> +(defun svg-path (svg commands &rest args)
> +  "Add the outline of a shape to SVG. The COMMANDS follow the
> +Scalable Vector Graphics standard. This function can be used to
> +create arcs."

The first line of the doc string should be a single complete sentence,
and it should mention all of the arguments.  Also, please keep 2
spaces between sentences in the doc strings.  I also think the doc
string should say that COMMANDS are strings, or objects whose printed
representation yields valid SVG commands.

This new function should also be announced in NEWS.

bug#32359: [PATCH] Add svg-path

[Felix E. Klee]

Hi Eli,

thanks for the feedback!

On 8/3/18, Eli Zaretskii <eliz@gnu.org> wrote:
> We don't maintain a ChangeLog file; the above should be the commit
> log message.

Well, the Emacs info page on committing patches states: “Write the
change log entries for your changes. […]”

Furthermore, it links to a page explaining `ChangeLog' files in
particular. Is that documentation outdated?

`ChangeLog.3' contains entries for previous additions to `svg.el', the
latest one as recent as September 2017.

Anyhow, if you want a commit log instead of a `ChangeLog' entry, how
should I submit the commit?

>> +@defun svg-path svg commands &rest args
>> +Add the outline of a shape to @var{svg}. The @var{commands} follow the
>> +Scalable Vector Graphics standard. This function can be used to create
>> +arcs.
>
> This is too cryptic for the manual,

It’s basically in line with the description for the other `svg' functions.

> and the example doesn't help enough.

For the intended audience, i.e. those knowing how to author SVG
documents, it should be clear. What I could do is add aliases for the
path commands:

  * `moveto-relative' → `m'

  * `moveto-absolute' → `M'

  * etc.

The example would then turn into:

    (svg-path svg '((moveto-absolute 100 300)
                    (arc-absolute 300 300 0 0 0 300 100)
                    (closepath-absolute))
              :stroke-color "blue" :fill-color "yellow")

Still users would need to know the command parameters which are
detailed in every comprehensive documentation about SVG.

> We should at least explain what "arcs" means in this context,

“arcs” in the context of SVG, i.e. vector graphics refers to curved
paths:

https://www.merriam-webster.com/dictionary/arc

> and in general what is this function about; also what kind of object
> is SCG.

Quote from the documentation in the elisp info page for `svg.el': “SVG
(Scalable Vector Graphics) is an XML format for specifying images.”

> In general, GNU Coding Standards frown upon using "path" for
> anything that is not PATH-style directory lists, so maybe use a
> different name or explain what kind of "path" is being referenced
> here.

Renaming `path' would be super confusing to those familiar with vector
graphics. If `path' needs to be avoided, then I’d rather not add
`svg-path'.

Instead one could add a more general:

    svg-node (parent tag &rest args)

This function is needed anyhow. It would be for inserting custom SVG
nodes, i.e. nodes beyond those currently available in the `svg'
package.

BTW I got in contact with Lars, the original author of `svg.el', and
he’s OK with the changes I proposed, including some additional
functions.

/ Felix

bug#32359: [PATCH] Add svg-path

[Eli Zaretskii]

> From: "Felix E. Klee" <felix.klee@inka.de>
> Date: Thu, 23 Aug 2018 17:50:08 +0200
> Cc: 32359@debbugs.gnu.org
> 
> thanks for the feedback!

Thanks for working on improving Emacs.

> > We don't maintain a ChangeLog file; the above should be the commit
> > log message.
> 
> Well, the Emacs info page on committing patches states: “Write the
> change log entries for your changes. […]”

The relevant place to look nowadays is CONTRIBUTE in the top-level
directory of the Emacs tree.

> Furthermore, it links to a page explaining `ChangeLog' files in
> particular. Is that documentation outdated?

It says "change logs", not ChangeLog.  However, since it confused you,
I have now replaced that with "commit log".  The reference to the GNU
Coding Standards is still relevant, I think, because we still use the
ChangeLog style in our commit log messages.

> `ChangeLog.3' contains entries for previous additions to `svg.el', the
> latest one as recent as September 2017.

That file is auto-generated nowadays from Git log.

> Anyhow, if you want a commit log instead of a `ChangeLog' entry, how
> should I submit the commit?

The best is in "git format-patch" format, which will include your
commit log message.  If that's hard or complicated for you, a normal
patch will do with the commit log as preamble, i.e. not in Diff
format.

> >> +@defun svg-path svg commands &rest args
> >> +Add the outline of a shape to @var{svg}. The @var{commands} follow the
> >> +Scalable Vector Graphics standard. This function can be used to create
> >> +arcs.
> >
> > This is too cryptic for the manual,
> 
> It’s basically in line with the description for the other `svg' functions.

Maybe so, but there's no reason to continue that practice when we add
new functions.  It is also okay to fix documentation of those other
functions, but of course it doesn't have to be part of this particular
changeset.

> > and the example doesn't help enough.
> 
> For the intended audience, i.e. those knowing how to author SVG
> documents, it should be clear.

Okay, but the manual exists not only for those already "in the know".
It should also cater to those who are studying the subject with the
purpose of writing some code for the first time in this domain.

> What I could do is add aliases for the path commands:
> 
>   * `moveto-relative' → `m'
> 
>   * `moveto-absolute' → `M'
> 
>   * etc.

I think it would be better simply to explain those in plain English,
not by adding code.

> The example would then turn into:
> 
>     (svg-path svg '((moveto-absolute 100 300)
>                     (arc-absolute 300 300 0 0 0 300 100)
>                     (closepath-absolute))
>               :stroke-color "blue" :fill-color "yellow")
> 
> Still users would need to know the command parameters which are
> detailed in every comprehensive documentation about SVG.

Exactly.  So it's slightly better (less cryptic), but still not clear
enough, because the meaning of moveto-relative and moveto-absolute is
not entirely obvious, only their general idea is evident ("relative"
vs "absolute").

I understand that it isn't reasonable to have the entire SVG docs
there, but we should explain a bit more before pointing to the
official SVG docs for further details.  I trust you that you will know
where to draw the line.

> > We should at least explain what "arcs" means in this context,
> 
> “arcs” in the context of SVG, i.e. vector graphics refers to curved
> paths:
> 
> https://www.merriam-webster.com/dictionary/arc

I didn't mean explain to me, I meant explain in the manual.

> > and in general what is this function about; also what kind of object
> > is SCG.
> 
> Quote from the documentation in the elisp info page for `svg.el': “SVG
> (Scalable Vector Graphics) is an XML format for specifying images.”

We are mis-communicating.  I didn't mean SVG the acronym, I meant SVG
the argument of the function.  The doc strings says

  Add the outline of a shape to SVG.

It is quite clear that "SVG" here doesn't stand for Scalable Vector
Graphics, it stands for some object to which the function will add a
shape.  I'm asking to say a word or two about what kind of object is
that, from the Lisp program POV.  is it a string? a symbol? a list? a
buffer? something else?

> > In general, GNU Coding Standards frown upon using "path" for
> > anything that is not PATH-style directory lists, so maybe use a
> > different name or explain what kind of "path" is being referenced
> > here.
> 
> Renaming `path' would be super confusing to those familiar with vector
> graphics. If `path' needs to be avoided, then I’d rather not add
> `svg-path'.

There's the second alternative: explain in a few words what kind of
"path" is meant here.  Then you can use the word freely.

> BTW I got in contact with Lars, the original author of `svg.el', and
> he’s OK with the changes I proposed, including some additional
> functions.

That's fine, but the way our patch review process works, the comments
are additive ;-)

Thanks.

bug#32359: [PATCH] Add svg-path

[Felix E. Klee]

On Thu, Aug 23, 2018 at 7:23 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> I think it would be better simply to explain those in plain English,
> not by adding code.

OK. Still the aliases do increase readability. They are not made up.
They are based on the “names” listed in the [specs][1].

For now, I am considering creating a separate package `svg+.el'. This
would allow me to play with various approaches, possibly with user
feedback. If that all works, one could merge the additions into Emacs.

[1]: https://www.w3.org/TR/SVG11/paths.html

bug#32359: [PATCH] Add svg-path

[Lars Ingebrigtsen]

"Felix E. Klee" <felix.klee@inka.de> writes:

> The example would then turn into:
>
>     (svg-path svg '((moveto-absolute 100 300)
>                     (arc-absolute 300 300 0 0 0 300 100)
>                     (closepath-absolute))
>               :stroke-color "blue" :fill-color "yellow")
>
> Still users would need to know the command parameters which are
> detailed in every comprehensive documentation about SVG.

I think this looks very nice -- the svg library is quite close to the
SVG specification, but when it makes sense to clarify some of the more
cryptic bits with clearer names, it should.  So these are better names
for an svg path than M/A/Z, which are extremely obscure.

So I'd welcome the patch with these name mappings.

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

bug#32359: [PATCH] Add svg-path

[Felix E. Klee]

Please have a look at:

https://github.com/feklee/svg-plus

Now the example is:

    (svg+-path svg
               '((moveto ((100 . 300)))
                 (elliptical-arc ((300 300 0 0 :large-arc nil :sweep nil)))
                 (closepath :relative nil))
               :stroke-color "blue"
               :fill-color "yellow")

I wanted to announce this package once it’s finished, which is always a
bad idea.  IIRC only complete documentation is missing, and of course
more SVG features could be added.  On Wednesday there is the Emacs
meetup in Berlin, and indeed I was thinking about presenting the package
there.  So that could be some motivation to finish it, and then we can
talk about a patch.

Thanks for bringing it up again. :)

bug#32359: [PATCH] Add svg-path

[Lars Ingebrigtsen]

"Felix E. Klee" <felix.klee@inka.de> writes:

> Please have a look at:
>
> https://github.com/feklee/svg-plus
>
> Now the example is:
>
>     (svg+-path svg
>                '((moveto ((100 . 300)))
>                  (elliptical-arc ((300 300 0 0 :large-arc nil :sweep nil)))
>                  (closepath :relative nil))
>                :stroke-color "blue"
>                :fill-color "yellow")

That's really good -- makes it actually understandable how a path is
composed.

> I wanted to announce this package once it’s finished, which is always a
> bad idea.  IIRC only complete documentation is missing, and of course
> more SVG features could be added.  On Wednesday there is the Emacs
> meetup in Berlin, and indeed I was thinking about presenting the package
> there.  So that could be some motivation to finish it, and then we can
> talk about a patch.

Bringing that function into svg.el in Emacs would be nice.

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

bug#32359: [PATCH] Add svg-path

[Felix E. Klee]

Hi Lars,

finally I got around to finishing documentation.  Find the latest
release at:

https://github.com/feklee/svg-plus

In addition to `svg+-path`, I added:

  * `svg+-clip-path`

  * `svg+-node`

If you want to play with the new functions, simply run the code examples
from the info page inside of `example.el`.  Concerning `svg+-path`, I’d
like to hear your thoughts: Do you see room for further improvement, or
could this be the final interface?

I was thinking about removing the double parentheses in commands such
as:

    (lineto ((100 . 200)))

One could simplify that to:

    (lineto (100 . 200))

Polylines would change from:

    (lineto ((100 . 200) (300 . 200)))

To:

    (lineto (100 . 200) (300 . 200))

Reasons against this change:

  * Parsing optional arguments (plist) could be a pain.  Currently what
    works nicely:

        (lineto ((100 . 200) (200 . 0)) :relative t)

    Elliptical arc allows additional optional arguments, such as:

        (elliptical-arc ((50 100 200 300 :large-arc 1)) :relative t)

  * Aesthetically, some standard Lisp commands aren’t “better.”  For
    example `let` also requires double parentheses for single
    assignments:

        (let ((x 3)) (* x x))

―Felix

bug#32359: [PATCH] Add svg-path

[Lars Ingebrigtsen]

"Felix E. Klee" <felix.klee@inka.de> writes:

> If you want to play with the new functions, simply run the code examples
> from the info page inside of `example.el`.  Concerning `svg+-path`, I’d
> like to hear your thoughts: Do you see room for further improvement, or
> could this be the final interface?

I haven't read it closely, but it looks good to me.  Could you post it
as a patch to svg.el?  That'll make it easier to read.

> I was thinking about removing the double parentheses in commands such
> as:
>
>     (lineto ((100 . 200)))
>
> One could simplify that to:
>
>     (lineto (100 . 200))
>
> Polylines would change from:
>
>     (lineto ((100 . 200) (300 . 200)))
>
> To:
>
>     (lineto (100 . 200) (300 . 200))
>
> Reasons against this change:
>
>   * Parsing optional arguments (plist) could be a pain.  Currently what
>     works nicely:
>
>         (lineto ((100 . 200) (200 . 0)) :relative t)

Yeah, I think you should keep the argument as a single argument.
Varargs with optional keywords parameters just isn't very nice.

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

bug#32359: [PATCH] Add svg-path

[Felix E. Klee]

[-- Attachment #1: Type: text/plain, Size: 239 bytes --]

Hi Lars,

find attached a patch against (coincidentally) your latest Emacs commit:

dea9970bc0deaf320e78c46a2e7456cbb6e7a0ea

Included are changes to the code and to the manual.  If you need
anything else, let me know!

―Felix

[-- Attachment #2: 0001-Add-functions-svg-path-svg-clip-path-svg-node.patch.gz --]
[-- Type: application/gzip, Size: 3877 bytes --]

bug#32359: [PATCH] Add svg-path

[Lars Ingebrigtsen]

"Felix E. Klee" <felix.klee@inka.de> writes:

> Included are changes to the code and to the manual.  If you need
> anything else, let me know!

Thanks!  It looks great, so I applied it to the trunk.  The only
possible tweak was with using moveto vs. move-to.  The latter looks more
Emacsish, but in SVG speak they're moveto (etc), so I think it makes
sense to leave them that way.

But after applying, I was suddenly unsure whether you'd signed FSF
copyright assignment papers yet or not.  I thought I remembered seeing
your name in the copyright.list file before, but now I can't see it.

Have you gone through the paperwork process with the FSF?

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

bug#32359: [PATCH] Add svg-path

[Felix E. Klee]

On Mon, Jul 15, 2019 at 5:12 PM Lars Ingebrigtsen <larsi@gnus.org>
wrote:
> The only possible tweak was with using moveto vs. move-to.  The latter
> looks more Emacsish, but in SVG speak they're moveto (etc), so I think
> it makes sense to leave them that way.

Good catch.  I had the same thought and decided to stick with `moveto`.

> Have you gone through the paperwork process with the FSF?

I just started with that, following:

https://www.gnu.org/prep/maintain/html_node/Copyright-Papers.html

A Savannah account I have, and I now requested an fencepost account.
Once I have that, I’ll try to find the appropriate template.

Sorry, I hope this is no problem.  Luckily, there is no issue with
copyright assignment: I am 1. old enough (Emacs user for >18y), and
2. not employed, wrote the code for my own pleasure.  But I understand
that the process can take a while, although nowadays it’s possible to
submit the form electronically:

“Contributors located in […] Germany […] can print, sign, and then email
(or fax) a scanned copy back to the FSF.”

bug#32359: [PATCH] Add svg-path

[Noam Postavsky]

"Felix E. Klee" <felix.klee@inka.de> writes:

>> Have you gone through the paperwork process with the FSF?
>
> I just started with that, following:
>
> https://www.gnu.org/prep/maintain/html_node/Copyright-Papers.html
>
> A Savannah account I have, and I now requested an fencepost account.
> Once I have that, I’ll try to find the appropriate template.

You don't need a Savannah nor fencepost account for this.  The form and
instructions are at
https://git.savannah.gnu.org/cgit/gnulib.git/tree/doc/Copyright/request-assign.future

bug#32359: [PATCH] Add svg-path

[Felix E. Klee]

On Tue, Jul 16, 2019 at 3:01 AM Noam Postavsky <npostavs@gmail.com> wrote:
> You don't need a Savannah nor fencepost account for this.  The form
> and instructions are at
> https://git.savannah.gnu.org/cgit/gnulib.git/tree/doc/Copyright/request-assign.future

I just submitted that form, thanks!

(Savannah account would’ve been needed for fencepost, though.)

bug#32359: [PATCH] Add svg-path

[Felix E. Klee]

Update: fencepost account got rejected because I’m only a contributor,
not a maintainer of a GNU project

How do I get access to the necessary copyright papers now?

bug#32359: [PATCH] Add svg-path

[Lars Ingebrigtsen]

"Felix E. Klee" <felix.klee@inka.de> writes:

> Sorry, I hope this is no problem.  Luckily, there is no issue with
> copyright assignment: I am 1. old enough (Emacs user for >18y), and
> 2. not employed, wrote the code for my own pleasure.  But I understand
> that the process can take a while, although nowadays it’s possible to
> submit the form electronically:

Sounds good, but I'll have to revert the patch in the meantime, I think.
Should be no problem to re-apply it later when the paperwork is done.

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

bug#32359: [PATCH] Add svg-path

[Felix E. Klee]

On Tue, Jul 16, 2019 at 8:05 AM Lars Ingebrigtsen <larsi@gnus.org>
wrote:
> Sounds good, but I'll have to revert the patch in the meantime, I
> think.

I understand.  It’s no problem at all.  I’ll let you know once the
paperwork is done.

bug#32359: [PATCH] Add svg-path

[Lars Ingebrigtsen]

"Felix E. Klee" <felix.klee@inka.de> writes:

> On Tue, Jul 16, 2019 at 8:05 AM Lars Ingebrigtsen <larsi@gnus.org>
> wrote:
>> Sounds good, but I'll have to revert the patch in the meantime, I
>> think.
>
> I understand.  It’s no problem at all.  I’ll let you know once the
> paperwork is done.

Great!

I've now reverted the patch (and Glenn's follow-up patch that added a
menu).  Both will be re-reverted once the paperwork's in place.

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

bug#32359: [PATCH] Add svg-path

[Felix E. Klee]

[-- Attachment #1: Type: text/plain, Size: 118 bytes --]

Don’t know if anyone can help here, but I sent the attached request
(edited) more than a week ago.  No reply yet.

[-- Attachment #2: Felix Edgar Klee.eml.gz --]
[-- Type: application/x-gzip, Size: 690 bytes --]

bug#32359: [PATCH] Add svg-path

[Eli Zaretskii]

> From: "Felix E. Klee" <felix.klee@inka.de>
> Date: Wed, 24 Jul 2019 09:49:26 +0200
> Cc: Eli Zaretskii <eliz@gnu.org>, 32359@debbugs.gnu.org
> 
> Don’t know if anyone can help here, but I sent the attached request
> (edited) more than a week ago.  No reply yet.

I suggest to ping them.

bug#32359: [PATCH] Add svg-path

[Felix E. Klee]

Hi Lars,

paperwork has been done, i.e. the assignment has been signed by both
parties.  If you need anything else, please let me know!

―Felix

bug#32359: [PATCH] Add svg-path

[Lars Ingebrigtsen]

"Felix E. Klee" <felix.klee@inka.de> writes:

> Hi Lars,
>
> paperwork has been done, i.e. the assignment has been signed by both
> parties.  If you need anything else, please let me know!

Great!  I've now reverted the reverting of the patch, so the svg-path
stuff should now be on the Emacs trunk.

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

bug#32359: [PATCH] Add svg-path

[Felix E. Klee]

Thanks, Lars!

bug#32359: [PATCH] Add svg-path

[Eli Zaretskii]

> From: "Felix E. Klee" <felix.klee@inka.de>
> Date: Thu, 1 Aug 2019 15:23:36 +0200
> Cc: Eli Zaretskii <eliz@gnu.org>, 32359@debbugs.gnu.org
> 
> Thanks, Lars!

Please review the followup change in the documentation I made, as the
original had a few nits that needed correcting.  In particular, you
cannot add a @node without also adding a @menu and mentioning that
node in a few other menus.

bug#32359: [PATCH] Add svg-path

[Felix E. Klee]

 On Fri, Aug 2, 2019 at 8:40 AM Eli Zaretskii <eliz@gnu.org> wrote:
> Please review the followup change in the documentation I made

The definition of SVG paths is a good addition IMO.

> In particular, you cannot add a @node without also adding a @menu and
> mentioning that node in a few other menus.

Now that “SVG Path Commands” is a subheading, isn’t the menu
superfluous?  I find it confusing to the reader.

For comparison, have a look in `searching.texi`:

    @subsubheading Literals

There is no menu for “Literals”.

bug#32359: [PATCH] Add svg-path

[Eli Zaretskii]

> From: "Felix E. Klee" <felix.klee@inka.de>
> Date: Fri, 2 Aug 2019 12:43:33 +0200
> Cc: Lars Magne Ingebrigtsen <larsi@gnus.org>, 32359@debbugs.gnu.org, Glenn Morris <rgm@gnu.org>
> 
> Now that “SVG Path Commands” is a subheading, isn’t the menu
> superfluous?

It should be superfluous.  I asked Glenn whether it was really needed;
I don't think it is.