How to enable syntax highlight of "@language yaml"?

[Exaos Lee]

I imported yaml config file into leo, but no syntax highlight for yaml. How to enable it?
BTW, my YAML config file just contains content like python dict objects. Can I view them like the imported python source file? I mean, I can view keys in tree navigation.

[Edward K. Ream]

On Tue, Apr 24, 2012 at 12:37 PM, Exaos Lee <exao...@gmail.com> wrote:
> I imported yaml config file into leo, but no syntax highlight for yaml. How
> to enable it?

At present, Leo does not know how to color yaml. You can see this
because there is not file yaml.py in the leo/modes directory.

> BTW, my YAML config file just contains content like python dict objects. Can
I view them like the imported python source file? I mean, I can view keys in
tree navigation.

Leo does not know how to import yaml *data* either, although there is
experimental support for importing leo files represented in yaml.

Edward

[Exaos Lee]

在 2012年4月25日星期三UTC+8上午6时41分38秒，Edward K. Ream写道：

On Tue, Apr 24, 2012 at 12:37 PM, Exaos Lee <exao...@gmail.com> wrote:
> I imported yaml config file into leo, but no syntax highlight for yaml. How
> to enable it?

At present, Leo does not know how to color yaml.  You can see this
because there is not file yaml.py in the leo/modes directory.

I checked leo/modes and didn't found it. I found lua, d, ini, css, and many more. JSON and YAML are missing. Could I request the support of YAML? :-) Python supports yaml internally since 3.0.

[Edward K. Ream]

On Wed, Apr 25, 2012 at 3:28 AM, Exaos Lee <exao...@gmail.com> wrote:
> 在 2012年4月25日星期三UTC+8上午6时41分38秒，Edward K. Ream写道：

> Could I request the support of YAML? :-)
> Python supports yaml internally since 3.0.

Sure. If you like, you could file an official wish-list bug.

As I mentioned previously, there are really two separate kinds of support:

1. syntax coloring

It's not clear what should be done. Almost all of yaml is key: value
pairs. It's not obvious to me what kind of coloring should be done.

2. importing

I found this in a to-do item:

QQQ
Import/Export to yaml
Need a good yaml parser first: I don't want to write another parser by hand.
QQQ

Googling "python yaml" yields: http://pyyaml.org/
which claims to be a "YAML parser and emitter for Python."

So this looks like the way to go. In fact, a case can be made for
representing .leo files as yaml files rather than xml files. This
isn't urgent, and can't be done at all unless yaml does as good a job
of handling Unicode as does xml.

Edward

[Offray Vladimir Luna Cárdenas]

Hi,

Just retaking/expanding the discussion here.

I think that we need a better way to make syntax coloring easier for
Leo. I don't know which are the details in leo/modes but would be nice
to have some kind of compatibility layer to some syntax coloring files.
For example importing the 200plus languages (including yaml) of jEdit
would be handy (If I remember well, there is a relationship in this
aspect between jEdit and leo, but I don't remember which one). Being Leo
such a a versatile tool, wich is also code editor, having such
limitation on syntax coloring support is really annoying.

On the argument about support for yaml as a storage format, I have
talked about it in the past. Yaml is as good as XML handling unicode and
Leo could be version control system friendlier with a light markup
language. I think that IPython people made a smart decision using JSON
as a human readable format for their notebooks, instead of the
ugly/unreadable, popular and machine oriented XML. I can imagine myself
solving merging conflicts on a human readable JSON IPython Notebook, but
now I'm having problems trying to make sense of this:

http://mutabit.com/deltas/repos.fossil/doctorado-offray/artifact/2f7866207b0301f9b6b07a9a311b9b5bbe1a79a3

which is a Leo notebook having all my research notes for my phD (and now
I'm unable to open it). I started a new notebook for other related phD
related matters (I wont' give up on Leo "meta-cognitive" features for
writing!) and now that I'm starting to express my ideas in code may be I
can made a more vocal case for this kind of feature. Having human
readable plain text format for Leo metadata structure would be a way to
support the things discussed in the recent threads of a distributed Leo
(without going in the way of some ZODB o git storage options).

Cheers,

Offray

El 25/04/12 13:58, Edward K. Ream escribió:

[Terry Brown]

On Tue, 07 Jan 2014 14:37:17 -0500
Offray Vladimir Luna Cárdenas <off...@riseup.net> wrote:

> which is a Leo notebook having all my research notes for my phD (and now
> I'm unable to open it).

Which, as you probably know, is because it has merge conflict markers
in it? They would break JSON or YAML too. The VCS should let you undo
the merge attempt.

Yes, reading XML is unpleasant and best avoided, and YAML is easier to
read, but Leo's file format isn't really intended to be human
readable. If your content is in @auto or @file nodes in human readable
formats like .txt and .rst, reading the merge conflicts wouldn't be too
bad.

Cheers -Terry

[Offray Vladimir Luna Cárdenas]

Hi,

El 07/01/14 15:09, Terry Brown escribió:

> On Tue, 07 Jan 2014 14:37:17 -0500
> Offray Vladimir Luna Cárdenas <off...@riseup.net> wrote:
>
>> which is a Leo notebook having all my research notes for my phD (and now
>> I'm unable to open it).
>
> Which, as you probably know, is because it has merge conflict markers
> in it? They would break JSON or YAML too. The VCS should let you undo
> the merge attempt.
>

Well, thats was my idea. Going back on history until having a properly
readable version of Leo, and I still keep writing on Leo, with the
confidence of version control.

> Yes, reading XML is unpleasant and best avoided, and YAML is easier to
> read, but Leo's file format isn't really intended to be human
> readable. If your content is in @auto or @file nodes in human readable
> formats like .txt and .rst, reading the merge conflicts wouldn't be too
> bad.
>

Sure, reading the the flat output of Leo is not the problem and I'm
able to read it. Is Leo metastructure what I want to recover and where
flat output is just a "pale subproduct". Deep notes under @ignore-rst
that contain my annotations and are not part of the "surface" writing at
the end. I will be able to recover them, but I think that YAML is a
good way to have a human and machine friendly data serialization format
for Leo trees without sacrificing anything and a real good step towards
a distributed Leo. I will make some test and I will share them back.

Cheers,

Offray

[Edward K. Ream]

On Tue, Jan 7, 2014 at 1:37 PM, Offray Vladimir Luna Cárdenas <off...@riseup.net> wrote:

I think that we need a better way to make syntax coloring easier for Leo. I don't know which are the details in leo/modes but would be nice to have some kind of compatibility layer to some syntax coloring files. For example importing the 200plus languages (including yaml) of jEdit would be handy (If I remember well, there is a relationship in this aspect between jEdit and leo, but I don't remember which one). Being Leo such a a versatile tool, wich is also code editor, having such limitation on syntax coloring support is really annoying.

​The script jedit2py in leo/scripts/scripts.py (accessible via the File menu) converts a jEdit xml file to a .py file.

Edward​

[Juraj]

Hello,

I did import yaml.xml from jEdit and added it into self.language_delims_dict but I can't get Leo to syntax highlight it nor apply the options like tabwidth = 2 . Leo *does* load the file and modes/yaml.pyc is created but otherwise it does nothing nor outputs any error..

Tried both yaml.xml from jedit distribution: http://sourceforge.net/p/jedit/jEdit.bak/ci/master/tree/modes/yaml.xml?format=raw  and third party one: https://raw.githubusercontent.com/djspiewak/jedit-modes/master/yaml.xml without avail.

I believe this is same as original poster's problem, but discussion was derailed into using yaml as leo file format and whatnot. I only need syntax coloring for @file nodes, using @language yaml, nothing else. Does this work for anyone?


Juraj

[Edward K. Ream]

On Mon, Jul 28, 2014 at 12:15 PM, Juraj <rin...@gmail.com> wrote:

> I did import yaml.xml from jEdit and added it into self.language_delims_dict
> but I can't get Leo to syntax highlight it nor apply the options like
> tabwidth = 2 . Leo *does* load the file and modes/yaml.pyc is created but
> otherwise it does nothing nor outputs any error.

Did you create modes/yaml.py using the jEdit2py script in scripts.leo?
I'm guessing maybe you did, since you mention modes/yaml.pyc...

This might be a good time to create the three language-description
dicts in leoApp.py using "plugin" descriptions in, say,
plugins/languages.

In the meantime, I'll attempt to support yaml myself.

Edward

[Juraj]

Yes, I did create modes/yaml.py using the jEdit2py script. Even verified my process by importing and testing pg-sql.xml from jEdit, which worked (colorized text in nodes with @language pg-sql).

So I suspect there's some yaml-specific bug in syntax highlighter.

Juraj

[Edward K. Ream]

On Mon, Jul 28, 2014 at 2:52 PM, Juraj <rin...@gmail.com> wrote:
> Yes, I did create modes/yaml.py using the jEdit2py script. Even verified my
> process by importing and testing pg-sql.xml from jEdit, which worked
> (colorized text in nodes with @language pg-sql).
>
> So I suspect there's some yaml-specific bug in syntax highlighter.

I looked at the alternative yaml.xml. There were a lot of regex's
there. Not sure whether that ever has been much tested.

Edward

[Edward K. Ream]

On Mon, Jul 28, 2014 at 3:31 PM, Edward K. Ream <edre...@gmail.com> wrote:

>> So I suspect there's some yaml-specific bug in syntax highlighter.
>
> I looked at the alternative yaml.xml. There were a lot of regex's
> there. Not sure whether that ever has been much tested.

Ha. It can't have been well tested. The problem became clear to me
as I was eating dinner ;-)

Many of the regex's in yaml.py start with \\s. The jEdit2py script
stupidly thinks that the lead-in character is a backslash, rather than
what \\s represents, namely [ \t\n\r\f\v] As a result, the regex
pattern matchers never succeed because they are only called with a
backslash as the first character!

The fix is at rev 5905eeb...

The fix disables the entry for '\\' in rulesDict1, and adds entries
for ' ','\t' and '\n', with the same list as for '\\'. Now syntax
coloring appears to work.

Edward

[Juraj]

Thanks very much, it works now!

[Edward K. Ream]

On Tue, Jul 29, 2014 at 5:32 AM, Juraj <rin...@gmail.com> wrote:
> Thanks very much, it works now!

Thanks for the confirmation. I wasn't sure.

Edward