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

Write plain text files

sive.rs

Post reply on HN
Print view View original

361–370 of 425 posts

Re: Write plain text files

#361

Post by awill »

crossroadsguy wrote: post #354
awill wrote: post #98

Earlier quoted context omitted.

I'd never heard of fsnot.es. It looks great. I bought Ulysses ages ago on Mac because I wanted a performant, native-app markdown app that supported external folders. Unfortunately, shortly after purchasing it Ulysses went subscription only. I had no alternative, so I kept paying. However, I don't used any of the advanced features, and I'm really overpaying when I have no iPhone, don't use iCloud, and just do simple m…

You won’t be able to. See if you’d like Joplin or Simplenote. I still use Simplenote. Because even though FSNotes seems promising, it’s still not there.

but both of them store notes in a proprietary way, so if they shut down (or I just wanted to move), wouldn't it be harder to migrate off?

Re: Write plain text files

#362

Post by GrumpySloth »

Nullabillity wrote: post #350
yakubin wrote: post #261

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…

The biggest UX sin of Git is that rebasing is featured so prominently. If you had just done a normal merge commit then Git could have realized the common history, done a three-way merge, and resolved the conflict automatically. But no, people always seem to insist on that linear history is the only concern that matters, explicitly delete the history, and then wonder why Git is so annoying and easy to screw up. Maybe…

When I have a chain of commits pending review on Gerrit, and I fixed some flaws in the first commit in chain and need to rebase the dependent commits, merging is not an option. And rightly so: when I look at the master branch, I don't want to see random corrections someone made during review, they're just irrelevant once the reviewed changes are merged.

There are many reasons why linear history is important. Rather than saying that "you shouldn't want to do that", I'd prefer it if the tools people use were fixed to better serve the things people actually want to do.

A merge would only make sure that I don't need to resolve the same conflict multiple times. It wouldn't result in the conflicts not being generated in the first place, or them being saner. The only difference in conflict resolution between rebasing and merging is that the sides are flipped (what's shown on left in rebase, is on the right in merge, and vice-versa). Which doesn't address the second issue I listed: conflicts are not only repeated, but the conflicts themselves are pretty crazy. In my example, often-times C would never even touch files which were detected as having conflicting changes with A or B. It was pretty absurd that I would have a 3-line change in C, several hundred-line changes in A and B, yet the biggest conflicts would be triggered when rebasing C on top of B, and those would be in files C did not touch. Other times diffs in conflicts would have most of the lines added and removed actually identical, with only a couple in the middle different. Why would git mark them as conflicting, is beyond me. And then there was the issue of git not detecting conflicts, when it should have, instead merging changes in a way that broke source code. None of those issues is better handled by merging than by rebasing. Most of them however have pretty good solutions in a patch-based version control system, as opposed to snapshot-based like git (conflicts in files which weren't changed? not going to happen). An even better solution would be binary formats with domain-specific merge logic, like the one in KeePassXC.

Re: Write plain text files

#363

Post by bellweather49 »

simion314 wrote: post #183
testermelon wrote: post #161

Earlier quoted context omitted.

I've heard somewhere that docx is actually gzipped xml. But I never really confirmed that myself. But it's binary once gzipped, so your point still stands.

>I've heard somewhere that docx is actually gzipped xml. But I never really confirmed that myself. docx and epub are zip files, you can rename them with a .zip at the end and open to see what is inside. It might not be as simple to zip them back, at least for epub is very important to zip the files in a certain order but I forgot the details, but is easy to do from command line.

Or use Vim; it has built in support for zip files, so you can just type something like `vim my_file.docx` and it will open the files in netrw (the built in file explorer). Move to the file you want and hit enter. "word/document.xml" has the main document contents in it.

The xml will probably need to be run through a formatter to be readable. You can type `:%!xmllint --format -` if you have xmllint installed.

Now prepare to spend several hours trying to make sense of the xml. :-p

Re: Write plain text files

#364

Post by Qub3d »

One of the ultimate plaintext champions is (unsurprisingly) John Gruber, the "inventor" of Markdown.

One of my favorite facts about his site, daringfireball.com: You can add the extension .text to any permalink and it will render that page as markdown:

- HTML: https://daringfireball.net/linked/2022/03/01/mozilla-on-tind...

- Markdown: https://daringfireball.net/linked/2022/03/01/mozilla-on-tind...

Re: Write plain text files

#365

Post by pmeunier »

yakubin wrote: post #261
imgabe wrote: 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…

> However, I feel that version control focused on text breaks,

Pijul doesn't, by the way, the diff algorithm is customisable. I wrote one industrial application of Pijul that uses spaces as breaks, and semantics-aware breaking is totally doable.

Re: Write plain text files

#366

Post by pmeunier »

FreezerburnV wrote: post #334
Hackbraten wrote: post #263

Earlier quoted context omitted.

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

I had no idea these options were a thing. Thank you for pointing them out, adding them to my config immediately and hoping it makes some merges and whatnot easier going forward.

Hint: rerere doesn't always work. It's still guesswork, like the rest of merges/rebases/cherry-picking in Git. This is because looking only at the tips of branches doesn't work, and that's the only thing Git can do (with or without diff3 as the merge algorithm).

Re: Write plain text files

#367

Post by sdoering »

nextlevelwizard wrote: post #231
sdoering wrote: post #187

Earlier quoted context omitted.

Code I write, be it python, php, HTML or JS is still plain text as a format. I can open any of these code documents in any dumb text editor. The fact that some other tool can do more with these files, parse them, execute them, "extract" some logic from them isn't relevant to the fact that I can open, read and edit these files as a pure and plain text file. Therefore adding parsable parts/logic to files like YAML head…

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.

Interesting interpretation of my words. Or should I say projection? Nothing to do with what I said. But if it pleases you. I am fine being an incoherent and unsavable something.

As said. There is no technical difference between a txt or a php file. I can both run through cat and grep stuff.

Are there special programs that interpret the contents differently? Sure. The same with the difference between a php and a py file. Different interpreters doing different things because of different definitions how to 'read' the content.

All pure text, just different languages.

To borrow from your metaphor:

One is Earl Grey. One Darjeeling. One might be Green Tea. One (God forbid) herbs as tea.

Re: Write plain text files

#368

Post by sdoering »

nextlevelwizard wrote: post #270
0xad wrote: post #242

Earlier quoted context omitted.

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

Why not. If there is a tool like pandoc parsing and translating your text and markup to anything (html, pdf, word docx, etc). Why not. I did that quite often at a former job.

All version controlled in git.

A few markup headers. Text formatted in markdown. Later combined with a bit of templating logic to ensure different looks (one for client and one for agency) when translating it into the final designed report.

Actually more efficient than creating the two target documents with design from the beginning as the reports quite often changed in structure while being prepared due to changes in requirements.

Separating content from (re-)presentation was a time saver.

Re: Write plain text files

#369

Post by iLoveOncall »

gatonegro wrote: post #15

> Every few years a new company says you should use their special format. You have to pay them a monthly fee to use it — or keep all of your documents in their care. [...] When you store your writing in one company’s unique format, then you need that program to access it. Then the economy takes a turn, they go out of business, and your work is trapped in an unusable format. This is something I've been dealing with la…

> they're locked behind proprietary software that I couldn't use even if I wanted to

Hum, yes you could. The formats aren't dead.

It's like putting on a blindfold and saying you couldn't see even if you wanted. Just remove the blindfold.

Just install Windows or Mac.

Re: Write plain text files

#370

Post by simion314 »

bellweather49 wrote: post #363
simion314 wrote: post #183

Earlier quoted context omitted.

>I've heard somewhere that docx is actually gzipped xml. But I never really confirmed that myself. docx and epub are zip files, you can rename them with a .zip at the end and open to see what is inside. It might not be as simple to zip them back, at least for epub is very important to zip the files in a certain order but I forgot the details, but is easy to do from command line.

Or use Vim; it has built in support for zip files, so you can just type something like `vim my_file.docx` and it will open the files in netrw (the built in file explorer). Move to the file you want and hit enter. "word/document.xml" has the main document contents in it. The xml will probably need to be run through a formatter to be readable. You can type `:%!xmllint --format -` if you have xmllint installed. Now prep…

Vim is not for me, I unzip the epub/docx and then open the xml/html files in Kate, I had to do this to examine what is saved or how it saved or if my custom epub exported worked correctly. For epub I think you need to make sure the metadata file is the first one in the archive for it to work(so not sure if editing stuff directly in vim will preserve the order)
Post reply on HN