Rich Text support in Leo

[duf...@gmail.com]

Hi

I would like to know if there are plans to add support for some kind of rich text *within* Leo (i.e. not just for export purposes like Leo-to-RTF).

Thanks

[Fidel Pérez]

You can change the editor suggested on leo when right clicking so it will open with any editor you want (notepad++ or any rich text editor) maybe that could help.

[dufriz]

On Mon, Aug 5, 2013 at 8:23 AM, Fidel Pérez <fidel...@gmail.com> wrote:

You can change the editor suggested on leo when right clicking so it will open with any editor you want (notepad++ or any rich text editor) maybe that could help.

Thanks, Fidel, but I am not sure that I fully understood your suggestion.
What I was asking was a way to have Leo itself (without any external program) support Rich Text. Since Leo is based on Qt, it should be technically possible, because Qt has no problems with rich text.

Please correct me if I am wrong, but as I see it Leo can currently support only text on the screen.
Is this text-only limitation of the program a strict policy of the developer?
I am asking because I need to know what to expect from future releases...

[Edward K. Ream]

On Sun, Aug 4, 2013 at 10:00 PM, <duf...@gmail.com> wrote:

I would like to know if there are plans to add support for some kind of rich text *within* Leo (i.e. not just for export purposes like Leo-to-RTF).

​This is an important question, and an ongoing one.

1. The viewrendered plugin already provides support for rich text using reStructuredText (rST): http://docutils.sourceforge.net/rst.html  This plugin also supports @image, @html, @movie, @networkx and @svg nodes.  All other nodes are assumed to contain rST markup. 

You can see the rendered version with <alt-x>vr.  To hide the viewrendered pane, do <alt-x>vr-hide.  The screenshot on Leo's home page came from an @svg node: the svg code is in the body pane on the left; the rendered result is in the vr pane on the right. Another node that would be good to view this way is the docstring for the viewrendered plugin in leoPlugins.leo, the node @file viewrendered.py--><< docstring >>

One could imagine supporting other kinds of renderings in the viewrendered pane, but I don't believe there are any requests for that at present. Indeed, rST is an excellent markup language: all of Leo's docs are created with rST.  I preview the docs in the vr pane, and create the docs themselves with the rst3 plugin and Sphinx: http://sphinx-doc.org/

2. googling qt rich text yields http://qt-project.org/doc/qt-4.8/demos-textedit.html.  This is not something that I would want to add to Leo directly: it would imply additions to Leo's body pane, along with associated new commands.  It might make a good plugin, but it would likely be a lot of work for little gain over rST rendered with the viewrendered plugin.

3. Leo is unlikely ever to support the Microsoft RTF format, unless Qt does so directly.

HTH.

Edward

[Jacob Peck]

On 8/5/2013 9:21 AM, Edward K. Ream wrote:

On Sun, Aug 4, 2013 at 10:00 PM, <duf...@gmail.com> wrote:

I would like to know if there are plans to add support for some kind of rich text *within* Leo (i.e. not just for export purposes like Leo-to-RTF).

This is an important question, and an ongoing one.

1. The viewrendered plugin already provides support for rich text using reStructuredText (rST): http://docutils.sourceforge.net/rst.html  This plugin also supports @image, @html, @movie, @networkx and @svg nodes.  All other nodes are assumed to contain rST markup. 

You can see the rendered version with <alt-x>vr.  To hide the viewrendered pane, do <alt-x>vr-hide.  The screenshot on Leo's home page came from an @svg node: the svg code is in the body pane on the left; the rendered result is in the vr pane on the right. Another node that would be good to view this way is the docstring for the viewrendered plugin in leoPlugins.leo, the node @file viewrendered.py--><< docstring >>

One could imagine supporting other kinds of renderings in the viewrendered pane, but I don't believe there are any requests for that at present. Indeed, rST is an excellent markup language: all of Leo's docs are created with rST.  I preview the docs in the vr pane, and create the docs themselves with the rst3 plugin and Sphinx: http://sphinx-doc.org/

Additionally, the viewrendered plugin supports markdown processing and rendering with @md nodes.  This requires the 'markdown' module to be installed.

2. googling qt rich text yields http://qt-project.org/doc/qt-4.8/demos-textedit.html.  This is not something that I would want to add to Leo directly: it would imply additions to Leo's body pane, along with associated new commands.  It might make a good plugin, but it would likely be a lot of work for little gain over rST rendered with the viewrendered plugin.

3. Leo is unlikely ever to support the Microsoft RTF format, unless Qt does so directly.

HTH.

Edward

--
You received this message because you are subscribed to the Google Groups "leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+...@googlegroups.com.
To post to this group, send email to leo-e...@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Edward K. Ream]

On Mon, Aug 5, 2013 at 8:27 AM, Jacob Peck <gates...@gmail.com> wrote:

 

Additionally, the viewrendered plugin supports markdown processing and rendering with @md nodes.  This requires the 'markdown' module to be installed.

​I didn't know that ;-)  I'll update the opening words of the docstring to emphasize that the plugin can render both markdown and rST.

Edward

[Edward K. Ream]

On Mon, Aug 5, 2013 at 8:30 AM, Edward K. Ream <edre...@gmail.com> wrote:

​> ​

I'll update the opening words of the docstring to emphasize that the plugin can render both markdown and rST

​.

Done at rev 5852.

EKR​

​

[dufriz]

Thanks for the clarification.
From what you wrote, I take it that no form of rich text support (whether Microsoft's RTF or otherwise) is going to be added *natively* to Leo (i.e. excluding plugins).
Of course, this is your choice as developers, but allow me to point out that this limits considerably the chances of Leo to compete with other applications such as Notecase and the like.

What I would love to see is a *native* implementation of some form of rich text (at the very least: font colors, sizes, italic, etc - that is, the basics) within Leo. Only then would I be willing to adopt Leo as my main production tool.
Having the export tools (to HTML and to RTF) are not good enough, because what I need is to be able to *see* the projected outcome visually on the screen, while I am working on it.

I think the question ultimately boils down to: do we want to keep Leo as a strictly (or 'mostly') programmer's tool, or should we be also looking at at wider range of uses, such as information storage (PIM and the like) and text production tool?

From what I understand, Leo has the potential of serving a wide range of purposes, and it is a pity to see its power restrained.
Just adding some (native) support for rich text, in whichever form, will be a great improvement.

I only hope that the developer does not fail to see how crucial is the point I am making, as it may determine the future success or failure of Leo.


---------------------------------------------

 

--
You received this message because you are subscribed to a topic in the Google Groups "leo-editor" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/leo-editor/uTjcqREs8qQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to leo-editor+...@googlegroups.com.

[Terry Brown]

I think the OP is looking for Leo to edit text with an interface like
this:
http://netdna.webdesignerdepot.com/uploads/2008/11/11_damn_small_rich_text_editor.jpg

I think Leo's users have been focused on plain text approaches like rst
and md. But I'm wondering if this might be fairly low hanging fruit,
because Qt serializes rich text as HTML.

So firstly, Fidel's approach could work as long as the external editor
called was an HTML editor. The Leo body window would just display the
raw HTML, and the view rendered window could display the rendered
version without invoking the external editor.

But secondly it would be an almost trivial plugin if we can find a PyQt
rich text editor. Trouble is, that seems to be harder than you'd
think, or at least it was last time this came up. It would need to be
cross platform and PyQt, as in Python, friendly. Qt offers this C++
starting point: http://qt-project.org/doc/qt-4.8/demos-textedit.html

Googling PyQt rich text editor doesn't throw any obvious candidates up.

Cheers -Terry

[Edward K. Ream]

On Mon, Aug 5, 2013 at 9:07 AM, dufriz <duf...@gmail.com> wrote:

From what you wrote, I take it that no form of rich text support (whether Microsoft's RTF or otherwise) is going to be added *natively* to Leo (i.e. excluding plugins).

​The distinction between plugin code and "native" code makes no difference in practice.  In fact viewrendered.py is a standard plugin that is already enabled in the @enabled-plugins node in leoSettings.leo.

What I would love to see is a *native* implementation of some form of rich text (at the very least: font colors, sizes, italic, etc - that is, the basics) within Leo.

​I think I understand what you mean.  The typical way is to have lots of formatting icons in the body text, as in most wysiwyg editors.  But that's not a high priority for Leo.
​

 

I think the question ultimately boils down to: do we want to keep Leo as a strictly (or 'mostly') programmer's tool, or should we be also looking at at wider range of uses, such as information storage (PIM and the like) and text production tool?

​Leo works really well as both a PIM and as a text production tool.  In fact, it is much more flexible than "what you see is *all* you get" editors.  True, you may have to adjust your notions of how to produce text, but you will have to do that for any high-performance text-production tool.

Edward

[Terry Brown]

On Mon, 5 Aug 2013 16:07:14 +0200
dufriz <duf...@gmail.com> wrote:

> Thanks for the clarification.
> >From what you wrote, I take it that no form of rich text support (whether
> Microsoft's RTF or otherwise) is going to be added *natively* to Leo (i.e.
> excluding plugins).
> Of course, this is your choice as developers, but allow me to point out
> that this limits considerably the chances of Leo to compete with other
> applications such as Notecase and the like.
>
> What I would love to see is a *native* implementation of some form of rich
> text (at the very least: font colors, sizes, italic, etc - that is, the
> basics) within Leo. Only then would I be willing to adopt Leo as my main
> production tool.
> Having the export tools (to HTML and to RTF) are not good enough, because
> what I need is to be able to *see* the projected outcome visually on the
> screen, while I am working on it.

Just a note that the `view rendered` plugin is a real time presentation
of the final output of rst, md, etc. But authoring is still in rst etc.

I think what you're looking for could be added to Leo quite simple *if*
there's a PyQt compatible Qt rich text editor out there somewhere, we
just haven't found one yet.

Cheers -Terry

[Edward K. Ream]

On Mon, Aug 5, 2013 at 9:19 AM, Terry Brown <terry_...@yahoo.com> wrote:

 

Qt offers this C++

​ ​

starting point: http://qt-project.org/doc/qt-4.8/demos-textedit.html

​Maybe this could be fed to c2py.

Edward

[Edward K. Ream]

On Monday, August 5, 2013 10:41:50 AM UTC-5, Edward K. Ream wrote:

On Mon, Aug 5, 2013 at 9:19 AM, Terry Brown wrote:

 

Qt offers this C++

​ ​

starting point: http://qt-project.org/doc/qt-4.8/demos-textedit.html

​Maybe this could be fed to c2py.

I'm going to do this now to see what happens...

EKR

[Edward K. Ream]

On Mon, Aug 5, 2013 at 8:29 PM, Edward K. Ream <edre...@gmail.com> wrote:
 

Maybe this could be fed to c2py.

I'm going to do this now to see what happens...

​I spent several pleasant hours converting the code to Python.  c2py did a surprisingly good job. The new code is in test.leo.

Here is the checkin log for rev 5858. 

QQQ
Added transliteration of code at http://qt-project.org/doc/qt-4.8/demos-textedit.html to python.

Initial code created by c-to-python command, with much hand munging.

This commit is for backup only. More work is needed before the code will even compile as Python, much less run.

Much of the code will go away when/if it ever makes it into the Leo code base.

QQQ

The business end of the code is surprisingly simple.  Indeed, much of the code just sets up menus, and all but the formatting menus already exist in Leo, and so are of no real importance.

The larger questions relate to how this code will fit into the Leo world.  Otoh, those questions are a bit premature: let's see what the code actually does first.

Edward

[Ville M. Vainio]

There is a rich tect editor "demo" in stickynotes plugin.

You received this message because you are subscribed to the Google Groups "leo-editor" group.

To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+...@googlegroups.com.

[Edward K. Ream]

On Tue, Aug 6, 2013 at 2:33 AM, Ville M. Vainio <viva...@gmail.com> wrote:

There is a rich

​text ​

editor "demo" in stickynotes plugin.

​I didn't know that ;-)

When I awoke this morning, I realized what the important part of the code is, for both the Qt demo or Ville's demo.  It's saving/restoring the formatting data!

For the Qt demo, the save done in the fileSave method::

    write = QTextDocumentWriter(self.fileName)
    success = writer.write(self.textEdit.document())

Note that the textEdit ivar is a QTextEdit.

The restore is done in the load method::

    data = file.readAll()
    codec = Qt.codecForHtml(data)
    s = codec.toUnicode(data)
    if Qt.mightBeRichText(s):
        self.textEdit.setHtml(s)
     else:
        s = QString.fromLocal8Bit(data)
        self.textEdit.setPlainText(s)

In Ville's demo, the save is done in the focusout method, defined in stickynoter_f::

    def focusout():
        ...
        v.b = nf.toPlainText()
        ...

And the restore is done in the focusin method:

def focusin():
    ...
    if v.b != nf.toPlainText():   
        nf.setPlainText(v.b)
    ...

This code doesn't look like it will remember formatting, but that's no big deal.  We can just write the data to a uA (v.u) using the same code as Qt demo.

In short, there now appears a straightforward route to using a typical gui to create rich text!

Edward

P.S. At present, I see the following problems with the stickynotesr command in the stickynotes plugin, on both Ubuntu and Windows 7.  These are not serious...

1. The rich text actions (menu items), defined in the SimpleRichText class, are not visible in the popup editor.

2. The text is rendered as html, which means that line breaks disappear.

Also, the stickynote-new command crashes ;-)

EKR

[Terry Brown]

Seems to me that the problem with rich text editing in Leo is not how
to manage rich text, but the lack of a pure Python rich text editor
*GUI* for Qt. Since Qt serializes rich text as HTML it can be treated
as body text within Leo's data model.

What we're looking for, and, as far as I can see, what does not exist,
is a widget with the controls in the attached screen snip.

Sure, one could be built, but that seems like so much re-invention of
the wheel. Ok, so you get bold, italics, and font selection working,
and then someone wants a table editor. Rich text editors have table
editors... where does it end?

Also, I'd make integration of Leo's key handling and other commands
with the rich text editor a low priority / down the road objective - I
think if people want a rich text editor, they want a rich text editor,
one that behaves like all the others they've used.

So - amusing thought - could we use an embedded web browser, Qt's
webkit or whatever, to access something like
http://www.tinymce.com/index.php :-) ?
(note, that's not a screen shot, that's an editor on the homepage)

Cheers -Terry

[Edward K. Ream]

On Tue, Aug 6, 2013 at 8:14 AM, Terry Brown <terry_...@yahoo.com> wrote:

​> ​

Sure,

​[a widget] could be built, but that seems like so much re-invention of

the wheel.  Ok, so you get bold, italics, and font selection working,
and then someone wants a table editor.  Rich text editors have table
editors... where does it end?

​I agree.​

​> ​

Also, I'd make integration of Leo's key handling and other commands
with the rich text editor a low priority / down the road objective - I
think if people want a rich text editor, they want a rich text editor,
one that behaves like all the others they've used.

​I agree.

Your remarks are consistent with the new thread, "Design questions re rich text edit".  My present opinion is that adding rich text capabilities to Leo will make it more complex without anything like a corresponding benefit.  And it will distract the core developers from much more interesting and important work.

Edward

[Steve Litt]

On Mon, 5 Aug 2013 16:07:14 +0200
dufriz <duf...@gmail.com> wrote:

> Thanks for the clarification.
> From what you wrote, I take it that no form of rich text support
> (whether Microsoft's RTF or otherwise) is going to be added
> *natively* to Leo (i.e. excluding plugins).
> Of course, this is your choice as developers, but allow me to point
> out that this limits considerably the chances of Leo to compete with
> other applications such as Notecase and the like.
>
> What I would love to see is a *native* implementation of some form of
> rich text (at the very least: font colors, sizes, italic, etc - that
> is, the basics) within Leo. Only then would I be willing to adopt Leo
> as my main production tool.

I don't get it. Everything I've ever seen tells me that RTF is an
almost-opaque text format whose only real asset is it's the one way
incompatible MSOffice versions can work on each others' content.

When you say "main production tool" you don't say what you're
producing, but I think if that something is a book, website, ePub, or
the like, you're much better off having HTML or XHTML or maybe LaTeX as
the transitional file format. MSOffice isn't an optimal print-book/PDF
producer, and as far as I know, it's an outright lousy HTML producer.

> Having the export tools (to HTML and to RTF) are not good enough,
> because what I need is to be able to *see* the projected outcome
> visually on the screen, while I am working on it.

Like you, I've always favored WYSIWYG myself, when it came to book
writing and web page development. Others don't understand my
motivation, but I found it sped up authoring. However, this might not
be as important now that Firefox sports its Auto-Reload addon and now
that computer screens are a lot wider than they are tall. For instance,
I write the Bluefish HTML tag editor (definitely not WYSIWYG) on the
right, and Firefox with the addon on the left, and every time I save in
Bluefish, Firefox updates. It's very much like WYSIWYG authoring.

I couldn't find out whether Leo exports XHTML, but if it does, that's
perfect. Every time you export you can see it in Firefox. Better yet, I
believe that if you do styles-based authoring, and only styles-based
authoring, it would be pretty easy to write a Python program to convert
XHTML to LaTeX, from which you can get very well formatted PDFs.

Like I said, I don't know what you're producing, but I don't know of
anything that's optimally produced by RTF.

On a slightly different subject, several people have mentioned Leo
working with reStructured Text and Markdown as a substitute for it
working with RTF. That wouldn't be my opinion, for the simple reason
that, as far as I know, neither of those is styles-based. By
styles-based, I mean that appearances in the finished document are
determined *solely* by the style applied to text elements, and which
style you apply to a text element is *solely* determined by what the
text represents in the document (I could start throwing around the word
"semantically" here, but everyone has a different definition of that
word and won't admit it).

Anyway, having a style for emphasized text is nowhere near good enough.
You could need one for a loud voice type of thing, another for words
being defined, another reserved for commandments in the Ten
Commandments, another one for optional types of Medicare coverage, and
another for each of several kindergarten classes. The fact that, *right
now*, each of these things happens to convert to an appearance of
italics, does not make them in any other way the same, and to try to do
so would do serious harm when you try to convert your work to different
formats (ePub, for instance). Once you convert from styles to
appearances and throw away the styles, you lose your ability to change
elements of one style but not another. Styles-based authoring is where
all appearance is defined *only* in style definitions (CSS, LaTeX
layout file, MSOffice styles, etc), and the only metadata applied to
text elements is the styles applied to those elements.

Leo has clones and Leo nodes can have attributes, so I'm pretty sure
Leo can easily do styles-based authoring. And if all appearances are
applied by style alone, it's pretty darn easy to write Python scripts
to convert between XHTML and LaTeX, etc. And a script could be run to
update the final format, either upon save, or on time intervals. If you
were running Linux, it would be trivial for you to use inotifywait to
keep your output formula visible and up to date. I don't know what the
Linux equivalent would be.

Which leads to the final question: Are any of you writing books in Leo?

Thanks,

SteveT

Steve Litt * http://www.troubleshooters.com/
Troubleshooting Training * Human Performance

[gatesphere]

Just to touch on the conversion thing - Pandoc is fantastic for that
sort of thing. Also, markdown and rst are styled, or can be, because
the rendering converts them to html, which can have a css sheet embedded
in it. I couldn't give you the code to do so, but it's very possible.

-->Jake

[Terry Brown]

On Tue, 6 Aug 2013 19:29:58 -0400
Steve Litt <sl...@troubleshooters.com> wrote:

> On Mon, 5 Aug 2013 16:07:14 +0200
> dufriz <duf...@gmail.com> wrote:
>
> > Thanks for the clarification.
> > From what you wrote, I take it that no form of rich text support
> > (whether Microsoft's RTF or otherwise) is going to be added
> > *natively* to Leo (i.e. excluding plugins).
> > Of course, this is your choice as developers, but allow me to point
> > out that this limits considerably the chances of Leo to compete with
> > other applications such as Notecase and the like.
> >
> > What I would love to see is a *native* implementation of some form of
> > rich text (at the very least: font colors, sizes, italic, etc - that
> > is, the basics) within Leo. Only then would I be willing to adopt Leo
> > as my main production tool.
>
> I don't get it. Everything I've ever seen tells me that RTF is an
> almost-opaque text format whose only real asset is it's the one way
> incompatible MSOffice versions can work on each others' content.

I think the term "rich text" is being used informally to mean "text
with bold / italic / color / bullet lists / etc." edited in a wysiwyg
way. The only file format being considered is HTML.

> that computer screens are a lot wider than they are tall. For instance,
> I write the Bluefish HTML tag editor (definitely not WYSIWYG) on the
> right, and Firefox with the addon on the left, and every time I save in
> Bluefish, Firefox updates. It's very much like WYSIWYG authoring.

Writing rst with the view rendered plugin works the same way.

> I couldn't find out whether Leo exports XHTML, but if it does, that's
> perfect. Every time you export you can see it in Firefox. Better yet, I
> believe that if you do styles-based authoring, and only styles-based
> authoring, it would be pretty easy to write a Python program to convert
> XHTML to LaTeX, from which you can get very well formatted PDFs.
>
> Like I said, I don't know what you're producing, but I don't know of
> anything that's optimally produced by RTF.
>
> On a slightly different subject, several people have mentioned Leo
> working with reStructured Text and Markdown as a substitute for it

rst does support what you're calling style based authoring, you can
define roles:

.. role:: litt_style

And then the :litt_style:`wheel` fell off!

yields

<p>And then the <span class="litt-style">wheel</span> fell off!</p>

when converted to HTML, or

And then the \DUrole{litt-style}{wheel} fell off!

when converted to LaTeX. In both cases you'd need to define what the
role means, in CSS and LaTeX.

I'd use something like rst or LaTeX rather than "rich text" myself, I'm
fine with *important* things like /italicized text/ being indicated
with asterisks and slashes. But rich text could be quite useful, if it
can be done using other tools.

And yes, if I was writing a book, I'd definitely use Leo, but I'm
not :-)

Cheers -Terry

[duf...@gmail.com]

On Wednesday, August 7, 2013 5:16:09 AM UTC+2, Terry wrote:

I think the term "rich text" is being used informally to mean "text
with bold / italic / color / bullet lists / etc." edited in a wysiwyg
way.  The only file format being considered is HTML.

Yes, actually that is the way I meant "rich text" in my original post. Whether it's M$'s RTF or ant other similar format, I don't care. Even an HTML-like format would be nice.

The benefits of WYSIWYG should not be overlooked, I believe.

WYSIWYG is useful not only for seeing what the output will be, but also for having the stored info accessible in an immediate visual way. That is, even when you don't need to print it out or to export it. A PIM-oriented use of Leo will greatly benefit from a rich text format, because a lot of the text that you store will need to be underlined, highlighted, etc. Another valuable text format is the strikethrough.
All these text formats, which are a given in the world of modern computing, do have real benefits. It's not just a matter of wanting rich text for using fancy fonts...

Cheers

 

[Steve Litt]

On Tue, 06 Aug 2013 22:50:27 -0400
gatesphere <gates...@gmail.com> wrote:

> Just to touch on the conversion thing - Pandoc is fantastic for that
> sort of thing. Also, markdown and rst are styled, or can be, because
> the rendering converts them to html, which can have a css sheet
> embedded in it. I couldn't give you the code to do so, but it's very
> possible.
>
> -->Jake

Hi Jake,

I just want to make sure I understand you correctly. Are you saying
that in markdown or rst, I could create a style called "myemph", and
apply it to pieces of text, and when it gets rendered I'll have
something to the effect of <span class="myemph">text to be
emphasized</span>, and that if I have another style called
"shoutparagraph", I could apply that to whole paragraph type entities,
and it would render to <p class="shoutparagraph">lots of stuff</p>?

[Steve Litt]

On Tue, 6 Aug 2013 22:16:09 -0500
Terry Brown <terry_...@yahoo.com> wrote:

> On Tue, 6 Aug 2013 19:29:58 -0400
> Steve Litt <sl...@troubleshooters.com> wrote:

> > I don't get it. Everything I've ever seen tells me that RTF is an
> > almost-opaque text format whose only real asset is it's the one way
> > incompatible MSOffice versions can work on each others' content.
>
> I think the term "rich text" is being used informally to mean "text
> with bold / italic / color / bullet lists / etc." edited in a wysiwyg
> way. The only file format being considered is HTML.

In that case I withdraw my comment about rich text. I was thinking of:
{\rtf1\ansi{\fonttbl\f0\fswiss Helvetica;}\f0\pard
I can't read this garbage! {\b bold} text.\par
}

[clip]

> rst does support what you're calling style based authoring, you can
> define roles:
>
> .. role:: litt_style
>
> And then the :litt_style:`wheel` fell off!
>
> yields
>
> <p>And then the <span class="litt-style">wheel</span> fell
> off!</p>
>
> when converted to HTML, or
>
> And then the \DUrole{litt-style}{wheel} fell off!
>
> when converted to LaTeX. In both cases you'd need to define what the
> role means, in CSS and LaTeX.

I didn't know that. I'll give rst and Markdown another look.

> I'd use something like rst or LaTeX rather than "rich text" myself,
> I'm fine with *important* things like /italicized text/ being
> indicated with asterisks and slashes. But rich text could be quite
> useful, if it can be done using other tools.
>
> And yes, if I was writing a book, I'd definitely use Leo, but I'm
> not :-)

First chance I get, I'll evaluate Leo as a book authoring tool. HTML
and XHTML are pretty good, and LaTeX is good if ePub/Mobi/Kindle/iPad
aren't in your list of targets, but it looks to me like Leo might be
able to accommodate all of that plus a lot of metadata that wouldn't
appear in the finished book.

Thanks

[Jacob Peck]

Well, it looks like RST has support for that. Not markdown, I don't
think, though a preprocessing extension could be fairly simple.

-->Jake

[Jacob Peck]

Correction, the python markdown package, which is what Leo uses for
markdown rendering, has support for that style, calling them
"admonitions". http://pythonhosted.org/Markdown/extensions/admonition.html

I need to make a markdown plugin for Leo, akin to the RST plugin(s), to
support exports, etc. At the moment, I use a button to export html from
my @md nodes, but that's not as clean as it could be.

-->Jake