Cash should read Crash
Thought I'd entered this already, but it isn't showing up.
Please increase the size limit for Notepad++ At the moment it seems to be about 500 MBytes. It should be AT LEAST 4 GBytes. I have to edit files up to over 1 GB, and have had to switch to EmEditor which can open files up to 248 GB!
@eastpak1980 and @tateu :
I posted crash issue fixed binary here (about select all + paste):
Please confirm me if the crash issue is fixed.
Notepad++ doesn't have a memory limit. Your machine does, and Scintilla consumes a fairly high amount of bytes per document character. Plugins also do sometimes.
So yes, you need to switch to specialised editors for the specific task of editing very large files like 1Go or above. They offer different features as I cannot think of man made 1Go source file.
To the google-accounts poster regarding file sizes:
32bit Windows processes can access 2GB of memory, 3.5GB using a special switch and some trickery, which may or may not be supported by scintilla - probably not. In order to access more, you need a 64bit process. Compiling Notepad++ for 64bit support is non-trivial - I know, I've done it, and although I got it as far as working, I never managed to load a 2Gb+ file in. Scintilla's not designed for it, and actually using an editor that doesn't load the whole file in is the correct way to go.
Choose the right tool for the job :)
(Hi, I am the 'google-accounts poster' - I hadn't realised that logging in via my Google Open-id would not show a name; I've now registered a Sourceforge account too so should not be quite so anonymous in future.)
Cchris: I'm running Windows 7/64 with 16 GB of real memory + more of virtual, so I don't think my machine is the problem. However, as Dave says, as Notepad++ is a 32-bit program it can only address 2 GB, (unless the IMAGE_FILE_LARGE_ADDRESS_AWARE switch is set at link time, which should allow up to 4 GB).
Of course that doesn't mean it could never edit larger files, but I can imagine that would require a LOT of work if its present design assumes the whole file is loaded into memory. I remember editor design from the days you only had a few k of RAM; it was quite complicated keeping track of what was in RAM and what was only on disk without making the editor very slow.
Pity though; I like Notepad++ and use it for all my text editing needs from tiny Perl programs to inspecting the massive data files I'm building database load code for as part of my job - but now I'm getting files too big for it. I've found an editor that CAN load very large files (EmEditor) but it's not Open Source.
Hopefully there'll be a 64-bit version of Scintilla and Notepad++ eventually; sorry I have neither the time nor the expertise to develop that myself.
why don't you post this request to Scintilla team.
See what they have to say about it.
Maybe Niel changed his mind:
Good idea, Loreia.
I've added a feature request to the Scintilla tracker, though as I don't know the exact details of why Scintilla is inefficient for large files it's a bit vague. Hopefully Neil will not give the same answer he gave in 2003 to the request you cited.
Well. at least you tried.
Indeed, Loreia. And he hasn't closed it yet - though I see someone has set it to Low Priority, so I won't hold my breath waiting for something to be done. Pity I don't have the time (or even know how at the moment) to take him up on his suggestion to fork the project with a 64-bit version.
Dear developers, I use your editor for a long time, never had any problems, but really want a new design interface of your program, such as Sublime Text2, when the launch of the new interface?
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.