perfetto grazie

@Alan-Kilborn thank you very much for pointing that out!

@Joseph-Newcomer

UDL has its limitations, one way to overcome those is to use a script like this.

Is your gawk udl available for download if one wants to make some tests?

God, it can’t be,
better not to change.

Just read better the title.
Moving from UTF8 wo/BOM to UTF8 w/BOM is not a conversion. All that need to be done is add 3 BOM bytes to the beginning of the file. Just be sure not to add them twice. So basically create a 3 byte file with BOM and do something like (I don’t remember the exact copy syntax of Windows):
copy bom.txt+file.txt file_new.txt

Read this to understand Unicode and encoding. You should realize that UTF8 w/BOM is a pretty stupid concept. So unless you need to feed your file into an application that requires UTF8 BOM stay with UTF8 wo/BOM.

תודה רבה!

@Atanvarno-Aldarion

Yes, there is, and it’s called the PythonScript plugin.
Probably any other scripting plugin can do this too.

Here is an example of what it might look like.

names = [ 'HARRY', 'RON', 'HERMIONE', ] template = ''' STUDENT {0} IS: NAME: {0} ID: 1-{0}-2 BIOGRAPHY: {0}'s biography follows. ''' editor.appendText('\r\n'.join([template.format(x) for x in names]))

@Michael-Eve

Define your UDL and create folding points.

thanks, guys it worked, both of your solutions worked

Hello, @vasile-caraus and All,

In fact, I’m presently on holidays ! Thus, my concentration is not at top level ;-))

So, here is the true story ! When using, for the second regex S/R, the simplified form :

SEARCH (?s)<meta\x20name="keywords"\x20content="\K(\w+)|\G[^\w\r\n]+(\w+)

The first alternative <meta\x20name="keywords"\x20content="\K(\w+) should be used first, in order to detect the first word after the string content="

However, if before running the S/R, the caret is at a location before some non-words chars, followed themselves by some words chars, then the regex engine wrongly selects the second alternative , due to the \G syntax

So, this new simplified syntax can be used if the initial location of the caret is on an pure empty line. Indeed, as the initial \G location must not be followed with, both, \r or \n ( \G[^\w\r\n]+...... ), this means that, necessarily, the next match will come from the first alternative of the regex, which is the correct solution !

But, of course, this new simplified regex is, then, no related, anymore, to a previous <title>......</title> tag !

BR

guy038

@Kendall-DeMott said in Files History:

it forgets the ones used a lot, and retains some of the oddball ones

If you use them “a lot”, wouldn’t they be in the 15 ?

Is there anyway to delete items of of the search history window?

Not on-demand, no.

Or a way to put often used phrases in there like favorites list, etc.

This is kind of a frequently asked for feature.
Sadly, no one has come up with a great idea for implementing it, or perhaps no developer has tackled it.
I think a workaround is to keep a file tab dedicated to such “phrases”.

Notepad ++ and Admin mode keep different search histories, it would be nice if they were synced (same).

That seems like it would be a security breach.

@Muhammad-Al-A3sar

We either have a case of CLICK HERE or if not that a case of CLICK HERE.

@Amsja-Mull said in File too big for notepad++:

I’ve read that notepad++ is capable of handling 2gb

Additional information can be found in some old posts:
https://community.notepad-plus-plus.org/topic/11803/feature-request-larger-file-sizes-allowed/2

https://community.notepad-plus-plus.org/topic/18950/file-size-problem-file-is-too-big-to-be-opened-by-notepad/6
notes that having a file type of .txt is likely to allow a larger file to be opened than other file types which are associated with “lexers”.

https://community.notepad-plus-plus.org/topic/16960/text-limit/16
where it is noted that scintilla (upon which Notepad++ is built) has a hard limit of 2GB. Maybe this is what you thought would allow your 600MB file to work.

However this is more a “theoretical” number that can NEVER be surpassed. However as I stated before the environment Notepad++ is running in and even the file type have a lot to play in how successful you will be in loading such a file.

Good luck
Terry

@Sherif-Hemida ,

It was an intentional change in v7.8.7, because find-previous doesn’t work how you think it will with regular expressions enabled. Find previous is still enabled for regular searches.

See the instructions in the official docs for a config file change to make it work with regex, with the caveat that reverse-direction searches with regex sometimes yield unexpected results: https://npp-user-manual.org/docs/preferences/#preferences-for-advanced-users

Thank you, for your answer,

now i have checked a liitle bit more and i found the master.bat start with an mtee splitter.
(http://ritchielawrence.github.io/mtee/)
“test.bat” 2>&1 | mtee_versions\mtee.exe /C “test_bat.log”

Without the splitter notepad++ works as expected.
So i think there changes from microsoft in windows.

@Gabriel-Pelayo

how do you replace it? Can you give us a screenshot from your
replace dialog? In addition, can you post the debug info from the last menu, the ? menu?

Hi @Michael-Charney

Try to select all files in reverse order. For example, if I want to get the files ordered as 1-3, I select first the 3, then the 2 and finally the 1. These will be copied in Notepad++ in order 1-3.

Tested and worked in my Windows 7.

Take care.

Thanks for the answers
It worked by editing %AppData%\Notepad++\ shortcuts.xml and then merging the pieces

I like the test word chosen here.