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 fo…
The Plain Text Project
31–40 of 208 posts
Re: The Plain Text Project
#32I'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 cons…
Interactive shell libraries exist. They are quite common for Unix oriented tools. Might be possible to reimplement the same API for a GUI
Re: The Plain Text Project
#33So 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.
Re: The Plain Text Project
#34Great 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…
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.
Re: The Plain Text Project
#35While 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 dum…
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.
Re: The Plain Text Project
#36Re: The Plain Text Project
#37Earlier quoted context omitted.
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?
Books don't have links.
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
Re: The Plain Text Project
#38I 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 fo…
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.
The real problem is dealing with SEO spam, not occasional false positives with hyperlink detection.
Re: The Plain Text Project
#39Recently 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…
Re: The Plain Text Project
#40Recently 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…