Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Toooo long working #2

insolution opened this Issue · 13 comments

7 participants


in Notepad ++, css
When the file is big, if i use script in the beginning of the file, its ok, and fast enough.
But if I use script in the end of the file, it works for a 30 second or longer.
in Notepad ++ calculations or some tags
after calculation is done cursor moves to some lines upper at the file, than if it should be.

Sorry for my English, here is the video demonstration of the problem

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.


It happens because of how N++ works with text. It treats text as a series of bytes, not charters (thus, any UTF character is represented as a series of bytes). In this case, I have to convert current document from bytes to characters (and vice versa) in order to make Emmet work properly. So, the larger your document, the more time it takes to convert it on each operation.

I don’t have a solution for this problem right now.


Хм... интересно, а можно тут по-русски писать? Долго переводить...

Вопрос такой.. насколько я понимаю, не весь документ инкодируется, а только от начала документа до курсора... нельзя ли задать ограничение, чтобы обрабатывалась только та часть, которая от начала строки, а не от начала документа, ну или хотя-бы килобайтное ограничение поставить. Чтобы от курсора и на килобайт назад максимум обрабатывалось?

@insolution insolution closed this

ой.. нечаянно закрыл

Если так и не получится ничего исправить.. подскажите, какой редактор лучше всего совместим с emmet?

@insolution insolution reopened this

Я посмотрю на API, но в общем виде — нет. Дело в том, что Emmet в неявном виде опрашивает весь документ, например, чтобы определить тэг, внутри которого происходит разворачивание аббревиатуры, чтобы правильно определить название тэгов (см. Implicit tag names).

Я позже попробую что-нибудь с этим сделать, но пока все найденные мной решения сводятся именно к тому, чтобы постоянно кодировать байты в символы и обратно.

@sergeche sergeche referenced this issue in emmetio/emmet

Задержка expand в Notepad++ #242


I don't agree. We have old version in Python:
I see the same person make this both plugin (Dave Brotherstone) but Emmet works worse (working slow, lost cursor position with some operations). Old Zen Coding don't have this issue.

Any solution at this moment?


Тогда почему в таком случае ZenCoding работает быстро? Хотя на сколько понял, это плагин, работающий не через API notepad++, я правильно понимаю?


@scriptishuser I don’t understand what you don’t agree with.

While Zen Coding and Emmet both share the same NPP wrapper, these plugins are different: Zen Coding had Python implementation and Emmet is written entirely on JS so I’m using PyV8 to run JS in Python.

PyV8 isn’t a bottleneck here, but Scintilla’s (editor component of NPP) way of working with text. JS works with UTF16-encoded text and Scintilla operates with bytes, e.g. 1 character of UTF16 text can be represented by 1–4 (or event more) bytes in Scintilla.

So I can’t just pass content from Scintilla to JS and vice versa because your multi bytes characters will be broken, I have to encode it to UTF first and then decode back to ASCII. And I have to do the verst same thing when Emmet asks to replace certain range of text in editor.

If you find a solution for operating with characters instead of bytes in Scintilla, it will solve the issue


Maybe I did not make myself clear. I mean that there are ways to create an efficient implementation in NPP. This version work without speed problem (I test all this version):

I don't understand why you can't use the above solutions. Maybe in Emmet you use sth news, and this solutions don't have such power.

It is a pity that there is no easy solution, because the NPP is a popular editor, and at this point we have to sit on the old version. But better any old version than nothing, without ZC I can't create markup:) I guess time to change the editor, I see that everyone migrate to the Sublime Text.

PS. Can you try ask Don Ho (NPP author)? Maybe he will give a solution to this problem. If no, I can make topic in NPP forum and put link to this thread. I do not know if this helps, but it is always worth a try.


I’ve used jN in previous versions of plugin: it has major problems with global shortcuts and modal dialogs, as well as outdated JS engine.


This plugin is much better then zen-coding...but since this bug exist I can not use use it...or I can but I need to wait about 15 seconds to respond for every command :(

Can't you just make it the same way as zen-coding plugin is made ( because zen coding work perfect )


I got the problem too. So crazy.


I too have the same problem. I'm using a Windows 8 / Core i7 / 8GM RAM machine.

Its consistently 3s at best to expand an abbreviation where as the old Zen Coding plugin is effectively instantaneous. So the excellent suggestion of using the Tab shortcut key works perfectly for the old plugin as it doesn't get in the way of the usual tab usage, but using this Emmet plugin then there is a 3s delay if you try to press the tab key whilst it figures out if there is a abreviation to do or not.

The loss of speed takes away any benefit of the new features, so until this is fixed I'll just use the old plugin unless there's some aspect of it that only works in Emmet, then I'll take the hit of waiting.

To be clear, I'm using the Zen Coding Python plugin - the one that this is forked from. So the changes made in this fork must be causing the problem.


ls英语屌炸天,I too have!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.