Is changing to bold font possible part of EnhanceAnyLexer

[oirfeodent]

From the documentation, I see only foreground color can be changed... In addition can we make it bold in any way?

Regards,

[Ekopalypse]

@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]

+1 and if possible, please add italic, underlined and font size too.

[Ekopalypse]

@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]

@Ekopalypse ok... hope you are in a position to get it working. Thx.

[Ekopalypse]

@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]

@Ekopalypse wow looks great!!! Looking forward.

Regards,

[Ekopalypse]

@oirfeodent, @bobcate, @Weber-Frank

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

[Weber-Frank]

Wow, that's almost what i wanted. but i have still 2 problems with this version:

1. 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?

2. 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]

@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]

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:

[global]: style_50=;0x5A9FF3;;;;; 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]

@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]

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]

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]

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]

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.

Thanks for testing and reporting the problem.