[Top][All Lists]

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

bug#1397: RFC: A "markup mode"

From: tomas
Subject: bug#1397: RFC: A "markup mode"
Date: Mon, 29 Feb 2016 10:05:39 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

Hash: SHA1

On Sun, Feb 28, 2016 at 11:18:05PM -0800, John Wiegley wrote:
> >>>>> Lars Ingebrigtsen <address@hidden> writes:
> >> The markup model is more or less what we know from XML: spans of text
> >> are attached with a "markup class" and a (possibly empty) list of
> >> attributes. Those spans may be empty (the "singletons" in XML).
> > I think there's several of these markup modes in Emacs (and in the various
> > package repos), so I don't think this is that relevant any more (seven years
> > later). Closing.
> Isn't this very similar to what enriched-mode tried to be?

It had a more general scope: the idea was to have a "pluggable" storage
representation, and the markup itself was "abstract" in the sense that
each "marked-up span of text", aka "element" in (rough) XML parlance,
could have an arbitrary attribute list associated with it.

But this has since been (nearly) superseded with far more powerful
ideas, org-mode being one. While coming from another side, it actually
covers much of what am tried to do, and a myriad of other things
too. And much better at that.

I still think there's a place for something along the lines of am
(think representing and editing *losslessly* a pre-existing markup [1]
while trying to show it to the user in a friendly way), but had I
to do it, I'd pull my lessons from there and reboot.

The repo still exists, for the curious :-)

- - - - -
[1] as long as it's hierarchical; I agonized a lot around this
    limitation (Emacs overlays are not hierarchical, and this
    opens up a lot of possibilities). Actually I hoped for some
    discussion on that point.

- -- tomás
Version: GnuPG v1.4.12 (GNU/Linux)


reply via email to

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