BETA: SciTE v5x & lua Dynamic_include and "Smart" AutoComplete for Vars/UDFs/Abbrevs

[Jos]

You can use an Enter or Tab to select an proposed variable from the dropdown list, which is then inserted in the editor, but the Enter/Tab used isn't forwarded. With this option you can define what character you like to have added after the inserted variable name.so in this shown example , the Enter is added after you use Enter to select the variable from the drop-down.

All clear?

[donnyh13]

Hi Jos, Thanks very much for your explanation.
 Just when you thought you got rid of me — I found a minor graphic glitch, Not sure If it's really important or not. When using multiple cursors to type data in a commented section (minimum 3), I noticed sometimes the words stay black instead of turning green, until some time later at least. Strange thing is, when attempting to re-create the problem, I typed four commented lines (see below image). If I began creating cursors (by holding CTRL and clicking) from lines 1 to 4, the problem appears, but if I start from line 4 and go to line 1, the problem doesn't appear. If I click after the line and hit space, backspace, etc., the words turn to green as they should be.

[snip]

Edited March 13 by donnyh13

[Jos]

That explanation sounds like an au3lexer issue, but I am somewhat confused what you mean by to replicate it:

14 hours ago, donnyh13 said:

If I began creating cursors (by holding CTRL and clicking) from lines 1 to 4

I have no idea what "creating cursors" means in this context. What exactly are you clicking on with Ctrl pressed? 
I only know the function of Ctrl+Click for folding.

So could you give me some layman steps to perform to see this Lexer issue so I can debug it in VS++?

Understand what you mean now and am able to replicate for debugging.

Thanks!  

Edited September 20, 2023 by Jos

[Jos]

6 hours ago, Jos said:

Understand what you mean now and am able to replicate for debugging.

Surprisingly it was an issue caused by the LUA script which forced the update in the lexer, which is fixed in the current updated LUA files in the zip file.
 

Just to be clear: At this moment the Dynamic AutoComplete doesn't support autocomplete for multiple words insertion like you are doing here with the Ctrl+Click. I might has a look at that but am not sure on its complexity yet. 

Edited September 20, 2023 by Jos

[donnyh13]

8 hours ago, Jos said:

which is fixed in the current updated LUA files in the zip file

Okay, great, glad you found it, and also figured out what I was trying to say. I didn't have a clue what that insertion method is called, I just happened across it by accident one day and found it handy from time to time.

8 hours ago, Jos said:

Just to be clear: At this moment the Dynamic AutoComplete doesn't support autocomplete for multiple words insertion

Ya, I kind of figured, it wasn't supported before either, just completes one line. I'm thinking it would be rather complex to implement, but who knows?  not to mention it may not be worth while since I doubt many even use/know about writing on multiple lines? It's not every day you need to write multiple identical lines.  

[mLipok]

On 7/1/2022 at 4:30 PM, Jos said:

Download SciTE_changes_Dynamic_Includes.zip, which contains the updated files for an standard installation.

Is it only on my computer or is this link broken?

Edited September 20, 2023 by mLipok

[Danp2]

It's just you. 😜

Seriously, try this link.

[donnyh13]

Hi again Jos,

This may be my imagination, but I'm noticing a "lagginess" on the AutoComplete drop down displaying actual text. (Just sitting there as a blank for milliseconds longer). I can press enter and the text is auto completed still, but the text isn't displayed in the drop down till longer — it seems?  I reverted AutoItAutoComplete.lua to your last version and my imagination seems to not notice the lag, I place the new AutoItAutoComplete.lua file in and my imagination sees it again. I'll try it again another day and see if it's just some sort of slow down on my computer or not.

[Jos]

8 hours ago, donnyh13 said:

This may be my imagination, but I'm noticing a "lagginess" on the AutoComplete drop down displaying actual text.

The change I made will "re-lexer" the whole file so assume this is a bigger scriptfile?
I could try changing that to only the lines displayed which should also fix the issue when you have multiple inserts going and not all being "Colored".

Will have check to see if that works too.

Edited September 21, 2023 by Jos

[Jos]

28 minutes ago, Jos said:

Will have check to see if that works too.

Change made in the current LUA scripts in SciTE_changes_Dynamic_Includes_LUA.zip.
Curious to see if that makes any difference for you.

Edited September 21, 2023 by Jos

[Jos]

Updated the Beta installer & portable files with the latest Lua scripts and SciTE V 5.3.7   Scintilla:5.3.6   Lexilla:5.2.6.
Also the SciTEx86 & SciTEX64 are updated with the latest version. 

[donnyh13]

8 hours ago, Jos said:

so assume this is a bigger scriptfile

Yes it is, ~ 7,500 lines, plus two others open, one which is 45,000 lines.

8 hours ago, Jos said:

Curious to see if that makes any difference for you.

I'll give it a shot, thanks for your prompt help and responses!

And then I'll update to the new beta files too.

[donnyh13]

Okay @Jos, I have tried the new files and Beta too, The slower behaviour is still present, but I think it has improved. I further noticed the slow down becomes more pronounced after saving changes made in the file, compared to freshly opening and editing a file, and having never pressed save.

I further noticed another thing, when hitting ENTER several times, before saving any changes in an open file, ever, it is instantly inserted, after saving, there are pauses for some milliseconds. (This, I think, has been present always, I've just noticed it now?)

If you aren't able to re-create these errors, it may be just my computer?

Probably helps you none, but I played with the AutoItAutoComplete.lua file, slowly adding your new changes into the Sept 19 version, and found that line 113 seems to be the cause of the slow AutoComplete window, changing this line (Line 113 in function AutoItAutoComplete:OnChar(c))

editor:Colourise(editor:PositionFromLine(editor.FirstVisibleLine), editor:PositionFromLine(editor.LineCount+1))

Back to:

editor:Colourise(editor:PositionFromLine(curlinenr - 1), editor:PositionFromLine(curlinenr + 1))

the issue is remedied, but I'm guessing that pretty much undoes much of your fix? I still notice a minor slow down, even after this, but it is greatly improved after editing that line.

This lagginess isn't intolerable, and like you pointed out, it is in a large file, so it should be expected. Just thought I should mention it when I first noticed it, in case it was useful. Everything looks great otherwise. By the way, my display issue that you helped me fix still exists in Scite 5.3.7. Weird!

Edit**

As an experiment, I monkeyed with a bit of stuff for that line, This seems to work okay, though is a bit "clumsy" ?

editor:Colourise(editor:PositionFromLine(curlinenr - editor.LinesOnScreen), editor:PositionFromLine(curlinenr + editor.LinesOnScreen))

Also, I noticed this:

editor.FirstVisibleLine

Reports a line number several thousand previous to my current visible position. Seems odd for the name of it? Maybe I misunderstand its use.  e.g., I am currently typing on line 5,207, it reports the first visible line is 2,454.

Edit2**

Something like this could also work, and fix the issue of multiple selections, although this still seems to be slower?? Hard to say, will have to try it more.

if (editor.Selections > 1) then 
    editor:Colourise(editor:PositionFromLine(editor.SelectionNCaret[0]), editor:PositionFromLine(editor.SelectionNCaret[editor.Selections -1]))
    else
    editor:Colourise(editor:PositionFromLine(curlinenr - 1), editor:PositionFromLine(curlinenr + 1))
    end

But instead of editor.SelectionNCaret[0], and editor.SelectionNCaret[editor.Selections -1], you would have to have a separate function to determine which selection is on the lowest numerical line # and which on the highest, and then set a variable in case the selections were created in a random order above and below the 0th selection and the last created selection. Such as:

Selection #2
Selection #0
Selection #1

Just my thoughts in case they help any.

Edited March 13 by donnyh13

[Jos]

Thanks for your debugging and will have a more detailed look tomorrow when i will have some time to debug. :-)

[Jos]

17 hours ago, donnyh13 said:

Also, I noticed this:

editor.FirstVisibleLine

Reports a line number several thousand previous to my current visible position. Seems odd for the name of it? Maybe I misunderstand its use.  e.g., I am currently typing on line 5,207, it reports the first visible line is 2,454.

This is very strange unless an fold is active, but it should have the value of the linenumber-1 for the first visible line on the screen.(line1=0)

This could explain why it becomes laggy for you in this specific script.

 

Edited September 22, 2023 by Jos

[donnyh13]

50 minutes ago, Jos said:

will have a more detailed look tomorrow

Sounds good!

43 minutes ago, Jos said:

This is very strange unless an fold is active

Yes, you are correct, I tried it with all folds unfolded and it reports correctly now. I suppose that it must be the "correct" line number with the folds then.

[Jos]

30 minutes ago, Jos said:

This is very strange unless an fold is active, but it should have the value of the linenumber-1 for the first visible line on the screen.(line1=0)

After rereading the SciTE/Scintilla API calls in the helpfile I see indeed that it will be a different line number than the Document linenumber.

I will make some changes to the script to avoid doing the lexing of too many lines, which should help decrease the lag.

[donnyh13]

Actually, I just tried inserting this in the auto Complete (at line 113)

editor:GotoLine(editor.FirstVisibleLine)

And it takes me to the literal line wayyyyyyy before where I'm at... From line 7378 to line 825, (this is with folds active by the way.) I think you're right, this would probably be why it's laggy on these bigger scripts.

[Jos]

correct. 

I need to use editor:DocLineFromVisible(line displayLine) to get the proper file record...   more tomorrow.  

[Jos]

Just had a bit of time to play with this so made some changes in the lua scripts:

• Correctly determine first line in display
• Re-lexer first displayline up to the current word being typed to reduce the lagging (hopefully)
• When using multiple inserts (Ctrl+Click) the backspace will work on all inputs and they will now remain active.

Give this version of lua scripts a spin available in SciTE_changes_Dynamic_Includes_LUA.zip.