by mmillin on 12/2/19, 7:07 PM with 202 comments
by mntmoss on 12/2/19, 10:05 PM
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.
by loh on 12/2/19, 9:09 PM
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.
by nlh on 12/2/19, 9:48 PM
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.)
by geraldbauer on 12/2/19, 8:34 PM
by brokenkebab on 12/2/19, 11:39 PM
by tubbs on 12/2/19, 8:58 PM
It's amazing what you can do with simple text, especially with a Markdown-supporting editor.
by kirubakaran on 12/2/19, 9:24 PM
You can plan and log your day in plain text and it visualizes your schedule.
Markdown for planning, if you will.
by jahbrewski on 12/2/19, 8:53 PM
by hprotagonist on 12/2/19, 8:14 PM
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!
by yegle on 12/2/19, 9:47 PM
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.
by hsitz on 12/2/19, 10:24 PM
by Emendo on 12/2/19, 10:21 PM
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.
by kickscondor on 12/2/19, 11:00 PM
by ggm on 12/2/19, 8:11 PM
by ImprovedSilence on 12/3/19, 1:28 AM
by WalterBright on 12/2/19, 11:07 PM
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.
by ses4j on 12/2/19, 8:27 PM
by preek on 12/3/19, 10:01 AM
by Nerada on 12/2/19, 10:07 PM
by zzo38computer on 12/2/19, 10:49 PM
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.
by bloak on 12/3/19, 11:37 AM
* 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?)
by pletnes on 12/2/19, 8:56 PM
by tabtab on 12/2/19, 9:17 PM
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"
$ = 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 labelby rhardih on 12/2/19, 11:05 PM
by marcg on 12/2/19, 11:18 PM
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.
by anderspitman on 12/3/19, 5:22 PM
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.
by reggieband on 12/3/19, 12:11 AM
* 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.
by gojomo on 12/2/19, 8:57 PM
by lwhsiao on 12/3/19, 5:33 AM
by hollerith on 12/2/19, 9:31 PM
by ngcc_hk on 12/3/19, 9:29 AM
by MontagFTB on 12/3/19, 12:53 AM
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.
by thanatropism on 12/3/19, 1:28 AM
by gtzi on 12/3/19, 7:49 AM
by whatever_dude on 12/4/19, 12:38 AM
by tannhaeuser on 12/3/19, 8:19 AM
by agsilvio on 12/3/19, 9:06 AM
by miguelmota on 12/2/19, 11:23 PM
by sktrdie on 12/2/19, 10:18 PM
