Hacker News new | past | comments | ask | show | jobs | submit login
The Plain Text Project (plaintextproject.online)
498 points by mmillin on Dec 2, 2019 | hide | past | favorite | 202 comments

Recently I decided that I was going to solve the problem of: I easily write inline TODO comments while I work on code, but then have difficulty keeping track of them and getting my head back into the state of things later. While there is IDE support for such things, it's usually not exactly the right interface I want.

So I made a tiny CLI app that scans the source for TODO and FIXME lines and presents a menu of files, containing the number of items to work on in each. Then I type in which file I want to work on and it instantly reports all relevant lines, plus successive comment lines. All I have to do is punch in the line number and start working.

I felt a kind of stress relief almost instantly after doing this. It's better than Trello for me.

If I need to add additional kinds of data sources, many syntaxes, etc. it might become a bit more complex, but still managable as long as there's an API to get some plaintext lines out. It's basically following up on the hypothesis of a lot of information tools today: it isn't the data generation that's the issue, but the filtering.

Just be careful about Microsoft's Patent US6748582B1; it doesn't expire for another few months. ;)

From the patent (edited down a bit):

> According to various example implementations of the invention, a task list facilitates code development by assisting developers in keeping track of and managing a variety of tasks, such as errors to be corrected, opportunities for optimization, and other user-defined tasks. As the developer edits source code, warnings and coding errors are detected and inserted as tasks in a task list. The developer can also embed keywords known as comment tokens in the code. These comment tokens are detected and used to define tasks.

> [...]

> Tasks can also be identified using tokens or keywords. These tokens or keywords typically preface comment lines in the code and may include predefined labels such as, for example, “UNDONE,” “TODO,” or “HACK,” as well as labels that are defined by the individual developer. If the source code has no syntax errors, the parser [...] determines whether any of the keywords are present in the source code[.] If so, [it] extracts the comment from the source code and uses the tag to determine the priority of the task. The task is then inserted in the task list[.] For example, if the source code contains the comment, “/TODO: Need to add copyright text/”, the parser [...] adds the task “TODO: Need to add copyright text” to the task list with a priority rating assigned to the “TODO” tag. [1]

[1] http://patents.google.com/patent/US6748582B1/en

This patent is invalid! Look at the source code in HN comment https://news.ycombinator.com/item?id=21685660#21689915 bellow and see the TODO tags in files last modified on 13. November 1999 which predates the patent application by Microsoft.

That is one of the dumbest patents I have ever seen.

Well.... [0]

I have a whole list of absurd patents... this is the classic go-to example of a patent that should have never been issued... basically, a patent issued saying that if you exercise a cat by moving a laser pointer around a floor, you're infringing on this patent.

[0] https://patents.google.com/patent/US5443036A/en

How is it you are aware of this? Affiliation with MS or a project that ran into it?

Wouldn't the key part:

"and in response to completion of a task, modifying the task list during the interactive code development session to indicate that the task has been completed."

mean it doesn't apply?

Worst case, just put a US exclusionary clause in the release so US copyright law doesn't apply. At least Europe is ahead of the US in this and doesn't allow such trivial patents and considers them invalid by definition.

Someone discovered it years ago online, and it's done a couple rounds in the media[1] as an example of an "overreaching software patent", similar to the "pop-under" patent, which patents a pop-up ad that opens after a window is closed[3].

So no personal experience, but I definitely think it's pretty frivolous; I don't imagine its ever been tested in court. :)

[1] https://www.theinquirer.net/inquirer/news/1040068/microsoft-... from 2004 [2] https://www.geek.com/news/microsoft-granted-patent-covering-... from 2010 [3] https://en.wikipedia.org/wiki/Pop-up_ad#Patent_controversy

I am an X-Microsoft employee. Pre-Nadella era, most teams had a patent budget. People would file patents for all sorts of reasons. The game was who can get away with vague-ish patents and collect the most cubes. There was a cube you got per patent.

Needless to say the number of cubes someone had, the more clout they had and it became a dick measuring contest.

There are VPs and distinguished engineers with 100s of cubes.

Nice idea. The JetBrains family of IDEs (RubyMine, IntelliJ, etc.) even have this as a built-in TODO panel that shows files with TODO and FIXME comments (syntax is configurable).

I use IntelliJ as well for years, but don't underestimate

   grep -r "# TODO" .

That’s great! Using ripgrep [1], I think it would even exclude all from your .gitignore by default.

I’ll give this a try before adding something to my .vimrc again.

1. https://github.com/BurntSushi/ripgrep

grep -H "# TODO" file1 dir1/* file2

Is also useful, as it prints the filename and the matching lines.

if you are using GNU grep, -H option gets enabled by default when there are multiple input files

Hopefully only when stdout isatty().

Edit: Nope, writes l̶i̶n̶e̶ ̶n̶u̶m̶b̶e̶r̶s̶ file names to output regardless. Boo.

you mean filename, not line numbers?

option -h will disable filename in output

This only works depending on how diligently you formatted those TODOs. Before you know it your regex explodes. I use IntelliJ as well, so I don't have to think about these problems.

I mean, how often do you place the four characters "TODO" in your code when you don't mean to mark a TODO? The only common English word I know of that contains that substring is "mastodon", and it'd have to be all-caps.

You could also include word boundaries if you cared enough.

    ag '\bTODO\b'

Does IntelliJ do something smarter than a regex to find TODO?

Visual Studio does the same ("Task List")

I really like JetBrain's Resharper for Visual Studio -- they have a very nice, flexible, and configurable 'TODO' window. For example, on our team we try to put TODO followed by our name or initials. The TODO window can then partition those out into separate lists.

Give Rider a go. I'm a complete convert; previous attempts were very unpleasant, but its a complete experience now, very similar feel to VS + RS, without the awful latency.

I cannot second this enough, Rider is so much nicer than VS these days. I too tried to convert to Rider previously and ended up not using it, but just a while ago I made the switch and spent some time watching some videos on what toys it has, and going through everything and configuring it how I like. It is a lot nicer and a lot quicker, and most importantly to me, has really good vim support (including easymotion / surround ).

I've seen it, but never taken the plunge. Thank you for the encouragement -- I'll definitely give it a go. That said, it's going to be extremely difficult to actually incorporate this in my 9-5 environment, so it will probably end up being for my home projects only.

out of interest, why do you think it'd be hard? It's what I did, just swapped over at work. Nearly everyone else is still using visual studio. It mostly is a zero friction change and you can swap back and forward between environments at any stage

Because I work in a highly regulated industry. We have to qualify/verify/validate everything that we use, and we all have to be standardized on the same thing. I'm currently struggling to get unit tests working smoothly -- we have to validate the "plugin" that we use to execute the unit tests (MSTest... part of Visual Studio), which means that we need to write requirements and then test those requirements. We're writing requirements for MSTest.... I'm pushing to get a CI pipeline set up so that our unit tests can be run automatically with every check-in, but we'll have to write-up requirements for whatever CI tool, validate that it works with our existing source control, validate that the unit tests execute properly, document it all, review it all, sign off on it all within our document control system. etc... Switching to an entirely new IDE I think would make people's heads explode. Personally I think that we make things excessively hard on ourselves -- I'm endeavoring to reduce some of that pain.

That sounds incredibly painful, I admire your tenacity.

Rails (or maybe it's just Rake) has `rake notes`

There's extension for VS Code - Todo Tree that organizes your files with TODO in the comments. Super helpful


Related to this. I write comments for TODOs that I want completed before I commit with a special prefix like:

    //hhh I want this to be done before I commit.
Then have a git pre-commit hook that scans for "//hhh" and aborts if it's found.

Same with XXX instead, which even gets auto-highlighted by many editors.

Have you considered open-sourcing this CLI app? I would benefit immensely from this tool, I think. Right now I just kind of ack and hope for the best.

Emacs supports this with the package magit-todos.

  :set wildignore+=node_modules/**
  :nmap gr :vimgrep '' **/* \| copen 20<Left><Left><Left><Left><Left><Left><Left><Left><Left><Left><Left><Left><Left><Left><Left><Left><Left>
grTODO, enter.

Edit: <C-f>0wa may work instead of Lefts, but I always forget about it.

You reminded me of the time one cool guy and a respectable troll ran a script to create tons of issues on github for TODO comments in the code. He quickly got banned and the issues removed, but I for one was thankful to him. I think I asked the staff to get them back for my repo, but no :)

This could be a Great GitHub Actions though.

So user can enable/disable it per account/repo as they wish.

I think it exists, I've had it enabled in some repo when figuring out new gh actions

I do something similar, but my flow is around feature branches: I create a branch, dumping TODOs in the code as I work out the feature, then progressively fix them before merging the branch. Wrote a little script to highlight TODOs created in current branch (vs base) if anyone's interested: https://github.com/yonilevy/branchtodo

eslint does this for JavaScript with the no-warning-comment rule. The general idea there goes something like "don't use code comments as a project management tool," but I tend to use eslint as a reminder to finish things for my current PR.

Also it occurred to me you could use grep or rg, something like...

  rg '\s*//\s*TODO'

This will open all of the files with TODO in them in vim:

    alias todogrep="vim $(grep TODO . -rl)"
You can modify this easily, such as by using ripgrep, adding excludes, or doing regex to find TODO and FIXME together, but this is a quick one-liner to add to your `.bashrc`.

You can put the grep flags at the end? All these years, and I had no idea.

Depends on your grep. Reordering flags is typically a GNU getopts extension, not present in traditional UNIXes.

I think more and more people are realizing that simpler is almost always better, and not only when it comes to software. I've found that this approach works best for nearly all aspects of life.

The hard part is simplifying complex things. We have so many odd pieces (usually due to legacy reasons or conflicting designs) which don't quite fit into an otherwise simple solution.

Plain text could probably work for most forms of communication and data formats. It's when you need to separate, categorize, and interact with the information that you need more than plain text.

This website briefly addresses plain text's shortcomings, so to add to that, in terms of software UX, I would say plain text should be used as a starting point while adding interactive elements (e.g., buttons) and layouts only as necessary. By layouts I mean visual separation of categorized information via whitespace and/or color variations. I've found that this results in extremely intuitive interfaces that are both easy for users to digest and developers to maintain.

We seem to be following a trend where "winning" software has little to no learning curves, as they are becoming the simplest possible tools for daily use. I'm not sure if it's a result of the fact that most people are tech savvy, or if we're just getting better at building software and designing interfaces. It's probably some combination of both.

> We seem to be following a trend where "winning" software has little to no learning curves, as they are becoming the simplest possible tools for daily use. I'm not sure if it's a result of the fact that most people are tech savvy, or if we're just getting better at building software and designing interfaces. It's probably some combination of both.

We're following a trend where "winning" software has little to no learning curve, as they are becoming the dumbest possible tools, with ceiling placed so low that no learning is happening at all - in first 5 minutes you get to see all that there is to see. It's the result of UX trends driven by SaaS businesses, where the first impression is what gets the sale, making development concentrated on looks over function.

I don't think the UX needn't be complicated. If you really wanted that you can use .rtf, but whitespace and at least grayscale separation are already possible in plaintext of course. Want a cute header? How about:




Smaller plain text files + folders are great for separating, categorizing, and interacting with information. Got another file type relevant to that note? throw it in a folder with a matching filename.txt describing it all. Have aliases or shortcuts to make these appear in any configuration you want all over your OS.

MacOS also lets you put tags on any file leading to further customization. Throw in Calendar into the mix for reminders (not proprietary Reminders) mail for communication and sending yourself notes when you don't have your laptop, and MacOS has all the features baked into the OS that most notetaking apps drip feed through a poorly optimized app on a subscription and with proprietary formats.

This system works on any computer built in the last 40 years and will probably work on all computers built in the next 40. Lets see a company like evernote last for that long.

It’s worth noting that unless your header text file is in a format that can be converted to HTML, there’s no easy way for third-party accessibility tools to understand your plain text the way you do. Accessibility is one of the reasons WYSIWYG is so common. It’s hard to translate plain text to a semantic verbal description (though with AI and pattern matching this might be getting easier), and even harder if it’s not actually text. ¯\_(ツ)_/¯

our even better then emailing yourself files, you can use something like syncthing and just drop the file into a folder to have it synced to another device. no need for importing and exporting from your email app

Simple is always better, the problem is that "simple" isn't the same for everyone because different people have different needs. Simple is often simplified into "one one size fits all," which often just ends up being limiting.

This. "Simple" so often turns into complex when the system is too brittle to fit your desired use case

I'm skeptical any such trend exists. Are you sure you're not misinterpreting your anecdotal experience?

I'm not sure if it's a result of the fact that most people are tech savvy

Most people aren't tech savvy. Again, maybe you are extrapolating inappropriately from your personal experiences, the people you hang out with, etc?

I'm mostly referring to the younger generation(s) and the apps most widely used by them. Think of the simplicity of applications like Instagram and Snapchat. There isn't much to the interfaces for most user interaction - some images, videos, text, an input or two, and a few buttons. There may be some advanced touch interactions (pinching and swiping), but overall, applications these days tend to be relatively simple.

Older generations definitely struggle using software though, so I think they may be a good metric for how simple and easy to use software can be.

Anecdotal experiences could certainly play a role in my opinion here, but I do think I've recognized a pattern over the past couple of decades where winning software interfaces have made a transition from being overly designed and complex to much simpler designs with (usually) predictable interactive element positions and flows.

Think of what software was like when there were "shiny" buttons and small text everywhere with confusing visual flow, and then think about what it is now, usually composed of flat buttons (e.g., the "material-ui" standard) and easy to digest visual flow with predictable interactions. This transition is likely a natural result of figuring out over time what works best and what doesn't.

By tech savvy people, I mean the end users who interact with software on a regular basis. These people (i.e., most people in the modern world, a number steadily increasing) will naturally gravitate towards the easy-to-use, predictable design patterns to which they've become accustomed.

I find Snapchat to be a confusing and complex app. It’s very hard to figure out how to do what you want unless someone shows you. The UI doesn’t have any discoverability. Many actions are hidden behind non-obvious gestures. Lake many apps nowadays, it gives the illusion of simplicity by just not having adequate UI.

On a related note, I absolutely hate how most mobile and many web and desktop-based apps nowadays don’t have tooltips, so I can’t figure out what some inscrutable icon/button is supposed to do by hovering my mouse on it or long pressing my finger on it. This used to be table stakes.

Yeah, I also find most modern "simple" apps and sites really confusing. Especially if they're social. Even Twitter's confusing as hell, despite doing very little. I bounced off Facebook in about a week back in 2011 or so, and never returned, because I couldn't figure out where anything was or where anything went, and it was less confusing back then from what I can tell.

Apps are simply becuase devices force them to appear simple. Screenestate is limited and inputactions are mostly touch&gesture-based. That leaves not much room for complexity. Even the onscreen-keyboard only has chars by default, not modifier for complex shortcuts.

Completely agree. Everything I publish starts with plain text.

I use the basic text editor that comes with the OS or Ghostwriter [1] when I really want no distractions. It's a great, minimal and distraction free editor I discovered recently when I switched to Linux (it does exist on Windows too and there's a macOS beta).

I put it on full screen with dark theme and focus mode on (it highlights the current line and fades everything else away). When I want to go gung-ho I also enable Hemingway mode which disables the backspace key. Love it.

[1] https://github.com/wereturtle/ghostwriter

> in terms of software UX, I would say plain text should be used as a starting point while adding interactive elements (e.g., buttons) and layouts only as necessary. By layouts I mean visual separation of categorized information via whitespace and/or color variations. I've found that this results in extremely intuitive interfaces that are both easy for users to digest and developers to maintain.

Is there any software that you think stands out as an example of this approach?

Emacs is exactly this. People usually think it's an editor, but I actually think it's better to regard it as the remains of a text-mode Lisp Machine that now happens to be a VM.

In particular, Org leads to very nice and simple text-mode workflows and mini applications. Besides, apparently Amazon used a custom Emacs application (not Org-based) in the early days to do customer service [1].

I actually very much prefer it to Unix ncurses applications, which tend to be little information silos. In contrast, Emacs makes it really easy to connect everything together thanks to great Elisp APIs. It feels like a really cohesive environment. Unix shines for non-interactive workflows.

I like doing my computing in 3 (actually 4 platforms): Emacs, a browser (Firefox), a terminal (XTerm) and F-Droid. That, plus a nice manual tiling WM (StumpWM) and functional plumbing (NixOS) is a great simple setup.

For example, a good keyboard, no compositor and XTerm reduces latency a lot vs more complex desktop environments. It's really noticeable.

[1] https://sites.google.com/site/steveyegge2/tour-de-babel

> In contrast, Emacs makes it really easy to connect everything together thanks to great Elisp APIs.

Elisp APIs and your standard editing commands (which are of course the pieces of Elisp that happen to be bound to keypresses). The difference between this and ncurses/other TUIs is profound - as you said, typical TUIs are data silos, just painting characters on the screen. Whereas in Emacs, all the text on the screen is accessible for search, navigation, copying, and even modification.

Even saying "Elisp APIs" doesn't do it justice; Emacs follows the best traditions of Lisp Machines - you can inspect and modify software at runtime, and make it do what you want it to do, whether it wants it or not. If an Emacs mode (i.e. essentially an Emacs app) doesn't provide some functionality, you can add it either way. Want to use pretty third-party autocomplete like Helm for e-mail addresses in To: field in your Emacs mail client, and want it to pull suggestions from some arbitrary .org file you use as an address book? No problem at all. Few lines of code and it just works.

That's right, API is not something I should have used for Elisp. The only thing that compares is Smalltalk in terms of being a live environment.

The downside is security. You need to trust everything you run, because as you say it's so open and inter-winded.

It’s much harder to build good search engines on top of plain text though, because it’s not possible to deterministically detect hyperlinks within text.

If the word starts with "http" and contains a period, it's probably a hyperlink. HN uses this assumption to automatically convert plain-text hyperlinks, and it works well enough.

The real problem is dealing with SEO spam, not occasional false positives with hyperlink detection.

Sometimes auto-conversion (esp with all the TLDs and gTLDs) has weird outcomes: >> "Rudy Giuliani accuses Twitter of bias for hyperlinking text" | https://www.theverge.com/2018/12/5/18127063/rudy-giuliani-tw...

> The real problem is dealing with SEO spam, not occasional false positives with hyperlink detection.

I mean that's easy to say, the obvious question then is why it's apparently too hard for Google, since they don't do it despite the fact that it would obviously be of value given their algorithm.

Why would it be of value? Google isn't in the business of giving best-quality search results; it's in the business of giving passable search results while exposing users to ads and collecting data for their advertising machine.

While we’re on the subject, I just moved my whole financial life over to hledger (https://hledger.org/) and oh my goodness I’m so much happier (I dumped both QuickBooks and Quicken, which I’d been using previously).

It won’t be for everyone, but if you know a bit about what you’re doing with double-entry accounting, it’s so so so much better. I only wish I’d discovered this was of doing things years ago (before dumping hundreds of hours into clicking and trying to wrestle with Intuit’s tools.)

I do my self-employment accounting using an accounting system I wrote myself in my own Lisp dialect (TXR Lisp), making heavy use of its object system. It works very well.

The entry is done in a file called "data.tl", using simple function calls and object construction. That is then checked into Git after every new transaction.

It does everything: deducting income tax, expenses, GST, capital cost allowance for writing off depreciation on equipment, ... And it has decent columnar format reporting for querying the accounts.

Invoices to clients are generated in HTML + CSS + SVG logo, which can render to a very polished PDF.

I based the system on something I call "zero sum accounting". Every transaction contains 2 or more deltas (N-entry, not just double entry), which represent entries going into various accounts. These deltas must add up to zero: like voltages around a circuit. So for instance a single transaction representing a paid invoice gets split up into an income tax withholding account, gst, account, equity account, cash account, and others, in a single transaction. Negative-running accounts represent outside interests in the business: e.g. the equity account (owner's interest in the business) runs negative, and so would an account representing a bank loan (lender's interest in the business). Positive accounts are what the business has, like cash or value of assets. The confusing "debit" and "credit" terminology is completely avoided.

Any plans to open-source your tool? Sounds fantastic.

Also I think "double-entry accounting" literally means "N-entry zero sum accounting" as you describe it, and hledger supports it.

When designing this system I wasn't able to find any online resource about accounting describing anything other than double-entry accounting in which every transaction consists of one debit and one credit in equal amounts (usually positive), not adding to zero.

The Wikipedia page has nothing about an N-entry, zero sum method:


Not going to open-source; I never open source anything without decent documentation, and this has none.

It’s implied in the first paragraph – “In double-entry bookkeeping, a transaction always affects at least two accounts, always includes at least one debit and one credit, and always has total debits and total credits that are equal.”

Do you have many automations or integrations in-place, or links to resources that helped you get beyond manual entry?

Not the OP, but: https://plaintextaccounting.org/#data-importconversion, https://hledger.org/about-real-world-setup-docs.html, #plaintextaccounting and the project IRC channels may have something helpful.

There's also ledger-cli.org, which appears to be pretty similar.

Great collection of tools and articles. Plain text is also a great (and the best) choice for datasets. Do NOT use JSON, YAML and friends, for example, as your input format but use plain text with a custom parser to import into any SQL database and than you can easily export to JSON, YAML and friends. See the football.db and the Premier League or World Cup match schedule as living examples [1]. [1]: https://github.com/openfootball

If your dataset is mostly a list of strings, sure. If it's anything more structured, why exactly?

I'd argue that using "plaintext" for structured data (a.k.a, inventing your own data representation) will set up both you and the users of your dataset for unnecessary pain dealing with unescaping and parsing.

> If it's anything more structured, why exactly?

It is way easier to input / type and change / update. And compared to lets say JSON, YAML or friends at least 5x times more compact (less typing is better). See the world cup all-in-one page schedule in .txt [1] and compare to versions in JSON, XML and friends that are page long dumps, for example.

[1]: https://github.com/openfootball/world-cup/blob/master/2018--...

One advantage I can think of is it doesn't need to be parsed into a node based tree structure like JSON. It's a lot easier to stream parts of it at a time.

if the dataset is "more structured" you can try to simplify this structure for great gains. As a byproduct, you get to use text files for the data.

Could you give an example?

See above the world cup match schedule [1], for another other examples with geo tree (e.g. country/province/city/district/etc.), see the Belgian Football clubs, for example [2] or for yet another example the Football leagues [3] with tiers (1,2,3, etc.) and cups and supercups, playoffs, etc. The .txt version are pretty compact with "tight" / strict error checking and JSON, YAML and friends I'd say it would be 2x, 3x or even more effort / typing. [1]: https://github.com/openfootball/world-cup/blob/master/2018--... [2]: https://github.com/openfootball/clubs/blob/master/europe/bel... [3]: https://github.com/openfootball/leagues/blob/master/europe/l...

I see what you mean. I agree, for a human editor with domain knowledge, those files are easier to read and maintain than JSON. However, it's definitely nontrivial to parse as a machine-readable format. If other projects are supposed to consume the .txt files directly (i.e. not going through the command-line utility), you should at least provide an EBNF grammar.

Example: I assume, the scorer lists are actually lists-of-lists, where equivalent JSON could look like this:

    {"player":"Gazinsky", "goals":[{"minute":12}]},
"goals":[{"minute":43}, {"minute":90, "overtime":1}]}, ... ]

... which is absolutely more verbose.

However, if someone just went by the data, they could get parsing wrong: It looks like the outer list (of players) is delimited by spaces - however, there are also spaces inside the player names. A better approach could be to split the list by ' signs as each player has at least one time - however, players can have more than one time and could probably also have apostrophes inside their names (e.g. Irish players). So I guess, the best delimiter would be a letter after an apostrophe after a number. Except, we might also have parantheses, etc etc.

I'm confused about what plain text means if JSON and YAML don't qualify. They are non-binary and non-proprietary. Is CSV plain text? And the example URL of openfootball has data files with fixed column positions and square brackets. Looks like you're packing semantics implicitly into the parser rather than leaving it explicit. I don't see why that's an argument in favor of plain text.

JSON and YAML qualify as plain text, for sure. Plain text is a spectrum. Let's say from "free form" english text as your comment to more machine-oriented structured formats like JSON and YAML. YAML, for example, tries to be a more human plain text format than JSON e.g. it supports keys without enclosing quotes or it supports comments and it supports variants and many shortcuts and much more. JSON is pretty "inhuman" if start hand-editing from scratch and NOT recommended, see Awesome JSON Next for "Why JSON is NOT a good / great configuration format" or "How to fix JSON" and so on - https://github.com/json-next/awesome-json-next

The football data looks easy for a human to read but a pain in the arse for a program to consume. Personally I think it's terrible, and the fact that they have had to develop a custom 'sportsdb' tool to manage it rather than using something generic like 'jq' is telling.


To properly parse this file you need to write a parser that cut fixed-width fields (wait, are the team names padded to fixed-width or is the '-', which doubles as part of the result, a delimiter?), trim strings, knows that "Aug/24" is August 24th, deals with wrapping of the months over the two years, is sensitive to indentation, and understands that "Matchday [0-9]+" and the [] bracketed dates are section delimiters. And what about that first line beginning with '=', comments? Where is the formal grammar for this format?

CSV of "matchday,fulldate,team1,team2,result" would be just as easy to read, much easier to parse, and probably smaller in size

Good point. See the football.csv project :-) @ https://github.com/footballcsv Here's, for example, the Premier League 2019/20 match schedule example - https://github.com/footballcsv/england/blob/master/2010s/201...

The point is as you say - the .csv format is easy to read / parse / write with a script for automation BUT it's way harder to start from scratch to input / type and keep it up-to-date. That's why you need both type of formats (one for hand-writing and one for easy auto-generation).

> rather than using something generic like 'jq' is telling.

The best generic tool for managing (structured) data is SQL. Once you have the datasets imported (via the custom readers / loaders) it's just plain SQL (and works with SQLite, PostgreSQL, MySQL, etc.)

For large data repositories, especially public/open datasets, a major concern is versioning. While it is not impossible to render a nice diff between two SQLite files, it's not as ingrained in our everyday tooling (e.g. GitHub) as plain-text diffs.

For small to medium-sized datasets, a nice middleground would be SQL dumps. Put the dumps in Git for versioning and diffing, and load them into $DATABASE for actual queries.

As great as such formats are for human consumption, they should come with reference specifications and parser implementations to be usable.

You might like the Comma-Separated Values (CSV) Format Specifications (and Tests) org @ https://github.com/csvspecs Trying to improve the world's most popular plain text format (and - surprise, surprise - nobody cares).

Plain text files that don't have a parser/schema also leave room for later breakage when somebody wants to add a field, make something longer, put a comment or note in, etc.

I find it weird that Emacs is not present in "Tools" section, even while org-mode mentioned several times in descriptions (as a compatibility) of other tools.

I recently just upped my StandardNotes subscription (the Black Friday ad is still active), and I'm now locked in for ~5.5 years. It's a very plain-text webapp/mobile app that aims to be simple and long-lasting, yet feature-full by means of optional extensions. It's not perfect, but I've been using it for a few months now without any data loss/major bugs encountered, and was excited to use it to ditch Google Keep/Google Authenticator.

It's amazing what you can do with simple text, especially with a Markdown-supporting editor.

I tried to love standard notes but I had several times where note contents were overwritten or missing between machines. I looked at the API for syncing and it did not give me confidence.

Using pass + git now. Works great.

Do you recall when this was? This kind of feedback is highly unusual for us. Most users love SN precisely for its reliable sync. Our syncing engine underwent large-scale changes in June/July of this year to solve an edge case with opening out-of-date clients. If you experienced any issues after this date with updated clients, I'd be very surprised, but would love to hear more if you can spare a moment.

The only other issue we have heard of precisely one other time has to do with Firefox pinned tabs + some assortment of Firefox browser extensions. To be clear, any reproducible issues with syncing are 100% fixed as quickly as possible.

Lastly, regarding our API for syncing, while our encryption specification is described in plain text detail, you'd have to inspect our source to see how syncing works.

I hadn't heard of StandardNotes before so I just went to the StandardNotes website. The explanation there is decent, but why no screenshot(s)? I had to go to Google Images to see what it actually looks like.

Out of curiosity - which Firefox browser extensions? I typically have SN open on my work PC in a Firefox pinned tab, and at home in a pin tabbed, and then on and off on mobile. I've never lost any data, but sometimes I'll have to refresh the tab for the right hand pane to load when just opening Firefox.

Is it possible to use VIM as a text editor in the terminal with SN? Or are users required to use a text editors supported by SN? This seems like an application I'm looking for but I can't ditch my vimrc and plugins

Yes, you can use https://github.com/tannercollin/standardnotes-fs to edit your notes with vim.

Wow, this might actually be what I need! Thanks!

Thanks for the follow up.

This was July or August of 2018 and Chrome on the desktop and Android.

Ah yeah, it would most likely have been the reason we updated our syncing engine in June of 2019. I don't believe you'd experience any of the same issues today.

I've switched to pass + git for my task list, diary, notes, creative writing. And of course passwords. It's working far better than the mix of things I was using previously.


I use working copy for accessing a git repo where I keep notes on my phone. It’s a great little app.

The only downside is I sometimes forget to commit and push, then expect docs to magically show up on my Desktop. I also wish it were a bit easier to add templates.

I’ve been building a markdown interpreter on top of that repo to parse some of the more structured parts of my journal into little graphs and things (so I can see how good I am at doing all my todos overtime, for example). I’m thinking about creating a sync system so I can get the real time saving, too.

I really, really want to just deal with plain files. So I think I’m going to try cooking up some sort of interface that commits to a git repo automatically/can spit out some templates and things, but have it be just git and plain files under the hood.

I've done this[1], it works super well. The templating and automatic git management makes it seamless to work with. Hopefully my codebase is enough of an inspiration for you to make your own tool!

[1] https://github.com/ghthor/journal

For mobile, I just use the `pass` Android app. It's very simple as an editor, but has build-in git support. My biggest issue has been forgetting to push and then creating merge conflicts, which don't work well on encrypted files.

I use markdown formatting for everything, so it's easy enough to export if I want to. For my diary I've written a script that decrypts the files (one per day), concatenates them, builds and index and spits out a single HTML file.

What are you using to encrypt/decrypt files?

In the script? the node-gpg package.

Was more curious about whether the pass app for android supports GPG, or whether you tend to edit outside and then paste stuff into it when you want to encrypt documents.

That's the main thing I'm lacking with my setup. I normally use git crypt when I need to encrypt something in a git repo, but I can't access files I encrypt with git-crypt via working copy.

I love the look of SN and their vision but its seems like if you start using any of the paid features that you are pretty much held hostage forever.

like the folders feature for organising your notes. what if for some reason you don't have the funds to pay next time your subscription is up, do you just go back to having thousands of notes without any organisation?

I pay for dynalist even though I don't need the premium features but because I want to support the devs and hopefully decrease the change of the service disappearing in the fir future. but it nice to know if I can't afford it for a year or two that I can still use service without having any drawbacks

i want to like StandardNotes but they basically force you to use the 5 year plan and it's much too expensive a cost to pay straight up (but i could and would use them if they slimmed it down to an annual charge, maybe even bi-annual, the current annual charge is overpriced tho). Bearapp is by far my favorite both by design, cost, stability and features, but I've left the Apple echosystem and their webapp isn't available yet and probably a long way off.

i guess, for us who can't afford StandardNotes, we're stuck with Joplin. bad phone app, no web app. but it has decent features and CLI support.

You can self host SN.

I don't have the economy to run my own server which would be more expensive than buying their 5-year subscription plan.

There is some irony in this, but it is still a fair complaint

Markdown is not plain text. Markdown destroys your single newlines. Plain text does not.

Markdown is plain text.

The output of Markdown processing is not.

Markdown is intended to be readable without processing as its syntax is mostly based on plain text email conventions. You should consider the ability to process Markdown to another output format to be an almost incidental benefit to using Markdown, rather than its primary function; meaning, Markdown syntax conveys semantics even without processing.

Its line behavior is based on plain text email client conventions, and plain text editor behavior, which many do not by default perform line wrapping, nor necessarily should, depending on user preference. Meaning, a Markdown file should be readable with line wrapping turned off, hence why it consumes line breaks, unless you use two spaces at the end of a line to override this behavior. (Think of the two spaces as an invisible rendering hint to Markdown processors.)

Email line length specifications: https://tools.ietf.org/html/rfc2822#section-2.1.1

Yes, Markdown is like HTML, its input is a plain text format but its output looks different (your single newlines get removed from the output, because single newline has a different meaning in the source code than in the output, unlike in real plain text, where they stay newlines)

> and plain text editor behavior, which many do not by default perform line wrapping

Not true, in a plain text editor you can make ascii art, or a dashed list of items, without having to type special syntax, and it will not become one long line

Dynamic line wrapping for display is something different than removing newline characters ("\n") you type in the string. Markdown does the latter. Text editors do not remove newlines you type.

> plain text email client conventions

I don't think plain text email ever removes a deliberate newline you type either. Does it?

I'm curious how you use Standard Notes for 2FA?

Likely using the TokenVault[1] extension for StandardNotes.

[1]: https://standardnotes.org/extensions/tokenvault

That is correct.

I use this plain text planner / calendar every day and I love it, if I can say so myself, since I made it too. I've been using it for a few years now and I can say that it has definitely made me more productive.


You can plan and log your day in plain text and it visualizes your schedule.

Markdown for planning, if you will.

> https://crushentropy.com/

That's a great name for a planning tool.

This is awesome, have been looking for something like this for a while, wondering if there's a way to export it to and from my ical

Thanks, I'd be happy to implement that. Can you please email me? My email is in my profile.

Check out NotePlan too.

Sounds great. Did you open source the parser?

Thanks! I haven't yet, but I'll work on releasing the code since there is interest :-) My email is in my profile. If you email me, I can let you know when it is available.

Looks really good! Any chance for the code?

Thanks! Okay I'll work on releasing the code. My email is in my profile. If you email me, I can let you know when it is available.

I really feel like this site should be in plain text.


  curl -H 'Accept: text/plain' https://plaintextproject.online/
and was disappointed with HTML...

It purports to be, even though it isn't:

>Believe it or not, plain text is used everywhere. Even when you don’t see it. Where? In the source code for software, web pages, blog posts and articles (like this one), configuration files on your computer, and more.


Looks good in lynx, but having the site be a .txt would be cute, if annoying.

Maybe it’s made of Markdown.

All I see is text and a few links. Are you claiming that typesetting doesn’t count as plain text?

If so then what do you call books?

>Formatted text, styled text, or rich text, as opposed to plain text, has styling information beyond the minimum of semantic elements: colours, styles (boldface, italic), sizes, and special features in HTML (such as hyperlinks).


Books don't have links.

Sometimes I forget that even HN has people who will happily argue about absolutely anything.

Plain text is printed in a physical surface by mechanical or manual means, but you don’t seem to have a problem with pixels.

Footnotes, figures, and bibliographies all refer to material out of time and space. Frequently you had to bust ass to make use of them but they were there. And they were replaced with something demonstrably better.

So you want a website about plain text with no hypertext at all where you have to copy and paste URLs in order to get past the landing page, in order to have a plain text experience. Maybe bullet journals should only be described in bullet journals and embroidery instructions be embroidered onto fabric.

> some of you are thinking, “but John, you just said there’s no difference between geeks and nerds,” and to you I say, “shut up nerds.” - John Hodgeman

The point is that this site is literally about plain text files, i.e. not using a markup format or other adornments.

We use other media to learn and talk about every medium. So what?

You do at least recognize that you guys are bagging on OP, right?

Just let it go man. Vannevar Bush was essentially talking about hypertext (and the semantic web) in the late forties. MIME types didn’t exist until decades later. It’s a jargon term and a concept, and the jargon term is often rendered as a single word.

not to be That Guy, but: all those things listed under each bullet are very nearly just org-mode documentation chapter titles.

Org is very clearly Just Plain Text, but there is a nontrivial caveat, which is "... backed by LISP, so text is also data is also code is also text". Most of the real goodies (babel, refile, capture) will not (ever, probably) work outside of emacs.

I agree that plain text is rad, though!

Furthermore, the templates provided are basically proto-org-mode syntax probably re-invented by someone who has never seen org-mode in the first place.

To me, that speaks to how natural much of (but certainly not all of) org-mode syntax is.

Related: https://plaintextaccounting.org/

In particular, the beancount community is pretty strong, judging by the frequency of posts in the mailing list and the Telegram group I'm in.

I’m going to smuggle in some hyperbole, but Ledger fundamentally changed the way I view software. Other than programming languages and excel, there’s not much other software I’ve used where the actual solution is consistently such a short gap from my desire for a solution to exist. Good software should make you feel more powerful every time you use it.

Ledger compelled me to see progressively structured but minimally verbose “plain text”, as an input, as a large advantage with regards to barrier to entry, provided you have excellent documentation, intelligent design that’s close to the domain at hand, and copious examples for that structure.

Power users can dive deep into the syntax at will, and evolve a simple file into a complex one at their own pace over time. Feature discovery is like discovering a language, which makes sense, because you’re discovering how the plain text you’re typing matches a parser, and how that parsed representation maps to higher level concepts.

Meanwhile, my nontechnical friends are totally capable of keeping a ledger, and reading the results with minimal assistance.

Learning software that’s been built this way is like learning a language; it’s a challenge that’s tackled in stages and allows you to progress at your own speed.

I didn't see any mention of in a quick look through the linked website, but the book "The Pragmatic Programmer" is one of the best resources you'll find for making the most out of text-based tools. PP goes a little beyond that, too, it's not the book's sole focus, but it's a major one, and the book is a classic: https://www.amazon.com/Pragmatic-Programmer-journey-mastery-...

I agree, but I found some of the relevant practices really hard to adopt. For example, how do you setup your tooling to put documentation in one place so it can be used for a wide variety of purposes, like code comments and relevant customer docs? Is that realistic from both the dev and user-facing perspectives?

Plain text is great when I am on my laptop, but not as well as soon as I want to, for example, check or update my todo list on OneDrive/Google Drive on my phone or on my work computer.

I have found myself moving back into proprietary formats like docx and xlsx because of the above.

All I want is a folder full of markdown files (and other files that need to stay in their original format), but I not could find a way to make it work on mobile.

I use Joplin, it uses markdown so I have my folder of files I can grep. It also has a mobile app and you can set up syncing with WebDAV, I use Seafile.

+1 for Joplin. I moved all my work notes to it and set up Syncthing with my phone and homeserver. Works beautifully.

Seems like there should be an app that serves as an editor for you well enough. The syncing problem is only a problem because Apple (I'm assuming your on iOS, and I don't know as much about android) doesn't give you a fucking filesystem.

I'd be pretty happy with something like ViMobile, and `git push` personally.

This situation has improved a lot within the last year. I'd highly recommend trying out a combination of a-Shell (includes vim!), and WorkingCopy for git. Both of these can access any folder in Files or any external file provider (even outside of their sandbox). SecureShellFish is also great if you want to interface with a server.

And before anyone asks what ViMobile is... I wouldn't know, developing applications for iOS is stupidly hard.

What about the native files app? Right now it seems Bear is using it.

That seems odd... at least on iOS, aren’t there a million markdown editors? What problem did you run in to?

That editing text files on mobile sucks, whereas selecting a date with the date selector, toggling an item as done with a checkbox click etc are much better...

That just seems a limitation of mobile keyboards: there’s no arrow keys so markdown editors lack navigation. One benefit of iOS is that if you hold the space key down it allows you to freely move your cursor around.

Markor works well on Android.

Thank you for this recommendation. Joplin didn't allow me to manage the files manually, but this gives me far more control. As a bonus, it supports todo.txt, which I was already using. Paired with Dropsync, this is my find of the month.

This is what I'm using now, and it seems to be working well although I'll point out that it is nagware. I'll put up with the intermittent begging for donations over ads, in-app purchases, and data mining you'd find on other apps.

I keep a similar list of sites where you can host plain text or hypertext or Web projects.


Except it's html. They didn't serve text/plain. I do get that thinking as words helps but isn't org mode or markdown plaintext?

That would be text/markdown :) Although serving markdown as text/plain should be totally fine if the client is a web browser. It would be incredibly useful if web browsers rendered text/markdown natively, though - mine renders PDFs, so I think the precedant's there.

I too would welcome this and text/org-mode

I have a plain text file that’s basically my notes, bookmarks, how to write ups and anything. I mark each section with hashtag labels, and set alias vinfo=vim /path/info.txt. Anytime I need to reference back how to setup some configuration, or the typical arguments for a command, or likes to YouTube vids on my watch list, I just vinfo in, and /#<topic>. It’s the best system I’ve used, and out lived all the Evernote’s, todo lists, stickies, whatever. Dropbox or chron rsync it to where u want.

I used to store bookmarks in the browser. But they wouldn't survive changing the browser, upgrading the browser, reinstalling the operating system, or moving to another device. Besides, I didn't really want to share my bookmarks with the browser vendor, every browser app vendor, and random web sites.

Now I just store them in a .txt file. My text editor recognizes URLs and I can just click on them. Matching { } is also supported, which is all one needs for a tree-style database.

> Matching { } is also supported, which is all one needs for a tree-style database.

Could you elaborate on this; maybe give an example?

I never thought of plaintext as a way of life, but I think I agree with it in principle (as many others on here probably do.) I didn't know I was part of a movement, but I did write my own simple (and open source) hours tracking/invoicing tool on plaintext principles: https://github.com/ses4j/ts

With organice[1], you have access Org mode without using Emacs. It is an implementation of Org mode without the dependency of Emacs. It is built for mobile and desktop browsers and syncs with Dropbox, Google Drive and WebDAV.

1. https://github.com/200ok-ch/organice/

Plaintext email is great too, cuts out a lot of superfluous junk.


They do not list Heirloom-mailx, which is what I use. Heirloom-mailx uses a command-line interface, uses plain text email, and does not use top posting. It also supports entering pipe commands.

I think many things can and should use plain text and yet they don't. Even, with gopher you can easily have plain text files, and simple menus which could be implemented by many different kind of user interface, you don't need to do what they do HTML try to have desktop/mobile and then it doesn't work on anything other than they expected it to be.

Many documents I will write plain text file, compatible with everything more than HTML and Microsoft Word is. I also don't like WYSIWYG when I do want text formatting.

I don't use favicon on my own server, and have it disabled on the browser. I also think "Plain Text Project" uses too much CSS too. Just you can use plain text. I don't want to use your large font sizes and narrow columns.

I use file with plain text for editing. Articles on Usenet and Unusenet too, are written plain text sometimes also with headers, but the headers are also a plain text just are more structured. Some programs have a different user interface for adjusting the headers, but I just use them same as with the rest of the text.

In addition to Usenet articles, there is many other thing that you can use a plain text file for many other things. Depending what kind of data it is, you might use just one string per line, or CSV or TSV, or JSON or YAML, or RDF (RDF/XML isn't so good, but I think the RDF Turtle format is good), etc.

In many cases I wrote my own programs because I do not like the existing ones.

Assume "plain text" means something like traditional printed text. This has three features which don't seem to be implemented on computers in a sensible standardised way:

* Spaces. In traditional printed text there is space between words but there are no leading spaces, double spaces or trailing spaces, so the ASCII space character is not an adequate representation.

* Paragraphs. In traditional printed text you can start a new paragraph but you can't have an empty paragraph so '\n' is not an adequate representation. Then there's the problem that some systems use '\r' or "\r\n" instead of '\n'. Then there's the problem that Emacs's "long lines" mode and Git's --word-diff don't work properly. (Almost certainly patch tools and "git rebase" don't work either.)

* Emphasis. In traditional printed text words and phrases can be printed in italics for emphasis. There are several ways this can be indicated in a computer file, but do editors and diff tools handle them nicely? I think not. Also, it's not completely clear how this should work. For example, I don't think <em></em> should be allowed, but are <em>a</em><em>b</em> and <em>ab</em> the same thing, or different things? You wouldn't be able to tell them apart in traditional printed text, but in traditional printed text you can't tell whether a space, a full stop or a dash is printed in italics, or not, either, so it's clear, I think, that we need to somewhat extend the concept of emphasis from what's available in print, but how far do you extend it? (What about nested emphasis?)

That I believe in stuff like markdown. You usually need like 3 or 4 options

Great find! But why on earth is there no mention of git, or the other VCSes? IMHO they’re a huge reason for using plaintext for more purposes.

I've been kicking around the idea of a plain-text GUI to demonstrate what a "GUI Markup Standard" may work like. Making a graphics-enabled version is a lot work for a demo.

VB-classic also had a text-based mouse-able GUI option for a short while, but it never took off. It was based on ANSI escape sequences for DOS consoles, which is sort of in-between "pure text" and graphics. A pure-text GUI is also doable, but console approach is probably more compact because it can use colors as cues instead of symbols.

An alternative or supplement to a markup standard is a text-based screen designer. Both a pure-ASCII and console text UI can be defined using plain text for semi-WYSIWYG designing. Rough example:

     $ Employee Edit Form
     * _thisLine.title
     $ Last: [#last    ] First: [#firstname] MI: [#MI]
     * #last:fullname=last_name, required=true; #MI:fullanem=mid_initl
     $    {#Save}    {#Cancel}   {#Other}
     * #Save:click=_thisForm.submit; #Cancel:click= _thisForm.close
     * #Other:click=specialProcedureX(), display="Other Options"
Symbols and conventions:

     $ = start of template line
     * = start of definition or command line
     [...] = input widget template
     {...} = button template
     # = start of reference name. 
     "fullName=" = use if actual database name is diff from reference name
     ; = definition or command separator
     "type=" = to define widget type, such as SELECT (not shown)
     "display=" use if actual label is different from reference label
Notes: "type=label" can be used to make bold or italics. The definition line(s) don't have to follow the template lines in most cases. One can thus optionally put most definition lines at the bottom. It may make interpreting the template easier for some people.

Interactive shell libraries exist. They are quite common for Unix oriented tools. Might be possible to reimplement the same API for a GUI

An example product? Note that I was talking about two different things: a GUI markup standard (probably XML based), and an ASCII WYSIWYG GUI designer. I'll make the distinction clearer in an edit.

I can recommend https://jrnl.sh for a minimal plaintext journal.

Plain text is best text. Word format is the worst when it comes to rendering from, say, legal docs to web copy, or any other hidden characters.

I came here to voice my support for PlainTasks plugin for Sublime, and found myself disappointed that the author skips over the gold standard in modern text editors... Sublime Text.

I love plain text, and generally agree with the principles here.

That said, I think it's important to remember that plain text is still a binary format under the hood. Its power comes from its simplicity and many independent implementations. There's a lesson there for designing software in general, especially APIs and protocols.

I also think it's somewhat unfortunate that breaking changes were made to the plain text "API" along the way, in the form of Unicode. Unicode is great, but I wish it wasn't conflated so much with the original plain text. Plus it adds significant complexity. Sure, you can view a plain text file from 1991 in today's editors, but you can't view a Unicode file in an editor from 1991. And it's not apparent to the user why that is.

Wasn't Unicode made to be kind of backwards-compatible with ASCII? If you stick to the ascii subset of unicode characters then it should be exactly the same, and if you don't then there's no good way to convert it back to ascii anyways.

When I'm not using a custom tool I tend to fallback on two (or three) alternatives:

* Markdown-ish in a text editor

* Google Doc

* Google Sheets

The first is for any quick notes I need to take or anything that might turn into a code checkin, confluence page, etc. The second is for anything I think I'll have to share and may want collaborators. The third is for almost everything else.

I feel I disagree with a lot of people in the rest of the comments. I think plain text in general is a major pain to deal with. I recall several years ago having to deal with CSV parsing and I was aghast at how complicated that is to get "correct". Give me highly structured data formats please. I'll take yaml, toml, JSON or even XML over CSV, TSV or plain text at pretty much every opportunity.

CSV is fairly OK if you just ignore Excel. Unfortunately, if you're working with others, they won't let you ignore Excel.

And yet, the site uses a favicon of a typewriter (https://plaintextproject.online/favicon.png). It's so hard to be pure in this world!

It's something I don't like about what programmers tend to mean when they say plain text: Plain text isn't the same as ASCII. It isn't the same as Latin-1 or some other eight-bit encoding. UTF-8 is plain text. UTF-16 is plain text, too, but UTF-8 is better to use on the Internet.

My point is that you can go well beyond the Latin alphabet and still be in the world of plain text. You can have correct quotes, as opposed to the apostrophe-quotes typewriters saddled us with, and still be producing plain text. There's nothing inherently "fancy" about using the writing systems most of the people on Earth are fluent in, and, thanks to Unicode, there's many fewer compatibility problems.

You say this but I bet most of the people who style themselves plain text purist really do mean ASCII.

Does anyone know of a system for managing contacts in plain text? I would love some CLI I could use to fuzzy search contacts, making it easy to grab info to my clipboard for using email clients like mutt or aerc.

I don't know of an existing system, but you could look into constructing something using FZF and a plain text file of contacts names and email addresses formatted in a specific way.


  tre-agrep -3 "Joohn Doe" contacts.txt|cut -d':' -f1

That’s nice I guess, but doesn’t address my main wish around text: that I will continue to be able to read textual email from my friends without using a full browser engine.

I switch to bear as it is text based with tag. I think similar text based and Cli would be useful and may be better than using a too specific And structured format.

I use TaskPaper synced via Dropbox to achieve a level of organization across my tasks, notes, and deadlines: https://www.taskpaper.com/

The beauty of it is that I have a GUI when I want it, but at the end of the day it's all stored as plain text, so I'm not bound to the GUI and can fall back to any text editor effortlessly.

I use Wordpress.com for blogging and its wizzy-wig editor because it gives me a rough visual estimate of how long my text really is. It’s a perfectly stupid reason and totally inadequate for the level of tech-savvy I’m supposed to have. Or maybe it’s just that the heavy crufty web editor was developed for a purpose and is good at it.

I'm a fan of Writeroom for Mac (http://www.hogbaysoftware.com/products/writeroom).

Nice to see Joplin in the list. It's a note-taking app, sorta like an open-source Evernote, and one of the _main_ reasons why I use it is indeed because it's plain text (markdown) only.

You should definitely add SGML to your list of tools. SGML can turn plain-text files into markup (HTML) documents using your own custom rules (via short references).

Plain text is the cornerstone of my b brainstorming app at jumproot.com. there are other tools too but it all starts with plain text.

A saas product is the oposite of a plaintext file..

Alright now everybody, please, resist the urge to post the shitty copycat sites that are always posted after motherfuckingwebsite.com. You can do it!

This is the most hipster project I've ever seen.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact