Re: I can't recommend black

2019-09-08 Thread Edward K. Ream
On Sun, Sep 8, 2019 at 12:48 AM rengel  wrote:

> My experience taught me never to work against a tool I don't have control
of. A couple of months down the road I tend to forget why I used this or
that workaround just to make the tool work.

Recall that my intention was to propose a pull request to the black devs.
That was the purpose of yesterday's studies. Alas, I was not able to make
any progress. Handling comments in an ast is inherently difficult.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAMF8tS3LwYW63jr9FuP5%2BsVOhbxWKHZdP-38ZuSSNtnF3Tg5iA%40mail.gmail.com.


About mass changes to Leo's code base

2019-09-08 Thread Edward K. Ream
I want to emphasize here that there is no great urgency to making any 
large-scale changes to Leo's code base.  There are much more important 
issues to attend to.  Having said this, here are my present plans:

1. I am happily converting to f-strings as I go along.

I probably will merge the fstring branch into devel, after at least one 
thorough review of the diffs before doing this.

I don't want to defer the decision much longer: it's inconvenient to be 
merging into long-lasting branches.

2. I have no intention of using black on Leo's code base.  Not now.  Not 
ever.

3. I have just begun work on #1266 
 (orange).

The new work contains a rewrite of the code that compares the "before" and 
"after" parse trees. It's much better than the previous code. I'll merge 
this into devel soon.

The rest of #1266 is experimental. I'll defer this project if it is going 
to take more than a few days.

*Summary*

I have gotten a bit sidetracked with code formatting issues.  I'll give 
myself a few more days to wrap things up.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/adce8cce-83d3-4351-abb3-e7c7f97b7f0e%40googlegroups.com.


Re: Second thoughts about f-strings

2019-09-08 Thread Matt Wilkie
Thank you for reporting on the variety in the to-be or not-to-be f-string 
landscape. This side by side comparison useful.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/2c98009f-da57-4b71-a216-2dee2e8ebc59%40googlegroups.com.


Re: Second thoughts about f-strings

2019-09-08 Thread Edward K. Ream
​On Sun, Sep 8, 2019 at 2:52 PM Matt Wilkie  wrote:

> Thank you for reporting on the variety in the to-be or not-to-be f-string 
landscape. This side by side comparison useful.

​You're welcome.

I have only been using f-strings in my present work on orange.​  String 
concatenations are perfect for comparisons.  Examples:

# Example 1:
raise self.AstNotEqual(
f"node1: {node1}\n"
f"node2: {node2}")

# Example 2:
g.trace("COMPARE LIST ITEMS")
print(
f"list1: {node1}\n"
f"list2: {node2}")

The print statement in the second example preserves alignments.  Using just 
g.trace would not work as well.

My present plan is to merge the fstring branch into devel in a day or two.  
I'll feel free to revert to % strings where they seem clearer.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/c3f6e868-2396-4136-9627-e532192b5e2b%40googlegroups.com.


Re: Chris: cause of outline artifact?

2019-09-08 Thread Chris George
After extensive testing I have determined that my initial conclusions hold.

With all else being equal (this took some effort), if the python 
environment leois running under is native to the OS the stylesheet is 
flawless.

If leo is running under a venv of any flavor (including conda) the 
artifacts appear.

Changing the stylesheet while using the venv doesn't work. Gammaray doesn't 
help. As far as it is concerned it is the same object with the same 
properties. 


I am stumped.


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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/ee1cad83-d9f7-4fa2-b6e8-da4186bf5c37%40googlegroups.com.


Re: Chris: cause of outline artifact?

2019-09-08 Thread Terry Brown
On Sun, 8 Sep 2019 13:25:23 -0700 (PDT)
Chris George  wrote:

> After extensive testing I have determined that my initial conclusions
> hold.
> 
> With all else being equal (this took some effort), if the python 
> environment leois running under is native to the OS the stylesheet is 
> flawless.
> 
> If leo is running under a venv of any flavor (including conda) the 
> artifacts appear.
> 
> Changing the stylesheet while using the venv doesn't work. Gammaray
> doesn't help. As far as it is concerned it is the same object with
> the same properties. 
> 
> I am stumped.

Could something else like screen dpi determination be different?

Can you run the OS native version (partially) in the venv?  Perhaps
just get Python from the venv not the Qt stuff - you'd have to tell the
venv to use system libs.  Then just PyQt from the venv not Python / Qt,
etc. if that pattern makes sense.

Cheers -Terr

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/20190908154933.1e63e7fe%40lakeview.


Re: Chris: cause of outline artifact?

2019-09-08 Thread Matt Wilkie

>
> With all else being equal (this took some effort), if the python 
> environment leois running under is native to the OS the stylesheet is 
> flawless. If leo is running under a venv of any flavor (including conda) 
> the artifacts appear.
>

Sounds like time to reach out to a wider community, though I don't know 
which one. And they'll likely need a Hello World kind of example to play 
with; no idea how hard that might be.

-matt

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/56575155-4c17-4208-a49a-374671c1ee93%40googlegroups.com.


Re: Chris: cause of outline artifact?

2019-09-08 Thread Chris George
I am taking a break from this for a bit. 

In the meantime I will run Leo "native" under Neon with Python 3.6.8 and 
PyQt 5.12.3.

Chris

On Sunday, September 8, 2019 at 1:56:11 PM UTC-7, Matt Wilkie wrote:
>
> With all else being equal (this took some effort), if the python 
>> environment leois running under is native to the OS the stylesheet is 
>> flawless. If leo is running under a venv of any flavor (including conda) 
>> the artifacts appear.
>>
>
> Sounds like time to reach out to a wider community, though I don't know 
> which one. And they'll likely need a Hello World kind of example to play 
> with; no idea how hard that might be.
>
> -matt
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/9a824218-d868-419f-b879-1b286088a0a2%40googlegroups.com.


Re: #1266: Orange is the new black :-)

2019-09-08 Thread Edward K. Ream

On Saturday, September 7, 2019 at 5:04:27 PM UTC-5, Edward K. Ream wrote:

I've just upgraded #1266 
> . This is the *orange 
> project*, to be done in the orange branch.
>

*Progress report*

- It took about 20 minutes to come up to speed on the code.  It is as I 
remembered it.

- The beautifier can now split long lines!
  The next project will be to join following lines, if they haven't just 
been split.

- I rewrote the code that checks two parse trees for equality.
  A big simplification: it raises AstNotEqual when mismatches are detected.
  Unlike the old code, it is unlikely ever to hang.

*Summary*

Progress has been more rapid than anticipated.  I'll spend a day or two 
more on this project.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/88297acf-8a85-4bfb-9f46-33033740192c%40googlegroups.com.