Forum Replies Created
- Posts
The %% is just for the sake of illustration.
I came up with the idea of using regex expressions for highlighting from other highlighters.
In the case of highlighting javascript these are:
[1] https://github.com/pygments/pygments/blob/master/pygments/lexers/javascript.py
[2] https://github.com/speed-highlight/core/blob/main/src/languages/js.js
and several others.To highlight javascript regex literals,
/…/one can, for example use (from [1]):
\/((?!\/)[^\r\n\\]|\\.)+\/[dgimsuy]*
And to highlight template literals ‵…‵
‵(?:(?!‵|${).)*?(?:‵|\${)
}(?:(?!‵|${).)*?(?:‵|\${))The problem is that these two interfere:
I’ve written several variable length regex based highlighters for Python, Javascript, PowerShell and more. These work well, but only up to the point where they don’t overlap with another variable length regex highlight definition.
I’ll consider adding an option to control how regex is applied in situations like this.
This would be awesome 😃.
I realise that I’m just one customer, so please first focus on what’s most important for EmEditor rather than my request. Should you find the time, then I’ll greatly appreciate the effort.
Thank you, Yutaka!You could do the following regular expression search, limit it to the selection(s) and count the matches:
.*
EmEditor’s status bar will display both the number of lines and the number of selections.Moreover, the search could be automated in a macro.
PS Though, I’d suggest to first wait for Yutaka’s opinion on whether this is intended or rather an oversight that will be fixed in one of the next updates.
What you could do is bookmark the lines in the selection(s) (Ctrl + F2) and then remove the bookmarks (Ctrl + F2).
However, this will only work well when your document hasn’t got any pre-existing bookmarked lines.Sorry, just realised that what you mean by “highlighted lines” is “lines in the selection(s)” rather than bookmarks.
In my case EmEditor’s behaviour with selected lines is just as you described.Perhaps you ticked the wrong boxes.
“Tools > Customize… > [Status] > [X] Number of Lines”
Actually reads
Number of Lines (in the selection/total)
So this has nothing to do with bookmarks.
The option to display the number of bookmarked lines in the status bar is.
Tools → Customize… → Status → Bookmark Count in the Entire DocumentIn version 25.2.0 the status bar then displays.
… | 0/7 lines | 4 Bookmarks4 Bookmarks actually means “4 bookmarked lines”. Adjacent bookmarked lines are counted individually, i.e. are seen as separate bookmarks.
Now I get it, and the behaviour is consistent.
When, for example, selecting «cde» and searching for «cde» in the selection, the search also fails.
Thank you for clarifying 😃.
I’ve just purchased an annual subscription. While I’ve been on a lifetime licence since 2015, I thought it was time to say thank you for 10 years of support.Ah 😀 💡, thanks for pointing this out! And sorry, I should have noticed myself.
This basically means that finding in a one character selection fails with both the search dialogue and the macro:
I spent a bit more time on this and it seems that Find in the Selection Only has some additional quirks.
1) EmEditor doesn’t update the search range when selecting a new one.
2) EmEditor collapses the selection when it contains only one character (found or not).In the following examples the macro code is:
nFound = document.selection.Find("d", eeFindNext | eeFindReplaceSelOnly); status = "nFound = " + nFound;
And the find dialogue settings are:
Example 1: EmEditor search range.
In the following example EmEditor incorrectly uses the previous search range when searching in a new search range.
1) Restart EmEditor
2) Select the left abcd.
3) Find d in the selection (dialogue or macro). → Selects the left d ✔
4) Select the right abcd.
5) Find d in the selection (dialogue or macro). → Selects the left d 🤔
→ EmEditor used the previous search range rather than the current one.Example 2: EmEditor one character selection collapse.
1) Restart EmEditor
2) Select one character, e.g. d
3) Find d in the selection → the selection collapses 🤔 (inconsistent with point 5 below).
4) Restart EmEditor
5) Select two characters, e.g. cd
6) Find d in the selection → the selection does not collapse (my preferred behaviour).
Btw: When selecting cd and searching for cd, the selection also doesn’t collapse, which is the expected (and in my case preferred) behaviour.Hello Yutaka,
Thank you for your feedback so far!
This is currently by design, as ” and // are given higher priority than other general highlights.
Perhaps you missed my last example, where
"and//are disabled and only regex highlighting is used (guess I posted too many examples).Motivated by your response, I’ve now looked into this a bit deeper and narrowed down the cause.
The problem arises when a regex matches multiple characters, i.e. when using*or+or{3,}etc.The following is an updated example, putting aside
"and//:
Two regex matches are active, all string and comment matches are disabled.″.*?″regex match 1/2
%%.*$regex match 2/2Same problem:
EmEditor stops matching″.*?″as soon as it encounters%%.*$, even though the regex match for″.*?″has not yet been completed.
Would this be difficult to fix?
Because it is a serious limitation. One could write much more accurate highlighters than what is currently possible.Your help is greatly appreciated.
Many thanks!
PatrickSame here.
It appears that EmEditor completely ignores the
Restore window position and Restore window size
settings in
Tools → Customize → WindowThanks!
In hindsight this question of mine wasn’t properly thought through.
Normally I would have used the output bar (OutputBar) for status updates, but my code already used it for messages other than status updates.
What I’m now doing is store the text for the output bar in a variable, which allows me to show status updates in the output bar.
Once done the OutputBar is cleared and the output text written to the output bar.Perhaps the following approach is easier for you:
Find:^(\d:\d\d)\n
selects x:xx located at the beginning of the line (^)
Replace:\1\t\tRe-pastes xx:xx (\1) and adds two tabs (\t)
OR:0\1\tPastes 0 followed by xx:xx (\1) and adds one tab (\t).Find:
^(\d\d:\d\d)\n
selects xx:xx located at the beginning of the line (^)
Replace:\1\tRe-pastes xx:xx (\1) and adds one tab (\t)Find:
^(\d:\d\d:\d\d)\n
selects x:xx:xx located at the beginning of the line (^)
Replace:\1\tRe-pastes x:xx:xx (\1) and adds one tab (\t)Adapt according to your needs.
To replace all expressions in one single go:
Use EmEditor’s batch replace feature (Find / Replace dialogue box → Batch >>).
Batch replace also allows saving and loading your find/replace definitions (import / export).Eeek noticed a mistake.
The following is wrong.
Find ^0:
Replace 00:Instead:
Find^(?=\d:)
Replace0Sorry.
First a suggestion:
Consider replacing the timestamps below 10 minutes:
0:xx
with
00:xx
This will make the number of tabs consistent across all times below 100 minutes.The regex for that is:
Find^0:
Replace00:Then replace the newlines after the timestamps with a tab.
Find(?<=^\d\d:\d\d)\n
Replace\tShould you need assistance on what the regex above does:
https://regex101.com => paste the regex and a transcript.Hope this helps.
Patrick—
Remarks:
1) I’m assuming that you have no leading or trailing whitespace.
2) Find/Replace Options → Advanced button: Boost engine with all options unchecked, additional lines is set to 0.Semi-Educated guess:
Could be due to the legacy JScript and VB Script libraries. Windows 11 has been messing around with them for a while now and they are marked for removal.
Compare:
https://techcommunity.microsoft.com/blog/windows-itpro-blog/vbscript-deprecation-timelines-and-next-steps/4148301
https://learn.microsoft.com/en-us/answers/questions/2130135/jscript-runtime-error-in-windows-11-24h2Potential workaround hack:
If you don’t mind experimenting at your own risk, you could try copying Jscript.dll and vbscript.dll to the same folder as EmEditor.exe (note the 32bit vs 64bit versions).
https://www.dll-files.com/jscript.dll.html
https://www.dll-files.com/vbscript.dll.htmlMight help, might not or not quite enough …
… → note that further dlls could be required.I think I found the root cause:
With
Treat CR and LF Separately disabled
and radio button Regular Expressions enabled.EmEditor’s Find in Files will interpret \n as LF as soon as the search term contains a regular expression token or actual regular expression.
Without a regular expression token, EmEditor behaves as if performing a Escape Sequence type search, presumably because this will speed up Find in File’s performance.{ and } are regular expression tokens, but most engines will treat it as a regular character until written as a complete regular expression, e.g a{3} for aaa.
Most of this is in line with EmEditor’s Help, which states:
● Find dialog box → Regex on → \n or \r\n (same meaning)
I.e. \n will match both CR+LF and LF.
● Find in Files dialog box → Regex on → \r\n, \r, or \n (depends on actual newline character)
Elaborated further in EmEditor Help → Tips
which explains that \r strictly matches CR and \n strictly matches LF, …… what is not explained in help is that
1) the Find in Files regex search will fall back to an escape sequence search when the search term does not contain at least one regular expression token
2) escaped regular expression tokens as in\{, are no longer identified as regular expression tokens, with Find in Files then performing an escape sequence type search.Hello David
Sorry, I should have read your initial question more carefully, as you did explain that To be strange , img \{\n works.
I just tested this with EmEditor Version 24.4.0.
When selecting Escape Sequence instead of Regular Expressions, both Find and Find in Files work with
img {\n.When selecting Regular Expressions (with the Boost.Regex engine) …
… and with Treat CR and LF Separately deactivated …
… and searching forimg {\n:
● The regular find (not in files) works, regardless of CR+LF or LF line endings.
● Find in files will not find CR+LF, but it will find LF line endings.After experimenting a bit …
When using Find in Files with Treat CR and LF Separately deactivated:
As soon as the Find term contains a { or a }, \n seems to exclusively find LF but not CR+LF. This even when { is followed by text before the \n.Example:
Line 1 { abcd Line 2 def { abc Line 3● Find in Files searching for abc\n works with both LF and CR+LF line endings.
● Find in Files searching for def { abc\n works only with LF line endings.
Adding a closing bracket as inLine 1 { abcd Line 2 def {a} abc Line 3won’t help either, i.e.
● Find in Files searching for def {a} abc\n works only with LF line endings.What also won’t help is a complete regex, e.g. find
ab{1}c\n.
……
Its as if { or } behave as a token to let \n match LF but no longer match CR+LF, even when Treat CR and LF Separately is disabled.As to why this is: Good question.
I guess that this is for Yutaka to answer.Cheers,
Patrick
