There's a bug in notepad that lets you turn your computer into a marquee. Making the text big and turning off wordwrap causes the text rendering to lag behind your typing. Here is a demo video I threw together. It's good to have in your pocket for if you're ever bored at fry's or something, that said the update speed is a bit jarring.
About 20 or so years ago, I was working at Microsoft and decided to see if I could find a bug in Notepad. With a bit of playing around I actually got it to crash with an access violation by doing something like scaling the font to a gigantic size, then print(preview?)ing it. Coincidentally, around the same time I attended a small talk by the guy who was listed as the current dev owner for it, so I tapped him on the shoulder afterwards and told him about it. Before listening to the repro steps, he assured me with complete confidence it was not a notepad bug and that I should go step through it for another look. I did, and he was right, it was a bug in the user mode part of the printer driver.
I thought that was true as well, but the connection appears to be the Fry family. The grocery stores got sold to Kroger, but the family kept the electronics business.
Aside from everything else, I have great respect for people who find bugs in widely used and long-established software. Even though this may not be a major bug, I admire the bugfinder just the same.
My understanding of notepad.exe is that it's a very-few-loc wrapper around a fundamental windows UI element. That's why it can be fun to see that there are bugs in its implementation.
It reminds me of this joke: Every program has at least one bug and can be shortened by at least one instruction — from which, by induction, every program can be reduced to one instruction which doesn't work.
2. Type <space> then backspace. (asterisk shows in title bar - arguably a bug here, but ignoring that ...)
3. Open a new text file. Asterisk showing in the title bar (Expected: no asterisk) - Unless you move the mouse over the window (then the asterisk disappears).
The behaviour in (2) seems to be pretty standard across editors I've used: Typing a letter and deleting it does count as a modified file; typing a letter and ^Z to undo it does not make the file count as modified.
Typing a letter and deleting it still counts as a modified file for me with VSCode, unless there's some platform-specific behavior or setting I'm missing. (I tested on Linux.)
I just tested (VS Code version 1.55.0 on Debian Bullseye, Linux 5.10.0-5-amd64) and it DOES show as modified to add then delete a character. I wonder if there's a setting somewhere or such.
Consider submitting bug reports or feature requests for Notepad to Microsoft with Windows' built-in Feedback Hub. For bugs, your reported reproduction steps and the diagnostic logs collected by Feedback Hub are often actionable without you having to debug Notepad yourself (as this person had to do).
You can increase the visibility of a Feedback Hub item by sharing a link to it on your blog, on Twitter, or wherever.
I was able to see that the <Delete> key doesn't add the asterisk. But I can't reproduce this: "notepad!UpdateTitle can be triggered by keys that do not edit text, for example by pressing the the arrow keys." My arrow keys don't trigger the asterisk.
Just looking at the messages received, it looks like they're triggering off a few different things to fall into the code path that looks for changes (the missing numbers are due to me deleting uninteresting messages):
<00133> 002A1272 P WM_KEYDOWN nVirtKey:VK_DELETE cRepeat:1 ScanCode:53 fExtended:1 fAltDown:0 fRepeat:0 fUp:0
<00150> 002A1272 S EM_POSFROMCHAR wCharIndex:0
<00152> 004E0A18 S WM_COMMAND wNotifyCode:EN_CHANGE wID:15 hwndCtl:002A1272
<00154> 002A1272 P WM_KEYUP nVirtKey:VK_DELETE cRepeat:1 ScanCode:53 fExtended:1 fAltDown:0 fRepeat:1 fUp:1
<00155> 002A1272 P WM_KEYDOWN nVirtKey:VK_RIGHT cRepeat:1 ScanCode:4D fExtended:1 fAltDown:0 fRepeat:0 fUp:0
<00174> 002A1272 S EM_POSFROMCHAR wCharIndex:1
<00182> 002A1272 S EM_GETMODIFY
<00184> 004E0A18 S WM_SETTEXT lpsz:02EDCAF8 ("*Example.txt- Notepad")
The one that seems to get triggered the most, indeed the one triggering it here, is the code path that also updates the position indicator, hence why Del isn't doing anything. Interestingly enough, they seem to be ignoring the EN_CHANGE message, and instead looking for changes explicitly after some events. Given the long history of Notepad, I'm sure there's some historical reason for that.
They do seem to be covering the bases checking for changes before anything that might lose data, like any path I can find to close the window, so it's a minor bug. They also check for changes on each and every mouse move message, so I think for most users, this state won't last long.
Ah, yes...that's what I was getting at. Notepad is mostly a wrapper around a rich edit control, and rich edit controls already emit "EN_CHANGE" when the content changes. So I suppose this must be some historical thing where an earlier version of notepad didn't have something like that to tee into.
I think the point is that the arrow keys update the status, if a change has indeed occurred, and delete key does not update status but does change the text.
Right. Trying to understand why you would check for an update for a key that doesn't change data and not check for one that does. It also checks when the window loses focus, so <del><click somewhere else> works.
If I absolutely had to guess, it'd be that there's an early out/special code path for the delete key where they forgot to add the "checkupdate" before the break/return/whatever ^^
Yeah I don't think that will literally be the code, but that's the outcome. Something like a range, or the del key being handled separately, I would assume.
I can reproduce with an added twist: deleting a character using Del does not cause the asterisk to appear. However, if I move my mouse over the Notepad window after deleting a character using Del, then the asterisk appears. Mouseover appears to cause an update.
Yeah, I played around with this a little bit. It seems like Notepad knows the document has been changed, the bug is purely that the title bar isn't updated in this one case.
Which actually seems all the more odd because it does get updated when you move the mouse, use the arrow keys (or other non-inserting keys like Alt+F4)
Talking mission critical software on Windows, I encountered two bugs in mspaint lately:
1) when resizing an image in >100% zoom from edge of the screen, it would cut more pixels than you tried to cut (although I don't repro anymore, seems fixed?)
2) sometimes when you press "shift" to draw a straight line, upon releasing shift, the line changes color (very rare repro, but happened to me many times; really curious what's the source of this one).
Since many are indicating that any UI event triggers the expected change to the Title bar, it seems to be an issue in the event handling loop in Notepad? For some reason it is "stuck" or otherwise sleeping and not picking up the changes from `notepad!UpdateTitle` unless the UI event loop gets kicked?
I frequently use it to clear the non-text formats from the clipboard so when I paste I actually get text. Some apps don't let you pick the paste format and try to be helpful with formatting. Most of the time I don't want that.
Win+R is useful for small snippets, but notepad is useful for multiline text.
But I don't pay attention to the asterisk, because I just use it as a scratchpad. When I need to restart for updates I inevitably have several Untitled notepads open that need to be manually closed out.
I do the same. People often reference CTRL+SHIFT+V without realizing that it isn't a Windows feature, the destination application needs to implement it (which several popular applications do, but not all).
Notepad is a great "scratchpad" application for clearing format/re-arranging data/fixing copy mistakes/etc. Plus leaving little short-duration notes to myself (with Sticky Notes for longer term reminders).
The fact it is a window-ed application on Windows is a major perk in 2021 when nearly no application behaves in a standard way anymore. That's why I use Notepad++ for different things than Notepad: It is more powerful, but takes longer to open, and has tabs which is a detriment for my usage of Notepad (I want fast taskbar switching) but a benefit for how I use Notepad++.
Notepad++ is great for Show Symbol -> Show All Characters, Encoding, and RegX/Extended Search&Replace in particular. Regular Notepad as a glorified clipboard helper.
I do not like to leave inane comments, but I feel the need to share that I somehow feel a bond with you, a total stranger online, just because we share identical practices in a very specific (generally speaking) problem.
Isn't that strange.
I use Notepad in the same way, every day over the last year or so (and ongoing). It did take a couple of months to find that non-breaking hyphens get eaten by Notepad.
Wonder if it could be something split between the control that the editor is using vs their key handler. The control may be eating it before the editor code even see the key press.
That would be my 'guess'.
I just tried any edit on my copy of windows and it is not showing any asterisk for any edits. It could be a newer feature that is not done yet? As I am using an older win10 copy.
Last week there was an article about how a tool that monitor WhatsApp contacts' online status can be used to stalk. Because I was bored I did a DDG search, and the top result was a Github repo of a Chrome extension that promised such monitoring. The readme was in broken English and hat lots of emojis, it had 500+ commits so I thought "Must be an active developer". Looking through the commits, the majority of them were "Changed readme" with single line changes to the readme file...
I was aghast when I read this comment until I realized it was sarcasm, and then I got a good laugh thinking about the look I still had on my face. It made me wonder... how many people in any given echo chamber are simply fanning the fire due to a misunderstanding? Probably a lot.
I mean, React Native is not a bad choice for a "new notepad", similar to how they did with the calculator. It can even get the "Microsoft OpenSource Project" seal. See ReactXP[1] a library for React Native from Microsoft
Speaking about the calculator app, did you know it is OpenSource[2]? You can only compile to windows as of now though
then it wouldn't be subject to the bug, but the performance would be terrible if you're editing a large file. To get good performance you'd need to use a flag and update it accordingly, which will subject you to the same bug.
You do have me wondering now how long it takes to compare large strings. DDR4-3200 has a peak transfer rate of 25.6 GB/s. So if you were editing a ridiculously large 1 GB text file, you could only make that comparison ~12.8 times per second, and that's assuming the CPU could compare data that fast.
ill give the short answer to this. millions depend on notepad. a small change , can have devastating effects. What if the editor doesn't respond to the same WM_XYZMESSAGE? what if your enterprise depends on an obscure app that modifies notepad.
So no, best option create a new editor, but there are 1000 editors out there.
look at sublime text 4.. its pure opengl. fast, and epic done right.
For a while I did a job where I had need for a text editor but wasn't allowed to install my own programs on my work computer. I tried using Notepad for a bit but switched to Code Writer and found it an acceptable solution. It seemed to me at the time Microsoft was considering that their 'modern' Notepad alternative(?). I haven't seen much about it since though.
I love how Windows and its Microsoft software often have the same type of bugs as any open source project run by volunteers. Except it costs a lot more.
VS Code will remove the unsaved mark if you undo the edit with the undo command (ctrl-z), but not if you for instance backspace to undo the character you entered manually.
That depends a lot; vi/vim and emacs keep track of your undos in a way so they know when you are back on the last saved version. But indeed, most other editors don't.
macOS is using "dot on top of the Close button", to indicate both that there are unsaved changes, and that if you tried to close the window, you would get a prompt asking about unsaved changes.
Simpler, more elegant, better integrated solution, consistent across the whole OS.
"Asterisk in the Title Bar" is a very unrefined solution to the problem.
The asterisk (as unsaved indicator) has been there on a lot of Linux programs for a while (the first I remember encountering was GIMP at least a decade ago).
It shows up on the titlebar but more importantly in the window pager/taskbar, which isn't a feature on Mac OS (though to be fair it also doesn't show up on Linux/Windows desktops that are configured to show icons only in the window pager).
not asking to get into an app namedropping war, but do alot of ppl use Notepad still? Kind of moved away from it years ago due to encoding, lack of some features etc
Any app that’s installed by default is always used by large numbers of users. Even if not for real text editing, plenty of people use it just as a temporary place to paste copied text to strip the formatting before copy/pasting it somewhere else.
I'm still kinda mad that there's no default shortcut for "paste without formatting" in Word, like CTRL+SHIFT+V in Chrome. It's like one if the most used feature for me in Word.
2) to validate text. For example spotting an O or 0, | or l, etc. Its quite normal when dealing with user input to find configuration errors this way
3) Quick temporary paste buffer. Nice when jotting down phonecalls. Better than onenote since it opens quickly and ready to accept input. it never opens on some random page full of categorized notes.
If I just need to take a quick note, I'll happily run Notepad, which opens instantly, write down what I needed to write down, save it, and then move on with my life. The "runs instantly" part is what still makes it useful, nothing else comes even close to just immediately giving you a textbox to spew characters into.
That's all it's for though, for real work, real editors (meaning different editors for different tasks, because writing a long text in a code editor is kind of like insisting on using a chef knife for everything in the kitchen. Possible, but a bit silly)
> nothing else comes even close to just immediately giving you a textbox to spew characters into
On my machine, when there's an Emacs daemon running in the background (so no existing windows, which might make this process faster), opening a new window ("frame" in Emacs terminology) and then closing it again takes 165 milliseconds total.
Google gives various values for "human reaction time", but one of them is 200 milliseconds.
I'd say that that's pretty close.
Unless you need to save those 12 MB of memory that the Emacs daemon consumes.
You're free to use whatever editor you want, but I find the claim that "nothing else comes even close to just immediately giving you a textbox to spew characters into" a bit doubtful.
Pretty sure tons of people use it still. It's the built-in editor, so while it's not a good code editor by any stretch of the imagination, it's infinitely useful for people who are not coding, who don't have some other editor or text processor installed.
I use notepad to take notes on calls. Opens very quickly. Other editors are usually filled with my other work. I can just pop open a blank text doc, take some notes, save it, and exit.
I use it every day. On my machine, it opens much faster than Sublime Text, let alone VS Code. If I want to see or change a small file, or want to write a quick note, I open Notepad.
I use it explicitly to lose formatting while I copy from browser to an application like excel or Word. The intermediate step causes it to lose all unnecessary text properties.
https://www.youtube.com/watch?v=w-Y9oeCWeGc