Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Plain Text Project

plaintextproject.online

Post reply on HN
Print view View original

101–110 of 208 posts

Re: The Plain Text Project

#101

Post by aeneasmackenzie »

tekknolagi wrote: post #40
mntmoss wrote: post #33

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…

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.

Check out lentil: http://hackage.haskell.org/package/lentil

Re: The Plain Text Project

#102

Post by MontagFTB »

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.

Re: The Plain Text Project

#103

Post by nextos »

nickloewen wrote: post #69
loh wrote: post #15

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…

> 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…

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

Re: The Plain Text Project

#104

Post by yonilevy »

mntmoss wrote: post #33

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…

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

Re: The Plain Text Project

#105

Post by TeMPOraL »

loh wrote: post #15

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…

> 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.

Re: The Plain Text Project

#106

Post by TeMPOraL »

nextos wrote: post #103
nickloewen wrote: post #69

Earlier quoted context omitted.

> 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…

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 i…

> 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.

Re: The Plain Text Project

#107

Post by TeMPOraL »

Alex3917 wrote: post #73
mrob wrote: post #38

Earlier quoted context omitted.

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.

> 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.

Re: The Plain Text Project

#108

Post by nextos »

TeMPOraL wrote: post #106
nextos wrote: post #103

Earlier quoted context omitted.

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 i…

> 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…

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.

Re: The Plain Text Project

#109

Post by pckls »

CharlesColeman wrote: post #88
loh wrote: post #15

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…

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

Re: The Plain Text Project

#110

Post by jamiesonbecker »

mntmoss wrote: post #33

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…

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`.
Post reply on HN