You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Is changing to bold font possible part of EnhanceAnyLexer #12
@oirfeodent
Unfortunately no, not with the current implementation. I tested, again, with styles, and although it says it can be used together with lexers, I see a constant high CPU usage with it. The strange thing is that using the batch lexer doesn't seem to cause this, but using Rust, C and V lexers for example causes this problem.
Still testing further.
@bobcate - if I can get it to work, then all style attributes can be used but to be honest, besides the high CPU usage there are other hurdles like resetting a set style that needs to be solved.
@oirfeodent , @bobcate
Using lexers seems to work, but there is a problem when using it with "normal text", i.e. without lexers.
I will test this for a few days to see if there are any other hidden oddities.
NOTE: Due to the reported crash, the experimental version has been removed.
An experimental version has been uploaded that allows styles to be used instead of or together with indicators.
Note: Styles have a negative impact on the overall performance of Notepad++, as the built-in lexer must be instructed to re-evaluate the entire visual area after each change.
If styles are not really needed, the use of the indicator is recommended.
During the internal test phase with ~1000 line sized source files, no noticeable delays due to styles were detected. However, a test with a 1_000_000 line XML file shows considerable delays.
Extract the zip file into the plugin directory of the Notepad++ installation.
When you start Notepad++ and open the About dialogue of EnhanceAnyLexer, you should see that version 2.0.0 has been loaded.
The following new configurations must be made in order to use the styles.
Lines with style_NNN=;;;;;; must be created in the global section and
lines with use_style_NNN=regular expression must be defined in the lexer related sections to be able to use them.
Currently, incorrectly defined style lines are ignored; in future, a linter will indicate any errors.
Extract from the help text of the initial configuration file:
...
; USE OF STYLES
; NOTE, If styles are used instead of the indicator, the computing power increases considerably,
; as the built-in lexer is instructed to re-evaluate the currently visible area with every change and every scroll.
; If a lexer has to re-evaluate the entire buffer, as is the case with xml and json, this can lead to very slow or even unusable response times.
;
; Each style must be defined beforehand.
; A line must start with style_NNN= followed by 7 style attribute values separated by semicolons.
; NNN should be a unique number per style in the range of 0 to 255 and must be used later with use_style_NNN.
; As Scintilla reserves the use of id 0 to STYLE_LASTPREDEFINED, currently 39, for internal use, a start id=50 seems appropriate.
; The order of the style attributes is IMPORTANT/SIGNIFICANT!!!
; The following 7 attributes can be set
;
; fore_color;back_color;bold;italic;underline;font_size;font_name
;
; bold, italic and underlined are boolean-like values, 1 means set, 0 means not set
; font_name a string like Consolas
; font_size a number like 12
; fore_color and back_color is the same as for the indicator configuration
; A missing value means that the value from Notepad++`s default style, aka style 0, is used.
; EXAMPLE
; A defined foreground and background color, a font size and with a bold style
; style id= fg ; bg ; bold ; italic; underline; font_size; font_name
; style_50=0x123456;#ff00ff; 1 ; ; ; 23 ;
; A style with a defined font name, the foreground color from the DEFAULT style, a defined background color and the rest are from the default style
; style_51=;#00d7ff;;;;;Consolas
; TEMPLATE
; style_id=fore_color; back_color; bold; italic; underline; font_size; font_name
; style_50= ; ; ; ; ; ;
...
; Each configured lexer must have a section with its name,
; (NOTE: use the menu function "Enhance current language" as it takes care of the correct naming)
; followed by one or more lines with the syntax
; color[optional whitelist] = regular expression
; or
; use_style_NNN[optional whitelist] = regular expression
Wow, that's almost what i wanted.
but i have still 2 problems with this version:
Scrolling with holding the arrow keys (left, rigth, up and down) keys are not possible like before.
The text or cursor scrolls but it jumps a lot and you can't see where the cursor is, so it's not really usable for me since i scroll a lot with the arrow keys.
Maybe it's possible to detect such a keypress in the plugin and not try to add the styles as long as that key is pressed?
When writing to the configuration, N++ is very slow and sometimes hangs. It may make sense to apply the changes when the configuration is saved rather than applying them in real time?
Hopefully you can do something about problem 1, problem 2 is not that important.
Regarding 1:
I also use the arrow keys quite often and have not had this problem with Rust, V or Python source files. May I ask what type of file you are processing and how big it is? Or can you share an example and your configuration for such a file? Subclassing scintilla to detect keystrokes could be one way to solve the problem, maybe using idle styling is another way, but the downside would be that the coloring happens later.
Re 2: Real-time matching is good because the effects of the regular expression used are immediately visible, but currently the plugin tries to find the matches in the entire content of the file. Limiting it to a configurable number of maximum matches should significantly improve performance.
I usually work on Javascript files (*.js and .tsx), the largest one i'm also testing the new version on is about 1.5MB in size and ~35000 lines.
My test configuration for coloring the background for all words Write until the next bracket and the word “G”. in orange and the word “Msg” in yellow is simply:
(I still need to find a better color for this orange, but it's good for testing)
I'm sorry I can't post a sample file because it's all copyrighted.
What i can say, it contains 2855 hits for Write..., 10276 for G. and 4015 for Msg.
If the coloration occurs later, that is certainly better than the current behavior.
Except that the delay time is half an hour. 😂
Regarding 2: In my opinion, this is a good idea, but as i said, not that important.
The problem seems to be lexer-specific, and it makes sense when you consider what happens now. However, I wonder whether it's even necessary for me to instruct the lexer to reevaluate the visual area. Yes, I have to think about strategies to equalize this, but it won't be possible to solve the whole thing completely. Caching doesn't seem to me to be a solution, as it is in the nature of regular expressions to invalidate previous matches with every change in the text. Unfortunately, Idle styling didn't help either. I will probably have to get an overview of where most of the time is spent first.
Maybe it makes sense to find out the difference between using the arrow keys and using the scroll bar or mouse wheel, because it works perfectly with the scroll bar and mouse wheel?
Maybe notpad interprets the use of the arrow keys as input in the text and 'thinks' that's are changes in the text and executes the appropriate routines for changes, which takes the time that causes the delays?
I just play a little with the config and get an exeeption:
It happened when i was scrolling the configuration with the mouse wheel.
When i scroll up and reach a point in the top, the style_xx... config entries get the background color defined in that line.
I've never seen this before because I apparently never scrolled that high to get to it. please refer:
At the time of the exception, only the first entry (style_50) was colored, the other two were not.
Maybe this will help find the cause. I haven't been able to reproduce this error again until now.
In such a case, is a debug log written here? If so, I think i can send it if i know where it was written.
If not, perhaps you can create and publish a debug version with such output enabled?
Just in case it happens again.
Sorry, that shouldn't have happened, and no, a debug log is not available.
I've never seen this before because ...
Are you saying that you didn't immediately see what a text styled like this would look like after you defined it? Of course, to see the background color, you have to move the cursor to another line.
If not, maybe you can create and publish a debug version with this output enabled...
I deleted the current version because that could lead to data loss (maybe already has?) ... I'll try to find some time this weekend to create a new version.
Hi @Ekopalypse
I understand there seems to be performance issues.
So far I have been using the experimental release (more than a month) without any issues.
Does it make sense to do a release with a "on/off switch", so some users who dont see the issues can use the newer features?
I don't know what you think about this or it would be bigger problem for you to maintain the code?
Hi @oirfeodent
sorry for the delay, but the only thing that makes me hesitate to release a new version is the reported crash.
Unfortunately, I haven't yet found out what could have caused it.
I have implemented a crash handler and run some tests, but so far I have not been able to generate a situation that leads to a crash.
Because of another problem with the lsp plugin I am currently trying to figure out how I can best implement a fuzzy testing framework with PythonScript.
This could also help here.
@netcraftz sorry for the inconvenience, yes it has been removed due to the reported crash.
I'm on vacation starting Monday, next week, which means I can spend some time working on this problem then.
Activity
Ekopalypse commentedon May 28, 2024
@oirfeodent
Unfortunately no, not with the current implementation. I tested, again, with styles, and although it says it can be used together with lexers, I see a constant high CPU usage with it. The strange thing is that using the batch lexer doesn't seem to cause this, but using Rust, C and V lexers for example causes this problem.
Still testing further.
bobcate commentedon May 29, 2024
+1 and if possible, please add italic, underlined and font size too.
Ekopalypse commentedon May 30, 2024
@bobcate - if I can get it to work, then all style attributes can be used but to be honest, besides the high CPU usage there are other hurdles like resetting a set style that needs to be solved.
oirfeodent commentedon May 31, 2024
@Ekopalypse ok... hope you are in a position to get it working. Thx.
Ekopalypse commentedon Jun 13, 2024
@oirfeodent , @bobcate
Using lexers seems to work, but there is a problem when using it with "normal text", i.e. without lexers.
I will test this for a few days to see if there are any other hidden oddities.
oirfeodent commentedon Jun 14, 2024
@Ekopalypse wow looks great!!! Looking forward.
Regards,
Ekopalypse commentedon Jun 17, 2024
@oirfeodent, @bobcate, @Weber-Frank
NOTE: Due to the reported crash, the experimental version has been removed.
An experimental version has been uploaded that allows styles to be used instead of or together with indicators.Note: Styles have a negative impact on the overall performance of Notepad++, as the built-in lexer must be instructed to re-evaluate the entire visual area after each change.
If styles are not really needed, the use of the indicator is recommended.
During the internal test phase with ~1000 line sized source files, no noticeable delays due to styles were detected. However, a test with a 1_000_000 line XML file shows considerable delays.
Extract the zip file into the plugin directory of the Notepad++ installation.
When you start Notepad++ and open the About dialogue of EnhanceAnyLexer, you should see that version 2.0.0 has been loaded.
The following new configurations must be made in order to use the styles.
Lines with
style_NNN=;;;;;;must be created in the global section andlines with
use_style_NNN=regular expressionmust be defined in the lexer related sections to be able to use them.Currently, incorrectly defined style lines are ignored; in future, a linter will indicate any errors.
Extract from the help text of the initial configuration file:
Weber-Frank commentedon Jun 17, 2024
Wow, that's almost what i wanted.
but i have still 2 problems with this version:
Scrolling with holding the arrow keys (left, rigth, up and down) keys are not possible like before.
The text or cursor scrolls but it jumps a lot and you can't see where the cursor is, so it's not really usable for me since i scroll a lot with the arrow keys.
Maybe it's possible to detect such a keypress in the plugin and not try to add the styles as long as that key is pressed?
When writing to the configuration, N++ is very slow and sometimes hangs. It may make sense to apply the changes when the configuration is saved rather than applying them in real time?
Hopefully you can do something about problem 1, problem 2 is not that important.
Best regards
Frank Weber
Ekopalypse commentedon Jun 17, 2024
@Weber-Frank
Regarding 1:
I also use the arrow keys quite often and have not had this problem with Rust, V or Python source files. May I ask what type of file you are processing and how big it is? Or can you share an example and your configuration for such a file? Subclassing scintilla to detect keystrokes could be one way to solve the problem, maybe using idle styling is another way, but the downside would be that the coloring happens later.
Re 2: Real-time matching is good because the effects of the regular expression used are immediately visible, but currently the plugin tries to find the matches in the entire content of the file. Limiting it to a configurable number of maximum matches should significantly improve performance.
Weber-Frank commentedon Jun 17, 2024
I usually work on Javascript files (*.js and .tsx), the largest one i'm also testing the new version on is about 1.5MB in size and ~35000 lines.
My test configuration for coloring the background for all words Write until the next bracket and the word “G”. in orange and the word “Msg” in yellow is simply:
style_51=;0x00F8F8;;;;;
[javascript]
use_style_50 = (Write.*?(|G.)
use_style_51 = Msg
(I still need to find a better color for this orange, but it's good for testing)
I'm sorry I can't post a sample file because it's all copyrighted.
What i can say, it contains 2855 hits for Write..., 10276 for G. and 4015 for Msg.
If the coloration occurs later, that is certainly better than the current behavior.
Except that the delay time is half an hour. 😂
Regarding 2: In my opinion, this is a good idea, but as i said, not that important.
best regards
oirfeodent commentedon Jun 21, 2024
@Ekopalypse It works for me.
The files I work on hardly reaches a max of 10K lines.
So far no issues or lags.
Regards,
Ekopalypse commentedon Jun 21, 2024
The problem seems to be lexer-specific, and it makes sense when you consider what happens now. However, I wonder whether it's even necessary for me to instruct the lexer to reevaluate the visual area. Yes, I have to think about strategies to equalize this, but it won't be possible to solve the whole thing completely. Caching doesn't seem to me to be a solution, as it is in the nature of regular expressions to invalidate previous matches with every change in the text. Unfortunately, Idle styling didn't help either. I will probably have to get an overview of where most of the time is spent first.
Weber-Frank commentedon Jun 21, 2024
Maybe it makes sense to find out the difference between using the arrow keys and using the scroll bar or mouse wheel, because it works perfectly with the scroll bar and mouse wheel?
Maybe notpad interprets the use of the arrow keys as input in the text and 'thinks' that's are changes in the text and executes the appropriate routines for changes, which takes the time that causes the delays?
Weber-Frank commentedon Jun 21, 2024
I just play a little with the config and get an exeeption:
It happened when i was scrolling the configuration with the mouse wheel.
When i scroll up and reach a point in the top, the style_xx... config entries get the background color defined in that line.
I've never seen this before because I apparently never scrolled that high to get to it. please refer:
At the time of the exception, only the first entry (style_50) was colored, the other two were not.
Maybe this will help find the cause. I haven't been able to reproduce this error again until now.
In such a case, is a debug log written here? If so, I think i can send it if i know where it was written.
If not, perhaps you can create and publish a debug version with such output enabled?
Just in case it happens again.
best regards
Ekopalypse commentedon Jun 21, 2024
Sorry, that shouldn't have happened, and no, a debug log is not available.
Are you saying that you didn't immediately see what a text styled like this would look like after you defined it? Of course, to see the background color, you have to move the cursor to another line.
I deleted the current version because that could lead to data loss (maybe already has?) ... I'll try to find some time this weekend to create a new version.
Thanks for testing and reporting the problem.
oirfeodent commentedon Aug 9, 2024
Hi @Ekopalypse
I understand there seems to be performance issues.
So far I have been using the experimental release (more than a month) without any issues.
Does it make sense to do a release with a "on/off switch", so some users who dont see the issues can use the newer features?
I don't know what you think about this or it would be bigger problem for you to maintain the code?
Regards
Ekopalypse commentedon Aug 9, 2024
Hi @oirfeodent
sorry for the delay, but the only thing that makes me hesitate to release a new version is the reported crash.
Unfortunately, I haven't yet found out what could have caused it.
I have implemented a crash handler and run some tests, but so far I have not been able to generate a situation that leads to a crash.
Because of another problem with the lsp plugin I am currently trying to figure out how I can best implement a fuzzy testing framework with PythonScript.
This could also help here.
ARCHE7YPE commentedon Oct 1, 2024
Experimental version link is 'not found'. What a pity
Ekopalypse commentedon Oct 2, 2024
@netcraftz sorry for the inconvenience, yes it has been removed due to the reported crash.
I'm on vacation starting Monday, next week, which means I can spend some time working on this problem then.
github-actions commentedon Mar 25, 2025
This issue has been automatically closed because it was marked as invalid and received no response in 4 weeks.
oirfeodent commentedon Mar 27, 2025
@Ekopalypse thx for reopening this.
Is there any news?
Regards,
Ekopalypse commentedon Mar 27, 2025
Sorry for closing this issue in the first place, it wasn't intentional.
I was playing with github actions and messed it up ;-D
Yes, I'm working on the next version, which will hopefully solve all the current issues