[vi simulator] how to highlight a word

Claudia Frank

I think you found a bug.
Regardless of executing via callback or “manually”, the result should always be correct and this isn’t.

In regards of speed comparision, I have the feeling that lua is using some gui freeze technique
(@dail should know more about it ;-)) whilst python script seems to update every hit instantly.
In addition, the python code sets the indicator every time a new “if” is found whilst lua is doing it once. I guess this is related to the asynchronous stuff because I’ve reported this some time ago and Dave mentioned that it is most likely that the python lexer is jumping in and interrupting the
script coloring. To be honest, it is ok for me as I don’t have huge documents which need to be colored manually and a simple trick would be “unfocusing” the doc to speed things up.

Cheers
Claudia

dail

I have the feeling that lua is using some gui freeze technique

Yes and no. Since the Lua code runs synchronously there is no way that Scintilla or Notepad++ can redraw the GUI until Lua returns. So since Lua sets the indicators on multiple ranges before it returns, Scintilla only redraws once.

whilst python script seems to update every hit instantly.

If we are assuming it is actually running asynchronously (again not completely sure about the internals), then there is a fight between Scintilla and Python. Scintilla wants to redraw as soon as there is a change, but Python is running in a separate thread constantly updating the indicators. However this still doesn’t explain everything…for example why are indicators getting removed in the example gif Scott provided.

Claudia Frank

@dail

I’m not sure about this, but, can we be sure that, if a synchronous action gets called it is more or
less an atomic action? As far as I understood only the processor can assure atomic executions.
In addition I thought that plugins running in their own threads, don’t they?

for example why are indicators getting removed in the example gif Scott provided.

:-) because of the bug?? :-) I was able to confirm that there must be a bug but my results weren’t
that bad as Scotts - I assume it is related to the script runner Scott is using or …
Scott you are using python script 1.0.8.0, do you?

Cheers
Claudia

dail

if a synchronous action gets called it is more or less an atomic action?

Yes “atomic” in regards to Scintilla and Notepad++ not able to execute it’s own code.

In addition I thought that plugins running in their own threads, don’t they?

No, by default there is no threading involved. It is as simple as a function call (e.g. Notepad++ calling a plugin’s function).

because of the bug??

Yes but indicators should only get removed when editor.indicatorClearRange() is called, and assuming the Python code is only ran 1 time, then editor.indicatorClearRange() should only ever be called once…even if it is running asynchronously.

Scott Sumner

@Claudia-Frank

Yes, I’m using Pythonscript 1.0.8.0 with Notepad++ 7.2.2.

When you say your results aren’t as “bad” as mine, I presume you mean that more of the text that should be highlighted remains so after a run of the Pythonscript? For me, I noticed that sometimes I get more “coverage” than I got for the run where I recorded the video, but it tends to run in spurts, meaning that I can’t predict how much coverage I’ll get but that it seems to be common to the previous run. Sometimes I’ll get very good coverage (only a few pieces of text don’t get highlighted), but I have no idea what influences this situation…

My “script runner” is simply a pythonscript that executes the active .py file, so nothing special there…

Claudia Frank

@dail - thank you for clarification.

Yes but indicators should only get removed when editor.indicatorClearRange() is called, and assuming the Python code is only ran 1 time, then editor.indicatorClearRange() should only ever be called once…even if it is running asynchronously.

From my test

it looks like that some found items were not colored instead of the previous are cleared as shown
by Scotts gif. To be honest, I didn’t really test if the uncolored once are reported as found - I will do so.

Cheers
Claudia

Scott Sumner

@Claudia-Frank

At one point I had some code in there to count the "if"s so that I could make sure they were all found by the search function…and I always saw a consistent and correct count.

Claudia Frank

@Scott-Sumner

I can confirm, I run it 100 times and it always reported it correctly but there is another strange thing
as soon as I put a print statement (which needs sys.stdout = console redirection) into the while loop I always get all "if"s colored. I even can now put the setIndicatorCurrent out of the loop.

else:
    endPos = editor.getTextLength()
    temp = editor.findText(FINDOPTION.WHOLEWORD | FINDOPTION.MATCHCASE, 0, endPos, 'if')
    editor.setIndicatorCurrent(indicator)
    console.clear()
    while temp != None:
        print temp
        (s, e) = temp
        editor.indicatorFillRange(s, e - s)
        temp = editor.findText(FINDOPTION.WHOLEWORD | FINDOPTION.MATCHCASE, e, endPos, 'if')  
print 'Done'

First I thought about a timing issue but replacing the print statement with another time consuming action brings back the issue so … ???

Cheers
Claudia

Scott Sumner

@Claudia-Frank

Noticed that, too…sorry I didn’t mention it. :-)

Claudia Frank

@Scott-Sumner, @dail

I guess I found the reason. It’s basically what we already assumed. Npp is stepping in.
During debugging I noticed, that sometime indicator was reset to value 29 (in such a case it was always 29),
which, afaik, is used by smart highlighting.
Albeit following code worked by 100 consecutive runs always, there is a potential risk that it fails again.

endPos = editor.getTextLength()
temp = editor.findText(FINDOPTION.WHOLEWORD | FINDOPTION.MATCHCASE, 0, endPos, 'if')
editor.setIndicatorCurrent(indicator)
while temp != None:
    (s, e) = temp
    editor.indicatorFillRange(s, e - s)
    if editor.getIndicatorCurrent() != indicator:
        # print 'getIndicatorCurrent:{}'.format(editor.getIndicatorCurrent())
        editor.setIndicatorCurrent(indicator)
        editor.indicatorFillRange(s, e - s)
    temp = editor.findText(FINDOPTION.WHOLEWORD | FINDOPTION.MATCHCASE, e, endPos, 'if')

Cheers
Claudia

Claudia Frank

By the way, disabling smart highlighting doesn’t solve the issue because than another set indicator jumps in.

Cheers
Claudia

dail

another set indicator jumps in.

Probably the xml tag highlighting.

Claudia Frank

@dail

correct, if we disable smart and matching tags highlighting then it works as expected
but this, at least for me, isn’t desirable.

Cheers
Claudia

dail

@Claudia-Frank

but this, at least for me, isn’t desirable

Oh I totally agree, it was just to prove it was caused by N++ :)

Js jS

This post is deleted!

Js jS

run this with the “if” block on screen
and again with the “if” block off screen

same result on “normal text” file

the “if” block has to be added

gets flagged as spam if i include it

from timeit import default_timer as timer

indicator = 12  # not sure what one is best to use but this works
editor.indicSetStyle       (indicator, INDICATORSTYLE.ROUNDBOX)
editor.indicSetAlpha       (indicator,  55)
editor.indicSetOutlineAlpha(indicator, 255)

first =  726
last  = 2260 

start = timer()
for s in range( first, last, 3):
    a=s
    editor.setIndicatorCurrent(indicator)
    editor.indicatorFillRange(s, 2)

end = timer()
console.write("4:\t%f\n" % (end - start))
  
start = timer()
for s in range( first, last, 3):
    a=s
    editor.setIndicatorCurrent(indicator)
    editor.indicatorClearRange(s, 2)

end = timer()
console.write("5:\t%f\n" % (end - start))

Js jS

forgot to mention …

open python console

turning off brace matching and smart highlighting makes no difference

npp 7.3.1 32 bit windows7 64bit

Js jS

addendum:

moving the mouse during the script execution causes misses in highlighting

Claudia Frank

@Js-jS

for me it is hard to see to whom you want to address to.
May I ask you to add the name of the recipients to your post?
Concerning the post, I’m not quite sure what you try to impart.
Are you surprised about time differences?

Cheers
Claudia

Scott Sumner

@Js-jS

I, too, am confused about what you are trying to demonstrate here. I’m more inclined to try code out if there is also a clear description about what it is doing that is odd or interesting. After reading such a description, I can decide if I want to try the code out or not (if there is something about it that is interesting to me…). Anyway, we kind of beat to death the “highlighting IFs” situation a couple of months ago…not sure what new there is to take away from it.