* DOM manipulation functions
@ 2014-11-23 15:18 Lars Magne Ingebrigtsen
2014-11-23 15:58 ` joakim
` (4 more replies)
0 siblings, 5 replies; 24+ messages in thread
From: Lars Magne Ingebrigtsen @ 2014-11-23 15:18 UTC (permalink / raw)
To: emacs-devel; +Cc: Stefan Monnier
As part of the TLS management thing, it was suggested that Emacs display
visually certificate fingerprints:
http://sebsauvage.net/wiki/doku.php?id=php:vizhash_gd
I've started looking into this, and it seems like this would be really
easy to implement as SVG images -- SVG provides all the primitives
vizhash needs.
SVG is basically an XML DOM, and while constructing these it would be a
lot easier if Emacs had a DOM manipulation library.
So here's my two questions:
1) Would it be OK if I added a DOM manipulation/searching library to
Emacs?
2) Due to stupidity on my part I disregarded Chong's advice on how to do
the DOM manipulation things in shr.el, so we now basically have two DOMs
in Emacs -- the xml.el one and the one that shr uses.
I think it would be a good idea if I rewrote shr.el to just use the
xml.el DOM, like Chong said back then. This will break any third-party
code that relies on shr internals, though.
So: New dom.el, and rewrite shr/eww to depend on dom.el.
Stefan, does this sound OK to you?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: DOM manipulation functions
2014-11-23 15:18 DOM manipulation functions Lars Magne Ingebrigtsen
@ 2014-11-23 15:58 ` joakim
2014-11-23 15:59 ` Rüdiger Sonderfeld
` (3 subsequent siblings)
4 siblings, 0 replies; 24+ messages in thread
From: joakim @ 2014-11-23 15:58 UTC (permalink / raw)
To: emacs-devel
Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> As part of the TLS management thing, it was suggested that Emacs display
> visually certificate fingerprints:
>
> http://sebsauvage.net/wiki/doku.php?id=php:vizhash_gd
>
> I've started looking into this, and it seems like this would be really
> easy to implement as SVG images -- SVG provides all the primitives
> vizhash needs.
>
> SVG is basically an XML DOM, and while constructing these it would be a
> lot easier if Emacs had a DOM manipulation library.
>
> So here's my two questions:
>
> 1) Would it be OK if I added a DOM manipulation/searching library to
> Emacs?
>
> 2) Due to stupidity on my part I disregarded Chong's advice on how to do
> the DOM manipulation things in shr.el, so we now basically have two DOMs
> in Emacs -- the xml.el one and the one that shr uses.
>
> I think it would be a good idea if I rewrote shr.el to just use the
> xml.el DOM, like Chong said back then. This will break any third-party
> code that relies on shr internals, though.
>
> So: New dom.el, and rewrite shr/eww to depend on dom.el.
>
> Stefan, does this sound OK to you?
It sounds cool, and I would like to use it in the xwidgets branch, if possible.
--
Joakim Verona
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: DOM manipulation functions
2014-11-23 15:18 DOM manipulation functions Lars Magne Ingebrigtsen
2014-11-23 15:58 ` joakim
@ 2014-11-23 15:59 ` Rüdiger Sonderfeld
2014-11-23 16:01 ` Lars Magne Ingebrigtsen
2014-11-24 0:26 ` Leo Liu
2014-11-23 18:45 ` DOM manipulation functions raman
` (2 subsequent siblings)
4 siblings, 2 replies; 24+ messages in thread
From: Rüdiger Sonderfeld @ 2014-11-23 15:59 UTC (permalink / raw)
To: emacs-devel; +Cc: Lars Magne Ingebrigtsen, Stefan Monnier
On Sunday 23 November 2014 16:18:24 Lars Magne Ingebrigtsen wrote:
> 2) Due to stupidity on my part I disregarded Chong's advice on how to do
> the DOM manipulation things in shr.el, so we now basically have two DOMs
> in Emacs -- the xml.el one and the one that shr uses.
>
> I think it would be a good idea if I rewrote shr.el to just use the
> xml.el DOM, like Chong said back then. This will break any third-party
> code that relies on shr internals, though.
Aren't there three? I think libxml has its own DOM structure as well or is it
the same as xml.el? Because in shr.el the code converts the libxml DOM into
its own DOM. But that's just from my memory.
> So: New dom.el, and rewrite shr/eww to depend on dom.el.
I think it would be awesome if we had one unified DOM implementation, which
could either use libxml (if available) or xml.el (as a fallback) to parse XML.
Regards,
Rüdiger
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: DOM manipulation functions
2014-11-23 15:59 ` Rüdiger Sonderfeld
@ 2014-11-23 16:01 ` Lars Magne Ingebrigtsen
2014-11-23 16:52 ` Steinar Bang
2014-11-24 0:26 ` Leo Liu
1 sibling, 1 reply; 24+ messages in thread
From: Lars Magne Ingebrigtsen @ 2014-11-23 16:01 UTC (permalink / raw)
To: Rüdiger Sonderfeld; +Cc: emacs-devel
Rüdiger Sonderfeld <ruediger@c-plusplus.de> writes:
> Aren't there three? I think libxml has its own DOM structure as well or is it
> the same as xml.el?
The libxml DOM is the same as the xml.el DOM.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: DOM manipulation functions
2014-11-23 15:59 ` Rüdiger Sonderfeld
2014-11-23 16:01 ` Lars Magne Ingebrigtsen
@ 2014-11-24 0:26 ` Leo Liu
2014-11-25 9:12 ` mapping data formats imported from C libraries (was: DOM manipulation functions) Ted Zlatanov
1 sibling, 1 reply; 24+ messages in thread
From: Leo Liu @ 2014-11-24 0:26 UTC (permalink / raw)
To: emacs-devel
On 2014-11-23 16:59 +0100, Rüdiger Sonderfeld wrote:
> I think it would be awesome if we had one unified DOM implementation,
> which could either use libxml (if available) or xml.el (as a fallback)
> to parse XML.
I also much prefer a unified and solid dom manipulation library in
emacs.
Leo
^ permalink raw reply [flat|nested] 24+ messages in thread
* mapping data formats imported from C libraries (was: DOM manipulation functions)
2014-11-24 0:26 ` Leo Liu
@ 2014-11-25 9:12 ` Ted Zlatanov
2014-11-25 15:54 ` mapping data formats imported from C libraries Lars Magne Ingebrigtsen
0 siblings, 1 reply; 24+ messages in thread
From: Ted Zlatanov @ 2014-11-25 9:12 UTC (permalink / raw)
To: emacs-devel
On Mon, 24 Nov 2014 08:26:47 +0800 Leo Liu <sdl.web@gmail.com> wrote:
LL> On 2014-11-23 16:59 +0100, Rüdiger Sonderfeld wrote:
>> I think it would be awesome if we had one unified DOM implementation,
>> which could either use libxml (if available) or xml.el (as a fallback)
>> to parse XML.
LL> I also much prefer a unified and solid dom manipulation library in
LL> emacs.
This is going to come up with libjson (see
https://github.com/vincenthz/libjson/blob/master/json.h) vs. json.el as
well. And libyaml probably, though that one may get mapped to whatever
we do for JSON anyway. Do we try to keep the existing data mappings or
fit closer to the library's mappings at the C level?
Ted
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: mapping data formats imported from C libraries
2014-11-25 9:12 ` mapping data formats imported from C libraries (was: DOM manipulation functions) Ted Zlatanov
@ 2014-11-25 15:54 ` Lars Magne Ingebrigtsen
2014-11-25 16:27 ` Ted Zlatanov
0 siblings, 1 reply; 24+ messages in thread
From: Lars Magne Ingebrigtsen @ 2014-11-25 15:54 UTC (permalink / raw)
To: emacs-devel
Ted Zlatanov <tzz@lifelogs.com> writes:
> This is going to come up with libjson (see
> https://github.com/vincenthz/libjson/blob/master/json.h) vs. json.el as
> well. And libyaml probably, though that one may get mapped to whatever
> we do for JSON anyway. Do we try to keep the existing data mappings or
> fit closer to the library's mappings at the C level?
I think it makes sense to map all those into the Emacs DOM.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: mapping data formats imported from C libraries
2014-11-25 15:54 ` mapping data formats imported from C libraries Lars Magne Ingebrigtsen
@ 2014-11-25 16:27 ` Ted Zlatanov
2014-11-25 16:32 ` Lars Magne Ingebrigtsen
0 siblings, 1 reply; 24+ messages in thread
From: Ted Zlatanov @ 2014-11-25 16:27 UTC (permalink / raw)
To: emacs-devel
On Tue, 25 Nov 2014 16:54:50 +0100 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:
LMI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> This is going to come up with libjson (see
>> https://github.com/vincenthz/libjson/blob/master/json.h) vs. json.el as
>> well. And libyaml probably, though that one may get mapped to whatever
>> we do for JSON anyway. Do we try to keep the existing data mappings or
>> fit closer to the library's mappings at the C level?
LMI> I think it makes sense to map all those into the Emacs DOM.
You mean json.el's mapping? I don't think there's an official DOM for that.
Ted
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: mapping data formats imported from C libraries
2014-11-25 16:27 ` Ted Zlatanov
@ 2014-11-25 16:32 ` Lars Magne Ingebrigtsen
2014-11-25 16:40 ` Ted Zlatanov
0 siblings, 1 reply; 24+ messages in thread
From: Lars Magne Ingebrigtsen @ 2014-11-25 16:32 UTC (permalink / raw)
To: emacs-devel
Ted Zlatanov <tzz@lifelogs.com> writes:
> LMI> I think it makes sense to map all those into the Emacs DOM.
>
> You mean json.el's mapping? I don't think there's an official DOM for that.
I want there to be One True Emacs DOM, and that's the xml.el/libxml2
DOM. :-) JSON maps just fine unto that DOM.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: mapping data formats imported from C libraries
2014-11-25 16:32 ` Lars Magne Ingebrigtsen
@ 2014-11-25 16:40 ` Ted Zlatanov
2014-11-25 17:06 ` Lars Magne Ingebrigtsen
0 siblings, 1 reply; 24+ messages in thread
From: Ted Zlatanov @ 2014-11-25 16:40 UTC (permalink / raw)
To: emacs-devel
On Tue, 25 Nov 2014 17:32:00 +0100 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:
LMI> Ted Zlatanov <tzz@lifelogs.com> writes:
LMI> I think it makes sense to map all those into the Emacs DOM.
>>
>> You mean json.el's mapping? I don't think there's an official DOM for that.
LMI> I want there to be One True Emacs DOM, and that's the xml.el/libxml2
LMI> DOM. :-) JSON maps just fine unto that DOM.
Yes, but in a really sucky way. If you look at the libjson and json.el
output, it's much leaner. Mapping JSON up to XML pretty much guarantees
pain when you use it and on the way back. Do you want to inflict that
on everyone in the name of a unified DOM?
Ted
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: mapping data formats imported from C libraries
2014-11-25 16:40 ` Ted Zlatanov
@ 2014-11-25 17:06 ` Lars Magne Ingebrigtsen
2014-11-26 10:41 ` Steinar Bang
2014-11-26 12:59 ` Ted Zlatanov
0 siblings, 2 replies; 24+ messages in thread
From: Lars Magne Ingebrigtsen @ 2014-11-25 17:06 UTC (permalink / raw)
To: emacs-devel
Ted Zlatanov <tzz@lifelogs.com> writes:
> Yes, but in a really sucky way. If you look at the libjson and json.el
> output, it's much leaner. Mapping JSON up to XML pretty much guarantees
> pain when you use it and on the way back. Do you want to inflict that
> on everyone in the name of a unified DOM?
The Emacs DOM is quite non-sucky. It's just a tree.
(thing ((attrib . value)) (foo) (bar))
JSON maps onto it really nicely. The attributes are always nil, though.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: mapping data formats imported from C libraries
2014-11-25 17:06 ` Lars Magne Ingebrigtsen
@ 2014-11-26 10:41 ` Steinar Bang
2014-11-26 15:51 ` Lars Magne Ingebrigtsen
2014-11-26 12:59 ` Ted Zlatanov
1 sibling, 1 reply; 24+ messages in thread
From: Steinar Bang @ 2014-11-26 10:41 UTC (permalink / raw)
To: emacs-devel
>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:
> The Emacs DOM is quite non-sucky. It's just a tree.
> (thing ((attrib . value)) (foo) (bar))
Nice. How do you get to that tree from libxml2? Is it parsed into the
libxml2 DOM first and then transferred into the lisp structure?
If so, is the libxml2 tree kept in memory as well, or is it free'd? Or
is the lisp structure a thin wrapper over the libxml2 native tree?
Or is the XML stream parsed by libxml2 directly into the lisp structure?
Ie. the lisp structure is the only in-memory representation of the DOM?
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: mapping data formats imported from C libraries
2014-11-25 17:06 ` Lars Magne Ingebrigtsen
2014-11-26 10:41 ` Steinar Bang
@ 2014-11-26 12:59 ` Ted Zlatanov
2014-11-26 15:56 ` Lars Magne Ingebrigtsen
1 sibling, 1 reply; 24+ messages in thread
From: Ted Zlatanov @ 2014-11-26 12:59 UTC (permalink / raw)
To: emacs-devel
On Tue, 25 Nov 2014 18:06:37 +0100 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:
LMI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> Yes, but in a really sucky way. If you look at the libjson and json.el
>> output, it's much leaner. Mapping JSON up to XML pretty much guarantees
>> pain when you use it and on the way back. Do you want to inflict that
>> on everyone in the name of a unified DOM?
LMI> The Emacs DOM is quite non-sucky. It's just a tree.
LMI> (thing ((attrib . value)) (foo) (bar))
LMI> JSON maps onto it really nicely. The attributes are always nil, though.
Yeah, I've seen the mess that libxml2 and json.el produce (not the
coder's fault, it's just a pain to adapt without native types). It
doesn't help that XML/SGML and Lisp are inbred cousins :)
* it's a pain to distinguish JSON's `false' and `null' while using them
in code
* in json.el you pick the key-value storage method! yay!
* in json.el you pick the array storage method! yay!
* JSON data is not a tree
My ideal mapping from libjson and libyaml would be:
* unambiguous: you can reconstruct a canonical version of the input
stream from the parse data, as much as possible (JSON is better at this)
* native: you can iterate over JSON arrays as Lisp lists, and JSON
key-value mappings as alists. JSON's `false' and `null' are both
false in Lisp boolean context.
* clean: no extra cons cells for attributes
* readable: this is huge IMO, to be able to pretty-print the data and
quickly see what it contains... one of the things I like about JSON
vs. SGML/XML.
The ideal thing may be a "libjson/libyaml native" data format that can
then be bidirectionally mapped to the DOM you suggest...
Ted
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: mapping data formats imported from C libraries
2014-11-26 12:59 ` Ted Zlatanov
@ 2014-11-26 15:56 ` Lars Magne Ingebrigtsen
2014-11-26 16:48 ` Ted Zlatanov
0 siblings, 1 reply; 24+ messages in thread
From: Lars Magne Ingebrigtsen @ 2014-11-26 15:56 UTC (permalink / raw)
To: emacs-devel
Ted Zlatanov <tzz@lifelogs.com> writes:
> Yeah, I've seen the mess that libxml2 and json.el produce (not the
> coder's fault, it's just a pain to adapt without native types). It
> doesn't help that XML/SGML and Lisp are inbred cousins :)
>
> * it's a pain to distinguish JSON's `false' and `null' while using them
> in code
Well, I don't think that's a DOM point.
> * in json.el you pick the key-value storage method! yay!
>
> * in json.el you pick the array storage method! yay!
>
> * JSON data is not a tree
Sure it is.
{"a": {"b": [1, 2], "c": 4}}
> My ideal mapping from libjson and libyaml would be:
>
> * unambiguous: you can reconstruct a canonical version of the input
> stream from the parse data, as much as possible (JSON is better at this)
Trivial from the Emacs DOM.
> * native: you can iterate over JSON arrays as Lisp lists, and JSON
> key-value mappings as alists. JSON's `false' and `null' are both
> false in Lisp boolean context.
Outside the scope of the DOM.
> * clean: no extra cons cells for attributes
Doesn't matter. :-)
> * readable: this is huge IMO, to be able to pretty-print the data and
> quickly see what it contains... one of the things I like about JSON
> vs. SGML/XML.
`pp' prints the DOM real purdy like. I've web scraped bunches and
bunches of pages, and reading the DOM in the *scratch* buffer is really
easy.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: DOM manipulation functions
2014-11-23 15:18 DOM manipulation functions Lars Magne Ingebrigtsen
2014-11-23 15:58 ` joakim
2014-11-23 15:59 ` Rüdiger Sonderfeld
@ 2014-11-23 18:45 ` raman
2014-11-25 11:01 ` Nicolas Richard
2014-11-26 18:44 ` Lars Magne Ingebrigtsen
4 siblings, 0 replies; 24+ messages in thread
From: raman @ 2014-11-23 18:45 UTC (permalink / raw)
To: emacs-devel
I'd love to have the DOM manipulation functionality to use from
Emacspeak -- so 1+!
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: DOM manipulation functions
2014-11-23 15:18 DOM manipulation functions Lars Magne Ingebrigtsen
` (2 preceding siblings ...)
2014-11-23 18:45 ` DOM manipulation functions raman
@ 2014-11-25 11:01 ` Nicolas Richard
2014-11-26 18:44 ` Lars Magne Ingebrigtsen
4 siblings, 0 replies; 24+ messages in thread
From: Nicolas Richard @ 2014-11-25 11:01 UTC (permalink / raw)
To: emacs-devel
Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> I think it would be a good idea if I rewrote shr.el to just use the
> xml.el DOM, like Chong said back then. This will break any third-party
> code that relies on shr internals, though.
>
> So: New dom.el, and rewrite shr/eww to depend on dom.el.
Great idea. I always wondered why shr had its own representation.
Please note that there are various existing implementations that might
be worth looking at, including one already named dom.el
(http://www.emacswiki.org/emacs/dom.el). See
http://www.emacswiki.org/emacs/XmlParser
--
Nicolas Richard
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: DOM manipulation functions
2014-11-23 15:18 DOM manipulation functions Lars Magne Ingebrigtsen
` (3 preceding siblings ...)
2014-11-25 11:01 ` Nicolas Richard
@ 2014-11-26 18:44 ` Lars Magne Ingebrigtsen
2014-11-26 19:42 ` Ted Zlatanov
4 siblings, 1 reply; 24+ messages in thread
From: Lars Magne Ingebrigtsen @ 2014-11-26 18:44 UTC (permalink / raw)
To: emacs-devel
This is now on the trunk. Please let me know whether something broke in
eww or shr.
I should probably add a manual entry for dom.el... But where? The
lispref manual?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2014-11-26 20:00 UTC | newest]
Thread overview: 24+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-11-23 15:18 DOM manipulation functions Lars Magne Ingebrigtsen
2014-11-23 15:58 ` joakim
2014-11-23 15:59 ` Rüdiger Sonderfeld
2014-11-23 16:01 ` Lars Magne Ingebrigtsen
2014-11-23 16:52 ` Steinar Bang
2014-11-24 0:26 ` Leo Liu
2014-11-25 9:12 ` mapping data formats imported from C libraries (was: DOM manipulation functions) Ted Zlatanov
2014-11-25 15:54 ` mapping data formats imported from C libraries Lars Magne Ingebrigtsen
2014-11-25 16:27 ` Ted Zlatanov
2014-11-25 16:32 ` Lars Magne Ingebrigtsen
2014-11-25 16:40 ` Ted Zlatanov
2014-11-25 17:06 ` Lars Magne Ingebrigtsen
2014-11-26 10:41 ` Steinar Bang
2014-11-26 15:51 ` Lars Magne Ingebrigtsen
2014-11-26 19:57 ` Steinar Bang
2014-11-26 20:00 ` Lars Magne Ingebrigtsen
2014-11-26 12:59 ` Ted Zlatanov
2014-11-26 15:56 ` Lars Magne Ingebrigtsen
2014-11-26 16:48 ` Ted Zlatanov
2014-11-23 18:45 ` DOM manipulation functions raman
2014-11-25 11:01 ` Nicolas Richard
2014-11-26 18:44 ` Lars Magne Ingebrigtsen
2014-11-26 19:42 ` Ted Zlatanov
2014-11-26 19:44 ` Lars Magne Ingebrigtsen
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.