Expand abbreviation slow at the first time.

[Chris2011]

As I mentioned it in this ticket: #3 (comment)

the problem is that when I first use my shortcut to expand abbreviation, it tooks some seconds to expand it. After the first time, it tooks ms. You can see it in my screen capture. I use the full bundled IDE 8.1. I don't want to use the HTML5 IDE because I have to use a lot of technologies, like Java, HTML5, JS, PHP and so on. So no option for me. I don't think that this will change anything. It should be as fast as in Sublime or other Editors/IDEs still from the very first time.

In my screencapture you see after I press a shortcut, that the cursor hangs for 2-3 seconds. It's weird.
Have Windows 10 64bit but it happened in Windows 7 too.

[markiewb]

IIRC the first time the RhinoEngine is initialised.

Two things have to be done

• update the very old bundled RhinoEngine
• execute the expand action using a RequestProcessor. If it takes longer than xxx ms (because of the init) it shows a selfclosing dialog/progress with a message "Init engine..." OR do the initialisation when the plugin is loaded (== after NB starts)

[markiewb]

@Chris2011: We could do this together in a coding evening. Now we have a topic...

[junichi11]

I've just improved a little.

@Chris2011 Could you try to use this?
https://dl.dropboxusercontent.com/u/10953443/netbeans-emmet/org-lorenzos-emmet-1.0.1.1-dev.nbm (NB81)

[markiewb]

@junichi11: I don't see any commit / feature-branch / pull-request for your changes. Did I missed it?

[junichi11]

@markiewb I'll push it later.

[Chris2011]

My installed version of emmet is 1.0.1.4.

[junichi11]

I just updated the version number.
https://dl.dropboxusercontent.com/u/10953443/netbeans-emmet/org-lorenzos-emmet-1.0.1.5-dev.nbm

[Chris2011]

It seems for me that it is a bit faster but it still hangs on the first time. As @markiewb said, the RhinoEngine should be initialised after NB started. And it should be updated to the newest one. It should exactly work as for code templates, they are immediately there. I don't know what you did but I think there is more todo.

@markiewb the self closing dialog is not an option for me, because it should took more than xxx ms at the first time. Emmet is very fast in other IDE's or editors so it should have the same fast functionality in Netbeans too.

[junichi11]

I've improved a bit.

https://dl.dropboxusercontent.com/u/10953443/netbeans-emmet/org-lorenzos-emmet-1.0.1.6-dev.nbm

[Chris2011]

No changes :/

[junichi11]

I guess that nb is opening/scanning your projects. So please try to wait it.

[Chris2011]

I have. I didn't try it right after opening netbeans. I already wait 5 until 10 min
Am 07.09.2016 5:23 nachm. schrieb junichi11 notifications@github.com:I guess that nb is opening/scanning your projects. So please try to wait it.

—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or mute the thread.

[junichi11]

Unfortunately, I cannot reproduce it. It's not slow in my environments(Windows10, Linux) when I run an action after the scanning.

[Chris2011]

Hm, I don't know how I can you help further to figure out what the problem is. Can you please tell me what your improvements were?

[junichi11]

My improvements are the following:

1. Loading core js files(emmet-app.js e.t.c.) on startup (this takes time)
2. Running an emmet action once on startup (the first action takes time a little)

[Chris2011]

And what about @markiewb said to change the old rhino engine with a new one? Or is it already new?

[junichi11]

I've just updated the rhino version. I don't think that it is the cause. But please try using it: https://dl.dropboxusercontent.com/u/10953443/netbeans-emmet/org-lorenzos-emmet-1.0.1.7-dev.nbm

[Chris2011]

Hm maybe there is something other blocking the process. It is not that slow but there is a little delay of round about 200ms or 300ms or more.

[junichi11]

there is a little delay of round about 200ms or 300ms or more.

Yes, but it is not a big problem. So, I think that we can close this issue.

IMHO, there may be a problem in the CodeTemplate. The cause of freezing was it before. And a difference between Emmet and Zencoding plugin is it. (Zencoding plugin doesn't use the CodeTemplate feature.)

[Chris2011]

Sure, but the delay is that what I really not wanted. It is not freezing anymore but I would like to have instant expand the abbreviation on hit my shortcut as in other editors or IDEs is standard. So it feels not quite fast with this delay and I don't know why this should have a delay at all.

[junichi11]

Unfortunately, it is impossible to resolve all delay. It seems that the CodeTemplate takes time a little. So, probably, we can do nothing at the moment. If Document.insert() is used, it will be faster than it. However, It means that we cannot move the next value position with the Tab key.

Thanks.

[Chris2011]

So the delays are not hardcoded inside the code, right? How can we check whether Document.insert() is used or not?

[junichi11]

I guess that Document.insert() would being used in the CodeTemplate class. Because Emmet plugin uses CodeTemplate.insert() instead of Document.insertString() when it replaces the content. see : https://github.com/emmetio/netbeans/blob/master/src/org/lorenzos/emmet/editor/EmmetEditor.java#L166