Live data from Hacker News

Write plain text files

sive.rs

261–270 of 425 posts

Re: Write plain text files

#261
post #35

Another advantage to plain text files: source control. You can check your writing into git and get a history of all your edits. It’s something programmers take for granted, but it would be amazing if this got more widely adopted outside of tech. The number of files with names like “Report Final Final draft v3.docx” is truly staggering. “Git for everything“ would be a multi-billion dollar startup easily.

The idea is pleasing, but when you specifically look at Git, its UX is rather disappointing. I'm not even talking about the CLI (after a while you can get used to it). I'm talking about resolving conflicts. If I have a sequence of changes A -> B -> C, then I change A and rebase B on top of A resolving any conflicts, then rebasing C on top of B will most of the time mean that Git will most likely ask me to resolve the same conflicts all over again and more. The kind of conflicts is also staggering. Each time I look at the conflicts it generated, I cannot explain how it could come up with that craziness. And all the while it also merged some changes without signalling conflicts, but instead breaking something in significant ways, without notifying me in any way, i.e. silently breaking something potentially important.

From what I've read, Pijul should fix at least the problem of needing to resolve the same conflicts multiple times over and over again. However, I feel that version control focused on text breaks, because the merging algorithm doesn't know anything about the semantics of what's represented in text. So yes, I'd say that version control in more areas would be nice, but one based on binary formats understood by version control. One glimpse of that may be KeePassXC, which can merge password databases and has never done it wrong in my experience.

Re: Write plain text files

#262
post #35

Another advantage to plain text files: source control. You can check your writing into git and get a history of all your edits. It’s something programmers take for granted, but it would be amazing if this got more widely adopted outside of tech. The number of files with names like “Report Final Final draft v3.docx” is truly staggering. “Git for everything“ would be a multi-billion dollar startup easily.

The idea is pleasing, but when you specifically look at Git, its UX is rather disappointing. I'm not even talking about the CLI (after a while you can get used to it). I'm talking about resolving conflicts. If I have a sequence of changes A -> B -> C, then I change A and rebase B on top of A resolving any conflicts, then rebasing C on top of B will most of the time mean that Git will most likely ask me to resolve the…

Have you tried git rere?

Re: Write plain text files

#263
post #35

Another advantage to plain text files: source control. You can check your writing into git and get a history of all your edits. It’s something programmers take for granted, but it would be amazing if this got more widely adopted outside of tech. The number of files with names like “Report Final Final draft v3.docx” is truly staggering. “Git for everything“ would be a multi-billion dollar startup easily.

The idea is pleasing, but when you specifically look at Git, its UX is rather disappointing. I'm not even talking about the CLI (after a while you can get used to it). I'm talking about resolving conflicts. If I have a sequence of changes A -> B -> C, then I change A and rebase B on top of A resolving any conflicts, then rebasing C on top of B will most of the time mean that Git will most likely ask me to resolve the…

While I agree in that Git’s UX is abysmal for the beginner or casual user, no one should have to endure resolving the same conflicts over and over again.

In my opinion, the following configuration should have been the default with Git:

    git config --global rerere.enabled true
    git config --global rerere.autoUpdate true
The `enabled` part means: transparently record all resolutions in a database, and re-apply them whenever bumping into the same conflict with the same pair of files in the future.

The `autoUpdate` part means: every time you finish re-applying a recorded resolution, please `git add` the result automatically for me so I don’t have to look for a "conflict" that’s actually no longer there.

Re: Write plain text files

#264
Any advice on syncing with iOS? I use iA Writer, but the syncing experience is awful because iA Writer is waiting for some sync provider (e.g. Dropbox) to implement the full iOS Files API, which it appears no one has done. That leaves iCloud as the only option.

Re: Write plain text files

#265

Earlier quoted context omitted.

The idea is pleasing, but when you specifically look at Git, its UX is rather disappointing. I'm not even talking about the CLI (after a while you can get used to it). I'm talking about resolving conflicts. If I have a sequence of changes A -> B -> C, then I change A and rebase B on top of A resolving any conflicts, then rebasing C on top of B will most of the time mean that Git will most likely ask me to resolve the…

Have you tried git rere?

No. That's the first I'm hearing of it. Thanks. I'll try it in the future.

Re: Write plain text files

#266
post #253

> NEED HIERARCHY? Use directories — also known as folders. I really wish I could define a custom order for files in a directory. A folder hierarchy is almost an outline, but not quite. Yes I could prefix with "01", "02", and sort alphabetically, but those are cumbersome workarounds and reordering is a pain. Are there file systems that allow for a custom order of files/folders?

I was just thinking about this at the weekend. One approach is to use a tool that supports [[Wiki-style Linking]], and have a kind of index/table of contents/home page for your notes.

Re: Write plain text files

#268

Plain text adoption often implies markdown for a richer experience, but we also have the wonderful https://orgmode.org markup. There is no shortage of markdown-based tools on all platforms. Our org markup options, on the other hand, are very few outside of Emacs. Org markup itself is super versatile and can power lots of use-cases. I built two org-powered apps for iOS myself: https://plainorg.com https://flathabits.c…

I wouldn't call those plain text, if it doesn't keep your newlines by default, it's not plain text but a markup language like HTML

BBCode is nice and keeps newlines, but something that uses markdown's syntax for bold and titles, but doesn't remove newline characters, would be ideal

Re: Write plain text files

#270
post #242

Earlier quoted context omitted.

Then the whole article loses all of its meaning. If you find yourself writing Python in Word something has gone so horribly wrong there is no saving you. Just use the good old file program and you'll see that in any coherent world we classify python, php, html, and js files as different from actual plain text files. This very much feels like you are trying to argue tea is same as plain water.

No. Open up a word document (.docx) in hex editor (head -80 foo.docx | xxd) and you'll see it's not a plain file on a binary level. Now do the same with any python, php, html, and js files and you'll see that they're plain files. That's the difference that Derek is talking about.

That makes the article extremely silly, actually almost pointless.

If you don't see difference between plain text files and text files then that's pretty much it for this conversation.

EDIT: just to hammer this point home; if you gave me a task to write a report in plain text and I delivered a .txt file with some custom markup language, would you consider the task to be completed satisfactorily? I wouldn't. You can argue that the specification of the task didn't exclude custom markup language, but any sane person would understand what plain text file means.

Post reply on HN