Fit and finish: plugins menu docstring

[Edward K. Ream]

As of rev 4490, choosing a plugin from the Plugins menu displays the
docstring in an "official" viewrendered pane if the viewrendered
plugin exits.

This means that the show/hide/close-rendering-pane commands now can be
used to close this window.

The changes to the code are as follows:

1. show_scrolled_message now just does::

vr = viewrendered(event=kw)

instead of creating a special-purpose rendering pane.

2. The viewrendered command now returns the controller it creates.

I suppose there might be some unanticipated side effects, but I don't
know of any.

Terry, please let me know if this change seems dubious to you.

Edward

[Edward K. Ream]

On Sep 29, 8:52 am, "Edward K. Ream" <edream...@gmail.com> wrote:
> As of rev 4490, choosing a plugin from the Plugins menu displays the
> docstring in an "official" viewrendered pane if the viewrendered
> plugin exits.

Imo, the scrolledmessage plugin needs work urgently: it doesn't
display docstrings at all well: they are laden with docutils error
messages.

Terry, is there a need for the scrolledmessage plugin at all?

Edward

[Terry Brown]

No, I pronounced it dead some time ago. I don't really know where it
came from. I think, not 100% sure, that many of the buttons it had
weren't implemented anyway, so it really does nothing the viewrendered
doesn't.

Be careful though, to display plugin docs viewrendered uses the
scrolledmessage *hook*, not the scrolledmessage plugin, so don't kill
the hook if you're mothballing the plugin.

Cheers -Terry

> Edward
>

[Edward K. Ream]

On Thu, Sep 29, 2011 at 9:12 AM, Terry Brown <terry_...@yahoo.com> wrote:

> No, I pronounced [scrolledmessage] dead some time ago.

Good. I'll remove it today.

> viewrendered uses the scrolledmessage *hook*, not the scrolledmessage plugin, so don't kill
> the hook if you're mothballing the plugin.

That should not be a problem. I won't touch the hook in any way.

Edward

[Terry Brown]

On Thu, 29 Sep 2011 06:52:04 -0700 (PDT)

"Edward K. Ream" <edre...@gmail.com> wrote:

> 1. show_scrolled_message now just does::
>
> vr = viewrendered(event=kw)
>
> instead of creating a special-purpose rendering pane.
>
> 2. The viewrendered command now returns the controller it creates.
>
> I suppose there might be some unanticipated side effects, but I don't
> know of any.
>
> Terry, please let me know if this change seems dubious to you.

Now selecting the About docs. for multiple plugins creates multiple
panes, whereas before the same pane was reused. Preference kind of
thing, I don't think it's that big a deal, although if you were
browsing plugin docs the new behavior could be annoying.

Cheers -Terry

[Edward K. Ream]

On Sep 29, 9:33 am, "Edward K. Ream" <edream...@gmail.com> wrote:

> On Thu, Sep 29, 2011 at 9:12 AM, Terry Brown <terry_n_br...@yahoo.com> wrote:
> > No, I pronounced [scrolledmessage] dead some time ago.
>
> Good.  I'll remove it today.

Done at rev 4497.

EKR

[Edward K. Ream]

On Sep 29, 9:57 am, Terry Brown <terry_n_br...@yahoo.com> wrote:

> > Terry, please let me know if this change seems dubious to you.
>
> Now selecting the About docs. for multiple plugins creates multiple
> panes, whereas before the same pane was reused.  Preference kind of
> thing, I don't think it's that big a deal, although if you were
> browsing plugin docs the new behavior could be annoying.

Interesting. There is a relationship here with mouseless
programming. It would seem that all visual elements, especially those
that may exist in multiple versions, must have a name or other
description suitable for generalized commands.

At present, the most serious hole in Leo's commands is that there is
no way to close or select a tab in the qttabs gui that represents an
entire file: afaik, you have to use the mouse to change files. By
extension, the user might want multiple rendering panes, especially if
one or more are locked. Without a description, there is no way to
specify exactly what show/hide-rendering pane does.

I haven't forgotten the autocompleter docs. I'll get to them next.
It looks like autocompletion would be the way to generalize the not-
very-effect commands that switch focus from one ui element to
another. A related benefit is one generalized command might be more
convenient to use than the present flavors of (buggy) cycle-focus
commands.

In short, contemplating generalized windows leads us to generalized
select/delete/show/hide commands, based on autocompletion, that work
on various ui elements. This looks like the next project.

Edward

[Kent Tenney]

I don't know if this is relevant or not, but the IPython autocompletion
capability is awesome.

If I'm investigating code I tend to do the following.

list the modules in a package:
In [1]: from fs import <tab>

this lists the modules, in a package so I pick one
In [1]: from fs import osfs
<the osfs entry is tab-completable>

now I can check the usage of fs.osfs
In [2]: osfs? <enter>

or the source:
In [2]: osfs?? <enter>

or the contents of the module
In [2]: osfs. <tab>

I can instantiate a class:
In [3]: myfs = osfs.OSFS('/')

and examine the ivars and methods:
In [4]: myfs. <tab>

It is such an efficient way to learn and remember the details of code.

I know a bunch of work was done on Leo/IPython integration, don't
know the current status, my wish of synchronized IPython and Leo
may well be one of the many granted wishes I have forgotten about.

I certainly think IPython autocompletion is the gold standard.

Thanks,
Kent

> --
> You received this message because you are subscribed to the Google Groups "leo-editor" group.
> To post to this group, send email to leo-e...@googlegroups.com.
> To unsubscribe from this group, send email to leo-editor+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
>
>

[Edward K. Ream]

On Fri, Sep 30, 2011 at 9:30 AM, Kent Tenney <kte...@gmail.com> wrote:
> I don't know if this is relevant or not, but the IPython autocompletion
> capability is awesome.

It's relevant. Getting the IPython/Leo to work with the latest
IPython is on the list. I'll be studying the IPython sources,
including autocompletion, in the near future.

Edward