Hacker News Reader

Comment by nijave | Hacker News Reader

That's disappointing. I used to use Notepad++ heavily but it seems to have really lagged behind other lightweight text editors like Visual Studio Code

View on HN

> lightweight text editors like Visual Studio Code

I wouldn't call anything based on Electron "lightweight".

My completely subjective list of text editors in order of lightweightness:

Notepad2 - a feather

Notepad++ - a dog

VS Code - an elephant

I haven't used it in a long time, but Textpad was my go-to ultra light. At the time, it only supported ASCII (no Unicode) so it only used one byte per character. I frequently had to open files that would hit 32 bit memory limits.

If VS Code is an elephant than what are VS, IntelliJ, Eclipse? Skyscrapers? Aircraft carriers?

Whales

Eclipse is a herd of cattle sellotaped together in the shape of a giant cow.

Yes. Though they don't pretend to be text editors.

IntelliJ and VS are like two different models of US aircraft carrier

Eclipse is like that one Russian aircraft carrier.

They're not text editors.

I think most people use vscode exactly like they would use IntelliJ; it's hard for me to justify that vscode is an editor but intellij isn't.

I don't have everything setup in vscode. I mostly just use it for syntax highlighting and generally use a JetBrains IDE for programming (code navigation works much better imo)

I think you can go either way with vscode similar to the whole vi vs neovim with tons of plugins

> If VS Code is an elephant than what are VS, IntelliJ, Eclipse? Skyscrapers? Aircraft carriers?

I was quite surprised, when I recently used VS for a small C project, at just how snappy it was for that project compared to VS Code for the same project.

I then compared it to VS Code for a larger C# project and it still compared very favourably in terms of responsiveness and speed.

I think a lot of people using VS Code are comparing small projects in VS Code to large projects in VS and concluding that it's VS that is the problem.

What about Vim and emacs?

I'm very fond of Notepad2, but development ceased in 2012 and the fork that I'm using, Notepad2-mod [1], had its last release in 2017. I wonder how many buffer overflows are lurking in there.

I just discovered Notepad3 [2], which appears to be a maintained fork. Screenshots look very similar to Notepad2. Gotta check it out later.

Any other forks that I should be aware of?

[1] https://github.com/XhmikosR/notepad2-mod

[2] https://www.rizonesoft.com/downloads/notepad3/

I use Notepad2-mod as well, didn't even know it wasn't maintained anymore! Thanks for mentioning Notepad3, I need to look into it.

My search for "notepad2" came up with https://github.com/zufuliu/notepad2, which sees routine changes: https://github.com/zufuliu/notepad2/commits/main

GUI applications are only as responsive as the framework allows them to be. Because Notepad2 and the later Notepad3 were built with win32, they will start the fastest. Applications with a lot of plugins will only load as fast as those plugins can be checked and loaded to prevent exceptions. Personally, I like AkelPad since it still uses a proper MDI like Visual Studio 2008.

It's hard to beat an extensible project maintained by Microsoft with a Windows C++ project written by one guy.

(I personally ditched n++ because the shell highlighting false-positives errors, and syntax errors are especially ugly in the default scheme. And it wasn't on GitHub back then, so complaining would be a chore.)

Interestingly my number #1 killer feature for N++ seems to be "having multiple unsaved files open and they are transparently saved and restored after restarting the app". In the past I've judged people who did this with a "just save your damn files" but since I, too, have converted to the ephemeral notes buffer where I don't want to find a location and file name to save it.

The funny thing is that my N++ instance has ~5 files always opened, 3-4 of those buffers and when they get to 6 or 7 I trim them down to 3-4. This is probably the beginning of why we find people doing weird things...

Been using Bear on macOS (work) and Obsidian on Linux (personal use) for that now

200MB download, 500MB install. "Lightweight text editor"

There are

- text editors

- programmers text editors

- integrated development environments

- rapid application development tools

Sorted by size, reversely proportional to feature set. Basically VSCode is an overbloated #2, that isn't good enough to be #3 and is nowhere near #4.

You could've fit a full blown RAD into 500MB (Borland C++ Builder) 20 years ago.

I'm going back and forth between those two and find it hard to leave NP++, but I know VSCode is superior in other ways besides minimalism. If the dev has a good response to this disclosure I'll probably continue to not be in a hurry to leave it.

I also use both. Notepad++ is better for quick and dirty editing

VS Code is not at all lightweight compared to NP++.

lightweight like vscode made me chuckle

Ok it was not just me then.

I use both. NP++ for like single documents or quick kanban lists for myself. VSCode is better for a group of closely related items such as when using it as an IDE. As I do not keep both open all the time NP++ usually wins on startup speed. Which fits my workflow.

I think they wrote "lightweight text editor" but really they meant lightweight editors, with a loose classification of full-blown IDEs as heavyweight and everything lighter as lightweight, VSCode being the heaviest in the lightweight category.

Do you know what lightweight means?

It's 4 potential memory corruption issues in a 300kloc C/C++ code base, only one "may be critical" (without a working exploit being provided that's hard to tell). That's actually not too bad for an "unsafe" language.

> It's 4 potential memory corruption issues in a 300kloc C/C++ code base, only one "may be critical" (without a working exploit being provided that's hard to tell). That's actually not too bad for an "unsafe" language.

It's about normal.

It's also why Rust is struggling to eat into C and C++ marketshare - the class bugs it prevents has such a tiny footprint compared to all the bugs present in any given C and C++ system that it doesn't motivate the developers to spend the time Rust requires to ramp up to speed on a new language, and then use it in production.

Reply on news.ycombinator.com