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.
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]
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.
https://marketplace.visualstudio.com/items?itemName=Gruntfug...
//hhh I want this to be done before I commit.
: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>
Edit: <C-f>0wa may work instead of Lefts, but I always forget about it.
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
Also it occurred to me you could use grep or rg, something like...
rg '\s*//\s*TODO' alias todogrep="vim $(grep TODO . -rl)"
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'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.
##########
Header
##########
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.
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?
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 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.
Is there any software that you think stands out as an example of this approach?
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.
The real problem is dealing with SEO spam, not occasional false positives with hyperlink detection.
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.
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--...
https://github.com/openfootball/england/blob/master/2019-20/...
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
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).
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.)
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'd be pretty happy with something like ViMobile, and `git push` personally.
It's amazing what you can do with simple text, especially with a Markdown-supporting editor.
Using pass + git now. Works great.
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.
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 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.
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
You can plan and log your day in plain text and it visualizes your schedule.
Markdown for planning, if you will.
That's a great name for a planning tool.
curl -H 'Accept: text/plain' https://plaintextproject.online/
>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.
If so then what do you call books?
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.)
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.
Also I think "double-entry accounting" literally means "N-entry zero sum accounting" as you describe it, and hledger supports it.
https://pragprog.com/book/tpp20/the-pragmatic-programmer-20t...
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 labelMy 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.
tre-agrep -3 "Joohn Doe" contacts.txt|cut -d':' -f1Org 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!
To me, that speaks to how natural much of (but certainly not all of) org-mode syntax is.
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.
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.
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.
Could you elaborate on this; maybe give an example?
* 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 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.
* 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.
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.
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.
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.