Efficiently handling large text files requires extra special care.
~2x memory looks like a naive implementation of just allocating an std::string from heap for each line. Due to heap fragmentation and various overhead it would quickly blow up.
~1x memory looks like just reading the entire file into RAM (that would still be slow).
A truly efficient implementation would never need to load the entire original file in RAM. It would just need to remember the binary offset of each line in a way that combines random access and reasonably fast insertion/deletion (e.g. K-fold trees). You can even keep everything beyond the top-level directory in an temporary on-disk file, so your RAM usage could be less than 1MB with nearly instant performance.
The efficient implementation is tricky, error-prone, and involves handling a solid amount of corner cases, which is beyond the amount of hassle a typical hobbyist developer is willing to go through.
> A truly efficient implementation would never need to load the entire original file in RAM. It would just need to remember the binary offset of each line
Except that this would most likely result in unpredictable corruption if another process modified the file while you had it open, which is contrary to the way basically every text editor works.
It would be nice if there was a way to mmap a file in such a way that the OS would give you a snapshot view, but AFAIK that doesn't exist, at least on Linux in a filesystem-agnostic way (not sure about other operating systems).
I think every platform supports FS notifications at least right? The app could listen for changes to the file and reload/discard when it goes out of sync. In fact Notepad++ already does this.
On Windows in particular you also have a ton of other facilities that could help with this (opportunistic locks, transactions, etc.) but notification is usually good enough.
My main editor is vim. It notifies the user when a file you have open in a buffer gets modified on disk by another process. It explicitly gives you the option to load the file from disk at this time. I would not use a text editor which silently reloads a file because this could result in a loss of work.
Not necessarily. It's possible to listen for file updates and respond accordingly on the fly by re-reading the file and updating all your offsets and mmaps. It doesn't even have to be efficient; it's not a common case.
> This would also be too slow. The user may want to jump from line 1 to line 999999. You can't do a file load fast enough.
My text editor supports files up to 256 GB in size, unless you have that much memory, you’ll have to wait a little bit to go from the first to the last line.
I use UltraEdit, it opens files way beyond hundreds of GB without issues, both text and binary (in hex edit mode). Love that editor for over 10 years (perpetual license) on Windows, Mac and Linux. See the video loading a 35GB text file: https://www.ultraedit.com/support/tutorials-power-tips/ultra...
This is why I will always pay for the latest version of Sublime Text. First to support indie developers, but second for the marvelous piece of software that allows me to browse gigabytes of data in a GUI.
I've been using Sublime Text for a decade and never had any reason to leave it. It's been pretty much the most valuable piece of software that I use daily for a big chunk of my career. I've had to buy a new license maybe twice? ST2 and ST3. And another for Sublime Merge. The $100 or whatever it was might as well be _zero_ compared to the amount of value I've gotten out of it. I love this thing.
I thought Sublime's popularity has grown in recent years? Was it even more popular in the past or am I mistaken? It's just that compared to the standard vim vs emacs debate, I now always hear sublime thrown in for good measure when discussing pure text editors.
I last used Sublime Text in early 2014 and the same is true for most of my friends.
It is a lot more performant than VS Code, but VS Code seems to have won on the sheer quantity of “good enough” plugins. Its pair programming features are a big deal as well.
For the most part I use VIM for quick things and VS Code when I need a plugin or to work with others. SBT kinda sits between those two extremes.
The pair programming feature from VSC is the only one I’d really miss from that side if I were to go back to SBT. Not sure about from the VIM side because I’m sure the SBT VIM plugins have improved over the past 8 years.
Everyone I worked with in about 2014 swore by sublime text. A few years later it lost a ton of ground when Atom was released (and then forked to make VSCode).
> A truly efficient implementation would never need to load the entire original file in RAM. It would just need to remember the binary offset of each line in a way that combines random access and reasonably fast insertion/deletion (e.g. K-fold trees).
To know the offset of each line, you'll need to load the entire file from disk. So you're talking about loading it, processing it, and throwing it out again. You should qualify calling that "efficient" since you will need to re-load portions of the file, as needed.
Also, an OS's virtual memory systems may work well for you with minor tuning, so it's work looking into that before you spend a lot of time essentially writing your own.
I think unless you have a good reason not to, your best bet for a text editor on a modern OS is to read the entire file into memory and leave it there. (But don't make multiple copies of it or use two bytes to store each character as the current version of NotepadNext is apparently doing.)
> To know the offset of each line, you'll need to load the entire file from disk.
No. You will need to read the file, not load it all at once in memory. And for a sequential scan, you need very little memory at any one time.
And if you are doing that, you can start displaying the file as soon as you have scanned enough to fill the view. The rest could happen in the background.
I didn’t say you had to keep it all in memory to process the line ending. Of course you don’t. You need only two characters of memory (assuming you’re handling windows line breaks).
With a 64-bit address space, you're probably better off just mapping the entire file into memory, not specifically loading it all. Let the OS swap in and out the pieces you need as you access it (and build your index of line offsets or whatever other structures you need).
The big advantage to mapping is that you only read from disk the portions of the file you need, and only when you need them. Disk access is monumentally slow, so this can be a big win: if you don’t need to access all of a large file, or don’t need to access it all at once, mapping saves you very expensive operations or spreads them out over time.
The problem with that for a text editor is that probably the first thing you want to do is process the line endings. So you’re just going to access the entire file, right away, as fast as possible anyway.
So mapping doesn’t really give an advantage in this case.
> Due to heap fragmentation and various overhead it would quickly blow up
I think this is mostly likely the culprit. There almost definitely isn't that much contiguous memory available for a large file like this, so there are a lot of wasted pages (maybe 2-3x) which is causing that footprint to balloon.
For 500MB there should easily be enough contiguous virtual address space, and if there isn’t the allocation would fail. I don’t see how it could take up 2-3x extra pages unless it’s being stored in a really poorly designed segmented memory structure.
Yeah without knowing anything about the implementation when I see "I opened a 500MB file and it's taking 1.3GB of memory" that's just my first guess. Maybe it's wrong.
How it can be nearly instant performance if you have to load data from disk on demand? If users jumps a few pages, or he performs a search or replace, things will get real slow.
We wouldn't use large quantities of RAM today if there were any techniques that could make disk acces "nearly instant".
Seems like anything past a few megabytes would really be better done with dedicated tools for that amount of data.
I think I'd be a bit unhappy if I was regularly loading megabyte blobs of text into editors, and start looking at other representations or tools.
The only files that big that I know of are log files, and very occasionally a CSV or two as some kind of data dump, and there's usually dedicated tools for those cases.
~1x memory looks like just reading the entire file into RAM (that would still be slow).
It's worth keeping in mind that typical CPUs from the past few years to today have memory bandwidths of several GB/s. Disks have sequential read speeds of ~100MB/s; SSDs can easily do 1GB/s and above.
It's vaguely reminiscent of Vim's implementation, in the sense that I think, for large files, in it's default config, Vim keeps most of the text in it's swap file and pages it in as needed.
Vim's implementation also feels somewhat line-oriented in that if you load a large JSON file that has everything on 1 line and you try to edit that line, uh... it will be sluggish, but if you do, like %!jq '.' and format it, you can them move around the file a little easier.
Edit - What the heck while I'm at it:
Emacs - Historically used a Gap-Buffer which optimized more for locality of edits than loading large files. It doesn't suffer though as much from heap fragmentation though as the linked-list of strings type approach.
Monaco - The editor in VS Code recently went from a linked-list of strings to a PieceTree buffer. Which basically loads a the whole file into an immutable buffer and then uses the PieceTree to manage the edits.
Others - Lately people keep talking about Ropes, which is another tree type deal with extra-smarts specifically for text editing. I don't know of a game-changing editor like the others mentioned that uses it tho.
Ropes were introduced in this paper in the journal Software, Pracise and Experience:
https://doi.org/10.1002/spe.4380251203
(best accessed from a university domain)
> 2x memory looks like a naive implementation of just allocating an std::string from heap for each line. Due to heap fragmentation and various overhead it would quickly blow up.
Looks more line Qt's internal UTF-16 encoding in this case.
Never fear, Emacs approach is pretty great. It uses a gap-buffer, which is conceptually an array with a space that moves around with the insertion point. It's pretty cool approach because, it's simple, there's very little bookkeeping overhead and moving around the gap is gonna generally be cheaper than shifting around the whole array and minimize complete re-allocations. In other words it's good for what we do the vast majority of the time with a text editor which is jump around reasonably size files making small edits.
One downside, relative to this conversation, is it doesn't make working with pathologically large files a lot better. Without further optimization a gap buffer could push your box into swap if you open a large enough file.
I love gap buffers because it was super simple to implement. I struggled with ropes and certain tree based algos when I wrote a terminal based text editor in Nim
Also if the file is 500Mb, probably a text editor isn't the best choice of app to work with it. That said it is often the most convenient. But a 'non loading' text editor would be interesting for this. E.g. it doesn't show the file, but you can still do find in file etc. operations. Maybe basically a thin UI around grep etc.
Let me rant for a bit because I've dealt with the following: Another downside is you'll get people complaining about memory usage despite mmap only paging in what's needed.
It's frustrating but users don't understand how to read memory usage at all. There's even guides out there quite wrongly telling users to look at virtual memory usage for each app.
Mmap is a brilliant way to have the os handle which parts of the file actually reside in memory but you'll seriously have to deal with users that know only enough to be dangerous complaining that your app uses gb of ram when it's merely mapping a file into virtual address space to allow the os to page as it sees fit.
In fact I wouldn't at all be surprised if the memory measurements in this thread were judging virtual allocation rather than physical memory used.
Because then all your edits have to go directly into the file, so you have no real "save" flow unless you make a swap file for every file and then mmap that (which can be an appropriate approach, to a degree). Then all your caching and memory use subject to OS I/O and filesystem concerns, and you can't optimize for specific use. And inserting or deleting the middle of the file means shifting all the bytes after it.
I could think of a reasonable implementation for Linux that would use mmap and fallocate, but it wouldn't "just" be an mmap, as the swap file would still need to represent a rope or a gap buffer or something else of the sort for efficient editing.
Aren't edits of a huge file expected to be comparatively small? If you're editing an mmap'd file, I'd expect the editor to maintain a display combining the original mmap'd file with a list of changes that have been performed so far.
I would be surprised if they use straight QStrings. Text editors typically use more sophisticated data structures for their text buffers - Ropes, Piece Tables, Gap Buffers, etc. - tuned for efficient text operations. Maybe their implementation has memory overhead? Wouldn't Notepad++ use UTF-16 internally too, with its Windows heritage?
> I would be surprised if they use straight QStrings. Text editors typically use more sophisticated data structures for their text buffers - Ropes, Piece Tables, Gap Buffers, etc. - tuned for efficient text operations.
Sure, I didn't mean to imply that the whole document would be one giant QString. But those data structures might still use a QString as backing memory in the new implementation. I tried to have a look around, but didn't have too much time on hand to dive deep. I could see some QString usage but couldn't confirm if the document itself uses it for storage.
> Wouldn't Notepad++ use UTF-16 internally too, with its Windows heritage
Not necessarily, as the memory consumption of 586MB for a 500MB file shows.
I'm having trouble finding anything in the source tree, but searches on "QTextEdit" and "QPlainText" fail, so it's maybe not using Qt's very competent text edit classes? The Readme indicates Qt is used, it would be odd not to use the built-in (but highly customizable) editor which supports a syntax analyzer and lots of other things you would think this project needs.
I checked with heaptrack, the big allocation seems to be within scintilla data structures (which should be the same on notepad++ if I'm not mistaken ?). So likely some suboptimal thing here like having some cache somewhere which does not matter for the average text file.
Dealing with large files or huge number of open files is something where Notepad++ really shines, it's basically the reason you would use it for text files instead of VS Code, IMHO. I've had Notepad++ open many hundreds of files in single sittings to do file exploration, data-cleaning and really aggressive regex search/replace. It's obviously smart about how to deal with this without locking up the application.
Definitely my goto editor for non-code files. I've wondered if emacs can do the same, but when I've asked an emacs user responded with "Why would you want to open 800 files?" I take that as a "no"?
> I've wondered if emacs can [deal with large files or huge number of open files] […] I take that as a "no"?
Emacs handles it fine. Two years ago¹, I wrote this:
“Just last week I opened, edited, and saved, a 4 Gigabyte SQL dump file, in Emacs. It was a bit slower than usual, but still well usable, and certainly no crashes.”
That sounds like a lot, but most (power user) machines have more RAM than that these days. Are there any editors that can deal with files larger than available memory?
Another (esoteric) editor I use for quick and dirty hacks on Windows is Notepad2[0]. It's a bare-bones drop-in replacement for the default notepad.exe on Windows, and has syntax highlighting.
Notepad2 hasn't seen any updates since 2012. Unlikely to be a massive issue for a text editor if it is considered feature complete, though it might at least mean unfixed annoyances creep in and go unfixed with newer OS versions.
They seem to add a lot of features, though ... I'd be interested to find a more minimal one, which mostly just updates language syntaxes and OS support, and the thankless minor bug squashing ...
Your first link is flagged as 'badware risk' by uBlock Origin.
> Title: uBlock filters – Badware risks
> Description: For sites documented to put users at risk of installing adware/crapware etc. The purpose is to at least ensure a user is warned of the risks ahead.
Geany fills this niche, and is close to being feature complete. It could use help and attention as well, it unfortunately doesn't get enough imho. Also on github: https://github.com/geany/geany
Geany is mature and solid, and I like it a lot, especially on Windows. However, I personally bump into some uncomfortable limitations with it.
The pace of the development, including just reacting to issues or PRs is rather slow.
Basic editing functions are few (just compare the contents of the "Edit" submenu with Notepad++). This is partially mitigated by "Send selection to", but a text editor without a simple line sorting?..
The settings for the "Build" submenu is artificially limited. Why just 3 filetype and 3 shared commands? Why not allow changing the keyboard shortcuts for those right in the same window?
No macro or scripting at all. In my view, such programs benefit a lot from having all their actions available as a list of commands which can be used to construct custom chains and scripts or be used setting the keybindings.
Somehow, not all the lexers from lexilla are available? For example, Nim lexer is more than 3 years old (5, if you count lexer for an earlier version then called Nimrod), but Nim settings for Geany still uses the Python lexer.
Hmm, I don't do most of those things. Or, I use external tools/pre-commit/terminal so not a big issue for me. For example, a tool like "black" or "prettier" has outsourced a lot of the manual formatting work I'd have done before. I "write ugly" and save the file.
For sorting I do in fact use the "Send selection to" to sort, bound to Ctrl+1, but I never got around to binding anything to Ctrl+2.
There were tons of little fiddly things in Notepad++ I never used because the things they fixed they never came up often enough to build up muscle memory to remember them. YMMV.
Sometimes it's just more convenient when all the little things are already in place, even if you're not using them frequently enough to build muscle memory. Also, for reasons described in the comment by @AdmiralAsshat below.
I have a container I setup with XFCE and this awesome Windows 95 theme: https://github.com/grassmunk/Chicago95 Geany works perfectly inside it for a little retro dev environment. It looks and feels just like old Visual Studio versions, but I can code any modern thing I want.
distrobox to manage the container: https://github.com/89luca89/distrobox Then just install XFCE and tiger VNC server inside it. Using VNC makes it easy to connect into a little isolated session that has its own theming, etc. vs. trying to send geany to my native X11/wayland server (which wouldn't theme it like windows 95).
Geany was the first editor I used to write code. It has just the right balance of features to make editing code productive while keeping it simple enough for beginners.
These light IDE editors should really be including some support for modern features like LSP, Tree-Sitter parsers and the Debug Adapter Protocol. Modern development flows have come to rely on this stuff.
This also goes for terminal-based editors, BTW. The old RHIDE is in many ways still unsurpassed in the intuitiveness and inherent extensibility of its text-based interface. A modern *nix-based equivalent would find plenty of use for light development work over SSH. (You could even ssh in and develop from an Apple iPad with keyboard addon!)
Geany drove me insane when I tried it. The horrific font rendering that turned underscores into spaces, the obtuse as hell format for custom syntax highlighting... No thanks man.
OMG, i ran into this issue and what fixed it for me was...increasing the font size! Slowly over the last couple of years i have been increasing the font size everywhere (because my eyes are aging!)...and then i started using Geany - which i do like - but ran into this odd behavior of underscores appearing like spaces but only with some themes, fonts...And when i went to increase the font size - for just helping me see better - voila; no more odd behavior! Admittedly, this is not the reason i lessen my use of geany. But that sure was one odd bug.
> The horrific font rendering that turned underscores into spaces
I have geany open right now and it is displaying underscores just fine with Noto Sans Mono. I have no idea what configuration you were using or what fonts, but this shouldn't be a problem currently.
I was thinking "this user is just unlucky" but I installed Geany from scratch and indeed underscores are invisible by default for me too! I switched fonts and it works.
if the often-default font is "out of spec" then the software has a problem they should mitigate somehow. Maybe pick a different default font if they can. I saw this underscore problem as soon as I installed Geany.
Was a problem for a few years on some Linux distros, should all be fixed now. Wasn't even their bug. Workaround was trivial, increase the line height. Let's focus on something slightly more interesting.
If they can't even be bothered to listen to bug reports for such a simple and important thing then I have very little trust in their project.
This has been a bug for years after they closed the issue and as far as I am aware they are the only software to have ever had a problem with these supposedly out of spec fonts that are still the default on some popular distributions.
Can you define custom syntax highlighting as easily as in notepad++? My use case was that I had one big text file for everything with some ad hoc format.
You have to write hex codes into a text file in your config folder, there is no GUI for it. They have themes for a few years now. You copy one and edit. Not hard but not effortless either. One interesting thing is that you can do it in Geany, there is a little plugin to show a color square when you hover over a #hex string.
I remember npp having a GUI, but from memory it was old-school, in the clunky sense and not in the simple one. It didn't have a little window showing code with the updates for example.
Now that you bring it up, that's an area where a developer could make a helpful contribution.
The original Notepad++ source code is written for the Windows API, built for Windows releases only. This project seems to be Qt-based, allowing cross platform development.
It seems like someone thought "building a Notepad++ of my own seems like a nice idea" and went with it long enough for it to become quite a competent editor.
This reminds of the guy I used to work with that used Notepad++ with Wine on Ubuntu as his primary editor and he seemed to get along just fine with it.
It's been a hell of a paradox for me after switching from Windows to Linux that the two types of applications that I missed the most were good text editor (Notepad++) and good ssh connection manager (Moba Xterm).
Mobaxterm is great. However it's worth spending a little bit of time putting your hosts into ~/.ssh/config and using short hostname aliases to start your ssh sessions. I had switched to using mobaxterm as just a shell without saved sessions before I switched completely (back) to using Linux. With a properly set up ssh-agent and this config file you probably won't miss mobaxterm.
Looks like a cool project, not throwing shade, but these two lines in this order made me giggle:
Though the application overall is stable and usable, it should not be considered safe for critically important work.
There are numerous bugs and half working implementations. Pull requests are greatly appreciated.
Another one directly inspired by N++ is NotepadQQ. Tried it briefly and passed - mostly the functionality was lacking. Not sure if it's Scintilla based, as the original, Geany or TextMate.
You know what? I cared enough to run a search for "scintilla" on their GH repo when I wrote the comment and got zero results. Still wrote "not sure". That says something about GitHub's search, I suppose.
Nice to see this project, will try it out. When I moved from Windows 11 to Ubuntu I was really happy to find most of my daily use utilities in Linux or equivalents, but I was shocked there isn't a native version of Notepad++, its the kind of app you would expected to have multiple ports in several OSes. The version from Snap doesn't integrate well with Linux.
The record and play macro feature is probably the most useful tool, I keep grabbing code from VStudio/JetBrains-based editors to refactor/format it in NP++. For me the future of text editors should go in the automated direction: "see these identifiers and strings, tabulate them in columns to make my code more readable, now convert this column of strings into identifiers with given prefix and camel case, and define them in that module."
I remember thinking this exact thing back in 2007! Shortly before discovering Kate and fish://. At the time I think I used regex and scripting instead of macros though.
Notepad++ is a wrapper around scite using native windows apis or at least was years ago. Find a native editor using that library in same way such as SciTE itself.
It's reasonably intuitive for a non-technical user to use (since it has pretty much the same control scheme as the familiar Notepad), but has enough technical tools built into it that you can do some serious diagnostic work.
In my job I often have clients install it so that we can review their datafiles and diagnose load problems. Many of my calls sound like this.
(On Zoom)
Me: Okay, so I understand this file is not loading, can you show me the file?
Client: (opens file)
Me: Ok, hard to see what's wrong at a glance. Can you open the file in Notepad++ for me?
Client: (Reopens file in N++)
Me: Ah, here we go. You see those characters in blue on line 49? Those are non-ASCII characters. You've got some garbage in there. NULLs, control characters, or some other thing. Those will break the XML parser. Try removing them and reloading the file.
Or:
Me: So it looks like this is coming from your source system with no line endings, and is quite difficult to read. Can you download the plug-in XML Tools/JSON Tools/Poor Man's TSQL Formatter and let's see if we can get the files indented to make reviewing easier?
Or:
Me: So if you click on the "View" tab and show the line-endings...thank you. This file is coming over with Windows CRLF line endings instead of the expected LF endings on UNIX/Linux. It's probably throwing off the record parser by one byte for each row. You can use the tool under 'EDIT' to change the newlines to UNIX convention, and you should be good to go.
Small things like that. It's a heck of a lot easier to teach the client to do that rather than try to convince them to run dos2unix on a terminal.
This covers it. Trying to talk a normal person through vim is like doing a keyhole appendectomy through the urethra.
It's a handy thing to have on Windows for anything text-oriented. Having a dual-platform version would be a benefit as well, as probably 95% of Notepad++ users are comfortable on Linux as well, so it would be helpful to talk somebody through it over the phone without having to access the dusty recesses of their memory.
It uses CUA keybindings which everyone should know. If you're already invested in vim, there's not much benefit, other than not having to use different keybindings in different windows.
For a Vim user, this an alternative you would suggest to other people for editing files. ie, like its name suggests, if you can use standard notepad, you can use Notepad++, but you get more toys. I think its main advantage is it is fast, features are discoverable through UI, and out of the box it understands many kinds of filetypes and has a ton of features, macro recording, it has plugins with a plugin browser also. But as a Vim user, you don't really need it, though I do use it sometimes for random obscure things instead of Vim (like Mime encoding/decoding)
Sublime is slow though. Both loading and editing. For a native editor I would expect it to be fast and snappy (like Notepad++ on Windows or Textmate on Mac). But the speed and responsiveness is similar to VSCode. The Windows version of sublime is faster and snappier though.
I used Notepad++ on Windows; now on MacOS I use TextMate. It's as simple and lightweight as Notepad++, and if I understand correctly, it has the save feature you're looking for. If you Command+Q without saving to a file, the contents will still be there the next time you start it.
gVim (only on windows/linux) with a minimal config is my preferred. Fast but a few powerful built-in vim features like search, replace, syntax highlighting, spellchecking, auto-indent etc. It loads in about 1.5s on my machine and renders the text nicely.
MacVim is a great compromise between vim and standard Mac behaviour (like mapping the standard app shortcuts everyone expects). They keep their bundled vim version updated pretty well too. I haven't got any complaints about it (though I do still tend to run vim in the terminal out of habit), like I do with gVim on Windows.
I’ve used Notepad++ with Wine on Linux. It works fine. The only problem is it doesn’t handle high DPI monitor very well so the UI font is really small. It might be a problem with Wine.
Also the directory navigation in the file dialog is clunky. The directory places are windows based rather than Linux based.
I haven't tried myself, but is there any reason why Notepad++ wouldn't run on Wine? I don't think it accesses APIs obscure enough to run into usability bugs, does it?
It'll have some small issues, of course. From what I can read online some plugins don't work because they rely on the Windows Script Host (the thing that runs JS and VBS scripts) and there's a performance issue here and there, but that's about it.
The thing about games is that there's only a limited OS surface area that they'll usually touch. There's I/O, GPU, a single render Windows, audio, and input state, but when those core APIs work, games should run just fine. Boring Win32 software can get real dependent on some obscure system APIs, COM+ objects with certain properties, library loading behaviour, etc., all things that can be a challenge to emulate successfully without tripping up programs that assume certain APIs just never fail or return certain results. Games don't call APIs like DsRoleGetPrimaryDomainInformation or SHEnumerateUnreadMailAccountsW so projects like Proton don't usually add a lot of fixes in that space.
As someone who relies on Notepad++ daily, to the point of being seriously worried about finding a replacement when I am inevitably forced to switch to Linux[0], I am encouraged by my short time playing around with NotepadNext. It looks right, it feels mostly right, and the AppImage started quickly. Unfortunately it is still missing most of the features I actually use in Npp, but it is a promising start!
[0] Being real: I'll probably just run Npp in WINE
Which features of Npp are you struggling to find in other editors? I used Npp a bit a decade ago when I had to work with Windows but it didn't really have any stand out features (not a complaint, it worked perfectly for what I needed).
The one that I've not yet seen in an alternative is a simple way to implement simple custom syntax highlighting. Npp has the UDL GUI, but I don't even need the GUI if specifying what to highlight and how to highlight it is as straightforward as the UDL XMLs are. Sadly most things have either hardcoded syntax highlighting or poorly documented convoluted specification files.
Most of the other features I use most are fairly common though: line sorting and dedupe, column editing, regex search and replace, EoL conversion, compare/diff, etc.
Interesting, the ease of editing syntax highlighting rules is something I hadn't considered. It feels like lots of editors are moving to Tree-sitter so things may improve in that regard.
I wonder what needs this reimplementation fulfills. I am quite happy with Notepad++ and I think that for other operating systems there are already a few competent text editors.
But if we think about IDEs, things aren't quite as rosy and I would love to see something as good as Visual Studio running on MacOS (the existing version is just a renamed Mono Develop).
My first thought was, "Finally I can use something like N++ on my mac".
Then I checked the project page and realized at this point cross-platform means "we ported it to Linux". Which is great (although frankly Linux users are spoiled for choice wrt editors), it's just the headline that is misleading (yet).
I've been looking for a Linux version of Notepad++ for what feels like years.
I started learning vim but can't use it at work as I'm stuck on windows (which vim is rubbish on), and the way they (IT dept) installed it basically made it worse, so I never used it enough for it to be my go-to.
I can find no compelling evidence that vim users are more efficient than non-vim users, and I have first-hand experience with the extra cognitive load of vim commands and and distracting config-fiddling... however, I learned vim and use vim-emulation in all the software I use which support it, just kind of a nasty habit which comes in handy for corner-cases like editing over SSH.
Anyway, I was going to say gVim is lovely on windows, with a little customization and doesn't require admin privileges (though it will likely be contrary to your companies IT policy to side-load it). Other alternatives are using vim emulation in VSCode or one of the Jetbrains editors (probably the strongest candidate for vim emulation: IdeaVim).
wxMEdit (formerly MadEdit) filled that niche for me for years. It does seem that recent versions do have some bugs that occasionally rear their head, but it's still very usable.
At least it was for me, Using Notepad++ for editing config files, batch files, large sql stuff from time to time and the occasional binary. Including search and replace in a bunch of directories.
I'm an old-school Linux user, and way back when I considered Wine to be sort of a joke. It's gotten better and better over the decades and it's been pretty impressive when I've used it recently.
Completely off-topic, but your comment reminded me of the "For Dummies" books; I spotted a copy of "Wine For Dummies" in the mid-90s and was briefly excited that the software was mainstream enough to warrant it.
Winmerge is so great. Mac and Linux users look at Windows devs with pity, and probably with good reason (only someone with approximately equal hours on different platforms can really judge) but we do have some nice things.
There are two aspects of the original Notepad that will never be duplicated. First, all the heavy lifting was done by built-in Windows components, it was just a simple wrapper. You could probably write your own replacement in an afternoon. Second, it was preinstalled on every single Windows machine, you could always count on it being there.
... and suffered by comparison in those aspects, but was infinitely superior in every other way that matters (and there are a lot of other ways that matter).
To be clear, I'm not arguing that Notepad++ or NotepadNext isn't superior to Notepad. I'm simply pointing out that the original Notepad had useful properties that have been lost. I didn't think that would be controversial.
Yes, I understood your point and I agree it's not controversial. (My response was not so much pushback as feeling a need to point out Notepad was something of a wasted opportunity, it had those fundamental advantages but wasted them by being so miserably awful IMHO).
BBEdit from Bare Bones Software is a longstanding Mac text editor in the same vein as Notepad++, though it isn't open source or fully free to use. Bare Bones used to offer a free text editor for Mac called TextWrangler (with fewer features than BBEdit), but I guess they've now made the free mode of BBEdit their free offering.
Sublime is way too heavy weight. Notepad++ is that thing I open up when I need to edit a 2GB log file really quick. Or use a regex to fix up a CSV file that somehow got messed up.
Not having Notepad++ on MacOS is a major pain point for me.
Notably Notepad++ is not project/folder based. It is for editing a file.
I can never understand why Visual Code has become so popular when it can't do keyboard macros. Keyboard macros have been a fundamental feature of every (other) programmer's editor since at least the 1980s.
Macros are probably the best feature IMHO. Unless I'm mistaken, I've not seen a macro recorder as featureful yet so easy/quick to use. I know vim has to have it, but I find it hard to believe I would ever get quick enough to be able to do it.
So simple to put a complex macro together -- I had one today that removed empty lines, did a regex replace, then a straight text replace and some random line manipulation within 2 minutes. You can do it so often and quickly it's basically zero cost.
A few months ago I went to install Notepad++ and the installer says "Software is like sex: It's better when it's free" so I closed and deleted the installer. (It still says that today.) Glad to see an alternative I can install!
It's nice to see freedom at play here — freedom of the developers to include sentences which might offend, and freedom of the offended to use a fork instead. I respect both of your decisions.
You do understand the problem but have taken a hard stance. I mean at this point what is crossing the line? Would we all be up in arms if the developer decides to say: "Butt f*ck your best friend"
The point I'm making is that there are lines to be crossed and if you don't understand that you have simply taken a hard stance on some aspect of this.
That all being said, YES I totally agree the dev should have full rights to say that in his software - but we can have an opinion too.
Well, there are places that certain words (e.g. sex) appearing on a screen will get you in trouble with management because it could fall under HR's harassment policy. I know folks don't give a damn, but some people have to worry about such things.
I think the problem is likely stigmatizing sex workers as less desirable which is sort of narrow-minded and perhaps dehumanizing. There's a large imposition of morality that isn't necessarily shared by everyone.
I don't think that's what is being said here. Sex is better when it's free, because then it's likely enriched with some kind of emotional bond (even if not love), whereas in case of paid sex you're just getting a service. Regardless of what the N++ developer(s) think, the statement doesn't criticize prostitution.
Your statement is valuing one form of sex over another. The point is that value isn't held by everyone, and asserting it as fact is diminishing someone else's entirely legitimate perspective.
Conversation is pointless as OP has now responded saying he simply doesn't like hearing about sex.
Yes, I shared my opinion, I'm aware it was subjective. If sharing one's opinion is diminishing someone's perspective and that's bad, then why did you just do the same? On a similar matter, if conversation is pointless, why did you bother to write your message? :D
Is it hard to imagine that a single sentence in the installer about sex offends you so much that you refuse to use the software? Yeah that's kinda hard for me to imagine.
In a world of many, many alternatives, I feel like someone's preferences can be as arbitrary as they want them to be. It's less a statement about the magnitude of the offense and more of a statement of "I have all of these options. Why would I pick one that annoys me, even slightly?"
To use a hypothetical example - a cereal company puts some tasteless comment in an unobtrusive corner of the box. You don't have to look at it if you don't want to - you can turn the box, or put the cereal into another container, or just not read the box that closely. But why would you want to when there are 45 other brands of cereal on the supermarket shelf?
It's in the installer not the splash screen for christ sake. You'll see it a grand total of one time, maybe have a more easygoing friend install it for you?
"Principled" is a rather neutral designation. All it means you have strict rules. As to whether those rules are at all useful is not included in that designation.
I think we should more of this stuff to hopefully desensitize people over time. When abstract symbols can somehow evoke such a visceral reaction in a person, that's the kind of stuff that scares me.
It is my experience as a developer of a text editor, that text edtor/IDE users make the decision whether to learn/use an editor within seconds. Just a quick look and it has been decided, in 3 seconds what they will spend their next 10000 hours working with. I do not understand this, but it is a phenomena. It's like when we look at the opposite sex and decides if he/she might become our future partner and live the rest of our life together - and the decision is made within seconds. At least the filtering-out.
Trying to understand this sentiment. Why does it matter? What do the authors’ politics have to do with using the software or not? Do you generally avoid any company that does any political speech?
I formulate opinions of people when I hear their political leanings; usually negative ones. I have no reason for this, and frankly, I don't want to do it. It just happens.
And yes, I do avoid companies with outspoken political views that I disagree with, especially if their actions tangibly harm other people.
The breaking point for me was back when I updated my beloved Notepad++ and it started typing something ominous into a text file. I couldn't stop it so I unplugged the network in panic because I thought I was being hacked by a script kiddie. Then I actually read what was written, and it was a current political message. I would really like my tools to not give me a jumpscare.
People disagree very easily in political matters. And when I am trying to focus on work or my personal projects I don't need to be roped into some pointless ideological discussion or metal state. For that we can go to HN
It works like advertisement for ideology
Imagine you are installing Chrome and the installer shows a banner saying: we support Trump, Biden, Ukraine, Russia, China, invading Iraq... You might then feel uncomfortable using/contributing to software that has nothing to do with politics, because of a developer founded/random/misguided opinion
For me, I try to avoid politics in general since I’m (along with everyone else) so inundated with it on a daily basis. It’s so wonderful and refreshing to find places where it doesn’t exist and isn’t mentioned. No matter how much bad is going on in the world we all need to be able to mentally escape it. It’s just one of those vital things.
So when you go to download the newest version of one of your fav text editors and you’re faced with messages like “you guys support who I support in the war right?! You should because the other guy is crazy! I stand with this side, I’m literally changing the world!” and I just gotta sigh and roll my eyes. Sir this is an Arby’s.
Ti and Do and their students (crew) have come from a genderless, crew-minded, service-oriented world that finds greed, lust, and self- serving pursuits abhorrent.
Meanwhile if I use Notepad++ and load the same file windows shows it is using 586MB.
Any ideas why such high memory usage if this is a direct port to QT?