Author Topic: I'm thinking of going primitive, with discursion into zettelkasten (Read 480713 times)

superboyac · « **Reply #150 on:** November 13, 2019, 12:15 PM »

I find it interesting that plain text / markdown solutions like Zettlr keep the files in a database.
WriteMonkey is the same (though documents can be bound to a file).
When I look at WM3 it seems to have all the features required for a zettelkasten, but I've never seen it mentioned in that context. Though it's very rarely mentioned in lists of markdown editors either.

I'm noticing that different types of notes may have different and predictable structures. Vacillating between using templates and autotext insert.
-Dormouse (November 10, 2019, 06:02 AM)

what do you mean by this? zettlr keeps the files just regular text files in whatever folder you like. you just open the file or folder. it has a database maybe for the program itself, but the files are all text files. the only thing the program seems to do is look for the ID somewhere in the filename or actual file itself. Is that what you are thinking too?

Dormouse · « **Reply #151 on:** November 13, 2019, 12:27 PM »

What do you mean a bound file? It's a text file on disk. How is that bound?
-wraith808 (November 13, 2019, 12:05 PM)

Their terminology, not mine.
My interpretation is that it's simply synchronising the database copy with the file copy. Doesn't impact editing the file using other programs.

On the basis of your video, my guess is that both versions do this in similar ways, although the details of the implementation vary. But know nothing of V2 since I started with V3.

The advantage of the method is that you have two copies of the file - one in the database, one as the file. Each copy can be worked on separately, but will be synchronised when WriteMonkey is active unless you turn the linking off.

wraith808 · « **Reply #152 on:** November 13, 2019, 12:31 PM »

What do you mean a bound file? It's a text file on disk. How is that bound?
-wraith808 (November 13, 2019, 12:05 PM)

Their terminology, not mine.
My interpretation is that it's simply synchronising the database copy with the file copy. Doesn't impact editing the file using other programs.

On the basis of your video, my guess is that both versions do this in similar ways, although the details of the implementation vary. But know nothing of V2 since I started with V3.

The advantage of the method is that you have two copies of the file - one in the database, one as the file. Each copy can be worked on separately, but will be synchronised when WriteMonkey is active unless you turn the linking off.
-Dormouse (November 13, 2019, 12:27 PM)

This is not how it's working in WM2. Check my post that I updated, i.e. from http://www.writemonkey.com/features.php

STANDARD AND CLEAN TEXT FORMAT
For maximum portability your work is stored in standard text files. Writemonkey is fully UTF-8 compatible and will recognize virtually all international characters. Supports other encoding standards ‒ Unicode, ANSII …

I really don't like this direction, personally.

I find it interesting that plain text / markdown solutions like Zettlr keep the files in a database.
WriteMonkey is the same (though documents can be bound to a file).
When I look at WM3 it seems to have all the features required for a zettelkasten, but I've never seen it mentioned in that context. Though it's very rarely mentioned in lists of markdown editors either.

I'm noticing that different types of notes may have different and predictable structures. Vacillating between using templates and autotext insert.
-Dormouse (November 10, 2019, 06:02 AM)
what do you mean by this? zettlr keeps the files just regular text files in whatever folder you like. you just open the file or folder. it has a database maybe for the program itself, but the files are all text files. the only thing the program seems to do is look for the ID somewhere in the filename or actual file itself. Is that what you are thinking too?
-superboyac (November 13, 2019, 12:15 PM)

I think we're finally getting on the same page- a lot had to do with the fact that I'm using WM2. WM3 actually *does* store its files in a database located in (on Windows) c:\Users\[user]\AppData\Local\Writemonkey 3\writemonkey3_sheets. It can sync with a local file, but it defaults to just storing everything there.

Which to me, is counterintuitive for a 'plain text' writing solution, and creates issues like this one:

https://github.com/w...onkey/wm3/issues/161

Store locally, operate on that file. It doesn't matter where the file is, if you just store it as plain text.

Dormouse · « **Reply #153 on:** November 13, 2019, 01:20 PM »

From the WM2 documentation
STANDARD AND CLEAN TEXT FORMAT
For maximum portability your work is stored in standard text files. Writemonkey is fully UTF-8 compatible and will recognize virtually all international characters. Supports other encoding standards ‒ Unicode, ANSII …
-wraith808 (November 13, 2019, 12:05 PM)

They can make the same claim in WM3. It's a plain text database.

Dormouse · « **Reply #154 on:** November 13, 2019, 02:18 PM »

What do you mean a bound file? It's a text file on disk. How is that bound?
-wraith808 (November 13, 2019, 12:05 PM)

Their terminology, not mine.
My interpretation is that it's simply synchronising the database copy with the file copy. Doesn't impact editing the file using other programs.

On the basis of your video, my guess is that both versions do this in similar ways, although the details of the implementation vary. But know nothing of V2 since I started with V3.

The advantage of the method is that you have two copies of the file - one in the database, one as the file. Each copy can be worked on separately, but will be synchronised when WriteMonkey is active unless you turn the linking off.
-Dormouse (November 13, 2019, 12:27 PM)

This is not how it's working in WM2. Check my post that I updated, i.e. from http://www.writemonkey.com/features.php

STANDARD AND CLEAN TEXT FORMAT
For maximum portability your work is stored in standard text files. Writemonkey is fully UTF-8 compatible and will recognize virtually all international characters. Supports other encoding standards ‒ Unicode, ANSII …

I really don't like this direction, personally.
...
I think we're finally getting on the same page- a lot had to do with the fact that I'm using WM2. WM3 actually *does* store its files in a database located in (on Windows) c:\Users\[user]\AppData\Local\Writemonkey 3\writemonkey3_sheets. It can sync with a local file, but it defaults to just storing everything there.

Which to me, is counterintuitive for a 'plain text' writing solution, and creates issues like this one:

https://github.com/w...onkey/wm3/issues/161

Store locally, operate on that file. It doesn't matter where the file is, if you just store it as plain text.
-wraith808 (November 13, 2019, 12:31 PM)

However you do it, there are potential problems unless you simply want standalone files and rely on file management tools. But many people want the advantages that can be got from a database solution: eg text search, linking, tagging.

The WM3 file binding feature means that you can have both at the same time.
And the database can be read as text.

The risk of a database is that there might be corruption. Most database programs attempt to deal with this through extensive backups.
The risk of separate files is that the link between the file and the program database gets lost (name change, location lost, files moved).

zettlr keeps the files just regular text files in whatever folder you like. you just open the file or folder. it has a database maybe for the program itself, but the files are all text files. the only thing the program seems to do is look for the ID somewhere in the filename or actual file itself. Is that what you are thinking too?
-superboyac (November 13, 2019, 12:15 PM)

Zettlr saves its files the individual files separately as .md files in its folder. I haven't checked about setting up other folders. If you move them in the folder, it keeps track (and if you move files into the folder, it sees them too). But if you move them out of the folder, it loses them. I assume that its database watches its folder(s) and simply keeps links to the files. The tagging must be part of an internal database. Text search probably is too - I'm assuming it keeps an index because it could get slow otherwise.

Dormouse · « **Reply #155 on:** November 13, 2019, 02:29 PM »

I find it interesting that plain text / markdown solutions like Zettlr keep the files in a database.
WriteMonkey is the same (though documents can be bound to a file).
-Dormouse (November 10, 2019, 06:02 AM)

What struck me as interesting was simply the simultaneous desires for the 'virtue' of simple plain text approach and the functional advantages of a database.
.txt is good; .md or .mmd is equivalently good (despite the existence of contradictory forms of markdown and the need for dual pane (or alternate views) editors so that it's possible for most people to use it) and .rtf is bad (although the text in the file can be read quite easily).

wraith808 · « **Reply #156 on:** November 13, 2019, 02:49 PM »

From the WM2 documentation
STANDARD AND CLEAN TEXT FORMAT
For maximum portability your work is stored in standard text files. Writemonkey is fully UTF-8 compatible and will recognize virtually all international characters. Supports other encoding standards ‒ Unicode, ANSII …
-wraith808 (November 13, 2019, 12:05 PM)
They can make the same claim in WM3. It's a plain text database.
-Dormouse (November 13, 2019, 01:20 PM)

WM2 doesn't involve the use of anything other than the files. There are no supporting files stored on your system. That's the difference. And it might be plain text, but that's pushing it. It's JSON, and definitely not what one thinks of when one says plain text.

However you do it, there are potential problems unless you simply want standalone files and rely on file management tools. But many people want the advantages that can be got from a database solution: eg text search, linking, tagging.

The WM3 file binding feature means that you can have both at the same time.
And the database can be read as text.
-Dormouse (November 13, 2019, 02:18 PM)

You can do the same thing still keeping text files. This is just how they've chosen to do it. It's an approach and a design decision- it's not the only approach to solving that problem.

Dormouse · « **Reply #157 on:** November 13, 2019, 02:53 PM »

For the reasons I stated at the beginning of the thread, I'm interested in a file based solution because I don't want to be reliant on any single database design (& other reasons). I'm quite happy to use databases, but I'd want the results in separate files reasonably speedily.

On that basis, I wouldn't use Zettlr. The files exist separately, but the tags and linking are tied up in the program.
I'd use WriteMonkey anyway for writing. But again tags and linking are tied up in the program.
Unique IDs and a text search program, might make them usable if the tags are unique strings.
Separate text files make a structure easier to rebuild, but it's not a complete protection. Though it is easier than extracting lots of bits from a single long text file.

So my zettelkasten solution has Unique IDs and tags in the file name with an indexed text search (made reasonably efficient by limiting the folders searched). And each file will be completely separate. The text search will be the only 'database'. I use a tags program, but won't be dependent on it.

wraith808 · « **Reply #158 on:** November 13, 2019, 03:45 PM »

How about some sort of plain text type wiki system? Ema Personal Wiki (https://jwbs-blog.bl...for-android-and.html) allows you to use it for the wiki functionality and work on plain text files. I work on my wiki outside of the browsing system at times (because the editor is pretty old, and I like to use sublime), but it is very easy to create the links even in a plain text editor. It's open source, so when I get the time, I was going to add an option to use the editor of your choice instead of the internal editor.

Dormouse · « **Reply #159 on:** November 13, 2019, 04:09 PM »

WM2 doesn't involve the use of anything other than the files. There are no supporting files stored on your system. That's the difference.
-wraith808 (November 13, 2019, 02:49 PM)

Where are the repository and backups and history kept if it's a files only program?

Dormouse · « **Reply #160 on:** November 13, 2019, 05:18 PM »

How about some sort of plain text type wiki system?
-wraith808 (November 13, 2019, 03:45 PM)

I've never really liked wikis. I tend to think of them as a database type solution using a single long text document. But they do tick all the required boxes.

I'm not unhappy with the separate file solution because there are always ways of managing files. It's a little more cumbersome up front. In use I'm not sure there's a difference. Depends on whether I stick with Tagspaces.

I haven't thought through a tagging solution yet. Tagspaces is inefficient in its use of space and will probably be inefficient if the tag numbers get too large. Simple words (the usual approach) are appealing but take a lot of typing and reading and hog limited spaces. I'm tending to a code system. # (it's a tag), 0-9 (ten major categories), A-z (52 main sub-categories assuming I'm not precluded from both cases) with the option of further numerals or letters if more are needed. But that's already indicating 520 tags using only three digits (admittedly 52 would be versions of 'other'). I know it would need a look up table, but would actually not take me long to learn 520 codes; I'd probably learn them as I went along. And would be followed if needed by simple words separated by commas. This would be a designed solution. How many tags are really needed if you have good text search?

wraith808 · « **Reply #161 on:** November 13, 2019, 05:24 PM »

How about some sort of plain text type wiki system?
-wraith808 (November 13, 2019, 03:45 PM)

I've never really liked wikis. I tend to think of them as a database type solution using a single long text document. But they do tick all the required boxes.
-Dormouse (November 13, 2019, 05:18 PM)

They don't have to be one text document. In fact, the one that I linked uses separate documents.

WM2 doesn't involve the use of anything other than the files. There are no supporting files stored on your system. That's the difference.
-wraith808 (November 13, 2019, 02:49 PM)

Where are the repository and backups and history kept if it's a files only program?

-Dormouse (November 13, 2019, 04:09 PM)

It has a toggle that you can switch to using a repository. But it's not inbuilt into the way that it handles files by default in WM2 as it is in WM3. I never used that feature, nor was it forced on me.

Dormouse · « **Reply #162 on:** November 14, 2019, 06:43 AM »

WM2 has a toggle that you can switch to using a repository. But it's not inbuilt into the way that it handles files by default in WM2 as it is in WM3. I never used that feature, nor was it forced on me.
-wraith808 (November 13, 2019, 05:24 PM)

The vast majority of even the most textish programs for writers work with a database. Keeps easy access to fragments, versions, chapters and scenes, characters, research etc. Even MS Word has effectively switched to that with 365 or OneDrive. For those that store separate files, it is generally easier to think of those as backups.

The WM developer seems to have developed WM to support his own writing & says he has done all his writing in WM3 for years. There were programming reasons for the switch to WM3, but I suspect that the change to database + bound files was because it worked much better for him as a writer. I'd concur. It makes it much more attractive to me for substantial use.

jeromg · « **Reply #163 on:** November 14, 2019, 07:46 AM »

I've been following this thread with interest and even though I guess I am strongly biased, I don't see anything that would beat my current text-only (markdown) setup : neovim + git + Nextcloud (this setup includes a couple of vim plugin like vimwiki and Voom to manage outlines). I get everything I need from folding to hoisting, outlines management, tags, backups, full undo history (through git), not to mention the incredible vim efficiency.
The only issue I can see is the rather steep vim learning curve. I fully understand this will not work for everybody.

Cheers,

Jerome

Dormouse · « **Reply #164 on:** November 14, 2019, 02:37 PM »

I don't see anything that would beat my current text-only (markdown) setup : neovim + git + Nextcloud
-jeromg (November 14, 2019, 07:46 AM)

I wouldn't argue with that though I can't see it being a good fit for me.

Looking over all the thread discussions so far, and forgetting digressions, the main issues seem either to be around long-term storage or optimal process and workflow.

Long-term storage
File based systems Versus database solutions
Plain text (inc markdown) Versus others (rtf, html, docx, odf, xml etc)

Workflow
Is zettelkasten worth it? What is it, if it is?

The ‘best’ solutions are very personal. We have different functional and usability needs, but it’s also a question of comfort and fit.
Naturally we have looked at a variety of software solutions. I was amused when I saw this quote:

I have grown weary of consumer geeks mistaking the tool for the work, and even more weary of the bizarro apple fan world in which notes apps are somehow second only to task managers for the tech mode du jour.
-https://appademic.tech/zettelkasten-thoughtful-plain-text-note-taking/

which was followed by going on about The Archive!

Personally, I will stick to file based solutions for long-term storage, even if they are less efficient in the short term. But I’m not bothered about file formats: I’ll go with the functionality I need. I anticipate most being rtf, pdf, txt, md, xls, html + images.

I’m not sure about zettelkasten. I see many advantages. I’m sure I can configure a system to suit me. I’ll give it two years, if I can, before making a judgement. I know my problem will be sticking to it consistently enough. When I started I was only thinking that I needed to give up OneNote/Evernote and their peers for anything long-term.

I remain happy to use database solutions for current workloads, with short-medium term outcomes.

wraith808 · « **Reply #165 on:** November 14, 2019, 04:16 PM »

WM2 has a toggle that you can switch to using a repository. But it's not inbuilt into the way that it handles files by default in WM2 as it is in WM3. I never used that feature, nor was it forced on me.
-wraith808 (November 13, 2019, 05:24 PM)

The vast majority of even the most textish programs for writers work with a database. Keeps easy access to fragments, versions, chapters and scenes, characters, research etc. Even MS Word has effectively switched to that with 365 or OneDrive. For those that store separate files, it is generally easier to think of those as backups.

The WM developer seems to have developed WM to support his own writing & says he has done all his writing in WM3 for years. There were programming reasons for the switch to WM3, but I suspect that the change to database + bound files was because it worked much better for him as a writer. I'd concur. It makes it much more attractive to me for substantial use.

-Dormouse (November 14, 2019, 06:43 AM)

While that might be true, in totally changing it so that you can't just work with unbound text files, he's forcing the users into his workflow though. Which is, in the end totally fine- there are several others who do the same (Atomic Scribbler for one). But I'm tied to my workflow, which works for me, and makes it so that I don't have to deal with my data being tied up in someone else's idea of what the process should be. I like using an external previewer for my markdown, and have it so that prowritingaid looks at the output for that preview, all spread out over my computers and monitors. This doesn't allow that.

Seeing that he gives you the option of binding to the local text file, I might try it to see if it works- WM was my choice when I wanted to just crank out some prose distraction free, and didn't want the hassle of dealing with a project as I do in Sublime. It might still work in that fashion, but if not, I still have WM2, and updates don't really matter to me as long as it works.

Dormouse · « **Reply #166 on:** November 14, 2019, 06:16 PM »

I still have WM2, and updates don't really matter to me as long as it works.
-wraith808 (November 14, 2019, 04:16 PM)

Absolutely.

I like using an external previewer for my markdown, and have it so that prowritingaid looks at the output for that preview, all spread out over my computers and monitors. This doesn't allow that.
-wraith808 (November 14, 2019, 04:16 PM)

Couldn't bound files be used that way?

I agree that it's critical that the software supports the way you want to work rather than you having to fit it. Though to some extent we've been shaped by programs we've used in the past.

From my point of view, WM is a very peculiar program. I've always been mouse based, and used the top down menus and ribbons to know my options as well as choose them. WM has no menus; there's a convoluted path through a Command Palette and various right click options but mostly it is keyboard shortcuts; actually, I'm being too negative, it does do many things with the mouse too. Wouldn't be so bad if it worked the way most writing programs do, but it doesn't. Seems to have a lot of text editor design and functions, though I'm not familiar enough with them to know. It's very different to the usual outliner design of Scrivener, Scribbler and all the others. Outline 4D is very different too, as was(is) Liquid Story Binder.

Nevertheless I like it a lot. Used it very simply to start with, and being able to set it up very easily to suit my eyes made a big difference to my attitude. And the folding always drew me back. Now I keep the wiki open and regularly read through the features. Try and work out how I can make use of each one. I can see how I can manage a major project right through with it (I've tended to write in it so far, then transfer the text to another program; which I will still do to some extent - I don't think I will edit in it). I wouldn't be able to do that if it didn't have both the database and the file binding. I can even see how it could become my main writing program.

wraith808 · « **Reply #167 on:** November 14, 2019, 11:22 PM »

Couldn't bound files be used that way?
-Dormouse (November 14, 2019, 06:16 PM)

We'll see. I'm going to try it out and see if I like it. It really depends on how well it works with git. I've changed the location of the files to my git repo, so I have the database and the individual files in the same repo. I'll see how it works out.

Dormouse · « **Reply #168 on:** November 15, 2019, 03:09 AM »

I'll see how it works out.
-wraith808 (November 14, 2019, 11:22 PM)

Makes sense. I'll be in a similar boat if I move major projects in and start deliberately using the database features. Wary of over-trusting the binding/syncing feature. I'd've been on to these details sooner if it hadn't been such a big effort understanding the UI.
-
It's now proving a bit like an Olde Curiosity Shoppe. Having been round it often enough to know where I am, I keep poking in obscured corners finding small features, and then realise how comfortably they solve a particular writing need. All completely obvious I expect to those who understand exactly where his design is coming from, but entirely opaque to me. Doesn't take much of that before I'm all poked out until I can start again the following day.

Dormouse · « **Reply #169 on:** November 15, 2019, 11:47 AM »

I've done minor testing with WM binding.

Renaming file breaks the link. WM simply resaves it with old name.
Moving file breaks the link. Ditto.
If the document is still open in WM, it seems not to be aware of any edit done outside WM
If the document isn't open in WM, it becomes aware of external editing and offers 3 choices:

keep the old WM document and unbind file
keep the document and overwrite the file changes
update WM document from file

Looks as if the binding is entirely about creating and maintaining a file copy. When it reopens a document with a bound file, it observes changes since the last saved state. It is otherwise unaware of any editing done outside WM (even if the file is changed and resaved in the meantime) and will simply overwrite them when it resaves itself as the document is closed.

I can cope with this. I might have liked to be able to rename or move the file, but will simply be careful about the timing of any move/renaming.
I don't think there's any chance I will want to edit the same document in WM and another program at the same time.
The big advantage of these files is simply having a file copy of the most recent version of the document, and that always remains true.

superboyac · « **Reply #170 on:** November 15, 2019, 03:26 PM »

Makes sense. I'll be in a similar boat if I move major projects in and start deliberately using the database features. Wary of over-trusting the binding/syncing feature. I'd've been on to these details sooner if it hadn't been such a big effort understanding the UI.
-Dormouse (November 15, 2019, 03:09 AM)

regarding the zettlr tagging system and the db....i get that there's a database, but let's say zettlr is no longer around, can't you just use the formatting around tags for another program to identify them as tags? like, if {} is a tag, then when you migrate, just say detect all those {} as tags. wouldn't that be sufficient? I feel like zettlr is hitting the nail on all these points.

Dormouse · « **Reply #171 on:** November 15, 2019, 04:38 PM »

regarding the zettlr tagging system and the db....i get that there's a database, but let's say zettlr is no longer around, can't you just use the formatting around tags for another program to identify them as tags?
-superboyac (November 15, 2019, 03:26 PM)

Personally I'd test it.
I assume that Zettlr keeps tags and links. Text search should be easily replicated.
Are the tags and links stored with the files or only in the database?
If it's in the files, then you can read the files and test how easy it is to set another program up to work with them. If the tags are in the metadata, it should be easy to find a program that will read and manage them. On Windows.
If it's only in the database - for example a list of tags with details of associated files - then I see no alternative to finding a program that can understand and import the database.

I suspect that the links could be more complicated.

Dormouse · « **Reply #172 on:** November 16, 2019, 07:10 AM »

My big problem at the moment is Tagging.
I go this way, then that.
I'm thinking of the situation in 10 years time (!) when I might have 100.000 notes (!!!).
(I expect far more than Luhmann because he was focused on one academic subject. I intend to put everything in - creative, practical, academic - and I cover many fields. My potential productivity gains come from having one system for everything.)

There will be indexed text search. It is possible on all platforms. I see no reason it shouldn't be reasonably fast. There will already be direct links. The visual benefit submerges entirely with that number. afaics, tags will primarily be filters. They might also operate as cross-links. So how many? How structured? How recorded?

The big advantage of having them in the file name is search speed. But changing the name breaks file links. And text search should be fast enough with indices. ? Another advantage is that it is, relatively, easy to add or remove tags.

Having them in the file itself requires a solution to add and remove content. Possible, but it's an extra step and an extra program. Unless the tags given remain forever unchanging.

Windows metadata is a possibility. But it's very specific and not robust - many changes will break it.

Sidecar files are another option. But they will need to be kept together and add extra complexity.

It is no wonder than the database solutions are so prevalent.

Of course, there's no reason to confine myself to one method
I could put the initial tags in the file and in the filename and use a database program for more ephemeral tags. No fiddling. Cross-platform to an extent. And probably I could produce and save a list of all the files with such tags and add it as a separate note.
-internal monologue

The big issue remains the design of the tag system. Luhmann didn't have tags or text search. He only had sections and subsections. And not a huge number of either. And only a very approximate ability to estimate creation or modification date.

The ultimate filtering power comes from the the multiplicative effect of using tag categories rather than a single long flat list. Especially when text search should be good at all possible flat list searches. I'm not sure how many categories will have many useful members though. So that is something I will have to work on.

Dormouse · « **Reply #173 on:** November 16, 2019, 01:13 PM »

Sidecar files are another option. But they will need to be kept together and add extra complexity.

It is no wonder than the database solutions are so prevalent.

Of course, there's no reason to confine myself to one method
I could put the initial tags in the file and in the filename and use a database program for more ephemeral tags. No fiddling. Cross-platform to an extent. And probably I could produce and save a list of all the files with such tags and add it as a separate note.
-internal monologue
-Dormouse (November 16, 2019, 07:10 AM)

I looked at the 'leading' database tagging programs, and failed to convince myself they would make sense for me.
I was already dabbling with Tagspaces.
So, I have provisionally decided to go with Tagspaces, but to use their sidecars. Theoretically at least they can be read on other operating systems; and, if not, they'll be good for short-medium term use and they won't break any links. I'll have to be careful to do any moving around from within Tagspaces, but I'm not intending to move them anyway.

I will put initial tags into the filename and directly into the file, just in case. Once I have worked a system out.

TaoPhoenix · « **Reply #174 on:** November 16, 2019, 02:33 PM »

For virtually all purposes I much prefer rtf to plain text.

Colours, fonts, tables, bullets etc all make a difference to my speed of apprehension. I will switch colour, or background colour, as part of my editing. It makes rtf much more practical for me than plain text. The ability to insert images is very helpful too.
-Dormouse (October 28, 2019, 01:11 PM)

An interesting (clash?) here is how much you intend to use any text processing tools. I agree with color layers visually - in a newer version of my paper book note system, I now use pencil and blue pen. (And when two types of page fold downs were not enough, I even ripped the sides of pages dog ear 2-3 times for crucial info!)

I just got a bit of clarity for me on accessibility (often with speed) vs "wonderful discovery" - when the field of knowledge starts to become too vast for you to retain natively in your mind, and certain things (could be many certain things!) need to be recalled quickly, especially in the "social context" where people who like to feel efficient want to "move on".

So if you want visual tools of RTF, certain text processing tools have trouble doing it with anything but pure text. A long time ago, I've commissioned various little widgets I think on oDesk as well as here, just because I sadly don't program. One project I tried was to build a "Super text processor" that had all these custom things it could do. So for example if your "main copy" is in RTF, the Super Processor could have native built in "create pure text shadow copy" which you could then parse, get something out of it, and then you paste it back into your RTF copy. Then instead of saving entire files as text, because you only need it for 10 minutes, it's still in the main Super Processor, then it goes away. My text file chess example is right down this alley, though there's gaming examples from my Ludum Dare adventures too.