On Wed, 7 Mar 2018 18:18:21 -0800 (PST)
"Edward K. Ream" <edream...@gmail.com> wrote:

> ​On Wed, Mar 7, 2018 at 6:30 PM, Terry Brown <terrynbr...@gmail.com>
> wrote:
> 
> > I really don't understand the disconnect here. I want to log a
> > warning to   
> the log pane.
> ​​
> At present, Leo has the following definitions in leoGlobals​:
> 
> def error(*args, **keys):
>    g.es_print(color=g.actualColor('red'), *args, **keys)
> 
> def note(*args, **keys):
>    g.es_print(color=g.actualColor('black'), *args, **keys)
> 
> def warning(*args, **keys):
>    g.es_print(color=g.actualColor('blue'), *args, **keys)
> 
> They can be changed to:
> 
> def error(*args, **keys):
>    g.es_print(color=g.actualColor('error'), *args, **keys)
> 
> def note(*args, **keys):
>    g.es_print(color=g.actualColor('note'), *args, **keys)
> 
> def warning(*args, **keys):
>    g.es_print(color=g.actualColor('warning'), *args, **keys)
> 
> And this is probably *all *that needs to happen.
> 
> So please calm down and read the following carefully.
> 
> > Ideally, it would be
> >  g.log("Warning, keep away from children", type="warning")
> > or
> >  g.warning("Warning, keep away from children")
> > (I prefer the former)  
> 
> g.log is a completely separate function.​ It should not be changed.

Digression, sort of.  Yes it's completely separate.  It appears to
be used exactly zero times in the code base (grep -ri \\bg\\.log\\b *).
It's completely separate, but the same issue - wanting to use
meaningful, memorable names for things.  You could say that "hello
world" in "Leo" is:

    g.es("Hello world")

Wouldn't

    g.log("Hello world")

be so much easier to remember?  I won't pursue it, but it's certainly a
change I think worthwhile.

> > Instead, for historical reasons, we have
> > g.es <http://g.es/>("Warning, keep away from children",
> > color="warning")  
> 
> There is no such code in Leo's core. There is color="red" or
> color="blue".

Ok, but my point was that writing color="warning" is clearly an
incomplete migration from legacy code, and turns out to be exactly what
you suggest as part of the solution in your next email:

> def warning(*args, **keys):
>     g.es_print(color='warning', *args, **keys)

Admittedly as an implementation detail of warning() it matters less,
but I think you're saying that's also what you'd write if you wanted a
warning colored g.es() call.
 
> In Leo's core all calls to g.es are exactly as they were before. Now, 
> however, you could write color="warning" or color="error".
> 
> > at least until recently, but now apparently we're supposed to use
> > g.es <http://g.es/>("Warning, keep away from children",
> > color="blue")  
> 
> You have the situation completely backwards. color="blue" is the
> *legacy*. You are no longer "supposed to" use it. You can use
> anything you like.

Until recent changes, these settings worked:

@color log_text_foreground_color = #93a1a1
@color log_text_background_color = #073642
@color log_error_color = #dc322f
@color log_warning_color = #268bd2

now they don't, and it seems instead we have to use

@color log_blue_color = yellow etc.

    grep -ri g\\.es.*color=.blue. *

hits 90 times, and 

    grep -ri g\\.warning *

hits 127 times, so it seems we need both log_blue_color and
log_warning_color.  In e4e0b81ad91e

g.error('error')
g.warning('warning')

and

g.blue('blue')
g.red('red')

give different results, seeing the first uses log_error_color /
log_warning_color and the second uses log_red_color (or red as a
default) and log_blue_color or blue as a default.

I assume that's not intended.

Likewise

g.es('test', color='red')
g.es('test', color='blue')
g.es('test', color='error')
g.es('test', color='warning')

give different results, so all the g.es(...color='blue') calls are
different from the g.warning() calls.

In terms of what settings we have to define, we can't "use  anything
you like", we have to use what the core uses, which is currently two
different things, inconsistently.

To me this just seems like the ideal time to clean things up, while all
the theme settings are freshly reviewed, let's rename everything by
role instead of by color.  At least that's what I'd do.

Cheers -Terry

> > So we (a) need to know that 'blue' is the arbitrary color code
> > for   
> warnings, and (b) that this will print a message in the log in a
> theme defined color that may not be any kind of blue.
> 
> This was what you were "supposed to know" previously. Nothing in
> Leo's core has changed.​ 
> 
> > So we're going backwards.  
> 
> No. You have it backwards.​ 
> 
> *Summary*
> 
> Changing calls to g.es in Leo's core is conceivable, but not
> necessary.
> 
> Changing the definitions of g.error, g.note and g.warning as
> described above would probably suffice, provided that themes define
> @color log_error/node/warning_color settings.
> 
> The new scheme increases our choices while allowing all legacy code
> to work as before.
> 
> 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+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Reply via email to