Quoted post unavailable.
Alternative take for this same sentiment: It's the year 2021, why has nobody figured out better ways to present knowledge than simple text files?
151–160 of 373 posts
Quoted post unavailable.
Alternative take for this same sentiment: It's the year 2021, why has nobody figured out better ways to present knowledge than simple text files?
I built a simple journal solution for myself two years ago. It sends an email every day and I can reply to it, and the response is stored in an SQLite database, in plain text. The db is on a remote server but copied to Dropbox every day (and in any case all the emails also exist in my sent folder). It is surprisingly effective at storing not just what I did with my day, but random thoughts and ideas, solutions to bug…
I'm somehow on the same boat as you. I've tried dozens of "fancy" tools but they never stuck. A plain text file, kind of a "flat wiki", that you can search with your text editor may be the grail of note taking. What I consider critical is to "tree-shake" it often to remove the cruft. Hints: - Tree-shake your notes each time you iterate them. You'll leverage your excitement and it won't be a chore. - Maintain part of…
The nice thing about both gjots2 and Zim, is that their source files read almost as easily as text. This is especially true for gjots2.
I like the hierarchical arrangement of gjots2. I still have Ctrl-F if I want to search, but sometimes in browsing a category, I find things I would not have found with search -- sometimes how I refer to things changes with time -- and I've got many years of gjots entries.
I do not, as gjots author Bob Hepple does, keep separate topics in separate gjots files -- one big tree in the left panel holds all topic headings.
Obsidian is great, but in a way it's quite limited as it only replaces the note-taking app / text editor I used before. We're building something similar but more capable https://acreom.com .
Quoted post unavailable.
Agreed on Markdown's limited expressiveness. I think the reason for programmers' attachment to Markdown isn't just about being able to operate on it in a terminal. It's about the general interoperability of plaintext. Terminal editing is one example, but even IDEs and non-terminal text editors also use plaintext. There's also the fact that version control tools are designed for line-based plaintext. Markdown is espec…
1000% this. Markdown will be around forever. I'll be able to open an old file 20 years from now, _because_ it's just plain text. That's a feature, not a bug.
I'm so done with tying myself to rent seeking proprietary formats. For something as personal, important, and long lasting as notes / writings, I'll take the minor hit on absolute feature set.
Quoted post unavailable.
It's true, most professionals use off-the-shelf solutions, the Office/Adobe suite, or other proprietary software like Catia, Autodesk, the likes. I have been nothing but frustrated by these options. I have dealt with gigabyte Illustrator files, as the inexperienced user accidentally embeds all linked media. I have been increasingly frustrated with "made up marketting terms" when saving Adobe proprietary formats, or OneNote's "invisible formatting language". I make a new line, then remove it, and whoops, the whole paragraph has been reformatted, all the equations are no longer in italics (despite this, I still use it for all of my study material, it's fantastic)! It helps to have a Markdown-like mental model when dealing with word processors, you understand the data hierarchy, which is at the end of the day underneath all of that GUI, most people I know who use Word make an absolute mess of the document because they have no idea how to have a consisent layout, they add new-lines, paragraphs, tables, fonts and indententations all over the place and then get frustrated when they don't get the desired results.
While Markdown may not be the best format with the most features, it has a fantastically consistent layout and it's easy to understand the hierachy of information. There is no obligation to use the terminal, you can open it in any visual editor. Also, I would not call the fact that it's plain text instead of XML/binary a limitation but rather a feature, not a "remenant of the 1970s".
There is something amazingly refreshing about knowing that what you see is what you get, I can't stress this enough. Instead of using buggy program that manipulates a mess of an XML file, you describe the layout from scratch and that gets "compiled" to a PDF. This is why programmer source code is written as text, and not in Word, for example, it's just plain information that any compiler can work with to achieve any sort of complexity. There is no hidden document metadata, there is no hidden bloat from [insert proprietary software here] having upgraded the document format several times over the years until it eventually corrupts something (I'm looking at you Premiere Pro, every major version requires you to upgrade your saved project, making a new copy "just in case", it's impossible to go back, and I've had it break several times). It's a single source of truth that describes a behaviour, and the compiler can get better over the years and generate better and better executables from that same code as it improves.
This is the worst argument ever, but it's still an important one: it's free, and works on any OS. There are definitely advantages to using off-the-shelf software, I myself am a heavy user, but I cringe every time I have to work on a messy document with other students, recently I had to work with another student that has macOS and could not get Word to open the document and display equations without converting them to images...
I find the Markdown/Word comparison similar to my experience with Docker and Windows, for those that are familiar with it. Windows, macOS and Linux (although Windows is the worst offender) get bogged down with bloat over time, dnagling files, layers of abstraction, derived from complexity. How many times I wish I could start from a base image, and add/remove (software) features as I go, like building a new Docker image, without losing data.
You bring up scientists, granted, not everyone uses it, but I believe LaTeX is more comparble to Markdown than to Word. It has a text-based source format that gets transformed and rendered as a PDF, but it's way, way too complex for the majority of use cases. If there's a better alternative to Markdown, I'd be glad to try it out, but for now it's my main choice for the long-term storage of information.
I just downloaded deb and was a bit worried that it has 60MB, quick check on forums and it us unfortunately Electron :( Oh well, back to vim and cd.
Last I heard it was built entirely by two people (and two cats). What’s a better way to build a high quality native-ish application targeting 5 platforms with a team of 2?
I started using Obsidian when it came out last year, and it instantly clicked for me. I immediately migrated 20 years of notes to it.
What differentiates Obsidian from all of the other tools in this area, is that they have made extensibility a top priority. The sheer breadth of plugins, themes, and other community-driven tools that have been generated in 18 months is spectacular. It makes it easy to recommend Obsidian because you can shape it into whatever you want.
There are a handful of plugins like Dataview, QuickAdd, Kanban and Periodic Notes that make Obsidian an incredibly powerful environment for thought.
I made a theme for Obsidian called Minimal that attempts to make the app feel more native, especially on Mac: https://github.com/kepano/obsidian-minimal
...and published a couple of my own plugins and a Web Clipper bookmarklet: https://gist.github.com/kepano/90c05f162c37cf730abb8ff027987...
The Obsidian community is just so fun, friendly, and collaborative, that you can't help but get involved and work on making the ecosystem better.
Quoted post unavailable.
- Have you ever tried using git on a docx file? The best you have is file history, but good luck trying to merge branches, create/apply patches, cherry-pick commits, rebase, or view line-by-line history.
- You lose the interoperability of plaintext. Any editor can open a plaintext file, and consuming a plaintext file is straightforward. Not so with binary.
- You lose a lot of choice about how you want to interact with the file. Syntax highlighting, TextMate bundles/snippets, and hundreds of editors and plugins are available to both create and consume Markdown (and many other text formats).
I agree that rich text editing is great, but may I suggest looking into another plaintext format besides Markdown if you can't find a wysiwyg markdown editor you like? There's RTF, TeX, and others -- each with a great ecosystem of tools around it.
More generally, if a particular plaintext format doesn't meet your needs, I'd argue the problem isn't necessarily that the format is plaintext as opposed to binary. Binary can be nice for serializing C/C++/etc. objects and for packaging resources, but there are tradeoffs.