There is a bug in the script:
g.es_print('done: %s formats %s sec' % (n,t2-t2))
is guaranteed to print zero every time :-) Should be t2-t1.
Thanks for the education for us all.
However in terms of importance I would rank dabbrev much ahead of syntax
coloring. My large nodes tend to be very regularly structured (repetition
of instance creations in bookkeeping, e.g.) so lack of syntax color is not
a real concern. Nodes with more obvious clustering properties I can and
should break up into smaller nodes.
I also second Viktor that it is an annoyance that the editor still scrolls
on its own after saving a file.
On Monday, October 1, 2012 7:44:04 AM UTC-7, Edward K. Ream wrote:
>
> On Mon, Oct 1, 2012 at 8:29 AM, Edward K. Ream
> <[email protected]<javascript:>>
> wrote:
>
> > So it should be possible to write a short script to get a concise
> > summary of the formatting. I might even dare hope that QTextLayout
> > may simplify the process. We shall see...
>
> Yes. There is an undocumented class involved, but Python's dir
> function came to the rescue. Here is the script::
>
> import time
> w = c.frame.body.bodyCtrl.widget # a subclass of QTextBrowser
> doc = w.document()
> t1 = time.time()
> n = 0
> for i in range(doc.blockCount()):
> b = doc.findBlockByNumber(i)
> s = str(b.text())
> layout = b.layout()
> for r in layout.additionalFormats():
> # r is an undocumented QFormatRange
> # r.format is a QTextCharFormat.
> # formats are shared only within a single block.
> s2 = s[r.start:r.start+r.length]
> # print('%20s %s' % (r.format,s2))
> brush = r.format.foreground()
> color = brush.color()
> n += 1
>
> t2 = time.time()
> g.es_print('done: %s formats %s sec' % (n,t2-t2))
>
> This script button reports 0.0 seconds even for nodes that take a
> noticeable time to redraw. Thus, it appears that it is indeed
> possible to create a fast, concise summary of all editing in a node.
>
> There are some gc issues involved. Putting each r.format in a list
> hard-crashed Python, so it may be necessary to create a copy of
> r.format for caching purposes. Still, this small script demonstrates
> the general idea.
>
> To summarize, when revisiting a node, we may be able to recolorize
> using the cached summary of syntax coloring rather than calling QSH to
> do a full recolor. This promises *much* faster reloading of nodes.
>
> Notes:
>
> 1. It's not proven that using cached data to recolor a node will be
> fast enough. Experiments should be easy to do. I'll know more soon.
>
> 2. Even when using cached data we still have to re-init the QSH when
> revisiting a node. Otherwise the QSH will not be able to do
> incremental recoloring. In essence, we must tell QSH the starting
> state of each line of the text. I believe this is feasible: the
> necessary data exist in Leo's colorizing code, and so can be cached.
>
> Edward
>
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/leo-editor/-/mePlc150Hx8J.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/leo-editor?hl=en.
