Forum Replies Created
- Posts
just the file name without the extension
To my knowledge EmEditor has not got a document name without extension property.
In JavaScript I’d do the following:
let bareName = ""; let iLastIdx = document.Name.lastIndexOf("."); if (iLastIdx > 0) { bareName = document.Name.substring(0, iLastIdx); } OutputBar.writeln("bareName = «" + bareName + "»");Its
document.FullNamerather thandocument.FileName.
file:///C:/ProgramData/Emurasoft/EmEditor/Help/en/macro/document/document_fullname.htmlI’ve adapted the list bookmarks macro for this task:
List all finds by repeating the most recent search.
Usage:
1) Find any match using EmEditor’s find dialogue.
2) Run the macro.
The macro will then list all occurrences in the output bar.Example output
The macro is configurable:
● Find in all open documents.
● List the entire line Y/N.
● List the find Y/N.
● …I’m glad it helps and thank you for the feedback :)
The other navigation option would be to use the outline bar with custom regex.
But getting the regex right can be a pain and only the current document is displayed.
(?#_text_c==0)"[^/]*?"
Isn’t exactly a fix as it makes it impossible for the string to contain a /.
Side note:
The regex I use in the example are intentionally simplified for the sake of illustration.
The regex to match a string actually is(?#_text_c==0)".*?(?<!\\)", which in the example is simplified to (?#_text_c==0)”.*?”.Yes, thank you for asking!
While the formatting is a lot better, there is the following shortcoming:Rather than not applying a rule,
(?^#_text_c==0)only postpones a rule’s formatting untilc==0.
This can lead to incorrect formatting.Example case (simplified regex):
Rule 1) Format javascript strings(?^#_text_c==0)".*?"
and
Rule 2) Format javascript template literals(?^#_text_c==0)\/.+?\/
On line 2:
The formatting between the «; "» is incorrect.
And rule 1 is not applied to «"a string"»If it were possible to set
(?^#_text_c==0)to ignore (i.e. not apply) the rule rather than just postpone its formatting, then this shortcoming would be solved.You could display them in the OutputBar.
I’ve adapted a script of mine with respect to listing bookmarks:
list_bookmarks_in_the_output_bar.jseeExample output:
Perhaps this helps.
Thank you! 🙏
I’ve just adapted my JavaScript highlighter template and the results are fantastic:
String and regex literals now render really well 😃.
With respect to single line highlighting EmEditor now is perfect for my needs.The only thing I do not have a solution for is multiline matching.
As an example: For the JavaScript multiline comment/*…*/one could use the regex
(?#_text_c==0)\/\*.*?\*\/with the /s flag:
Should something like a
/sflag or a directive
#Keyword color=10, …, regexp=on, multiline=on
be possible, then EmEditor’s highlighter would be one of the best I’ve ever seen.Essentially I need the following (using the regex matching example at the top):
(?#_text_c==0)″.*?″ (?#_text_c==0)%%.*$I.e. apply the highlight only when the start of the match uses
SMART_COLOR_NORMAL = 0This works fantastically well, but only on odd lines:
→ Line 1, 3, 5 and 7 are correct.My test file is UTF-8 with LF as line terminator (no CR).
I cannot thank you enough for taking time for this!
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!
Patrick
