Hello, Vasile,

My updated regex ( See the second post, above ) works perfectly well, even if I insert your expression – Mother is home –, in a list !?. For instance, the original text, below :

aaa ccc bbb ddd aaa -- Mother is home – eee ddd aaa fff -- Mother is home – -- Mother is home – ddd ggg hhh -- Mother is home – iii hhh iii

with the S/R :

SEARCH : (?-s)^(.+\R)(?s)(?=(.+\R)?\1)|^\R

REPLACE : EMPTY

will be changed into :

ccc bbb eee aaa fff ddd ggg -- Mother is home – iii hhh iii

=> It did keep all the unique lines AND the last item of all the duplicate lines, whose your string – Mother is home – !

Cheers,

guy038

Plus 100 to this. Been meaning to log such a request many times.
Please don’t notify the user about change to the file UNTIL they click on that tab, or at least make it an option alongside ‘Update silently’. Thx.

I guess, an ability of defining own language highlight rules is one of the differences.

Hello, Markus-Ruhsam,

Of course, it’s a bit late, by now, but here is a shorter regex, that works perfectly well !

SEARCH (?-s)^(?=.{10}\.).+\R

REPLACE EMPTY

Et voilà !

Notes :

The first part (?-s) is an in-line modifier, which ensures that the dot meta-character will match only standard characters, even if you previously checked the . matches newline option

From the beginning of line ^, the form (?=.{10}\.), also called a positive look-ahead, verifies if the condition Does exist a DOT character, in column 11, of the current line, is true.

The important thing to remember about look-arounds is that, as soon as the condition is evaluated, the regex engine position is reset to the position before evaluating the look-around condition. So, in our case, to the position just before the first character of each line

Consequently, if this condition is true, the following part of the regex .+ matches all the standard characters of the current line

Finally, the \R syntax matches any kind of EOL characters ( \r\n ) in Windows files, ( \n ) in Unix files or ( \r ) in Mac files

Now, as the replacement string is empty, that means that any complete line ( with a dot character at column 11 ) will be, automatically, deleted !

Best Regards,

guy038

Well, I didn’t expect UDL to be capable of doing it at the moment, as far as I could read the documentation, but it might eventually enhance a constant literal rule from only covering a subset of ASCII numbers (e.g. +1,024.50 or 6.19e-23 won’t be matched either, afaik) to some more complex definitions, where the time definition might find its place :-)