emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Saving markup formats


From: Oliver Scholz
Subject: Re: Saving markup formats
Date: Wed, 20 Jun 2007 14:36:37 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)

Nic James Ferrier <address@hidden> writes:

> Oliver Scholz <address@hidden> writes:
>
>>> #("Nic Ferrier - CV" 0 16 (element h2))
>>> #("Nic is a hacker with some crazy ideas" 0 37 (element para style p1))
>>
>> Unless I am missing something, this is just one possible internal
>> representation of a tree-like data structure. In fact, I have once
>> experimented with this. 
>
> I thought the rms was saying "why store data somewhere other than a
> buffer?". In other words, why add DOM (for example) to Emacs so that
> we can store text in it when we already have text buffers?

If you use buffers and text-properties (or overlays) as an internal
represenation of the XML infoset (or the XDL of XPath) and then add an
according API, then you have DOM, or something very DOM-like. On the
other hand, if you do something at the C-level (whatever it is) and
make sure that the integration with the rest of Emacs is right, i.e.
that killing text in a WP buffer and yanking text in a source code
buffer DTRT (whatever the right thing is ...) and vice versa, then
"you can kill text anywhere and yank it anywhere". My reading of
Richards post was different, I sense a deep conceptual disagreement
behind the sentence: "It is an important feature of Emacs that text is
a sequence of characters, not structured." Otherwise, I really think
that the internal representation is a secondary issue, the decision
about which depending on possibly conflicting parameters like
robustness, performance, aesthetics and work needed for
implementation. The UI is relevant there, too, but that is another can
of worms.


    Oliver
-- 
Oliver Scholz               2 Messidor an 215 de la Révolution
Ostendstr. 61               Liberté, Egalité, Fraternité!
60314 Frankfurt a. M.       




reply via email to

[Prev in Thread] Current Thread [Next in Thread]