Viewrendered3 Updated to V3.0rc4

37 views
Skip to first unread message

Thomas Passin

unread,
Oct 6, 2020, 4:47:37 PM10/6/20
to leo-editor
I have just merged a new release candidate of VR3 into the devel branch.  The main changes for users are

1. There are two new VR3-* Leo commands to zoom or unzoom the zoom size in the rendering pane.  These commands can be linked to shortcut keys - typically, one would use the same keys as for an ordinary browser.  VR3 already responded to these keys when the rendering pane has focus.  Now these keys can be used when the focus is not in the rendering pane if one sets up the shortcuts in the @settings section of myLeoSettings.leo.

2. There is another new VR3-* Leo command to restore the panes to a useful default layout.  I added this command because Leo's "nested splitter" machinery was sometimes producing a weird or unworkable layout of the rendering pane. If that were to happen, this command will let you get things back to normal. (This splitter behavior appears to be the subject of its own separate issue (#1686)).

If nobody reports any problems over the next few days or a week, I will release this version is the v3.0 release version.

zhaohe wang

unread,
Oct 11, 2020, 9:43:10 AM10/11/20
to leo-editor

run vr3, errors displayed

Leo Log Window
Leo 6.3-devel, devel branch, build e8319a6
2020-10-10 14:25:04 -0500
Python 3.7.3, PyQt version 5.12.1
darwin

***

Traceback (most recent call last):


  File "/Users/swot/app/leo-editor/leo/core/leoPlugins.py", line 322, in callTagHandler

    result = handler(tag, keywords)


  File "/Users/swot/app/leo-editor/leo/plugins/viewrendered3.py", line 1529, in update

    _kind = pc.get_kind(p) or self.default_kind


  File "/Users/swot/app/leo-editor/leo/plugins/viewrendered3.py", line 2974, in get_kind

    language = self.get_language(p1)


  File "/Users/swot/app/leo-editor/leo/plugins/viewrendered3.py", line 3000, in get_language

    return colorizer.findFirstValidAtLanguageDirective(p.copy())


AttributeError: 'JEditColorizer' object has no attribute 'findFirstValidAtLanguageDirective'

zhaohe wang

unread,
Oct 11, 2020, 9:55:12 AM10/11/20
to leo-editor
happend after git pull: d9367016487a9304a4f35f8f848651347f127683

Thomas Passin

unread,
Oct 11, 2020, 10:15:18 AM10/11/20
to leo-editor
One thing I see is that the VR3 version has some experimental code that I had not intended to have outside of my own clone.  I'll have to revert that.  It must have been some mistake on my part.But that would not be the cause of this problem, which I'm now seeing but didn't a day or two before.

Thomas Passin

unread,
Oct 11, 2020, 11:41:52 AM10/11/20
to leo-editor
Strange ... nothing has been changed about this in VR3.  Edward, has something been changed in JEditColorizer?  I have never seen this error before, and it ought to be showing up all the time..

Edward K. Ream

unread,
Oct 11, 2020, 2:51:11 PM10/11/20
to leo-editor
On Sun, Oct 11, 2020 at 10:41 AM Thomas Passin <tbp1...@gmail.com> wrote:
Strange ... nothing has been changed about this in VR3.  Edward, has something been changed in JEditColorizer?

I just fixed this in devel. colorizer.findFirstValidAtLanguageDirective has been replaced by g.findFirstValidAtLanguageDirective. I changed the code in Leo's core, but I forgot about plugins.

Which reminds me. I'm planning to merge leoPluginsRef.leo into leoRef.leo so this kind of thing will be less likely.

Edward

Thomas Passin

unread,
Oct 11, 2020, 3:18:19 PM10/11/20
to leo-editor
That makes it awkward for the plugins because it's not backwards compatible.  Especially, if I would want to go back and revisit code in some previous commit ir another branch where the change hadn't been made.  Maybe leaving in the deprecated method for a while would be a good idea.

I think I'll put in a conditional call in VR3 in case one or the other method doesn't work.

Edward K. Ream

unread,
Oct 11, 2020, 3:20:25 PM10/11/20
to leo-editor
On Sun, Oct 11, 2020 at 2:18 PM Thomas Passin <tbp1...@gmail.com> wrote:
That makes it awkward for the plugins because it's not backwards compatible.  Especially, if I would want to go back and revisit code in some previous commit ir another branch where the change hadn't been made.  Maybe leaving in the deprecated method for a while would be a good idea.

I think I'll put in a conditional call in VR3 in case one or the other method doesn't work.

You can do whatever you like in VR3, but I'm not going to worry about the kind of compatibility problems that deleting old code might present.

Edward

Thomas Passin

unread,
Oct 11, 2020, 3:38:33 PM10/11/20
to leo-editor
Speaking of that, what changes did you make to the splitter layout methods?  I'm getting a number of exceptions that didn't happen before.

Edward K. Ream

unread,
Oct 11, 2020, 5:25:11 PM10/11/20
to leo-editor
On Sun, Oct 11, 2020 at 2:38 PM Thomas Passin <tbp1...@gmail.com> wrote:
Speaking of that, what changes did you make to the splitter layout methods?  I'm getting a number of exceptions that didn't happen before.

See PR1691

Edward
Reply all
Reply to author
Forward
0 new messages