Syntax colorizer change for html

[Rob]

With all of the new work on themes, I loaded each one and all of them, for some unknown reason cause my syntax colorizer to not work on @language html. Before, tags would be blue and content text would be black. Now, everything is black. Also, if I choose one of the dark themes, the tag colors are also black against either dark gray or black background making them essentially invisible.

Unfortunately, in the process of trying the new themes, I deleted my old ones (they triggered some CSS errors, but otherwise worked fine). Now, I don't know how to get back there. Any ideas?

Rob...

PS The syntax colorizer works as expected on @language tex (the only other one I typically use).

[Chris George]

@theme Breeze Dark-->Settings for Leo Breeze
Dark-->Colors...-->Colors: Syntax coloring


In BreezeDark, for example, I adjusted the colours to my liking as
some were too dark for a dark theme. Go through both Colors: Defaults
and Colors: Leo constructs and fiddle until you get them where you
like them.


Chris

> --
> 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 https://groups.google.com/group/leo-editor.
> For more options, visit https://groups.google.com/d/optout.

[Rob]

I'm stumped!

After much experimenting, I find the following:

1. The Leo Light theme (copied from EKRLight.leo) is my favorite color palette. However, the html syntax color for tags is black (same as content color), not blue. I changed the @color markup_color = blue (also tried some hex values). That made no difference, the tags were still undifferentiated.
2. The BreezeDark theme also has the same problem with html tags. They're white, the same as content color. Also, changing the @color markup_color = blue (or other hex values) makes no difference.
3. The Leo Black Solarized theme is the only one that properly differentiates html tags. I looked, but cannot find which setting (or set of settings) makes it work for html tags where the others do not.

Besides the @color markup_color = ??? in the Syntax coloring node, I'm at a complete loss to find which setting to change. I don't really like the dark themes, but would like to know which setting in the light theme will fix the html syntax coloring problem.

Rob...

[Chris George]

Looking at a raw html file, it is all white except the urls are the color which is defined in "Leo constructs".

As soon as I add

@language html

to the node, the syntax coloring comes into play.

HTH,

Chris

[Rob]

That doesn't work for me. I always have the @language html in the root node of these files, and it still doesn't work. Wonder what's different about my system from yours. This screenshot of an example with Breeze Dark theme loaded:

[Chris George]

My system does exactly what yours does.

I loaded a large, complex html document. With no @language directive, all of the text except for urls is white. The urls are the color specified in the "Leo constructs" setting.

Add @language html.

Now the document pulls in coloring for other elements of the document. The only colors it is pulling from the syntax coloring settings are keyword2_color = #3875db, literal1_color = #002c00, comment1_color = #ff9a00. Or blue for = signs, green for anything inside "" and orange for comments. Mark-up is entirely ignored.

All other color settings are ignored completely. If it wasn't seeing the defined colors at all, we would be seeing the default colors from leo/modes/html.py which are mainly "red".

We are now officially beyond my pay grade.

Chris

[Terry Brown]

On Thu, 29 Mar 2018 12:29:14 -0700 (PDT)
Chris George <techn...@gmail.com> wrote:

> My system does exactly what yours does.

with @language html at top of node, and my personal old solarized dark
theme, I see the attached, just FYI.

Cheers -Terry

[Chris George]

I am becoming convinced that the syntax coloring settings don't work.

Before I changed the settings, I read as much as I could find about
it. My understanding is those language elements are tagged with the
keyboard1, keyword2 etc. and the colors themselves are set via the
syntax coloring settings.

The existing settings used one color for all four keywords, one color
for all four literals and one color for all four comments.

No matter what I do, I can't get the actual mark-up tags to be any
color but white.

Chris

[Rob]

So, the mystery is why does it work with some themes and not with others? After much searching, I can't find the 'missing link'.

Rob...

[Chris George]

Terry uses a custom theme of his own devising.

Do you use the syntax coloring settings Terry?

Chris

[Terry Brown]

On Thu, 29 Mar 2018 14:20:17 -0700
Chris George <techn...@gmail.com> wrote:

> Terry uses a custom theme of his own devising.

which is attached here is anyone wants to try it

https://github.com/leo-editor/leo-editor/issues/595#issuecomment-347030885

although I may have tweaked it to cope with the last changes to themes,
can't remember.

> Do you use the syntax coloring settings Terry?

Not sure what you mean - I've always thought syntax coloring settings
were separate from themes. Well, separate from stylesheets, I guess
they're part of a theme, but my theme just defines all the syntax
colors as various solarized colors. comment1, comment2, etc.

Cheers -Terry

[Edward K. Ream]

On Wed, Mar 28, 2018 at 2:08 PM, Rob <lar...@gmail.com> wrote:

With all of the new work on themes, I loaded each one and all of them, for some unknown reason cause my syntax colorizer to not work on @language html.

​I just had ​a similar problem when using Leo on a laptop for the first time in awhile.

It looks like the settings in a theme are tricky (impossible?) to override from myLeoSettings.leo. 

Instead, I changed a local copy of the theme itself, as follows:

1. Copied the theme (EKRDark.leo) file from leo/themes to ~/.leo/themes.

This should be enough to have Leo find that theme, instead of the copy in leo/themes.

Actually, though, I renamed the copy to be EKRDarkPortable.leo, and in EKRDarkPortable .leo changed:

@string theme-name = EKRDark

to:

@string theme-name = EKRDarkPortable

2. In myLeoSettings.leo I changed:

@string theme-name = EKRDark

to:

@string theme-name = EKRDarkPortable

After this, ~/.leo/themes/EKRDarkPortable.leo controls Leo's look and feel

3. I changed the font settings in EKRDarkPortable.leo and those became active on the next reload.

I suggest doing something similar, if you haven't done so already.

Edward

[Chris George]

Worked for me.

Just don't ask me to explain why. :-)

I totally removed the @theme node from myLeoSettings.leo. The only
theme related setting in myLeoSttings.leo is now @string theme-name =
BreezeDarkThemeLocal.


Changes to syntax coloring in the @theme settings in the local file
(~/.leo/themes/BreezeDarkThemeLocal) now work as intended.


This is a much better way of handling themes IMHO. Several personally
modified themes can exist in the local directory and can be easily
switched between by changing one string setting instead of
copy/pasting an entire tree and positioning it in the right place.

Chris

[Rob]

Thanks, Edward! I would not have thought of that solution. This now works for me.

Rob...

[Edward K. Ream]

On Fri, Mar 30, 2018 at 8:48 AM, Rob <lar...@gmail.com> wrote:

Thanks, Edward! I would not have thought of that solution. This now works for me.

​Glad to hear it.  It's on the list to document the interaction between theme .leo files and other settings files.

Edward

[Thomas Passin]

I've also had  a lot of problems adjusting colors in themes.  One thing I discovered is that the presence of the node
with headline "@data qt-gui-plugin-style-sheet" has font and color settings that make the desired changes when none of the other settings - the ones that are supposed to work - have an effect.

I copied mine from one in leoSettings and put it ahead of my @theme tree.  I don't know why this has any effect, since from its name I wouldn't think it would affect Leo's primary settings.   But it does on my system.

[Chris George]

Hi Thomas,

Which theme were you having trouble with?

The @data qt-gui-plugin-style-sheet node is created from the nodes
below in the tree.

There is a Qt bug (~=, see issue #485) that will stop Qt from
rendering everything after the first instance of this in the
stylesheet if you are using Qt 5.8 or newer. The workaround is to move
the individual widget styles using this construct to the very end of
the tree. This maintains backwards compatibility (Qt 5.7 and earlier)
while allowing people using Qt 5.8 or newer the ability to load the
entire stylesheet except for the offending widgets using ~=.

It took me a while to figure out what kept breaking the stylesheet.

Any styles below the first ~= will not be read in Qt >=5.8.

HTH,

Chris