Re: Leo 5.4b1 coming soon. Please test

['tfer' via leo-editor]

git pull complains that stderr.txt and or stdout.txt can't be merged.  I 
think these files might be due to the pythonw.exe fix.  Anyway, I think 
that these need to be added to .gitignore

Tom

On Wednesday, September 21, 2016 at 12:01:00 PM UTC-4, Edward K. Ream wrote:
>
> The only remaining bug on the list is #304 
> , which is annoying 
> nit that applies only to PyQt5 on Windows.
>
> Expect Leo 5.4b1 in about a week.  There is no hurry whatever.  I'll be 
> adding enhancements in the meantime.  
>
> Which enhancements find their way into 5.4 remains to be seen.  If there 
> are any you would especially like, let me know.  Limit: one per customer.
>
> 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.

Re: Proposal: abandon #303 and VR3

[lewis]

I just ran last commit *3f0d2ce*, running vr2 and PyQt5 to test the new 
warnings:










*Leo Log WindowLeo 5.4-devel, build 20160722143100, Fri, Jul 22, 2016  
2:31:00 PMGit repo info: branch = master, commit = 3f0d2ce1acd8Python 
3.5.2, PyQt version 5.7.0Windows 10 AMD64 (build 10.0.14393) SP0The 
viewrendered2 plugin is not compatible with PyQt5loadOnePlugin: can not 
load enabled plugin: leo.plugins.viewrendered2reading: 
N:\leo\DServe_Eff_Filters.leoread outline in 0.05 secondsviewrendered 
plugin loaded.*

Leo successfully reports the that viewrendered2 doesn't get on well with 
PyQt5, and proceeds to load viewrendered plugin. All the unpleasant errors 
are gone.
This is very neat!

Thanks
Lewis


On Thursday, 22 September 2016 20:52:17 UTC+10, Edward K. Ream wrote:
>
> ​​
> The plain fact of the matter is that I have made more progress on 
> improving vr in the last day or so than in the previous year.  Why?  
> Because I simply focused on vr.
> [snip]
> Better, simply run vr2 to see the new features it offers.
>

-- 
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.

Re: Proposal: abandon #303 and VR3

[Edward K. Ream]

On Wednesday, September 21, 2016 at 3:45:44 PM UTC-5, Edward K. Ream wrote:

> I'm having second thoughts about the wisdom of merging VR and VR2 into VR3

As mentioned just now in a comment to #303 
, there is a much 
easier way to do the merge.  Just add some commands to the vr2 plugin, 
*without* using QWebView or any other part of the VR2 gui.

I should have thought of this earlier.  Today's workarounds of Qt5 troubles 
shows that QTextBrowser can do enough to emulate QWebView.

Indeed, given the problems with QWebView, it would seem natural to use 
QTextBrowser for the bigdash plugin as well.  Perhaps QWebView should be 
deprecated for the time being.

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.

Re: Is anyone else seeing cache warnings on Windows 10 with PyQt5?

[Edward K. Ream]

On Thursday, September 22, 2016 at 9:43:29 AM UTC-5, Edward K. Ream wrote:
>
> #304  describes this 
> problem.  It's bugging me, and there is no obvious solution.
>

Rev 69c3201 

 
is a better workaround. It leaves leoQt.py unchanged. The viewrendered.py 
and bigdash.py plugins now use QTextBrowser widgets instead of QWebView 
widgets when using PyQt5 on Windows.

Apparently, instantiating a QWebView holds the cache open. The workaround 
degrades the vr and bigdash plugins, but imo that is preferable to the 
messages appearing in the console.

This was the last known bug in Leo! I'll be working on preparing Leo 5.4b1 
for distribution next.

EKR

-- 
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.

Re: Is anyone else seeing cache warnings on Windows 10 with PyQt5?

[Edward K. Ream]

On Thursday, September 22, 2016 at 9:43:29 AM UTC-5, Edward K. Ream wrote:
>
> #304  describes this 
> problem.  It's bugging me, and there is no obvious solution.
>

Progress.  The warnings happen only if a version of Leo running PyQt5 is 
*already 
open*.  Apparently, PyQt5 is holding the Python cache open even when Leo is 
not active.

So the workaround is to open leoPy.leo with Python 2, and do testing with 
Python 3.  Not great, but much better than seeing the dashed warnings.

EKR

-- 
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.

Is anyone else seeing cache warnings on Windows 10 with PyQt5?

[Edward K. Ream]

#304  describes this 
problem.  It's bugging me, and there is no obvious solution.

I'm wondering whether it could be a weird installation/settings issue on 
just my machine, or whether others are affected.  If so, please respond 
here.

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.

Re: importer proposal

[Edward K. Ream]

On Thursday, September 22, 2016 at 6:30:04 AM UTC-5, Edward K. Ream wrote:

> To summarize, your proposal amounts to a request to redesign or refactor 
basescanner.py.

In fact, the BaseScanner code already has three phases, as shown by the 
tree structure of the BaseScanner class's code. The top levels of the 
phases are:

1. The bs.scan method, in Parsing, called from bs.run.
2. The bs.put methods, in Code generation, called from bs.scan and helpers.
3. The bs.check method, in Checking, called from bs.run.

One could imagine separating these phases by passing dicts of information 
between them, but nothing much would change.  The code would still be 
exactly as complex.

The complications of the basescanner code are a *good* thing, imo.  They 
simplify the importers, as clearly shown by the C importer.

EKR

-- 
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.

Re: importer proposal

[Edward K. Ream]

​​
​​On Wed, Sep 21, 2016 at 11:11 AM, 'tfer' via leo-editor <
leo-editor@googlegroups.com> wrote:

There are always request for new importers or changes to existing
> importers, few people other than Edward have wrapped their mind around how
> to do this for themselves.  This is a proposal to make this easier for
> people to create their own importers or easily customize any importer to
> create nodes at whatever level of detail they want.
>

​This a very long reply, but I want to explain exactly why the present code
is as it is.

This would work by borrowing the Unix principles of making little programs
> that do one thing, then composing a chain of them to accomplish the task
> you want done.
>

​I am aware of this design pattern.  ​The present code uses a different
pattern, namely having individual importers/writers override base importer
and writer classes.​

The writer base class is relatively simple. Writing is much simpler than
reading.

The importer base class is complex for three distinct reasons:

1. Parsing is inherently a per-language process.  We could use a different
parsing tool for each language, but that will lead to duplicate code.  I
discuss parsing in greater detail below.

2. Given a proper parse of the language, splitting the code into separate
Leo nodes (what the importer calls code generation) is a tricky process.
We want to preserve line breaks and whitespace wherever possible.

3. We typically want to verify that the result of import will produce (when
written) the original import.  There is a separate (*extremely complex*)
phase that does this, based on several switches in the overridden importer
classes.

So yes, one could turn each of these areas of code into a separate process,
but the actual code would not change much.

Take a look at CScanner class in leo/plugins/importers/c.py.  It consists
only of a ctor that sets various switches.  All the real work is done in
leo/plugins/importers/basescanner.py.  There is *no way* to make the C
scanner simpler.

Imo, your proposal amounts to a request to refactor basescanner.py.
Perhaps that could be done, but I don't see any advantage to doing so.

 Each language would have its own default chain, but you would have the
> option of adding your own chains/parameters/programs in your files
> "settings" node for each language you want to override the defaults on.
>

​That's exactly the situation at present.  Each importer uses settings to
modify the operation of basescanner.py, but importers are free to override
various methods as needed.  For example, see importers/python.py.

Yes, the BaseScanner.Parsing methods are hairy.  But there is a reason: the
parsing code, especially the scan and scanHelper must preserve line breaks
and whitespace.  Traditional parsers don't do this.  They simply create a
parse tree.

I have lots of experience with Python's AST parse trees.  Annotating the
tree to show comments and whitespace is a big hole in the Python API. I
describe the workaround in this stack overflow page
.
As you can see, there are substantial difficulties involved.

But our problem is even harder: to create a *character-oriented* parser for
every imported language.  The present parsing code works, though it is ugly
behind the scenes.  Rather than using the base scanHelper method,
individual importers can override scanHelper.  That's a feasible approach,
and it may be that some importers actually do that, but it doesn't change
the overall situation.
​


> I imagine some of these tools would be general and then made specific to
> the language at hand by passing them things like a keyword list, regex's,
> and the like.  I'm not sure if this would need a intermediate format that
> gets turned into the nodes by a "nodeMaker" program at the end, (though
> this seems the likely scenario as the Unix approach is to keep things in
> text as long as possible), or if each program refines the parsing of nodes
> created by the previous program in the chain more directly.
>

​The tools already exist.  They are all the methods in basescanner.py.​


Python has support for this sort of thing in the "included batteries", the
> io module includes stuff to work with strings.  To make things look more
> Unix like their is pipetools:  https://pypi.python.org/pypi/pipetools.
>
​
To summarize, your proposal amounts to a request to redesign or refactor
basescanner.py.  I'm not going to do this, absent proof that the actual
problems to be solved are much easier than I know them to be :-)

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 

Re: Backspace key when editing headlines on Mac

[Edward K. Ream]

On Wed, Sep 21, 2016 at 6:54 PM, Ghostwriter <
michael.charles.mcc...@gmail.com> wrote:

When I try to use the backspace key on my Mac (labeled "delete") when
> editing a headline, it deletes the node rather than deleting the previous
> character in the headline. I've tried changing key codes in my personal
> settings, but to no avail. How can I change this?
>

​Please file a bug report about this.  There may be a workaround, but if so
I don't remember what it was.

EKR

-- 
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.

Re: Proposal: abandon #303 and VR3

[Edward K. Ream]

​​
On Wed, Sep 21, 2016 at 5:24 PM, lewis  wrote:

I was under the impression (possibly mistaken) that vr3 was the future and
> that vr + vr2 were headed for the attic.
>

​That was the original plan.  This proposal it an acknowledgement that this
plan wasn't working.

The plain fact of the matter is that I have made more progress on improving
vr in the last day or so than in the previous year.  Why?  Because I simply
focused on vr.

Merging vr and vr2 is a hard project. Perhaps a new kind of Leo tool would
help, but  I don't know what such a thing would be. It's in the back of my
mind...
​


> So now would be a good time to summarize the actual feature sets or
> differentiating features of vr, vr2 and vr3.
>

You can read the vr and vr2 docstrings to see the differences.  Better,
simply run vr2 to see the new features it offers.

More importantly in practice, vr is based on a QtWebKitWidgets.QWebView
(Qt5 terminology, per leoQt.py). vr2 is based on a
QtWebKitWidgets.QWebView().  At present, vr2 does not work with PyQt5.
Substantial porting would be required.

Updating the plugins documentation and http://leoeditor.com/plugins.
> html#viewrendered-py to keep users aware of PyQt5 issues would be helpful.
>

​True.  vr2 now refuses to run (and tells why) when PyQt5 is in effect.
​


> Terry made a proposal
>  to
> include python/Qt compatibility and maintenance status in the docstrings.
>

​That's a separate issue.  In practice, such standards are difficult to
maintain over time, even if somebody enforces them once.

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.

Backspace key when editing headlines on Mac

[Ghostwriter]

Hi,

When I try to use the backspace key on my Mac (labeled "delete") when 
editing a headline, it deletes the node rather than deleting the previous 
character in the headline. I've tried changing key codes in my personal 
settings, but to no avail. How can I change this? 

Thanks for your help.

-- 
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.